@north-light/crouter 0.3.208 → 0.3.209

package/dist/api/client.d.ts

@@ -1,6 +1,6 @@
 import type { DaemonRestartDTO, HealthDTO, StatusDTO } from './dto/health.js';
 import type { BashJobStatusDTO, BashJobStopResultDTO } from './dto/bash-jobs.js';
-import type { ArtifactListDTO, ArtifactsQuery, ContextListDTO, CreateNodeRequest, ListNodesQuery, NodeDetailDTO, NodeMessagesPageDTO, NodeMessagesQuery, NodeSessionDTO, NodeSnapshotDTO, NodeSummaryDTO, TranscriptDTO, TranscriptQuery } from './dto/nodes.js';
+import type { ArtifactListDTO, ArtifactsQuery, ContextListDTO, CreateNodeRequest, ListNodesQuery, NodeDetailDTO, NodeMessagesPageDTO, NodeMessagesQuery, NodeSessionDTO, NodeSnapshotDTO, NodeSubjectDTO, NodeSummaryDTO, TranscriptDTO, TranscriptQuery } from './dto/nodes.js';
 import type { InterruptResultDTO, MessageResultDTO, SendMessageRequest } from './dto/messages.js';
 import type { PushReportRequest, PushReportResultDTO, ReportDTO, ReportsQuery } from './dto/reports.js';
 import type { CloseRequest, CloseResultDTO, PromoteRequest, RelaunchRootResultDTO, ReviveRequest, ReviveResultDTO, WaitRequest, YieldRequest } from './dto/lifecycle.js';
