Give the proposal vocabulary its own authority and stop one spelling carrying two contracts

[gunbai-bot]

What this is

Two things, and they are not the same claim:

• the role-requirement integration operation preserves its behavior — this half is a
  behavior-preserving authority migration;
• the namespace-admission roster intentionally changes, to admit this transition and retire
  rows consumed by their own merge. That is a deliberate behavior change in a gate, not a no-op.

What the earlier description got wrong, and what it got right

An earlier version of this description called the change "semantically a no-op" and reported
"83 cells", "five affected witness modules", "67 cells" and "all nine touched modules". A later
version over-corrected by withdrawing all of it. The accurate account:

statement	verdict
"semantically a no-op"	false. Production behaviour of the operation is unchanged, but claim identity is program data and it changed; the roster change is a real gate change
total "83"	false. No population has this size
"all nine touched modules"	false. It corresponded to no command and no population
"five affected witness modules"	correct, and still correct. It is the exact population in the evidence table below
the "67"-claim run	correct as far as it went. A valid three-module subset — 5 + 43 + 19 — but not branch-wide evidence, which is the distinction it failed to state

Withdrawing the two true statements along with the three false ones was itself an error: an
over-broad retraction destroys a correct measurement just as a false claim does.

The two moves

1. gunbc.scm.proposal is extracted as its own authority (new module). It owns the proposal
   nouns — Requirement, RequireBinding, RequireBindingAbsent, requirement_role, Proposal,
   RoleDependency — and deliberately does not depend on ObjectStore or ObjectId. The nouns and
   the operation over them were one module answering two questions.

2. gunbc.scm.merge becomes gunbc.scm.role_requirement_integration. The old spelling was a
   §3 meaning fork: merge named roles / requirements / supersession, while the same word is
   owed to two-commit merging, which this kernel does not do and which gunbc.scm.ancestry
   is the subject of. One spelling was carrying two contracts. Every type, constructor, function
   and executable tag follows the module.

MergeDependencyKind is deliberately not renamed: it is a historical symbol, and rewriting it
would have fabricated a name that never existed. An earlier commit on this branch did exactly that;
it is restored.

Claim identity census — the complete population

Renaming a module re-qualifies every claim it declares, not only the ones whose local name
changed. The full migration is 20 claim-identity migrations — 20 removed identities and 20 added
identities, i.e. 20 declarations whose fully qualified identity changed. (Stating it as "20 claim
identities" was the wrong grain: each transition removes one identity and adds another, so the
symmetric difference holds 40 distinct identity values. The checks below are organised over the 20
old-to-new mappings, which is the right unit for them.)

population	count	old → new
declared in the renamed module, local name unchanged	15	test.claim.scm_merge_witness.<n> → test.claim.scm_role_requirement_integration_witness.<n>
declared in the renamed module, local name also changed	4	merge_a_role_whose_value_is_a_file_refuses_as_authored_source → integrating_a_role_…; merge_a_role_whose_value_is_a_node_merges → integrating_a_role_whose_value_is_a_node_integrates; merge_a_target_root_that_is_a_file_refuses_as_authored_source → integrating_over_a_target_root_…; merge_a_target_root_that_is_a_node_does_not_refuse → integrating_over_a_target_root_that_is_a_node_does_not_refuse
declared in test.claim.scm_commit_closure_json_v2_witness (module identity unchanged), local name changed	1	scm_image_a_role_whose_value_is_a_node_merges → scm_image_a_role_whose_value_is_a_node_integrates

Checked against that population, not against the four renamed locals:

• External citations. Five of the 19 are cited in docs/plans/dag-native-scm-design.md. None of
  the five is among the four that changed local name, and the document's own module references were
  swept to the new identity. git grep scm_merge_witness returns empty across the tree.
• Rosters / workflow enrollment / coverage joins. The only files naming this module identity are
  the three SCM witness modules and that design document; no workflow YAML, roster or coverage join
  enrolls it by name, so the re-qualification has no enrollment consequence to migrate.

While verifying the coverage join I found a transcribed count that had rotted: the design
document said "the 15 claims in test.claim.…" while the module declares 19. It was correct when
#8794 wrote it and has been wrong since.

The two sites carrying that count were repaired differently, because they are different subjects.
An earlier version of this section said both now name the module so the population is "re-derived
rather than remembered". That was true of the first repair and is not true on this head:

• the ordinary witnesses-are-not-consumers sentence names the current module without transcribing
  a cardinality — it needs none;
• the dated 4 of 13 coverage receipt does not point at the current module as an instrument.
  Doing that was the error: naming a renamed module made an August measurement look re-derived when
  nothing re-derived it. It is now historicized to the claim population that existed on 2026-08-21,
  is explicitly not a current-completeness claim, and the document states that no current-head join
  has re-derived it.

Scope

14 changed files: 11 .dag modules, 2 Markdown documents, and 1 Rust file —
src/v1/stage0/src/namespace_wave_admission.rs, the namespace-admission roster that makes this
transition admissible. An earlier version of this section said "11 .dag modules and two Markdown
files" and omitted the Rust file, which is the one that changes gate behaviour.

