@haaaiawd/loom 2.0.0 → 2.0.1

package/design.md

@@ -1,194 +1,201 @@
-# LOOM 2 System Design
-
-Status: implemented core, evaluation pending independent trials.
-
-## Product decision
-
-LOOM is for the Agent, not the human. Its job is to make a normal capable Agent substantially better at
-understanding a personalized project, acquiring the right professional judgment, continuing after context
-loss, and completing real work. The human experience remains natural conversation.
-
-The system therefore optimizes for four observable outcomes:
-
-1. The Agent can explain the intended whole rather than mirror a feature list.
-2. Consequential uncertainty becomes useful conversation instead of silent guessing or a fixed questionnaire.
-3. Consequential product, experience, system, contract, and verification decisions remain navigable as
-   separate documents rather than collapsing into one summary.
-4. Each relevant professional field changes decisions and produces a distinctive project stance without
-   being blended into an invented hybrid capability.
-5. A fresh Agent can resume the current Task from disk without inherited chat memory.
-
-Document production, role performance, stage completion, and graph density are not success metrics.
-
-## Minimal closed loop
-
-```text
-Understand → Clarify → Record → Map professional fields
-     ↑                              ↓
-     └──── update whole ← Design document graph → Work Map
-                            ↑                      ↓
-                            └── Keeper gaps ← fresh Keeper
-                                                   ↓ passed
-                           blocked/reopen ← Active Task → Evidence → next Task
-```
-
-### Understand and clarify
-
-The Agent inspects the workspace when the user's request makes it relevant. It describes the emerging
-result naturally and identifies the current uncertainty frontier. The frontier contains only decisions
-whose answers could materially change outcome, behavior, boundary, system, risk, or completion.
-
-The prompt constrains judgment, not question content. It requires a coherent high-value round, adaptive
-grouping, first-principles re-evaluation, and a convergence condition. It does not mandate headings,
-question counts, or a universal sequence.
-
-Convergence means the Agent can explain the whole result, its boundaries, the professional capability it
-needs, and how completion will be observed. Remaining unknowns must be reversible and local, explicitly
-delegated to the Agent, or explicitly skipped by the human after a concrete warning.
-
-### Record
-
-Markdown stores human-readable project truth. JSON stores machine state that people do not need to edit.
-Important corrections do not leave contradictory truths scattered through the corpus: PROJECT.md maps the
-current whole, `.loom/design/` owns detailed decisions, and DECISIONS.md records consequential supersession
-with rationale and impact.
-
-### Design document graph
-
-`PROJECT.md` is an entry point, not a compression target. Product definition, experience, independent
-systems, contracts, verification, operations, and research receive separate documents when they have their
-own decisions, interfaces, failure modes, or proof. Project size determines document count. This keeps a small
-project small while allowing a large system to become fully legible instead of “minimal” in the anemic sense.
-
-### Acquire capability
-
-Capabilities are project-scoped professional-field dossiers, not reusable expert personas or task methods.
-One dossier maps to one recognizable field. UI/UX design, visual art direction, game design, psychology,
-biology, security, and distributed systems remain separate when they use different evidence or judgments.
-Cross-field synthesis lives in the design document whose decision it changes. A dossier contains:
-
-- the field boundary, the decisions it changes, and the project reality grounding it;
-- specialist principles, evidence, sources, conflicts, and uncertainty;
-- an authored, falsifiable project stance and deliberate refusals;
-- questions whose answers could change the decision;
-- design and implementation consequences;
-- generic failure modes and observable verification signals;
-- opened sources, what each changed, conflicts, and uncertainty when research is used.
-
-Acquisition can happen quietly. The Agent may briefly name the capability it is obtaining, but does not
-turn research logistics into user workflow.
-
-### Work Map and Task
-
-Planning uses progressive resolution. A broad initial Work Map protects whole-project coverage and may be
-very long. Only the active horizon receives detailed actions. The context compiler returns counts and the
-current Task rather than injecting the whole plan.
-
-Task is the single execution contract:
-
-```json
-{
-  "id": "TASK-001",
-  "title": "Implement restartable context",
-  "outcome": "A fresh Agent receives only decision-relevant context",
-  "done_when": ["A forced-reset transcript resumes correctly"],
-  "boundaries": ["The human never operates LOOM"],
-  "depends_on": [],
-  "reads": [".loom/PROJECT.md", ".loom/design/context-system.md", ".loom/capabilities/human-agent-interaction.md", "fixtures/reset-case.md"],
-  "touches": ["cli/src/context.js"],
-  "status": "active",
-  "progress": {
-    "completed": [],
-    "current": "Implementing selector",
-    "next": "Run reset transcript"
-  },
-  "evidence": []
-}
-```
-
-There is at most one active Task. Completion requires a concrete evidence mapping for every exact `done_when`
-criterion. A completed Task can be reopened with a reason when later evidence disproves it. The Task plan may change without
-human approval when the change is a reversible implementation refinement inside the agreed whole; outcome,
-authority, risk, or material cost changes return to the conversation.
-
-### One-time Keeper
-
-Keeper is not a recurring role. It is a single isolation test at the transition from shaping to material
-execution. A fresh Agent receives no prior conversation, runs `loom context --keeper`, explains the whole,
-selects a first Task, navigates its design documents and professional capabilities, and identifies concrete evidence. Every attempt binds a unique
-fresh-thread `run_id` to the digest frozen by `project ready`. It may return gaps; summary, evidence and exact gaps
-are injected into the main Agent's next context. Revision must change project truth or Task definitions before a
-new digest and fresh Keeper run are allowed. Once passed, normal Task evidence replaces further Keeper ceremony.
-
-If the host lacks subagents, LOOM supplies a one-sentence prompt for a new window. Explicit skip is possible
-but must preserve a concrete reason and reduced confidence.
-
-## Runtime structure
-
-```text
-cli/bin/loom.js       small command router
-cli/src/store.js      state, design, capability, Task, Keeper, context and eval operations
-cli/src/protocol.js   layered Agent prompts and every human-readable template
-cli/test/run-all.js   end-to-end contract tests
-```
-
-The CLI has five responsibilities:
-
-1. Initialize the minimal project backbone.
-2. Record structured understanding and decision history safely.
-3. Scaffold a scalable design-document graph and separate professional-field dossiers.
-4. Maintain a large Work Map and a single active Task.
-5. Compile only decision-relevant context after reset.
-6. Prepare one-time Keeper and controlled Evil Eval artifacts.
-
-It does not orchestrate models, browse the web, generate project documents, or pretend that a CLI command
-clears model memory. Those capabilities belong to the host Agent and its tools.
-
-## State transition
-
-Project status is a compact orientation signal, not a phase bureaucracy:
-
-```text
-shaping ⇄ question, design-document, and professional-capability loop
-   ↓
-ready_for_keeper ⇄ fresh Keeper needs_revision or blocked → shaping
-   ↓ passed
-build_ready → building ⇄ Task repair or block or reopen → complete
-```
-
-`project ready` checks only structural prerequisites: PROJECT.md is no longer a template, at least one design
-document and a Work Map exist, and no high-impact open question remains. Keeper judges semantic build-readiness. Task start requires Keeper
-pass or an explicit recorded skip. An unchanged revision, duplicate Keeper run, wrong digest, or stale prepared
-state is rejected. Imported Tasks start open, `task start` rejects missing or directory-level context reads,
-generic updates cannot change status, and completion requires criterion-by-criterion evidence.
-
-## Context selection
-
-`loom context` always injects:
-
-- the stable Agent protocol;
-- compact state counts and open uncertainty;
-- PROJECT.md, with decision history identified as on-demand context;
+# LOOM 2 System Design
+
+Status: implemented core, evaluation pending independent trials.
+
+## Product decision
+
+LOOM is for the Agent, not the human. Its job is to make a normal capable Agent substantially better at
+understanding a personalized project, acquiring the right professional judgment, continuing after context
+loss, and completing real work. The human experience remains natural conversation.
+
+The system therefore optimizes for four observable outcomes:
+
+1. The Agent can explain the intended whole rather than mirror a feature list.
+2. Consequential uncertainty becomes useful conversation instead of silent guessing or a fixed questionnaire.
+3. Consequential product, experience, system, contract, and verification decisions remain navigable as
+   separate documents rather than collapsing into one summary.
+4. Each relevant professional field changes decisions and produces a distinctive project stance without
+   being blended into an invented hybrid capability.
+5. A fresh Agent can resume the current Task from disk without inherited chat memory.
+
+Document production, role performance, stage completion, and graph density are not success metrics.
+
+## Minimal closed loop
+
+```text
+Understand → Clarify → Record → Map professional fields
+     ↑                              ↓
+     └──── update whole ← Design document graph → Work Map
+                            ↑                      ↓
+                            └── Keeper gaps ← fresh Keeper
+                                                   ↓ passed
+                           blocked/reopen ← Active Task → Evidence → next Task
+```
+
+### Understand and clarify
+
+The Agent inspects the workspace when the user's request makes it relevant. It describes the emerging
+result naturally and identifies the current uncertainty frontier. The frontier contains only decisions
+whose answers could materially change outcome, behavior, boundary, system, risk, or completion.
+
+The prompt constrains judgment, not question content. It requires a coherent high-value round, adaptive
+grouping, first-principles re-evaluation, and a convergence condition. It does not mandate headings,
+question counts, or a universal sequence.
+
+Convergence means the Agent can explain the whole result, its boundaries, the professional capability it
+needs, and how completion will be observed. Remaining unknowns must be reversible and local, explicitly
+delegated to the Agent, or explicitly skipped by the human after a concrete warning.
+
+### Record
+
+Markdown stores human-readable project truth. JSON stores machine state that people do not need to edit.
+Important corrections do not leave contradictory truths scattered through the corpus: PROJECT.md maps the
+current whole, `.loom/design/` owns detailed decisions, and DECISIONS.md records consequential supersession
+with rationale and impact.
+
+### Design document graph
+
+`PROJECT.md` is an entry point, not a compression target. Product definition, experience, independent
+systems, contracts, verification, operations, and research receive separate documents when they have their
+own decisions, interfaces, failure modes, or proof. Project size determines document count. This keeps a small
+project small while allowing a large system to become fully legible instead of “minimal” in the anemic sense.
+
+### Acquire capability
+
+Capabilities are project-scoped professional-field dossiers, not reusable expert personas or task methods.
+One dossier maps to one recognizable field. UI/UX design, visual art direction, game design, psychology,
+biology, security, and distributed systems remain separate when they use different evidence or judgments.
+Cross-field synthesis lives in the design document whose decision it changes. A dossier contains:
+
+- the field boundary, the decisions it changes, and the project reality grounding it;
+- specialist principles, evidence, sources, conflicts, and uncertainty;
+- an authored, falsifiable project stance and deliberate refusals;
+- questions whose answers could change the decision;
+- design and implementation consequences;
+- generic failure modes and observable verification signals;
+- opened sources, what each changed, conflicts, and uncertainty when research is used.
+
+Acquisition can happen quietly. The Agent may briefly name the capability it is obtaining, but does not
+turn research logistics into user workflow.
+
+### Work Map and Task
+
+Planning uses progressive resolution. A broad initial Work Map protects whole-project coverage and may be
+very long. Only the active horizon receives detailed actions. The context compiler returns counts and the
+current Task rather than injecting the whole plan.
+
+Task is the single execution contract:
+
+```json
+{
+  "id": "TASK-001",
+  "title": "Implement restartable context",
+  "outcome": "A fresh Agent receives only decision-relevant context",
+  "done_when": ["A forced-reset transcript resumes correctly"],
+  "boundaries": ["The human never operates LOOM"],
+  "depends_on": [],
+  "reads": [".loom/PROJECT.md", ".loom/design/context-system.md", ".loom/capabilities/human-agent-interaction.md", "fixtures/reset-case.md"],
+  "touches": ["cli/src/context.js"],
+  "status": "active",
+  "progress": {
+    "completed": [],
+    "current": "Implementing selector",
+    "next": "Run reset transcript"
+  },
+  "evidence": []
+}
+```
+
+There is at most one active Task. Completion requires a concrete evidence mapping for every exact `done_when`
+criterion. A completed Task can be reopened with a reason when later evidence disproves it. The Task plan may change without
+human approval when the change is a reversible implementation refinement inside the agreed whole; outcome,
+authority, risk, or material cost changes return to the conversation.
+
+### One-time Keeper
+
+Keeper is not a recurring role. It is a single isolation test at the transition from shaping to material
+execution. A fresh Agent receives no prior conversation, runs `loom context --keeper`, explains the whole,
+selects a first Task, navigates its design documents and professional capabilities, and identifies concrete evidence. Every attempt binds a unique
+fresh-thread `run_id` to the digest frozen by `project ready`. It may return gaps; summary, evidence and exact gaps
+are injected into the main Agent's next context. Revision must change project truth or Task definitions before a
+new digest and fresh Keeper run are allowed. Once passed, normal Task evidence replaces further Keeper ceremony.
+
+If the host lacks subagents, LOOM supplies a one-sentence prompt for a new window. Explicit skip is possible
+but must preserve a concrete reason and reduced confidence.
+
+## Runtime structure
+
+```text
+cli/bin/loom.js       small command router
+cli/src/store.js      state, design, capability, Task, Keeper, context and eval operations
+cli/src/protocol.js   layered Agent prompts and every human-readable template
+cli/test/run-all.js   end-to-end contract tests
+```
+
+The CLI has six responsibilities:
+
+1. Initialize the minimal project backbone.
+2. Record structured understanding and decision history safely.
+3. Scaffold a scalable design-document graph and separate professional-field dossiers.
+4. Maintain a large Work Map and a single active Task.
+5. Compile only decision-relevant context after reset.
+6. Prepare one-time Keeper and controlled Evil Eval artifacts.
+
+It does not orchestrate models, browse the web, generate project documents, or pretend that a CLI command
+clears model memory. Those capabilities belong to the host Agent and its tools.
+
+## State transition
+
+Project status is a compact orientation signal, not a phase bureaucracy:
+
+```text
+shaping ⇄ question, design-document, and professional-capability loop
+   ↓
+ready_for_keeper ⇄ fresh Keeper needs_revision or blocked → shaping
+   ↓ passed
+build_ready → building ⇄ Task repair or block or reopen → complete
+```
+
+`project ready` checks only structural prerequisites: PROJECT.md is no longer a template, at least one design
+document and a Work Map exist, and no high-impact open question remains. Keeper judges semantic build-readiness. Task start requires Keeper
+pass or an explicit recorded skip. An unchanged revision, duplicate Keeper run, wrong digest, or stale prepared
+state is rejected. Imported Tasks start open, `task start` rejects missing or directory-level context reads,
+generic updates cannot change status, and completion requires criterion-by-criterion evidence.
+
+## Context selection
+
+`loom context` always injects:
+
+- the stable Agent protocol;
+- compact state counts and open uncertainty;
+- PROJECT.md, with decision history identified as on-demand context;
 - the active Task, if one exists;
 - the exact design, capability, source, contract, or fixture files named in that Task's `reads` list.
 
