PM May 24

[briansrls]

Auto-opened by session-dashboard for session loyal-stag-23.
Pushing to docs/v4-compilation-milestones advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

• Title describes the change (not the session id or branch).
• PR body summarises what and why (replace the TODO below).
• Tests run: name the command (e.g. npm test, cargo test) and the result.
• If this closes a work item, the body contains a Closes #N directive.
• No commits on this branch are surprises (no fork/cherry-pick I did not make).
• No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

• TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 727517a4 · Trigger: schedule
• Thinking: 253s wall

---

BLOCKING (3)

Root Cause

• docs/v4-compilation-milestones.md The milestone model collapsed the canonical compiler spine after parse → include T-8 normalize/resolve and T-9 infer in M2 required work/dependencies before treating T-10 as the emit gate.
• docs/v4-compilation-milestones.md Pure Bootstrap Zero's ".dag-authored" mandate was conflated with "must run through the eval interpreter" → keep T-6/T-7 authored in .dag, but route M2 through the emitted stage0 compiler pipeline unless a higher authority changes TASKS.
• docs/v4-compilation-milestones.md The milestone snapshot was authored from an older Wave-1 parser state → refresh T-7 status from the current 02_parse.dag and name the remaining parser gaps precisely.

⚠️ The new planning authority needs its M2/T-7 dependency model reconciled with the current v4 compiler spine before merge.

[briansrls]

Relay finding at line 119 (T-7 description stale) is addressed in 9b0cc93 — the description was updated to accurately reflect the post-#3626 state: parse() now dispatches through grammar_lookup_production → parse_production → parse_expr; parse_expr is the remaining stub with its 🟡 gated — feature:T-7-parse-walk-realization marker. All three blockers from the codex review on 727517a are resolved in 9b0cc93.

— sent from loyal-stag-23

[briansrls]

Addressed both cursor/composer-2.5 findings in 43c466c:

Finding 1 (M0 evidence overstates CI green): The CI gate has two arms — full compile receipt and resolve-posture bridge receipt. M0 is only confirmed by the full-compile arm. Updated Evidence block to distinguish the two arms and explain what each proves. The Status line now notes that CI green must be verified as the full-compile arm before treating it as M0 confirmation.

Finding 2 (T-28 description wrong): The 🟡 gate is at namespace_from_tree_and_graph (line 564-570 of 03_resolve.dag), which receives the ModuleGraph but does not walk ModuleGraph.entries. resolve_with_graph itself passes the graph through — it does not drop it. Both occurrences (M3 blockers section and Gap 3) corrected to name the actual gated function.

— sent from loyal-stag-23

[briansrls]

Added dag.dag LM wiring as an explicit M2 blocker in d72f3b7 (per nimble-koi-111 independent verification + scope ruling).

Finding: dag_wave1_grammar() → ModeledGrammar exists in dag.dag but neither pipeline-facing LM function uses it — both call dag_wave1_g0_void_grammar() (VoidGrammar). parse() dispatches VoidGrammar to the accept-empty arm, rejecting any real program input at parse. Adding a pipeline-facing dag_language_model_wave1() using ModeledGrammar is not T-7 scope (generic walk algorithm) — it is dag.dag data wiring, a separate follow-on task.

Blocker 3 now names this explicitly. Blocker 4 (was 3) and 5 (was 4) renumbered.

— sent from loyal-stag-23

[briansrls]

Reviewing the claims in docs/v4-compilation-milestones.md, I think this needs revision before merging. The high-level framing is useful, but a few claims are inaccurate or internally inconsistent against the current repo state.

Findings:

1. docs/v4-compilation-milestones.md:94 / :205 claim no CI step runs --target rust over all of src/v4. That is false. The T-22 host eval CI receipt runs scripts/check-v4-host-eval-receipt.py, which sets SOURCE_ROOT = src/v4 and invokes v2-compiler compile --source-root src/v4 --target rust, then checks the clean compile receipt. The real missing piece appears to be full emitted-crate link/build/run, not full-tree Rust emission.

2. docs/v4-compilation-milestones.md:128 says M2 has only serial blockers T-6 -> T-7 -> T-10, but :218 and :246 say M2 depends on T-22/T-34. Those claims conflict. src/v4/TASKS.md lists the compiler critical path as T-6 -> T-7 -> T-8 -> T-9 -> T-10; T-22 is the sibling eval/TestClaim path, not listed as a prerequisite for the compile pipeline. Pure Bootstrap supports authoring compiler behavior in .dag, but I do not see authority for “T-6/T-7 cannot execute until T-22/T-34” in the generated-Rust stage0 path.

3. docs/v4-compilation-milestones.md:57 says “CURRENT, CI green.” Current PR checks were still pending when checked. The gate exists, and recent main runs include successes, but a planning doc should avoid claiming “CI green” without pinning a specific run/date or wording it as “expected/current gate.”

