all-for-claudecode 2.4.0 → 2.6.0

package/commands/qa.md

@@ -0,0 +1,191 @@
+---
+name: afc:qa
+description: "Project quality audit — detect gaps between structure and runtime behavior"
+argument-hint: "[scope: all, tests, errors, coverage, or specific concern]"
+user-invocable: true
+context: fork
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+model: sonnet
+---
+
+# /afc:qa — Project Quality Audit
+
+> Detects quality gaps between structural correctness and actual runtime behavior.
+> **Read-only** — does not modify any files. Reports findings to console only.
+
+## Arguments
+
+- `$ARGUMENTS` — (optional) scope of audit. Defaults to `all`.
+  - `all` — run all 5 categories
+  - `tests` — category A only (Test Confidence)
+  - `errors` — category B only (Error Resilience)
+  - `coverage` — categories A + D (Test Confidence + API & Contract Safety)
+  - Or a free-form concern (e.g., "are error messages user-friendly", "check for dead exports")
+
+## Config Load
+
+**Always** read `.claude/afc.config.md` first. This file contains free-form markdown sections:
+- `## Architecture` — architecture pattern, layers, import rules
+- `## Code Style` — language, naming conventions, lint rules
+- `## CI Commands` — test, lint, gate commands (YAML)
+- `## Project Context` — framework, state management, testing strategy
+
+If config file is missing: read `CLAUDE.md` for project info. Proceed without config if neither exists.
+
+## Audit Categories
+
+### A. Test Confidence
+
+Evaluate whether the test suite actually catches regressions.
+
+Checks:
+- **Assertion density**: ratio of assertions to test functions (low ratio = weak tests)
+- **Test-to-code ratio**: test LOC vs source LOC per layer (guided by `{config.architecture}`)
+- **Mock overuse**: tests that mock so much they only test the mock setup
+- **Runtime verification**: execute `{config.test}` and analyze output (pass/fail counts, skipped tests, timing)
+- **Missing coverage**: source files/modules with zero test coverage
+
+### B. Error Resilience
+
+Evaluate whether errors are handled consistently and helpfully.
+
+Checks:
+- **Catch consistency**: unhandled promise rejections, empty catch blocks, swallowed errors
+- **Error propagation**: errors that lose context through the call chain
+- **User-facing messages**: cryptic error strings, raw stack traces exposed to users
+- **Boundary validation**: missing input validation at API/CLI/form boundaries
+- Apply `{config.code_style}` error handling rules if available
+
+### C. Build & CI Integrity
+
+Evaluate whether CI pipeline is healthy and reproducible.
+
+Checks:
+- **CI execution**: run `{config.ci}` and `{config.gate}` commands, verify they pass
+- **Lock file integrity**: lock file present, consistent with manifest (package.json vs lock, etc.)
+- **Unused dependencies**: declared but never imported packages
+- **Build reproducibility**: environment-dependent paths, hardcoded secrets, missing env vars
+
+### D. API & Contract Safety
+
+Evaluate whether interfaces between modules are sound.
+
+Checks:
+- **Type mismatches**: function signatures vs actual usage at call sites
+- **Dead exports**: exported symbols never imported elsewhere
+- **Deprecated usage**: calls to deprecated APIs (internal or external)
+- **Layer boundary violations**: imports that cross architecture boundaries (guided by `{config.architecture}`)
+
+### E. Code Health Signals
+
+Evaluate general code quality indicators.
+
+Checks:
+- **Complexity hotspots**: deeply nested logic, functions exceeding ~50 LOC
+- **Duplication**: near-identical code blocks across files
+- **Magic numbers/strings**: unexplained literals in logic
+- **TODO/FIXME accumulation**: stale markers (count, age if git history available)
+- Compare against `{config.code_style}` rules if available
+
+## Execution Steps
+
+### 1. Load Config
+
+Read `.claude/afc.config.md` (or fallback to `CLAUDE.md`). Extract:
+- Test command (`{config.test}`)
+- CI/gate commands (`{config.ci}`, `{config.gate}`)
+- Architecture layers (`{config.architecture}`)
+- Code style rules (`{config.code_style}`)
+
+### 2. Parse Scope
+
+Interpret `$ARGUMENTS` to determine which categories to run:
+
+| Argument | Categories |
+|----------|-----------|
+| `all` or empty | A, B, C, D, E |
+| `tests` | A |
+| `errors` | B |
+| `coverage` | A, D |
+| free-form text | best-matching subset |
+
+### 3. Lightweight Runtime
+
+Run commands that produce real output:
+- `{config.test}` — capture pass/fail/skip counts and timing
+- `{config.gate}` or `{config.ci}` — capture exit code and output
+
+Only run commands that exist in config. Skip gracefully if not configured.
+
+### 4. Codebase Scan
+
+For each active category:
+1. Use Glob to discover relevant files
+2. Use Grep for pattern-based detection (empty catches, TODO markers, etc.)
+3. Use Read for targeted inspection of flagged files
+4. Cross-reference findings against `{config.architecture}` layer structure
+
+### 5. Critic Loop
+
+Apply `docs/critic-loop-rules.md` with **safety cap: 3 rounds**.
+
+Focus the critic on:
+- Are the findings actionable or just noise?
+- Did I miss obvious quality gaps?
+- Are severity ratings justified by evidence?
+
+### 6. Console Report
+
+Output the final report in this format:
+
+```markdown
+## QA Audit: {project name or directory}
+
+### Category A: Test Confidence
+{findings with file:line references}
+Verdict: PASS | WARN | FAIL
+
+### Category B: Error Resilience
+{findings with file:line references}
+Verdict: PASS | WARN | FAIL
+
+### Category C: Build & CI Integrity
+{findings with file:line references}
+Verdict: PASS | WARN | FAIL
+
+### Category D: API & Contract Safety
+{findings with file:line references}
+Verdict: PASS | WARN | FAIL
+
+### Category E: Code Health Signals
+{findings with file:line references}
+Verdict: PASS | WARN | FAIL
+
+### Summary
+├─ A: Test Confidence    — {PASS|WARN|FAIL} {(N issues) if any}
+├─ B: Error Resilience   — {PASS|WARN|FAIL} {(N issues) if any}
+├─ C: Build & CI         — {PASS|WARN|FAIL} {(N issues) if any}
+├─ D: API & Contract     — {PASS|WARN|FAIL} {(N issues) if any}
+└─ E: Code Health        — {PASS|WARN|FAIL} {(N issues) if any}
+
+Total: {N} PASS, {N} WARN, {N} FAIL
+Priority fixes: {top 3 most impactful issues}
+```
+
+## Verdict Criteria
+
+- **PASS** — no issues found, or only cosmetic observations
+- **WARN** — issues found but not blocking; quality could degrade over time
+- **FAIL** — critical gaps that likely cause bugs, outages, or security issues
+
+## Notes
+
+- **Read-only**: Do not modify any files. Report only.
+- **Evidence-based**: Every finding must include a `file:line` reference or command output.
+- **Config-aware**: Adapt checks to the project's declared architecture and conventions.
+- **Scope discipline**: Only run categories matching the requested scope.
+- **Not a linter**: Focus on semantic quality gaps that automated tools miss.

