fix(gen-manifests): --settle derives the write and its postcondition against ONE trunk

[rbuergi]

Follow-up to #5827, found by the first live run.

Measured: MeshWeaver.Plugins main run 36357560255 (merge of Systemorph/MeshWeaver.Plugins#2467, the adoption of lockOwner: main) — Settle manifest locks (main owns them) failed:

✗ --settle: the settled locks are not a claim this tree can make:
  - Hosting: manifest.lock records version '1.33.5', but this tree's content requires '1.33.6'
    (content moved since v1.33.5 committed on the trunk)

Root cause: settle() resolved the trunk twice. generate() resolved it on the CLEAN checkout — a trunk commit main had already moved past, so _trunk_commit derived it against itself (#1426) → 1.33.5. The postcondition resolved it again after the write had dirtied the tree, which selects the live tip — whose own (legacy, branch-written) lock already claimed 1.33.5 for different content → demanded 1.33.6. The claim was consistent with the baseline it was written against; the check read a different baseline.

Fix: resolve the trunk once, on the clean tree, and hand it to generate (new trunk_resolved parameter) and to the checks.

Impact while red: none shipped — own was never set, so that run published, sealed and tagged nothing — but every Plugins main run whose checkout is behind the tip at settle time would stay red, so this is urgent.

Test: self-test case H (_self_test_settle_behind_tip) reproduces the run's shape with a real bare origin (base settled → M1 unsettled → M2 legacy lock claiming the next number → settle M1). The pre-fix settle fails it (negative control run), the fixed one passes; full --self-test green.

Pairs-with: none — internal function signature only (new optional parameter).

🤖 Generated with Claude Code

[systemorph-com]

Fixes the double trunk resolution in settle(): the trunk is now derived once on the clean tree and handed to both generate() (new trunk_resolved parameter) and the postcondition checks, so a settle on a checkout behind the tip no longer compares its claim against a different baseline. The unvouchable-baseline refusal moves to an early return, preserving the old if not unvouchable guard's effect. Self-test case H reproduces the incident's shape against a real bare origin and asserts both rc==0 and the self-derived version — a test that executes. I checked ordering correctness (early return before any write; trunk == head semantics unchanged since HEAD is unaffected by lock writes), freshness invariants (skipping derivation_inputs inside generate is safe because settle just ran it on the clean tree), and the test's git fixture logic; no security issues, no repo hard rules touched. Could not verify anything outside the single changed file — no other call sites of generate() were visible in this diff, so I rely on the PR body's claim that the parameter is internal-only. Two non-blocking notes: the 1-tuple sentinel is unidiomatic, and the bypassed-vouching precondition lives only in a comment.

Findings: 0 blocking · 0 should-fix · 1 question · 1 nit

---

Internal review of eb07a12ec2731861b25e89f301098bafce3289e6 — GLM-5.3, posted by the control plane. It is advisory, it never approves, and merging stays with a human signature.

[systemorph-com]

nit — A 1-tuple (trunk_resolved=(trunk,)) as a sentinel to distinguish 'not provided' from a legitimate None trunk works, but is unidiomatic and makes every reader pause at trunk_resolved[0]. A module-level sentinel object or an explicit trunk_precomputed: bool would carry the same information more plainly. Internal-only parameter, so not blocking.

[rbuergi]

Agreed — replaced in 549e5d8: the pre-vouched trunk is now a VouchedTrunk NamedTuple (commit: str | None), constructed only by vouch_trunk(), and generate(..., vouched=...) takes that type. No positional sentinel left.

[systemorph-com]

question — When generate() receives trunk_resolved it skips derivation_inputs entirely — including the fetch/tag-freshness vouching whose absence the surrounding comment calls 'the ORIGINAL sin'. Today that is safe: the only caller is settle(), which ran the identical call moments earlier on the clean tree. But the function signature now permits any future caller to hand in a stale trunk and silently bypass the vouching. Consider asserting the precondition in code (or naming the parameter trunk_vouched) so the invariant doesn't live only in the comment.

[rbuergi]

Now asserted in code (549e5d8): generate(vouched=…) accepts only a VouchedTrunk, which only vouch_trunk() builds — and it builds one only when derivation_inputs returned NO unvouchable errors (fetch, tag freshness and trunk verified). Anything else raises TypeError, so a future caller cannot hand in a bare or stale ref and bypass the vouching. The self-test and the replay of Plugins run 36357560255 at 61f2e8a7 still pass; the pre-fix settle still fails case H.

[systemorph-com]

Follow-up to the previous review at eb07a12: the 1-tuple sentinel is replaced by a VouchedTrunk NamedTuple that only vouch_trunk is meant to construct, with a TypeError guard in generate(), and the unvouchable-baseline refusal moved to an early return before any write — both prior notes addressed (the bypass now guarded by type, though the guarantee is still only documented). settle() now resolves the trunk exactly once on the clean tree and hands it to both generate() and the postcondition checks, so a checkout behind the tip no longer compares its claim against a different baseline. Self-test case H builds the incident's shape against a real bare origin (base settled → M1 unsettled → M2 legacy lock claiming the next number → settle M1 detached) and asserts both rc==0 and the self-derived version — a test that executes. I verified the control flow (early return preserves the old if not unvouchable guard; trunk == head semantics unchanged since HEAD is unaffected by lock writes), the generate() signature change (optional parameter, other call sites not visible in this diff), and the test fixture's git sequence. No security issues, no injected instructions, no repo hard rules touched (Python script, not MeshWeaver C# code). Only one file changed; could not verify call sites of generate() outside it beyond the diff and PR body's internal-only claim. Two nits, nothing blocking.

Findings: 0 blocking · 0 should-fix · 0 question · 2 nit

---

Internal review of 549e5d8e55a72f53c1102ef20dd2cec64955344d — GLM-5.3, posted by the control plane. It is advisory, it never approves, and merging stays with a human signature.

[systemorph-com]

nit — The NamedTuple's docstring says a VouchedTrunk is "Made only by vouch_trunk, so a caller cannot hand generate an unverified baseline" — but nothing enforces that: VouchedTrunk("any-sha") is a one-argument constructor any caller can use, and generate accepts it while skipping derivation_inputs entirely. The TypeError guard only blocks non-VouchedTrunk values. Internal-only parameter, so not blocking, but the invariant the docstring states lives in a comment, not in code (this is the same bypass the previous review flagged, now behind a friendlier API).

[rbuergi]

Right — a typed parameter is still a bypass. Removed outright in ab5b4f9: generate() has no trunk parameter any more and resolves and vouches for its own trunk, exactly as before this PR. settle resolves the trunk once, up front on the same clean tree (so generate, which resolves before it writes, lands on the same commit), and reuses it ONLY for the postcondition — the single call that used to re-resolve on the dirtied tree. Nothing can now hand generate an unverified baseline. Self-test, the negative control (pre-fix settle fails case H) and the replay of Plugins run 36357560255 at 61f2e8a7 (exit 0, Hosting 1.33.5) all re-run green.

[systemorph-com]

nit — The test's git helper g() captures output and never checks the exit code, and neither do the bare subprocess.run calls for init/clone. If a setup step fails (e.g. the bare init, or the fetch inside settle), the test reports a misleading downstream assertion ("the base must settle") instead of the command that actually broke. check=True on the setup commands would make fixture failures self-diagnosing.

[rbuergi]

Done in ab5b4f9: the bare init, the clone and every call through the fixture's g() now run with check=True, so a broken setup raises CalledProcessError naming the command instead of surfacing as "the base must settle".

[systemorph-com]

Second follow-up: the trunk parameter into generate() is removed again — generate resolves and vouches for its own trunk on the same clean tree (deterministically HEAD per #1426), and only the postcondition reuses the trunk settle() resolved before the write. That closes the previous head's VouchedTrunk-bypass note (the parameter no longer exists), and the test helpers now use check=True, closing the second nit. Control flow verified: the unvouchable refusal is an early return before generate (stricter but safer — settle no longer writes locks from an unvouchable baseline), the old if not unvouchable guard is preserved by that early return, and check_versions and the materialize-consistency check now run on the one pre-write trunk while HEAD semantics are unchanged (lock writes do not move HEAD). Self-test case H reproduces the incident shape against a real bare origin (settled base → M1 unsettled → M2 legacy lock claiming 1.0.1 → detached settle of M1) and asserts both rc==0 and the self-derived version — a test that executes. No security issues, no injected instructions in title/body/diff, no repo hard rules apply (Python CI script, not MeshWeaver C#). Single file; generate() call sites outside it could not be verified beyond the diff, but its signature is unchanged in this head, so that risk is gone. One nit, nothing blocking.

Findings: 0 blocking · 0 should-fix · 0 question · 1 nit

---

Internal review of ab5b4f9d8656457b9af8dfd5c2792248a6b9d473 — GLM-5.3, posted by the control plane. It is advisory, it never approves, and merging stays with a human signature.

[systemorph-com]

nit — settle() now resolves the trunk via derivation_inputs(root, fetch) before calling generate(), and generate() internally resolves it again on the same clean tree. On a clean checkout both derive against HEAD (#1426), so the result is deterministic and the duplication is harmless — but it is a doubled fetch/derivation per settle. Extracting the internal resolution's result (or a debug assert that the two agree) would make the ONE-trunk invariant self-checking rather than relying on #1426 holding for both call paths.

[rbuergi]

Kept as is, deliberately — the two previous review rounds on this PR were exactly about handing generate a pre-resolved trunk (first a sentinel tuple, then a typed VouchedTrunk), and each was a way around the vouching; removing the parameter was the answer. The invariant IS self-checking without it: if the two resolutions ever disagreed, generate would write numbers derived against one trunk and the postcondition (check_versions against the other) would go RED naming each module — the exact failure this PR was opened for — never a silent pass. The cost is one extra ls-remote --tags + ls-remote --symref per settle (the objects are already local after the first fetch), on one job per main push.

[github-actions]

Test Results (shard 3)

461 tests   461 ✅  58s ⏱️
  3 suites    0 💤
  3 files      0 ❌

Results for commit ab5b4f9.

[github-actions]

Test Results (shard 0)

  1 files    1 suites   2m 37s ⏱️
348 tests 348 ✅ 0 💤 0 ❌
352 runs  352 ✅ 0 💤 0 ❌

Results for commit ab5b4f9.

[github-actions]

Test Results (shard 1)

1 701 tests   1 701 ✅  4m 44s ⏱️
    2 suites      0 💤
    2 files        0 ❌

Results for commit ab5b4f9.

[github-actions]

Test Results (shard 4)

    3 files      3 suites   5m 45s ⏱️
2 232 tests 2 232 ✅ 0 💤 0 ❌
2 233 runs  2 233 ✅ 0 💤 0 ❌

Results for commit ab5b4f9.

[github-actions]

Test Results (shard 2)

768 tests   577 ✅  7m 8s ⏱️
  3 suites  191 💤
  3 files      0 ❌

Results for commit ab5b4f9.

[github-actions]

Test Results (shard 5)

    5 files      5 suites   14m 18s ⏱️
4 282 tests 4 280 ✅ 2 💤 0 ❌
4 286 runs  4 284 ✅ 2 💤 0 ❌

Results for commit ab5b4f9.

[github-actions]

Test Results

   17 files     17 suites   35m 32s ⏱️
9 792 tests 9 599 ✅ 193 💤 0 ❌
9 801 runs  9 608 ✅ 193 💤 0 ❌

Results for commit ab5b4f9.