4. docs/v4-compilation-milestones.md:191 overstates eval as “nothing can execute.” Some wave-1 runtime hooks accept literals/binds; the rejecting hooks are the nontrivial transform/branch/loop/call path in src/v4/extdeps/runtimes/v4_evaluator.dag.

Most other claims checked out: bootstrap.dag models the seed/stage0/stage1/stage2 chain, CI bootstrap viability uses --target dag, tokenize/parse modeled walks are still stubbed, and resolve_with_graph currently ignores the module graph. The main fix is to revise the M1/M2 dependency story so it matches existing CI and TASKS.md.

[briansrls]

All four findings are valid. Fixed in 7b77fe9:

Finding 1 (M1 --target rust already in CI): check-v4-host-eval-receipt.py already runs --source-root src/v4 --target rust with zero v2 diagnostics. The doc incorrectly said 'no CI step runs --target rust over full src/v4.' Corrected: the Rust emission step exists; what's missing is cargo check/cargo build of the emitted crate. Updated M1 definition, blockers (blocker 2 is now the ~4,900 rustc errors from PR #3654), Gap 1, and the current-CI-state paragraph.

Finding 2 (parallel track table): Added an explicit note before the table: 'The eval track column is NOT a prerequisite for the compiler track row. M2 does not require T-22 or T-34.' Reformatted table header to make the independence unambiguous.

Finding 3 (heading 'CI green'): Changed 'CURRENT, CI green' → 'CURRENT STATE' in the M0 heading. CI status belongs in the body, not the title.

Finding 4 (eval 'nothing can execute' too strong): Named the deferred hooks precisely: call_primitive, choose_branch, step_loop, call, represent_literal, all arms of transfer. Named the accepting hooks: bind_value, allocate, return_value, terminal_value (Continue/Return arms). Changed 'nothing can execute' to 'no nontrivial expression can evaluate end-to-end while transfer rejects all control-transfer arms.'

— sent from loyal-stag-23

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 7b77fe9d · Trigger: schedule
• Thinking: 271s wall

---

BLOCKING (2)

Root Cause

• docs/v4-compilation-milestones.md M2 models trivial emit as only the local compiler spine → add the T-4/T-33 side branch and algebra-grounding gates wherever T-9/T-10 require target facts.
• docs/v4-compilation-milestones.md M4 collapses T-15 to hash equality after M3 → preserve TASKS' full T-15 gate, including T-16 and T-36 before fixed-point validation is meaningful.

⚠️ Two planning-authority contradictions remain and should be reconciled before merge.

[briansrls]

Addressed in 8e4ae24. Line 146 now says: 'T-9 infer: modeled and in the chain; requires T-4 algebra grounding (formal TASKS.md prerequisite) — T-9 fail-closes on bare-Atom bridge symbols until T-4 fills real Node constructors for each algebra type.' T-4 and T-33 added as explicit M2 Known blockers (5 and 6) with TASKS.md line citations. Sequential dependency section updated to name the T-33 → T-4 → T-9 chain.

[briansrls]

Addressed in 8e4ae24. M4 Note now explicitly names T-16 and T-36 as prerequisites per TASKS.md lines 31-33 ('Both must be complete before T-15'), shows the critical path T-10 -> T-11 -> T-16 and T-36 both feeding T-15, and explains that asserting fixpoint before those gates is a correctness claim about an incomplete binary.

[briansrls]

Addressed both codex BLOCKING findings from review on 7b77fe9 in 8e4ae24:

Finding 1 — M2 missing T-4/T-33 side branch:
TASKS.md line 42: "T-9 [needs T-8, T-2, T-3, and T-4]"; line 43: "T-10 [needs T-9, T-4]." Added as M2 Known blockers 5 and 6:

• Blocker 5 (T-4): T-9 infer rejects bare-Atom algebra references via infer_algebra_ref_ungrounded. rust.dag uses bridge Symbols as placeholders (e.g., rust_model_core_bridge_std_ordered_ring_representable_integer) that fail-closed at T-9 until T-4 Wave 2b fills real Node constructors (ordered_ring_node(inhabitant: Node) -> Node, etc.). Applies even for trivial fn add(a, b) = a + b targeting Rust.
• Blocker 6 (T-33): T-4 cannot ground primitives or algebra references without std/model_core.dag (T-33). Side branch {P1-KEYSTONE, T-30, T-29, T-25-core, T-33} → T-4 → T-9 is a watch item per TASKS.md.
  Required Work and Sequential dependency sections updated to reflect formal TASKS.md prerequisites.

Finding 2 — M4 collapsed T-15 to hash equality, treating T-16/T-36 as optional:
TASKS.md lines 31–33: "T-11 → T-16 (full-stack omni-emission demo) and T-36 (ingest round-trip fidelity claim). Both must be complete before T-15." Fixed M4 Note to name T-16 and T-36 as prerequisites with explicit citation, show the critical path T-10 → T-11 → T-16 and T-36 both feeding T-15, and explain that asserting fixpoint before those gates is a correctness claim about an incomplete binary.