package/commands/release-notes.md

@@ -0,0 +1,219 @@
+---
+name: afc:release-notes
+description: "Generate user-facing release notes from git history"
+argument-hint: "[v1.0.0..v2.0.0 | v2.0.0 | --post]"
+allowed-tools:
+  - Read
+  - Bash
+  - Glob
+  - Grep
+model: sonnet
+---
+
+# /afc:release-notes — Generate Release Notes
+
+> Rewrites commit/PR history into user-facing release notes and optionally publishes to GitHub Releases.
+> This is a **standalone utility** — not part of the auto pipeline.
+> Does NOT modify local files (CHANGELOG updates are handled by `/afc:launch`).
+
+## Arguments
+
+- `$ARGUMENTS` — (optional) Version range and flags
+  - `v2.3.0..v2.4.0` — specific tag range
+  - `v2.4.0` — from that tag to HEAD
+  - Not specified — auto-detect last tag to HEAD
+  - `--post` — publish to GitHub Releases after preview (can combine with any range)
+
+Parse the arguments:
+1. Extract `--post` flag if present
+2. Parse remaining as version range:
+   - If contains `..`: split into `{from_tag}..{to_tag}`
+   - If single version: use `{version}..HEAD`
+   - If empty: auto-detect with `git describe --tags --abbrev=0`
+
+## Execution Steps
+
+### 1. Determine Range
+
+```bash
+# Auto-detect last tag if no range specified
+git describe --tags --abbrev=0 2>/dev/null
+```
+
+- If a tag is found, set `from_tag` to that tag, `to_tag` to HEAD
+- If no tags exist, inform the user: "No tags found. Include all commits? (y/n)"
+- If a `to_tag` is specified (not HEAD), verify it exists: `git rev-parse --verify {to_tag} 2>/dev/null`
+- Determine the version label for the notes header:
+  - If `to_tag` is a version tag: use it (e.g., `v2.4.0`)
+  - If `to_tag` is HEAD: use "Unreleased" or the `from_tag` bumped (ask user)
+
+### 2. Collect Raw Data
+
+Run these commands to gather change context:
+
+```bash
+# Commit history (no merges)
+git log {from_tag}..{to_tag} --pretty=format:"%H %s" --no-merges
+
+# Merged PRs since the from_tag date
+from_date=$(git log -1 --format=%aI {from_tag})
+gh pr list --state merged --search "merged:>$from_date" --json number,title,author,labels,body --limit 100
+```
+
+If `gh` is not available or the repo has no remote, skip PR collection — proceed with git-only data.
+
+### 3. Detect Breaking Changes
+
+Search commit messages and PR titles for breaking change indicators:
+
+- Patterns: `BREAKING`, `BREAKING CHANGE`, `!:` (conventional commits `feat!:`, `fix!:`)
+- Also check PR labels for: `breaking`, `breaking-change`, `semver-major`
+
+Flag any matches for the Breaking Changes section.
+
+### 4. Categorize and Rewrite
+
+Categorize each commit/PR into one of:
+
+| Category | Conventional Commit Prefixes | Fallback Heuristics |
+|----------|------------------------------|---------------------|
+| Breaking Changes | `!:` suffix, `BREAKING` | Label: `breaking` |
+| New Features | `feat:` | "add", "new", "implement", "support" |
+| Bug Fixes | `fix:` | "fix", "resolve", "correct", "patch" |
+| Other Changes | `chore:`, `docs:`, `ci:`, `refactor:`, `perf:`, `test:`, `style:`, `build:` | Everything else |
+
+**Rewriting rules** — transform each entry from developer-speak to user-facing language:
+
+1. Remove conventional commit prefixes (`feat:`, `fix(scope):`, etc.)
+2. Rewrite in terms of **what the user experiences**, not what the developer changed
+   - Bad: "Refactor ThemeProvider to use context API"
+   - Good: "Improved theme switching reliability"
+   - Bad: "Fix race condition in afc-state.sh"
+   - Good: "Fixed an issue where pipeline state could become corrupted during concurrent execution"
+3. Merge related commits into a single entry when they address the same feature/fix
+4. Include PR number references where available: `(#42)`
+5. For breaking changes, add a brief migration note after the description
+
+### 5. Collect Contributor Info
+
+Build a contributors section:
+
+```bash
+# Get commit authors with their commit counts
+git log {from_tag}..{to_tag} --format="%aN" | sort | uniq -c | sort -rn
+
+# Resolve repo identity for GitHub username lookup
+gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"'
+
+# Map git authors to GitHub usernames via commit SHAs
+git log {from_tag}..{to_tag} --format="%H" | head -100 | while read sha; do
+  gh api "repos/{owner}/{repo}/commits/$sha" --jq '.author.login // empty' 2>/dev/null
+done | sort -u
+```
+
+For each contributor:
+- Try to resolve GitHub username via the commit SHA lookup above, or from PR author data collected in step 2
+- List their PR numbers if available
+- Fall back to git author name if no GitHub username found
+- If `gh` is not available, skip username resolution entirely — use git author names
+
+### 6. Compose Release Notes
+
+Assemble the final release notes in this format:
+
+```markdown
+# {version}
+
+{2-3 sentence summary: what is the most important thing in this release? Written for end users.}
+
+## Breaking Changes
+
+- {description + migration guide}
+
+## New Features
+
+- {user-facing description} (#{pr_number})
+
+## Bug Fixes
+
+- {user-facing description} (#{pr_number})
+
+## Other Changes
+
+- {description} (#{pr_number})
+
+## Contributors
+
+{contributor list with @mentions and PR numbers}
+```
+
+**Format rules**:
+- Omit empty sections entirely (if no breaking changes, skip that section)
+- Breaking Changes section always comes first when present
+- Each entry is a single bullet point, max 2 sentences
+- Summary paragraph should highlight the top 1-2 changes
+- Contributors section: `@username (#42, #45)` format, or `Name (#42)` if no GitHub username
+
+### 7. Preview Output
+
+Display the complete release notes to the user in the console.
+
+Print a summary:
+```
+Release notes generated
+├─ Version: {version}
+├─ Range: {from_tag}..{to_tag}
+├─ Commits: {N}
+├─ PRs referenced: {N}
+├─ Breaking changes: {count or "none"}
+├─ Contributors: {N}
+└─ --post: {will publish / preview only}
+```
+
+### 8. Publish to GitHub Releases (if --post)
+
+If `--post` flag is present:
+
+1. Determine the tag name:
+   - If `to_tag` is a specific tag: use it
+   - If `to_tag` is HEAD: ask the user what tag to create (suggest next version)
+
+2. Ask user to confirm using AskUserQuestion:
+   - **Post as-is** — Publish the GitHub Release immediately
+   - **Post as draft** — Create as draft release (can review and publish later from GitHub)
+   - **Edit first** — Let me modify the notes before posting
+   - **Cancel** — Do not post
+
+3. On approval, write to a temp file and publish:
+   ```bash
+   tmp_file=$(mktemp)
+   cat > "$tmp_file" << 'NOTES_EOF'
+   {release notes content}
+   NOTES_EOF
+   # Add --draft if user chose "Post as draft"
+   gh release create {tag} --notes-file "$tmp_file" --title "{version}" [--draft]
+   rm -f "$tmp_file"
+   ```
+
+4. Print result:
+   ```
+   GitHub Release published
+   ├─ Tag: {tag}
+   ├─ Title: {version}
+   ├─ Status: {published / draft}
+   └─ URL: {release URL from gh output}
+   ```
+
+If `--post` is not present, print:
+```
+To publish these notes as a GitHub Release, run again with --post flag.
+```
+
+## Notes
+
+- **Read-only by default**: Without `--post`, this command only outputs to console. No files are created or modified.
+- **Complements `/afc:launch`**: Use `launch` for local artifact generation (CHANGELOG, README). Use `release-notes` for GitHub Release publishing.
+- **Conventional Commits aware**: Projects using conventional commits get better categorization. Projects without them still get reasonable results via heuristic matching.
+- **Contributor attribution**: Best effort. GitHub username resolution requires `gh` CLI and repository access.
+- **User confirmation required**: `--post` always asks for explicit approval before publishing to GitHub.
+- **Idempotent**: Running without `--post` is safe to repeat. With `--post`, GitHub Releases for existing tags will fail (GitHub does not allow duplicate release tags).