-Workspace code paths in `touches` are identified but not automatically copied into context. Full decision
-history is not repeatedly injected because current truth belongs in PROJECT.md and linked design documents.
-`loom context --keeper` includes history, every design document, and every professional capability dossier
-because whole-project coverage and contradiction detection are exactly what the isolated handoff tests.
-
-## Compatibility decision
-
-LOOM 2 is a major redesign. It does not silently mutate `.loom/v1` projects and does not preserve the old command
-surface. Encountering a legacy layout produces an explicit migration boundary. Git remains the recovery path;
-an automated semantic migration can be designed only after real v1 projects reveal which history is valuable.
-
-## Known boundaries
-
-- External capability acquisition is represented but not automated yet; the host Agent performs research.
-- Markdown is intentionally human-editable. LOOM validates file existence and structured state, not prose truth.
-- Keeper independence depends on the host creating a fresh thread or window.
-- Evil Eval scaffolding controls experiment design but does not itself launch model runs.
-- A one-time Keeper verifies build-readiness, not the eventual quality of every implementation Task.
-
-These are honest capability boundaries, not deferred stages disguised as completion.
+When a Task is active, context also injects a short execution protocol. It tells a reset Agent to reconcile
+the Task with the current workspace and version-control state, inspect relevant tests before editing, choose
+verification according to risk and the exact `done_when` claims, persist `completed/current/next` at meaningful
+handoff boundaries, and close only with reproducible criterion-level evidence. It deliberately does not require
+a ceremonial unit test for every kind of work or a branch, commit, or pull request for every Task. Those
+delivery mechanisms remain conditional on the human request and repository workflow.
+
+Workspace code paths in `touches` are identified but not automatically copied into context. Full decision
+history is not repeatedly injected because current truth belongs in PROJECT.md and linked design documents.
+`loom context --keeper` includes history, every design document, and every professional capability dossier
+because whole-project coverage and contradiction detection are exactly what the isolated handoff tests.
+
+## Compatibility decision
+
+LOOM 2 is a major redesign. It does not silently mutate `.loom/v1` projects and does not preserve the old command
+surface. Encountering a legacy layout produces an explicit migration boundary. Git remains the recovery path;
+an automated semantic migration can be designed only after real v1 projects reveal which history is valuable.
+
+## Known boundaries
+
+- External capability acquisition is represented but not automated yet; the host Agent performs research.
+- Markdown is intentionally human-editable. LOOM validates file existence and structured state, not prose truth.
+- Keeper independence depends on the host creating a fresh thread or window.
+- Evil Eval scaffolding controls experiment design but does not itself launch model runs.
+- A one-time Keeper verifies build-readiness, not the eventual quality of every implementation Task.
+
+These are honest capability boundaries, not deferred stages disguised as completion.

