DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path change-requests/cr-2026-170-companion-room-reads-v0_1.md

DUNIN7-M4 — CHANGE REQUEST

CR-2026-170 — B-8 slice one: the Companion can see all four rooms — v0.1

Version. v0.1 Date. 2026-08-05 Author. Claude.ai (drafting session). Approving: Marvin Percival. Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. No session executes a change request it drafted (§1). Target. /Users/dunin7/loomworks-engine at main bd60cec. One repository. No surface change. [EXECUTING SESSION: confirm; report if it has moved.] Baseline. Not green — one long-standing unrelated failure. The criterion is no new failure, against a set recorded at Step 0. Build-list item. B-8, change request D. Slice one of two — reads only; writes are slice two. CR number. CR-2026-170. Highest confirmed is CR-2026-169. [EXECUTING SESSION: verify; advance if taken.] Grounding. inspection-briefs/loomworks-b8-step-0-findings-v0_1; scoping-notes/loomworks-b8-scoping-note-v0_2; standing-notes/loomworks-standing-note-skill-method-vocabulary-v0_6 for the vocabulary authority. Status. Pre-execution.


1. What this fixes

The Companion has full run of Memory and almost nothing of the other three rooms. No access at all to Manifestation. Counts on Shaping — how many things are waiting, never what they are. A narrow list of finished artifacts on Rendering.

And it cannot name three of the four rooms. Its vocabulary has words for things — a note, an artifact, a draft — and none for the places.

This slice fixes both, and only for reading. After it, the Companion can say what is in every room and discuss it. It still cannot change anything in three of them — that is slice two, and each write needs its authority answered on its own terms.


2. Construction decisions

D-1 — the room names become sayable. Operator decision, 2026-08-05.

The Companion's persona forbids manifestation, shape and render among a list of engine vocabulary. The Operator has settled that the engine's names are fine as the default, on the reasoning that the vocabulary is customizable per method — so the default fill matching the engine costs nothing, and a method wanting different words supplies them.

Remove manifestation, shape and render from the forbidden list.

What stays forbidden, and why the distinction is real:

> Why this is a settlement rather than a change of position. standing-notes/loomworks-standing-note-skill-method-vocabulary-v0_6 §6.2 establishes that a method fills the vocabulary wall for its domain — the coaching method makes session / client / intake the surface words; the litigation method makes matter / privilege / production the surface words. §7 settles that the engagement speaks in one voice the Operator governs. The persona's word list is the default method's fill, and the Operator has just set it.

D-2 — reads only. Writes are slice two, and the separation is not arbitrary.

Reading changes nothing, so it raises no authority question. Every write does, and each raises a different one — deriving a Manifestation supersedes a prior reading; asking for a draft routes through a delegation layer that currently dead-ends for these capabilities.

Slice one is therefore mostly wiring — the engine already serves everything, the same finding every room's build produced.

D-3 — the confirm stays where it is, in both slices.

Confirming a Shape enqueues production of renders elsewhere, and the Shaping room's own build made its control name what it will produce before it is pressed. A sentence cannot carry that property. Confirm the thing and confirm the thing, and here is what will be made are different acts, and only the second is an Operator approving something.

Not in this slice, and named as not belonging in slice two either.

D-4 — the safety property is made deliberate, not inherited.

A vaguely-worded request cannot reach any write today: it falls through to ordinary conversation, and that path never enters a write handler. That is structural.

But the findings are explicit that it holds by absence: the wiring for the sharpest case was never built — which is a different finding than the wiring being safe.

This slice adds reads only, so it cannot break the property — but the change request records it as a property to hold on purpose, and slice two inherits the obligation to demonstrate it rather than assume it.

D-5 — sources do not generalize by themselves, and this slice does not make them.

An answer's citations are facts rather than model claims for one intent only, hard-coupled to one key. Four other retrieval-backed answers already carry no sources.

A new room-read answer would carry none. Generalising that channel is a real decision — either the system attaches what it retrieved whatever the intent, or some answers are checkable and others are not with nothing telling a reader which. It is not this change request's, and building it in passing would settle by accident something worth settling deliberately.