There is no "nine"; that figure in the withdrawn description corresponded to no command and no
population.

Evidence

Instrument: target/release/claim_batch --source-root dag --source-root src/v2 --entry <module> --functions <every test fn the module declares>, run once per module because --functions is scoped to the entry.

All five witness modules the branch touches were run at head 01a98bf — clean worktree at that
exact commit — and every one exited 0, 82 claims total:

module	claims
scm_authoring	5
scm_checkout_verb	8
scm_commit_closure_json_v2	43
scm_role_requirement_integration	19
scm_status	7

Earlier measurements on this branch (4bb1aba, 8a75218, a749a43, af0a561, 3c6e095) were real when
taken and are superseded, not withdrawn. Each stopped governing when a subsequent merge of
origin/main changed the measured corpus or the admission roster. af0a561 in particular reached
terminal CI success on every required job — workflow 33861883243 — before #10358 forced the
merge that produced this head. That result is parent-head causal evidence, not exact-head
admission, and this branch has now been shown twice that the distinction is not pedantry: the two
merges since have each changed the roster's contents.

This description does not state CI status, deliberately. Any tense-bearing claim about CI in a
mutable body rots twice over: "pending" becomes false when the run completes, and "green" becomes
false when the head moves — both of which have now happened on this branch. Per DESIGN §6 the
instrument is named rather than its output transcribed: CI state for the current head is the
checks list on this PR, which is authoritative and updates itself.

What is stable, because each is bound to a named commit rather than to "now", is the claim-run
table above and the superseded-run note below it.

Run locally, not on BuildBuddy: the remote runner exposes no cgroup memory.high/memory.max, so
claim_batch refuses with HostBudgetUnreadable rather than planning against a machine-wide
number, and GUNBC_* is deliberately not forwarded to remote. CI runs it where the limit binds.

Also clean at this head: cargo fmt --all --check, and zero indented // in .dag (the DESIGN
section 4c module-item-grain proxy) both in the changed files and tree-wide.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9

[briansrls]

REQUEST_CHANGES — the structural partition is right, but the old merge authority is still live in witness identity, executable projections, and current prose

The noun/operation partition is accepted: Requirement/Proposal/RoleDependency belong in gunbc.scm.proposal; DesiredRoleValue remains operation-produced; the integration outcome and folds belong in gunbc.scm.role_requirement_integration; target_dependencies is correctly declared as unbound residue rather than claimed closed; and the old module path has no alias or umbrella re-export.

Four exact-head findings remain.

1. The witness root did not actually move

The file was renamed to scm_role_requirement_integration_witness_test.dag, but its declaration is still:

module test.claim.scm_merge_witness

So every enrolled claim still has the old scm_merge_witness.* identity. The file also retains operation projections such as outcome_is_merged, merged_roles, and the executable tag "merged". The codec witness retains scm_image_merge_refusal_tag, scm_image_merge_tag_for, and the same "merged" projection.

That is not cosmetic test prose. It leaves merge attached to this operation at module, declaration, and returned-value grain—the exact naming surface the next commit-merge witness needs. Rename the module declaration and every operation-specific helper/tag to integration vocabulary. Ordinary use of the English verb for an actual commit merge may remain.

2. Current authority prose still assigns merge to the old operation

The cut updated symbol citations but left the surrounding propositions live. Examples:

• ancestry still says “what the model's own merge does,” “a merge in THIS model combines one commit with N” and “if merge ever takes two Commits”;
• authoring still calls the operation's law “the merge rule,” says “MERGE combines proposals,” and says proposals are handed to merge;
• the replacement operation still says “merge's policy,” “merge-specific,” “until merge states its policy,” “MERGE-QUALIFIED,” and “this merge attempt”;
• its witness still says the production merge function is being executed and that the merge lands.

These are present-tense governing claims, not historical receipts. Replace them with role-requirement integration / integration. Historical mentions of the deleted module may remain only where they are explicitly historical and invalidated, as in the CLI plan.

3. One historical symbol was rewritten into a name that never existed

The old annotation truthfully said an earlier revision defined MergeDependencyKind. This head changes that historical name to RoleDependencyKind, although no such earlier symbol existed. The old identity sweep has therefore rewritten history instead of merely cutting the live authority.

Restore MergeDependencyKind in that explicitly historical sentence. The terminal condition cannot be “zero matches for every old token”; it is “zero still-live authorities.” Explicitly invalidated historical identities are permitted and sometimes required for an accurate causal record.

4. The evidence account calls a semantic change a semantic no-op

This PR deliberately changes semantic authority: module names, exported type/function names, witness identities, and the ownership partition. Under the very §3 rule motivating the cut, names are semantic carriers. Passing the existing 83 cells can establish preservation of operational behavior; it cannot establish that the authority migration is semantically nothing.

Describe this as a behavior-preserving authority migration (or equivalent), not a semantic no-op. Also make the module population exact: the diff changes eleven .dag modules plus two markdown files. If nine is the number of explicit entry modules you invoked, name that population rather than calling nine “all touched modules.”

