@rosenfan/matrix 0.1.1 → 0.1.2

package/.claude/skills/matrix-claude/SKILL.md

@@ -5,45 +5,45 @@ description: Export a frozen Matrix design as a bounded Claude Code task package
 
 # Matrix Claude Handoff
 
-This is an optional Matrix sidecar, not a Matrix phase. It must not call `transition`, `archive`, or write `matrix.yaml`, `run-state.json`, or `events.jsonl`.
+This is an optional Matrix sidecar, not a Matrix phase. It must not call `transition`, `archive`, or write `matrix.yaml` or `events.jsonl`.
 
 ## When to Use
 
 Use `$matrix-claude` when:
-- The design phase guard has passed (design is frozen)
+- The active change is in Build and the Design -> Build transition has approved the contract
 - You want Claude Code (instead of Codex) to implement the design
 - You need a bounded task package with all implementation details
 
 ## Preconditions
 
-The exporter performs this read-only check before writing anything:
+The exporter performs this read-only check before writing anything:
 
-```powershell
-matrix workflow guard design
-```
-
-If `matrix` is genuinely absent from PATH, use the bundled runtime from the installed root Matrix Skill. Do not fall back when the primary command starts and returns an error.
+```powershell
+matrix workflow guard build
+```
 
-If the design guard fails, stop and return to `$matrix-design`. The exporter reads the active change's `proposal.md`, `design.md`, and `plan.md`; it does not invent missing facts.
+If `matrix` is genuinely absent from PATH, use the bundled runtime from the installed root Matrix Skill. Do not fall back when the primary command starts and returns an error.
+
+If the build guard reports `CONTRACT_CHANGED` or `CONTRACT_UNAPPROVED`, return to `$matrix-design` and approve a new contract through Build. The exporter reads the approved bytes of `proposal.md`, `design.md`, and `plan.md`; it does not invent missing facts.
 
 ## Export
 
-Treat explicit invocation of `$matrix-claude` as the user's choice of Claude Code as the implementation actor. Generate the package with the deterministic exporter; it refuses a missing design guard and does not alter Matrix state.
+Treat explicit invocation of `$matrix-claude` as the user's choice of Claude Code as the implementation actor. Generate the package with the deterministic exporter; it refuses a non-matching approved contract and does not alter Matrix state.
+
+```powershell
+# Generic project: only exports a Matrix artifact.
+matrix workflow export --task-id <ID> --target generic
 
-```powershell
-# Generic project: only exports a Matrix artifact.
-matrix workflow export --task-id <ID> --target generic
-
-# FnSec: exports its formal task package. Add --apply-fnsec-board only when
-# active.md is NO_ACTIVE_OBJECTIVE; an existing task is never overwritten.
-matrix workflow export --task-id <ID> --target fnsec --apply-fnsec-board
-```
+# FnSec: exports its formal task package. Add --apply-fnsec-board only when
+# active.md is NO_ACTIVE_OBJECTIVE; an existing task is never overwritten.
+matrix workflow export --task-id <ID> --target fnsec --apply-fnsec-board
+```
 
 ## Task Package Contents
 
 The exported package (`artifacts/claude-task.md`) contains everything Claude Code needs to implement and produce evidence for `$matrix-verify`:
 
-1. **Task ID and execution actor**: Claude Code
+1. **Task ID, execution actor, and approved contract hash**: Claude Code and the exact approved snapshot
 2. **Objective and acceptance criteria** — copied from `proposal.md`
 3. **In-scope and out-of-scope boundaries** — from `proposal.md`
 4. **Frozen design decisions** — from `design.md` (Decisions, Boundaries, Test seams)
@@ -76,12 +76,12 @@ After Claude Code completes and evidence is present:
 
 1. Run build guard to verify evidence:
    ```powershell
-   matrix workflow guard build
+   matrix workflow guard build
    ```
 
 2. If guard passes, transition to verify:
    ```powershell
-   matrix workflow transition verify
+   matrix workflow transition verify
    ```
 
 3. Enter `$matrix-verify` to继续验证流程
@@ -91,6 +91,6 @@ If the build guard fails, return to Claude Code to补充 missing evidence.
 ## Important Notes
 
 - This sidecar does NOT change Matrix phase, workflow, or guard result
-- The Matrix state remains in `design` phase until explicitly transitioned
+- The Matrix state remains in `build` phase; export itself does not advance it
 - Claude Code must produce evidence that satisfies the build guard conditions
 - After successful transition to verify, the normal verify流程 continues

package/.claude/skills/matrix-design/SKILL.md

@@ -5,35 +5,35 @@ description: Design and freeze the active Matrix change before implementation. U
 
 # Matrix Design
 
