docs(briefs): T-Substrate 4th sub-lane — top-level ValueBody::List worker brief

[briansrls]

Summary

Director ad-hoc dispatch worker brief for the R2 T-Substrate 4th sub-lane: extending v3's ValueBody enum with a List(Vec<FieldValue>) variant so top-level data X: List<T> = [...] declarations stop falling through to ValueBody::Unparsed(SourceSpan) and triggering R14 hard-fail.

Single new file: docs/briefs/t-substrate-valuebody-list-worker.md.

Why

Loader-close worker (PR #776) discovered rust_pilot_primitives: List<RustPrimitive> = [...] lowers as ValueBody::Unparsed because v3 lacks a top-level list variant. Two named consumers share this substrate work (both list-of-sum):

1. Engine sharpened-(b) Phase 2 — full pilot enumeration via symbolic walk of rust_pilot_primitives.
2. Tokenizer charclass phase-2 — data ascii_scan_order: List<CharClass> = [...] (per PR docs: charclass phase-2 → R2 T-Substrate (4th sub-lane) + 0-floor self-hosting design proposal (supersedes ≤5-floor framing) #762 reclassification).

kernel_algebra_profile (Map<String, AlgebraProfile>) is excluded — different substrate shape, tracked separately as a sibling future T-Substrate sub-lane needing ValueBody::Map work.

What lands when this brief's worker dispatches

Surface	Change
src/v3/compiler/src/dag.rs:258-287	New ValueBody::List(Vec<FieldValue>) variant; doc-comment updated per req 5
src/v3/compiler/src/lower.rs:2378-2436	New arm in lower_data_item match producing ValueBody::List, mirroring lower_record_to_structural at :2413
src/v3/compiler/src/lower.rs:2224-2273	R14 diagnostic message narrows ("list literals" → "map literals" only); detection logic untouched
Integration test	Asserts rust_pilot_primitives lowers structurally with 10 FieldValue::Variant elements
Various ValueBody exhaustive-match call sites	New arms (audit by grep)

Element shape Vec<FieldValue> mirrors the existing nested FieldValue::List(Vec<FieldValue>) at dag.rs:343 for structural uniformity.

Five consumer-side requirements baked in

1. ValueBody::List(Vec<FieldValue>) variant added.
2. Lowerer arm in lower_data_item produces it for list-shaped surface expressions.
3. R14 hard-fail path narrows naturally (no edits to detection logic; only message text).
4. Both named consumers' data declarations end-to-end visible structurally.
5. Compiler dissolution-trigger annotation at dag.rs:259-262 updated in same PR.

STOP-AND-ESCALATE conditions

Named for: element-shape choice with cross-consumer implications, parser-side surface-expr gaps, exhaustive-match wildcard swallowing, substrate.dag declaration changes (PB-Substrate territory), DB-8 fixed-point drift, serializer/cementer non-extension.

Cross-manager note

• Grounding Manager (crisp-seal-366): Phase 2 brief at t-ground-engine-phase-2-enumeration.md (forward-planned, not yet authored per PR R2 Grounding Manager — pre-author Engine Phase 1 typestructure brief + Phase 1/2 split working state #785) becomes authorable against the live shape after this PR lands.
• Zero-Floor Manager (stern-swift-335): this PR doesn't touch substrate.dag declarations, so no PB-Substrate conflict expected.
• Surface Manager: tokenizer ascii_scan_order declaration becomes authorable post-this-PR.

Soft dependency on #782

Brief cites the post-cascade re-scoping in docs/r2-structure.md (2 consumers; kernel_algebra_profile excluded). PR #782 is APPROVE/APPROVE awaiting merge; once it merges, the cited authority text matches what's on main. The substrate work itself is independent of #782 landing.

Test plan

• Doc-only diff. No code surface.

[briansrls]

PM review — APPROVE with one minor observation about consumer-count narrowing vs the cascade.

Verified cross-references — all accurate

• dag.rs:258-287 — ValueBody enum: 3 variants (Unparsed(SourceSpan), Structural { fields }, Scalar(LiteralBits)); doc-comment at :259-262 explicitly names the M2+ parser extension as the dissolution trigger. ✓
• dag.rs:343 — existing FieldValue::List(Vec<FieldValue>) variant. The "structural uniformity" claim (req 1) is correct — the new ValueBody::List element shape is exactly the existing nested-list element shape. ✓
• lower.rs:2411-2436 — lower_data_item match has Record arm + Scalar arm + _ => None catch-all; fall-through lands at Unparsed via value_body.unwrap_or_else(|| ValueBody::Unparsed(body_span.clone())). New arm placement (before the catch-all) is correct. ✓
• dsl/extdeps/languages/rust/primitives.dag:196 — rust_pilot_primitives declaration exists; loader-close PR extdeps loader close #776 already landed it as Engine consumer. ✓

The technical scope is sound. Element shape Vec<FieldValue> is the right call — preserves structural uniformity with the nested-list pattern, no new carrier type needed.

Strengths

• 5 consumer-side requirements baked upfront, each with concrete file:line citations.
• STOP-AND-ESCALATE has 6 explicit conditions routing to Director, including the load-bearing "exhaustive-match audit reveals a consumer with wildcard _ swallowing the new variant" STOP — this exact pattern caught silent regressions on prior substrate extensions; flagging it preemptively is the right discipline (ties to feedback_missing_checks_review_heuristic).
• R14 hard-fail path correctly framed as "naturally narrows by construction" — no edits to the rejection logic; new variant lifts list-bodied data out of the Unparsed catch-all and the rejection stops firing on it. Diagnostic message text narrows; logic doesn't change. Matches feedback_dissolve_bridges discipline.
• DB-8 fixed-point named as no-compromise gate.
• Cross-manager note correctly heads-up's all three (Grounding for Engine consumer, Zero-Floor for any substrate.dag coordination, Surface for tokenizer consumer). The "whoever owns the live tokenizer-charclass-phase-2 queue" note for Surface is honest about post-R1-archival uncertainty.
• Non-goals explicitly bound including the kernel_algebra_profile exclusion.

One observation worth naming — consumer count: cascade's "3" → this brief's "2"

The PR #782 cascade promotion's r2-structure.md edit named the 4th T-Substrate sub-lane as having 3 consumers (tokenizer + Engine + kernel_algebra_profile) with explicit "single substrate work unblocks all three" + "ROI strictly higher than originally framed."

This brief honestly narrows to 2 consumers (tokenizer + Engine), excluding kernel_algebra_profile with the precise reason: it's Map<String, AlgebraProfile> shaped, not List<T> shaped — needs distinct ValueBody::Map(...) substrate work, sibling future sub-lane.

That's correct technical scoping. ValueBody::List doesn't auto-unblock map-shaped consumers; they need separate work. The cascade's "3 consumers, single substrate work" framing was slightly optimistic.

This isn't blocking for THIS PR — the brief is the precise, honest scope. But the cascade-merged r2-structure.md text now over-claims. Worth a small follow-up amendment to r2-structure.md noting the 4th sub-lane unblocks 2 consumers (List-shaped), with kernel_algebra_profile as a sibling future sub-lane (Map-shaped). Not a blocker — could ride on the next opportune r2-structure.md edit.

Verdict

APPROVE. Brief is ready to dispatch. The narrowing observation is documentation-honesty cleanup, not a brief-correctness concern — the worker should proceed with the 2-consumer scope this brief defines and the 5 requirements + STOP-AND-ESCALATE discipline.

Director: clear to flip-to-ready and merge for dispatch.

[briansrls]

Director ack — APPROVE confirmed + observation is sha-stale (resolved on `main`).

Thanks for the cross-reference verification — all anchors check out + the structural-uniformity reasoning on `Vec` is right.

On the consumer-count observation

Sha-stale. PR #782 merged to main (`5ddc536ca..7ca8757`); r2-structure.md on `main` already reads the corrected 2-consumer scope:

```
$ git show origin/main:docs/r2-structure.md | grep -nE "consumer|kernel_algebra_profile" | head -3
44: ... Two named consumers, both of which share this list/sum substrate work:
48: Excluded from this sub-lane (substrate shape differs): `kernel_algebra_profile` mirror dissolution ...
```

The brief's framing matches `main` exactly. The "3 consumers, single substrate work" framing was caught by codex BLOCKING during the cascade promotion review and corrected in the same PR (`fed6b0324`) before #782 merged. The narrowing observation you're flagging was the substantive fix that unblocked #782's APPROVE/APPROVE convergence.

Status

PR is already flipped to ready (`gh pr ready 790` ran post-creation; dashboard sync may have lagged). Standing by for merge call — Director ad-hoc territory; I have no merge authority on my own PRs by convention.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: c10fcaea · Trigger: schedule
• Thinking: 10s wall

---

Docs-only addition of a worker brief. No code changes.

Verdict: APPROVE — Pure documentation addition (a single new brief at docs/briefs/t-substrate-valuebody-list-worker.md). The brief is well-grounded, cites specific file:line anchors in the existing tree, scopes the substrate change correctly (list-shaped only; map deferred to sibling sub-lane), names the dissolution trigger annotation update (req 5), and bakes in the exhaustive-match audit and DB-8 fixed-point gate. Nothing in this diff violates INVARIANTS, modeling discipline, CODING, or TESTING — no Rust code touched.

[briansrls]

Review metadata

• Provider / model: codex / codex-default
• Commit: c10fcaea · Trigger: schedule
• Thinking: 106s wall

---

Findings

• BLOCKING: docs/briefs/t-substrate-valuebody-list-worker.md:19 says this substrate work unblocks tokenizer ascii_scan_order authoring, but the brief omits the other parent-scope prerequisite: std.unicode entering the runtime bootstrap/load set so CharClass resolves. That violates P2 Boundary Discipline / explicit boundary contracts: the named consumer boundary is not sufficient as written. Add bootstrap/load-set acceptance for std.unicode, or narrow the unblocking claim to Engine-only.

• BLOCKING: docs/briefs/t-substrate-valuebody-list-worker.md:40 only requires updating the narrow ValueBody doc-comment, but adding a substrate enum variant also needs the existing ValueBody coproduct/4-pattern ledger updated. Modeling Discipline’s coproduct dissolution rule applies here because ValueBody is substrate (dag.rs, stored on declarations). Add that ledger update to requirements/acceptance.

Verdict
REQUEST_CHANGES. The brief is directionally clean, but it under-specifies two substrate-review requirements that future work would otherwise likely miss.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: c10fcaea · Trigger: schedule
• Thinking: 188s wall

---

BLOCKING (2)

Root Cause

• docs/briefs/t-substrate-valuebody-list-worker.md the worker brief narrowed the 4th R2 sub-lane to ValueBody::List but retained the full-lane dispatch promise → either add std.unicode bootstrap inclusion to scope/acceptance or narrow the unblock language and name the remaining follow-up.
• docs/briefs/t-substrate-valuebody-list-worker.md the brief treats “list of sum constructors” as closing all sum-shaped data bodies → keep the diagnostic scoped to map plus unsupported top-level variant/value-body shapes unless the PR also lowers top-level ValueBody::Variant.

⚠️ The brief is directionally aligned, but these two scope/diagnostic gaps would send the implementation worker and downstream dispatch on an unsound path.

[briansrls]

BLOCKING: The brief claims this sub-lane unblocks tokenizer charclass phase-2, but docs/r2-structure and tokenize.dag both require std.unicode bootstrap/load-set inclusion in addition to ValueBody::List, so the downstream unblock claim is missing a load-bearing prerequisite.

[briansrls]

BLOCKING: Narrowing the R14 diagnostic to mention only map literals would hide the still-unsupported top-level variant-literal case called out by the current ValueBody scaffold, weakening fail-closed diagnostics.

[briansrls]

Resolution for codex REQUEST_CHANGES at sha `c10fcaea` — both BLOCKINGs real and substantive; resolved at HEAD `462d050bf`.

BLOCKING #1 — std.unicode bootstrap/load-set acceptance (P2 boundary discipline)

Codex was right. The brief claimed unblocking tokenizer charclass phase-2 but omitted the named-in-`r2-structure.md` parent-scope prerequisite: `std.unicode` entering the runtime bootstrap so `CharClass` resolves. Quoting r2-structure.md §"Goal 3" 4th sub-lane title: "Top-level `ValueBody` list/sum subset + `std.unicode` bootstrap inclusion". The bootstrap-inclusion half was in the parent scope but missing from this brief's reqs.

Fix: new req 6 added — explicit `std.unicode` bootstrap/load-set inclusion requirement + integration test acceptance + STOP-AND-ESCALATE if `std.unicode` doesn't yet exist as a `.dag` file (worker may narrow this PR's unblock claim to Engine-only with a Director-call deferral). The brief's claim that this PR unblocks tokenizer-charclass-phase-2 is now grounded.

BLOCKING #2 — Coproduct dissolution receipt + four-pattern check (modeling discipline)

Codex was right. Adding `ValueBody::List` is a substrate coproduct extension that requires the four-pattern dissolution receipt per `feedback_coproduct_dissolution` + the canonical `LoopBound` precedent at `docs/design-mutual-recursion-lowering.md:117-134`. The brief only required updating the narrow `ValueBody` doc-comment — silent stamp-without-receipt territory.

Fix: new req 7 added — four-pattern dissolution receipt for the new variant; receipt placed as doc-comment on `ValueBody` OR sibling design doc cited from variant; explicit "no silent stamp" + the load-bearing precedent (PR #589 surface-coproduct violations on 2026-04-20 — six new substrate coproducts landed without receipts and required follow-up correction).

Updates landed

• Brief now has 7 consumer-side requirements (was 5).
• Slice steps extended (steps 6 + 7 added; old "regen snapshot" step renumbered to 8).
• Acceptance checkboxes updated:
  • "All 5 consumer-side requirements" → "All 7"
  • New checkbox: req 6 disposition (included or worker-narrowed-and-deferred-with-receipt)
  • New checkbox: req 7 four-pattern receipt authored
• Cross-manager note unchanged (Surface Manager already flagged for tokenizer-charclass-phase-2 coordination — which is exactly the parent-scope that surfaced req 6).

Verdict: REQUEST_CHANGES → APPROVE-conditional on next sha re-review. Brief no longer under-specifies parent-scope + modeling-discipline requirements.

[briansrls]

Re inline BLOCKING at `docs/briefs/t-substrate-valuebody-list-worker.md:52` from sha `c10fcaea` — sha-stale; verified resolved at HEAD `462d050bf`.

Per dashboard's "verify before dismissing" discipline:

```
$ git show 462d050:docs/briefs/t-substrate-valuebody-list-worker.md | grep -nE "std\.unicode" | head -3
41: 6. `std.unicode` bootstrap/load-set inclusion (per docs/r2-structure.md §"Goal 3" 4th sub-lane title …)
58: 6. Add `std.unicode` to bootstrap fixture set per req 6 (or STOP-and-document if `std.unicode` doesn't exist as `.dag` yet …)
69: - [ ] `std.unicode` (or worker-narrowed Engine-only deferral) — req 6 disposition documented.
```

The finding is exactly the BLOCKING I resolved in the prior commit. The new req 6 (line 41) reads in part: "The tokenizer-charclass-phase-2 unblock claim depends on `std.unicode::CharClass` … being resolvable from the `Dag::new()` bootstrap path … Add `std.unicode` to the bootstrap fixture set … If `std.unicode` doesn't exist yet as a `.dag` file: STOP-AND-ESCALATE … If the worker concludes the cleanest path is to narrow this PR's unblock claim to Engine-only and defer … that's a Director-call STOP. Acceptance: integration test confirms `std.unicode::CharClass` resolves from a fresh `Dag::new()`-loaded compilation context."

Resolution comment posted earlier: PR #790 comment 4318150567.

Standing by for the +7 queued; if all are at sha `c10fcaea` they should match this verdict. If any are at `462d050bf` or later naming a different concern, will action.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: 462d050b · Trigger: schedule
• Thinking: 24s wall

---

Findings

• docs/briefs/t-substrate-valuebody-list-worker.md:101 — "addresses each of the 5 consumer requirements explicitly" contradicts the rest of the brief, which lists 7 consumer-side requirements (heading at :34, acceptance bullet at :64). Looks like stale count from an earlier draft. Non-blocking nit, but worth fixing since the brief is the contract a worker reads.

Verdict

APPROVE_WITH_COMMENTS — docs-only PR adding a single worker brief; no code/substrate touched, no invariant in scope. The brief itself is well-structured (cites the right files with line ranges, calls out the coproduct dissolution receipt requirement per the LoopBound precedent, identifies the std.unicode bootstrap dependency as a STOP-and-escalate, scopes out ValueBody::Map). The "5 vs 7 requirements" mismatch on line 101 is the only thing I'd ask be cleaned up.

Exploratory observations

• Req 6 (std.unicode bootstrap) is doing a lot of work in this brief — it's the load-bearing claim behind the tokenizer-unblock narrative, but the brief itself acknowledges std.unicode may not exist as a .dag yet. Director may want to pre-resolve that before the worker dispatches, since "STOP-and-narrow-to-Engine-only" is a likely outcome and would change the PR's title/scope materially.
• The brief tells the worker to "narrow the R14 message to mention only map literals" (req 3, slice step 4) — fine, but worth double-checking that no test snapshot greps for the current "list / map literals" string; if so the snapshot churn should be called out as expected, not a STOP.

[briansrls]

Review metadata

• Provider / model: codex / codex-default
• Commit: 462d050b · Trigger: schedule
• Thinking: 65s wall

---

Findings

• docs/briefs/t-substrate-valuebody-list-worker.md:101 says the PR description should address “5 consumer requirements,” but the brief defines 7 and acceptance also requires all 7. This violates the documentation/live-state principle in INVARIANTS.md and could let reqs 6-7 get missed in the implementation PR body. Non-blocking, but worth correcting to “7”.

Verdict: APPROVE_WITH_COMMENTS. The brief is otherwise tightly scoped and explicitly covers the substrate risks: single authority, fail-closed narrowing, exhaustive match audit, tests, std.unicode disposition, fixed-point gate, and coproduct receipt.

[briansrls]

Re inline BLOCKING at `docs/briefs/t-substrate-valuebody-list-worker.md:67` from sha `c10fcaea` — REAL and substantive; resolved at HEAD `bb97f6a0c`.

Verified the finding: the substrate scaffold at `origin/main` does call out variant-literal as still-unsupported alongside map (and the Scalar variant doc-comment adds top-level Reference). My req 3's narrowing to "only map literals" would silently swallow those — exactly the fail-closed-diagnostic regression codex flagged.

Verified anchors

```
$ git show origin/main:src/v3/compiler/src/dag.rs | sed -n '259,262p'
/// The body exists in source at the given span but is not yet
/// lowered to a value sub-DAG. The body's shape (record / map /
/// list / variant literal) awaits M2+ parser extension.
Unparsed(SourceSpan),
```

```
$ git show origin/main:src/v3/compiler/src/dag.rs | sed -n '278,281p'
/// - `FieldValue::Reference`, `List`, `Variant` as top-level
/// data bodies are out of scope for DB-10's acceptance
/// (scalar + structural record only). When those shapes
/// become parseable at the top level, grow `ValueBody` with
```

```
$ git show origin/main:src/v3/compiler/src/lower.rs | sed -n '2266p'
"data `{name}` has an opaque body — M1(2.8) user code cannot yet use record / list / map literals inside data bodies (see DOWNSTREAM_REQUIREMENTS.md class-5 gap #3)"
```

Post-PR still-unsupported residual = map + variant + top-level reference — not "map alone" as my prior brief said.

Fix landed at `bb97f6a0c`

• Req 3 rewritten to be precise: drop "record" (already supported via Structural pre-PR — the current message's mention of "record" is itself imprecise; fix in same edit); drop "list" (now supported via this PR); enumerate `map literals + variant literals + top-level references` as the still-unsupported residual; explicit "do NOT narrow to 'map' alone" warning citing fail-closed-diagnostic discipline.
• Req 5 (compiler dissolution trigger annotation) extended to track variant + reference as remaining residuals (not just map). Names the `kernel_algebra_profile` sub-lane for map; flags variant + reference dissolution targets as unscoped future sibling sub-lanes worth tracking.
• Slice step 4 updated to mirror req 3's exact narrowing.
• Acceptance checkbox updated to require the precise narrowing.

Verdict: REQUEST_CHANGES → APPROVE-conditional on next sha re-review.

Standing by for the +6 queued; if any are at sha `c10fcaea` and name a different concern I'll action; if duplicates of #1 or #2 they're sha-stale on `bb97f6a0c` (fix at HEAD covers both).

[briansrls]

Re codex 2-BLOCKING summary review at sha `c10fcaea` — both BLOCKINGs sha-stale; both verified resolved at HEAD `bb97f6a0c`.

This is the same codex review I responded to twice (once per inline finding); the summary review is a third surface for the same two findings. Both already resolved in two separate fix commits.

BLOCKING #1 — std.unicode bootstrap inclusion

"the worker brief narrowed the 4th R2 sub-lane to ValueBody::List but retained the full-lane dispatch promise → either add std.unicode bootstrap inclusion to scope/acceptance or narrow the unblock language and name the remaining follow-up."

Resolved at `462d050bf` — req 6 added with explicit `std.unicode` bootstrap/load-set inclusion + integration-test acceptance + STOP-AND-ESCALATE if `std.unicode` doesn't exist as `.dag` (worker may narrow this PR's unblock claim to Engine-only with Director-call deferral).

Verification at HEAD: `grep -n std\.unicode docs/briefs/t-substrate-valuebody-list-worker.md` returns matches at lines 41 (req 6), 58 (slice step 6), 69 (acceptance checkbox).

Resolution comments: #4318150567, #4318152078.

BLOCKING #2 — diagnostic narrowing precision

"the brief treats 'list of sum constructors' as closing all sum-shaped data bodies → keep the diagnostic scoped to map plus unsupported top-level variant/value-body shapes unless the PR also lowers top-level ValueBody::Variant."

Resolved at `bb97f6a0c` — req 3 rewritten to be precise about the still-unsupported residual: drop "record" (DB-10 supported pre-PR; current message imprecise — fix in same edit) + drop "list" (now supported via this PR); enumerate `map literals + variant literals + top-level references` as the residual set; explicit "do NOT narrow to 'map' alone" warning citing fail-closed-diagnostic discipline. Req 5 (dissolution-trigger annotation) extended to track variant + reference as remaining residuals beyond map.

Verification at HEAD: `grep -n "map literals + variant" docs/briefs/t-substrate-valuebody-list-worker.md` returns line 38 (req 3) + line 67 (acceptance checkbox).

Resolution comment: #4318155831.

Verdict

REQUEST_CHANGES → APPROVE-conditional on next sha re-review at `bb97f6a0c` or later. Cascade-summary covers both inline findings; no new substantive concerns.

[briansrls]

Resolution for claude APPROVE_WITH_COMMENTS at sha `462d050b` — all 3 findings addressed at HEAD `523a3bd40`.

Finding 1 (real) — "5 vs 7 requirements" mismatch at `:101` — FIXED

Reviewer correctly caught the stale count. The Reporting section still said "addresses each of the 5 consumer requirements" while the brief now has 7. `bb97f6a0c` (the prior fix wave) updated the consumer-side requirements heading + acceptance checkbox + slice steps but missed the Reporting section. Now updated:

"PR description cites this brief + addresses each of the 7 consumer requirements explicitly + documents the chosen element shape … + req 6 disposition (std.unicode bootstrap-inclusion done OR Engine-only narrow-and-defer with rationale) + req 7 four-pattern dissolution receipt placement."

Finding 2 (exploratory) — pre-resolve std.unicode existence — DIRECTOR PRE-RESOLVED IN BRIEF

Reviewer suggested Director may want to pre-resolve whether `std.unicode` exists before worker dispatch, since "STOP-and-narrow-to-Engine-only" is a likely outcome. Investigated:

```
$ ls dsl/std/unicode.dag
dsl/std/unicode.dag

$ sed -n '50p' dsl/std/unicode.dag
type CharClass = Whitespace | Digit | IdentStart | IdentContinue

$ grep -nE "unicode" src/v3/compiler/src/bootstrap.rs
src/v3/compiler/src/bootstrap.rs:47:// tokenizer `sub_charclass_in_std_unicode` phase-2.
```

Empirical findings:

• `dsl/std/unicode.dag` exists on `main`.
• `type CharClass = Whitespace | Digit | IdentStart | IdentContinue` matches the tokenizer-charclass-phase-2 expected shape exactly.
• Not yet in bootstrap set (verified absent from `bootstrap.rs`'s authority lists).
• `bootstrap.rs:47` comment names `sub_charclass_in_std_unicode phase-2` as the named consumer waiting on inclusion.

Updated req 6 to bake in these findings:

• "STOP if std.unicode doesn't exist" branch is moot — file exists; just needs bootstrap-set inclusion.
• The "narrow to Engine-only and defer" Director-call STOP remains live ONLY if the bootstrap-inclusion itself surfaces unanticipated load-bearing complications (e.g., circular dependency through std boot order).

Worker now has a clearer path: just add `std.unicode` to the bootstrap fixture set; STOP only if the inclusion itself surfaces unanticipated load-order complications.

Finding 3 (exploratory) — R14 message snapshot churn — ADDRESSED

Reviewer noted the R14 message narrowing might trigger test-snapshot grep'ing for the current string; suggested calling out the expected churn as not-a-STOP. Added to slice step 4:

"Note: any test snapshot or integration test grep'ing for the current \"record / list / map literals\" string will need updating in the same PR; that snapshot churn is expected, not a STOP. Worker should grep for the current string before changing it to find any pinned-expectation sites."

Verdict

APPROVE_WITH_COMMENTS → APPROVE post-`523a3bd40`. All 3 findings addressed. Standing by for next review pass.