package/docs/PROMPT_CATALOG.md

@@ -1,99 +1,106 @@
-# LOOM Prompt and Message Catalog
-
-LOOM's prompts are cognitive interfaces, not a collection of role-playing personas. The exact live
-inventory is emitted by:
-
-```bash
-loom prompts
-```
-
-The command is the auditable source of truth. It returns the complete text, placeholders, and composition
-order as JSON, so documentation cannot quietly describe a different prompt from the one Agents receive.
-
-## Instruction layers
-
-| Layer | Message | Injected when | Purpose |
-|---|---|---|---|
+# LOOM Prompt and Message Catalog
+
+LOOM's prompts are cognitive interfaces, not a collection of role-playing personas. The exact live
+inventory is emitted by:
+
+```bash
+loom prompts
+```
+
+The command is the auditable source of truth. It returns the complete text, placeholders, and composition
+order as JSON, so documentation cannot quietly describe a different prompt from the one Agents receive.
+
+## Instruction layers
+
+| Layer | Message | Injected when | Purpose |
+|---|---|---|---|
 | Stable core | `layers.stable_core` | Every `loom context` | Durable collaboration judgment: user ownership, evidence classes, question threshold, corrections, reversible delegation |
 | Runtime adaptation | `layers.runtime_protocol` | Every `loom context` | LOOM-specific disk model, document graph, capability boundaries, Work Map, and three production loops |
 | Project state | `layers.project_state` | Every `loom context` | Dynamic status, uncertainty, assumptions, document/capability inventory, Task counts, and Keeper feedback |