— sent from loyal-stag-23

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: 8e4ae248 · Trigger: manual
• Comparison: main @ 3a9be658 ... docs/v4-compilation-milestones @ 8e4ae248
• Conversation: View conversation

---

1. Story of the diff

This PR adds a new planning document, docs/v4-compilation-milestones.md, whose job is to define observable v4 compilation milestones rather than edit compiler behavior directly. The doc separates structural .dag compilation, Rust emission, and full bootstrap into distinct evidence levels (docs/v4-compilation-milestones.md:38-56), then walks M0 through M4: M0 is current structural compile, M1 is emitted Rust linking to a runnable stage0, M2 is stage0 compiling a trivial program, M3 is stage0 producing stage1 from src/v4, and M4 is the bit-identical fixed point (docs/v4-compilation-milestones.md:60-238). The load-bearing intent is good: it tries to prevent CI’s current “compile” language from being mistaken for a runnable v4 binary, and it names the compiler-pipeline track separately from the TestClaim/eval track (docs/v4-compilation-milestones.md:203-238). The risk is that because this is a planning authority, imprecise milestone labels become dispatch instructions.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

N/A — this is a docs-only PR; it does not introduce or modify substrate types, Dag storage, cross-pass carriers, .dag variants, or reusable algebraic helpers.

1. INVARIANTS.md + modeling-discipline.md.

Compliant — fail-closed / no fabricated success: M0 explicitly distinguishes the full compile receipt from the resolve-posture bridge and says the bridge does not guarantee zero diagnostics or full parse coverage (docs/v4-compilation-milestones.md:64-82). That is the right shape for avoiding a fabricated “M0 achieved” claim.

1. CODING.md.

N/A — no Rust code or implementation helpers are changed; CODING.md’s data/free-function, method, error-shape, and comment-discipline rules do not apply to this new Markdown planning document.

1. TESTING.md.

N/A — no executable behavior changed. The document defines future CI evidence, but this PR does not add a runner, gate, or test subject that needs a same-PR test.

1. LOCKED DESIGN DECISIONS.

Finding — docs/v4-compilation-milestones.md:165-166 conflicts with the locked fixed-point meaning of self-hosting. The new M3 section says that once stage0 compiles src/v4 into stage1, “Self-hosting is structurally achieved (even if not yet bit-identical).” The thesis explicitly separates “the compiler can compile itself” from the Pure Bootstrap deliverable: compiler self-emission is fixed-point, bit-identical output, and is “strictly stronger than ‘the compiler can compile itself’” (THESIS.md:247-252; also docs/design-pure-bootstrap-zero.md:155-160 names DB-8 bit-identical convergence as the no-compromise gate). chatgpt-review-fe7dc5e2-c8bb-42…

chatgpt-review-2e344f81-be59-4d…

M3 can be called “self-compilation” or “stage1 exists,” but calling self-hosting structurally achieved before M4 dilutes the locked acceptance target and would let downstream planning mark the central Pure Bootstrap goal as achieved too early.

1. TRACKED vs UNTRACKED DEBT.

Compliant — the doc names existing stubs/gates as blockers rather than introducing new scaffolds: T-7’s feature:T-7-parse-walk-realization marker, T-28’s namespace_from_tree_and_graph gate, T-34 deferred evaluator hooks, and T-4/T-33 prerequisites are all presented as blocking work with explicit milestone placement (docs/v4-compilation-milestones.md:133-154, docs/v4-compilation-milestones.md:168-177, docs/v4-compilation-milestones.md:227-238). I do not see a new TODO, bridge, or temporary implementation shape introduced by this PR.

2.5. Top-down PM intent review

Finding — docs/v4-compilation-milestones.md:165-166 weakens the PM-level Pure Bootstrap target. Highest authority says the v4 fixed-point acceptance is a v4 binary compiling compiler.dag into bit-identical stage0 Rust and bit-identical artifacts (THESIS.md:321-327), and the Pure Bootstrap Zero design makes DB-8 bit-identical convergence a no-compromise acceptance gate (docs/design-pure-bootstrap-zero.md:155-160). chatgpt-review-fe7dc5e2-c8bb-42…

chatgpt-review-2e344f81-be59-4d…

The diff’s M3 wording would cause a faithful worker or manager to treat “stage0 produced stage1” as self-hosting achieved, even though the plan’s must-have target remains M4 fixed point. Rename that proof to self-compilation/stage1 existence and reserve self-hosting achieved for M4/T-15.

Finding — docs/v4-compilation-milestones.md:102-114 misclassifies an M2 semantic blocker as an M1 link blocker. The same document defines M1 only as emitted Rust compiling/linking into a runnable v4-stage0 binary, and explicitly says M1 does not prove the binary can compile a v4 program correctly (docs/v4-compilation-milestones.md:86-100). But the “Known blockers” for M1 lists the T-10 emit stub because it produces no useful output for real input (docs/v4-compilation-milestones.md:102-114). By the doc’s own definition, a semantic emit stub belongs in M2, not M1; keeping it under M1 would misdispatch work toward v4 emit semantics before the M1 rustc/cargo-link evidence is even isolated.

