prizmkit 1.1.154 → 1.1.155

package/bundled/dev-pipeline/templates/sections/phase-commit.md

@@ -1,61 +0,0 @@
-### Architecture Sync & Commit (SINGLE COMMIT)
-
-**a.** Run `/prizmkit-retrospective` — maintains `.prizmkit/prizm-docs/` (architecture index):
-1. **Structural sync**: Use `git diff --cached --name-status` to locate changed modules, update KEY_FILES/INTERFACES/DEPENDENCIES/file counts in affected `.prizmkit/prizm-docs/` files
-2. **Architecture knowledge** (feature sessions only): Extract TRAPS/RULES/DECISIONS from completed work into `.prizmkit/prizm-docs/`
-3. **Detail-doc coverage check**: For any module/sub-module with source files created or significantly modified in this session but no detail `.prizm` doc — evaluate whether one is warranted and create it when needed. The current session has the best context for accurate KEY_FILES, TRAPS, and DECISIONS.
-4. Stage doc changes: `git add .prizmkit/prizm-docs/`
-⚠️ Do NOT commit here. Only stage.
-
-**b.** Stage all feature code explicitly (NEVER use `git add -A` or `git add .`):
-```bash
-git add <specific-files-created-or-modified>
-git add .prizmkit/prizm-docs/
-```
-
-**c.** Run `/prizmkit-committer` → THE ONLY commit for this feature:
-`feat({{FEATURE_ID}}): {{FEATURE_TITLE}}`
-This single commit includes: feature code + tests + .prizmkit/prizm-docs/ updates.
-- MANDATORY: commit must be done via `/prizmkit-committer` skill. Do NOT run manual `git add`/`git commit` as a substitute.
-- Do NOT run `update-feature-status.py` here — the pipeline runner handles feature-list.json updates automatically after session exit.
-
-**d.** Final verification:
-```bash
-git status --short
-```
-Working tree MUST be clean after this step. If any feature-related files remain, stage them explicitly and amend the SAME commit with `git commit --amend --no-edit`; do NOT create a separate commit.
-
-**e.** Write completion summary for downstream dependency context:
-
-Write `.prizmkit/specs/{{FEATURE_SLUG}}/completion-summary.json` with the key changes from this session. This file is NOT committed to git — the pipeline runner reads it to propagate context to dependent features.
-
-```json
-{
-  "completion_notes": [
-    "<each item: one key change, API, model, or integration point that downstream features may need>",
-    "Example: Added User model (id, email, password_hash, display_name) in prisma/schema.prisma",
-    "Example: POST /api/auth/register and POST /api/auth/login endpoints in src/api/auth.ts",
-    "Example: Auth middleware in src/middleware/auth.ts — validates JWT on protected routes"
-  ]
-}
-```
-
-Rules for writing completion notes:
-- Focus on **what downstream features need to know**: new APIs, models, exported functions, key file paths
-- Each note should be self-contained and concise (one line, under 120 characters preferred)
-- Include 3-8 notes covering the most important changes
-- Do NOT include test files, config changes, or internal implementation details unless they affect other features
-- If this feature has no downstream dependents, still write the summary (it serves as documentation)
-
-
-
-### TERMINAL STOP — Commit Completed
-
-After all of the following are true, the session is **TERMINAL**:
-
-- `/prizmkit-committer` has completed
-- `git status --short` is clean (except ignored/local-only pipeline artifacts)
-- `.prizmkit/specs/{{FEATURE_SLUG}}/completion-summary.json` is written
-- the `prizmkit-committer` checkpoint is marked `completed`
-
-At that point, stop immediately. Do **not** process delayed normal-work results, edit files, amend the commit, or start any new tool calls. Code Review must end its optional Reviewer lifecycle before Final Result, so no independent-review response remains pending. Any normal-work result that arrives after S09 is completed is follow-up work for a later session, not part of this feature commit.

package/bundled/dev-pipeline/templates/sections/phase-context-snapshot-agent-suffix.md