+| Execution protocol | `layers.execution_protocol` | Active Task or `--task` | Recovery, workspace inspection, risk-based testing, progress persistence, exact proof, and delivery boundaries |
 | Current task | `layers.current_task` | Active Task or `--task` | Exact Task JSON followed by the exact contents of every path in `reads` |
-
-This separation is deliberate. Project-specific expertise does not inflate the stable prompt; it lives in
-field dossiers. One-off Task instructions do not become global doctrine. Host permissions and tools are not
-claimed by prompt text.
-
-## Workspace and document messages
-
-`workspace_anchor` is the short block added to `AGENTS.md`. It tells an entering Agent to run `loom context`
-and keeps CLI operation invisible to the human.
-
-`templates.project_index` creates `.loom/PROJECT.md` as a concise whole and document map. It explicitly
-prevents a large project's systems from being compressed into one file.
-
-`templates.design_documents` contains all seven live design templates:
-
-1. `product` — outcome, users, problem, product principles, scope, end-to-end behavior, success and failure.
-2. `experience` — journey, information architecture, states, content, visual direction, accessibility, recovery, usability proof.
-3. `system` — responsibilities, boundaries, control flow, data, interfaces, dependencies, failure, implementation, verification.
-4. `contract` — consumers, schemas or commands, invariants, permissions, errors, compatibility, fixtures, contract tests.
-5. `verification` — claims, environments, fixtures, acceptance matrix, commands, negative tests, blind spots.
-6. `operations` — authority, procedures, commands, safety, failure recovery, evidence and audit trail.
-7. `research` — decision, evidence, method, sources, findings, conflicts, consequences and follow-up proof.
-
-These are possible document kinds, not a fixed seven-file checklist. The Agent creates as many actual
-documents as the project's independent decision surfaces require.
-
-`templates.professional_capability` is the only capability template. It enforces one recognizable field per
-file, a project-specific diagnosis and stance, opened evidence, rejected generic defaults, concrete design and
-verification consequences, failure modes, and links to adjacent fields without merging them.
-
-`templates.decision_history` is the preamble for consequential superseding decisions. Current truth stays in
-the project map and linked design documents.
-
-## Keeper message
-
-`keeper` is the exact independent handoff prompt. It binds a unique fresh-Agent `run_id` to a frozen
-`prepared_digest`, asks the Keeper to navigate the whole corpus and attempt the first Task, and defines three
-verdicts:
-
-- `passed`: a fresh Agent can responsibly begin.
-- `needs_revision`: concrete disk-truth gaps can be repaired.
-- `blocked`: progress needs unavailable authority or external state.
-
-A failed result is injected into the next project-state message. A retry requires changed project truth, a
-new digest, and another fresh Keeper.
-
-## Evil Eval messages
-
-`evaluation.baseline_condition` gives a normal capable Agent the identical brief and ordinary tools without
-LOOM. It does not weaken the baseline or prohibit normal planning.
-
-`evaluation.loom_condition` gives the same brief, model class, tools, workspace facts, and budget, adding only
-LOOM continuity infrastructure and no extra authority.
-
-`evaluation.blind_judge` scores anonymized output on intent fidelity, question value, whole coverage,
-professional depth, buildability, reset continuity, implementation evidence, human burden, and cost. It
-penalizes ceremony and runs an order swap.
-
-## Composition messages
-
-`composition.normal_resume`, `composition.active_task`, and `composition.keeper_handoff` list the exact block
-order. Keeper receives every design and capability document; a normal active Task receives only its declared
+
+This separation is deliberate. Project-specific expertise does not inflate the stable prompt; it lives in
+field dossiers. One-off Task instructions do not become global doctrine. Host permissions and tools are not
+claimed by prompt text.
+
+## Workspace and document messages
+
+`workspace_anchor` is the short block added to `AGENTS.md`. It tells an entering or reset Agent to run
+`loom context`, rerun it before editing after an interruption, persist state at meaningful boundaries rather
+than before every tool call, and keep CLI operation invisible to the human.
+
+`templates.project_index` creates `.loom/PROJECT.md` as a concise whole and document map. It explicitly
+prevents a large project's systems from being compressed into one file.
+
+`templates.design_documents` contains all seven live design templates:
+
+1. `product` — outcome, users, problem, product principles, scope, end-to-end behavior, success and failure.
+2. `experience` — journey, information architecture, states, content, visual direction, accessibility, recovery, usability proof.
+3. `system` — responsibilities, boundaries, control flow, data, interfaces, dependencies, failure, implementation, verification.
+4. `contract` — consumers, schemas or commands, invariants, permissions, errors, compatibility, fixtures, contract tests.
+5. `verification` — claims, environments, fixtures, acceptance matrix, commands, negative tests, blind spots.
+6. `operations` — authority, procedures, commands, safety, failure recovery, evidence and audit trail.
+7. `research` — decision, evidence, method, sources, findings, conflicts, consequences and follow-up proof.
+
+These are possible document kinds, not a fixed seven-file checklist. The Agent creates as many actual
+documents as the project's independent decision surfaces require.
+
+`templates.professional_capability` is the only capability template. It enforces one recognizable field per
+file, a project-specific diagnosis and stance, opened evidence, rejected generic defaults, concrete design and
+verification consequences, failure modes, and links to adjacent fields without merging them.
+
+`templates.decision_history` is the preamble for consequential superseding decisions. Current truth stays in
+the project map and linked design documents.
+
+## Keeper message
+
+`keeper` is the exact independent handoff prompt. It binds a unique fresh-Agent `run_id` to a frozen
+`prepared_digest`, asks the Keeper to navigate the whole corpus and attempt the first Task, and defines three
+verdicts:
+
+- `passed`: a fresh Agent can responsibly begin.
+- `needs_revision`: concrete disk-truth gaps can be repaired.
+- `blocked`: progress needs unavailable authority or external state.
+
+A failed result is injected into the next project-state message. A retry requires changed project truth, a
+new digest, and another fresh Keeper.
+
+## Evil Eval messages
+
+`evaluation.baseline_condition` gives a normal capable Agent the identical brief and ordinary tools without
+LOOM. It does not weaken the baseline or prohibit normal planning.
+
+`evaluation.loom_condition` gives the same brief, model class, tools, workspace facts, and budget, adding only
+LOOM continuity infrastructure and no extra authority.
+
+`evaluation.blind_judge` scores anonymized output on intent fidelity, question value, whole coverage,
+professional depth, buildability, reset continuity, implementation evidence, human burden, and cost. It
+penalizes ceremony and runs an order swap.
+
+## Composition messages
+
+`composition.normal_resume`, `composition.active_task`, and `composition.keeper_handoff` list the exact block
+order. Keeper receives every design and capability document; a normal active Task receives only its declared
 reads. This difference is intentional: Keeper audits whole-project coverage, while delivery protects context
 focus.
 
