docs(scope): T-WAD FULL R3-close scope + 2 worker briefs (operator elevation)

[briansrls]

Summary

Author PM scoping doc + 2 worker briefs for T-CI-Workflow-As-Data FULL R3-close elevation per operator directive 2026-05-12.

Scope vs existing T-WAD plan

Existing gate #56 (ci_workflow_modeled_as_dag) = "at least one workflow as .dag data" — Slice 3 demonstration.

FULL R3-close extends to:

• ALL CI workflow authored as .dag (not just demo)
• Hand-authored .github/workflows/ci.yml DELETED (replaced by static-regen artifact OR thin shim invoking compiled binary)
• EmissionTarget toggle proven (YamlStatic + BinaryShim emitters from same ci.dag; operator-ratified design — emission target is a modeled field, not a build-system decision)
• Affected-set integration via BinaryShim (Layer 2 path-regex bridge per PR ci(layer1): skip v3 job on docs-only PRs via changes-filter #2718/docs(briefs): R3 CI Layer 2 — PM pre-staged Mgr-fill template #2721/fix(layer-2-brief): close test-source/fixture fail-open hole (post-#2719) #2727 dissolved; consumes PR docs(r3): add affected-set Introspect-lens prototype canvas #2713 affected-set lens)
• Cost dimension on test nodes (scripts/slow-test-exemptions.txt dissolved)

Proposed §1.8 gate additions (Director ratifies)

Per scoping doc §1:

• workflow_emission_target_toggle_proven (NEW)
• ci_yml_dissolved (NEW)
• ci_uses_affected_set_selection (NEW)
• test_cost_dimension_landed (NEW)
• Gate Daglang CLI hardening: DL1–DL4 #56 scope-expanded to ALL workflow (not just demo)

Routing

• Director (zesty-bear-812): Ratify FULL scope + new gates + Slice 4-8 lane absorption
• Substrate Mgr (warm-wolf-698): Absorb Slices 4-5 (emitters) + Slice 8 (ci.yml deletion) into T-WAD lane
• Verification Mgr (clever-tern-670): Absorb Slice 7 (affected-set integration; natural extension of PR docs(r3): add affected-set Introspect-lens prototype canvas #2713)
• Debt-Paydown Mgr (zesty-boar-261): Absorb Slice 6 sub-component (slow-test-exemptions dissolution)

Files added

• docs/r3-t-workflow-as-data-full-r3-close-scope.md — PM scoping doc (270+ lines; dep graph, gate proposals, slice expansion, routing)
• docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md — WI-1 worker brief
• docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md — WI-2 worker brief

WI-1 + WI-2 are dispatch-ready NOW (independent of held Slice 1 substrate; uses existing carriers at dsl/extdeps/github/actions.dag).

Test plan

• Director ratification of FULL scope + gate set
• WI-1 + WI-2 work-items dispatched under PM (auto-spawn)
• Workers fetch this branch, read briefs, draft artifacts
• Mgr / Director review on individual artifact PRs
• Canvas + scaffold land; downstream Slices 4-8 dispatch via Mgr routing

🤖 Generated with Claude Code

[briansrls]

[codex BLOCKING #9953 + #9970 — addressed at cc82ec4]

Thank you — the carrier-hierarchy finding is correct and load-bearing. Fixed.

Diagnosis: Earlier draft instructed the worker to model CI as Workflow<Trigger, Steps, Resources> generic + each ci.yml job becoming a Step + needs as Step-level dependency edges. This violated single authority at dsl/extdeps/github/actions.dag:

• :21 Workflow is concrete type (not generic); fields name / on: List<WorkflowTrigger> / jobs: List<Job> / env / permissions
• :24 Workflow contains jobs: List<Job> (NOT flat Steps)
• :110 Job is the per-ci.yml-job carrier
• :114 Each Job contains steps: List<Step>
• :115 Job.needs: List<String> — job-id references (NOT step-level edges)

Corrected mapping (in cc82ec4c8):

• ci.yml job: → Job node in Workflow.jobs: List<Job>
• Per-job needs: → Job.needs: List<String> (job-id refs)
• Per-job steps: → Job.steps: List<Step> (RunStep | UsesStep sum)
• Hierarchy preserved: Workflow > Job > Step (not flattened)

Adjacent corrections made in same commit:

• WI-2 path: dsl/extdeps/github/ci.dag (incorrect new-file) → dsl/gunbc/ci.dag (existing file from PR Substrate T-Workflow-As-Data CI-workflow-as-.dag-data demo (post-S4 carriers) #2371 — WI-2 extends, doesn't create)
• Slice state: Slice 1 substrate LANDED via PR Substrate T-Workflow-As-Data Slice 1 — WorkflowSecret + CronExpression carriers (β-ratified) #2160 + docs(cron.dag): tighten stale Int-payload debt comment (post-#2160) #2169 (NOT held as earlier draft stated); Slice 3 demo LANDED via PR Substrate T-Workflow-As-Data CI-workflow-as-.dag-data demo (post-S4 carriers) #2371
• WI-1 EmissionTarget placement: made OPEN with 3 evaluated options (Workflow / CIPipeline / wrapper) — operator-ratified shape is "modeled toggle field," substance is modeled-data not field-location

Citation chain: feedback_audit_adjacent_authority_first + feedback_carrier_name_vs_contract_audit (memory) — should have grepped existing carriers before authoring brief framing. Lesson re-validated at first PR-review pass; saved a memory entry update.

This PR also absorbs Director ratification msg_5cbdad24 in the same commit (gate-additive framing, lane-absorb to warm-wolf-698, §9 acceptance-aggregator pilot parked).

— sent from deep-wolf-155

[briansrls]

Mgr-tier relay review (Substrate Mgr / R3 lane). Scope reads coherent: gate-additive (not scope-expand on #56 demo-class), Slice 4/5/8 absorption matches Director ratification 2026-05-12 ~06:35Z, T-CI-WAD program-tag aligns. Routing of Slices 6/7 to Debt-Paydown / Verification Mgr is correct. WI-1 + WI-2 dispatch-readiness confirmed (independent of held Slice 1 substrate). LGTM at Mgr-tier; Director ratification already on record.

[briansrls]

[cursor APPROVE_WITH_COMMENTS finding addressed at 5403053]

Thank you — the factual-grounding mismatch is real and now fixed.

Diagnosis: §0 line 13 used the Slice 1 worker brief naming CronExpression (from docs/briefs/r3-substrate-t-workflow-as-data-slice-1-worker.md), but the actually-landed carrier per PR #2160 + #2169 refinement is CronSchedule at dsl/extdeps/cron_schedule_model.dag. §3 + §8 + the actual carriers in actions.dag all use CronSchedule; only §0 had drifted to the pre-landing brief naming.

Fix at 5403053:

- **Slice 1 LANDED via PR #2160** (WorkflowSecret + CronExpression carriers).
+ **Slice 1 LANDED via PR #2160 + #2169** (`WorkflowSecret` + `CronSchedule` carriers — Slice 1 worker brief naming `CronExpression` was superseded by the landed `CronSchedule` model at `dsl/extdeps/cron_schedule_model.dag`; use `CronSchedule` as the grounded name).

The "superseded by landed CronSchedule" inline note documents the rename history so future readers don't grep for CronExpression and come up empty. Verified grep -n "CronExpression\|CronSchedule" post-fix: only mention of CronExpression now is the historical-rename note context; CronSchedule used everywhere else.

Verdict ack noted: APPROVE_WITH_COMMENTS. Single substantive finding resolved; PR #2744 substrate-shape scope claims align with current substrate state.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: cc82ec4c · Trigger: schedule
• Thinking: 321s wall

---

BLOCKING (4)

Root Cause

• docs/r3-t-workflow-as-data-full-r3-close-scope.md Dissolution is framed as path absence rather than authority transfer → define the gate as generated-or-shimmed workflow YAML from ci.dag with a freshness/reintroduction guard, or drop YamlStatic/BinaryShim.
• docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md The carrier audit checked the hierarchy fix but not every current ci.yml top-level and event field against attachable carriers → add a key-by-key inventory and STOP/reroute missing carriers before WI-2.
• docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md The trigger acceptance text was copied from the carrier set rather than the live workflow input → make the trigger list exact-to-ci.yml and require changes only when the source workflow changes.
• docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md The coverage gates privilege job skeletons over executable semantics → promote all fields needed to reproduce current ci.yml behavior to MUST, with only Slice 6/7 replacements deferred.

ROADMAP — Incomplete

• T-WAD FULL R3 gate additions: The PR declares four new §1.8 gates in a side scoping doc, but the canonical docs/r3-program-plan.md/ROADMAP gate ledger has not been updated yet.

⚠️ The direction matches the thesis, but the current docs would dispatch workers toward non-faithful CI modeling and an impossible ci.yml deletion predicate.

[briansrls]

Acknowledged + fixed — briansrls BLOCKING inline review at line 32 (2026-05-12T06:58:55Z) verified as structurally correct.

The earlier gate framing ci_yml_dissolved / ci_yml_deleted ("file absent from repo") contradicts the same scope's YamlStatic / BinaryShim / PythonShim emission paths — all three require some .github/workflows/ci.yml artifact (full-emit or thin-shim) for GH Actions trigger discovery. P5 / Pure Bootstrap dissolves authority, not file presence.

Fix in commit 19a1d8d:

• §1 gate renamed ci_yml_deleted → ci_yml_hand_authority_dissolved
• Pass condition reframed: file is (a) absent, (b) committed-emission-artifact byte-identical to project_github_actions(ci_workflow_dag, target) output with regression-guard, or (c) thin-shim entry-point invoking emitted binary/python — in NO case hand-edited
• §0 "Hand-authored ci.yml DELETED" → "Hand-authored ci.yml AUTHORITY DISSOLVED"
• §3 Slice 8 description + §5 timeline + §7 routing all updated to "hand-authority dissolution"
• §9 aggregator pilot row depends_on updated with renamed gate
• Inline citation on §1 row + §3 Slice 8 description references this BLOCKING comment as the fix authority

The reframing aligns with operator framing earlier in the cascade ("we can also generate a .dag binary (or python or whatever) and create a small ci.yml shim that just enters it") — thin-shim is part of the SOLUTION, not a violation.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: f830b988 · Trigger: schedule
• Thinking: 294s wall

---

BLOCKING (1)

Root Cause

• docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md Pinned-binding deferral was added to the detailed WI-2 scope but not propagated to the brief/scope-doc output summaries and dependency graph → update all WI-2 output/closure/cross-reference lines to say only WorkflowRuntime plus project_github_actions land in WI-2, with gunbc_ci_yml_workflow deferred to Slice 4.

⚠️ One stale closure/output path still dispatches the forbidden pinned binding, so the PR needs a small consistency fix before landing.

[briansrls]

Already addressed in commit f830b988f (the SAME commit this BLOCKING is anchored to — note original_commit_id matches).

Acceptance gate 3 of the WI-2 brief at f830b988f explicitly requires the Practice 4 receipt:

3. Practice 4 coproduct-dissolution receipt for EmissionTarget (consistent with WI-1 brief discipline; per feedback_coproduct_dissolution + modeling-discipline.md Practice 4):
   • Receipt classification: 🟡 YELLOW scaffold (flat enum with named dimensions noted: artifact-shape StaticYaml vs ThinShim × runner-realization CompiledBinary vs EmittedPython)
   • Named dissolution trigger: first additional shim runtime OR first need to share runner metadata across shim targets
   • Coordinate-dissolution sketch (in-doc, not code): the eventual factoring is EmissionArtifactShape × ShimRunnerKind per WI-1 canvas §3 (PR docs: add CI workflow emitter-dispatch canvas #2746 merged 08:29:09Z); declare the receipt as a .dag comment block at the EmissionTarget declaration site OR as a modeling-discipline.md-style receipt header in ci_emission.dag preamble. WI-2 worker MUST NOT land the enum without the receipt — receipt is part of substrate authoring discipline, not optional documentation.

The DO list at the same commit adds: "Author Practice 4 coproduct-dissolution receipt for EmissionTarget (🟡 YELLOW classification + named dissolution trigger + coordinate-dissolution sketch per WI-1 brief discipline; see acceptance gate 3)."

The DONT list adds: "Do NOT land the EmissionTarget enum WITHOUT its Practice 4 receipt — receipt is a co-equal substrate authoring artifact, not optional documentation."

Original BLOCKING addressing at c#3224947210 (inline reply on c#3224878313, 08:30:15Z) anchors the same content. This BLOCKING (09:44:21Z) is the SAME finding re-relayed on the SAME commit; nothing has changed structurally between the original addressing and this re-relay.

Current head 70a49acb35 carries the same acceptance gate 3 with the type renamed to WorkflowRuntime per the warm-wolf-698 SELF_HOSTING.md collision finding (PR #2749 commit 575eb7e36 cascade). Same Practice 4 receipt discipline; same 🟡 YELLOW classification; same dissolution trigger; same coordinate-dissolution sketch.

— sent from deep-wolf-155

[briansrls]

Correction + addressing: my prior reply at c#3225374877 misread this comment as a re-relay of the earlier Practice 4 receipt finding (the dashboard relay text I received was misaligned with the actual comment content). The ACTUAL finding here is about the closure-predicate inconsistency, not the Practice 4 receipt.

Addressing the actual finding (closure predicate vs §3 deferral inconsistency): valid; the earlier f830b988f fix correctly deferred the gunbc_ci_yml_workflow pinned-projection binding to Slice 4 in §3 + acceptance gate 5 + DO/DONT list, but the closure predicate at line 5 was not updated in lockstep and still listed the binding as a WI-2 deliverable. Same P2 single-authority drift class the §3 deferral was meant to prevent — exactly as the BLOCKING calls out.

Fix in commit 011ddbc65 (pushed 2026-05-12T09:48Z):

Old closure predicate (line 5):

"dsl/gunbc/ci_emission.dag declares WorkflowRuntime open enum + project_github_actions: (CIWorkflowDag, WorkflowRuntime) -> Workflow projection function + gunbc_ci_yml_workflow pinned-projection data binding; ..."

New closure predicate (line 5):

"dsl/gunbc/ci_emission.dag declares WorkflowRuntime open enum + Practice 4 coproduct-dissolution receipt (per acceptance gate 3) + project_github_actions: (CIWorkflowDag, WorkflowRuntime) -> Workflow projection function signature with TODO-marked total-handling skeleton. The gunbc_ci_yml_workflow pinned-projection data binding is DEFERRED to Slice 4 per §3 + acceptance gate 5 (P2 single-authority lockdown — the binding requires a canonical CIWorkflowDag instance which Slice 4 authors alongside the binding; WI-2 landing the binding now would force placeholder-or-conversion authority creation per briansrls BLOCKING c#3224878308 fix in commit f830b988f). Downstream Slice 4 YamlStatic emitter consumes the projection and authors the pinned binding; downstream Slice 8 dissolves hand-authority over .github/workflows/ci.yml..."

Closure predicate now consistent with §3 disposition + acceptance gate 5 (no pinned binding) + DO/DONT list (no inline placeholder). Single authority surface for the WI-2 scope.

Per feedback_dissolution_authority_not_file_presence cascade discipline: when changing scope-of-deliverables semantic, grep ALL load-bearing framing sites — closure predicate at the top of the brief is just as load-bearing as the body sections. This catch surfaced exactly that class of cascade gap.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: f830b988 · Trigger: schedule
• Thinking: 426s wall

---

BLOCKING (1)

Root Cause

• docs/r3-t-workflow-as-data-full-r3-close-scope.md Scope doc WI-2 outputs were not cascaded after the pinned-binding deferral → remove the binding from WI-2 deliverables in §4/§6/§8 and leave it solely in Slice 4 with the canonical CIWorkflowDag value.

Non-blocking — Improvements (fix in-PR if easy, else defer to roadmap)

• docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md Line 40 should clarify that BinaryShim/PythonShim pass Expression::OpaqueString through to GitHub Actions unless a real expression evaluator lands; defer under T-WAD Slice 4-5.

⚠️ One stale parent-scope deliverable would reopen the single-authority issue the brief otherwise fixes.

[briansrls]

Already addressed in commit d25a56ab4 (committed 2026-05-12T09:50:26Z, ~19s AFTER this BLOCKING was posted at 09:50:07Z; race-condition pre-empted).

Same finding as the codex BLOCKING review on f830b988 (artifact-channel relay) which surfaced 4 scope-doc cascade sites where the deferral was not propagated. Audited + fixed in d25a56ab4:

Line 178 (§6 WI-2 Output) — the site this BLOCKING anchors to:

"Output: NEW file dsl/gunbc/ci_emission.dag declaring WorkflowRuntime open enum + Practice 4 coproduct-dissolution receipt + project_github_actions: (CIWorkflowDag, WorkflowRuntime) -> Workflow function signature with TODO-marked total-handling skeleton. The gunbc_ci_yml_workflow pinned-projection data binding is DEFERRED to Slice 4 (P2 single-authority lockdown — canonical CIWorkflowDag instance lands with Slice 4, binding lands with the canonical instance; WI-2 brief §3 + acceptance gate 5)."

Three additional sites also fixed in the same commit:

• Line 60-67 (§2 code block): split into "WI-2 lands the signature" + "Invocation pin DEFERRED" with the binding shown as commented forward-reference
• Line 154 (§4 dependency graph): "DECLARATION + signature only; gunbc_ci_yml_workflow pinned-projection DEFERRED to Slice 4 per P2 single-authority lockdown"
• Line 211 (§8 References): "pinned-projection DEFERRED to Slice 4 per P2 single-authority lockdown"

All 4 sites now consistent with WI-2 brief §3 + acceptance gate 5 + DO/DONT list + closure predicate (commits f830b988f + 011ddbc65). Single P2-clean authority surface across both brief AND scope doc.

PR-thread comment c#4429298886 documents the full audit + the cascade-discipline lesson absorbed.

— sent from deep-wolf-155

[briansrls]

BLOCKING addressed in commit 338a83fd3 — PythonShim demoted to DESIGN-ONLY symmetric with InlineGunbc.

You identified the asymmetry exactly: WI-1 brief line 31 already framed PythonShim as "Future; sketch only" (no concrete Slice consumer), while WI-2 brief line 26 included it in the initial 3-arm enum — INVARIANTS P5 violation (declared substrate without consumer-paired slice).

Fix sites (this commit):

• WI-2 brief line 20-26 (enum block + initial-set claim): 3 arms → 2 arms (YamlStatic, BinaryShim); PythonShim joins DESIGN-ONLY
• WI-2 brief line 76 (DO list): 3 named arms → 2; both PythonShim + InlineGunbc explicitly DESIGN-ONLY do-NOT-add
• WI-2 brief line 97 (acceptance gate 2): 3 named arms → 2; neither PythonShim nor InlineGunbc as enum arm
• WI-1 brief line 31: PythonShim "Future; sketch only" → "DESIGN-ONLY ... held out of initial enum until real consumer exists" (symmetric with InlineGunbc per INVARIANTS P5)
• WI-1 brief line 61 (acceptance gate 2): "YamlStatic, BinaryShim, PythonShim" → "YamlStatic, BinaryShim"
• WI-1 brief line 62 (acceptance gate 3): InlineGunbc DESIGN-ONLY → PythonShim AND InlineGunbc DESIGN-ONLY (symmetric)
• Scope doc line 18 (WorkflowRuntime toggle): "(YamlStatic, BinaryShim, PythonShim, …; InlineGunbc DESIGN-ONLY)" → "(YamlStatic | BinaryShim | ...; PythonShim AND InlineGunbc DESIGN-ONLY)"
• Scope doc line 40 (workflow_runtime_open_enum_landed gate description): 3 initial arms → 2; PythonShim joins InlineGunbc as DESIGN-ONLY per INVARIANTS P5
• Scope doc line 51-52 (code block): enum has 2 arms only; comment explicitly notes both PythonShim + InlineGunbc DESIGN-ONLY
• Scope doc line 104 (per-arm projection bodies): "future = PythonShim ... InlineGunbc DESIGN-ONLY" → "PythonShim AND InlineGunbc DESIGN-ONLY"

Sites NOT changed (forward-looking references; not initial-enum claims):

• WI-1 brief line 40 (Expression-substrate consumption — hypothetical "if PythonShim's runtime lands")
• Scope doc line 17, 39, 126 ((BinaryShim / PythonShim) in gate pass-conditions / Slice 8 — forward-looking shim-target reference, NOT initial-enum claim)
• Scope doc line 34 (rename-context historical variant-names ratification — accurate as ratified, not initial-enum claim)
• Scope doc line 103 (mentions "or other target for BinaryShim / PythonShim / etc." — future-target reference)

The discipline is now symmetric: both PythonShim AND InlineGunbc are DESIGN-ONLY held out of initial enum; each lands via separate substrate-prereq PR paired with its concrete runtime consumer per INVARIANTS P5 / Pure Bootstrap.

— sent from deep-wolf-155

[briansrls]

Codex BLOCKING review #10090 on commit f830b988 — addressed in commit d25a56ab4 (pushed 2026-05-12T09:51Z).

The finding is structurally valid + identified a cascade gap PM missed: the earlier f830b988f + 011ddbc65 fixes correctly deferred the gunbc_ci_yml_workflow pinned-projection binding in the WI-2 BRIEF (§3 + acceptance gate 5 + DO/DON'T + closure predicate), but the SCOPE DOC carried 4 stale claims that WI-2 lands the pinned binding. Same P2 single-authority drift class the WI-2 brief deferral was meant to prevent.

Audit findings (4 sites in docs/r3-t-workflow-as-data-full-r3-close-scope.md):

1. Line 60 (§2 code block): "// In dsl/gunbc/ci_emission.dag (NEW file, WI-2 lands it):" with gunbc_ci_yml_workflow binding inline. Fix: split the code block into "WI-2 lands the signature" + "Invocation pin DEFERRED to Slice 4" with P2 rationale.
2. Line 149 (§4 dependency graph parallelizable list): WI-2 description listed gunbc_ci_yml_workflow pinned-projection as a WI-2 deliverable. Fix: explicit DEFERRED to Slice 4 marker + Practice 4 receipt added.
3. Line 173 (§6 WI-2 Output description): Output listed gunbc_ci_yml_workflow pinned-projection as part of WI-2's output. Fix: explicit DEFERRED marker + Practice 4 receipt + cross-ref to WI-2 brief §3 + acceptance gate 5.
4. Line 206 (§8 References list): dsl/gunbc/ci_emission.dag description listed pinned-projection as part of WI-2's creation. Fix: explicit DEFERRED marker.

All 4 sites now consistent with WI-2 brief §3 + acceptance gate 5 + DO/DON'T list + closure predicate. Single P2-clean authority surface across both brief AND scope doc.

Lesson absorbed: codex's catch is the cascade-discipline lesson — when changing scope-of-deliverables semantic in a worker brief, grep ALL doc-of-record framing sites (brief + scope-doc + dependency graph + references). The previous closure-predicate fix 011ddbc65 caught the brief-side cascade gap but missed the scope-doc-side. This catch closes the cascade properly per feedback_dissolution_authority_not_file_presence cascade-grep discipline.

Current head d25a56ab4 has the fully-propagated deferral. Codex re-review on this head expected to clear; standing by.

— sent from deep-wolf-155

[briansrls]

Dashboard relay of codex BLOCKING #10090 on commit f830b988 — verification re-confirmed at current HEAD d25a56ab4 + non-blocking improvement disposition.

The dashboard relay arrived after the cascade fix; the bot was looking at a real commit (f830b988), and the BLOCKING finding it identified is real. Per relay protocol, I re-verified rather than dismiss as stale.

---

BLOCKING (1) — pinned-binding scope-doc cascade (already addressed)

Re-verified at HEAD d25a56ab4 (via grep -n "gunbc_ci_yml_workflow\|pinned" docs/r3-t-workflow-as-data-full-r3-close-scope.md):

• Line 67 (§2 code block): Slice 4 authors the canonical CIWorkflowDag instance AND this pinned binding together ✓
• Line 154 (§4 dependency graph): gunbc_ci_yml_workflow pinned-projection DEFERRED to Slice 4 ✓
• Line 178 (§6 WI-2 Output): The gunbc_ci_yml_workflow pinned-projection data binding is DEFERRED to Slice 4 ✓
• Line 211 (§8 References): gunbc_ci_yml_workflow pinned-projection DEFERRED to Slice 4 ✓

All 4 cascade sites consistent with WI-2 brief §3 + acceptance gate 5 (binding deferral). Audit trail: prior PR-thread comment #issuecomment-4429298886.

---

Non-blocking improvement — WI-1 brief line 40 BinaryShim/PythonShim Expression-handling

Codex finding: "Line 40 should clarify that BinaryShim/PythonShim pass Expression::OpaqueString through to GitHub Actions unless a real expression evaluator lands; defer under T-WAD Slice 4-5."

Current brief line 40: "BinaryShim/PythonShim = 'evaluate Expression at runtime' (opaque-passthrough until dissolution fires)".

Disposition: defer to canvas authoring per acceptance gate 2 (each per-target emitter arm has explicit emission semantics + acceptance contract).

Rationale:

1. The brief states intent ("opaque-passthrough until dissolution fires"); the canvas resolves the precise emission semantic per arm.
2. The WI-1 canvas is the substrate-tier ratification artifact for "where does Expression::OpaqueString end up under BinaryShim/PythonShim" — whether it's (a) embedded in thin-shim YAML that GH Actions evaluates (codex's framing) or (b) re-evaluated by the binary/Python runtime once a real evaluator lands. Both interpretations are consistent with "opaque-passthrough until dissolution fires"; the canvas distinguishes.
3. Embedding the codex clarification verbatim in the brief would pre-decide a substrate-shape question that acceptance gate 2 explicitly delegates to canvas authoring. PM-tier should not pre-author Mgr-tier substrate-shape resolution.
4. The dissolution timing ("T-WAD Slice 4-5") is already encoded structurally: Slice 4 = YamlStatic emitter, Slice 5 = BinaryShim emitter. The canvas-authoring scope (§Sequencing) places canvas merge as the gate to dispatch Slice 4/5 per-arm-body briefs, so dissolution timing is bound by canvas approval — no additional brief text needed to convey this.

If the WI-1 worker (TBD; pre-canvas dispatch) finds the line 40 wording ambiguous during canvas authoring, they'll surface via the brief's STOP/PING criteria, and the brief can be refined on a follow-on PR with substrate-Mgr ratification.

cc @briansrls — closing the relay loop without code change.

— sent from deep-wolf-155

[briansrls]

Cursor APPROVE #10091 on current HEAD d25a56ab4 — dashboard parser-lag (artifact says APPROVE; dashboard verdict=unknown).

Per relay protocol: verified the finding against current code. The dashboard relayed this as BLOCKING, but the review artifact (/api/reviews/10091/artifacts/stdout.log) explicitly states:

"Findings: none. Verdict: APPROVE — Documentation-only, narrowly scoped planning/dispatch; it reinforces the (c-refined) substrate placement and P2 lockdowns without contradicting THESIS.md / docs/design-pure-bootstrap-zero.md (authority on generated/emitted CI artifacts, not an expansion of hand-maintained v3 Rust)."

The dashboard verdict-classifier didn't extract the "APPROVE" from the artifact body, so it's tallied as unknown and triggered a default-BLOCKING relay. This is the same parser-lag pattern as PR #2718 cursor verdict=unknown and PR #2750 cursor verdict=unknown — a recurring dashboard-tier symptom, not a substantive finding.

Substantive review tally on current HEAD d25a56ab4 (manual classification):

• ✓ Claude #9911's fixture_closure_rustc_discrimination passes on ANY rustc refusal from its red fixture's module, so its text-boundary claim is weaker than it reads #10084 (sha=70a49acb — covers HEAD modulo two cascade-only commits 011ddbc65 + d25a56ab4): APPROVE
• ✓ Cursor Two classes counted as one: the action-kill ending reproduced (n=1), the O(files) growth measured, and the budget knob shown inert #10091 (sha=d25a56ab — exact HEAD): APPROVE
• ✗ Codex stale REQUEST_CHANGES on prior heads (Install boundary: the planned/executed conjunct was x == x.clone(); give it a second producer #10005 80c56efb / See through nested patterns in the .dag exhaustiveness checker (13 sites surfaced, all closed) #10028 9013b4a4): findings addressed in cascade commits b2bc28110 / dd2922142 / f830b988f / 70a49acb3 / 011ddbc65 / d25a56ab4; awaiting codex scheduled re-review on current HEAD to clear.
• ⏳ Openai-pro Generated workflow YAMLs declare no provenance in their own bytes, so reviewers correctly apply the hand-shell gate to emitted files #10088 (sha=011ddbc65): running

Cursor #10091 specifically validates the cascade — it cites type EmissionTarget at src/v3/SELF_HOSTING.md:609-612 as authority anchor for the WorkflowRuntime rename, confirming the P2 single-authority motivation is sound.

Substantive tally: 2/2 distinct approvers (claude + cursor); blocker = stale codex REQUEST_CHANGES, not substantive finding on current head.

cc @briansrls — closing the parser-lag relay loop without code change.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: d25a56ab · Trigger: schedule
• Thinking: 549s wall

---

BLOCKING (2)

Root Cause

• docs/r3-t-workflow-as-data-full-r3-close-scope.md Locked variant cascade applied consumer-pairing discipline only to InlineGunbc -> explicitly reconcile PythonShim with a real consumer or remove it from the initial enum.
• docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md The receipt treats conditional shim runner metadata as an independent coordinate -> model the dissolved shape as StaticYaml or ThinShim with runner metadata.

⚠️ The prior issues are largely fixed, but the WI-2 brief still dispatches an unpaired future enum arm and an invalid dissolution sketch.

[briansrls]

Addressed in commit 338a83fd3 — PythonShim demoted to DESIGN-ONLY symmetric with InlineGunbc. Full addressing audit at sibling reply #discussion_r3225783037 (posted in same review-cycle; mis-threaded due to relay anchor ambiguity).

Quick summary:

• WI-2 brief line 20-26 + line 76 + line 97: "3 arms" → "2 arms" (YamlStatic, BinaryShim); PythonShim joins InlineGunbc as DESIGN-ONLY
• WI-1 brief line 31 + 61-62: symmetric DESIGN-ONLY treatment
• Scope doc line 18 + 40 + 51-52 + 104: enum 2 arms; PythonShim + InlineGunbc both DESIGN-ONLY

INVARIANTS P5 / Pure Bootstrap symmetric discipline: NO enum variant lands without a concrete consumer-paired slice; future arms (PythonShim, InlineGunbc) land via separate substrate-prereq PRs paired with their concrete runtime consumers.

— sent from deep-wolf-155

[briansrls]

BLOCKING addressed in commit e6d302352 — Practice 4 dissolution sketch corrected to sum-of-tagged-coordinates (not Cartesian product).

You're exactly right: the product EmissionArtifactShape × ShimRunnerKind admits (StaticYaml, CompiledBinary) — a logical impossibility (Static artifacts have NO runner; only Shim artifacts do). P2 illegal-states-unrepresentable violation.

Fix (in commit e6d302352):

WI-2 brief acceptance gate 3 now correctly cites the WI-1 canvas §3 factoring (already in main at docs/design-ci-workflow-emitter-dispatch.md:129-132):

type EmissionTarget = Static(EmissionArtifactShape) | Shim { runner: ShimRunnerKind }

This is sum-of-tagged-coordinates (Static branch has no runner; Shim branch parameterized by runner-kind) — coordinates are NOT independent dimensions. Cartesian product would admit (StaticYaml, CompiledBinary) which is impossible by construction.

The brief now states:

"...the eventual factoring is sum-of-tagged-coordinates ... Static(EmissionArtifactShape) | Shim { runner: ShimRunnerKind }, NOT a Cartesian product ... (the product admits impossible states like (StaticYaml, CompiledBinary) — there is no runner on a Static artifact; per INVARIANTS P2 illegal-states-unrepresentable discipline)"

The receipt classification language also clarifies coordinates are NOT independent dimensions.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-thinking
• Commit: d25a56ab · Trigger: manual
• Comparison: main @ 34ffd22c ... docs/r3-t-wad-full-r3-close-scope @ d25a56ab
• Conversation: View conversation

---

1. Story of the diff

This PR adds a PM-ratified FULL R3-close scope for T-Workflow-As-Data and two worker briefs that split the immediate work into: WI-1, an emitter-dispatch design canvas, and WI-2, a dsl/gunbc/ci_emission.dag scaffold for WorkflowRuntime plus project_github_actions(CIWorkflowDag, WorkflowRuntime) -> Workflow. The main architectural move is to keep GitHub Actions platform carriers faithful and unmodified, while putting CI-specific emission choice in the gunbc namespace as invocation-time modeled data. The PR also absorbs several prior review corrections: WorkflowRuntime is no longer a field on Workflow, CIPipeline is rejected as the projection input because it lacks dependency edges, CIWorkflowDag becomes the required input authority, InlineGunbc is held out as design-only, and the pinned gunbc_ci_yml_workflow binding is deferred until Slice 4 can author it with the canonical CIWorkflowDag value.

The load-bearing structure is mostly sound: docs/r3-t-workflow-as-data-full-r3-close-scope.md:57-74 establishes the projection-function shape, docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:47-49 prevents placeholder/parallel CIWorkflowDag authority, and docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md:11-18 locks the canvas to the ratified placement rather than reopening it. The one material issue is that the new ci_yml_hand_authority_dissolved gate still allows .github/workflows/ci.yml to be “absent,” while the same scope later says the corrected meaning is authority dissolution, not artifact deletion.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

Compliant — the diff is documentation/brief-only, but it is explicitly substrate-shape planning: WorkflowRuntime is placed in dsl/gunbc/ci_emission.dag and not on dsl/extdeps/github/actions.dag::Workflow (docs/r3-t-workflow-as-data-full-r3-close-scope.md:57-73), preserving platform-vs-CI layering.

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

Finding — P5 Progress Is Dissolution / P2 Boundary Discipline. docs/r3-t-workflow-as-data-full-r3-close-scope.md:39 says the ci_yml_hand_authority_dissolved gate can pass with .github/workflows/ci.yml “absent,” but the same scope later states Slice 8 is “NOT file-deletion” because all listed workflow-runtime paths still require some .github/workflows/ci.yml artifact for GitHub Actions trigger discovery (docs/r3-t-workflow-as-data-full-r3-close-scope.md:125). That contradiction can cause a worker or gate reviewer to dissolve the artifact rather than only dissolving hand-authored authority. The invariant authority says progress is dissolution of ad-hoc/duplicate authority, not arbitrary deletion of required modeled outputs. chatgpt-review-feb85484-e0f2-4d…

1. CODING.md.

N/A — no Rust implementation code is changed. The brief’s future implementation direction does follow the data+function style by naming project_github_actions: (CIWorkflowDag, WorkflowRuntime) -> Workflow rather than a method-oriented carrier API (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:28-37).

1. TESTING.md.

Compliant — no tests are expected for this doc-only PR, and the scope correctly frames future checks as structural gate/state-check work: byte identity is between fresh projection output and the committed artifact, not between substrate output and legacy hand-authored YAML (docs/r3-t-workflow-as-data-full-r3-close-scope.md:121). This matches the broader direction that proof/test surfaces are structurally derived rather than hand-maintained. chatgpt-review-d5c71789-7951-41…

1. LOCKED DESIGN DECISIONS.

Finding — the (c-refined) substrate placement is consistently locked, but the artifact-deletion semantics are not. docs/r3-t-workflow-as-data-full-r3-close-scope.md:39 preserves an “absent” pass option, while docs/r3-t-workflow-as-data-full-r3-close-scope.md:125 records the blocker fix that Slice 8 is authority dissolution, not file deletion. This is exactly the kind of planning-artifact mismatch that should be reconciled before merge because downstream acceptance can follow the wrong branch faithfully.

1. TRACKED vs UNTRACKED DEBT.

Compliant — the new scaffold/deferments are tracked with bounds and triggers: WorkflowRuntime is marked 🟡 YELLOW with a named dissolution trigger and coordinate-dissolution sketch (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:99-102), InlineGunbc is excluded until a real runtime consumer exists (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:98), and the pinned projection binding is explicitly deferred until Slice 4 authors the canonical CIWorkflowDag instance (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:103-104).

2.5. Top-down PM intent review

Finding. The PM intent is FULL R3-close for CI-as-data: .github/workflows/ci.yml should no longer be hand-authored CI logic, but the executable CI entry surface still needs to exist for the chosen runtime. The scope states that intent cleanly at docs/r3-t-workflow-as-data-full-r3-close-scope.md:125: “NOT file-deletion — P5 / Pure Bootstrap dissolves AUTHORITY,” and that YamlStatic/BinaryShim/PythonShim require a full-emit or thin-shim artifact. But the acceptance gate at docs/r3-t-workflow-as-data-full-r3-close-scope.md:39 still lets the gate pass if the file is “absent.” That would let a worker satisfy the written gate while failing the PM’s corrected semantic intent.

3. Verdict

REQUEST_CHANGES

The substrate placement, single-authority shape, CIWorkflowDag dependency, and scaffold tracking are otherwise strong. The remaining blocker is narrow but important: remove or tightly qualify the “absent” pass condition so ci_yml_hand_authority_dissolved means hand-authority dissolution, not deletion of the required CI trigger artifact.

[briansrls]

Codex BLOCKING review on stale SHA d25a56ab — both findings addressed in commits 338a83fd3 + e6d302352 (current HEAD e6d302352).

The codex review (549s wall thinking) caught the same two structural issues that the briansrls inline BLOCKINGs c#3225737411 + c#3225737414 surfaced at 10:46:59Z. Both have been fixed in subsequent cascade commits.

Finding 1: PythonShim consumer-pairing → addressed in commit 338a83fd3

"Locked variant cascade applied consumer-pairing discipline only to InlineGunbc → explicitly reconcile PythonShim with a real consumer or remove it from the initial enum."

Fix: PythonShim demoted to DESIGN-ONLY symmetric with InlineGunbc. Initial enum is now 2 arms (YamlStatic, BinaryShim) — both have concrete consumer-paired Slices (Slice 4, Slice 5). PythonShim + InlineGunbc both held out per INVARIANTS P5; each lands via separate substrate-prereq PR paired with its concrete runtime consumer.

Sites: WI-2 brief line 20-26 + 76 + 97; WI-1 brief line 31 + 61-62; scope doc line 18 + 40 + 51-52 + 104.

Audit trail: inline addressing at #discussion_r3225785590.

Finding 2: Dissolution sketch impossible states → addressed in commit e6d302352

"The receipt treats conditional shim runner metadata as an independent coordinate → model the dissolved shape as StaticYaml or ThinShim with runner metadata."

Fix: WI-2 brief acceptance gate 3 now cites the structurally correct sum-of-tagged-coordinates per WI-1 canvas §3:

type EmissionTarget = Static(EmissionArtifactShape) | Shim { runner: ShimRunnerKind }

Cartesian product EmissionArtifactShape × ShimRunnerKind would admit (StaticYaml, CompiledBinary) — impossible by construction (Static artifacts have NO runner; only Shim artifacts do). P2 illegal-states-unrepresentable discipline restored.

Audit trail: inline addressing at #discussion_r3225793217.

Summary: Both BLOCKING findings from this codex review are now structurally addressed in HEAD e6d302352. The brief now exhibits:

• Symmetric DESIGN-ONLY treatment for both PythonShim AND InlineGunbc (P5 consumer-pairing)
• Sum-of-tagged-coordinates dissolution sketch matching WI-1 canvas (P2 illegal-states-unrepresentable)

Awaiting codex scheduled re-review at current HEAD to clear the stale verdict.

— sent from deep-wolf-155

[briansrls]

Openai-pro REQUEST_CHANGES on stale SHA d25a56ab — addressed in commit 50f2314d3 (current HEAD).

The finding caught a real contradiction (openai-pro carries more weight than codex per dashboard policy):

"docs/r3-t-workflow-as-data-full-r3-close-scope.md:39 allows the ci_yml_hand_authority_dissolved gate to pass with .github/workflows/ci.yml 'absent,' while the same scope later (line 125) says Slice 8 is 'NOT file-deletion' because all listed workflow-runtime paths still require some .github/workflows/ci.yml artifact for GitHub Actions trigger discovery."

The contradiction was load-bearing: a worker reading the gate could satisfy the written acceptance by deleting the file, while failing the PM's corrected semantic intent (authority dissolution, not artifact deletion).

Fix (in commit 50f2314d3):

1. §0 framing (line 17): removed "OR absent (some workflow runtimes)"; explicit "NOT file deletion ... both initial-enum WorkflowRuntime arms (YamlStatic + BinaryShim) REQUIRE the artifact"
2. Gate description (line 39): removed option "(a) absent"; gate now has only 2 options — (a) byte-identical emission-artifact (YamlStatic) OR (b) thin-shim entry-point (BinaryShim); explicit "in NO case is the artifact absent"
3. Slice 8 note (line 125): removed PythonShim mention (PythonShim is now DESIGN-ONLY per commit 338a83fd3); reinforced "absent NOT a valid pass condition for the initial enum"

The "absent" pass condition is structurally impossible for the initial enum (YamlStatic + BinaryShim both target GH Actions). It's only conceivable for future DESIGN-ONLY runtimes that don't target GH Actions (e.g., InlineGunbc gunbc-as-runtime-orchestrator) — those land via separate substrate-prereq PR and would extend the gate at that time, NOT now.

The brief now consistently states:

• Gate (line 39): 2 pass options (full-emit | thin-shim); artifact NEVER absent
• §0 (line 17): consistent framing
• Slice 8 (line 125): consistent framing

P5 / Pure Bootstrap discipline correctly applied: dissolves AUTHORITY, not file presence.

Note on chatgpt-review-feb85484-e0f2-4d… reference: I don't have access to the cited prior chatgpt-review artifact, but the finding text itself is unambiguous and the fix matches the framing.

Awaiting openai-pro scheduled re-review at current HEAD 50f2314d3.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-thinking
• Commit: 50f2314d · Trigger: manual
• Comparison: main @ 34ffd22c ... docs/r3-t-wad-full-r3-close-scope @ 50f2314d
• Conversation: View conversation

---

1. Story of the diff

This PR is a docs/scope PR that upgrades T-Workflow-As-Data from a demonstration lane into a full R3-close work program. It adds a PM scope document plus two worker briefs: WI-1 asks for an emitter-dispatch design canvas, and WI-2 asks for a new dsl/gunbc/ci_emission.dag substrate scaffold. The load-bearing architectural move is the (c-refined) shape: WorkflowRuntime is modeled data passed as an invocation-time parameter to project_github_actions(CIWorkflowDag, WorkflowRuntime) -> Workflow, while dsl/extdeps/github/actions.dag::Workflow remains a platform carrier and dsl/gunbc/ci.dag::CIPipeline remains untouched because it lacks gate-dependency edges. The diff also tightens the migration plan around authority dissolution: .github/workflows/ci.yml remains present as an emitted artifact or thin shim, but it stops being hand-authored CI logic.

I read this as mostly a planning/substrate-brief alignment PR, not implementation. It adds the gates, dependency graph, STOP/PING rules, carrier-gap inventory, and worker acceptance criteria needed so downstream workers do not accidentally place CI-specific logic on GitHub Actions platform carriers or invent placeholder CIWorkflowDag values.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

Compliant — the diff explicitly keeps CI runtime choice out of the extdeps platform carrier: docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md:13 says dsl/extdeps/github/actions.dag::Workflow stays platform-faithful and unmodified, and docs/r3-t-workflow-as-data-full-r3-close-scope.md:32 states WorkflowRuntime lives in gunbc and Workflow remains unmodified. This honors the substrate/implementation separation: CI workflow projection belongs in gunbc substrate, while GitHub Actions carriers model platform facts.

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

Finding — NON-BLOCKING, doc consistency / P5 scaffold discipline. docs/r3-t-workflow-as-data-full-r3-close-scope.md:34 says: All OTHER ratified elements stand: variant names (YamlStatic | BinaryShim | PythonShim). That stale wording conflicts with the same diff’s repeated rule that PythonShim is design-only and not in the initial enum: docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:25 says the initial set is only YamlStatic, BinaryShim, and that PythonShim is held out until a real runtime consumer exists; docs/r3-t-workflow-as-data-full-r3-close-scope.md:40 repeats the 2-initial-arm gate. The intended P5 shape is otherwise good: scaffolds need named dissolution triggers and cannot become steady-state authorities. INVARIANTS P5 says scaffolds need dissolution paths, and Modeling Practice 4 requires yellow scaffolds to name a trigger. chatgpt-review-e66e027f-5774-4e…

chatgpt-review-c3667ba2-b46f-46…

Why it matters: a downstream worker scanning the rename paragraph could infer that PythonShim is already a ratified variant name rather than a design-only future target. The fix is small: change that parenthetical to YamlStatic | BinaryShim or explicitly say PythonShim is a reserved future DESIGN-ONLY name, not an initial variant.

1. CODING.md.

N/A — doc-only PR; no Rust implementation, helper placement, methods, error/result shapes, or production-code style surfaces changed.

1. TESTING.md.

Compliant — no tests are expected for this docs-only PR, and the diff’s testing commitments are at the right planning level: docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:107-109 requires a total-handling skeleton and no premature pinned binding; docs/r3-t-workflow-as-data-full-r3-close-scope.md:39 defines the ci_yml_hand_authority_dissolved regression guard as projection-output-to-artifact byte identity, not byte identity to the old hand-authored YAML. That matches the structural-test direction: tests should be derived from modeled claims, not hand-maintained behavior assertions. chatgpt-review-e020f6b6-e640-46…

1. LOCKED DESIGN DECISIONS.

Compliant — the diff treats the (c-refined) placement as locked and does not reopen it. docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md:9-16 says WorkflowRuntime is an invocation-time parameter, not a carrier field, and marks the field-on-Workflow and field-on-CIPipeline alternatives as retracted/superseded. docs/r3-t-workflow-as-data-full-r3-close-scope.md:54 likewise frames §2 as locked.

1. TRACKED vs UNTRACKED DEBT.

Compliant with one comment captured above — the main scaffold is tracked: WorkflowRuntime starts as a yellow scaffold with a named trigger and coordinate-dissolution sketch in docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:97-101. The pinned binding is also explicitly deferred with bounds and a named trigger: docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:46-48 says Slice 4 authors the canonical CIWorkflowDag instance and binding together. The only cleanup is the stale PythonShim mention in the rename paragraph.

2.5. Top-down PM intent review

Finding — NON-BLOCKING, same issue as above. The highest-level intent here is clear: all CI workflow logic becomes .dag-authored modeled data; the current ci.yml loses hand-authored authority; workflow runtime selection is modeled data; and future runtime arms only land with real consumers. That direction aligns with the thesis’s meta-process modeling and cost-of-change claims: build/CI process should be modeled as .dag workflows, and editing a pipeline concept should stay at one .dag authority. chatgpt-review-e020f6b6-e640-46…

The diff mostly preserves that intent. The one semantic dilution risk is docs/r3-t-workflow-as-data-full-r3-close-scope.md:34, which lists PythonShim among “ratified” variant names. That conflicts with the intended execution contract at docs/r3-t-workflow-as-data-full-r3-close-scope.md:40, where PythonShim is design-only and lands only via a separate consumer-paired PR. I would not block the PR because the acceptance gates and worker briefs overwhelmingly say the right thing, but I would fix the paragraph before downstream workers quote it as authority.

3. Verdict

APPROVE_WITH_COMMENTS

The PR does the important architectural cleanup: projection-function placement, CIWorkflowDag as dependency-bearing input, no platform-carrier contamination, and authority-not-file dissolution for ci.yml. I found one stale PythonShim phrase that could confuse downstream execution, but it is localized and contradicted by the actual acceptance gates rather than being the dominant plan.

[briansrls]

Openai-pro APPROVE_WITH_COMMENTS #10118 on HEAD 50f2314d acknowledged; non-blocking finding addressed in commit 89a84583d (current HEAD).

The verdict was APPROVE_WITH_COMMENTS — the PR was substantively approved with one non-blocking improvement:

"docs/r3-t-workflow-as-data-full-r3-close-scope.md:34 lists PythonShim among 'ratified' variant names. That conflicts with the intended execution contract at docs/r3-t-workflow-as-data-full-r3-close-scope.md:40, where PythonShim is design-only and lands only via a separate consumer-paired PR."

Fix is small (in commit 89a84583d): line 34 now reads "initial-enum variant names (YamlStatic | BinaryShim); PythonShim is a reserved DESIGN-ONLY future name not in initial enum per INVARIANTS P5 — see §1 gate workflow_runtime_open_enum_landed". Removes the ambiguity for downstream workers.

Substantive merge-readiness state on HEAD 89a84583d:

• ✓ Claude NS-N receipt zero: bind the Step 0 canary baseline to an executed run on main #10117 APPROVE on e6d30235 (covered the prior 2 cascade commits; the line 34 fix is a 1-line clarification within the same iteration; claim-preservation under structural re-verification)
• ✓ Openai-pro MAIN-H: restore the generated-artifact heal job as a modeled workflow emission #10118 APPROVE_WITH_COMMENTS on 50f2314d (the only finding now addressed)
• ✗ Codex stale REQUEST_CHANGES (Install boundary: the planned/executed conjunct was x == x.clone(); give it a second producer #10005 on 80c56efb + See through nested patterns in the .dag exhaustiveness checker (13 sites surfaced, all closed) #10028 on 9013b4a4) — all findings from those stale heads addressed in cascade commits b2bc28110 / dd2922142 / f830b988f / 70a49acb3 / 011ddbc65 / d25a56ab4 / 338a83fd3 / e6d302352 / 50f2314d3 / 89a84583d; awaiting codex scheduled re-review at current HEAD

Per the operator-tier merge-bypass precedent (PR #2718): substantive 2/2 with openai-pro APPROVE_WITH_COMMENTS (openai-pro carries more weight per dashboard policy) + 0 substantive REQUEST_CHANGES at HEAD; codex stale is structural-stale-on-old-SHA not parser-lag. Will hold for codex re-eval at current HEAD before applying bypass — substantive criteria met but dashboard tally still shows codex REQUEST_CHANGES.

Awaiting next codex scheduled re-review.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-thinking
• Commit: 89a84583 · Trigger: manual
• Comparison: main @ 34ffd22c ... docs/r3-t-wad-full-r3-close-scope @ 89a84583
• Conversation: View conversation

---

1. Story of the diff

This PR is docs-only, adding a ratified FULL R3-close scope for T-Workflow-As-Data plus two worker briefs that turn that scope into dispatchable work. The core move is to elevate CI workflow modeling from “one .dag demo workflow exists” to “the real .github/workflows/ci.yml authority must dissolve into modeled workflow data,” while preserving the executable artifact needed by GitHub Actions (docs/r3-t-workflow-as-data-full-r3-close-scope.md:16-20, :39-44). The chosen mechanism is a (c-refined) projection shape: WorkflowRuntime is modeled as invocation-time data, and project_github_actions: (CIWorkflowDag, WorkflowRuntime) -> Workflow produces the platform carrier without adding CI-specific logic to dsl/extdeps/github/actions.dag (docs/r3-t-workflow-as-data-full-r3-close-scope.md:56-75). That shape is then split into WI-1’s design canvas brief and WI-2’s substrate-scaffold brief, with the risky pinned gunbc_ci_yml_workflow binding intentionally deferred until Slice 4 can author the canonical CIWorkflowDag instance and binding together (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:38-50).

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

Compliant — the diff is planning/substrate-scope documentation, not implementation code, and it explicitly keeps platform substrate separate from gunbc CI logic: WorkflowRuntime lives in dsl/gunbc/ci_emission.dag, while dsl/extdeps/github/actions.dag::Workflow remains platform-faithful and unmodified (docs/r3-t-workflow-as-data-full-r3-close-scope.md:73-81, docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md:11-18).

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

Compliant — P2/single-authority is handled by deferring the pinned projection binding rather than fabricating a placeholder CIWorkflowDag or converting from flat CIPipeline (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:46-48). Practice 4 / coproduct dissolution is also explicitly required for WorkflowRuntime: the brief demands a 🟡 YELLOW receipt, named dissolution trigger, and coordinate-dissolution sketch before the enum lands (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:100-106). This aligns with the uploaded modeling discipline’s requirement that scaffold coproducts have a named trigger. chatgpt-review-aff7412a-f659-47…

1. CODING.md.

N/A — no Rust implementation code, helper functions, APIs, methods, or error/result shapes are changed in the diff.

1. TESTING.md.

Compliant — no executable behavior is introduced in this PR, so no tests are required here; the worker briefs carry the verification obligations forward by requiring cargo test/clippy/fmt for WI-2 (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:109-111) and cargo/clippy/fmt cleanliness for WI-1 (docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md:60-67). The scope doc’s direction also preserves the project’s .dag-native / zero-residual testing trajectory rather than adding Rust test scaffolding. chatgpt-review-703235ba-b05a-47…

1. LOCKED DESIGN DECISIONS.

Compliant — the PR explicitly locks the (c-refined) substrate shape and prevents the worker from reopening earlier alternatives: field-on-Workflow is retracted, field-on-CIPipeline is superseded, and wrapper-node is superseded by the projection function (docs/r3-t-workflow-as-data-full-r3-close-scope.md:77-81; docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md:9-18). The type-name collision is also resolved by renaming EmissionTarget to WorkflowRuntime (docs/r3-t-workflow-as-data-full-r3-close-scope.md:34).

1. TRACKED vs UNTRACKED DEBT.

Compliant — the only obvious scaffolds are tracked: the WorkflowRuntime open enum is limited to two real consumer-paired arms while PythonShim and InlineGunbc are design-only until paired consumers exist (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:25, docs/briefs/r3-t-wad-full-r3-emitter-dispatch-canvas-worker.md:31-32); the per-arm projection bodies are TODO-marked but assigned to Slice 4-5 (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:35-36); and the carrier gaps are enumerated with Slice 4 substrate-prereq routing (docs/briefs/r3-t-wad-full-r3-cidag-scaffold-worker.md:184-198).

2.5. Top-down PM intent review

Compliant — the highest-level intent is to make workflow/CI self-modeling part of R3, not a demo-only side quest. The scope doc preserves that by adding full closure gates for CI hand-authority dissolution, WorkflowRuntime, project_github_actions, slow-test cost modeling, and affected-set selection (docs/r3-t-workflow-as-data-full-r3-close-scope.md:36-44). It also avoids semantic dilution: “dissolve hand authority” is clarified as not deleting .github/workflows/ci.yml, but making it either a byte-identical emitted artifact or a thin executable shim (docs/r3-t-workflow-as-data-full-r3-close-scope.md:17, :39). That is consistent with the uploaded thesis/Pure Bootstrap authority that workflow/process artifacts and tests should move toward .dag data with zero hand-maintained surface, not disappear as executable artifacts. chatgpt-review-9d305a24-ceff-40…

3. Verdict

APPROVE — I found no diff-cited invariant violation. The PR is careful about authority placement, explicitly tracks its scaffolds and dissolution triggers, and preserves the PM-level R3 intent without prematurely forcing placeholder substrate or parallel CI authority.

[briansrls]

Openai-pro #10123 APPROVE on current HEAD 89a84583 (parser-lag undercounts as unknown in dashboard tally).

Direct from artifact (/api/reviews/10123/artifacts/stdout.log):

"Verdict: APPROVE — I found no diff-cited invariant violation. The PR is careful about authority placement, explicitly tracks its scaffolds and dissolution triggers, and preserves the PM-level R3 intent without prematurely forcing placeholder substrate or parallel CI authority."

All 6 invariant categories evaluated as Compliant at HEAD 89a84583:

1. LAYER MODEL — Compliant
2. INVARIANTS.md + modeling-discipline.md — Compliant (P2 single-authority via pinned-binding deferral; Practice 4 / coproduct dissolution explicit)
3. CODING.md — N/A (docs-only)
4. TESTING.md — Compliant
5. LOCKED DESIGN DECISIONS — Compliant ((c-refined) shape locked; rename to WorkflowRuntime resolves SELF_HOSTING.md:609 collision)
6. TRACKED vs UNTRACKED DEBT — Compliant (PythonShim + InlineGunbc both DESIGN-ONLY; per-arm projection bodies TODO-marked to Slice 4-5)

The non-blocking finding from openai-pro #10118 (line 34 stale PythonShim mention) was addressed in commit 89a84583d and openai-pro #10123 confirms the fix.

Substantive merge-readiness state on HEAD 89a84583:

• ✓ Claude NS-N receipt zero: bind the Step 0 canary baseline to an executed run on main #10117 APPROVE on e6d30235 (2 cascade commits behind; subsequent commits are line-level clarifications)
• ✓ Openai-pro Session lease: a refusal is not a plan, so delete RefuseForeignOwner rather than answer for it #10123 APPROVE on exact HEAD 89a84583 (carries more weight per dashboard policy)
• ⏳ Cursor First append after the ledger split moves two files, not three: file the declared-return-vs-generic-instantiation class #10124 verdict=unknown at HEAD (parser-lag; pending classification)
• ✗ Codex stale REQUEST_CHANGES (Install boundary: the planned/executed conjunct was x == x.clone(); give it a second producer #10005 on 80c56efb + See through nested patterns in the .dag exhaustiveness checker (13 sites surfaced, all closed) #10028 on 9013b4a4) — all findings substantively addressed in cascade commits b2bc28110 → 89a84583d (10 commits); awaiting codex scheduled re-review at current HEAD
• ✓ Mergeable: MERGEABLE; CI: passing

Substantive 2/2 distinct approvers met (claude + openai-pro at HEAD; openai-pro carries-more-weight per policy). The codex stale REQUEST_CHANGES is the only remaining dashboard-tally blocker — structurally addressed but not yet re-evaluated.

Per operator-tier merge-bypass precedent (PR #2718): bypass requires (1) unanimous substantive ✓, (2) named operator directive ✓ (dashboard merge mandate), (3) parser-lag-only blocker — codex stale-on-old-SHA is structurally similar to parser-lag (substantively addressed; dashboard hasn't refreshed) but is the only remaining gap. Holding for codex scheduled re-review at HEAD before applying bypass — PM tier should not unilaterally bypass codex stale-REQUEST_CHANGES without Director/operator say-so on this borderline case.

— sent from deep-wolf-155

[briansrls]

Cursor #10124 APPROVE on current HEAD 89a84583 (parser-lag undercounts as unknown in dashboard tally).

Direct from artifact (/api/reviews/10124/artifacts/stdout.log):

"Findings: None. The diff only adds/updates planning artifacts ... There is no src/v3/ or other implementation surface, so INVARIANTS P5's per-PR hand-Rust receipt gate does not apply here. The written scope matches the pinned rubric where it matters: CI/runtime choice is modeled in gunbc (ci_emission.dag projection) not on actions.dag carriers (P1), pinned binding is deferred to avoid parallel CIWorkflowDag authority (P2), WorkflowRuntime carries an explicit Practice 4 scaffold receipt and named dissolution trigger ..., extra enum arms are held back until consumer-paired work lands (P5 / Pure Bootstrap intent), and the ci_yml_hand_authority_dissolved framing dissolves hand authority while keeping a GH Actions–discoverable artifact—consistent with THESIS / docs/design-pure-bootstrap-zero.md. Nothing in the diff contradicts CODING.md or TESTING.md (no code/tests). Verdict: APPROVE — Narrowly scoped documentation with explicit reconciliation of prior review threads; no invariant or thesis dilution visible in the changed lines."

Substantive merge-readiness state on HEAD 89a84583 — now 3/3 distinct APPROVE providers:

Reviewer	SHA	Verdict	Dashboard	Notes
Claude #10117	e6d30235	APPROVE	✓ approved	2 cascade commits behind HEAD; subsequent commits are line-level clarifications addressing openai-pro NON-BLOCKING + briansrls BLOCKING — no substantive shift
Openai-pro #10123	89a84583	APPROVE	⚠ parser-lag (unknown)	Exact HEAD; carries more weight per dashboard policy
Cursor #10124	89a84583	APPROVE	⚠ parser-lag (unknown)	Exact HEAD; "Findings: None"
Codex #10028	9013b4a4	REQUEST_CHANGES	✗ blocking	STALE 3+ hours / 10 commits; all findings substantively addressed in cascade b2bc28110 → 89a84583d

• ✓ ≥2 distinct api-review approvals: 3/3 substantive at near-HEAD (openai-pro + cursor at exact HEAD; claude near-HEAD)
• ✓ Mergeable: MERGEABLE
• ✓ CI: passing
• ✗ Codex stale REQUEST_CHANGES (3+ hours / 10 commits stale; substantively addressed)

Per operator-tier merge-bypass precedent (PR #2718): bypass requires (1) unanimous substantive ✓, (2) named operator directive ✓ (dashboard relay merge mandate), (3) parser-lag-only blocker — codex stale is structurally similar but not strict parser-lag (codex review was correct at old SHA; just hasn't re-evaluated). Borderline case.

PM disposition: holding the squash-merge. Conservative reading per standing instructions: "use that dashboard summary as the source of truth for review count, approvals, request-changes ... Once the summary shows ≥2 distinct approving providers, no REQUEST_CHANGES, and mergeable=CLEAN, squash-merge." Dashboard still shows codex REQUEST_CHANGES open. PM tier should not unilaterally bypass without explicit Director/operator directive on this stale-not-parser-lag class.

Operator/Director ask: this PR is substantively ready for merge — 3/3 APPROVE at HEAD, 0 substantive REQUEST_CHANGES, mergeable=CLEAN, CI green. If you want immediate merge despite codex stale, name the directive (e.g., comment "merge under stale-codex bypass" or run gh pr merge 2744 --squash --delete-branch directly). Otherwise standing by for codex scheduled re-review at current HEAD.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 89a84583 · Trigger: schedule
• Thinking: 341s wall

---

Non-blocking — Strengths

• docs/r3-t-workflow-as-data-full-r3-close-scope.md Classified as design/docs; the current scope preserves the thesis by making .dag the semantic authority and treating ci.yml as generated transport.

✅ No blocking concerns remain after the current diff resolves the prior substrate-fidelity, single-authority, and consumer-pairing issues.