-Read the active proposal. Write `artifacts/design.md` with `## Decisions`, `## Boundaries`, `## Test seams`, and `## Risks`; write `artifacts/plan.md` with `## Steps`, `## Validation`, and `## Stop conditions`.
-
-## Skills to Use (Recommended Order)
-
-1. **`domain-modeling`** — First, establish or refine the domain vocabulary. Update `CONTEXT.md` with any new terms from the proposal. This ensures all subsequent design work uses consistent language.
-
-2. **`research`** — If the design requires investigating external APIs, documentation, or specifications, spawn a background research agent. It will investigate primary sources and write findings to a Markdown file.
-
-3. **`wayfinder`** — For complex codebases, use this to explore and understand existing module structure, seams, and dependencies before making design decisions.
-
-4. **`prototype`** — When a design question needs empirical validation (e.g., "does this state model feel right?" or "what should this UI look like?"), build a throwaway prototype. Two modes:
-   - **Logic prototype**: interactive terminal app to test state machines
-   - **UI prototype**: multiple UI variations on a single route
-
-5. **`codebase-design`** — Finally, define module boundaries, interfaces, and test seams. Use its "design-it-twice" pattern to explore alternative approaches before committing.
+Run `matrix workflow inspect`, read the active proposal and frozen `orchestration`, then write `artifacts/design.md` with `## Decisions`, `## Boundaries`, `## Test seams`, and `## Risks`; write `artifacts/plan.md` with `## Steps`, `## Validation`, and `## Stop conditions`.
+
+## Prim
+
+Use Matrix's own capability to investigate the repository and design the change.
+
+## Arch
+
+Invoke only capabilities whose task-fact trigger is proven:
+
+- `domain-modeling` for unclear vocabulary, invariants, or architectural decisions;
+- `research` when required external facts cannot be established from the repository;
+- `wayfinder` when module ownership or dependency seams are unknown;
+- `prototype` when a material design decision needs disposable empirical evidence;
+- `codebase-design` when a deep-module, interface, or test-seam decision remains.
+
+Order follows actual dependencies; never run a fixed companion sequence. Announce each invocation and reason. A correctly installed capability gets at most one same-capability Matrix fallback; installation-integrity failure stops the phase.
+
+Long-lived domain, ADR, or research artifacts follow repository conventions, and material conclusions must be synchronized into the canonical design or plan. Prototypes default to an OS temporary directory unless the approved design promotes a project path. Companion output cannot own Matrix state or create a competing plan.
 
 ## Process
 
-1. Start with `domain-modeling` to ground the vocabulary
-2. Use `research` for external dependencies (runs in background)
-3. Use `wayfinder` to explore complex existing code
-4. Use `prototype` to validate key design questions
-5. Use `codebase-design` to finalize module boundaries
-6. Confirm material architecture choices with the user before freezing
-7. Run the guard
-8. If guard passes, ask the user to choose implementation method:
+1. Establish repository facts and resolve only triggered design questions.
+2. Write and synchronize the canonical Matrix design and plan.
+3. Confirm material architecture choices with the user before freezing.
+4. Run the guard, then choose the implementation actor.
 
 ```powershell
-matrix workflow guard design
+matrix workflow guard design
 ```
 
 ## Implementation Decision Point
@@ -45,22 +45,21 @@ After the design guard passes, the user chooses:
 Run transition and enter `$matrix-build`:
 
 ```powershell
-matrix workflow transition build
+matrix workflow transition build
 ```
 
 Then enter `$matrix-build` to implement directly in this session.
 
 ### Option B: Use Claude Code for implementation
 
-Run `$matrix-claude` to export the frozen design as a bounded task package. This:
-- Does NOT change Matrix phase or state
+First approve the frozen contract by transitioning to Build, then run `$matrix-claude` to export a bounded task package. This:
+- Does not change the Build phase or state beyond the preceding transition
 - Creates `artifacts/claude-task.md` with all implementation details
 - Includes acceptance criteria, test seams, and required commands
 
-After Claude Code completes and returns results, run the transition and enter `$matrix-verify`:
+After Claude Code completes and returns results, run the Build guard and enter `$matrix-verify`:
 
 ```powershell
-matrix workflow transition build
 matrix workflow guard build
 matrix workflow transition verify
 ```

package/.claude/skills/matrix-hotfix/SKILL.md