-## CLI operational messages
-
-`loom --help` is the complete command-oriented message surface. JSON command results report state and the next
-host action. Validation errors are contract enforcement rather than cognitive prompts; they reject unsafe
-references, template-only readiness, missing design documents, open high-impact uncertainty, unchanged Keeper
-retries, stale digests, duplicate run identities, Task dependency violations, missing or directory-level Task
-reads, status bypasses, completion without evidence for every done condition, and reasonless reopening of a
-disproven completion.
-
-The short human fallback when the host cannot create a Keeper Agent remains:
-
-```text
-Please open a new window in this project, run loom keeper prompt, and follow it.
-```
+The active Task composition adds `execution_protocol` between the recovered project whole and the exact Task.
+It requires inspection of current workspace/version-control reality, risk-appropriate tests, restartable
+progress, and criterion-level proof. It does not force a unit test for non-code claims or a branch/PR for every
+Task; those are selected when the behavior, human request, or repository workflow makes them meaningful.
+
+## CLI operational messages
+
+`loom --help` is the complete command-oriented message surface. JSON command results report state and the next
+host action. Validation errors are contract enforcement rather than cognitive prompts; they reject unsafe
+references, template-only readiness, missing design documents, open high-impact uncertainty, unchanged Keeper
+retries, stale digests, duplicate run identities, Task dependency violations, missing or directory-level Task
+reads, status bypasses, completion without evidence for every done condition, and reasonless reopening of a
+disproven completion.
+
+The short human fallback when the host cannot create a Keeper Agent remains:
+
+```text
+Please open a new window in this project, run loom keeper prompt, and follow it.
+```