3. Verdict

REQUEST_CHANGES

The milestone framing is useful, but the M3 self-hosting wording contradicts the locked fixed-point acceptance semantics, and the M1 blocker list mixes linkability with runtime compiler usefulness. Both are planning-authority issues that can steer downstream work incorrectly if merged as written.

[briansrls]

Addressed both openai-pro REQUEST_CHANGES findings in f4082f0:

Finding 1 — M1 blocker list mixes linkability with runtime compiler usefulness:
T-10 emit being a stub is a semantic concern (M2), not a link concern (M1). By the doc's own definition, M1 proves only that the emitted Rust compiles and links — it explicitly states M1 does NOT prove the binary can compile a v4 program correctly. Removed T-10 from M1 Known blockers. Updated the dependency note to state explicitly: "Semantic correctness is M2."

Finding 2 — M3 "Self-hosting is structurally achieved" contradicts the locked Pure Bootstrap target:
THESIS.md §247-252 and design-pure-bootstrap-zero.md §155-160 define self-hosting as bit-identical fixed-point convergence (DB-8), which is strictly stronger than "compiler can compile itself." M3 is stage0 self-compilation — stage1 exists. It is a necessary step toward M4, not the Pure Bootstrap deliverable. M3 What-this-proves now reads: "The v4 compiler can compile itself — stage0 self-compilation, stage1 exists. This is NOT self-hosting. Self-hosting (the Pure Bootstrap Zero requirement) is the bit-identical fixed point at M4/T-15."

— sent from loyal-stag-23

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: f4082f00 · Trigger: schedule
• Thinking: 390s wall

---

BLOCKING (1)

Root Cause

• docs/v4-compilation-milestones.md M2 treats T-10 as serializer-only and misses the 00_compile.dag source-entry boundary → add an M2 blocker/required-work bullet to wire or dissolve compile_ingest_staging so the stage0 CLI composes T-6/T-7/T-8/T-9/T-10 from Source input.

⚠️ One planning-authority gap remains in the M2 unblock list.

[briansrls]

Addressed in 1839602 (operator-committed).

Finding (Gap 2 — T-6/T-7 Rust path framed as P5-scaffold dispatch): Valid. The prior wording created a dispatchable hand-Rust path — "would be a P5 scaffold... requires dissolution receipt before dispatch." THESIS.md:294-296 is unambiguous: "Stage0 Rust compiler internals (tokenize, parse, lower, infer, emit, lenses, std library) are emitted from the .dag graph and committed — not hand authored. Hand-maintained surface target: 0."

Gap 2 now states: writing T-6/T-7 in Rust is a STOP — not a normal P5-scaffold dispatch path. Workers must not be dispatched on a hand-Rust path for T-6/T-7 without explicit PM/Director re-ratification of the Pure Bootstrap Zero mandate. THESIS.md:294-296 is quoted directly on-page. No dissolution receipt makes hand-Rust authoring of these internals a valid normal path.

— sent from loyal-stag-23

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: 18396020 · Trigger: manual
• Comparison: main @ 3a9be658 ... docs/v4-compilation-milestones @ 18396020
• Conversation: View conversation

---

1. Story of the diff

This PR adds docs/v4-compilation-milestones.md, a new planning authority that separates “v4 compiles” into observable milestones: structural .dag compile, emitted Rust linking into stage0, stage0 compiling a trivial program, stage0 compiling src/v4 into stage1, and finally the stage1/stage2 fixed point. The useful mechanism is that it distinguishes the current CI structural receipt from a runnable binary, then names concrete blockers for M1/M2 such as v2 emitter fidelity, compile_ingest_staging, T-6/T-7 walks, dag.dag language-model wiring, T-8/T-28 resolution, T-9/T-4 grounding, and T-10 emit (docs/v4-compilation-milestones.md:44-153). It also protects the Pure Bootstrap Zero direction by explicitly saying T-6/T-7 walks must be authored in .dag, not hand-Rust, and by keeping the compiler pipeline track separate from the TestClaim/eval track until they converge later (docs/v4-compilation-milestones.md:210-277).

2. Invariant categories