@@ -1,8 +1,8 @@
----
-name: matrix-hotfix
-description: Run a constrained Matrix workflow for a reproducible small bug. Use for a bug fix that has no material architecture, API, schema, or multi-module coordination impact.
----
-
-# Matrix Hotfix
-
-Start through `$matrix` with workflow `hotfix`, then use `diagnosing-bugs` to establish a red-capable feedback loop before changing code. Write the compact proposal, then continue through Matrix gates. If the bug requires architecture change, a new public API, schema work, or broad coordination, pause and ask whether to upgrade to full `$matrix`.
+---
+name: matrix-hotfix
+description: Run a constrained Matrix workflow for a reproducible small bug. Use for a bug fix that has no material architecture, API, schema, or multi-module coordination impact.
+---
+
+# Matrix Hotfix
+
+Start through `$matrix` with workflow `hotfix` and preserve its frozen Prim or Arch orchestration. Prim diagnoses directly. Arch invokes `diagnosing-bugs` only when an actual failure exists and root cause is not established. Write the compact proposal, continue through the normal Matrix gates, and keep all companion output subordinate to Matrix artifacts and state. If the bug requires architecture change, a new public API, schema work, or broad coordination, use controlled Return and upgrade the work to a full Matrix change.

package/.claude/skills/matrix-open/SKILL.md

@@ -5,29 +5,26 @@ description: Open or resume the Matrix open phase by clarifying a development re
 
 # Matrix Open
 
-Read the active Matrix change with `matrix workflow inspect`. Produce `artifacts/proposal.md` containing exactly these substantive sections: `## Goal`, `## Scope`, `## Non-goals`, `## Acceptance`, and `## Risks`.
-
-## Skills to Use
-
-For a **full workflow**, use `grill-with-docs` to resolve ambiguity before writing the proposal. This skill automatically:
-
-1. Runs a `/grilling` session to stress-test the plan through relentless Q&A
-2. Invokes `/domain-modeling` to establish shared vocabulary
-3. Creates or updates `CONTEXT.md` with domain terms
-4. Creates ADRs (Architecture Decision Records) for significant decisions
-
-For **hotfix/tweak**, use `grilling` directly (without docs) — keep it concise but preserve acceptance criteria.
+Run `matrix workflow inspect`, read the active change and its frozen `orchestration`, then produce `artifacts/proposal.md` containing exactly these substantive sections: `## Goal`, `## Scope`, `## Non-goals`, `## Acceptance`, and `## Risks`.
+
+## Prim
+
+Use Matrix's own capability to clarify the request and write the proposal.
+
+## Arch
+
+Invoke `grilling` only when material ambiguity remains or the user asks to stress-test the request. Invoke `domain-modeling` only when domain vocabulary, invariants, or an architectural decision is unclear. Announce the capability and reason before invoking it; selecting Arch already authorizes triggered capabilities.
+
+Companion output is evidence for the Matrix proposal. It must not create another workflow, proposal, confirmation state, or phase transition. If a correctly installed capability fails, perform at most one Matrix-owned fallback for that same capability and record the failure and evidence. Installation-integrity failures require `matrix init --with-mattpocock` and are not eligible for fallback.
 
 ## Process
 
-1. Run `grill-with-docs` (or `grilling` for hotfix/tweak)
-2. Write `proposal.md` with all required sections
-3. Ask the user to confirm when scope or risk is material
-4. Run the guard
-5. If guard passes, run transition to advance to design phase
-6. **Then enter `$matrix-design` to continue the workflow**
+1. Resolve only ambiguities required by the active workflow.
+2. Write the canonical proposal and synchronize material companion conclusions into it.
+3. Ask the user to confirm when scope or risk is material.
+4. Run the guard and transition, then enter `$matrix-design`.
 
 ```powershell
-matrix workflow guard open
-matrix workflow transition design
+matrix workflow guard open
+matrix workflow transition design
 ```

package/.claude/skills/matrix-status/SKILL.md