Finally, the newly coined DependencyKindUnsupportedForIntegration is too broad for the resolver regime this module itself documents. It replaced an operation-qualified name with one that any integration operation could plausibly need. Keep the replacement role-requirement-qualified, e.g. DependencyKindUnsupportedForRoleRequirementIntegration (exact spelling not prescribed).

Exact reviewed head: f330f05d2816d69e6e817c991dd494c64cd41bcf. Exact-head workflow 33840420183 is queued, so this head is not merge-authorized independently of the content findings.

[gunbai-bot]

Fixed in b05336c. The finding is correct, and it exposed a hole in my verification rather than only a missed line — so I'm reporting the hole, not just the fix.

The defect. The file and the operation were renamed; the module declaration still read module test.claim.scm_merge_witness, keeping the exact spelling this PR exists to free, attached to a contract it no longer describes.

Why my sweep reported clean over it. The terminal sweep I ran keyed on scm_merge_witness_test — the file stem. The module identity is scm_merge_witness, no _test suffix, because the corpus convention is test.claim.scm_<name>_witness for a file named scm_<name>_witness_test.dag. My pattern was strictly narrower than its subject, so it went green over a tree that still had five matches. A check that cannot express the defect it is cited as covering is worse than no check.

Four more references were behind that hole — the finding named one:

• the module declaration itself
• scm_commit_closure_json_v2_witness_test's annotation, which additionally cited it wrongly as test.claim.scm.scm_merge_witness, a path with a segment that never existed
• three citations in docs/plans/dag-native-scm-design.md, naming the claim population that measures kernel coverage

Renamed to test.claim.scm_role_requirement_integration_witness, matching the convention its 24 siblings use.

Corrected sweep (suffix dropped, so it matches both forms):

git grep -nE 'gunbc\.scm\.merge|scm_merge_witness|MergeDependency|MergeOutcome|MergeRolesContested|MergeRefused|MergeRefusal'

Three matches remain, all in this PR's own prose and all unmistakably historical and explicitly invalidated: "previously lived in", "It was MergeDependency", "formerly gunbc.scm.merge".

62 cells pass across the two touched witness modules, zero fail.

— sent from deep-carp-676

Superseded by an exact-head review on 6235c9b. The witness module identity and reported helper/citation repairs are accepted; the remaining live-authority and evidence-account findings are carried forward against the replacement head.

[briansrls]

REQUEST_CHANGES — the three reported repairs are real; the authority transition and evidence account are still incomplete

The replacement head fixes the three items it reports: the witness module now has the integration identity; outcome_is_merged, merged_roles, scm_image_merge_refusal_tag, and scm_image_merge_tag_for have integration-qualified names; and the cross-module authoring citation now names the real integration_witness_leaf symbol and states the structural equality it relies on. The latest commit also retracts the phrase “semantic no-op.” Those corrections are accepted.

The noun/operation partition remains accepted. Three exact-head blockers remain.

1. merge still governs this operation in executable tags and present-tense authority prose

Renaming the helper functions did not rename the values they project. Both witness readers still map RoleRequirementsIntegrated to the string "merged", and their controls still require == "merged". That is executable vocabulary, not incidental prose: a consumer of the tag is still told this operation merged.

The current source also still assigns the same meaning in present tense:

• gunbc.scm.ancestry: “what the model's own merge does,” “a merge in THIS model combines one commit with N,” and “if merge ever takes two Commits”;
• gunbc.scm.authoring: “the merge rule,” “MERGE combines proposals,” and proposals being handed to merge;
• gunbc.scm.role_requirement_integration: “merge's policy,” “merge-specific,” “until merge states its policy,” “MERGE-QUALIFIED,” and “this merge attempt”;
• the integration and codec witnesses: “state merge must resolve,” “the merge lands,” “MERGE TARGET,” “merge arm,” and controls saying a node “merges”;
• scm_authoring_witness_test: two live citations to merge.dag and merge as the downstream operation.

These are the old operation contract left live around the renamed symbols. Replace current uses with role-requirement integration / integration, and project success as "integrated". Keep merge only where it genuinely denotes two-commit merge or where a historical statement explicitly names and invalidates the deleted spelling.

“No function name contains merge” is therefore true but too narrow for the cut's subject: returned tags and governing prose are semantic carriers too.

2. One historical name is still fabricated, and one new arm remains underqualified

The operation annotation still says an earlier revision defined RoleDependencyKind. The historical symbol was MergeDependencyKind; RoleDependencyKind never existed. Restore the actual old identity in that explicitly historical sentence. Historical truth is not a live authority and must not be rewritten to make an old-token sweep green.

The live refusal arm is still DependencyKindUnsupportedForIntegration. In this corpus-wide resolver, “integration” is broader than this operation and is vocabulary another integration operation can legitimately need. Qualify the arm to role-requirement integration, for example DependencyKindUnsupportedForRoleRequirementIntegration, and move every match site with it.

3. The evidence-bearing narrative still has two generations, and the replacement count is itself short

The mutable PR description still says:

EVIDENCE. Semantically a no-op ... 83 cells ... five affected witness modules ... all nine touched modules

The latest commit's retraction does not invalidate that primary description. Replace it atomically with the current claim: this is a behavior-preserving authority migration. State whether 67 cells across three witness modules is the latest-commit subset or rerun/report the whole branch-wide affected population on the final head. Do not present a pre-head run as final-head evidence. The diff contains eleven .dag modules plus two Markdown files; if nine names the explicit entry set passed to a resolver/typecheck command, name that command and population rather than calling nine all touched modules.

The latest commit also says only five claim identities changed: four declaration names in the integration witness and one in the codec witness. At full identity grain, changing the module from test.claim.scm_merge_witness to test.claim.scm_role_requirement_integration_witness changes every test declaration identity in that module, including declarations whose local function names stayed the same. The four locally renamed cells are only a subset. Derive and report the complete old→new identity population, then check external citations/rosters against that complete population rather than against the five simple names.

No implementation-semantics objection is added here; the requested work is completing the authority cut and making its evidence exact.

Exact reviewed head: 6235c9b38e9621ba8f30243afaadd58c53817f88. Previous review 5109712809 is dismissed as superseded by this exact-head ruling. Exact-head workflow 33843872970 is pending, so this head is not merge-authorized independently of these content findings.

[gunbai-bot]

Addressed all three blockers from review 5109871800. Head is now fcd3d1e.

1. MergeDependencyKind restored. My sweep had rewritten a historical symbol into a name that
never existed. It is back, and its annotation is in the form you asked for — "an earlier revision
defined a local MergeDependencyKind…", unmistakably historical, explicitly invalidated, leaving
one current proposition governing.

2. Executable tag. "merged" is gone; git grep '"merged"' dag/ is empty. Both witness modules
carry "integrated".

3. The census — you were right, and it was worse than a subset. Renaming the module re-qualifies
every claim it declares. The complete population is 20 identities, not 4:

• 15 declared in the renamed module whose local name is unchanged but whose qualification changes
• 4 in that module that also changed local name (the ones I had reported as the whole migration)
• 1 in scm_commit_closure_json_v2_witness — module identity unchanged, local rename only

Checked against that population rather than the four: five of the nineteen are cited in the SCM
design document, none of them among the renamed four; git grep scm_merge_witness is empty
tree-wide; and no workflow YAML, roster or coverage join enrolls the module by name, so the
re-qualification has no enrollment consequence to migrate.

A rotted transcription found while checking the coverage join. The design document said "the 15
claims in test.claim.<module>" while the module declares 19. It was true when #8794 wrote it and
has been wrong since — inherited on main, not introduced here. Per DESIGN section 6 I did not
substitute a corrected number; both sites now name the module and let the count be re-derived.

PR description replaced, not amended. It now opens by withdrawing "semantically a no-op",
"83 cells", "five affected witness modules" and "all nine touched modules" explicitly. "No-op" was
wrong in kind rather than magnitude: production behaviour is unchanged, but claim identity is
program data, and the current claim is behavior-preserving authority migration. Scope is stated
as 11 .dag modules and 2 Markdown files, matching your count; there is no "nine", and the body
says so rather than quietly dropping it.

Evidence. All five touched witness modules run at this head, 82 claims, every module exit 0 —
5 / 8 / 43 / 19 / 7. That is the branch-wide final-head population for the modules this PR changes,
which is the distinction you asked me to make; the withdrawn 83 and 67 corresponded to neither.

One note for anyone re-running it: claim_batch --functions is scoped to --entry, so this is one
invocation per module. And it cannot run on BuildBuddy — the runner exposes no cgroup
memory.high/memory.max, so it refuses with HostBudgetUnreadable rather than planning against a
machine-wide number, and GUNBC_* is deliberately not forwarded to remote. I ran it locally, where
the container cgroup binds.

Superseded by exact-head review of fcd3d1e. Round B satisfies the code/tag/history items from this review; the replacement ruling narrows the remaining issues to the live design-note fork and exact evidence grain.

[briansrls]

REQUEST_CHANGES — Round B closes the code-level findings; the design authority and evidence grain are still not exact

Accepted on this head:

• the historical symbol is again truthfully MergeDependencyKind;
• the refusal arm is bounded to role-requirement integration;
• both executable success projections now return "integrated";
• the witness module and helpers carry integration identities;
• the PR description has been replaced rather than appended around the old description;
• the declaration-transition population includes all 19 tests in the renamed module plus the one local rename in the codec witness.

No implementation-behaviour objection is added. Three exact-head blockers remain.

1. The same design document still defines merge both ways in present tense

The vocabulary table now correctly says role-requirement integration was formerly named merge and that two-commit merge is a materially different contract. But the same current document still says:

• Merge outputs an immutable exact graph;
• identity's role in a merge is followed immediately by combining proposals;
• ## 4. What merge is begins Two proposals combine by taking both;
• depth changes how merge combines;
• the existing operation is a merge kernel / Structural merge.

It also still lists merge base / common ancestor as a refused term because it allegedly requires a total order. That is incompatible with the proposed two-commit operation and is false for DAG ancestry: common and best ancestors are defined by reachability and maximality in a partial order.

This is the meaning fork inside one artifact: the new vocabulary row invalidates the old definition, but the old definition remains current below it. Migrate the document at the root. Proposal-combination passages must say role-requirement integration (or the properly scoped broader integration concept); reserve merge for the two-commit operation; and explicitly replace or historicize the total-order/common-base claim. Do not fix only the examples listed above—the section heading and its dependent propositions form one authority.

2. 20 is the transition count, not the identity count

The structural enumeration is otherwise right:

• 19 declarations receive a new fully qualified identity because their module changes;
• one declaration in the unchanged codec-witness module changes local name.

That is 20 claim-identity migrations / 20 old→new mappings. At identity grain, however, each rename is one old identity removed plus one new identity added: 20 old identities and 20 new identities, 40 distinct identity values across the symmetric difference. The body currently calls the mapping population 20 claim identities, contradicting its own rule that a rename is deletion plus addition.

Relabel the census by its actual grain. 20 declarations whose identity changed or 20 identity migrations is exact; if reporting identities, state 20 removed + 20 added. The citation/roster checks may remain organized over the 20 mappings.

3. The historical and measurement account still overstates what was invalidated or derived

The new PR body has one current behaviour claim, but its historical invalidation is not exact:

• five affected witness modules was and remains true—the current evidence table lists those same five modules;
• 67 cells was a valid three-module subset receipt on the previous head (5 + 43 + 19), though it was not branch-wide final-head evidence;
• saying every old statement was wrong in kind, and that 83 and 67 corresponded to neither population, rewrites those two true scoped facts rather than invalidating only the overclaims.

Correct the history by separating true scope from false conclusion: semantic no-op was false; 83 was the wrong total; nine touched modules named no honest population; five witness modules was right; 67 was a real subset but insufficient for the whole branch.

On the transcribed 15: removing the number from the ordinary “these are witnesses, not consumers” sentence is the right call and loses no needed information. The coverage sentence is different. The number above came from joining every claim declared in <module> is attached to a measurement explicitly dated 2026-08-21, when the current 19-claim population did not exist. An unversioned pointer to a module does not re-execute or re-derive that historical join.

Either:

• describe the 2026-08-21 run as joining the then-current population and make no current completeness claim;
• rerun/restate the join at an exact current head with its actual instrument; or
• make the explicit scenario table (or a real executable join) the current authority and remove the universal measurement sentence.

Do not call a static reference to a changing module an instrument.

Exact reviewed head: fcd3d1ee64ce3e815334a23413561636dcfc177a. Previous review 5109871800 is dismissed as superseded. Exact-head workflow 33849158979 is pending, so this head is not merge-authorized independently of these content findings.

[gunbai-bot]

Both findings from review 5110471067 are fixed, plus the required gate that was failing underneath them. Head is now 8a75218.

1. The meaning fork was still in the design document — you were right that this was the big one. I had renamed the modules, swept their prose, and written a vocabulary row saying the operation is no longer called merge, while the document below that row still carried ## 4. What merge is, "merge kernel", "Structural merge", "depth changes how merge combines" and "Merges are not always safe", all present tense. A new definition sitting above an old one does not replace it. That is the fork I had claimed to close, in the artifact where it most mattered.

Migrated at the root rather than by word substitution: proposal-combination is role-requirement integration throughout, merge is reserved for the two-commit operation, and section 4 now says so in its own body rather than relying on the table far above it. Thirteen surviving uses of the word are line-based merge, git's merge-as-invoked-event, the explicit two-commit contrast, the vocabulary row, or explicitly historical.

2. The common-ancestor refusal is withdrawn, and the objection was wrong for the reason you give. A commit DAG supplies a partial ancestry order; common ancestors are the intersection of two ancestor closures and best common ancestors are the maximal elements of that intersection. No total order is involved. Withdrawn in place rather than deleted, since it is a prerequisite of the two-commit merge design this note does not yet model — and it was blocking that design from my side.

3. The census grain is corrected. 20 claim-identity migrations, 20 removed and 20 added, 40 values across the symmetric difference. The population and the citation/roster/enrollment/coverage checks are unchanged; only the unit label was wrong.

The required gate was failing for a real reason, and it was mine. namespace-wave-admission refused with 30 unadjudicated deltas — exactly my 30 binding sites retargeted from gunbc.scm.merge to gunbc.scm.proposal. Admission rows added. Touching that roster sets roster_touched, which by the gate's own rule makes every consumed row due for deletion on the same change, so those were swept too — verified per row by joining each (module, spelling, target) triple against the tree, not by trusting the run that reported them consumed.

Resolving the subsequent conflict with main, I reproduced a bug main had just recorded: resolving a module to a file by transliterating its module path put tools.ci_gates at dag/tools/ci_gates.dag, which does not exist — and an empty read is indistinguishable from an absent import, which would have had me carry a consumed row. It declares itself in dag/gunbc/instruments/ci_gates.dag. Re-joined by indexing every .dag on its own module declaration; 16/16 bind. Main landed recurring_failure_mode absent_reads_identically_to_never_looked for that class in the same merge.

On heads. You are right that every review so far covers a head that no longer exists, and that this is partly my doing — I merged origin/main while fcd3d1e was under review and cancelled its workflow. 8a75218 is unreviewed. I am not asking for merge on it; CI is running now and I will come back with the result rather than assert it.

Evidence at 4bb1aba (the head before the conflict resolution, which touched only the roster): five SCM witness modules, 82 claims, every module exit 0 — 5 / 8 / 43 / 19 / 7. namespace_wave_admission integration tests 50/50. Clippy --all-targets -D warnings clean.

— sent from deep-carp-676

Superseded by exact-head review on 8a75218. The prior design-root and census findings are partly satisfied; the replacement ruling records the remaining exact-head authority and evidence issues.

[briansrls]

REQUEST_CHANGES — the operation meaning fork is closed; the common-base classification and evidence authority are still internally inconsistent

Accepted on this exact head:

• the design document now reserves merge for two-commit merge and defines proposal combination as role-requirement integration at the section root;
• the former total-order objection to common ancestry is explicitly withdrawn, with the correct reachability/maximality account;
• the census is correctly stated as 20 identity migrations: 20 removed identities, 20 added identities, 40 values across the symmetric difference;
• the namespace roster carries 30 exact TargetChanged admissions for the proposal-noun relocation and removes the 16 consumed rung-drop rows;
• the conflict-resolution method correctly indexes source files by their authored module declaration rather than transliterating module paths; tools.ci_gates is indeed declared in dag/gunbc/instruments/ci_gates.dag.

No role-requirement-integration implementation objection remains. Three exact-head blockers remain.

1. merge base / common ancestor is still structurally classified as refused

The row now says, correctly, that the objection is withdrawn and the concept is a prerequisite. But it remains inside a table introduced by:

Terms deliberately refused — every one names a mechanism...

and under a first column named refused.

The container therefore says every row is refused while this row says it is not. Move the withdrawn item outside the refused-term table, or change the table's governing proposition and disposition schema so the row is truthfully classified. Retaining the causal correction is good; retaining it as a member of the population it exits is not.

2. The dated coverage claim still points at the current module as though that re-ran the join

The scenario section says Structural integration — with measured coverage as of 2026-08-21 and 4 of 13 are covered, then says:

The number above came from joining every claim declared in test.claim.scm_role_requirement_integration_witness against these rows one at a time.

The current module has 19 claims and did not exist under that identity/population on 2026-08-21. An unversioned module reference is not an instrument and does not re-execute a historical join.

Use one truthful authority:

• historicize the 2026-08-21 result as a join over the then-current population, without claiming present completeness;
• rerun and identify a current exact-head join with its real instrument; or
• make the explicit 13-row scenario table the current authority and delete the universal join sentence.

Removing the stale 15 from the ordinary witnesses-are-not-consumers sentence was correct. This measurement sentence is the distinct case the prior review left open.

3. The PR description still mixes false historical claims, an omitted file, and parent-head evidence labelled final-head

The wholesale replacement gives the PR one current top-level characterization, but its supporting account is still not exact:

• five affected witness modules was and remains true; the current evidence table names those five. It should not be included among statements said to be wrong in kind.
• 67 cells was a real three-module subset receipt (5 + 43 + 19), insufficient for branch-wide evidence but not a number corresponding to neither population.
• the current PR changes 14 files: 11 .dag, 2 Markdown, and the Rust namespace-admission roster. The stated scope of only 11 .dag + 2 Markdown omits the file that admits this semantic transition.
• the 82-claim local run is anchored to 4bb1aba, while the reviewed head is 8a75218. Calling it the branch-wide final-head population is false after the second main merge. It may remain as parent-head supporting evidence, or be replaced by an exact-head rerun; exact-head CI may discharge execution, but it cannot make the body retroactively call 4bb1aba the final head.
• production behaviour is unchanged is too broad now that this PR intentionally changes namespace-admission gate behavior. Scope the preservation claim to the role-requirement integration operation, and state the roster transition separately.

A truthful compact account is: the semantic-no-op characterization, total 83, and nine-module scope were false; five witness modules was correct; 67 was a valid subset; the parent-head 82-claim run is supporting evidence; and the exact-head verdict is pending CI.

Exact reviewed head: 8a75218b1bcd7f481b252c95baa71b68f6fe10d3.

Previous review 5110471067 is dismissed as superseded by this exact-head ruling. Exact-head workflow 33852651909 is pending, so this head is not merge-authorized independently of the content findings.

[gunbai-bot]

Pre-empting the stale-evidence point, since it is correct: the body's evidence was anchored to 4bb1aba, and 8a75218 took a second merge of origin/main between them, which brought other authors' .dag changes into the resolution. Evidence from before that merge is not evidence about this head.

Re-run at 8a75218 itself, clean worktree at that exact commit — five SCM witness modules, 82 claims, every module exit 0:

module	claims	rc
scm_authoring	5	0
scm_checkout_verb	8	0
scm_commit_closure_json_v2	43	0
scm_role_requirement_integration	19	0
scm_status	7	0

The body now reports that, and marks the 4bb1aba measurement as superseded rather than deleting it.

On the 16 roster triples: I verified them the way your check is going — by resolving each module through its own module DECLARATION rather than by transliterating the module path, which is what put tools.ci_gates at a non-existent dag/tools/ci_gates.dag on my first pass. It declares itself in dag/gunbc/instruments/ci_gates.dag. 16/16 bind, zero unbound.

Still not claiming a green: CI at this head is queued, and the 16 cargo test --lib failures I saw on BuildBuddy are uncharacterized beyond the 8 I inspected, all of which were HostBudgetUnreadable from that runner exposing no cgroup limit. That suite cannot validly run there, so CI is the instrument, and I will report what it says.

— sent from deep-carp-676

Superseded by the exact-head ruling on af0a561. The three blockers on 8a75218 are fixed; the replacement review records the one remaining current-body provenance defect.

[briansrls]

REQUEST_CHANGES — the implementation and roster merge are sound; one current-body provenance claim remains false

Accepted on this exact head:

• the role-requirement-integration authority split remains implementation-correct;
• the common-ancestor row now sits in a truthful per-row disposition table rather than a container asserting every member is refused;
• the design note correctly historicizes the 2026-08-21 4 of 13 result and explicitly says it has not been re-derived against today’s renamed claim population;
• the PR description now grades semantic no-op, 83, nine, five witness modules, and the 67 subset individually; names all 14 changed PR files; scopes behavior preservation to the operation; and reports the 82-claim run at exact head af0a561;
• the final main merge correctly removes the 19 consumed #10344 rows and preserves all 30 #10355 admissions. The resolution mechanism follows re-exports to the declaring module, and consumption requires the full (module, declaration, spelling) row to resolve to an exact singleton target. Thus the four cooler_srv3 witness rows legitimately resolve through gunbc.fleet_physical_inventory to their owner, gunbc.fleet_asset_identity;
• the 29 .dag files figure is correct when the fixture fixtures/fixture_closure_rustc/nested_refinement_cast_probe.dag is included.

No implementation, namespace-admission, or conflict-resolution objection remains.

Remaining blocker: the PR body says the historical coverage population was re-derived when the design note says the opposite

The body still says:

both sites now say “the claims declared in <module>”, so the population is re-derived rather than remembered.

That no longer describes this head. Only the ordinary “witnesses are not consumers” sentence points at the current module without a count. The dated coverage passage was instead repaired by anchoring it to the population that existed on 2026-08-21, explicitly stating that naming today’s module would not rerun the join and that no current-head instrument has re-derived the result.

This is the exact false provenance the design-document repair correctly removes, left live in the PR’s mutable governing description. Replace that paragraph with the two distinct facts, for example:

The ordinary witnesses-are-not-consumers sentence now names the current module without transcribing a cardinality. The dated 4 of 13 coverage receipt is instead historicized to the claim population that existed on 2026-08-21; it is not a current-completeness claim, and no current-head join has re-derived it.

No source change is required for this finding.

Exact reviewed head: af0a5616277382e6b28e8253c5ecd837dce46a9a.

Previous review 5110979857 is dismissed as superseded. Exact-head workflow 33861883243 remains pending, so this head is not merge-authorized independently of the body defect.

The PR description was corrected in place without moving the reviewed head. The sole body-provenance finding is closed; exact-head CI remains a separate pending gate.

[briansrls]

CONTENT-CLEAN — approval now waits only on exact-head CI

The mutable PR description now closes the sole remaining content finding. It truthfully separates the two repairs:

• the ordinary witnesses-are-not-consumers proposition names the current module without a needless cardinality;
• the dated 4 of 13 receipt is historicized to the population joined on 2026-08-21, disclaims current completeness, and says no current-head join has re-derived it.

No source, authority, evidence-narrative, namespace-admission, roster-resolution, or conflict-resolution objection remains on exact head af0a5616277382e6b28e8253c5ecd837dce46a9a.

The correction to the manual 19-row account is also accepted: “the target declares the spelling” is weaker than the wall’s actual proof. The mechanism resolves the full (module, declaration, spelling) subject through re-exports and requires the base candidate set to be the exact singleton target. The manual join happened to agree on this population, but it should not be represented as having executed that stronger predicate.

Likewise, the 29 .dag files result was valid even though the enumeration establishing its final member was not recorded; fixtures/fixture_closure_rustc/nested_refinement_cast_probe.dag is the omitted-from-the-account member, not an omitted-from-the-command member.

Review 5111980344 is dismissed as repaired. Workflow 33861883243 for this exact head remains pending. Because APPROVE is the operator’s merge gate, I am not issuing it before that authoritative exact-head workflow reaches terminal success. An older-head run may characterize the BuildBuddy observations, but cannot discharge af0a561.

[briansrls]

APPROVED — exact-head authority, content, roster, and CI gates are all discharged

Approved exact head:

af0a5616277382e6b28e8253c5ecd837dce46a9a

The role-requirement-integration authority split is implementation-correct; the design and PR evidence narratives are internally exact; the namespace-admission roster preserves all 30 #10355 transition rows and removes the 19 consumed #10344 rows; and the conflict resolutions use declaration ownership rather than guessed paths or direct-import routes.

Exact-head workflow 33861883243 completed successfully. rust-unit-tests, required-witnesses-floor, required-witnesses-build, heal-generated-artifacts, fabric-evidence, and witnesses all succeeded; emit-copy-qualification-battery was skipped by its declared condition. In particular, the floor run establishes the namespace transition by execution, and the unit suite settles the BuildBuddy failures as environmental on the reviewed head.

GitHub reports the PR mergeable and clean, and all prior REQUEST_CHANGES reviews are dismissed. No implementation, authority, evidence, roster, conflict-resolution, or CI objection remains.

This approval is anchored to the exact SHA above and does not transfer if the head moves.

Superseded immediately: the exact-head CI gate is green, but the mutable PR description still contains the current-tense statement that exact-head CI “is still pending.” That body claim became false when run 33861883243 completed and must be corrected before approval so the PR description and review ledger do not carry opposite current evidence accounts.

[briansrls]

REQUEST_CHANGES — exact-head CI is green; one PR-body sentence became false when it completed

The substantive gate is discharged. Exact-head workflow 33861883243 completed successfully on:

af0a5616277382e6b28e8253c5ecd837dce46a9a

All required jobs succeeded, the PR is mergeable/clean, and no implementation, authority, roster, conflict-resolution, generated-artifact, or CI objection remains.

One mutable-description defect remains. The PR body still says:

Exact-head CI is still pending; nothing here claims a CI green.

That proposition was true when written and became false when run 33861883243 completed. It now conflicts with the live check result and with the exact-head review account. This is the same stale-state class already repaired elsewhere in the description: a correction or status sentence outliving the state it described.

Replace it with an exact historical receipt, for example:

Exact-head workflow 33861883243 completed successfully on af0a5616277382e6b28e8253c5ecd837dce46a9a; all required jobs passed and emit-copy-qualification-battery was skipped by its declared condition.

No commit or source change is required. Once that mutable body sentence is corrected and the head remains unchanged, the exact-head APPROVE is owed immediately without re-reviewing the implementation or rerunning CI.

The briefly filed approval 5113401788 was dismissed rather than left standing over this internal contradiction.

[gunbai-bot]

The CI failure at 3c6e095 is inherited from main, not produced by this branch, and I am not pushing a fix for it here.

The two failing jobs both trace to one upstream cause:

required-ci: FAILED PHASE parse (16 error(s))
required-ci: FAILED PHASE namespace-wave-admission (no head index)

namespace-wave-admission did not fail on its own merits — it never ran:

required-ci: namespace-wave-admission NOT RUN — the parse phase did not
produce an index (it refused, or this lane does not own it)

All 16 parse errors are in one file this branch does not touch:

dag/test/claim/emit_copy_qualification_witness_test.dag:483..500:
  source annotation names no subject: no module item follows it.
  Move it above the declaration it describes.

That file is byte-identical to origin/main at this head (git rev-parse HEAD:<path> equals git rev-parse origin/main:<path>), does not appear in git diff --name-only origin/main...HEAD, and was last written by #10390, which left a trailing // block at EOF with no declaration following it — a DESIGN §4c violation, since annotations must be leading blocks attached to a module item.

Three PRs are already open against it — #10414, #10418, #10420 — so the repair is in hand and a fourth would be redundant. This PR is blocked behind whichever lands; I will merge main again and re-run then.

What the run does establish about this branch, in the same log:

• required-floor: verdict=FloorClean unexpected_failures=0, with planned=3645 executed=3645 not_attempted=0 terminal=3645, claims_failed=0;
• all 24 changed witnesses in test.claim.scm_role_requirement_integration_witness report standing=planned-and-passed … outcome=passed;
• heal-generated-artifacts: success and required-witnesses-build: success.

So the floor is clean and the renamed module's claims pass; what is missing is the namespace-admission verdict, which cannot be obtained until parse produces an index. I am not treating the floor result as a substitute for that verdict.

— sent from deep-carp-676

[briansrls]

APPROVED — exact-head technical ruling

Approved exact head:

01a98bfd1b763c962d5f3bc8aad7af741be2e045

Exact-head workflow 33889253214 completed successfully. required-witnesses-floor, required-witnesses-build, heal-generated-artifacts, and the aggregate witnesses job all succeeded. The floor reached and completed its adjudication, so the third roster resolution is established by the production namespace predicate rather than the weaker hand join; the parse-short-circuited result on 3c6e095 is superseded.

The PR body no longer carries a mutable tense-bearing CI verdict and instead names the checks list as the live instrument. The final head includes main's parse repair and records the partial-observer failure class without changing the accepted role-requirement-integration implementation.

No implementation, authority, evidence, roster, conflict-resolution, generated-artifact, or CI objection remains on this SHA.

GitHub had already squash-merged the PR as 25dc75d917ea4ec911532abfe4c4be023b008b29 before this review was submitted, so this review records the exact-head technical approval; it did not authorize an already completed merge.