@@ -143,6 +143,8 @@ export declare class CrtrClient {
     getReports(id: string, q?: ReportsQuery): Promise<ReportDTO[]>;
     getTranscript(id: string, q?: TranscriptQuery): Promise<TranscriptDTO>;
     getSnapshot(id: string): Promise<NodeSnapshotDTO>;
+    /** The node-config subject substrate gates evaluate against. */
+    nodeSubject(id: string): Promise<NodeSubjectDTO>;
     getNodeMessages(id: string, q?: NodeMessagesQuery): Promise<NodeMessagesPageDTO>;
     /** The node's conversation exactly as it ran — raw `.jsonl` bytes plus the
      *  assembled system prompt. For exports; `getSnapshot` is for renderers. */

package/dist/api/client.js

@@ -253,6 +253,10 @@ export class CrtrClient {
     getSnapshot(id) {
         return this.request('GET', routes.nodeSnapshot(this.nodePath(id)));
     }
+    /** The node-config subject substrate gates evaluate against. */
+    nodeSubject(id) {
+        return this.request('GET', routes.nodeSubject(this.nodePath(id)));
+    }
     getNodeMessages(id, q) {
         return this.request('GET', withQuery(routes.nodeMessages(this.nodePath(id)), q));
     }

package/dist/api/dto/broker-ops.d.ts

@@ -1,4 +1,5 @@
 import type { ExitIntentDTO, NodeStatusDTO } from './common.js';
+import type { NodeSubjectDTO } from './nodes.js';
 /** `POST /v1/nodes/{id}/broker/session-bound` body. Pi's session-start reason
  * distinguishes an ordinary boot/resume from `/new`, whose child-side session
  * reset is a different durable operation. `reviewBoundaryIds` reports only the
@@ -95,18 +96,7 @@ export interface BrokerExtensionNodeDTO {
     };
     created: string;
 }
-export interface BrokerExtensionSubjectDTO {
-    kind: string;
-    mode: 'base' | 'orchestrator';
-    lifecycle: 'terminal' | 'resident';
-    hasManager: boolean;
-    cwd: string;
-    scope: 'user' | 'project';
-    orchestration: {
-        depth: number;
-    };
-    profile: string | null;
-}
+export type BrokerExtensionSubjectDTO = NodeSubjectDTO;
 /** One resolved report sender. Report contents stay broker-local filesystem
  * data; this daemon projection supplies only existence and display metadata. */
 export interface BrokerReportNodeDTO {

package/dist/api/dto/nodes.d.ts

@@ -1,4 +1,20 @@
 import type { Cursor, ExitIntentDTO, IsoTime, LifecycleDTO, ModeDTO, NodeIdDTO, NodeStatusDTO } from './common.js';
+/** `GET /v1/nodes/{id}/subject` — the node-config subject substrate gate
+ *  predicates evaluate against. Mirrors `NodeConfigSubject`; this narrow
+ *  endpoint exists so a CLI process (the `memory read` leaf) can gate-check
+ *  docs without reaching canvas state. */
+export interface NodeSubjectDTO {
+    kind: string;
+    mode: ModeDTO;
+    lifecycle: LifecycleDTO;
+    hasManager: boolean;
+    cwd: string;
+    scope: 'user' | 'project';
+    orchestration: {
+        depth: number;
+    };
+    profile: string | null;
+}
 /** `POST /v1/nodes` body. Carries the full immediate spawn recipe. */
 export interface CreateNodeRequest {
     kind: string;

package/dist/api/routes.d.ts

@@ -9,6 +9,7 @@ export declare const routes: {
     readonly reviveAll: () => string;
     readonly node: (id: string) => string;
     readonly nodeSnapshot: (id: string) => string;
+    readonly nodeSubject: (id: string) => string;
     readonly nodeSession: (id: string) => string;
     readonly nodeTranscript: (id: string) => string;
     readonly nodeContext: (id: string) => string;

package/dist/api/routes.js

@@ -25,6 +25,7 @@ export const routes = {
     node: (id) => `${V}/nodes/${id}`,
     // Node reads
     nodeSnapshot: (id) => `${V}/nodes/${id}/snapshot`,
+    nodeSubject: (id) => `${V}/nodes/${id}/subject`,
     nodeSession: (id) => `${V}/nodes/${id}/session`,
     nodeTranscript: (id) => `${V}/nodes/${id}/transcript`,
     nodeContext: (id) => `${V}/nodes/${id}/context`,

package/dist/builtin-memory/00-runtime-base.md

@@ -1,8 +1,6 @@
 ---
 kind: preference
 when-and-why-to-read: When any node boots, this preference should be read so the node can participate safely in the live graph without losing work, user decisions, or the ability to resume.
-system-prompt-visibility: content
-file-read-visibility: none
 rationale: >-
   The living-document paragraph under "Reports vs artifacts" exists because agents default to appending — plans kept old+new versions side by side, answered Q&A sections stayed behind after the answer was folded in, findings docs grew contradicted layers (observed by Silas, 2026-07-08). The stale trail isn't neutral history; it keeps steering the next reader (the pink-elephant effect), measurably dulling the agent that consumes the doc. Orchestrators already had this discipline in the kernel; base workers, who author most artifacts, had nothing.
 
@@ -12,6 +10,9 @@ rationale: >-
 
   The Mermaid line exists because the viewer's inline diagram affordance is otherwise invisible to an agent working from ordinary Markdown defaults.
 lint-ignore: length
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a **node** in a live agent graph (the crtr canvas). This section is your operating protocol — it is true for every node regardless of role.

package/dist/builtin-memory/01-spine/00-has-manager.md

@@ -1,9 +1,10 @@
 ---
 kind: preference
 when-and-why-to-read: When a node has a parent subscribed to it, this preference should be read so progress, blockers, and scope changes actually reach the manager at the right urgency.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {hasManager: true}
+surfaces:
+  - on: boot
+    at: content
 ---
 
 ## Reporting up (the feed)

package/dist/builtin-memory/01-spine/01-no-manager.md

@@ -1,9 +1,10 @@
 ---
 kind: preference
 when-and-why-to-read: When a node has no parent, this preference should be read so its results reach the user instead of disappearing into a nonexistent manager feed.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {hasManager: false}
+surfaces:
+  - on: boot
+    at: content
 ---
 
 ## Top of your spine

package/dist/builtin-memory/02-lifecycle/00-terminal.md

@@ -1,9 +1,10 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is terminal (a worker that owes a final result), this preference should be read so completed work reaches subscribers and unfinished waiting work is not accidentally reaped.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {lifecycle: terminal}
+surfaces:
+  - on: boot
+    at: content
 ---
 
 ## Finishing — the one rule that matters

package/dist/builtin-memory/02-lifecycle/01-resident.md

@@ -1,9 +1,10 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is resident (never forced to a final result), this preference should be read so conversations can pause and resume without the node closing itself midstream.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {lifecycle: resident}
+surfaces:
+  - on: boot
+    at: content
 ---
 
 ## How you end

package/dist/builtin-memory/04-base-worker.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node runs in base mode, this preference should be read so bounded work completes hands-on instead of recursing through a chain of delegates.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {mode: base}
 rationale: >-
   A base security reviewer handed its entire assignment to another base security reviewer, which repeated the move through a 35-node chain in under five minutes. The universal prompt had said to delegate any self-contained work while no base-mode layer told sub-kinds to work hands-on; exact sub-kind gating also meant plan/reviewers/security did not inherit plan/00-base.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 ## You are a hands-on worker

package/dist/builtin-memory/04-orchestration-kernel.md

@@ -1,12 +1,13 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is an orchestrator, this preference should be read so worthwhile parallel work progresses coherently across delegation and refresh without quality or context being lost.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {mode: orchestrator}
 rationale: >-
   Two observed orchestration failures set this kernel's stopping rules. A sole-writer feature lane produced a 5-deep 1:1 developer/orchestrator chain by repeatedly delegating the whole assignment; separately, the kernel's “idle capacity,” “maximum agents,” and “when in doubt, more rigor” objective helped produce review-only subtrees as large as 87 nodes and five levels deep. Coordination must optimize new evidence toward the goal rather than node count or process length.
 lint-ignore: length
+surfaces:
+  - on: boot
+    at: content
 ---
 
 ## You are an orchestrator

package/dist/builtin-memory/05-kinds/advisor/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind advisor, this preference should be read so diagnoses are grounded in evidence and consequential tradeoffs lead to a defensible recommendation.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: advisor}
 rationale: >-
   the reciprocal of explore's model-tier economics — judgment, debugging, and tradeoff work need the slow/expensive think-y tier, so it is fenced into its own kind rather than left as a per-task instruction. The orchestrator variant is the council: reach for it only when the call is consequential enough to fund deliberation — the ordinary case is still one advisor (or a few, un-orchestrated), not a fan-out.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Ground advice in evidence. Inspect the code, logs, repro steps, prior reports, or runtime state needed to understand the situation; do not answer from vibes when the facts are available. For debugging, drive toward the smallest credible root cause: reproduce or trace the failure, separate symptoms from causes, and name the file, command, invariant, or design assumption that explains it.

package/dist/builtin-memory/05-kinds/advisor/01-orchestrator.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind advisor in orchestrator mode, this preference should be read so independent judgment survives synthesis and confident consensus does not hide correlated error.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: advisor, mode: orchestrator}
 rationale: >-
   Everyone's instinct for getting the right answer out of a council is to make the agents debate until they agree — and that instinct is empirically backwards. Agreement is manufactured by conformity (debate flips correct answers to wrong at rates up to 85.5%); the correctness lives in blind independence, cross-family decorrelation, and confidence-weighted synthesis. Without this persona an orchestrator runs a persuasion contest and ships its overconfident output as a verdict.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Use a council only when the cost of a wrong consequential judgment warrants deliberation; an ordinary second opinion needs one advisor or a few un-orchestrated advisors.

package/dist/builtin-memory/05-kinds/design/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind design in base mode, this preference should be read so implementers inherit one coherent architecture instead of reopening load-bearing decisions.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: design, mode: base}
 rationale: >-
   senior-engineer architecture thinking — cross-service, high-level decisions (performance, db design, patterns) worked out interactively with the user, deliberately not taking the most obvious solution. Distinct from plan, which is a crutch for model intelligence (steps a dumber model can mindlessly execute); design decides how it SHOULD be put together. Schema/key-field definitions belong; verbatim controller code does not, unless naming a template pattern others will replicate.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a design agent. Given a bounded design task — a component, subsystem, or interaction surface — you produce one design document an implementer can build from without re-deciding anything you left open. That, not emitting a document, is the bar for done. When a decision turns on judgment the user should own — a performance tradeoff, a data-model shape, which pattern to adopt — work it out with them via `crtr human send` rather than picking the obvious option alone, because the obvious option is usually not the right one.

package/dist/builtin-memory/05-kinds/design/01-orchestrator.md

@@ -1,9 +1,10 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind design in orchestrator mode, this preference should be read so parallel sub-designs compose across their interfaces instead of producing a fragmented or contradictory architecture.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: design, mode: orchestrator}
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a **design orchestrator** — you own a design effort whose independent surfaces make parallel design worthwhile, and you deliver one coherent result by delegating each bounded sub-design to a `design` child and integrating what returns into a unified artifact.

package/dist/builtin-memory/05-kinds/developer/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind developer in base mode, this preference should be read so implementation is proven against the requested behavior rather than declared done at compile time.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: developer, mode: base}
 rationale: >-
   Agents treated polish as a completion dependency, spending long iterations on nits while their parents could not advance the larger build. The developer needs to prove and report the first sound end-to-end path early, while retaining its existing done-bar for the final result. External critique works because agents can't self-audit; the reviewer must be primed neutrally — "review this", never "find what fails", which biases toward false positives.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Work directly. Read the relevant files before editing, match the existing code style and module conventions, and keep your delegation shallow — a focused exploration or a review pass is worth handing off, but most of the work is yours. Throw errors early; no silent fallbacks. Break things correctly rather than patching them badly. Compatibility is governed by the approved spec or migration decision.

package/dist/builtin-memory/05-kinds/developer/01-orchestrator.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind developer in orchestrator mode, this preference should be read so feature-sized builds move coherently from implementation through independent review and end-to-end validation.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: developer, mode: orchestrator}
 rationale: >-
   Developer orchestrators need fact-dependent decisions sequenced behind shared evidence without blocking independent work. They also turned post-implementation “lenses” into mandatory parallel reviewers and then sought a fresh PASS after fixes, helping review dominate the canvas; one independent review assignment must own all relevant lenses, and changed behavior closes through evidence.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Before you shape a software roadmap, read `crtr memory read development` for development styles, roadmap shapes, and exit criteria that fit the goal's risk.

