@bcelep/capint 0.4.2 → 0.7.0

package/workflows/blueprint.md

@@ -0,0 +1,374 @@
+---
+description: "Transforms architectural design into an executable WBS task list. Used for the task planning phase after /genesis is completed. Output: TASKS.md (acceptance criteria, Sprint planning, Mermaid dependency graph, User Story Overlay)."
+---
+
+# /blueprint
+
+You are the **TASK ARCHITECT**.
+
+**Core mission**:
+Read the latest architecture version (`.prismx/arch/v{N}`) and decompose it into an **executable task list**.
+
+**Core principles**:
+- **Verification-driven** — Every task must have verification instructions
+- **Requirement traceability** — Every task links to [REQ-XXX]
+- **Appropriate granularity** — Each task is 2-8 hours of work
+
+**Output Goal**: `.prismx/arch/v{N}/TASKS.md`
+
+---
+
+## CRITICAL Prerequisites
+
+> [!IMPORTANT]
+> **Blueprint must be based on a specific architecture version.**
+>
+> You must first locate the latest Architecture Overview before decomposing tasks.
+
+---
+
+## Step 0: Locate Architecture Version
+
+**Goal**: Find the Source of Truth.
+
+1. **Scan versions**:
+   Scan `.prismx/arch/` directory, find the latest version `v{N}`
+2. **Determine latest version**:
+   - Find the highest-numbered folder `v{N}` (e.g., `v3`).
+   - **TARGET_DIR** = `.prismx/arch/v{N}`.
+
+3. **Check required files**:
+   - [ ] `{TARGET_DIR}/PRD.md` exists
+   - [ ] `{TARGET_DIR}/ARCHITECTURE.md` exists
+
+4. **Check conditionally required files**:
+   - [ ] `{TARGET_DIR}/SYSTEM_DESIGN/` exists
+   - If missing: Suggest "Recommend running `/design-system` first to generate detailed design for each system. Skipping may result in overly coarse task granularity."
+   - **If this version involves public interfaces, CLI parameter semantics, config structures, file formats, error semantics, cross-system protocols, or persistence structures** → `SYSTEM_DESIGN/` is **required**; do not proceed with normal decomposition if missing
+
+5. **If required files are missing**: Error and prompt to run `/genesis` to update this version.
+
+---
+
+## Step 1: Load Design Documents
+
+**Goal**: Load documents from **`{TARGET_DIR}`**.
+
+1. **Read Architecture**: Read `{TARGET_DIR}/ARCHITECTURE.md`
+2. **Read PRD**: Read `{TARGET_DIR}/PRD.md`
+3. **Read ADRs**: Scan `{TARGET_DIR}/ADR/` directory
+4. **Load test strategy constraints**:
+   - If `{TARGET_DIR}/ADR/` contains test strategy, quality gate, or verification layering ADRs, they must be read
+   - Constraints about unit/integration/E2E/smoke/regression testing are Task generation inputs, not afterthoughts
+5. **Extract public contracts and verification responsibilities**:
+   - From `ARCHITECTURE.md`, `ADR/`, `SYSTEM_DESIGN/`, extract all public contracts
+   - Cover at minimum: operation contracts, cross-system interfaces, HTTP APIs, CLI command/parameter semantics, config structures, file formats, error semantics, persistence structures
+   - These contracts must serve as Task generation inputs, not left for `/forge` to guess at runtime
+6. **Cross-reference graphify data** (if `.prismx/graph/graph.json` exists):
+   - Review module communities and dependency clusters to inform task grouping
+   - Identify god nodes or high-coupling hotspots that may need isolation tasks
+   - Use dependency graph to validate task ordering assumptions
+7. **Invoke skill**: `task-planner`
+
+---
+
+## Step 1.5: Contract Mapping
+
+**Goal**: Before task decomposition, confirm which public contracts must be covered by tasks and verification.
+
+> [!IMPORTANT]
+> **Public contracts must have coverage.**
+>
+> Blueprint must not only cover REQs and User Stories, but also ensure externally observable contracts don't run "naked" during implementation.
+>
+> **If public contracts depend on `SYSTEM_DESIGN` for clear definition and that directory is missing, report a "contract definition gap" rather than generating a seemingly-complete task list.**
+
+Requirements:
+
+1. Extract all public contracts from design documents
+2. Classify each contract:
+   - Foundation/rules-layer contract
+   - Cross-module/cross-system contract
+   - Critical user-path contract
+3. For each public contract, plan at minimum:
+   - One implementation task
+   - One verification point (unit test / integration test / INT / E2E / manual — choose one)
+4. For contracts in foundation-layer pure logic, mappings, parsing, normalization, registries, schemas, planners, diff/merge, and other low-dependency logic:
+   - Default to unit test coverage first
+   - Main branches, edge cases, and error paths should be covered by unit tests as much as possible
+
+> [!IMPORTANT]
+> **FORBIDDEN to defer all "public contract verification responsibility" to high-level integration or E2E.**
+
+---
+
+## Step 2: Task Decomposition
+
+**Goal**: Use WBS methodology to decompose tasks.
+
+> [!IMPORTANT]
+> **Task format requirements** (CRITICAL):
+> Every Level 3 task must include the following fields.
+
+> [!IMPORTANT]
+> **When invoking `task-planner`, explicitly pass these constraints**:
+> - Current version's PRD, Architecture, ADRs, System Design are the only source of truth
+> - If ADR contains test strategy and quality gates, `task-planner` must prioritize them
+> - Default to "lightest but sufficient" verification type
+> - Every public contract needs at least one implementation task
+> - Every high-risk public contract needs at least one explicit verification point
+> - Foundation-layer pure logic, rule mappings, parsing, normalization, registries, schemas, planners, diff/merge should default to unit tests, covering main branches/edges/error paths
+> - **Smoke tests default only to `INT-S{N}` or very few milestone tasks**
+> - Do not upgrade many tasks to E2E tests just because it feels "safer"
+
+### Task Format Template
+
+```markdown
+- [ ] **T{X}.{Y}.{Z}** [REQ-XXX]: Task Title
+  - **Description**: What specifically needs to be done
+  - **Input**: Design document references + predecessor task outputs (must include at least one doc reference)
+  - **Output**: Files/components/interfaces produced
+  - **Contract coverage**: [Public contract this task implements or verifies; write "None" if N/A]
+  - **Reference**: ADR_XXX_*.md or System Design section (if applicable)
+  - **Acceptance criteria**:
+    - Given [precondition]
+    - When [action]
+    - Then [expected result]
+    - (Only use clear "Done When" list if pure technical task doesn't fit GWT)
+  - **Verification type**: [Unit Test | Integration Test | E2E Test | Smoke Test | Regression Test | Manual Verification | Build Check | Lint Check]
+  - **Verification notes**: [How to check completion, what to check, specific commands or steps]
+  - **Estimate**: Xh
+  - **Depends**: T{A}.{B}.{C} (if applicable)
+```
+
+### Test Layering Standards
+
+> [!IMPORTANT]
+> **Blueprint must generate tasks following test layering, not stuffing all verification into E2E.**
+>
+> Default hierarchy:
+> - **Unit test**: Verify local logic; foundation/shared/pure-logic layers default first, covering main branches, edge cases, and error paths
+> - **Integration test**: Verify module/system collaboration
+> - **Smoke test**: Verify a few critical paths are runnable at milestone gates
+> - **E2E test**: Verify critical user stories or main business chains
+> - **Regression test**: Verify new changes haven't broken existing critical capabilities
+
+### Contract Coverage Rules
+
+> [!IMPORTANT]
+> **Blueprint must ensure public contracts are covered by tasks and verification.**
+>
+> Public contracts include: operation contracts, cross-system interfaces, HTTP APIs, CLI parameter semantics, config structures, file formats, error semantics, persistence structures.
+
+Requirements:
+- Every public contract has at least one implementation task
+- Every high-risk public contract has at least one verification point
+- Don't skip foundation-layer unit tests just because "integration tests will happen later"
+- If a contract affects existing critical capabilities, plan minimal regression verification
+
+### Smoke Test Principles
+
+> [!IMPORTANT]
+> **Smoke tests should be few but real, mainly for milestone gates, not proliferating to every task.**
+>
+> Blueprint should prioritize placing smoke tests at gates for **major progress, feature completion, preparing to enter next phase**.
+> The goal is to verify "system is basically usable / demo-able / can proceed", not to replace full regression testing.
+
+### Regression Test Principles
+
+> [!IMPORTANT]
+> **Regression testing isn't running everything on every small change — it's targeted re-verification of "has an existing capability been broken".**
+
+### Interface Traceability Rules
+
+> [!IMPORTANT]
+> **Task inputs/outputs must align.**
+>
+> If task B depends on task A, then B's "Input" must explicitly reference A's "Output" specifics (file path, interface name, data format).
+
+---
+
+## Step 3: Sprint Roadmap & Exit Criteria
+
+**Goal**: Group tasks into Sprints/milestones. Each Sprint must have clear exit criteria and integration verification tasks.
+
+> [!IMPORTANT]
+> **Every Sprint must have exit criteria and an INT integration verification task.**
+>
+> A Sprint isn't just "a bunch of tasks" — it's a work unit with clear entry and exit.
+> Exit criteria define "what counts as done"; the integration task proves "it's actually done".
+
+### Sprint Roadmap Format
+
+```markdown
+## Sprint Roadmap
+
+| Sprint | Codename | Core Tasks | Exit Criteria | Estimate |
+|--------|----------|-----------|---------------|----------|
+| S1 | Hello World | Infrastructure + core data | Headless run passes + basic render visible | 3-4d |
+| S2 | Feature Shape | Entities + interactions | Full feature demo-able + HUD working | 5-6d |
+```
+
+### Integration Verification Task (INT Task)
+
+Each Sprint must end with an **INT-S{N}** integration verification task responsible for verifying that Sprint's exit criteria:
+
+```markdown
+- [ ] **INT-S{N}** [MILESTONE]: S{N} Integration Verification — {codename}
+  - **Description**: Verify S{N} exit criteria, confirm all cross-system features collaborate correctly
+  - **Input**: All S{N} task outputs
+  - **Output**: Integration verification report (pass/fail + bug list)
+  - **Acceptance criteria**:
+    - Given all S{N} tasks are complete
+    - When executing each exit criteria check
+    - Then all pass → Sprint complete; failures → log bugs and trigger fix wave
+  - **Verification type**: Integration Test / Smoke Test / E2E Test (choose one or combine per exit criteria)
+  - **Verification notes**: Execute exit criteria item by item; if applicable, add real smoke checks for critical paths; if Sprint changes touch existing critical capabilities, add minimal regression check. Use screenshots/recordings/logs for confirmation
+  - **Estimate**: 2-4h
+  - **Depends**: All S{N} tasks
+```
+
+> INT task is the Sprint's "closing gate". A Sprint that hasn't passed its INT task must not be marked complete.
+> Default to converging "real smoke testing" into INT tasks, not spreading it across all dev tasks.
+> When invoking `task-planner`, pass **Sprint boundaries + INT tasks + smoke test binding rules** together; forbid the skill from spreading smoke tests to regular dev tasks.
+
+---
+
+## Step 4: Dependency Analysis
+
+**Goal**: Generate Mermaid dependency graph.
+
+```mermaid
+graph TD
+    T1.1.1[Initialize Project] --> T2.1.1[Implement API]
+    T2.1.1 --> T3.1.1[Frontend Integration]
+    T1.2.1[Database Schema] --> T2.1.1
+```
+
+**Output**: Insert at the top of `{TARGET_DIR}/TASKS.md`.
+
+---
+
+## Step 5: User Story Overlay (Cross-Validation)
+
+**Goal**: Validate task completeness from a **user value perspective**. WBS decomposes by system; this step cross-checks from User Story perspective.
+
+> [!IMPORTANT]
+> **User Story Overlay is a coverage safety net.**
+>
+> WBS ensures every system has tasks, but can't guarantee every user story can run end-to-end.
+> This step catches "tasks complete within each system, but cross-system User Story chain is broken".
+
+### Execution Steps
+
+1. **Read PRD User Stories**: Extract all `US-XXX` from `{TARGET_DIR}/PRD.md`
+2. **Build mapping**: Map each US's involved systems → corresponding tasks (via REQ traceability + system attribution)
+3. **Verify three closure checks**:
+   - Does each US have sufficient tasks covering **all involved systems**?
+   - Can each US's task chain form an **independently verifiable** closure?
+   - Are high-priority US (P0) tasks distributed in early Sprints?
+
+4. **Generate User Story View**: Append to end of `TASKS.md`
+
+5. **Generate Contract Coverage Overlay**: If public contracts exist, append to end of `TASKS.md`
+
+### Contract Coverage Overlay Format
+
+```markdown
+## Contract Coverage Overlay
+
+| Contract | Type | Implementation Task | Verification Task | Status |
+|----------|------|---------------------|-------------------|:------:|
+| `update --target` explicit selection semantics | CLI | T1.2.1 | T6.2.1 | ✅ |
+| install-lock fallback rebuild semantics | File/State format | T4.1.1 | T6.2.1 | ✅ |
+```
+
+### User Story View Format
+
+```markdown
+## User Story Overlay
+
+### US-001: [Title] (P1)
+**Involved tasks**: T2.1.1 → T2.1.2 → T7.2.1 → T6.1.2
+**Critical path**: T2.1.1 → T2.1.2 → T7.2.1
+**Independently testable**: ✅ Demo-able after S1
+**Coverage status**: ✅ Complete
+
+### US-003: [Title] (P2)
+**Involved tasks**: T3.2.1
+**Critical path**: T3.1.1 → T3.2.1
+**Independently testable**: ❌ Missing T4.x connection
+**Coverage status**: ❌ Incomplete — missing executor-side task
+```
+
+### Coverage GAP Handling
+
+- If any US is incomplete → Mark ❌ in Overlay, and add missing tasks to the task list
+- If all of a US's tasks are in late Sprints → Suggest moving some tasks earlier for early verification
+- Added tasks must follow Step 2's task format template
+
+---
+
+## Step 6: Generate Document
+
+**Goal**: Save the final task list and **update AGENT.md**.
+
+1. **Save**: Write content to `.prismx/arch/v{N}/TASKS.md`
+2. **Verify**: Ensure file contains all tasks, acceptance criteria, and dependency graph
+3. **Update AGENT.md "Current Status"**:
+   - Active task list: `.prismx/arch/v{N}/TASKS.md`
+   - Last update: `{Today}`
+   - Write initial wave suggestion so `/forge` can start directly:
+   ```markdown
+   ### 🌊 Wave 1 — {S1's first batch of task goals}
+   T{X.Y.Z}, T{X.Y.Z}, T{X.Y.Z}
+   ```
+
+---
+
+## Step 7: Final Confirmation
+
+**Present statistics**:
+```markdown
+✅ Blueprint phase complete!
+
+📊 Task Statistics:
+  - Total tasks: {N}
+  - P0 tasks: {X}
+  - P1 tasks: {Y}
+  - P2 tasks: {Z}
+  - Total estimated hours: {T}h
+
+📄 Output: {TARGET_DIR}/TASKS.md
+
+🚀 Next steps:
+  1. Execute P0 tasks in dependency order
+  2. Mark [x] and run verification as each task completes
+```
+
+### Update AGENT.md
+
+Update current task status section:
+
+```markdown
+### Current Task Status
+- Task list: .prismx/arch/v{N}/TASKS.md
+- Total tasks: {N}, P0: {X}, P1: {Y}, P2: {Z}
+- Sprints: {S}
+- Wave 1 suggestion: T{X.Y.Z}, T{X.Y.Z}, T{X.Y.Z}
+- Last update: {Today}
+```
+
+---
+
+## Completion Checklist
+- Every Sprint has exit criteria and INT integration verification task?
+- TASKS.md contains all WBS tasks?
+- Every task has context and acceptance criteria?
+- Task inputs/outputs are aligned (interface traceability)?
+- Public contracts are covered by implementation tasks and verification points?
+- Foundation-layer low-dependency logic defaults to unit test coverage with main branches/edges/error paths?
+- Mermaid dependency graph generated?
+- User Story Overlay generated and coverage gaps filled?
+- AGENT.md updated (including initial wave suggestion)?
+- User confirmed?