1. LAYER MODEL — Compliant. This is a planning-doc-only diff; it does not add substrate types, Dag fields, computation variants, or Rust mutation surfaces. The layer-sensitive decision it does make is correct: T-6/T-7 compiler behavior stays in .dag, with hand-Rust authoring called a STOP rather than a scaffold path (docs/v4-compilation-milestones.md:260-269).
2. INVARIANTS.md + modeling-discipline.md — Compliant. The doc names existing stubs as fail-closed blockers instead of treating structural receipts as execution: M0 explicitly says full structural compile does not prove tokenizer/parser/evaluator/emitter execution (docs/v4-compilation-milestones.md:73-85), and M2 lists ParseExprRejected, compile_pipeline_not_realized_diagnostic, and bare-Atom algebra rejection as blockers rather than fabricating success (docs/v4-compilation-milestones.md:131-148).
3. CODING.md — N/A. The diff adds a Markdown planning authority, not Rust implementation code, helper functions, comments in code, or API shapes.
4. TESTING.md — Finding. docs/v4-compilation-milestones.md:162 gives M3 evidence as only v4-stage0-compiler compile src/v4 ... && rustc ... -o v4-stage1, but the M3 definition says “stage1 is functionally complete: it can compile v4 programs, not just trivial ones” at docs/v4-compilation-milestones.md:160. That evidence proves stage0 emitted a linkable stage1 binary; it does not prove the stage1 binary can compile anything. This violates the behavior-driven evidence discipline: the milestone names a behavior, but the acceptance command checks only artifact existence/linking. Fix by either narrowing M3’s definition to “stage1 binary links/exists” or adding a stage1 invocation to the evidence, for example a v4-stage1 compile trivial.dag ... smoke before M3 can be marked reached.
5. LOCKED DESIGN DECISIONS — Compliant. The PR references Pure Bootstrap Zero and preserves the locked direction: no hand-Rust for v4 compiler internals, T-6/T-7 in .dag, and self-hosting reserved for the bit-identical fixed point rather than conflated with stage0 self-compilation (docs/v4-compilation-milestones.md:164-167, docs/v4-compilation-milestones.md:260-269).
6. TRACKED vs UNTRACKED DEBT — Compliant. The diff documents existing stubs and bridges with concrete owning lanes or file anchors: resolve-posture bridge is explicitly weaker than M0 full compile (docs/v4-compilation-milestones.md:70-77), T-7 is tied to feature:T-7-parse-walk-realization (docs/v4-compilation-milestones.md:132), and compile_ingest_staging is named as a required M2 orchestration blocker (docs/v4-compilation-milestones.md:134, docs/v4-compilation-milestones.md:141). I do not see a new scaffold introduced by this PR.

2.5. Top-down PM intent review

Finding. Pure Bootstrap Zero’s acceptance shape is a working compile cycle, not merely an emitted artifact: docs/design-pure-bootstrap-zero.md:159-160 requires fixed-point convergence and “regen → rustc → run → diff fixed-point,” and THESIS.md:321-322 frames fixed-point acceptance as the v4 binary compiling compiler.dag into bit-identical outputs. The new M3 milestone says stage1 is “functionally complete” (docs/v4-compilation-milestones.md:160) but its evidence only builds v4-stage1 and never runs that binary (docs/v4-compilation-milestones.md:162). A worker following the doc faithfully could declare M3 complete with a stage1 binary that links but cannot compile even the trivial M2 fixture, which semantically dilutes the milestone.

3. Verdict

REQUEST_CHANGES

The document is directionally strong and mostly aligns with Pure Bootstrap Zero, but the M3 acceptance evidence is under-specified relative to its own definition and the PM-level fixed-point intent. Tightening that milestone now avoids giving workers a false “stage1 exists/functionally complete” receipt.

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: 0009bb7a · Trigger: manual
• Comparison: main @ 3a9be658 ... docs/v4-compilation-milestones @ 0009bb7a
• Conversation: View conversation

---

1. Story of the diff

This PR adds a new planning authority, docs/v4-compilation-milestones.md, to define what “v4 compiles” means at progressively stronger evidence levels. The doc separates structural .dag compilation, Rust emission, and a full runnable bootstrap artifact so CI green does not get mistaken for an executable compiler (docs/v4-compilation-milestones.md:38-56). It then maps the bootstrap chain into M0–M4: M0 is current structural compile, M1 is emitted Rust linking, M2 is a stage0 binary compiling a trivial .dag program, M3 is stage0 producing stage1, and M4 is the fixed-point / T-15 hash equality gate (docs/v4-compilation-milestones.md:60-202). The load-bearing planning work is the blocker inventory for M2—compile_ingest_staging, T-6/T-7, dag.dag language-model wiring, T-8/T-9/T-10, and T-4/T-33 dependencies—and the explicit separation between compiler-pipeline progress and the TestClaim/eval track (docs/v4-compilation-milestones.md:130-153, docs/v4-compilation-milestones.md:206-241).

2. Invariant categories

1. LAYER MODEL

N/A — this is a docs-only planning PR. It does not add or mutate Dag substrate types, cross-pass carriers, dag.rs state, or new substrate variants.

2. INVARIANTS.md + modeling-discipline.md

Finding — docs/v4-compilation-milestones.md:294-296, P2 Boundary Discipline / Practice 5 single-authority metadata. The recommendation says the M1 action is “Zero code changes to src/v4 required — just a CI wiring change.” But v4’s build/CI pipeline is explicitly modeled as .dag data in workflow/bootstrap.dag and workflow/ci.dag (THESIS.md:266-270), and Pure Bootstrap Zero names those workflow models as the load-bearing authorities for bootstrap and CI (docs/design-pure-bootstrap-zero.md:7). As written, the planning instruction would let a worker add or modify the CI step directly in the checked workflow surface without updating src/v4/workflow/ci.dag, creating a parallel CI authority. The fix is to say the M1 gate must be added through the modeled CI authority, with any checked workflow/YAML change treated as the projection/receipt, not the source.