package/commands/resume.md

@@ -22,7 +22,7 @@ allowed-tools:
 ### 1. Load Checkpoint
 
 Read `.claude/afc/memory/checkpoint.md`:
-- If not found: check **auto-memory fallback** — read `~/.claude/projects/{ENCODED_PATH}/auto-memory/checkpoint.md` (where `ENCODED_PATH` = project path with `/` replaced by `-`):
+- If not found: check **auto-memory fallback** — read `~/.claude/projects/{ENCODED_PATH}/memory/checkpoint.md` (where `ENCODED_PATH` = project path with `/` replaced by `-`):
   - If fallback found: use it as the checkpoint source (auto-memory is written by `pre-compact-checkpoint.sh` during context compaction)
   - If fallback also not found: output "No saved checkpoint found. Use `/afc:checkpoint` to create one, or checkpoints are created automatically on context compaction." then **stop**
 - If found: parse the full contents (extract branch, commit hash, pipeline feature, task progress, modified files)

package/commands/triage.md

@@ -0,0 +1,222 @@
+---
+name: afc:triage
+description: "Parallel triage of open PRs and issues"
+argument-hint: "[scope: --pr, --issue, --all (default), or specific numbers]"
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Task
+  - Write
+model: sonnet
+---
+
+# /afc:triage — PR & Issue Triage
+
+> Collects open PRs and issues, analyzes them in parallel, and produces a priority-ranked triage report.
+> Uses lightweight analysis first (no checkout), then selective deep analysis with worktree isolation for PRs that require build/test verification.
+
+## Arguments
+
+- `$ARGUMENTS` — (optional) Triage scope
+  - `--pr` — PRs only
+  - `--issue` — Issues only
+  - `--all` — Both PRs and issues (default)
+  - Specific numbers (e.g., `#42 #43`) — Analyze only those items
+  - `--deep` — Force deep analysis (worktree) for all PRs
+
+## Execution Steps
+
+### 1. Collect Targets
+
+Run the metadata collection script:
+
+```bash
+"${CLAUDE_PLUGIN_ROOT}/scripts/afc-triage.sh" "$ARGUMENTS"
+```
+
+This returns JSON with PR/issue metadata. If the script is not available, fall back to direct `gh` commands:
+
+```bash
+# PRs
+gh pr list --json number,title,headRefName,author,labels,additions,deletions,changedFiles,createdAt,updatedAt,reviewDecision,isDraft --limit 50
+
+# Issues
+gh issue list --json number,title,labels,author,createdAt,updatedAt,comments --limit 50
+```
+
+### 2. Phase 1 — Lightweight Parallel Analysis (no checkout)
+
+For each PR/issue, gather analysis data **without** checking out branches:
+
+#### PR Analysis (parallel — one agent per PR, max 5 concurrent)
+
+Spawn parallel agents in a **single message**:
+
+```
+Task("Triage PR #{number}: {title}", subagent_type: "general-purpose",
+  prompt: "Analyze this PR without checking out the branch.
+
+  PR #{number}: {title}
+  Author: {author}
+  Branch: {headRefName}
+  Changed files: {changedFiles}, +{additions}/-{deletions}
+  Labels: {labels}
+  Review status: {reviewDecision}
+  Draft: {isDraft}
+
+  Steps:
+  1. Run: gh pr diff {number}
+  2. Run: gh pr view {number} --comments
+  3. Analyze the diff for:
+     - What the PR does (1-2 sentence summary)
+     - Risk level: Critical (core logic, auth, data) / Medium (features, UI) / Low (docs, config, tests)
+     - Complexity: High (>10 files or cross-cutting) / Medium (3-10 files) / Low (<3 files)
+     - Whether build/test verification is needed (yes/no + reason)
+     - Potential issues or concerns (max 3)
+     - Suggested reviewers or labels if obvious
+
+  Output as structured text:
+  SUMMARY: ...
+  RISK: Critical|Medium|Low
+  COMPLEXITY: High|Medium|Low
+  NEEDS_DEEP: yes|no
+  DEEP_REASON: ... (if yes)
+  CONCERNS: ...
+  SUGGESTION: ...")
+```
+
+#### Issue Analysis (parallel — one agent per batch of 5 issues)
+
+```
+Task("Triage Issues #{n1}-#{n5}", subagent_type: "general-purpose",
+  prompt: "Analyze these issues:
+  {issue list with titles, labels, comment count}
+
+  For each issue:
+  1. Read issue body and comments: gh issue view {number} --comments
+  2. Classify:
+     - Type: Bug / Feature / Enhancement / Question / Maintenance
+     - Priority: P0 (blocking) / P1 (important) / P2 (nice-to-have) / P3 (backlog)
+     - Estimated effort: Small (< 1 day) / Medium (1-3 days) / Large (3+ days)
+     - Related PRs (if any mentioned)
+  3. One-line summary
+
+  Output as structured text per issue:
+  ISSUE #{number}: {title}
+  TYPE: ...
+  PRIORITY: P0|P1|P2|P3
+  EFFORT: Small|Medium|Large
+  RELATED_PR: #N or none
+  SUMMARY: ...")
+```
+
+### 3. Phase 2 — Selective Deep Analysis (worktree, optional)
+
+From Phase 1 results, identify PRs where `NEEDS_DEEP: yes`.
+
+For each deep-analysis PR, spawn a **worktree-isolated agent**:
+
+```
+Task("Deep triage PR #{number}", subagent_type: "afc:afc-pr-analyst",
+  isolation: "worktree",
+  prompt: "Deep-analyze PR #{number} ({title}).
+
+  Branch: {headRefName}
+  Phase 1 concerns: {concerns from Phase 1}
+
+  Steps:
+  1. Checkout the PR branch: gh pr checkout {number}
+  2. Run project CI/test commands if available (from .claude/afc.config.md or CLAUDE.md)
+  3. Check for type errors, lint issues, test failures
+  4. Analyze architectural impact
+  5. Report findings
+
+  Output:
+  BUILD_STATUS: pass|fail|skip
+  TEST_STATUS: pass|fail|skip (N passed, M failed)
+  LINT_STATUS: pass|fail|skip
+  DEEP_FINDINGS: ...
+  RECOMMENDATION: merge|request-changes|needs-discussion")
+```
+
+**Important**: Launch at most 3 worktree agents concurrently to avoid resource contention.
+
+If `--deep` flag was specified, run Phase 2 for **all** PRs regardless of Phase 1 classification.
+
+### 4. Consolidate Triage Report
+
+Merge Phase 1 and Phase 2 results into a single report:
+
+```markdown
+# Triage Report
+
+> Date: {YYYY-MM-DD}
+> Repository: {owner/repo}
+> Scope: {PRs: N, Issues: M}
+
+## PRs ({count})
+
+### Priority Actions
+
+| # | Title | Risk | Complexity | Status | Action |
+|---|-------|------|------------|--------|--------|
+| {sorted by: Critical first, then by staleness} |
+
+### PR Details
+
+#### PR #{number}: {title}
+- **Author**: {author} | **Branch**: {branch}
+- **Changes**: +{add}/-{del} across {files} files
+- **Risk**: {risk} | **Complexity**: {complexity}
+- **Summary**: {summary}
+- **Concerns**: {concerns or "None"}
+- **Deep analysis**: {findings if Phase 2 ran, otherwise "Skipped"}
+- **Recommendation**: {recommendation}
+
+## Issues ({count})
+
+### By Priority
+
+| Priority | # | Title | Type | Effort | Related PR |
+|----------|---|-------|------|--------|------------|
+| {sorted by priority, then by creation date} |
+
+## Summary
+
+- **Immediate attention**: {list of Critical PRs and P0 issues}
+- **Ready to merge**: {PRs with no concerns and passing checks}
+- **Needs discussion**: {PRs/issues requiring team input}
+- **Stale items**: {PRs/issues with no activity > 14 days}
+```
+
+### 5. Save Report
+
+Save the triage report:
+
+```
+.claude/afc/memory/triage/{YYYY-MM-DD}.md
+```
+
+If a previous triage report exists for today, overwrite it.
+
+### 6. Final Output
+
+```
+Triage complete
+├─ PRs analyzed: {N} (deep: {M})
+├─ Issues analyzed: {N}
+├─ Immediate attention: {count}
+├─ Ready to merge: {count}
+├─ Report: .claude/afc/memory/triage/{date}.md
+└─ Duration: {elapsed}
+```
+
+## Notes
+
+- **Read-only**: Triage does not modify any code, merge PRs, or close issues.
+- **Rate limits**: `gh` API calls are rate-limited. For repos with 50+ open items, consider using `--pr` or `--issue` to reduce scope.
+- **Worktree cleanup**: Worktree agents auto-clean on completion. If a worktree is left behind, use `git worktree prune`.
+- **NEVER use `run_in_background: true` on Phase 1 Task calls**: agents must run in foreground so results are collected before consolidation. Phase 2 worktree agents also run in foreground.
+- **Parallel limits**: Phase 1 — max 5 concurrent agents. Phase 2 — max 3 concurrent worktree agents.

