all-for-claudecode 2.1.0 → 2.2.1

package/.claude-plugin/marketplace.json

@@ -6,14 +6,14 @@
   },
   "metadata": {
     "description": "Automated pipeline for Claude Code — spec → plan → implement → review → clean",
-    "version": "2.1.0"
+    "version": "2.2.1"
   },
   "plugins": [
     {
       "name": "afc",
       "source": "./",
       "description": "Automated pipeline for Claude Code. Automates the full development cycle: spec → plan → implement → review → clean.",
-      "version": "2.1.0",
+      "version": "2.2.1",
       "category": "automation",
       "tags": ["pipeline", "automation", "spec", "plan", "implement", "review", "critic-loop"]
     }

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "afc",
-  "version": "2.1.0",
+  "version": "2.2.1",
   "description": "Automated pipeline for Claude Code. Automates the full development cycle: spec → plan → implement → review → clean.",
   "author": { "name": "jhlee0409", "email": "relee6203@gmail.com" },
   "homepage": "https://github.com/jhlee0409/all-for-claudecode",

package/README.md

@@ -1,82 +1,103 @@
+<div align="center">                                                                                                                                        
+  <img src="https://github.com/user-attachments/assets/9e23029e-e326-4cfa-b329-3bdd1006aecd" alt="all-for-claudecode" width="640" />                        
+</div>
+
 # all-for-claudecode
 
 **Claude Code plugin that automates the full development cycle — spec → plan → implement → review → clean.**
 
 [![npm version](https://img.shields.io/npm/v/all-for-claudecode)](https://www.npmjs.com/package/all-for-claudecode)
+[![npm downloads](https://img.shields.io/npm/dm/all-for-claudecode)](https://www.npmjs.com/package/all-for-claudecode)
 [![license](https://img.shields.io/github/license/jhlee0409/all-for-claudecode)](./LICENSE)
-[![test](https://img.shields.io/badge/tests-125%20passed-brightgreen)](#how-it-works)
-[![hooks](https://img.shields.io/badge/hooks-15%20events-blue)](#15-hook-events)
-[![commands](https://img.shields.io/badge/commands-18-orange)](#18-slash-commands)
-
-> Zero-dependency automation pipeline for Claude Code. One command (`/afc:auto`) runs the entire cycle: write specs, design plans, implement code, review quality, and clean up — all with built-in CI gates and critic loops.
-
-## What is all-for-claudecode?
-
-all-for-claudecode is a **Claude Code plugin** that transforms your development workflow into a fully automated pipeline. Instead of manually prompting Claude through each development phase, you run a single command and the pipeline handles everything — from writing feature specifications to final code review.
+[![test](https://img.shields.io/badge/tests-passing-brightgreen)](#how-it-works)
 
-- **18 slash commands** for every phase of development
-- **15 hook events** with 3 handler types (shell scripts, LLM prompts, subagents)
-- **5 project presets** for popular stacks (Next.js, React SPA, Express API, Monorepo)
-- **Persistent memory agents** that learn across sessions
-- **Built-in CI gates** that physically prevent skipping quality checks
+> One command (`/afc:auto`) runs the entire cycle. Zero runtime dependencies — pure markdown commands + bash hook scripts.
 
 ## Quick Start
 
-### Option A: Inside Claude Code (`/plugin`)
-
-```
+```bash
+# Option A: Inside Claude Code
 /plugin marketplace add jhlee0409/all-for-claudecode
 /plugin install afc@all-for-claudecode
-```
 
-Or use the interactive UI: type `/plugin` → Manage → Add marketplace → `jhlee0409/all-for-claudecode` → Discover → install **afc**.
-
-### Option B: One-line install (via npx)
-
-```bash
+# Option B: npx
 npx all-for-claudecode
 ```
 
-Interactive installer — choose scope (user / project / local) and done.
-
-### Option C: Claude Code CLI
-
-```bash
-claude plugin marketplace add jhlee0409/all-for-claudecode
-claude plugin install afc@all-for-claudecode --scope user
-```
-
-### Then, inside Claude Code:
+Then:
 
 ```
 /afc:init                              # Detect your stack, generate config
 /afc:auto "Add user authentication"    # Run the full pipeline
 ```
 
-That's it. The pipeline will:
+The pipeline will:
 1. Write a feature spec with acceptance criteria
-2. Design an implementation plan with file change map and dependency graph
-3. Implement each task with CI verification (tasks auto-generated from plan)
-4. Run a code review with security scan
+2. Design an implementation plan with file change map
+3. Implement tasks with CI gates (auto task decomposition + parallel execution)
+4. Run code review with architecture/security agent analysis
 5. Clean up artifacts and prepare for commit
 
-## Features
+## How It Works
+
+```
+/afc:auto "Add feature X"
+
+Spec (1/5) → Plan (2/5) → Implement (3/5) → Review (4/5) → Clean (5/5)
+  │              │              │                │              │
+  │              │              │                │              └─ Artifact cleanup
+  │              │              │                └─ 8 perspectives + agent review
+  │              │              └─ Auto task decomposition, parallel execution, CI gates
+  │              └─ File change map, ADR recording, research persistence
+  └─ Acceptance criteria, pre-implementation gates
+
+Hooks run automatically at each step.
+CI failure → debug-based RCA (not blind retry).
+Critic Loops verify quality at each gate until convergence.
+```
 
-### Full Auto Pipeline
+## Walkthrough: What a Pipeline Run Looks Like
 
+Running `/afc:auto "Add password reset flow"` produces this (abbreviated):
+
+**Spec (1/5)** — Generates `spec.md` with requirements and acceptance criteria:
 ```
-/afc:auto "feature description"
+FR-001: POST /auth/reset sends email with token
+FR-002: GET /auth/reset/:token validates and shows form
+FR-003: Token expires after 1 hour
+Acceptance: Given expired token, When user submits, Then show error
 ```
 
-Runs all 5 phases automatically with **Critic Loop** quality checks at each gate:
+**Plan (2/5)** — Creates `plan.md` with file change map and architecture decisions:
+```
+File Change Map:
+  src/routes/auth.ts        — ADD reset endpoint handlers
+  src/services/email.ts     — ADD sendResetEmail()
+  src/middleware/validate.ts — MODIFY add token validation
+  tests/auth.test.ts        — ADD reset flow tests
+```
 
+**Implement (3/5)** — Auto-decomposes into tasks, executes with CI gates:
 ```
-Spec (1/5) → Plan (2/5) → Implement (3/5) → Review (4/5) → Clean (5/5)
+Tasks: 4 total (2 parallel)
+  [1] Add reset endpoint     ✓
+  [2] Add email service       ✓  ← parallel with [1]
+  [3] Add token validation    ✓  ← depends on [1]
+  [4] Add tests               ✓
+CI: npm test → passed
 ```
 
-### 18 Slash Commands
+**Review (4/5)** — 8-perspective review + specialist agent analysis:
+```
+Architecture (afc-architect): ✓ layer boundaries respected
+Security (afc-security): ⚠ rate-limit reset endpoint
+Performance: ✓ no N+1 queries
+→ Auto-fixed: added rate limiter middleware
+```
 
-**User and model (unrestricted):**
+**Clean (5/5)** — Removes pipeline artifacts, final CI check.
+
+## Slash Commands
 
 | Command | Description |
 |---|---|
@@ -85,14 +106,9 @@ Spec (1/5) → Plan (2/5) → Implement (3/5) → Review (4/5) → Clean (5/5)
 | `/afc:plan` | Design implementation plan with file change map |
 | `/afc:implement` | Execute code implementation with CI gates |
 | `/afc:test` | Test strategy planning and test writing |
-| `/afc:review` | Code review with security scanning |
+| `/afc:review` | Code review with architecture/security scanning |
 | `/afc:research` | Technical research with persistent storage |
 | `/afc:debug` | Bug diagnosis and fix |
-
-**User-only** (`disable-model-invocation: true`):
-
-| Command | Description |
-|---|---|
 | `/afc:init` | Project setup — detects stack and generates config |
 | `/afc:doctor` | Diagnose project health and plugin setup |
 | `/afc:architect` | Architecture analysis (persistent memory) |
@@ -100,16 +116,32 @@ Spec (1/5) → Plan (2/5) → Implement (3/5) → Review (4/5) → Clean (5/5)
 | `/afc:principles` | Project principles management |
 | `/afc:checkpoint` | Save session state |
 | `/afc:resume` | Restore session state |
-
-**Model-only** (`user-invocable: false`):
-
-| Command | Description |
-|---|---|
 | `/afc:tasks` | Task decomposition (auto-generated by implement) |
+| `/afc:ideate` | Explore and structure a product idea |
+| `/afc:launch` | Generate release artifacts (changelog, tag, publish) |
 | `/afc:analyze` | Verify artifact consistency |
 | `/afc:clarify` | Resolve spec ambiguities |
 
-### 15 Hook Events
+### Individual Command Examples
+
+```bash
+# Write a spec for a specific feature
+/afc:spec "Add dark mode toggle"
+
+# Design a plan from an existing spec
+/afc:plan
+
+# Debug a specific error
+/afc:debug "TypeError: Cannot read property 'user' of undefined"
+
+# Run code review on current changes
+/afc:review
+
+# Explore and structure a product idea
+/afc:ideate "real-time collaboration feature"
+```
+
+## Hook Events
 
 Every hook fires automatically — no configuration needed after install.
 
@@ -120,7 +152,7 @@ Every hook fires automatically — no configuration needed after install.
 | `PreToolUse` | Blocks dangerous commands (`push --force`, `reset --hard`) |
 | `PostToolUse` | Tracks file changes + auto-formats code |
 | `SubagentStart` | Injects pipeline context into subagents |
-| `Stop` | CI gate (shell) + code completeness check (AI agent) |
+| `Stop` | CI gate (shell) + code completeness check (agent) |
 | `SessionEnd` | Warns about unfinished pipeline |
 | `PostToolUseFailure` | Diagnostic hints for known error patterns |
 | `Notification` | Desktop alerts (macOS/Linux) |
@@ -130,84 +162,70 @@ Every hook fires automatically — no configuration needed after install.
 | `PermissionRequest` | Auto-allows CI commands during implement/review |
 | `ConfigChange` | Audits/blocks settings changes during active pipeline |
 | `TeammateIdle` | Prevents Agent Teams idle during implement/review |
+| `WorktreeCreate` | Sets up worktree isolation for parallel workers |
+| `WorktreeRemove` | Cleans up worktree after worker completion |
 
-### 3 Hook Handler Types
+Handler types: `command` (shell scripts, all events), `prompt` (LLM single-turn, TaskCompleted), `agent` (subagent with tools, Stop).
 
-| Type | Description | Use Case |
-|---|---|---|
-| `command` | Shell script execution (deterministic) | All 15 events |
-| `prompt` | LLM single-turn evaluation (haiku) | TaskCompleted |
-| `agent` | Subagent with file access tools | Stop |
+## Persistent Memory Agents
 
-### Persistent Memory Agents
-
-Two custom agents that **learn across sessions**:
+| Agent | Role |
+|---|---|
+| `afc-architect` | Remembers ADR decisions and architecture patterns across sessions. Auto-invoked during Plan (ADR recording) and Review (architecture compliance). |
+| `afc-security` | Remembers vulnerability patterns and false positives across sessions. Auto-invoked during Review (security scanning). Runs in isolated worktree. |
+| `afc-impl-worker` | Parallel implementation worker. Receives pre-assigned tasks from orchestrator. Ephemeral (no memory). |
 
-| Agent | Role | Memory |
-|---|---|---|
-| `afc-architect` | Architecture analysis — remembers ADR decisions and patterns | `.claude/agent-memory/afc-architect/` |
-| `afc-security` | Security scan — remembers vulnerability patterns and false positives | `.claude/agent-memory/afc-security/` |
+## Task Orchestration
 
-### Project Presets
+The implement phase automatically selects execution strategy:
 
-| Preset | Stack |
+| Parallel tasks in phase | Mode |
 |---|---|
-| `template` | Generic (manual config) |
-| `nextjs-fsd` | Next.js + FSD + Zustand + React Query |
-| `react-spa` | Vite + React 18 + Zustand + Tailwind |
-| `express-api` | Express + TypeScript + Prisma + Jest |
-| `monorepo` | Turborepo + pnpm workspace |
+| 0 | Sequential — one task at a time |
+| 1–5 | Parallel Batch — concurrent Task() calls |
+| 6+ | Swarm — orchestrator pre-assigns tasks to worker agents (max 5) |
 
-## How It Works
-
-```
-┌─────────────────────────────────────────────┐
-│  /afc:auto "Add feature X"              │
-├─────────────────────────────────────────────┤
-│  Phase 1: Spec      → Critic Loop → Gate ✓   │
-│  Phase 2: Plan      → Critic Loop → Gate ✓   │
-│  Phase 3: Implement → Tasks auto-gen → CI ✓  │
-│  Phase 4: Review    → 8 perspectives → Gate ✓│
-│  Phase 5: Clean     → Artifacts removed      │
-├─────────────────────────────────────────────┤
-│  15 hooks run automatically at each step    │
-│  Stop/TaskCompleted gates block if CI fails │
-└─────────────────────────────────────────────┘
-```
+Dependencies are tracked via DAG. CI gate + Mini-Review + Auto-Checkpoint run at each phase boundary.
 
 ## Configuration
 
-Initialize your project:
-
-```bash
+```
 /afc:init
 ```
 
-This detects your tech stack and generates `.claude/afc.config.md` with:
-- CI/lint/test commands
-- Architecture style and layers
-- Framework-specific settings
-- Code style conventions
+Auto-detects your tech stack (package manager, framework, architecture, testing, linting) and generates `.claude/afc.config.md` with CI commands, architecture rules, and code style conventions. No manual preset selection needed — the init command analyzes your project structure directly.
 
 ## FAQ
 
-### What is all-for-claudecode?
-A Claude Code plugin that automates the entire development cycle (spec → plan → implement → review → clean) through 18 slash commands and 15 hook events.
-
-### How does it compare to manual Claude Code workflows?
-Instead of manually prompting each step, all-for-claudecode orchestrates the full cycle with built-in quality gates that physically prevent skipping CI or security checks.
-
 ### Does it work with any project?
-Yes. Run `/afc:init` to auto-detect your stack, or use one of the 5 presets (Next.js, React SPA, Express API, Monorepo, or generic template).
+Yes. Run `/afc:init` to auto-detect your stack. Works with JavaScript/TypeScript, Python, Rust, Go, and any project with a CI command.
 
 ### Does it require any dependencies?
-No. Zero runtime dependencies — pure markdown commands + bash hook scripts.
+No. Pure markdown commands + bash hook scripts. No npm packages are imported at runtime.
+
+### What happens if CI fails during the pipeline?
+Debug-based RCA: traces the error, forms a hypothesis, applies a targeted fix. Halts after 3 failed attempts with full diagnosis.
+
+### Can I run individual phases?
+Yes. Each phase has its own command (`/afc:spec`, `/afc:plan`, `/afc:implement`, `/afc:review`). `/afc:auto` runs them all.
+
+### What are Critic Loops?
+Convergence-based quality checks after each phase. They evaluate output against criteria and auto-fix issues until stable. 4 verdicts: PASS, FAIL, ESCALATE (asks user), DEFER.
+
+### How many tokens does a pipeline run use?
+Depends on project size and feature complexity. A typical `/afc:auto` run for a medium feature uses roughly the same as a detailed manual implementation session — the pipeline adds structure, not overhead.
+
+### Can I customize the pipeline behavior?
+Yes. Edit `.claude/afc.config.md` to change CI commands, architecture rules, and code style conventions. The pipeline reads this config at every phase.
+
+### Does it work with monorepos?
+Yes. Run `/afc:init` in the monorepo root. The init command detects workspace structure and configures accordingly.
 
-### How do I install it?
-Inside Claude Code, run `/plugin marketplace add jhlee0409/all-for-claudecode` then `/plugin install afc@all-for-claudecode`. Alternatively, run `npx all-for-claudecode` from your terminal for a guided install.
+### Can multiple team members use it on the same repo?
+Yes. Each developer runs their own pipeline independently. The `.claude/afc.config.md` config is shared (commit it to the repo), but pipeline state is local and session-scoped.
 
-### What Claude Code version is required?
-Claude Code with plugin support (2025+). The plugin uses standard hooks, commands, and agents APIs.
+### How is this different from Cursor / Copilot / other AI tools?
+All-for-claudecode is not a code completion tool — it is a structured development pipeline. It enforces spec → plan → implement → review flow with quality gates, persistent memory agents, and CI verification at every step.
 
 ## License
 

package/agents/afc-architect.md

@@ -11,6 +11,8 @@ tools:
   - WebSearch
 model: sonnet
 memory: project
+# Note: no `isolation: worktree` — architect writes ADR files to project memory
+# which must persist in the main worktree (unlike afc-security which is read-only)
 skills:
   - docs/critic-loop-rules.md
   - docs/phase-gate-protocol.md

package/commands/analyze.md

@@ -22,13 +22,12 @@ model: haiku
 
 ## Config Load
 
-Read the following settings from `CLAUDE.md` or `.claude/CLAUDE.md` at the project root and assign to the `config` variable:
+**Always** read `.claude/afc.config.md` first. This file contains free-form markdown sections:
+- `## Architecture` — architecture pattern, layers, import rules (primary reference for this command)
+- `## Code Style` — language, naming conventions, lint rules
+- `## Project Context` — framework, state management, testing, etc.
 
-```
-config.architecture = the architecture pattern used in the project
-                      (e.g., "FSD", "Clean Architecture", "Layered", "Modular Monolith")
-                      → Architecture standard specified in CLAUDE.md. Assume "Layered Architecture" if not present.
-```
+If config file is missing: read `CLAUDE.md` for architecture info. Assume "Layered Architecture" if neither source has it.
 
 ## Execution Steps
 

package/commands/architect.md

@@ -2,7 +2,6 @@
 name: afc:architect
 description: "Architecture analysis and design advice"
 argument-hint: "[analysis target or design question]"
-disable-model-invocation: true
 context: fork
 agent: afc-architect
 allowed-tools:
@@ -27,13 +26,12 @@ model: sonnet
 
 ## Config Load
 
-Read the following settings from `CLAUDE.md` or `.claude/CLAUDE.md` at the project root and assign to the `config` variable:
+**Always** read `.claude/afc.config.md` first. This file contains free-form markdown sections:
+- `## Architecture` — architecture pattern, layers, import rules (primary reference for this command)
+- `## Code Style` — language, naming conventions, lint rules
+- `## Project Context` — framework, state management, testing, etc.
 
-```
-config.architecture = the architecture pattern used in the project
-                      (e.g., "FSD", "Clean Architecture", "Layered", "Modular Monolith")
-                      → Architecture standard specified in CLAUDE.md. Assume "Layered Architecture" if not present.
-```
+If config file is missing: read `CLAUDE.md` for architecture info. Assume "Layered Architecture" if neither source has it.
 
 ## Execution Steps
 
@@ -94,7 +92,7 @@ Structure analysis results and **print to console**:
 
 > **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/critic-loop-rules.md` first and follow it.
 
-Run the critic loop until convergence. Safety cap: 7 passes.
+Run the critic loop until convergence. Safety cap: 7 passes (higher than the standard 5 because architecture analysis involves broader exploration across modules and layers).
 
 | Criterion | Validation |
 |-----------|------------|

package/commands/auto.md

@@ -22,13 +22,11 @@ argument-hint: "[feature description in natural language]"
 ## Config Load
 
 **Always** read `.claude/afc.config.md` first (read manually if not auto-loaded above). Values defined in this file are referenced below as `{config.*}`:
-- `{config.ci}` — full CI command
-- `{config.gate}` — phase gate command
-- `{config.architecture}` — architecture style and rules
-- `{config.framework}` — framework characteristics (server/client boundary etc.)
-- `{config.code_style}` — code style rules
-- `{config.risks}` — project-specific risk patterns
-- `{config.mini_review}` — Mini-Review checklist items
+- `{config.ci}` — full CI command (from `## CI Commands` YAML)
+- `{config.gate}` — phase gate command (from `## CI Commands` YAML)
+- `{config.test}` — test command (from `## CI Commands` YAML)
+- `{config.architecture}` — architecture style and rules (from `## Architecture` section)
+- `{config.code_style}` — code style rules (from `## Code Style` section)
 
 If config file is missing:
 1. Ask the user: "`.claude/afc.config.md` not found. Run `/afc:init` to set up the project?"
@@ -115,7 +113,11 @@ If all checks pass, proceed to Phase 0.8.
 2. Run `{config.ci}` verification
    - On fail: **abort fast-path**, restart with full pipeline: `⚠ Fast-path aborted — change is more complex than expected. Running full pipeline.`
 3. If change touches > 2 files OR modifies any `.sh` script: **abort fast-path**, restart with full pipeline
-4. **Checkpoint**: `"${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" phase fast-path`
+4. **Checkpoint**:
+   ```bash
+   "${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" phase fast-path
+   "${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" ci-pass
+   ```
 5. Run `/afc:review` logic inline (mini-review only — single Critic pass)
 6. Run Phase 5 Clean logic (artifact cleanup, CI gate, pipeline flag release)
 7. Final output:
@@ -204,8 +206,8 @@ Execute `/afc:plan` logic inline:
      5. Acceptance anchor alignment: Implementation Context Acceptance Anchors faithfully reflect spec acceptance scenarios
    - **RISK criterion mandatory checks**:
      - Enumerate **at least 3** `{config.ci}` failure scenarios and describe mitigation
-     - Check each pattern in `{config.risks}` one by one
-     - Consider `{config.framework}` characteristics (server/client boundary etc.)
+     - Check each risk pattern described in config's Project Context section one by one
+     - Consider framework characteristics from config's Project Context (server/client boundary etc.)
    - **ARCHITECTURE criterion**: explicitly describe import paths for moved/created files and pre-validate against `{config.architecture}` rules
    - Each pass must **explicitly explore what was missed in the previous pass** ("Pass 2: {X} was missed in pass 1. Further review: ...")
    - FAIL → auto-fix and continue. ESCALATE → pause, present options, resume after response. DEFER → record reason, mark clean.
@@ -229,14 +231,18 @@ Execute `/afc:plan` logic inline:
    ```
    - If architect returns conflicts → **ESCALATE** to user with conflict details
    - If no conflicts → proceed (ADR recorded for future reference)
-8. **Session context preservation**: Save key decisions and constraints for context compaction resilience:
-   ```
-   save_session_context({
-     goal: { original_request: "$ARGUMENTS", current_objective: "Implement {feature}" },
-     decisions: [{ what: "{key design decision}", why: "{rationale}" }],
-     discoveries: [{ file: "{path}", insight: "{finding}" }]
-   })
+8. **Session context preservation**: Write key decisions to `.claude/afc/specs/{feature}/context.md` for compaction resilience:
+   ```markdown
+   # Session Context: {feature}
+   ## Goal
+   - Original request: $ARGUMENTS
+   - Current objective: Implement {feature}
+   ## Key Decisions
+   - {what}: {rationale}
+   ## Discoveries
+   - {file path}: {finding}
    ```
+   This file is read at Implement start to restore context after compaction.
 9. **Checkpoint**: phase transition already recorded by `afc-pipeline-manage.sh phase plan` at phase start
 10. Progress: `✓ 2/5 Plan complete (Critic: converged ({N} passes, {M} fixes, {E} escalations), files: {N}, ADR: {N} recorded, Implementation Context: {W} words)`
 
@@ -244,7 +250,7 @@ Execute `/afc:plan` logic inline:
 
 `"${CLAUDE_PLUGIN_ROOT}/scripts/afc-pipeline-manage.sh" phase implement`
 
-**Session context reload**: At implement start, call `load_session_context()` to restore key decisions and constraints from Plan phase (resilient to context compaction).
+**Session context reload**: At implement start, read `.claude/afc/specs/{feature}/context.md` if it exists. This restores key decisions and constraints from Plan phase (resilient to context compaction).
 
 Execute `/afc:implement` logic inline — **follow all orchestration rules defined in `commands/implement.md`** (task generation, mode selection, batch/swarm execution, failure recovery, task execution pattern). The implement command is the single source of truth for orchestration details.
 
@@ -328,7 +334,7 @@ Execute `/afc:implement` logic inline — **follow all orchestration rules defin
    For each acceptance scenario in spec.md:
    - Map GWT to a test case: Given → Arrange, When → Act, Then → Assert
    - Target file: determined by the component/module referenced in the scenario
-   - Test file location: follows project convention ({config.testing} framework patterns)
+   - Test file location: follows project convention (test framework from Project Context)
    ```
 3. Run `{config.test}` to verify tests pass against the implementation
    - If tests fail → this reveals a gap between spec and implementation:
@@ -402,7 +408,7 @@ Execute `/afc:review` logic inline — **follow all review perspectives defined
    - A. Code Quality — `{config.code_style}` compliance (direct review)
    - B. Architecture — **delegated to afc-architect agent** (persistent memory, ADR-aware)
    - C. Security — **delegated to afc-security agent** (persistent memory, false-positive-aware)
-   - D. Performance — `{config.framework}`-specific patterns (direct review)
+   - D. Performance — framework-specific patterns from Project Context (direct review)
    - E. Project Pattern Compliance — conventions and idioms (direct review)
    - **F. Reusability** — DRY, shared utilities, abstraction level (direct review)
    - **G. Maintainability** — AI/human comprehension, naming clarity, self-contained files (direct review)
@@ -412,16 +418,16 @@ Execute `/afc:review` logic inline — **follow all review perspectives defined
 6. **Retrospective check**: if `.claude/afc/memory/retrospectives/` exists, load and check:
    - Were there recurring Critical finding categories in past reviews? Prioritize those perspectives.
    - Were there false positives that wasted effort? Reduce sensitivity for those patterns.
-6. **Critic Loop until convergence** (safety cap: 5, follow Critic Loop rules):
+7. **Critic Loop until convergence** (safety cap: 5, follow Critic Loop rules):
    - COMPLETENESS: were all changed files reviewed across all 8 perspectives (A-H)?
    - SPEC_ALIGNMENT: cross-check implementation against spec.md — (1) every SC verified with `{M}/{N}` count, (2) every acceptance scenario (GWT) has corresponding code path, (3) no spec constraint is violated
    - PRECISION: are there unnecessary changes? Are there out-of-scope modifications?
    - FAIL → auto-fix and continue. ESCALATE → pause, present options, resume after response. DEFER → record reason, mark clean.
-7. **Handling SC shortfalls**:
+8. **Handling SC shortfalls**:
    - Fixable → attempt auto-fix → re-run `{config.ci}` verification
    - Not fixable → state in final report with reason (no post-hoc rationalization; record as Plan-phase target-setting error)
-8. **Checkpoint**: phase transition already recorded by `afc-pipeline-manage.sh phase review` at phase start
-9. Progress: `✓ 4/5 Review complete (Critical:{N} Warning:{N} Info:{N}, SC shortfalls: {N})`
+9. **Checkpoint**: phase transition already recorded by `afc-pipeline-manage.sh phase review` at phase start
+10. Progress: `✓ 4/5 Review complete (Critical:{N} Warning:{N} Info:{N}, SC shortfalls: {N})`
 
 ### Phase 5: Clean (5/5)
 
@@ -546,7 +552,7 @@ Pipeline aborted (Phase {N}/5)
 - **[P] parallel is mandatory**: if a [P] marker is assigned in tasks.md, it must be executed in parallel. Orchestration mode (batch vs swarm) is selected automatically based on task count. Sequential substitution is prohibited.
 - **Swarm mode is automatic**: when a phase has 6+ [P] tasks, the orchestrator pre-assigns tasks to swarm workers. Do not manually batch.
 - **Implementation Context travels with workers**: every sub-agent prompt includes the Implementation Context section from plan.md, ensuring spec intent propagates to parallel workers.
-- **Session context resilience**: key decisions are saved via `save_session_context` at Plan completion and restored at Implement start, surviving context compaction.
+- **Session context resilience**: key decisions are written to `.claude/afc/specs/{feature}/context.md` at Plan completion and read at Implement start, surviving context compaction.
 - **Specialist agents enhance review**: afc-architect and afc-security agents are invoked during Review to provide persistent-memory-aware analysis. Their findings are merged into the consolidated review. Agent memory updates happen automatically during the agent call.
 - **Debug-based RCA replaces blind retry**: CI failures trigger `/afc:debug` logic (hypothesis → targeted fix) instead of generic "retry 3 times". This produces better fixes and records patterns via retrospective.
 - **Acceptance tests close the spec-to-code gap**: When spec contains GWT scenarios and a test framework is configured, acceptance tests are auto-generated after implementation, verifying spec intent is met.

package/commands/checkpoint.md

@@ -2,7 +2,6 @@
 name: afc:checkpoint
 description: "Save session state"
 argument-hint: "[checkpoint message]"
-disable-model-invocation: true
 model: haiku
 allowed-tools:
   - Read

package/commands/debug.md

@@ -48,7 +48,7 @@ Proceed in order:
 
 1. **Error trace**: extract file:line from error message/stack trace → read that code
 2. **Data flow**: trace backwards from the problem point (where did the bad data come in?)
-3. **State analysis**: check relevant {config.state_management} cache state
+3. **State analysis**: check relevant state management cache state (from Project Context)
 4. **Recent changes**: check recent changes with `git log --oneline -10 -- {related files}`
 5. **Race conditions**: check for timing issues between async operations
 

package/commands/doctor.md

@@ -2,7 +2,6 @@
 name: afc:doctor
 description: "Diagnose project health and plugin setup"
 argument-hint: "[--verbose]"
-disable-model-invocation: true
 allowed-tools:
   - Read
   - Grep
@@ -49,7 +48,7 @@ Run ALL checks regardless of earlier failures. Do not short-circuit.
 | Check | How | Pass | Fail |
 |-------|-----|------|------|
 | Config file exists | Read `.claude/afc.config.md` | File exists | Fix: run `/afc:init` |
-| Required sections present | Grep for `## CI Commands`, `## Architecture`, `## Code Style`, `## Framework` | All 4 sections found | Fix: add missing section to `.claude/afc.config.md` or re-run `/afc:init` |
+| Required sections present | Grep for `## CI Commands`, `## Architecture`, `## Code Style` | All 3 sections found | Fix: add missing section to `.claude/afc.config.md` or re-run `/afc:init` |
 | Gate command defined | Grep for `gate:` inside `## CI Commands` section | `gate:` field found | Fix: add `gate:` field to `## CI Commands` section |
 | CI command runnable | Extract CI command from config, run it | Exits 0 | ⚠ Warning: CI command failed. Check `{config.ci}` in afc.config.md |
 | Gate command runnable | Extract gate command from config, run it | Exits 0 | ⚠ Warning: gate command failed. Check `{config.gate}` in afc.config.md |