docs(r3): §3.1 emission interrogation — scope correction + GAP findings at HEAD

[briansrls]

Summary

• Scope correction: §3.1 promise text claimed "R3 scope: Rust + Python + Go + C + C++" — but per THESIS.md:180 L5 + WISHLIST.md:67-73 R4.A (operator ratification 2026-05-12), C/C++ is R4.A scope, not R3. R3 is 3 Shape-A targets (Rust/Python/Go). LLVM/assembly/machine code is R4.C scope. Fixed header + cite chain.
• Findings at HEAD (2026-05-13) subsection added with concrete emission-state enumeration: target substrate inventory, L6 data-coverage status, per-target L4 runtime byte-identity status (Rust unconditional ✓ in CI; Python/Go #[ignore]'d), L5 corpus gate Design: LLM-powered code review pipeline with Codex CLI #15 state (DECLARED, RED).
• Open R3 question surfaced (PM-tier, not yet routed): interpretation divergence between (a) L6 data-coverage = ✓ for all 3 targets, vs (b) L4 runtime byte-identity = ✓ Rust-runtime in CI; Python/Go toolchain-gated. THESIS.md:180 ("same .dag produces same behavior in Rust/Python/Go") reads as runtime-shape; CI evidence is Rust-runtime + 3-target data-coverage.

Triggered by operator question 2026-05-13: "how do we know general purpose language emission works for all of our target languages?" Director-busy + PM-owned interrogation-sheet doc → PM-tier fix-forward authoring.

Authority chain:

• THESIS.md:115 (omni-emission claim) + :180 (L5: same .dag → same behavior in Rust/Python/Go) + :215 (Shape A target enumeration)
• WISHLIST.md:67-73 (R4.A C/C++ ingest+emission added 2026-05-12)
• WISHLIST.md:107-121 (R4.C low-level emission targets)
• r3-program-plan.md:185 gate Design: LLM-powered code review pipeline with Codex CLI #15 l5_cross_target_consistency + :243 (DECLARED) + :431 (RED, waits on L4 + Shape A grounding)
• src/v3/std/cross_target_coverage.dag (L6 substrate, 41-row Phase-1)
• src/v3/compiler/tests/boundary/m1_{3_emit_rust,3_emit_go,4_emit_python,5_emit_omni_demo}_test.rs (per-target test state)

Test plan

• cargo fmt --all --check passes (pre-push hook)
• docs-only diff; no Rust source touched
• All cited paths exist at HEAD (verified via grep)
• Cited line numbers checked at authoring time (m1_3_emit_rust_test.rs:735/764/995/1199/1218; m1_3_emit_go_test.rs:252/279/324; m1_4_emit_python_test.rs:1003/1070; m1_5_emit_omni_demo_test.rs:124)
• r3-program-plan.md:185/243/431 verified at HEAD
• Scope-correction supersedes prior PR docs(r3): R3 close interrogation sheet — meta-acceptance checklist per operator directive (Director ratification pending) #2822 (interrogation sheet v1) §3.1 phrasing — §3.1 was the only section with the 5-target misread

🤖 Generated with Claude Code

[briansrls]

Both findings ACCEPTED + fixed in commit 9613b9e4b:

Finding 1 (BLOCKING-shape, omni-demo wording): confirmed via m1_5_emit_omni_demo_test.rs:6-19 ("Run the full three-way proof locally") + :117 ("all three targets produce identical stdout"). The "(5-target combined)" parenthetical was an editorial slip carried over from the prior wrong "R3 scope: 5 targets" framing — the same misread the PR was supposed to correct. Now distinguishes:

• emit_omni_demo_rust_roundtrip at :106 — Rust-only slice over omni fixture set, unconditional in CI (previously omitted from the inventory — substantively strengthens (b) interpretation evidence-bar)
• emit_omni_demo_fixtures_green at :125 — full 3-target receipt (Rust + Python + Go) at #[ignore], toolchain-gated

Finding 2 (exploratory, "byte-identity" terminology): confirmed via m1_3_emit_rust_test.rs:1000-1009 — the rustc_roundtrip_* family asserts stdout == expected, i.e., compiled-binary stdout vs fixture-expected stdout. That's runtime stdout-parity (oracle-style), not literal artifact byte-equality. Wording corrected throughout §3.1 — heading is now "L4 runtime equivalence at HEAD (oracle-style stdout-parity: ...; not literal artifact byte-equality)"; per-target bullets switched to "stdout-parity tests"; interpretation (b) reframed as "L4 runtime stdout-parity interpretation". Aligns with feedback_byte_identity_internal_not_external (byte-identity claims need internal/external discrimination).

Verdict consistent with cursor's APPROVE_WITH_COMMENTS — keeping the structural surfaces (scope correction, GAP findings, open R3 question on close-shape) but tightening the wording to match grounded check-pipelines per INVARIANTS P1.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 9613b9e4 · Trigger: schedule
• Thinking: 149s wall

---

BLOCKING (1)

Root Cause

• .github/workflows/ci.yml CI integration execution is hot-fixed to a zero-test filter while §3.1 reads test attributes as CI evidence → either re-enable a real Rust roundtrip CI filter or downgrade §3.1 to compile-only CI plus local runtime evidence.

⚠️ The scope correction looks right, but the CI evidence claim needs to match the actual workflow before this close-interrogation doc can be trusted.

[briansrls]

BLOCKING: This says Rust stdout-parity tests run unconditionally in CI, but .github/workflows/ci.yml currently runs the integration harness with __HOT_FIX_NONEXISTENT_FILTER__ and zero selected tests, so the new HEAD finding overstates live L4 evidence (INVARIANTS P1: Documentation Describes Live State).

[briansrls]

Operator BLOCKING finding ACCEPTED + fixed in commit 1f56e6544. Should have grepped ci.yml first per my own feedback_audit_consumer_scripts_before_ci_skip discipline — that memory was about CI-step modifications but the same audit-first rule applies to FINDING claims about CI state. Logging that generalization.

Verification of the BLOCKING: .github/workflows/ci.yml:458-501 confirms:

• Line 478: step name "v3 tests (full suite integration harness, HOT-FIX zero-test-filter)"
• Line 490-493: cargo test -p v3-compiler --test integration __HOT_FIX_NONEXISTENT_FILTER__ ... — integration binary runs with zero tests selected per nonexistent-filter pattern
• Line 501: Restore criteria — rebuild OnceLock/cached_compile amortization → per-test wall ≤ 2s ratchet → replace nonexistent-filter with cluster-specific filter
• Line 385: Lane2d also HOT-FIX-SKIPPED separately
• Per operator directive gunbc#846 2026-05-12: "cut all demos and integration tests for now, get v3 to 10 minutes"

So the per-fixture Rust rustc_roundtrip_* tests EXIST + are unconditional in source (no #[ignore]), BUT they live in the integration binary that CI runs with the zero-test-filter. The honest framing at HEAD is "runnable locally, not actually executed in CI" — exactly what INVARIANTS P1 flags.

Fixes applied:

1. New top-level bullet under §3.1 "CI integration-binary execution state" cites ci.yml:478-501 verbatim + restore-criteria + lane2d (ci.yml:385) HOT-FIX-skip. States: in-CI L4 evidence at HEAD = integration-binary-prebuild-passes + non-integration test surfaces (lib + bins + determinism_test + doc) only.
2. Rust bullet reworded: "EXIST + unconditional in source BUT live in HOT-FIX-filtered integration binary; execution at HEAD is local-only".
3. Omni-demo Rust slice reworded similarly.
4. Open R3 Question interpretation (b) reframed: distinguishes "runnable locally" vs "actually-executed-in-CI"; adds (b3) gate-class promotion option to add integration-harness-execution-state restore as a new §1.8 R3-close-anchored gate (which would make the integration-binary-execution restore a structural close-criterion rather than a fast-follow).

This finding is also load-bearing for the whole §3.1 close-shape analysis: if integration-harness CI execution is the restore-bar, then the omni-emission claim's R3-close evidence at HEAD is genuinely just L6 data-coverage + integration-binary-prebuild-passes. Without the restore, even the "L4 runtime in CI for Rust" base case is gone.

Watching for the queued +1 more inline comment; will address on arrival.

— sent from deep-wolf-155

[briansrls]

codex BLOCKING ACCEPTED — same finding as operator's inline BLOCKING (briansrls 04:22:32Z); both already fixed forward in commit `1f56e6544` (pushed 04:24 after operator's inline arrived first).

codex's review was against SHA `9613b9e4` which preceded the fix. The codex finding ("CI integration execution is hot-fixed to a zero-test filter while §3.1 reads test attributes as CI evidence → either re-enable a real Rust roundtrip CI filter or downgrade §3.1 to compile-only CI plus local runtime evidence") is structurally identical to operator's framing; chose the downgrade path: §3.1 now distinguishes "exists + unconditional in source" vs "actually-executed-in-CI", with new top-level bullet "CI integration-binary execution state" citing `ci.yml:478-501` + restore-criteria verbatim. Open R3 Question interpretation (b) reframed: "runnable locally" vs "actually-executed-in-CI"; new sub-option (b3) for gate-class promotion adding integration-harness-execution-state restore as a §1.8 R3-close-anchored gate.

Verbatim from current HEAD §3.1 (commit 1f56e6544):

CI integration-binary execution state (`.github/workflows/ci.yml:478-501`): integration harness is prebuilt in CI but execution is HOT-FIX-SKIPPED via `HOT_FIX_NONEXISTENT_FILTER` (zero tests selected) per operator directive at gunbc#846 (...). Lane2d (Stage 2d integration module, `m1_5_testgen`-class) also HOT-FIX-SKIPPED at `ci.yml:385`. Restore criteria at `ci.yml:501`: OnceLock/cached_compile amortization → per-test wall ≤ 2s ratchet → re-enable per cluster filter. Until restore, in-CI L4 evidence at HEAD is: integration-binary compilation passes (structural exercise of emit code paths) + non-integration test surfaces (lib + bins + determinism_test + doc) only.

Verdict: re-running on new HEAD should land APPROVE.

— sent from deep-wolf-155