@@ -1,24 +0,0 @@
-   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from the loaded Prizm docs. Do NOT copy complete documentation files — the orchestrator already loaded them.
-   - **Section 4 — File Manifest**: For each file, list: path, why needed, and a **key-content summary** so you do NOT need to re-read the file. Format depends on file type:
-     - **Code files** (JS/TS/Python/Go): function signatures. Example: `config` (Zod object), `loadConfig(path)→Config`.
-     - **Shell scripts** (`.sh`): command-line args, key behavior branches, sourced libs, critical line ranges. Example: `args: --feature-id; sources lib/common.sh; lines 120-180 worktree logic`.
-     - **Config/manifest** (`package.json`, `tsconfig.json`, `.env`): key scripts/fields/deps/env vars. Example: `scripts:{dev,test}, deps:{vitest}, env:USE_WORKTREE`.
-     - **Docs/README**: section headings + 2-3 relevant sections only.
-     - **Test files**: test names + what each tests (1 line each).
-     Format:
-     ### Files to Modify
-     | File | Why Needed | Key Content Summary |
-     |------|-----------|---------------------|
-     | `<src>/config.js` | Add config layer | `config`, `configSchema`, `loadConfig(p)→Config` |
-     | `dev-pipeline/run-feature.sh` | Remove shell entry | args:--feature-id; lines 120-180 worktree |
-
-     ### Files for Reference
-     | File | Why Needed | Key Content Summary |
-     |------|-----------|---------------------|
-     | `<src>/permission-guard.js` | Perm check | `checkPermission(uid,cmd)→bool` |
-     | `package.json` | Test cmd+deps | scripts:{test:vitest}, deps:{vitest} |
-
-     ### Known TRAPS (from .prizmkit/prizm-docs/)
-     - <trap entries extracted from the loaded Prizm docs>
-
-

package/bundled/dev-pipeline/templates/sections/phase-context-snapshot-lite-suffix.md

@@ -1,12 +0,0 @@
-   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from the loaded Prizm docs that apply to files in this scope. Do NOT copy complete documentation files.
-   - **Section 4 — File Manifest**: For each relevant file, list path, why needed, key interface signatures. Use table format:
-
-     ### Files to Modify
-     | File | Why Needed | Key Interfaces |
-     |------|-----------|----------------|
-
-     ### Files for Reference
-     | File | Why Needed | Key Interfaces |
-     |------|-----------|----------------|
-
-

package/bundled/dev-pipeline/templates/sections/phase-implement-agent.md

@@ -1,44 +0,0 @@
-### Implement — Plan Execution
-
-Execute the reviewed plan through the active implementation skill. The skill and runtime determine the execution topology; preserve the shared artifact directory, active checkout, and task checkpoints.
-
-Before starting, check plan.md Tasks:
-```bash
-{{RUNTIME_HELPER_CMD}} text count .prizmkit/specs/{{FEATURE_SLUG}}/plan.md --pattern "- [ ]"
-```
-- If result is `0` (all tasks already `[x]`) → **SKIP to Review**.
-- If non-zero → execute the remaining tasks below.
-
-**Build artifacts rule**: After any build/compile command, ensure output is in `.gitignore`. Never commit binaries/build output.
-
-**3a.** Run `/prizmkit-implement` directly:
-- Continue from the `spec.md` / `plan.md` / `context-snapshot.md` content you created in Phase 1-2; do not re-read self-authored artifacts just because implementation starts
-- Re-read `plan.md` or `context-snapshot.md` only when resuming/continuing, when current context was compacted or lost, or when task checkbox state may have changed outside this session
-- Follow the implementation skill's current execution and delegation contract
-- Use context-snapshot.md Section 4 File Manifest for targeted source reads; avoid re-reading source files already summarized there unless they changed after the snapshot
-- Implements task-by-task, marking each `[x]` immediately
-- Remember to update checkpoints after finishing a series of tasks
-
-**3b. Focused checks only (no test gate here)**:
-- During implementation, do not run mandatory periodic or full-suite tests.
-- If a tiny targeted check is needed to understand a local failure, run only the smallest relevant command and capture output to `/tmp/test-out.txt`.
-- The scoped feature test gate runs after code review; do not declare implementation success based on an early full-suite run.
-
-**3c. Verification Gate Self-Check (BLOCKING — before declaring implement done)**:
-For each Verification Gate from the Task Contract, write one evidence line to Implementation Log:
-```
-### Gate Evidence
-- [x] G1: <gate text> — Evidence: <test name / file:line / fixture path>
-- [ ] G3: <gate text> — BLOCKED: <reason>  ← no evidence = BLOCKED, not success
-```
-
-**3d.** Append `## Implementation Log` (with Gate Evidence) to `context-snapshot.md`:
-- files changed/created
-- key decisions
-- deviations from plan
-- test results
-- Gate Evidence section
-- unresolved blockers
-
-**CP-2**: All tasks `[x]`, Implementation Log written with Gate Evidence, and blocked gates documented in `failure-log.md`. Test execution is deferred until after code review.
-