package/docs/phase-gate-protocol.md

@@ -34,7 +34,7 @@ Quantitatively inspect changed files within the Phase against `{config.code_styl
 After passing the Phase gate, automatically save session state:
 
 1. Create `.claude/afc/memory/` directory if it does not exist
-2. Write/update `.claude/afc/memory/checkpoint.md` **and** `~/.claude/projects/{ENCODED_PATH}/auto-memory/checkpoint.md` (dual-write for compaction resilience — `ENCODED_PATH` = project path with `/` replaced by `-`):
+2. Write/update `.claude/afc/memory/checkpoint.md` **and** `~/.claude/projects/{ENCODED_PATH}/memory/checkpoint.md` (dual-write for compaction resilience — `ENCODED_PATH` = project path with `/` replaced by `-`):
 
 ```markdown
 # Phase Gate Checkpoint

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "all-for-claudecode",
-  "version": "2.4.0",
+  "version": "2.6.0",
   "description": "Claude Code plugin that automates the full dev cycle — spec, plan, implement, review, clean.",
   "bin": {
     "all-for-claudecode": "bin/cli.mjs"
@@ -34,10 +34,12 @@
     "url": "https://github.com/jhlee0409/all-for-claudecode/issues"
   },
   "scripts": {
-    "lint": "shellcheck -x --source-path=scripts scripts/*.sh && bash scripts/afc-schema-validate.sh --all && bash scripts/afc-consistency-check.sh",
+    "lint": "shellcheck -x --source-path=scripts --severity=warning scripts/*.sh && bash scripts/afc-schema-validate.sh --all && bash scripts/afc-consistency-check.sh",
+    "qa": "bash scripts/afc-qa-audit.sh",
     "test": "vendor/shellspec/shellspec",
-    "test:all": "npm run lint && npm run test",
-    "setup:test": "bash scripts/install-shellspec.sh"
+    "test:all": "npm run lint && npm run qa && npm run test",
+    "setup:test": "bash scripts/install-shellspec.sh",
+    "sync:cache": "bash scripts/afc-sync-cache.sh"
   },
   "engines": {
     "node": ">=18"

package/scripts/afc-bash-guard.sh

@@ -14,15 +14,15 @@ cleanup() {
 }
 trap cleanup EXIT
 
+# Consume stdin immediately (prevents SIGPIPE if exiting early)
+INPUT=$(cat)
+
 # If pipeline is inactive -> allow
 if ! afc_state_is_active; then
   printf '{"hookSpecificOutput":{"permissionDecision":"allow"}}\n'
   exit 0
 fi
 
-# Parse tool input from stdin
-INPUT=$(cat)
-
 # If stdin is empty -> allow
 if [ -z "$INPUT" ]; then
   printf '{"hookSpecificOutput":{"permissionDecision":"allow"}}\n'