Repository navigation
The strip's coordinate map: the transport half of the lineage rule - #10247
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
gunbai-bot
Bot
changed the title
|
Addressed review 59359. Two defects sat inside its one finding and they had different repairs. The dangling field — deleted, not fed. I extended the subtraction one layer past the finding, and flagging it because it is a judgement Both fields come back in the same change as the comparison fold that reads them — the one that also The title. Retitled to what the change is. Canary v1 was deleted three PRs ago (6d0963a) and 🤖 Generated with Claude Code |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 07f11ba2f8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| post_second: post_second | ||
| ), | ||
| stripped: stripped, | ||
| coordinate_map: coordinate_map, |
There was a problem hiding this comment.
When run_current_step0_candidate reaches the observed arm, this value exists only in the internal Step0PairArms: step0_candidate_receipt_of_run never reads it, and Step0CandidateObserved exposes only the existing v2 receipt and counts. A repository-wide search finds no other consumer of arms.coordinate_map, so after the one sealed dispatch returns, callers cannot relate post-strip reference spans to their original occurrences and therefore cannot produce the intended paired binding-provenance census without rerunning the strip and violating the run's same-observation guarantee. Thread the map into the returned receipt/census rather than discarding it here.
Useful? React with 👍 / 👎.
… it is produced and witnessed Review 59359 is right on the narrow point and the repair is SUBTRACTIVE. The strip's coordinate map belongs where it is produced -- std.import's rewrite fold accumulates it as it moves the bytes, and an executing witness pins every retained segment in both original and rewritten coordinates by exact identity. That half stays. What went is the storage with no reader. Step0PairArms.coordinate_map was declared and written and read by nothing, which is DESIGN section 6's "a new artifact with no final consumer" exactly. The same objection lands one layer down the moment that field goes: Step0SourceStripped.coordinate_map had precisely one reader, the pair-arms writer, so removing the reader without removing the field would have moved the dead field rather than deleted it. Both are gone. The fields come back in the SAME change as the comparison fold that reads them -- the one that also mints the sealed retained-reference lineage, so the pre/post join never has a spelling-or-span address available to it in the first place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RvMEJFpYsy55NRdJ1Az4Vd
988d6fd to
a733a8e
Compare
strip_import_statementsnow reports, beside the rewritten source and the removed statements, thecoordinate map: one segment per RETAINED region, carrying both its original and its rewritten
[start, end). The rewrite fold produces it as it moves the bytes, so the map is an artifact of theauthoritative edit rather than a reconstruction of it.
Why the transport half is worth landing alone. Import removal shifts every later offset, so a
later pre/post comparison over reference occurrences cannot join by span, and it must not join by
spelling either — two implementations emit identical receipts on any fixture set, one carrying real
lineage and one guessing from an adjusted offset that happens to land. The rule that follows is that
the comparison never gets a spelling-or-span address to join on: a sealed retained-reference lineage
minted inside the typed strip walk is the only thing it may consume. Coordinate transport through
the authoritative edit is legitimate; coordinate equality as semantic identity is not. This PR
is the transport, and nothing here is that join.
The executing evidence is
the_rewrite_reports_every_retained_segment_in_original_and_rewritten_coordinatesin
test.claim.namespace_step0_strip_producer_witness, asserting the whole segment list by exactidentity rather than by count. The retained newline between two adjacent imports is its own segment
on purpose: it is what goes red if two removals apply one stale offset twice instead of accumulating.
What review 59359 caught, and the repair.
Step0PairArms.coordinate_mapwas declared, written,and read by nobody. That is storage with no consumer — DESIGN §6's "a new artifact with no final
consumer" — and it passes every check this project has: it compiles, it is typed, it even has a
witness one layer below. The question that catches it is not "is this correct" but "who reads this,
by name". Both dangling fields are deleted: the pair-arms one, and
Step0SourceStripped.coordinate_map,whose only reader was that pair-arms writer — removing the reader without the field would have moved
the dead field rather than deleted it. They return in the same change as the comparison fold that
reads them.
What this PR does not contain, said plainly because its previous title claimed otherwise. Canary
v1 was deleted three PRs ago in 6d0963a, and there is no binding-provenance census here. The
title had been inherited from a work item; squash-merge would have made it main's permanent record of
a commit that does neither.
🤖 Generated with Claude Code
https://claude.ai/code/session_01RvMEJFpYsy55NRdJ1Az4Vd