package/bundled/dev-pipeline/templates/sections/phase-implement-lite.md

@@ -1,25 +0,0 @@
-### Implement
-
-**Protocol references**:
-- Follow Context Budget Rules §8 for scaffold/generated files.
-- Follow Context Budget Rules §9 before package install/build commands that resolve dependencies.
-- Follow Context Budget Rules §10 after build/compile commands.
-
-**3a.** Run `/prizmkit-implement` — this handles the implementation cycle:
-- Continue from the plan/context you just created; do not re-read self-authored artifacts just because implementation starts
-- Re-read plan.md or `context-snapshot.md` only when resuming/continuing, when current context was compacted or lost, or when task checkbox state may have changed outside this session
-- If implementation is delegated to a subagent, the subagent must read `plan.md` and `context-snapshot.md` before editing
-- Uses context from `context-snapshot.md` (Prizm docs, TRAPS, file manifest) for targeted source reads; avoid re-reading source files already summarized there unless they changed after the snapshot
-- Implements task-by-task, marking each `[x]` immediately
-- Creates/updates detail `.prizm` docs when creating new modules or significantly modifying existing ones — AI selectively decides which modules warrant detail documentation based on complexity and importance
-- Does not run the scoped/full test gate; testing happens after code review in the PrizmKit Test phase
-- Writes '## Implementation Log' to `context-snapshot.md`
-
-**3b.** After implement completes, verify:
-1. All tasks in plan.md are `[x]`
-2. Verify each Verification Gate from the Task Contract using code/file evidence already in context — do NOT re-read files you already wrote
-3. If any gate is unmet or blocked, write `failure-log.md` and stop for recovery
-
-**CP-2**: Implementation may proceed only when all tasks are `[x]` and blocked gates are documented in `failure-log.md`. Test execution is deferred until after code review.
-
-

package/bundled/dev-pipeline/templates/sections/phase-plan-agent.md

@@ -1,20 +0,0 @@
-### Plan & Tasks
-
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists .prizmkit/specs/{{FEATURE_SLUG}}/plan.md
-```
-
-If missing, run `/prizmkit-plan` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` to generate `plan.md`:
-- The plan.md should include: architecture — components, interfaces, data flow, files to create/modify, testing approach, and a Tasks section with `[ ]` checkboxes ordered by dependency.
-- Resolve uncertain requirements from the feature description, existing code, and conservative existing-project patterns.
-
-**Database Design Gate** (if feature involves data persistence — new tables, schema changes, new entities):
-Before proceeding past CP-1, verify:
-1. Plan.md Data Model section references existing schema/model files (scan for `*.prisma`, `*.sql`, `migrations/`, `models/`, `*.entity.*` files; read them if not already in context-snapshot)
-2. All new tables/fields follow existing naming conventions, ID strategy, timestamp patterns, and constraint style
-3. No unresolved data model uncertainty remains in the Data Model section — resolve by reading existing code and making a conservative choice that matches existing patterns. Document the resolution in plan.md.
-4. If a DB design decision genuinely cannot be resolved from existing code alone, document the assumption made and flag it in the Implementation Log for user review.
-
-**CP-1**: plan.md exists with Tasks section.
-
-

package/bundled/dev-pipeline/templates/sections/phase-plan-lite.md

@@ -1,20 +0,0 @@
-### Plan & Tasks
-
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists .prizmkit/specs/{{FEATURE_SLUG}}
-```
-
-If plan.md missing, run `/prizmkit-plan` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`:
-- Pass the Objective and Verification Gates from the Task Contract as input
-- The plan.md should include: key components, data flow, files to create/modify, and a Tasks section with `[ ]` checkboxes (each task = one implementable unit). Keep under 80 lines.
-- Resolve uncertain requirements from the feature description, existing code, and conservative existing-project patterns.
-
-**Database Design Gate** (if feature involves data persistence — new tables, schema changes, new entities):
-Before proceeding past CP-1:
-1. Scan for existing schema files (`*.prisma`, `*.sql`, `migrations/`, `models/`, `*.entity.*`) and read them
-2. Ensure new tables/fields follow existing naming conventions and constraint patterns
-3. Resolve all uncertain DB design decisions before writing Tasks — document choices in plan.md
-
-**CP-1**: plan.md exists with Tasks section.
-
-