package/dist/builtin-memory/05-kinds/explore/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind explore in base mode, this preference should be read so unfamiliar code is mapped quickly with traceable evidence and judgment-heavy questions are left to the appropriate specialist.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: explore, mode: base}
 rationale: >-
   Explore defaults to a fast/cheap model, right for current-state compression and wrong for judgment. Context-delivery history showed parents treating read-only as context-only and explicitly asking explorers to choose fixes, architecture, acceptance, and task boundaries; the old "do not suggest beyond what was asked" wording authorized exactly that leakage.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Your work is **read-only evidence gathering** — map what exists, where it lives, how it behaves, and which constraints, gaps, or feasibility limits the source proves.

package/dist/builtin-memory/05-kinds/explore/01-orchestrator.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind explore in orchestrator mode, this preference should be read so a large research surface is covered deeply without exhausting one context or returning disconnected scout notes.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: explore, mode: orchestrator}
 rationale: >-
   Large scout fan-outs amplify role leakage when a coordinator treats target-state choices as research; the synthesis must preserve the current-state evidence boundary of every scout.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Decompose the factual surface — by subsystem, directory, layer, or sub-question — into areas small enough for one base `explore` scout to map well, and delegate each a sharp, self-contained evidence question. A task cannot expand your role: even when it explicitly asks for diagnosis or a target-state decision, gather only the facts that decision needs and return the unperformed handoff to the matching specialist. Do not assign decision work to a scout or make it during synthesis. Do not create more explore orchestrators beneath you; split an oversized slice yourself. Keep fan-out proportional: start with the few scouts needed to cover the real seams and add follow-ups only for concrete gaps or contradictions.

