Skip to content

(Roadmap) RLM-Manager - #10441

Closed
gunbai-bot[bot] wants to merge 1 commit into
mainfrom
fix/triplicated-annotation-block
Closed

gunbai-bot[bot] wants to merge 1 commit into
mainfrom
fix/triplicated-annotation-block

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Auto-opened by session-dashboard for session tidy-swift-334.
Pushing to fix/triplicated-annotation-block advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

  • Title describes the change (not the session id or branch).
  • PR body summarises what and why (replace the TODO below).
  • Tests run: name the command (e.g. npm test, cargo test) and the result.
  • If this closes a work item, the body contains a Closes #N directive.
  • No commits on this branch are surprises (no fork/cherry-pick I did not make).
  • No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

  • TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

…deictics that no gate can see

`dag/test/claim/emit_copy_qualification_witness_test.dag` on main holds THREE copies of the
same block, at lines 2, 74 and 99. Only the first is #10425's repair. The other two are the
PRE-REPAIR text, and their deictics are now false at their positions:

    "Three rows stood HERE ..."          the rows were deleted by #10390
    "calibration mutants BELOW ..."      points at rows that are not below it
    "the rows ABOVE THIS COMMENT ..."    points at rows that do not exist

#10425 rewrote exactly those words for exactly this reason, recording that "a relocated
pointer that still says below is a false citation of exactly the kind this repository files."
Two stale copies then landed beside its corrected one.

HOW IT ARRIVED, and it is not #10425's fault. Two PRs cut BEFORE the repair (#10408, #10376)
carried their own copy of the block and landed after it. Neither contested a line, so the
merge UNIONED rather than refused and both sides' bytes survived. This is
`gunbc.recurring_failure_mode` `append_only_carrier_whose_serialization_shares_a_merge_region`
on ordinary source rather than on a roster: THE UNIT OF MERGE IS COARSER THAN THE UNIT OF EDIT.

WHY NOTHING CAUGHT IT. All three copies are leading blocks attached to declarations, so §4c is
satisfied and the parse phase is silent. The defect we spent the afternoon on announced itself
in 16 errors; this one is the same class, from the same commit family, and is invisible to
every gate we have. A green main is not evidence this did not happen.

This deletes copies B (74-91) and C (99-116) and keeps A at the module head — the one whose
deictics name the module. Result: one copy, zero false deictics, no unattached block, and the
file still ends at its last declaration.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LSzWg5t7F22xEtbd83fzQ6
@gunbai-bot

gunbai-bot Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor Author

Closing as already-landed, not as abandoned.

This PR was opened automatically against fix/triplicated-annotation-block, whose content merged twenty minutes ago as #10434 (3d4f0cec840). The branch survived only because gh pr merge --delete-branch could not remove it — it is checked out in this session's worktree — so the auto-opener found a live branch and raised a second PR for content that is already on main.

Verified it is a no-op rather than assuming it:

branch tip  2383da02d2a   521 lines, marker x1
main        3d4f0cec840   528 lines, marker x1
git merge-tree --write-tree origin/main <branch>   rc=0
merged result: 528 lines, marker x1, byte-identical to current main

So merging this would change nothing. The +0/-37 diff GitHub renders is against the branch's original base, not against current main — gh pr view --json files diffs the PR base, which is exactly what makes an already-landed branch look like outstanding work.

Nothing to rework and nothing lost. — sent from tidy-swift-334

@gunbai-bot gunbai-bot Bot closed this Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants