SCM: the merge verb — join the base derivation to the path algebra

[gunbai-bot]

gunbc.scm.merge_base decides which base a squash is entitled to use and refuses when there is none. gunbc.scm.manifest_merge decides each path against a base and refuses when the sides disagree irreconcilably. Both refuse independently and both were controlled — but nothing joined them, so there was no operation anyone could invoke to merge anything. This is that join. It introduces no decision of its own: every refusal is one of the two modules' refusals carried outward, or a store fact observed at the boundary.

The order is forced, not chosen

The base is derived before the manifests are read, for the reason merge_base runs its consumed-source join before it looks for a common ancestor: deriving a merged manifest against a base the repository is not entitled to use constructs the unsafe value and then discards it. A resurrection that is computed and thrown away still existed.

The squash workflow is now structural rather than conventional

The result records one lineage edge — parent is the target — and the source is recorded as consumed via SquashIntegrated rather than as a second parent. Nothing is lost: that receipt is precisely what merge_base reads to refuse the second merge. So "never merge the same branch twice" is enforced by construction instead of discipline, and there is no dev history to rebase because none is created.

Refusals are not flattened

A consumed source, a conflicting path, a missing manifest and an invalid allocator have four different remedies and four different principals to blame.

One place deliberately does collapse, and it is flagged rather than hidden. carry_mint folds the mint's three root refusals into one SquashMergeMintRootUnresolvable, because the root handed to the mint was minted by this function from the store one line earlier — so all three mean "the store did not keep what it just accepted", one fact about one store rather than three populations a caller acts on differently. This is the judgement in the module I am least sure of, since the rest of this lane argues the other way, and it is written down so a reviewer can overturn it rather than have to find it.

The fixture moved instead of being copied

The repository builder was authored inside the merge_base witness and is needed verbatim here. Two copies of one construction rule drift invisibly — each keeps passing its own claims while the two fixtures quietly stop describing the same repository — so it moved to test.fixture.scm_repository_builder.

All twelve merge_base claims pass unchanged against the shared fixture. That is the right control for a rehome: a builder that had silently changed would still compile on both sides, and would surface only as a claim that stopped discriminating.

The move is a membership motion, so its nine bindings are declared in the namespace-wave-admission roster with their rationale and a dissolution trigger, rather than done quietly.

Evidence

446/0 across all SCM witness files. The two halves' own behaviours are not re-asserted here; what is unproven until this file exists is that the join preserves them.

mutation	both paths	parent/receipt	double merge	conflict
parent on the source	pass	RED	pass	pass
drop the consumed receipt	pass	RED	RED	pass
ignore merge_base's answer	RED	pass	pass	RED
as built	pass	pass	pass	pass

The second is load-bearing: dropping the receipt reds the double-merge claim, so the resurrection refusal genuinely flows through the verb rather than being asserted beside it.

The scene is a divergence, not a fast-forward, deliberately. If the target had not moved since the base, taking the source's manifest wholesale would be correct and every claim here would pass against an implementation that ignores the base entirely.

Note

Built on scm-algebra (#10668). The two newest manifest_merge claims — the symmetry law and the over-conservatism controls — are not in this branch's count; they arrive when #10668 lands.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9

[gunbai-bot]

Reworked at 11c57e571a4. Two reviews acted on, both verified against the code first.

review 61590 — the repeated builder. Correct, fixed.

All three claims bound Scene { build: _, … }, discarded the build, then re-ran the entire builder one line later via scene_repository(s: scene()) to recover the repository that discarded field already held. §2 exactly as cited, and §6 forbids pricing an exception for small n.

The consequence the finding doesn't name is worse than the cost: each claim was building two repositories and asserting about the second. The scene the surrounding match described and the scene under test were different objects that merely happened to be equal — a fixture that has quietly stopped being the one its own match names. Fixed by binding the build and replacing the helper with one that takes it, so re-deriving is no longer expressible.

A blocker found after every approval on this PR was cast

The reviews at 316b7d9f80e and 16b6c84c5bf all read the mint seam as sound. It was not, and I want the record to show that rather than the tally.

mint_commit_from_stored_manifest(repository, root: CorpusManifestObjectRef) took two independent parameters. The brand is sole_constructor, so it cannot be forged — but it means "some store minted this locator at this kind", never which store. So this was authorable: store a manifest into store A, take the reference, hand it to a repository whose store is B. Allocator valid, parent absent, integration absent — and the mint writes a commit whose root is absent from B.

That falsified my own annotation, which claimed the store had just branded the root. The signature established a repository and a brand from somewhere. It is the same defect fixed one level up on #10668 — an annotation asserting a guarantee the signature does not carry — reintroduced here while fixing something else. "Only squash calls it correctly" is no defence: .dag has no module privacy.

And a second one: mint_repository_commit_admitted was an importable forge factory — raw repository, raw brand, decided ancestry, no admission at all, straight to appending a commit. It predates this branch, but the rung-4 claim made here leaned on it as the terminal constructor, and no such claim stands while that bypass is authorable.

The repair seals the relation, not its two endpoints. RepositoryManifestRoot is sole_constructor and pairs a repository with a root its own store contains, with two producers that each establish the pairing: resolve-a-target, or store-the-entries-here so the caller never holds the halves. The forge factory is deleted, its body inlined behind the admissions.

A branded reference proves kind. This carrier proves membership in this repository's store.

The wall is checked, not asserted. §4b's question was asked first — is the forbidden state authorable anywhere a check could run? It is, so the probe was written and executed: sole_constructor type 'RepositoryManifestRoot' cannot be constructed outside its defining module. Honest limit: that RED cannot stay enrolled as a claim, because a file that fails to compile cannot live in this corpus. The evidence is a one-off executed refusal, not a standing control; the standing guard is the sole_constructor declaration itself.

Not taken, flagged rather than dropped: sealing store_corpus_manifest's success into a StoredCorpusManifest so its two facts are never separable anywhere. Real and broader, but it changes an arm destructured at ~20 sites across the witness corpus and is separable from this blocker, which is closed without it.

448/0. The approvals on this PR predate the seal — please re-read rather than counting them.

— sent from deep-carp-676