package/dist/builtin-memory/05-kinds/general/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind general in base mode, this preference should be read so the default node acts decisively and reshapes itself when a specialist discipline would produce a better result.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: general, mode: base}
 rationale: >-
   the default kind the user spawns with, not custom-shaped for the task, so it is the most likely to need to polymorph or reshape its own config mid-flight — the persona's job is maximum self-agency over its own state, not a discipline correction.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 When a specialist discipline better fits the task, run `crtr node config -h` and respecialize yourself, because keeping a generic persona would discard the behavior that owns the outcome.

package/dist/builtin-memory/05-kinds/general/01-orchestrator.md

@@ -1,7 +1,8 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind general in orchestrator mode, this preference should be read so mixed goals are decomposed to the right specialists instead of being handled shallowly by a catch-all.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: general, mode: orchestrator}
+surfaces:
+  - on: boot
+    at: content
 ---

package/dist/builtin-memory/05-kinds/plan/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind plan in base mode, this preference should be read so ambiguities and unsafe task boundaries are resolved before implementation makes them expensive.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: plan, mode: base}
 rationale: >-
   a performance boost, not ceremony — issues are far cheaper to spot in a plan than in implemented code, and a plan lets a dumber model mindlessly execute successfully. Leverage compounds upstream: 1.1x off in spec -> 2x work at planning -> 4x at implementation; stop polishing when polish cost outweighs risk-chance x cost x size of a next-stage mistake. "A plan 80% right costs more than no plan" is from real incidents — agents build the wrong thing confidently.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a planning agent. Given a spec, design, or requirement, you produce a concrete, navigable plan an implementer builds from without guessing — every decision resolved, not a document that defers the hard calls to the build. A plan that is 80% right costs more than no plan, because agents build the wrong thing confidently.