@@ -9,6 +9,7 @@ Run the same Matrix state kernel used by the main entry and every phase Skill:
 
 ```powershell
 matrix workflow inspect
-```
-
-Report the returned change id, workflow, phase, guard result, and `next_skill`. Do not infer status from conversation history and do not modify state. If the guard is failing, name the missing evidence and direct the user to the current phase Skill.
+matrix workflow doctor
+```
+
+Report the returned change id, workflow, frozen `orchestration`, phase, guard result, `next_skill`, Workflow health, unfinished transactions, available strategies, and exact recovery commands. If Arch integrity fails, identify the affected platform/Skill facts and report `matrix init --with-mattpocock`; do not reinterpret the change as Prim. Both commands are read-only. Do not infer status from conversation history, run `--repair`, or modify state. If the guard is failing, name the missing evidence and direct the user to the current phase Skill.

package/.claude/skills/matrix-tweak/SKILL.md

@@ -1,8 +1,8 @@
----
-name: matrix-tweak
-description: Run a lightweight Matrix workflow for a bounded small development change. Use for a small request with no schema, public API, architecture, or cross-module coordination impact.
----
-
-# Matrix Tweak
-
-Start through `$matrix` with workflow `tweak`. Keep proposal and design concise, but still define acceptance criteria and test seams. Upgrade to full `$matrix` when the change crosses module, API, schema, or architecture boundaries.
+---
+name: matrix-tweak
+description: Run a lightweight Matrix workflow for a bounded small development change. Use for a small request with no schema, public API, architecture, or cross-module coordination impact.
+---
+
+# Matrix Tweak
+
+Start through `$matrix` with workflow `tweak` and preserve its frozen Prim or Arch orchestration. Keep proposal and design concise, but still define acceptance criteria and test seams. Arch invokes only capabilities whose normal task-fact triggers are present; shortcut workflows do not gain a fixed companion sequence or weaker evidence requirements. Use controlled Return and upgrade to full Matrix when the change crosses module, API, schema, or architecture boundaries.

package/.claude/skills/matrix-verify/SKILL.md

@@ -27,30 +27,22 @@ Before starting verification, ensure:
 
 If these are missing (e.g., Claude Code didn't produce complete evidence), return to `$matrix-build` or ask Claude Code to补充.
 
-## Skills to Use
-
-### Primary: `code-review`
-
-Use the `code-review` skill to perform a two-axis review of the diff:
-
-1. **Standards axis** — Does the code conform to this repo's documented coding standards? Includes a "smell baseline" (Fowler code smells) even when no standards are documented.
-
-2. **Spec axis** — Does the code faithfully implement the originating issue/PRD/spec? Checks for:
-   - Missing or partial requirements
-   - Scope creep (behavior not asked for)
-   - Wrong implementations of required behavior
-
-Both axes run as parallel sub-agents and report separately. Record findings under `## Review evidence` in `artifacts/verification.md`.
-
-### Optional: `improve-codebase-architecture`
-
-After verification passes, if the change touched modules that could be deepened, use `improve-codebase-architecture` to scan for shallow-module opportunities. This is advisory — skip it for simple changes or when time is constrained.
+## Orchestration
+
+Run `matrix workflow inspect` and read the frozen mode.
+
+- **Prim**: Matrix performs the Standards and Spec review itself.
+- **Arch**: invoke `code-review` to produce both review axes; announce the invocation and reason.
+
+Review findings are inputs to Matrix Verify; a companion cannot decide the phase outcome, broaden approved architecture, transition, or archive. Do not invoke post-review architecture wrappers. A correctly installed review capability gets at most one same-capability Matrix fallback; installation-integrity failure stops verification.
 
 ## Failure Handling
 
-If verification or review fails:
-- If the issue is in the implementation → **return to `$matrix-build`** or ask Claude Code to fix
-- If the issue is in the plan/design → return to `$matrix-design`
+If verification or review fails:
+- If the issue is in the implementation, run `matrix workflow return build --reason verification-failed`, then enter `$matrix-build` or ask Claude Code to fix.
+- If the issue is in the acceptance criteria or design, run `matrix workflow return design --reason acceptance-or-design-gap`, then enter `$matrix-design`.
+
+Both Return paths rotate the current `verification.md` into revisioned evidence history. Do not copy stale conclusions back into the new current evidence.
 
 If documents or public behavior changed, record the required synchronization work before the guard.
 
@@ -59,17 +51,14 @@ If documents or public behavior changed, record the required synchronization wor
 1. Check that `artifacts/verification.md` exists with `## Build evidence`
 2. Run the plan's acceptance commands (from `plan.md` `## Validation` section)
 3. Record test output under `## Test evidence`
-4. Load `code-review` skill
-5. Run both axes (Standards + Spec) in parallel
+4. Produce both Standards and Spec review axes through the selected orchestration mode
 6. Record findings under `## Review evidence`
-7. Optionally run `improve-codebase-architecture`
-8. Run the guard
-9. If guard passes, run transition to advance to archive phase
-10. **Then enter `$matrix-archive` to continue the workflow**
+7. Run the guard
+8. If it passes, transition to archive and enter `$matrix-archive`
 
 ```powershell
-matrix workflow guard verify
-matrix workflow transition archive
+matrix workflow guard verify
+matrix workflow transition archive
 ```
 
 ## Evidence Requirements

package/LICENSE

@@ -1,21 +1,21 @@
-MIT License
-
-Copyright (c) 2026 Rosen
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2026 Rosen
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.