package/bundled/dev-pipeline/templates/sections/phase-review-agent.md

@@ -1,20 +0,0 @@
-### Review — Code Review
-
-Review the completed implementation before the scoped feature test gate runs. Use `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` so `/prizmkit-code-review` can read the spec, plan, context snapshot, implementation log, and current diff. Follow the skill's current review contract for review execution, repairs, verification, evidence, and handoff. Do not invoke another review skill or add a second review path outside that contract.
-
-Missing required evidence, an unsafe repair, a failed verification, or failure to converge by the contract's review limit produces `NEEDS_FIXES`.
-
-**Gate Check — Final Review Result**:
-
-```bash
-{{RUNTIME_HELPER_CMD}} text final-verdict .prizmkit/specs/{{FEATURE_SLUG}}/review-report.md
-```
-
-Handle the marker:
-
-- `REVIEW_PASS` → proceed to next phase.
-- `REVIEW_NEEDS_FIXES` → log unresolved findings and follow the task failure policy; do not externally restart the review loop.
-- `REVIEW_INCOMPLETE` or `REVIEW_INVALID` → inspect the append-only progress once, write `failure-log.md`, and stop. Do not treat an old or incidental verdict as completion and do not synthesize a passing result outside the skill.
-
-**CP-3**: Review has a valid Final Result and `review-report.md` preserves this execution's progress.
-

package/bundled/dev-pipeline/templates/sections/refactor-artifacts.md

@@ -1,17 +0,0 @@
-## Refactor Artifacts Directory
-
-Use only this durable artifact directory for this refactor:
-
-```text
-.prizmkit/refactor/{{REFACTOR_ID}}/
-├── spec.md
-├── plan.md
-├── context-snapshot.md
-├── review-report.md
-├── refactor-report.md
-├── completion-summary.json
-├── failure-log.md
-└── workflow-checkpoint.json
-```
-
-Do not write refactor artifacts under feature or bugfix artifact directories.

package/bundled/dev-pipeline/templates/sections/refactor-session-status.md

@@ -1,28 +0,0 @@
-### Step 3: Report Session Status
-
-Before exiting, write the session status file:
-
-`{{SESSION_STATUS_PATH}}`
-
-```json
-{
-  "session_id": "{{SESSION_ID}}",
-  "refactor_id": "{{REFACTOR_ID}}",
-  "status": "<success|partial|failed>",
-  "completed_phases": [1, 2, 3, 4],
-  "current_phase": 4,
-  "checkpoint_reached": "<current checkpoint step>",
-  "errors": [],
-  "can_resume": false,
-  "resume_from_phase": null,
-  "artifacts": {
-    "spec_path": ".prizmkit/refactor/{{REFACTOR_ID}}/spec.md",
-    "plan_path": ".prizmkit/refactor/{{REFACTOR_ID}}/plan.md",
-    "report_path": ".prizmkit/refactor/{{REFACTOR_ID}}/refactor-report.md",
-    "completion_summary_path": ".prizmkit/refactor/{{REFACTOR_ID}}/completion-summary.json"
-  },
-  "git_commit": "<commit hash>",
-  "behavior_preserved": true,
-  "timestamp": "{{TIMESTAMP}}"
-}
-```

package/bundled/dev-pipeline/templates/sections/test-failure-recovery-agent.md