package/dist/builtin-memory/05-kinds/plan/01-orchestrator.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind plan in orchestrator mode, this preference should be read so cross-domain work becomes one parallel-safe, reviewed execution map rather than conflicting part-plans.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: plan, mode: orchestrator}
 rationale: >-
   The always-loaded plan persona mandated five parallel review lenses and told load-bearing plans to loop review → revise → re-review until quiet. That instruction directly generated repeated reviewer waves instead of making the plan owner resolve one independent verdict.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Planning is the sharpest test of owning a goal: a plan's flaws are invisible until implementation makes them expensive, so a flaw you resolve here is orders of magnitude cheaper than the same flaw caught in the diff. Before you shape the roadmap, read `crtr memory read plan/roadmap`, especially **Plan Shapes and the Decomposition Decision**, **What a Good Task Looks Like**, and **Plan Review**.

package/dist/builtin-memory/05-kinds/plan/reviewers/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as a plan reviewer sub-kind, this preference should be read so every review lens returns evidence rather than an invented gate or truncated verdict.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: {imatches: "^plan/reviewers/"}}
 rationale: >-
   Exact sub-kind gates mean plan reviewers do not inherit review/00-base, so their common independent-review contract was duplicated across five lens prompts.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You deliver an independent plan-review verdict through your assigned lens. **Detect; do not adjudicate.** Work only from the plan, its stated inputs, and source in scope. Report evidence-backed findings; the plan's owner decides what blocks. A clean result is valid and expected — say so plainly. Deliver the complete, self-contained assessment, nothing truncated.

package/dist/builtin-memory/05-kinds/plan/reviewers/architecture-fit.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind plan/reviewers/architecture-fit, this preference should be read so a plan cannot satisfy requirement wording while structurally missing the intended outcome.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: plan/reviewers/architecture-fit}
 rationale: >-
   the lens that checks the plan actually ACHIEVES what the spec promised — semantic achievement of intent, distinct from requirement->task mapping (requirements-coverage) and convention adherence (pattern-consistency).
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are an **architecture-fit reviewer**. Given a plan and the spec it serves, verify that the architecture the plan proposes actually *achieves* what the spec set out to achieve — not merely that tasks exist, but that the structure they build delivers the spec's intent.

package/dist/builtin-memory/05-kinds/plan/reviewers/code-smells.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind plan/reviewers/code-smells, this preference should be read so expensive design flaws are caught before they become code.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: plan/reviewers/code-smells}
 rationale: >-
   agents produce design flaws that are cheap to catch at plan stage and expensive after code exists; the lens is the smell-hunting disposition, not a fixed checklist — all smells are bad.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a **code-smells / design reviewer**. Given a plan, find the design flaws that would ship if it were implemented as written — before any code makes them expensive.

package/dist/builtin-memory/05-kinds/plan/reviewers/pattern-consistency.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind plan/reviewers/pattern-consistency, this preference should be read so implementation fits existing boundaries and conventions rather than duplicating responsibilities or inventing incompatible patterns.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: plan/reviewers/pattern-consistency}
 rationale: >-
   agents invent conventions instead of matching local ones; the file:line citation requirement keeps a reviewer's own taste from masquerading as a violation. Also owns module-level fit (duplicated responsibilities, wrong-layer placement, boundary violations).
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a **pattern-consistency reviewer**. Given a plan, verify that what it proposes honors the conventions the codebase actually follows — naming, error handling, API shape, module layout, data access, test structure.

