Version. 0.1
Date. 2026-05-08
Provenance. Claude.ai, responding to a pre-kickoff review of phase-49-cr-companion-intelligence-v0_1.md (CC, 2026-05-08; 1,116 lines). Operator: Marvin Percival.
Purpose. Specifies the changes CC should apply to produce CR v0.2 before kickoff. Three tightenings, none structural — each prevents a specific drift failure mode the v0.1 framing leaves implicit. Operator chose path (B) — amend before kickoff — over path (A) — kickoff as-is and absorb at Checkpoint A.
Status. For CC consumption. Three tightenings (T1, T2, T3). All edits are paragraph-level additions or replacements. No build-step changes; no test-count changes; no decision changes. CC re-archives the CR at v0.2 before Step 1 begins.
CR v0.1 P49-D15 reads: "Voice-quality acceptance criteria: structural at CR §16; qualitative through Operator iteration." §15.1 reinforces: "Voice content quality is materially below the Operator's bar at first iteration. This is not a halt trigger — voice quality emerges through Operator iteration per P49-D15. CC ships first-draft voice content; Operator refines after wire-up."
The structural-vs-qualitative split is solid. What's missing is the explicit guard that Operator voice iteration after Phase 49 closes is ongoing Operator work, not Phase 49 amendments. Without this guard, voice tuning that lands in alpha could get framed as Phase 49 amendments — re-opening the phase boundary repeatedly, blurring the Phase 49 → Phase 50 seam, and creating amendment-fatigue.
The risk is methodologically specific to Phase 49 because this is the first phase shipping voice content as a first-class artifact (per CR §15.2's "the voice content section is novel for Phase 49 — Phase 47 / 48 didn't ship voice content"). Subsequent voice phases inherit the framing established here.
Replace P49-D15's right-hand cell with:
> CR §16 acceptance gates verify "the voice fires"; quality emerges through Operator iteration on item 6 + voice tuning, recorded in implementation notes at Checkpoint B. Iteration that lands after Phase 49 tag is ongoing Operator work, not a Phase 49 amendment trigger. Voice content authored during the build is the as-shipped baseline; subsequent refinement has its own discipline (likely a methodology consolidation pass when persona has emerged across enough surfaces).
Append to §15.1's voice-quality bullet:
> Operator iteration that lands after the Phase 49 tag is not a Phase 49 amendment — it's ongoing voice work outside the phase boundary. The Phase 49 tag captures the as-shipped voice baseline; later refinement is its own track. This framing matches the persona-emergence pattern from companion expertise note v0.1 §6 and applies to all future voice-shipping phases.
CR v0.1 §3 pre-flight item 1 (substrate baseline) carries the Phase 48 §15 §3 lesson exemplary: "If main has advanced since 2026-05-08, CC reports the current numbers and the CR's expected post-CR figures shift accordingly." The staleness lesson was originally a frontend lesson — Phase 48's CR cited 63/18/7 vitest/files/routes from 2026-05-07; live state at Step 0 was 71/19/6 (four commits past phase-46-operator-layer-frontend had landed in the interim). Final 100/24/10 was computed against the live baseline.
CR v0.1 item 12 (Operator Layer baseline) does not carry parallel "if main has advanced" language. Just [CC verifies] plus 100/24/10. This is exactly the asymmetry that produced the original lesson.
CC will likely re-derive naturally given Phase 48's history, but the CR text doesn't explicitly invite it. With the Operator Layer being the more active repo for surface work, the protection should be strongest there, not weakest.
Replace item 12 with:
> 12. Operator Layer baseline. [CC verifies] baseline state in DUNIN7/loomworks: 100 vitest tests, 24 files, 10 prerendered routes, eslint/tsc/build clean. Tag phase-48-credit-completion-and-operator-signin at e060fd7. If main has advanced since 2026-05-08, CC reports the current numbers and the CR's expected post-CR figures (~128 vitest, +~28) shift accordingly against the live baseline, not against the CR's snapshot. This mirrors item 1's discipline; the frontend staleness lesson originated in Phase 48 §15 §3 (CR cited 63/18/7; live was 71/19/6 because four commits had landed in the interim).
CR v0.1 §15.2 generically says implementation notes capture "determinations made during construction". CR v0.1 §17 enumerates ten carry-forward items for Phase 50 — all build-shaped (items 2/3/8 + items 10/12 + cross-Operator stewardship + persona-prompt + Phase 45 OVA-spec watch-this + item 6 spillover + voice tuning).
Missing: an explicit hook for methodology-level findings to record at Phase 49 close. Phase 49 surfaces four findings worth carrying upward to the next manifest consolidation, distinct from build carry-forward:
loomworks-closed-loop-engagement-investigation-v0_1.md).loomworks-upload-pathway-investigation-v0_1.md §7.4).These are knowledge artifacts, not build carry-forward. They land in implementation notes during construction and feed the next manifest update / methodology consolidation pass. The framework supports recording them; pre-listing ensures they don't get missed.
Append to §15.2 after the "voice content section is novel" paragraph:
> Methodology-level findings to record alongside build determinations. Phase 49 surfaces four findings that carry upward to the next manifest consolidation pass, distinct from build carry-forward:
>
> 1. AI-invisibility credit-system carve-out as a bounded named exception (per P49-D4; scoping v0.3 §4.1, §7.3). Methodologically: invisibility holds in normal Companion operation; credit-system surfaces are named exceptions because credits are model-identified and user decisions are model-tied. The next manifest update should record this as a class of legitimate exception rather than letting the principle silently erode.
> 2. First post-bootstrap specification-grammar extension (per P49-D10; scoping v0.3 §3.6; Step 0 §8.8). Methodologically: DeclaredShapeTypes/RenderTypes are MemoryObjects, not seed-resident — an engagement's specification grammar evolves through Memory contributions, not at seed-creation time only. Consistent with manifest §2 "rooms as facets of the event log" principle. Phase 49 exercises the pattern at the substrate level via a bootstrap-idempotent function; in mature operation, an engagement Operator could propose new declared types through their Companion via the elevation pathway.
> 3. First closed-loop application class build instance (per scoping v0.3 §3.4; cites loomworks-closed-loop-engagement-investigation-v0_1.md). Methodologically: the Accounting Engagement consumes its own observations and Renders are action; this is the closed-loop class's first production exercise. Phase 50's item 2 (Companion-as-Authority for grants) is the first delivery-class instance of the same proposer/committer pattern.
> 4. Phase 38 declare-and-register pattern parallel (per loomworks-upload-pathway-investigation-v0_1.md §7.4). Methodologically: the same declare-grammar / register-specialists / engine-matches-at-runtime pattern applies at multiple layers — engagement specification grammar (Phase 49 item 9) and upload pathway transformation skills (queued direction) being two surfacings. Worth naming so future surfacings of the pattern are recognized rather than re-invented.
>
> Recording at Checkpoint A (or Checkpoint B if the finding lands during frontend work). The implementation notes are the bridge from Phase 49 build determinations to manifest v0.35 absorption.
Append a new line to §17 carry-forward as item 11:
> 11. Methodology-level findings recorded for next manifest consolidation pass. Per §15.2, four findings: AI-invisibility credit-system carve-out; first post-bootstrap specification-grammar extension; first closed-loop application class build instance; Phase 38 declare-and-register pattern parallel across engagement specification grammar and upload pathway transformation skills. These are knowledge artifacts feeding manifest v0.35, not build carry-forward.
phase-49-cr-companion-intelligence-v0_2.md. All three are paragraph-level additions or replacements.docs/phase-crs/.The four updates are mechanical. No build-step changes; no test-count changes; no decision changes; no halt-condition changes; no architectural changes. The amendment is exactly what scoping note v0.3 §6 step 9–13 reserved-buffer slots are for at the CR layer rather than the build layer — clarity tightening before execution begins.
The pre-kickoff review surfaced four soft misses (T1, T2, T3 here, plus a fourth on reserved-slot buffer language at §15). The fourth was judged acceptable: §15's slots show as _(reserved — buffer for amendments arising from steps 1–9)_ and _(reserved — buffer)_, which is reserved-not-skipped in shape; the explicit "unconsumed if no amendment arises, not skipped" principle is in scoping v0.3 §6 (which CC reads). No CR text change needed.
The kickoff prompt at §18 was also reviewed and judged solid — points at CR archive, names Step 0, carries baseline, names halt conditions, reaffirms P49-D15, points at impl notes, specifies tag. After T1/T2/T3 land in v0.2 and the §18 path reference updates to v0.2, the prompt is kickoff-ready.
DUNIN7 — Done In Seven LLC — Miami, Florida Phase 49 CR Amendment for v0.2 — v0.1 — 2026-05-08