@@ -1,52 +0,0 @@
-## Test Failure Recovery Protocol
-
-Use this protocol whenever the post-review PrizmKit Test gate fails. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
-
-### Failure Classes
-
-| Class | Meaning | Required Action | May Continue? |
-|-------|---------|-----------------|---------------|
-| Baseline failure | Existed before this session | Document in the Implementation Log or `failure-log.md` | Yes |
-| New regression | Introduced by this session | Fix before reporting success | No |
-| Brittle test | Test expectation/setup is wrong for the intended behavior | Fix the test or environment setup, then rerun | Only after fixed or documented as blocked |
-| Environment/tooling failure | External tool, network, install, or local environment prevents verification | Document in `failure-log.md` with impact on gates | Only if no Verification Gate is blocked |
-
-### Recovery Loop
-
-1. Run tests and record: failing test names, failure count, and class for each failure.
-2. Compare with `BASELINE_FAILURES`; never blame baseline failures on this feature.
-3. Fix new regressions and brittle tests while progress is being made.
-4. Stop after a plateau: same failure count and same failing tests for 3 consecutive rounds.
-5. If failures decrease, reset the plateau counter.
-
-### Hard Round Cap (BLOCKING)
-
-After **6 total test-fix rounds**, STOP trial-and-error. Write failure-log listing all hypotheses tried. Switch to: locate an anchor with `{{RUNTIME_HELPER_CMD}} text search <file> --pattern "<anchor>" --json`, read one bounded relevant source section with the platform file-reading tool (never full Read), understand control flow, rewrite failing block in one shot. Do NOT exceed 7 total rounds.
-
-### Success Rule
-
-Proceed to retrospective/commit only when:
-
-1. all new regressions are fixed;
-2. baseline failures are documented;
-3. every Verification Gate is verified.
-
-Blocked gates are not success. If any gate cannot be verified, follow the Blocked Rule.
-
-### Blocked Rule
-
-If a remaining failure prevents any Verification Gate from being verified, the feature is incomplete. Write `failure-log.md` and do not report success.
-
-### Failure Capture Format
-
-```markdown
-## Test Failures Encountered
-
-- **Test**: [test name/path]
-  - Root Cause: [explanation]
-  - Category: [baseline failure | new regression | brittle test | environment/tooling]
-  - Rounds Attempted: [N rounds, plateau at round M]
-  - Status: [fixed | still failing | blocked]
-
-- **Impact on Verification Gates**: [verified | not affected | blocked + reason]
-```

package/bundled/dev-pipeline/templates/sections/test-failure-recovery-lite.md

@@ -1,52 +0,0 @@
-## Test Failure Recovery Protocol
-
-Use this protocol whenever the post-review PrizmKit Test gate fails. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
-
-### Failure Classes
-
-| Class | Meaning | Required Action | May Continue? |
-|-------|---------|-----------------|---------------|
-| Baseline failure | Existed before this session | Document in Implementation Log | Yes |
-| New regression | Introduced by this session | Fix before reporting success | No |
-| Brittle test | Test expectation/setup is wrong for the intended behavior | Fix the test or environment setup, then rerun | Only after fixed or documented as blocked |
-| Environment/tooling failure | External tool, network, install, or local environment prevents verification | Document in `failure-log.md` with impact on gates | Only if no Verification Gate is blocked |
-
-### Recovery Loop
-
-1. Run tests and record: failing test names, failure count, and class for each failure.
-2. Compare with `BASELINE_FAILURES`; never blame baseline failures on this feature.
-3. Fix new regressions and brittle tests while progress is being made.
-4. Stop after a plateau: same failure count and same failing tests for 3 consecutive rounds.
-5. If failures decrease, reset the plateau counter.
-
-### Hard Round Cap (BLOCKING)
-
-After **6 total test-fix rounds**, STOP trial-and-error. Write failure-log listing all hypotheses tried. Switch to: locate an anchor with `{{RUNTIME_HELPER_CMD}} text search <file> --pattern "<anchor>" --json`, read one bounded relevant source section with the platform file-reading tool (never full Read), understand control flow, rewrite failing block in one shot. Do NOT exceed 7 total rounds.
-
-### Success Rule
-
-Proceed only when:
-
-1. all new regressions are fixed;
-2. baseline failures are documented;
-3. every Verification Gate is verified.
-
-Blocked gates are not success. If any gate cannot be verified, follow the Blocked Rule.
-
-### Blocked Rule
-
-If a remaining failure prevents any Verification Gate from being verified, the feature is incomplete. Write `failure-log.md` and do not report success.
-
-### Failure Capture Format
-
-```markdown
-## Test Failures Encountered
-
-- **Test**: [test name/path]
-  - Root Cause: [explanation]
-  - Category: [baseline failure | new regression | brittle test | environment/tooling]
-  - Rounds Attempted: [N rounds, plateau at round M]
-  - Status: [fixed | still failing | blocked]
-
-- **Impact on Verification Gates**: [verified | not affected | blocked + reason]
-```