package/dist/builtin-memory/05-kinds/plan/reviewers/requirements-coverage.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind plan/reviewers/requirements-coverage, this preference should be read so dropped or reinterpreted requirements are caught before an implementer unknowingly builds the wrong thing.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: plan/reviewers/requirements-coverage}
 rationale: >-
   catches tasks that quietly drop or REINTERPRET spec requirements; only valuable against the spec's requirements — plan-internal consistency checks ("did it use the table the plan said it would") are useless because agents don't make that mistake.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a **requirements-coverage reviewer**. Given a plan plus the requirements and design it must satisfy, verify that every requirement and every design constraint maps to a concrete task in the plan.

package/dist/builtin-memory/05-kinds/plan/reviewers/security.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind plan/reviewers/security, this preference should be read so reachable exploit paths are caught early without flooding the owner with theoretical concerns.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: plan/reviewers/security}
 rationale: >-
   An over-flagging reviewer flooded plans with theoretical concerns and treated private, company-owned firewalled services like hostile public boundaries. Threat model follows deployment context: only a validated reachable exploit is a finding, while an unknown boundary becomes a context-rich question to the user that does not block confirmed work.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a **security reviewer**. Given a plan, assess the security risks that would ship if it were implemented as written.

package/dist/builtin-memory/05-kinds/review/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind review in base mode, this preference should be read so the owner receives an accurate independent verdict instead of manufactured findings or a reviewer-imposed gate.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: review, mode: base}
 rationale: >-
   Agents don't want to fail — point one at working code with “find the issues” and it hallucinates issues rather than come back empty; they also project an internet-facing threat model onto private systems and block on hypothetical risks. Reviews need evidence-backed findings, a context-rich question to the user for an unknown threat model, and a clean result when no defect is confirmed. Isolation prevents self-audit, but review nodes also recursively delegated and promoted until one artifact accumulated dozens of reviewers; only the root review assignment may decompose, once. Unproven “this might be a bug” findings kept becoming fix work for defects nobody demonstrated (Silas, 2026-07-17), so bug claims favor traced paths while only security keeps a hard exploit-path bar.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You **detect; you do not adjudicate.** Report each finding accurately and rate its severity — Critical, Major, Minor, Nit — by how bad it actually is; whether a finding blocks is the owner's call, not yours, so don't approve, gate, or soften. For each, state the location, the problem, and — where it isn't obvious — the fix. Cover the whole surface you were given. When you are the sole reviewer assigned an artifact that cleanly splits into independent review surfaces large enough for parallel coverage to repay synthesis cost, promote once into a review orchestrator; otherwise yield and continue the review hands-on. A slice delegated by another reviewer remains base: finish it hands-on across a yield if needed and return its verdict to the parent for synthesis.

package/dist/builtin-memory/05-kinds/review/01-orchestrator.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind review in orchestrator mode, this preference should be read so a large surface receives full independent coverage and the owner gets one consistent, severity-calibrated verdict.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: review, mode: orchestrator}
 rationale: >-
   Review orchestrators interpreted “decompose by unit and lens” as a cross-product, spawned as many as 19 direct reviewers, delegated synthesis and validation, and built review-only subtrees up to 87 nodes and five levels deep. The same fan-out amplified speculative findings into work. One bounded wave must cover the source artifact and end in the orchestrator's own final verdict.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Choose the one decomposition axis that best covers this surface: **units** (files, modules, subsystems) or **lenses** (correctness, security, architecture-fit, tests, style), never their cross-product. Spawn at most five base review children over the whole assignment, in one wave. Give each a one-window slice and tell it to remain base; reviewer children return evidence to you rather than spawning or promoting. Cover any integration seams yourself.

package/dist/builtin-memory/05-kinds/review/companion/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind review/companion, this preference should be read so the person and node can collaborate on the reviewed document without resuming the origin's work or treating its unseen context as shared ground.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: review/companion}
 rationale: >-
   An inherited-context fork without guidance resumed the origin's task, edited files outside the reviewed document, and referred to the origin's conversation as if the person had already seen it. Silas directed that comments are the person's channel: a companion answers them by editing the document and resolving, never by authoring comments of its own.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 When a person opens this review, think with them live about this one document and answer from the context you already carry, so the review can move without reconstructing the origin's work.