[EXECUTING SESSION: record in the implementation notes which of this slice's new answers carry sources and which do not, so the inconsistency is visible rather than discovered later.]

D-6 — the reads go through the same door everything else does.

The whole conversation sits behind one membership check at its entry point, and the room endpoints' own gates are not in its path — the Companion queries beneath them.

New reads stay behind that one gate, following the pattern the Memory reads already use. Do not mix: a read calling a room's HTTP route inherits that route's gate; a read querying beneath it inherits the conversation's. Both work; using both without saying which is how a gap appears.


3. In scope

3.1 The persona's vocabulary, per D-1. Three words removed from one list.

3.2 Manifestation reads. The Companion can say what manifestations exist and describe the current one. The engine's routes already exist.

3.3 Shaping reads with content, not just counts. What is waiting, and what it actually is.

3.4 Rendering reads with content. Extending what already exists beyond the narrow finished-artifact listing.

3.5 The classifier's intents, so requests about these rooms route somewhere rather than falling through to ordinary conversation. [EXECUTING SESSION: report how many intents this adds and their names before writing them.]


4. Out of scope


5. Order of operations

Step 0 begins by creating the branch. Then pre-flight: verify HEAD, tree, CR number, and record the baseline failure set by name. Re-confirm the findings' anchors. Report the intent count at §3.5 before writing any.

Step 1 — the persona, D-1. Three words.

Step 2 — Manifestation reads.

Step 3 — Shaping reads.

Step 4 — Rendering reads.

Step 5 — tests. One per new read, plus a test that fails if any of the new intents can reach a write — D-4's property, made a check rather than a consequence of the wiring not existing. Assert specific conditions, never a bare exception.

CHECKPOINT A — report, then proceed. Baseline comparison; the intent list; the tests; and a live pass showing the Companion answering about each of the three rooms by name. [EXECUTING SESSION: model calls authorized here, at the minimum that demonstrates it. Report the count.] No Operator confirmation. Halt and queue on: any new failure; any new intent able to reach a write; any charter §6 anomaly.

Step 6 — implementation notes, carrying the intent list and D-5's sources inventory.

CHECKPOINT B — merge and tag. --no-ff to main, tag companion-room-reads-v0_1, push. Authorized under R-2 including the push. The engine gates on push — report the first run's outcome.

Deployment is never autonomous (F-1).


6. Acceptance gate

  1. No new failure against the Step 0 baseline set.
  2. The Companion can name the Manifestation, Shaping and Rendering rooms, and engagement remains forbidden with project in its place.
  3. It can describe the contents of each of the three rooms, not merely count them.
  4. No new intent can reach any write, and a test enforces it.
  5. Every new read sits behind the conversation's existing membership gate, per D-6.
  6. The Shaping confirm is not reachable, and remains unreachable.
  7. Implementation notes record which new answers carry sources and which do not.
  8. No surface change. No write added in any room.
  9. The status brief is appended, per charter §7.

7. Claude Code kickoff


CR-2026-170 — B-8 slice one, the Companion can see all four rooms.
Execution session.

CR: loomworks-record/change-requests/cr-2026-170-companion-room-reads-v0_1.md
Confirm it exists, and that it is the highest version present — numeric sort.

Grounding, read before the CR:
  inspection-briefs/loomworks-b8-step-0-findings-v0_1.md
  scoping-notes/loomworks-b8-scoping-note-v0_2.md

Charter dunin7-standing-authorization-charter-v0_1 governs.
Read the CR in full. It is the authority on what changes, where and why; this
block repeats none of it. Where this block and the CR appear to differ, the CR
is right and you halt rather than choosing.

  Section 2 — the construction decisions and their reasoning
  Section 3 — what changes
  Section 4 — what is out of scope
  Section 5 — the step sequence and both checkpoints
  Section 6 — the acceptance gate

ONE REPOSITORY — the CR's header names the target. No surface change.

READS ONLY. If a change appears to need a write in Manifestation, Shaping or
Rendering, halt — that is slice two and it is not authorized here.

Model calls are authorized for the live pass at Checkpoint A only, at the
minimum that demonstrates the behaviour. Report the count.

Standing fences, true regardless of this CR:
  Step 0 begins by creating the branch.
  playground_dev and playground_test are live databases and are not touched.
  If a database is needed, use a throwaway, dropped after.
  Deployment is never yours.
  Append the outcome to current-status/dunin7-status-brief at close.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-170 — B-8 slice one: the Companion can see all four rooms — v0.1 — 2026-08-05 Three words come off a list, and the Companion can finally talk about three quarters of the system.