package/bundled/skills/prizmkit-code-review/references/workflow-state-protocol.md

@@ -1,174 +0,0 @@
-# PrizmKit Workflow State Protocol
-
-`workflow-state.json` is lifecycle metadata for one formal requirement. It preserves stage handoff, orchestrator ownership, and resume information without replacing skill-owned artifacts or any host-owned execution checkpoint.
-
-## Location and Identity
-
-```text
-.prizmkit/state/workflows/<requirement-slug>.json
-```
-
-The active `artifact_dir` is preserved exactly across every stage:
-
-```text
-.prizmkit/specs/<requirement-slug>/
-.prizmkit/bugfix/<bug-id>/
-.prizmkit/refactor/<refactor-id>/
-```
-
-Never select another recent plan when resuming. Any external execution checkpoint remains separate from this state. Never merge, substitute, or infer one schema from the other.
-
-## Authority
-
-The state file is an index, not the authority for stage completion:
-
-| Information | Authority |
-|---|---|
-| Requirement goals and acceptance criteria | `{artifact_dir}/spec.md` |
-| Implementation tasks and completion | `{artifact_dir}/plan.md` plus current workspace |
-| Review findings and result | `{artifact_dir}/review-report.md` |
-| Test semantics and native execution | `{artifact_dir}/test-report.md` |
-| Terminal testing result | `{artifact_dir}/test-result.json` |
-| Retrospective completion | `{artifact_dir}/retrospective-result.json` |
-| Durable architecture knowledge | `.prizmkit/prizm-docs/` |
-| Local commit | Git history and confirmed or authorized commit identity |
-| Current stage, orchestrator, and resume entry | Workflow state |
-| External orchestration progress | External host checkpoint |
-
-Every consumer compares workflow state with the skill-owned artifacts and current workspace. Missing or stale state is reconstructed from those sources and is never accepted as success by itself.
-
-## Schema
-
-```json
-{
-  "schema_version": 1,
-  "artifact_dir": ".prizmkit/specs/example",
-  "orchestrator": "prizmkit-workflow",
-  "stage": "test",
-  "status": "completed",
-  "stage_result": "TEST_PASS",
-  "completed_stages": ["plan", "implement", "code-review", "test"],
-  "repair_scope": null,
-  "repair_round": 0,
-  "next_stage": "retrospective",
-  "resume_from": "prizmkit-retrospective"
-}
-```
-
-### Fields
-
-| Field | Meaning |
-|---|---|
-| `schema_version` | State schema version. |
-| `artifact_dir` | Generic requirement artifact root reused by every stage. |
-| `orchestrator` | Semantic coordinator identifier, or null for direct stage use. |
-| `stage` | Stage that most recently wrote state. |
-| `status` | Lifecycle status: `pending`, `in_progress`, `completed`, `failed`, or `skipped`. |
-| `stage_result` | Domain result for the current stage, such as `PLAN_READY`, `IMPLEMENTED`, `REVIEW_PASS`, `REVIEW_NEEDS_FIXES`, `TEST_*`, `RETRO_COMPLETE`, or `COMMITTED`. |
-| `completed_stages` | Ordered stages completed for this requirement. |
-| `repair_scope` | Optional caller-owned routing scope. The test skill reports high-risk repairs through `test-result.json` instead of scheduling another stage. |
-| `repair_round` | Optional outer cross-stage repair round, from 0 through 3. It is not a test-internal repair counter. |
-| `next_stage` | Next semantic stage, or null when stopped. |
-| `resume_from` | Exact atomic skill that can resume, or null when none is selected. |
-
-`status` and `stage_result` are deliberately separate. Lifecycle status values must never be replaced with domain result values.
-
-## Lifecycle and Result Mappings
-
-```text
-PLAN_READY
-→ IMPLEMENTED
-→ REVIEW_PASS
-→ TEST_PASS
-→ RETRO_COMPLETE
-→ COMMIT_PENDING
-→ COMMITTED
-```
-
-No formal stage is silently optional. Domain artifacts map to workflow state as follows:
-
-```text
-plan PLAN_READY                  → status=completed,  stage_result=PLAN_READY
-plan PLAN_BLOCKED                → status=failed,     stage_result=PLAN_BLOCKED
-implementation IMPLEMENTED       → status=completed,  stage_result=IMPLEMENTED
-implementation repair/block      → status=failed,     stage_result=IMPLEMENT_REPAIR or IMPLEMENT_BLOCKED
-review-report PASS               → status=completed,  stage_result=REVIEW_PASS
-review-report NEEDS_FIXES        → status=failed,     stage_result=REVIEW_NEEDS_FIXES
-test-result TEST_PASS            → status=completed,  stage_result=TEST_PASS
-test-result TEST_NEEDS_FIXES     → status=failed,     stage_result=TEST_NEEDS_FIXES
-test-result TEST_BLOCKED         → status=failed,     stage_result=TEST_BLOCKED
-retrospective DOCS_UPDATED       → status=completed,  stage_result=RETRO_COMPLETE
-retrospective NO_DOC_CHANGE      → status=completed,  stage_result=RETRO_COMPLETE
-retrospective blocked            → status=failed,     stage_result=RETRO_BLOCKED
-commit authorization pending     → status=in_progress, stage_result=COMMIT_PENDING
-local commit confirmed           → status=completed,  stage_result=COMMITTED
-commit blocked                   → status=failed,     stage_result=COMMIT_BLOCKED
-```
-
-`DOCS_UPDATED` and `NO_DOC_CHANGE` remain retrospective artifact `result` values. The workflow `stage_result` is the retrospective stage result `RETRO_COMPLETE`.
-
-`TEST_PASS` requires both `test-report.md` and a consistent `test-result.json`. No manifest, attestation, evidence package, or test-internal checkpoint is part of this contract.
-
-## Non-Pass Results and Routing Boundary
-
-`prizmkit-test` performs its own bounded failure repair and review loops before returning. The test skill never invokes another lifecycle stage.
-
-```text
-TEST_NEEDS_FIXES
-→ known correction or required delta review remains
-→ caller decides whether and how to arrange another stage
-
-TEST_BLOCKED
-→ truth, input, safe environment, or reliable execution prevents a verdict
-→ never make speculative production edits
-→ caller or external host owns recovery policy
-```
-
-A test result is not an AI CLI session classification. `TEST_NEEDS_FIXES` and `TEST_BLOCKED` must not be rewritten as crash or infrastructure failure merely because they stop lifecycle progression.
-
-Any outer repair or continuation policy is independently owned by the caller and cannot alter the test report. The Main-Agent test review limit of ten rounds, independent Test Reviewer limit of five responses, and execution-failure repair limit of three rounds are internal to one test invocation and do not update outer counters.
-
-## Orchestrator Ownership and Handoff
-
-1. An atomic stage performs only its own stage, writes its truthful result and artifact paths, and returns control.
-2. When `orchestrator` is non-null, only that orchestrator invokes the next skill.
-3. Direct stage use may report a possible next invocation but does not claim it ran.
-4. Every handoff preserves the same `artifact_dir`.
-5. External automation invokes atomic stages directly and does not nest the composite workflow.
-6. Workflow state never replaces or absorbs an external host checkpoint.
-
-## Commit Authorization
-
-Interactive execution:
-
-```text
-committer previews intended files and message
-→ waits for explicit current-user confirmation
-→ creates the local commit
-```
-
-Trusted headless execution:
-
-```text
-trusted host explicitly authorizes the current local task commit
-→ committer verifies gates and commits automatically
-→ remote publication remains separate
-```
-
-A self-declared or untrusted headless context does not authorize a commit.
-
-## Recovery
-
-When state is missing, stale, or inconsistent:
-
-1. Reuse current context, then read `spec.md` and `plan.md` only when needed.
-2. Inspect task markers and current workspace.
-3. Read the current review report when needed to establish review authority.
-4. Validate that `test-report.md` and terminal `test-result.json` exist, agree, and reflect the claimed result.
-5. Validate `retrospective-result.json` when retrospective is claimed complete.
-6. Verify the commit when commit is claimed complete.
-7. Let an active external host validate its own checkpoint independently.
-8. Reconstruct the latest safe predecessor and report the reconstruction.
-9. Continue only from the first incomplete or invalid stage.
-
-Stale state never bypasses review, testing, retrospective, commit authorization, or external checkpoint enforcement.