Repository navigation
docs(solution): current customer limitations for Fleet v0.6.0 - #45
Merged
Merged
Conversation
timothy-weston
changed the title
timothy-weston
force-pushed
the
docs/fleet-v0.6.0
branch
from
September 11, 2026 10:18
f4e3c7b to
4de02f2
Compare
Squashed for replay onto a main that has since restructured. The correction history this replaces is recorded in TODO.md deliberately, including the two control names and one reassurance that were published and withdrawn.
timothy-weston
force-pushed
the
docs/current-limitations
branch
from
September 11, 2026 10:37
481fac1 to
4fd04f9
Compare
Four wording changes. The point-cloud limitation explained a storage model the reader cannot act on; the floors section collapsed physical elevation into map level, which told a customer with a ramped site the wrong thing and sent one with stairs to ask us for a specification we do not have. Testing the actual route is the only check that decides it, so the section says that instead.
Go Home cancels a running mission before it sends the robot back, and that cancel takes the same unnarrowed path as Stop — so it belongs in the list rather than being left out as safe. Retry comes out for the opposite reason: the banner that offered it was removed, so the prop is passed but never read and there is no control for a customer to press.
The supplied render shows all three bases carrying a Weston Robot payload, which the previous one did not for the Go2. Resized to the 1500 px width it replaces and palette-quantized, since it is a card thumbnail — 761 KB of source would otherwise have landed on the two pages that use it.
The residency banner opened by calling itself a defect and spent seven blocks on a narrow, preventable case, which reads as alarm rather than guidance — it is a caution now, and says the conditions, the one-click precaution and that halting a robot still matters more. The second banner opened by referring to the first, which only works if you read them in order; it now states its own scope.
The two banners had been carrying four different behaviours between them. The investigation separated them, so each now says one thing: an unsent mission arriving, and a saved edit arriving early. A moved location travelling is normal by-reference behaviour and moves to Saved locations; a deactivated mission being dropped is a qualification on the deactivation rule, not a third alarm. The refusal table gets the numbered references its prose was already citing.
The page named the role that manages people but never showed the work, so a customer with the authority to add an account had no way to find it and reasonably read the support line as covering users too. Adds the procedure from the Users view, and says what Tenant Role None actually means — no tenant-wide authority, not no access. Sites stay with us, and that boundary is now stated where it bites.
The bars were drawn to the glyph bounding box, and the anti-aliased bottom edge let the tails of g and y through on five rows. Not readable, but real user names sat under them, so the bars now clear the descenders outright.
Two cautions had grown into a description of the defect's side effects, which read as though Stop and Go Home were ways to manage what a robot holds. Send to Robot owns residency and revision, and deactivation changes eligibility — that goes first. The divergence follows as one known issue with its three effects, said plainly as a defect being fixed.
Wording only — the contract and the three effects are unchanged. "Send to Robot is: it is" was awkward, the rows now say a mission may later run rather than implying it starts at once, and the check reads as a step instead of an abrupt label. The release number comes out: these pages describe the product as it is, and a version in the prose dates them the moment it ships.
"Nor does activating one" only parsed if you had just read the sentence above it, and the paragraph no longer needs to lean on that — it now leads with Send to Robot in its own right. Naming both steps in the opening says what the paragraph is about before the reader has to infer it.
The defect is tracked in Fleet and will be fixed rather than lived with, so the page teaches how sending is meant to work and stops there. Removing it also takes out the three Known limitations rows that pointed at it; the unrelated ones stay.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current customer-facing limitations layer for the Robot Management Toolbox and the Robot Deployment Toolbox, against production Fleet v0.6.0.
What this adds
Two limitations that were verified against Fleet source rather than inferred, and are kept deliberately separate because their consequences and eventual fixes differ:
A mission you have never sent can still reach the robot. Fleet has ruled this a known production contract violation of ADR-056 §5 — a distinct sibling defect of their #372, not an accepted semantic. Stopping or acknowledging a saved mission that was running to its schedule rebuilds the robot's mission list from every currently-active saved mission, so one the robot was never sent can arrive and then run to its own schedule. Published as a
:::warningwith the one precaution that was tested against the affected rebuild: deactivate an active mission that is not on the robot and should stay off it.Saved changes can reach missions the robot already holds, during other work. Separate and lower-severity: for a mission already on the robot, its content is rebuilt from what is saved now — so an unsent edit, or a saved location that has moved, can travel with ordinary work. Includes the case with no press behind it at all, where a one-off run simply finishing republishes the set.
Both sit in
mission-editing.md› Sending missions to a robot, with one index row each. Nothing is duplicated across pages.Alongside them: the Known limitations sections the solution template requires, desktop-browser boundaries, the multi-level wording, localisation and Init Pose troubleshooting, and the unexpected-error guidance.
What was deliberately not published
The persistent confirmed-checkpoint enumeration stays engineering-only — it states completed work, asks for nothing, and blocks nothing, and the sweep's semantics are frozen pending a v2 model. Mission-wide background audio is neither a current feature nor a current limitation; an earlier false claim was removed and the tree is clean. Per-checkpoint Announce remains documented as real.
Both rulings are recorded in
TODO.mdwith their reasoning, so the next person meeting the same finding does not re-derive them.Review notes
Two customer controls were published during this work and withdrawn after tracing the UI rather than the handler behind it — a Quick Dispatch on this release acknowledges through the execution path, which narrows correctly, and Go Home establishes no residency at all. A reassurance that an unsent mission could never arrive was also published and withdrawn once the trace reached the paths that disprove it. Those corrections are in the history and the reasoning is in
TODO.md.No unconditional "only Send to Robot can change what the robot holds" claim survives on this branch.
Ordering
Depends on #43, which owns the supported v0.6.0 workflow and is still open. This branch must be rebased onto
mainafter #43 lands, not before — both touch the same four files, and #43 carries three absolute Send to Robot statements plus a corrected· needs reviewparagraph that this branch should adopt rather than re-write. The reconciliation steps are listed inTODO.md.Docs issue #38 stays future work and is gated behind both.
Validation
npm run build,npx tsc --noEmit,npm run typecheck,npm run check:video,npm run check:downloadsandnpm run test:filesall pass one3a8225. The build runsonBrokenLinksandonBrokenAnchorsasthrow, so passing it is what proves the cross-section anchors resolve.