mapping pipeline: review + land the design doc - #114
Closed
MJohnson459 wants to merge 1 commit into
Closed
Conversation
… CLAUDE.md The design landed in #111 and the month since has built four of its ten items, so the doc described work as pending that is in main and attributed two of it to the wrong task. Each work-breakdown item now names its Voro task and takes that task's state as its own, and the doc is registered as Voro doc 1 so the derivation is queryable from either end (`voro doc show 1`). Corrections the review found: - Item 8 (candidate zone editing) was credited to task 339. That is the preview pane; the editor is task 346. Stage 3's third bullet carried the same mistake. - Items 4, 7 and 8 read as unbuilt. 7 and 8 are in main (PR #100, #101), and 4 is in review (PR #113) — which also moved where it runs: a workstation beside `bag_replay`, not the fleet box, until item 5 gives a builder standing to upload. Its invocation is `map-build -- --bag <bag>`. - Stage 3's "see the candidate" described an overlay on the promote picker. What shipped is a `review` mode that stands the operations panes down, because two canvases is the confusion the pane exists to remove. The substantive finding is stage 2's step 5. It was written on zone/v0's vocabulary/binding split — names stable, coordinates rebuilt per revision — and made carry-forward a re-binding of names onto new geometry. Task 625 settled that the other way on 2026-09-02: a zone is a coordinate in the floor's frame, a fact about the building, so a rebuild moves no zone and the same-frame half of the step is void rather than easier. The step keeps what survives — matching new rooms to existing zones, proposing the leftovers, the report the review pane reads — and states the reversal rather than quietly rewriting around it, since 625 has not landed. Task 345 is parked behind 625 and carries the rescoping; its acceptance also still named `aliases` and `kinds`, which task 491 retired. CLAUDE.md gets a short section beside the fleet design references pointing at the doc: the four stages, the two rules that do most of the work, and where the state of the work lives. Verified: `mkdocs build --strict` passes (the doc was already in the nav from #111); pre-commit clean on both files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018MSorjZAVQsDoXfmJsJwDt
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
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 design doc itself landed in #111 while this task sat in the queue, so the
work here was the review half: reconciling the doc with a month of shipped
work, indexing it from CLAUDE.md, and wiring the work breakdown to its Voro
tasks in both directions.
The doc against what landed
Four of the ten items have moved since the doc was written, and it described
three of them as pending and attributed one to the wrong task. Every item now
names its Voro task and takes that task's state as its own.
zone editor is task 346 (PR mapping pipeline: candidate zone editing from the dashboard #101). Stage 3's "edit before promoting" bullet
carried the same mistake.
4 is in review (PR mapping pipeline: map-build orchestrator #113), which also moved where it runs — a workstation
beside
bag_replay, not the fleet box, until item 5 gives a builder standingto upload — and its invocation is
map-build -- --bag <bag>.What shipped is a
reviewmode that stands the operations panes down,because a canonical canvas with robots on it beside a candidate one without
is the confusion the pane exists to remove.
(341, 344, 347).
The substantive finding: stage 2, step 5
Carry-forward was written on zone/v0's vocabulary/binding split — names are the
stable half, coordinates are rebuilt per revision — and so made the step a
re-binding of names onto new geometry. Task 625 settled that the other way on
2026-09-02: a zone is a coordinate in the floor's frame, a fact about the
building. The kitchen does not move; a map is an estimate registered into that
frame. So a rebuild moves no zone at all, and the same-frame half of the step is
void rather than easier, while the cross-frame half becomes a question about the
map's registration and not the names'.
The step now states the reversal rather than quietly rewriting around it, since
625 has not landed. What survives is written out: match new rooms to existing
zones, propose the leftovers, emit the report the review pane reads. The "Stays"
row no longer claims the split stays, and the scope note points at 625.
Task 345 carries the rescoping: parked behind 625 (it would otherwise be written
against
binding.yamland rewritten immediately), with a note recording that itsacceptance also still named
aliasesandkinds, which task 491 retired.Cross-referencing
Registered the doc as Voro doc 1 and linked the twelve tasks it spawned, so
voro doc show 1is the progress view for the whole design and each task showsthe doc it derives from. Six task bodies still pointed at the unpushed branch
mapping-pipeline-design/af9cc81; those now name main and PR #111 (343 got anappended correction rather than a body replacement, since
voro showinterleavesits completion summary with the body and a clean extraction was not safe).
CLAUDE.md
A short section beside the fleet design references: the four stages, the two
rules that do most of the work (the live config is never deliberately hobbled;
a build gates on what it can measure and reports the rest), and a pointer to the
work breakdown as the state of the work.
Verification
mkdocs build --strictpasses — run twice, after each edit round. The doc wasalready in the nav from mapping design: the alignment step's lattice does not exist and its residual is unmeasurable #111, and the one path named that does not exist yet
(
docs/tuning/2026-09-01-map-build.md, banked with PR mapping pipeline: map-build orchestrator #113) is a code span,which
docs/hooks/repo_links.pydoes not resolve.pre-commit run --files CLAUDE.md docs/design/mapping-pipeline.mdclean.ASCII diagram and the stays/changes table.
No code changed, so there is nothing else to run. Branch
mapping-pipeline-land-340, commit b13dbec, not pushed.