3. CODING.md

N/A — no Rust implementation code is added or refactored. The doc’s prose is the artifact under review, and the issue above is about architectural authority rather than Rust style.

4. TESTING.md

Compliant — the milestone evidence is behavior-driven rather than implementation-layout-driven: M0 distinguishes full compile receipt from the resolve-posture bridge (docs/v4-compilation-milestones.md:64-82), M1 requires a linkable/runnable emitted artifact (docs/v4-compilation-milestones.md:88-100), and M2 requires an end-to-end stage0 invocation on a minimal .dag input (docs/v4-compilation-milestones.md:121-128). No new tests were required for this docs-only PR.

5. LOCKED DESIGN DECISIONS

Finding — docs/v4-compilation-milestones.md:294-296, Pure Bootstrap Zero / CI-as-data authority. The locked Pure Bootstrap Zero context says v4’s workflow authorities are src/v4/workflow/bootstrap.dag and src/v4/workflow/ci.dag, and that the committed ci.yml is a checked projection from .dag (docs/design-pure-bootstrap-zero.md:7). The “Zero code changes to src/v4 required — just a CI wiring change” wording dilutes that locked decision for the very first recommended action. This should be rephrased to preserve the modeled CI source of truth: for example, “no compiler-spine changes required; add the M1 gate in src/v4/workflow/ci.dag and update/regenerate the checked CI projection as its receipt.”

6. TRACKED vs UNTRACKED DEBT

Compliant — the doc does not introduce a new scaffold or TODO shape. Existing stubs and blockers are named with concrete owning lanes/tasks and failure modes, especially for T-6/T-7, compile_ingest_staging, T-4/T-33, and T-34 (docs/v4-compilation-milestones.md:130-153, docs/v4-compilation-milestones.md:230-241). The only debt-related blocker is the CI-authority wording above, which would become untracked parallel authority if followed literally.

2.5. Top-down PM intent review

Finding — PM intent mismatch between CI-as-data and the recommended M1 action. The highest-level authority says gunbc applies its own lenses to its own build/CI pipeline, which is modeled as .dag data in workflow/bootstrap.dag and workflow/ci.dag (THESIS.md:266-270), and the Pure Bootstrap Zero design names those as the load-bearing workflow authorities with ci.yml only a checked projection (docs/design-pure-bootstrap-zero.md:7). The new plan’s top recommendation says to add the M1 CI step with “Zero code changes to src/v4 required — just a CI wiring change” (docs/v4-compilation-milestones.md:294-296). A worker following that faithfully could bypass src/v4/workflow/ci.dag, which would dilute the recursive-flex / CI-as-data commitment. This is a planning-artifact issue, not a repo-wide backlog item: the new doc should route the M1 step through the modeled CI authority.

3. Verdict

REQUEST_CHANGES

The milestone framing is otherwise useful and mostly careful, especially around structural vs executable compile evidence. I would not merge it until the M1 recommendation is corrected so CI changes remain authored through src/v4/workflow/ci.dag rather than encouraging a direct workflow-only authority.

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: a57e04c8 · Trigger: manual
• Comparison: main @ 3a9be658 ... docs/v4-compilation-milestones @ a57e04c8
• Conversation: View conversation

---

1. Story of the diff

This PR adds docs/v4-compilation-milestones.md, a planning authority that separates “v4 structurally compiles” from “v4 emits Rust” from “v4 produces a runnable compiler” (docs/v4-compilation-milestones.md:38-56). It maps the modeled bootstrap chain seed→stage0→stage1→stage2 into M0–M4 milestones, then names the current blockers for moving from structural CI coverage to a real stage0 binary and eventually a fixed-point stage1/stage2 compiler (docs/v4-compilation-milestones.md:60-202). The strongest parts of the doc are the fail-closed M0 distinction between a full compile receipt and the resolve-posture bridge (docs/v4-compilation-milestones.md:64-82) and the explicit Pure Bootstrap guard that T-6/T-7 lexer/parser work must be authored in .dag, not hand-Rust (docs/v4-compilation-milestones.md:256-265).

2. Invariant categories

