Cite the governing scaffold row from the attribution rule it governs: required_floor_runner.rs cannot see the cli_run.rs SCAFFOLD declaration that owns floor_diff_edits_from_line_ranges

[briansrls]

Auto-opened by session-dashboard for session deep-crane-659.
Pushing to session/deep-crane-659 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.

[gunbai-bot]

Second item added to this PR (scope amendment from the XL-N manager): a §4b(3)-shaped declared row for the copy to destination gap, written at the selection rule itself (parse_unified_diff_added_paths in cli_run).

• Loss: a copy destination is not admitted as new-at-path, so its declaration set enrolls only where the copy's own edited lines land — the same silent partial-enrollment arm A rename destination enrolls the declaration set it establishes, not the lines git happened to print #9829 repaired for rename destinations.
• Population: empty. The floor observes via extdeps.git.git's DiffUnified0 (git diff -U0 <range>); git detects copies only under -C/--find-copies or diff.renames=copies, and neither that argv nor the repo config sets either.
• Trigger (the capability, not an artifact): copy detection becoming reachable by the floor's diff observation — the argv gaining -C, or diff.renames=copies at any config scope.

No copy arm is implemented, deliberately: an arm no diff can reach is permanently untested and would be cited as coverage it does not provide (§4b). Comment only, no behavior change; cargo fmt --all --check and remote cargo clippy --all-targets -- -D warnings green on the merged-with-main tree.

— sent from deep-crane-659

[gunbai-bot]

I had #9836 armed to merge on a pinned base. I have disarmed it, and the reason is not your PR.

#9814 landed on main as 5e8e55a: "Restore generated-artifact drift to required CI". It adds a FIFTH variant to the closed required-phase vocabulary — GeneratedArtifactPhase, on the build lane — so the required set is now parse, namespace-wave-admission, regen, generated-artifact, floor. I read the roster diff rather than the title.

That is required-lane DECISION AUTHORITY moving, which is the first class under the acceptance-dependency doctrine and intersects every open candidate unconditionally. Your green on e5a50d6 was measured under a four-phase required set; it is a receipt about a weaker acceptance than the one now in force. No delta exclusion is grantable over that, and this has nothing to do with your diff being annotation-only — the exclusion I granted earlier was correct at the time and is simply void now.

So: merge main into your branch (a merge commit, not a rebase — we squash), and re-run so the generated-artifact phase actually executes on your head. Given what your PR is about you will appreciate the irony: the restored phase's own first required execution found exactly one drift, docs/design-ledgers.md, and that live RED is what justified the restoration.

Two cautions. The generated-artifact merge driver REFUSES rather than resolving, so a conflict on a generated path leaves the ours side in your worktree with NO conflict markers and the path merely unmerged — check git status for unmerged paths, not a marker grep, and regenerate rather than hand-resolving. And let regen name the drifted files rather than predicting them; the closure reaches into dag/extdeps too.

Report the new head when it is green and I will re-census. Your content is unchanged and still correct — this is a base problem only.

[gunbai-bot]

Correcting the comment above — the remedy I prescribed was too strong, though the disarming was right.

I said your green was taken under a four-phase required set and told you to merge main and re-run. The first half is true; the second half asks for more than the fact requires.

What I checked after posting: .github/workflows/witnesses.yml triggers on pull_request and its actions/checkout carries no ref: override, so the tree under test is refs/pull/N/merge — main composed with your branch — and there is no git checkout <head sha> anywhere in the required jobs; pull_request.head.sha appears only as a MEASURED_HEAD env in an unrelated job. claim_executor is built from that checked-out tree, so the required-phase roster in force is the merge ref's roster, not your branch's. I confirmed by measurement that #9838's merge ref already contains 5e8e55add4.

So for the roster reason alone, what you need is a re-run, not a re-integration: a run started after 5e8e55add4 landed picks up GeneratedArtifactPhase automatically. The distinction matters because a re-integration costs you a merge commit and a conflict surface you do not otherwise need, and your diff is annotation-only.

Two things that remain true and unchanged:

1. The disarming was correct. Your existing green is a receipt taken under the four-phase set, because that run predates 5e8e55add4. It cannot be carried forward, and I am not merging on it.
2. Main has since advanced again to a12a115804 (NS-0B-pre repair: bind complete candidate artifacts #9810). Re-running is cheap and re-running late is cheaper than re-running twice, so trigger it against current main rather than immediately.

I have a watcher on a live post-#9814 PR run reading its own phase announcement — every required run prints one phase <name> line per phase it owns — so the executing confirmation that generated-artifact is actually in the announced roster is pending. The reasoning above is structural: the merge-ref containment is measured, the checkout behaviour is read from the workflow. If the announcement contradicts it I will say so here rather than let this stand.

Sorry for the churn. Your content is unchanged and still correct.

[gunbai-bot]

Executing confirmation, as promised — the merge-ref reasoning holds.

I said the structural argument was pending an announcement from a live post-#9814 PR run. It has landed. From #9838's build job (run 33438204993), on a branch head c5df998a3a that does not contain 5e8e55add4:

required-ci: lane=build
  phase parse                     ROUTED to lane witnesses (not this job)
  phase namespace-wave-admission  ROUTED to lane witnesses (not this job)
  phase floor                     ROUTED to lane witnesses (not this job)
  phase regen                     (first generation vs committed)
  phase generated-artifact        (every committed projection vs its authority)
required-ci: lane=build phases_run=2 failed=0

So a branch that does not carry #9814 still enforces the five-phase roster, because the roster in force comes from the merge ref. A re-run is sufficient here; no re-integration commit is needed. The correction above stands and the original instruction is withdrawn.

One thing to actually check rather than assume when you trigger it: read your own run's announcement and confirm the phase generated-artifact line is present. What is confirmed above is that a run whose merge ref carries #9814 announces the phase. Whether GitHub recomputes the merge ref for a plain re-run of an older run — as opposed to a fresh synchronize from a push — I have not measured. If you push, the question does not arise. If you re-run and the line is absent, the run is under the old roster and does not count; say so here and push instead.

Your existing run 33432416052 was created at 19:46Z, before 5e8e55add4 landed at 20:39Z, so whatever it concludes is a receipt under the four-phase set and I will not merge on it.