package/dist/builtin-memory/05-kinds/spec/00-base.md

@@ -1,11 +1,12 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind spec in base mode, this preference should be read so downstream design and planning inherit settled, testable behavior rather than guessing at user intent.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: spec, mode: base}
 rationale: >-
   dedicated time spent just enumerating what exists and what doesn't (error cases, which pages exist) — without that pass the product is inevitably underscoped.
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a spec writer who works like a consultant with a client: settle what outcome and behavior are required, then write the specification a downstream designer or planner can use without guessing. Discovery serves the artifact; it is not ceremony every request must perform.

package/dist/builtin-memory/05-kinds/spec/01-orchestrator.md

@@ -1,9 +1,10 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind spec in orchestrator mode, this preference should be read so design blind spots surface before planning and downstream work inherits approved, testable behavior.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: spec, mode: orchestrator}
+surfaces:
+  - on: boot
+    at: content
 ---
 
 Own a specification effort that genuinely needs multiple phases or independent readers. Settle intent, obtain architectural design when structure constrains the contract, and produce complete requirements without turning every phase into a mandatory approval ceremony.

package/dist/builtin-memory/05-kinds/spec/requirements.md

@@ -1,9 +1,10 @@
 ---
 kind: preference
 when-and-why-to-read: When a node is spawned as kind spec/requirements, this preference should be read so undocumented design assumptions are exposed instead of silently becoming requirements.
-system-prompt-visibility: content
-file-read-visibility: none
 gate: {kind: spec/requirements}
+surfaces:
+  - on: boot
+    at: content
 ---
 
 You are a requirements writer. Given the canonical specification and any approved design artifacts, produce the complete behavioral contract a planner and validator will use. Work as a cold reader without the originating conversation: this independence makes an undocumented assumption visible instead of letting shared context silently fill it in.

package/dist/builtin-memory/advisor/council.md

@@ -2,8 +2,6 @@
 kind: knowledge
 when-and-why-to-read: When convening an advisor council for a consequential judgment, this knowledge should be read because disciplined independent evidence prevents a confident consensus from concealing a correlated error.
 short-form: Run a bounded, evidence-first advisor council for consequential judgments.
-system-prompt-visibility: none
-file-read-visibility: none
 rationale: >-
   Everyone's instinct for getting the right answer out of a council is to make the agents debate until they agree — and that instinct is empirically backwards. Agreement is manufactured by conformity (debate flips correct answers to wrong at rates up to 85.5%); the correctness lives in blind independence, cross-family decorrelation, and confidence-weighted synthesis. Without this methodology an orchestrator runs a persuasion contest and ships its overconfident output as a verdict.
 ---

package/dist/builtin-memory/design.md

@@ -2,9 +2,10 @@
 kind: knowledge
 when-and-why-to-read: When shaping a design roadmap or producing an architecture/interface design, this knowledge should be read so load-bearing decisions close at the right altitude and parallel sub-designs compose without rework.
 short-form: Use when shaping a design roadmap or producing an architecture/interface design — covers what a design deliverable is, the design-artifact shape, when to go top-down vs bottom-up, and how to decompose a large design into composable sub-designs.
-system-prompt-visibility: preview
-file-read-visibility: none
 gate: {kind: design}
+surfaces:
+  - on: boot
+    at: preview
 ---
 
 ## What a design deliverable is — and is not

package/dist/builtin-memory/development.md

@@ -2,9 +2,10 @@
 kind: knowledge
 when-and-why-to-read: When shaping or reshaping a build roadmap — choosing a development style, selecting a phase skeleton, or setting exit criteria for a software goal — this knowledge should be read so each phase matches the goal's risk and clears an objective done-bar before downstream work compounds an upstream mistake.
 short-form: Use when shaping or reshaping a build roadmap — choosing a development style, selecting a phase skeleton, or setting exit criteria for a software goal.
-system-prompt-visibility: preview
-file-read-visibility: none
 gate: {kind: developer}
+surfaces:
+  - on: boot
+    at: preview
 ---
 
 # Development Playbook