1. LAYER MODEL — N/A — the diff is a documentation/planning artifact only; it does not add substrate types, mutate Dag, introduce new variants, or change implementation code.
2. INVARIANTS.md + modeling-discipline.md — Compliant — fail-closed / facts-flow-forward discipline is handled by distinguishing the M0 full compile receipt from the weaker resolve-posture bridge instead of treating any green CI arm as equivalent (docs/v4-compilation-milestones.md:64-82). The doc also preserves single-authority workflow modeling by sending the M1 CI gate through src/v4/workflow/ci.dag, not an unmodeled CI-only script path (docs/v4-compilation-milestones.md:294-298).
3. CODING.md — N/A — no Rust implementation code or in-code explanatory comments are added; this is a planning document whose prose is the artifact.
4. TESTING.md — Finding — docs/v4-compilation-milestones.md:162 defines the M3 evidence as v4-stage1 compile trivial.dag --target rust, but it does not compile the stage1-emitted Rust with rustc or run the emitted trivial artifact. That leaves the exact M1 failure mode open: an executable compiler binary can run while producing wrong or empty output, which the doc itself calls out at docs/v4-compilation-milestones.md:99-100. For behavior-driven milestone evidence, M3 should either repeat the M2-style compile→rustc→run check against stage1 output, or explicitly narrow M3 to “stage1 binary executes a smoke command” and move the “functionally complete” claim elsewhere.
5. LOCKED DESIGN DECISIONS — Compliant — the doc references the Pure Bootstrap Zero mandate and preserves it: lexer/parser algorithm walks are explicitly .dag work, and hand-Rust T-6/T-7 authoring is marked STOP without PM/Director re-ratification (docs/v4-compilation-milestones.md:256-265). The CI recommendation likewise routes through the modeled CI authority (docs/v4-compilation-milestones.md:294-298).
6. TRACKED vs UNTRACKED DEBT — Compliant — the doc names existing stubs/bridges as blockers rather than normalizing them: parse_expr, compile_ingest_staging, T-28 namespace walking, and v4_evaluator deferred hooks are each bounded to the milestone they block (docs/v4-compilation-milestones.md:130-149, docs/v4-compilation-milestones.md:230-241, docs/v4-compilation-milestones.md:275-280). I do not see a new TODO/scaffold introduced by this PR.

2.5. Top-down PM intent review

Finding — the M3 definition says the stage0 compiler should produce a stage1 binary and that “stage1 is functionally complete: it can compile v4 programs, not just trivial ones” (docs/v4-compilation-milestones.md:157-160), but the evidence only asks the resulting stage1 binary to run compile trivial.dag --target rust (docs/v4-compilation-milestones.md:162). That dilutes the milestone from “stage1 is a working compiler” into “stage1 can execute a smoke command,” and a worker could faithfully implement the written M3 gate while never proving stage1’s emitted output is valid or that stage1 can compile the v4 pipeline. Either strengthen the evidence or weaken the definition.

3. Verdict

REQUEST_CHANGES

The planning shape mostly preserves the v4/Pure Bootstrap intent, but the M3 acceptance evidence under-proves the milestone it defines. Fixing that before merge matters because this document is intended to steer future CI and worker dispatch.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 0009bb7a · Trigger: schedule
• Thinking: 411s wall

---

Non-blocking — Strengths

• docs/v4-compilation-milestones.md The milestone framing now cleanly separates structural compile, Rust link, first execution, self-compilation, and fixed-point evidence.

✅ No blocking concerns found.

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: a04cbf4a · Trigger: manual
• Comparison: main @ 3a9be658 ... docs/v4-compilation-milestones @ a04cbf4a
• Conversation: View conversation

---

1. Story of the diff

This PR adds docs/v4-compilation-milestones.md as a planning authority for what “v4 compiles” means at each observable stage. It separates structural compile, Rust emit, and a full runnable bootstrap; then maps the modeled bootstrap.dag chain into M0 through M4, from current structural compile through stage0 linking, trivial-program execution, stage1 self-compilation, and final stage1/stage2 fixed-point. The strongest parts are the explicit distinction between compiler-pipeline milestones and the independent TestClaim/eval track, and the M2 blocker decomposition that prevents workers from treating parser/lexer/emit/T-4/T-33 gaps as one undifferentiated “v4 doesn’t run yet” problem. The one load-bearing problem is in the immediate-actions section: it reverses the document’s own sequencing for the M1 CI gate.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

N/A — this diff is a documentation/planning artifact only; it does not introduce substrate types, Dag mutation, std/ primitives, or new coproduct variants.

1. INVARIANTS.md + modeling-discipline.md.

Finding — Fail-Closed / Boundary Discipline. docs/v4-compilation-milestones.md:250-255 says the next M1 step is a gating cargo check only “once the emitter gaps are fixed,” after noting the probe currently surfaces ~4,900 rustc errors. But docs/v4-compilation-milestones.md:295-299 makes the first recommended action “Add M1 CI step” and says to “author the gate” in src/v4/workflow/ci.dag to surface those breaks. That collapses two different CI contracts: a non-gating diagnostic probe versus a fail-closed milestone gate. Because workflow/ci.dag is the modeled CI authority under the Pure Bootstrap/recursive-flex path, landing a planning doc that tells a worker to add a known-red gate first would either break CI or normalize a continue-on-error probe as a milestone gate. Fix by either resequencing action 1 after the emitter fixes, or explicitly naming it as a bounded non-gating probe with a dissolution trigger into the real M1 gate. The relevant higher-level CI-as-data / fixed-point framing is consistent with the uploaded thesis/design context. chatgpt-review-2c35d065-d28f-4b…

1. CODING.md.