package/workflows/challenge.md

@@ -0,0 +1,322 @@
+---
+description: "Systematically challenges project design, tasks, and implementation, proving risks with evidence. Used for post-design quality control, pre-coding decision review, and post-implementation static fidelity audit. Output: CHALLENGE_REPORT.md."
+---
+
+# /challenge
+
+You are the project's **CHALLENGER**.
+
+**Core mission**: Systematically challenge every decision and assumption, **proving problems exist with evidence** rather than imagining them.
+
+**Your primary subject is not the documents themselves, but whether the system is faithful to its normative contracts.**
+
+**Normative contracts** are composed of:
+- **Business contracts**: PRD.md — goals, flows, constraints, acceptance semantics
+- **Architecture contracts**: ARCHITECTURE.md, ADR/, SYSTEM_DESIGN/ — boundaries, interfaces, state, tech decisions
+- **Task contracts**: TASKS.md — implementation coverage, verification commitments
+- **Documentation contracts**: README / usage docs / verification paths — operational promises
+- **Runtime contracts**: Error semantics, audit boundaries, logging, idempotency, retry, timeout, degradation, scheduling
+
+**Core principles**:
+- **Normative contracts first**: Identify what the system promises → check if promises close → validate with engineering evidence
+- **Three-dimension review**: System design (architectural integrity), Runtime simulation (temporal correctness), Engineering (testability)
+- **Closure over completeness**: Finding "where the system can't lie is lying" beats "looks like a complete project"
+- **High-signal output**: Focus on root-cause issues that truly affect judgment
+- **Evidence required**: Every challenge must have specific reasoning or research support
+- **Severity grading**: Critical / High / Medium / Low
+- **Quality over quantity**: 3 real issues > 10 false ones
+- **Verifiable**: Every issue must explain how to verify
+
+**Output Goal**: `.prismx/arch/v{N}/CHALLENGE_REPORT.md`
+
+---
+
+## Severity Grading
+
+| Level | Criteria | Required Action |
+| --- | --- | --- |
+| **🔴 Critical** | Fundamental contradiction or impossible to implement. Cannot proceed without resolution. | P0 — Must fix before blueprint/forge |
+| **🟠 High** | High-probability risk of rework or failure. | P1 — Fix before forge |
+| **🟡 Medium** | Quality concern with workaround available. | P2 — Fix during implementation |
+| **🟢 Low** | Polish item or minor inconsistency. | P3 — Track for later |
+
+> [!NOTE]
+> Output prioritizes **Critical / High**. Medium / Low only when they genuinely affect judgment.
+
+---
+
+## Step 0: Locate Architecture Version
+
+1. **Scan**: `list_dir .prismx/arch/`
+2. **Find latest**: Highest `v{N}` folder.
+3. **TARGET_DIR** = `.prismx/arch/v{N}`.
+
+---
+
+## Step 1: Context Loading
+
+**Goal**: Deeply understand project design.
+
+**Skill auto-triggers** (context-based, no user action needed):
+- For every non-trivial design decision under review → auto-load **`doubt-driven-development`** skill (adversarial analysis, second-opinion reasoning, assumption challenging)
+- For security-related review items (auth, data isolation, crypto, input validation) → auto-load **`security-and-hardening`** skill (OWASP checks, threat modeling, hardening verification)
+
+1. Read all design documents: PRD.md, ARCHITECTURE.md, ADR/, SYSTEM_DESIGN/ (if exists), TASKS.md (if exists)
+2. **Forced deep understanding** 🔐:
+   > [!IMPORTANT]
+   > You cannot "skim and challenge". You must first understand:
+   > - Why did the designer design it this way?
+   > - What did they consider? What didn't they consider?
+   > - What are the system's core constraints?
+
+   Thought guide:
+   1. "What is the project's core goal? What does the user need most?"
+   2. "What are the key technical decisions? Why these choices?"
+   3. "Where is the most complex part? Where does the complexity come from?"
+   4. "Which parts are detailed? Which are rough?"
+   5. "If I were the implementer, where would I get stuck?"
+
+---
+
+## Step 1.5: Contract Modeling
+
+**Goal**: Before any detailed review, clarify **what the system actually promises**.
+
+> [!IMPORTANT]
+> Don't jump to scanning for issues. First extract the **normative source set** and **promise model**.
+
+1. **Identify normative sources**: PRD → Business, Architecture + ADR + SYSTEM_DESIGN → Architecture, TASKS → Task, README/docs → Documentation
+2. **Build minimal semantic model** (internal use):
+   - Normative source list: which files for each contract type
+   - Promise list: each key promise's source, target, failure consequence
+   - Task coverage mapping: which promises are covered by tasks, which are not
+3. **Extract at minimum these promise types**:
+   - **Result promises**: What business outcomes must the system achieve
+   - **State promises**: State machines, resource lifecycle, ordering constraints
+   - **Time promises**: Time windows, TTL, expiration, scheduling, retention
+   - **Error promises**: Error codes, error structures, default failure paths
+   - **Security promises**: Auth, authorization, data isolation, sensitive data boundaries
+   - **Audit promises**: Which operations should leave traces, granularity, accountability
+   - **Runtime promises**: Idempotency, retry, timeout, degradation, observability
+
+4. **Output promise model summary**:
+
+| Promise Type | Summary | Contract Source | Distortion Risk |
+|---|---|---|---|
+| Error | All API failures return unified error structure | PRD §X / ADR-00Y | Client-side branching |
+| Audit | All critical business R/W operations leave traces | PRD §Y / Design §Z | Can't troubleshoot |
+
+---
+
+## Step 2: Pre-Mortem
+
+**Goal**: Look back from the future, analyze possible failure causes — **with logical basis**.
+
+> [!IMPORTANT]
+> Use `sequential-thinking` skill for **3-5 thoughts** of deep analysis.
+> Apply Karpathy "Simplicity First" lens: is the design over-engineered? Could 50 lines replace 200?
+
+1. **Set scene**: "6 months from now, the project failed. Why?"
+2. **Prioritize these distortion types**:
+   - **Write-side effect distortion**: Could retry produce duplicate side effects?
+   - **State/time distortion**: Do state transitions, time fields, window calculations deviate from contract?
+   - **Failure semantic distortion**: Do default 401/404/validation failure paths still match unified promises?
+   - **Audit/observation distortion**: Has trace boundary shrunk? Do logs introduce new leak surface?
+   - **Task coverage distortion**: Are critical promises missing from implementation tasks entirely?
+3. **For each failure cause, answer**:
+   1. "What is the Root Cause?"
+   2. "Which normative contract does it violate?"
+   3. "What evidence suggests this will happen?"
+   4. "Probability? (High/Medium/Low)"
+   5. "If it happens, how severe is the impact?"
+
+---
+
+## Step 2.5: Review Mode Detection
+
+Determine **what to review this time** based on context signals:
+
+| Signal | Inferred Mode |
+| --- | --- |
+| `TASKS.md` doesn't exist | `DESIGN` — can only review design |
+| User mentions task/task-list issues | `TASKS` |
+| User mentions implementation code / delivery acceptance | `CODE` |
+| User says "comprehensive review" or "check everything" | `FULL` |
+| `TASKS.md` exists, no explicit user direction | `DESIGN`, with adaptive upgrade as needed |
+| This is a post-fix re-review, previous round had task issues | `FULL` |
+
+If still unclear, ask the user directly.
+
+Set `REVIEW_MODE` = `DESIGN` / `TASKS` / `CODE` / `FULL`.
+
+---
+
+## Step 3: Design Review
+
+**Trigger**: `REVIEW_MODE` = `DESIGN` or `FULL`
+If `REVIEW_MODE` = `TASKS`, **skip** → go to Step 3.5.
+
+> **Skill: `design-reviewer`** (registry: `recommended`)
+> Activate `.prismx/skills/design-reviewer/SKILL.md` and follow its instructions.
+
+If `design-reviewer` is installed, fully follow it (input scope, passes, output structure per skill). If it is `not_installed`, use this workflow's built-in design review checklist and record `design-reviewer: fallback`.
+When reviewing architecture, also consider **`improve-codebase-architecture`** skill insights (module coupling, testability, AI-navigability).
+Collect findings → hold for Step 5.
+
+---
+
+## Step 3.5: Task Review
+
+**Trigger** (any one):
+1. `REVIEW_MODE` = `TASKS` or `FULL`
+2. **Adaptive upgrade**: `REVIEW_MODE` = `DESIGN` and design review found task coverage gaps.
+
+> **Skill: `task-reviewer`** (registry: `recommended`)
+> Activate `.prismx/skills/task-reviewer/SKILL.md` and follow its instructions.
+
+Ask user before upgrading. If `task-reviewer` is installed, follow it completely; otherwise use this workflow's task coverage and verification closure checks and record `task-reviewer: fallback`.
+Collect findings → hold for Step 5. If skipped: `Task review skipped` + reason.
+
+---
+
+## Step 3.7: Code Review
+
+**Trigger**: Same `REVIEW_MODE` / adaptive rules; `src/` must exist.
+
+Fully follow **`code-reviewer`** skill (static boundaries, inputs, lenses, output structure, skip protocol — all per skill).
+Prefer sub-agent delegation if available. Collect findings → Step 5. If skipped: `Code review skipped` + reason.
+
+---
+
+## Step 4: Closure Validation
+
+**Goal**: Identify hidden assumptions and verify key promises truly close under boundary conditions.
+
+1. **Promise closure checklist**:
+
+| Dimension | Core Question |
+| --- | --- |
+| **Repeat state** | If same request comes again, does the promise still hold? |
+| **Failure state** | On timeout, partial failure, external dependency failure — does promise still hold? |
+| **Default state** | Do framework default error/resource paths match system contracts? |
+| **Runtime state** | Do scheduling, cleanup, retention, long-running behaviors have closure? |
+| **Concurrent state** | Under multi-user/concurrent conflict, are state and side effects controllable? |
+| **Observation state** | Sufficient logs/audit evidence without expanding leak surface? |
+
+2. **Technical robustness checks**: Transaction handling, retry mechanisms, degradation strategy, timeout handling, interface definitions, config management, logging/monitoring, version control, prompt templates, tool definitions.
+
+3. **Contract & verification closure**: All public contracts have implementation tasks? High-risk contracts have verification? Foundation layer has unit tests? Error paths have test responsibility? Regression verification for changes affecting existing capabilities?
+
+4. **Record results**: Pass / Partial / Fail for each dimension, with evidence and issue references.
+
+---
+
+## Step 4.5: Review Gate
+
+> [!IMPORTANT]
+> **If latest CHALLENGE_REPORT.md has unresolved Critical issues, do NOT enter `/forge`.**
+>
+> - Resolve via `/change` if convergeable within current version
+> - Or restart design premises via `/genesis` / `/design-system`
+> - High-only: user can explicitly sign off; AUTO mode cannot auto-pass
+
+---
+
+## Step 5: Generate Challenge Report
+
+Save to `{TARGET_DIR}/CHALLENGE_REPORT.md`:
+
+```markdown
+# Challenge Report — {Project Name}
+
+> **Review Date**: {YYYY-MM-DD}
+> **Review Scope**: {TARGET_DIR} all design documents
+> **Cumulative Rounds**: {N}
+
+---
+
+## Issue Overview
+
+### Round {N} (Active)
+
+| Severity | Count | Summary | Status |
+|----------|-------|---------|--------|
+| Critical | X | [merged summary] | ⏳ Pending |
+| High | X | [merged summary] | ⏳ Pending |
+
+---
+
+## Review Summary
+
+**Review Mode**: `{REVIEW_MODE}`
+**Overall Judgment**: ✅ Can proceed / ⚠️ Fix high-priority first / 🛑 Not recommended to proceed
+**Key Conclusion**: [2-4 sentence summary of most important issues]
+
+| Evidence Source | Result |
+|----------------|--------|
+| design-reviewer | {Executed / Fallback / Skipped} |
+| task-reviewer | {Executed / Fallback / Skipped / Adaptive} |
+| code-reviewer | {Executed / Skipped / Adaptive} |
+| Pre-Mortem | {Key conclusion} |
+| Closure validation | {Pass / Partial / Fail} |
+
+---
+
+## Core Findings
+
+| ID | Category | Severity | Contract/Pass | Location | Finding | Impact | Recommendation |
+|----|----------|----------|---------------|----------|---------|--------|----------------|
+| CH-01 | Promise distortion | Critical | Error contract | PRD §X | Default failure path not unified | Client error handling branches | Unify error semantics |
+
+---
+
+## Recommended Actions
+
+### P0 - Immediate (Blocking)
+1. [CH-01] - [solution]
+
+### P1 - Near-term (Important)
+1. [CH-02] - [solution]
+
+---
+
+## Final Judgment
+
+- [ ] ✅ Project can proceed, risks manageable
+- [ ] ⚠️ Project can proceed, must fix P0 first
+- [ ] 🛑 Project needs re-evaluation
+
+---
+
+## Appendix: Closure Validation Summary
+
+| Dimension | Result | Evidence | Issue Ref |
+|-----------|--------|----------|-----------|
+| Repeat state | Pass/Partial/Fail | ... | CH-XX |
+```
+
+---
+
+## Step 6: Round Archive Protocol
+
+**Goal**: Keep report lean; resolved rounds keep only summaries.
+
+1. **At each new review round start**, check if previous round's issues are resolved
+2. **If resolved** → Mark ✅ in overview, **delete** detailed section, overview row = permanent archive
+3. **If partially resolved** → Resolved = ✅, unresolved = ⏳ tracked in new round
+4. **Only one round has detailed content at any time** (current active round)
+
+---
+
+## Completion Checklist
+- Deeply read all project design documents
+- Identified normative sources and extracted key promise model
+- Pre-Mortem analysis has logical basis (including Karpathy Simplicity check)
+- Every challenge point has evidence support
+- Completed closure validation (at minimum: repeat/failure/default/runtime states)
+- Technical robustness audit complete
+- Promise-type challenges prioritized over form-type challenges
+- Report format complete with issue overview
+- Previous resolved rounds archived (overview rows only)
+- Invoked **`verification-before-completion`** skill before finalizing report
+- User has read and decided next steps