c emission

[briansrls]

Phase 0 — C emission reaches bar (c): green by execution

Flips the C (cpp) target's add from bar (b) (emits the expected source string) to bar (c) (a real cc compiles the emitted output and it runs correctly) — the first non-Rust target proven green-by-execution through the actual emit pipeline.

What lands

• ProcessProgram coproduct in host_transport.dag: HostToolProgram { tool } | ProducedProgram { path }. A transport can now run a produced binary (./fixture), which cargo hid behind cargo run. This is the principled model (DESIGN §3) — a produced artifact is categorically not a PATH tool, so it doesn't belong in the tool registry.
• host_tool_cc → "cc" registered in emit_host.dag; invocation_argv resolves the program coproduct.
• C host transport in cpp.dag: cc fixture.c -o fixture → run ./fixture, 5-byte LE codec; runtime_row wired (was unconfigured).
• Existing rust/go/ts/python/rust_test descriptors + the wire test lifted to program: (argv-identical mechanical lift).
• Coverage-completeness test updated: cpp is now host-smoked (present count 4→5).

Verification

• cpp_add_emit_host_run_all_holds PASS wet — emitted add(2,3) compiled by real cc, ran, wrote [0,5,0,0,0] = 5; plus nonzero-exit and byte-width-mismatch refusal discriminators fire.
• Rust bar-c regression (emit_host_transport_wire_all_holds) still PASS wet — the lift didn't break the self-host path.
• Whole-tree compile-clean (gunbc compile --target dag over dag/src/v2/src/v1) exit 0, zero errors.

Not in this PR (disclosed, not narrowed)

CI-wet-gate enrollment for cpp (a run_cpp_smoke in emit_host_gate) is the clean follow-up — the execution witness has the same enrollment status as the existing Rust wire test (run wet on demand, excluded from the hermetic floor). This is the next step toward CI-defending cpp bar-c.

[gunbai-bot]

CI fix pushed — the 5 failures were an unrelated pre-existing landmine my diff exposed

The ci floor failed on 5 wave1_gate1 body-producer/symbol-index witnesses (src/v2/test/claim/long/…) hitting the 5s fast-lane eval budget — nothing to do with C emission.

Root cause (verified by execution, not guessed):

• These witnesses eval ~9.4s locally (wave1_gate1_a1_real_ingest_lowers), well over the 5s budget — correctly homed in long/.
• They were also enrolled per-PR via CommitWitnessClaim in gunbc.commit_workflow. An explicit enrollment row bypasses the long/ discovery exclusion (documented in commit_workflow_long_lane_note).
• They reach v2.std.host_transport transitively via extdeps.languages.dag (witness → helpers → .dag target model → host_transport). My ProcessProgram change edits host_transport, so the affected-set marked these witnesses affected → they ran → over budget → RED.
• On main they're predict-skipped on every normal PR (no diff touches their closure), so this landmine had never fired. main is green on all recent runs.

Fix (the documented remedy, not an improvisation): commit_workflow_long_lane_note already spells out the rule for exactly this case — "an explicit enrollment row bypasses discovery exclusion … Offlining an explicit row means deleting its declaration … Delete when the enrolled fns themselves are slow." Two prior enrollments (fold_lowering, accumulator_copy) were offlined the same way on 2026-07-12. So I deleted the two over-budget wave1_gate1 enrollments and recorded it in the note. The witness files stay under src/v2/test/claim/long/ and run via the local recipe / scheduled lane — no coverage is lost that ever worked (it only ever ran to fail). This is also consistent with the 2026-07-15 two-tier CI policy (slow/wet runs out-of-band, not per-PR).

No ci.yml drift: the enrollments feed the runtime floor roster (project_ci_floor_witness_entries), not the ci.yml text (0 wave1_gate1 references in ci.yml). Whole-tree compile-clean is green.

Cross-lane note: these keystones belong to the body-lowering / general-body-producer lane (#6620). If they want per-PR coverage back, the principled path is enrolling fast (<5s) check_fns or the scheduled long-lane trigger — not re-adding the >5s rows.

— sent from eager-ferret-110

[gunbai-bot]

Correction after merging main: adopted main's fix, reverted my deletion

Integrating main revealed that the wave1_gate1 budget issue was already fixed on main, more completely than my deletion — so I reverted my commit_workflow.dag change and took main's version wholesale. commit_workflow.dag is now identical to main; my branch's only diff is the C-emission changes.

Main's fix (the right one): reclassify the wave1_gate1 a1/b1 enrollments from CorpusWitnessKind → ExecutionWitnessKind (and add a c1 enrollment). That routes them from the hermetic discovery-corpus batch (where the operator 5s fast-lane budget is armed) to the Wet execution-corpus batch — and the budget is armed only for hermetic batches (claim_executor.rs: effective_budget = if execution_mode.is_hermetic() { fast_lane_budget } else { None }; execution_corpus_runnable_for is execution_mode: Wet). So the witnesses keep their per-PR coverage but run without the 5s wall, completing in ~9s each. This keeps the coverage my deletion would have dropped, and matches the 2026-07-15 two-tier CI policy (slow runs in the Wet lane, not the hermetic fast lane).

With my host_transport change, these witnesses are still pulled into the affected set — but now they land in the Wet execution batch (no budget) and pass, rather than the hermetic discovery batch that killed them at 5s. Whole-tree compile-clean is green on the merged tree.

— sent from eager-ferret-110