Dissolve roadmap_spawn_request git rev-parse shell into git.Core.HeadCommit op (fixes medium_structure fleet-red, §3/§5)

[briansrls]

What

Dissolve the raw shell in dsl/gunbc/tools/roadmap_spawn_request.dag — shell.Exec.Run(script: "git rev-parse HEAD 2>/dev/null | tr -d '\n'") — into a modeled git extdeps operation git.Core.HeadCommit (argv ["git", "rev-parse", "HEAD"] → CommitSha), mirroring the existing git.Core.CurrentBranch (which is git rev-parse --abbrev-ref HEAD). roadmap_next_spawnable now calls git.Core.HeadCommit() and reads .sha / .success.

Why

#5797 (roadmap-spawner Lane G) introduced an unrostered ShellInRun leak (the 2>/dev/null marker), failing medium_structure_clean_tree_holds fleet-wide (red on a clean origin/main worktree; medium-leak count = 1 on main).

Per DESIGN §3, a git rev-parse HEAD argv is a nickname for git's semantics, and git is already modeled as an extdeps service (cf. git diff, CurrentBranch). Per DESIGN §5, the fix is construction (dissolve), not validation (roster) — rostering a leak the lens correctly caught would mask the lens (the inert-lens / masked-green failure mode) and grow the frozen medium exception roster. So: dissolve the argv into the git model. Nothing added to the roster; no raw shell left in the .dag.

Proof by execution

• medium_structure_clean_tree_holds → PASS on this branch; FAIL when roadmap_spawn_request.dag is reverted to origin/main (discriminating control — my change is exactly what flips it).
• git_mock_consumer_is_total_holds → PASS (the new op does not break git mock-totality; it is not added to the published corpus, so the corpus→materialize totality is unchanged).
• roadmap_spawn_request.dag resolves clean (41 modules, 598 items; CommitSha→String for anchor_commit coerces, git.Core.HeadCommit resolves).

Coordination / scope notes

• Cross-red: this PR's ci will still show red on doc_graph_has_no_orphan_docs (a separate pre-existing main-red owned by sharp-carp's Fix orphan doc: cite roadmap-spawner.md from roadmap_authority §8 + regen ROADMAP.md #5804) until that lands. The two fixes together clear the fleet-red; merge order resolves it. This PR fixes only the medium-structure half, proven above.
• Follow-up (not blocking): git.Core is a corpus-governed service, so HeadCommit is fail-closed on hermetic realization until a published mock case exists. roadmap_next_spawnable has no hermetic consumer today (only a wet/production consumer), so no floor witness realizes it. Publish a HeadCommit mock case (corpus + materialize arm + MaterializedGitMock variant) when a hermetic test of roadmap_next_spawnable lands.

🤖 Generated with Claude Code

[gunbai-bot]

Rebased onto current main and de-rostered: this PR now supersedes #5821's medium_structure_exception_roster entry for dsl/gunbc/tools/roadmap_spawn_request.dag. #5821 took the fast roster path (masks the lens, grows the frozen roster); this PR dissolves the git rev-parse HEAD 2>/dev/null ShellInRun leak into a git.Core.HeadCommit extdeps op, making the roster entry inert cruft, so it's deleted here.

Verified by execution (claim_batch, both source-roots): medium_structure_clean_tree_holds PASS with the roster entry removed (pass is via the dissolve, not the roster); git mock-totality witnesses PASS with HeadCommit added (no corpus red). Scope: git.dag + roadmap_spawn_request.dag + medium_structure_containment.dag only.

— sent from neat-fox-547

[gunbai-bot]

Investigated the failing ci check. Root cause: infra OOM, not content. The failing step is gunbc ci (.dag witnesses + gates), which ran ~16min and ended with ##[error]Process completed with exit code 137 — SIGKILL (128+9), the OOM-killer taking out the floor process on memory. rust_tests passed; job setup passed (no action-cache corruption); the floor ran and was killed on RAM.

This is not a content failure and is not introduced by this PR. #5822's content is verified clean by my own execution: medium_structure_clean_tree_holds PASS, git mock-totality PASS, oracle shows only the 3 intended files (git.dag + roadmap_spawn_request.dag + medium_structure_containment.dag), and #5827+#5829 are absorbed (no revert). There is no content fix to push.

The systemic cause is the floor's peak memory exceeding the runner — the same runner-OOM issue affecting main and the sibling PRs. (Note: #5827's swap-off appears to have changed the failure mode — clean exit-137 OOM-kill instead of 'runner lost communication' thrash — without reducing the floor's memory demand.) I've re-triggered the ci job (OOM can be load-dependent; a fresh/less-loaded runner may pass). The durable fix is floor-memory / runner-capacity, which is infra, not this 3-file PR.

— sent from neat-fox-547

[gunbai-bot]

Re-investigated at the new head a25c714 (a clean auto-merge of main absorbing #5805 — oracle confirms still ONLY my 3 intended files: git.dag + roadmap_spawn_request.dag + medium_structure_containment.dag, no contamination, #5827/#5829 still absorbed, revert-safe).

Same failure, now confirmed deterministic: floor OOM, not content. The gunbc ci step ended again with ##[error]Process completed with exit code 137 (SIGKILL / OOM-killer) after 25min; rust_tests + job setup passed. This is the third exit-137 on this PR (original head 942739b, a manual retrigger, and now a25c714) — so the OOM is not load-dependent and a retrigger does not help (the prior retrigger also OOM'd at 7m51s). The floor's peak memory genuinely exceeds the runner, even after #5827/#5829.

There is no content fix I can push — #5822 is a 3-file medium-leak dissolution, verified clean by execution, and the failure is in the shared CI floor's memory footprint, which is infra. The durable fix is floor-memory / runner-capacity (the resource-aware-scheduler / CI-floor demand-envelope thread), not this PR. I am not retriggering further (confirmed to only burn runner cycles). The same exit-137 floor OOM blocks all the sibling lane PRs (#5818/#5819/#5820/#5828) and main itself — it is the lane-wide and main blocker.

— sent from neat-fox-547

[gunbai-bot]

Merge-readiness determination (responding to the claude-opus-4-7 APPROVE relay). No code fix to push — the content is clean and approved; the two blockers are both outside this PR's content:

1. Approvals: 1/2 distinct providers. Two APPROVE artifacts, both claude (claude-opus-4-7). Needs a 2nd distinct provider (openai-pro/codex) to meet the 2-approval rule. This is review scheduling, not a content matter.

2. ci job red = the systemic floor-OOM, NOT content. The failing step is claim_executor … --plan-function gunbc_ci_floor_batches, killed with exit code 137 (SIGKILL/OOM) in run 28211445146. rust_tests passes (39s) and the build compiles — this PR's diff (the git rev-parse → git.Core.HeadCommit dissolution) is content-clean. The OOM is the claim_executor spawn-width-vs-cgroup root cause being fixed in Fix CI floor OOM: route srv1_floor_memory_budget to real 8 GiB cgroup cap, raise per_shard to 3.5 GiB #5831 / Fix srv1_floor_memory_budget: use real runner cgroup cap (8 GiB) instead of whole-run-peak × margin #5836 (the floor-budget reground to the real 8 GiB cap). This PR is blocked on that landing, then a re-run; the red here is not a defect in Dissolve roadmap_spawn_request git rev-parse shell into git.Core.HeadCommit op (fixes medium_structure fleet-red, §3/§5) #5822.

Net: content-clean and approved, blocked on (a) a 2nd distinct review provider and (b) the floor-OOM root fix. Nothing to fix on this branch. Not self-merging (operator merges manually). — sent from neat-fox-547