N/A — no Rust implementation code is changed. There are no new functions, helpers, methods, error/result shapes, or comments in src/v3/compiler/src/ to evaluate against CODING.md.

1. TESTING.md.

Compliant — no tests are required for a doc-only milestone map, and the proposed evidence is behavior-driven at the right level: M2 requires the real compile→emit→rustc→run chain for a trivial program at docs/v4-compilation-milestones.md:125, and M3 repeats that chain through stage1 at docs/v4-compilation-milestones.md:159-168. The M1 gate/probe ambiguity above is the one testing/CI defect; once clarified, the evidence shapes are appropriate.

1. LOCKED DESIGN DECISIONS.

Compliant — the doc preserves the locked Pure Bootstrap Zero direction by stating T-6/T-7 must be authored in .dag, not Rust, and that hand-Rust algorithm walks are a STOP without explicit PM/Director re-ratification (docs/v4-compilation-milestones.md:257-266). It also keeps CI wiring under src/v4/workflow/ci.dag (docs/v4-compilation-milestones.md:295-298), which matches the uploaded PBZ/THESIS workflow-authority framing. chatgpt-review-c86e4164-9ae7-4d…

1. TRACKED vs UNTRACKED DEBT.

Compliant — the existing stubs and blockers are named with bounded milestone context rather than introduced as new scaffolds: T-6 lexer walk (docs/v4-compilation-milestones.md:131), T-7 parse walk/parse-tree construction (:132), compile_ingest_staging (:134), T-4/T-33 (:136-137), and T-34 evaluator hooks (:231-242). The only debt-tracking ambiguity is the M1 CI action already called out: a probe needs an explicit probe disposition and dissolve-into-gate trigger, not the word “gate.”

2.5. Top-down PM intent review

Finding — the immediate-action sequence would cause the wrong work. The highest-level intent is that bootstrap/CI behavior is modeled in .dag, with compiler internals emitted from .dag and fixed-point acceptance eventually producing bit-identical stage output from the .dag source of truth. chatgpt-review-2c35d065-d28f-4b…

Within this PR’s own milestone authority, Gap 1 says the gating M1 cargo check should come “once the emitter gaps are fixed” (docs/v4-compilation-milestones.md:250-255), but Recommended action 1 tells a worker to add the M1 CI step/gate now to surface the same known breaks (docs/v4-compilation-milestones.md:295-299). A worker following that faithfully would either create a known-failing modeled CI gate or encode a non-gating probe while the document calls it a gate. That semantic mismatch should be corrected before merge.

3. Verdict

REQUEST_CHANGES. The milestone decomposition is useful and mostly aligned with Pure Bootstrap Zero, but the M1 CI gate/probe contradiction is load-bearing in a planning authority. Clarify that action before this doc becomes the dispatch surface for the next worker.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: a04cbf4a · Trigger: schedule
• Thinking: 283s wall

---

BLOCKING (1)

Root Cause

• docs/v4-compilation-milestones.md T-4 algebra grounding and T-2 algebra constructor export were collapsed into one M2 blocker → split M2 into a T-2 Node-constructor prerequisite plus T-4 Wave 2b replacing bridge Symbols with those constructors.

⚠️ One planning-authority ownership error remains; the rest of the prior findings look resolved.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: b214f90a · Trigger: schedule
• Thinking: 342s wall

---

Non-blocking — Strengths

• docs/v4-compilation-milestones.md Classified as design/docs; the milestone framing is consistent with the thesis, TASKS critical path, and live v4 scaffold I checked.

✅ No blocking concerns.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: ba042b66 · Trigger: schedule
• Thinking: 143s wall

---

Non-blocking — Strengths

• docs/v4-compilation-milestones.md Classified as design/docs, and the milestone framing is consistent with the thesis, Pure Bootstrap Zero, and the task dependencies I checked.

✅ No blocking concerns found.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 5a560258 · Trigger: schedule
• Thinking: 253s wall

---

BLOCKING (1)

Root Cause

• docs/v4-compilation-milestones.md M1 mixes type-checking evidence with binary-link evidence → keep the cargo-check probe non-gating and require cargo build or rustc plus a produced/runnable v4-stage0 receipt for M1.

⚠️ M1’s acceptance path must prove the binary milestone it defines.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: ebe35709 · Trigger: schedule
• Thinking: 389s wall

---

BLOCKING (1)

Root Cause

• docs/v4-compilation-milestones.md cycle-prevention rationale upgrades a desired module-graph acyclicity invariant into a current guarantee → either add the concrete T-28 import-edge/acyclic diagnostic work item or remove the live “no import cycle can survive” claim.

⚠️ One new documentation-faithfulness issue remains in the ratified cycle-prevention section.

[briansrls]

BLOCKING: Under INVARIANTS P1 documentation-faithfulness, this records circular imports as already rejected by 03_resolve.dag, but the live T-28 ModuleGraph only models entries/path uniqueness and resolve_with_graph still has a gated namespace merge, so the milestone doc turns an unimplemented import-cycle invariant into live evidence.