all-for-claudecode 2.7.0 → 2.7.1

package/.claude-plugin/marketplace.json

@@ -6,14 +6,14 @@
   },
   "metadata": {
     "description": "Automated pipeline for Claude Code — spec → plan → implement → review → clean",
-    "version": "2.7.0"
+    "version": "2.7.1"
   },
   "plugins": [
     {
       "name": "afc",
       "source": "./",
       "description": "Automated pipeline for Claude Code. Automates the full development cycle: spec → plan → implement → review → clean.",
-      "version": "2.7.0",
+      "version": "2.7.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.7.0",
+  "version": "2.7.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",
@@ -8,6 +8,5 @@
   "license": "MIT",
   "keywords": ["pipeline", "automation", "spec", "plan", "implement", "review", "critic-loop"],
   "commands": "./commands/",
-  "agents": "./agents/",
   "hooks": "./hooks/hooks.json"
 }

package/agents/afc-impl-worker.md

@@ -32,6 +32,14 @@ The orchestrator pre-assigns tasks to you via the prompt. Do NOT self-claim task
    - Gate command result
 5. Do NOT call TaskList or TaskUpdate — the orchestrator handles task state management
 
+## Cross-Phase Awareness
+
+When implementing tasks that call functions modified in a previous phase:
+- Read the callee's current implementation (it may have changed in the previous phase)
+- Verify that your call pattern is compatible with the callee's actual behavior (side effects, return values, error handling)
+- If `{config.test}` is available, run it after completing tasks that depend on cross-phase changes
+- If no E2E/integration tests are configured, note in your output: "⚠ Cross-phase dependency on {function} — no E2E verification available"
+
 ## Rules
 
 - Always read existing files before modifying them

package/commands/architect.md

@@ -59,6 +59,17 @@ Task("analyze features/timeline", subagent_type: Explore)
 Task("analyze widgets/timeline", subagent_type: Explore)
 ```
 
+**Cross-Module Import Chain Verification** (after Explore agents return):
+
+When parallel Explore agents are used, the orchestrator must verify cross-module boundaries that no single agent can see:
+
+1. From each agent's dependency map, extract **outbound imports** that cross module boundaries
+2. For each cross-module import chain (e.g., widget → feature → shared), read the actual import statements at the boundary files
+3. Verify against {config.architecture} rules: does the full chain respect layer direction, not just each module's internal imports?
+4. Report any cross-module violations not surfaced by individual agents
+
+Do not trust agent-summarized import relationships for cross-boundary chains — re-read the boundary files directly.
+
 ### 3. Write Analysis
 
 Structure analysis results and **print to console**:

package/commands/implement.md

@@ -271,7 +271,7 @@ When a worker agent returns an error:
 
 #### Phase Completion Gate (3 steps)
 
-> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/phase-gate-protocol.md` first and perform the 3 steps (CI gate → Mini-Review → Auto-Checkpoint) in order.
+> **Always** read `${CLAUDE_PLUGIN_ROOT}/docs/phase-gate-protocol.md` first and perform the 3–4 steps (CI gate → Mini-Review → Integration/E2E Gate (conditional) → Auto-Checkpoint) in order.
 > Cannot advance to the next phase without passing the gate. Abort and report to user after 3 consecutive CI failures.
 
 After passing the gate, create a phase rollback point:
@@ -320,6 +320,7 @@ After CI passes, run a convergence-based Critic Loop to verify design alignment
 - **SCOPE_ADHERENCE**: Compare `git diff` changed files against plan.md File Change List. Flag any file modified that is NOT in the plan. Flag any planned file NOT modified. Provide "M of N files match" count.
 - **ARCHITECTURE**: Validate changed files against `{config.architecture}` rules (layer boundaries, naming conventions, import paths). Provide "N of M rules checked" count.
 - **CORRECTNESS**: Cross-check implemented changes against spec.md acceptance criteria (AC). Verify each AC has corresponding code. Provide "N of M AC verified" count.
+- **SIDE_EFFECT_SAFETY**: For tasks that changed call order, error handling, or state flow: verify that callee behavior is compatible with the new call pattern. Provide "{M} of {N} behavioral changes verified" count.
 - **Adversarial 3-perspective** (mandatory each pass):
   - Skeptic: "Which implementation assumption is most likely wrong?"
   - Devil's Advocate: "How could this implementation be misused or fail unexpectedly?"

package/commands/research.md

@@ -51,6 +51,16 @@ Source priority:
 2. **Codebase** (existing patterns in the current project)
 3. **Community** (GitHub Issues, blogs)
 
+### 3.5. Reconcile Findings
+
+After parallel agents return, the orchestrator checks for conflicts between sources:
+
+1. Compare codebase agent findings (current usage patterns) against web agent findings (official docs, latest versions)
+2. If a codebase pattern conflicts with official documentation (e.g., deprecated API, changed behavior in newer version):
+   - Flag the conflict explicitly in Findings rather than silently adopting one source
+   - Note: "Current codebase uses {pattern} but official docs recommend {alternative} since {version/date}"
+3. If no conflicts → proceed to Summarize
+
 ### 4. Summarize Conclusions
 
 ```markdown

package/commands/review.md

@@ -51,6 +51,23 @@ If config file is missing:
 
 Choose review orchestration based on the number of changed files:
 
+**Pre-scan: Call Chain Context** (for Parallel Batch and Review Swarm modes only):
+
+Before distributing files to review agents, collect cross-boundary context:
+
+1. For each changed file, identify **outbound calls** to other changed files (imports + function calls)
+2. For each outbound call target, extract: function signature + 1-line side-effect summary (e.g., "mutates playlist state", "triggers async cascade")
+3. Include this context in each review agent's prompt:
+   ```
+   ## Cross-File Context
+   This file calls:
+   - `deleteVideo()` in api/videos.ts → internally auto-advances to next video if current is deleted
+   - `getNextVideo()` in api/playlist.ts → pops pending keyword queue first, falls back to normal next
+   Review findings should account for these behaviors.
+   ```
+
+For Direct review mode (≤5 files): skip pre-scan — orchestrator already has full context.
+
 #### 5 or fewer files: Direct review
 Review all files directly in the current context (no delegation).
 
@@ -152,6 +169,31 @@ For each changed file, examine from the following perspectives:
 - Open/Closed principle adherence where applicable
 - Future modification cost — would a reasonable feature request require rewriting or only extending?
 
+### 3.5. Cross-Boundary Verification
+
+After individual/parallel reviews complete, the **orchestrator** performs a cross-boundary check on behavioral findings:
+
+1. **Filter**: From all collected findings, select those involving:
+   - Call order changes (function A now calls B before C)
+   - Error handling modifications (try/catch scope changes, error propagation changes)
+   - State mutation changes (new writes to shared state, removed cleanup)
+
+2. **Verify**: For each behavioral finding rated Critical or Warning:
+   - Read the **callee's implementation** (the function/method being called)
+   - Check: does the callee's internal behavior (side effects, state changes, return values) actually conflict with the change?
+   - If no conflict → downgrade: Critical → Info, Warning → Info (append "verified: no cross-boundary impact")
+   - If confirmed conflict → keep severity, enrich description with callee behavior details
+
+3. **Output**: Append verification summary before Review Output:
+   ```
+   Cross-Boundary Check: {N} behavioral findings verified
+   ├─ Confirmed: {M} (severity kept)
+   ├─ Downgraded: {K} (false positive — callee compatible)
+   └─ Skipped: {J} (no behavioral change)
+   ```
+
+This step runs in the orchestrator context (not delegated), as it requires reading code across file boundaries that individual review agents cannot see.
+
 ### 4. Review Output
 
 ```markdown
@@ -197,6 +239,7 @@ Run the critic loop until convergence. Safety cap: 5 passes.
 |-----------|------------|
 | **COMPLETENESS** | Were all changed files reviewed? Are there any missed perspectives (A through H)? |
 | **SPEC_ALIGNMENT** | Cross-check implementation against spec.md: (1) every SC (success criterion) is satisfied — provide `{M}/{N} SC verified` count, (2) every acceptance scenario (GWT) has corresponding code path, (3) no spec constraint is violated by the implementation |
+| **SIDE_EFFECT_AWARENESS** | For findings involving call order changes, error handling modifications, or state mutation changes: did the reviewer verify the callee's internal behavior? If a Critical finding assumes a side effect without reading the target implementation → auto-downgrade to Info with note "cross-boundary unverified". Provide "{M} of {N} behavioral findings verified" count. |
 | **PRECISION** | Are the findings actual issues, not false positives? |
 
 **On FAIL**: auto-fix and continue to next pass.

package/commands/security.md

@@ -46,11 +46,52 @@ For dependency audit command: infer from `packageManager` field in `package.json
 ### 2. Agent Teams (if more than 10 files)
 
 Use parallel agents for wide-scope scans:
+
+**Pre-scan: Data Flow Context** (before distributing to agents):
+
+1. For each changed file, identify **input entry points** (user input, API params, URL params, form data) and **sanitization calls** (validation, escaping, encoding)
+2. Trace input flow across changed files: where does user input enter? Where is it sanitized? Where is it consumed?
+3. Include this context in each agent's prompt:
+   ```
+   ## Data Flow Context
+   Input flows relevant to your scan scope:
+   - User input enters via `req.body` in api/routes.ts → sanitized by `validateInput()` in shared/validation.ts → consumed in features/user.ts
+   - URL params enter via `req.params` in api/routes.ts → NO sanitization found → used in features/search.ts
+   Account for these flows when assessing injection/XSS severity.
+   ```
+
 ```
-Task("Security scan: src/features/", subagent_type: general-purpose)
-Task("Security scan: src/shared/api/", subagent_type: general-purpose)
+Task("Security scan: src/features/", subagent_type: general-purpose,
+  prompt: "... {include Data Flow Context} ...")
+Task("Security scan: src/shared/api/", subagent_type: general-purpose,
+  prompt: "... {include Data Flow Context} ...")
 ```
 
+For scans with ≤10 files: skip pre-scan — orchestrator has full context.
+
+### 2.5. Cross-Boundary Verification
+
+After parallel agent results are collected, the **orchestrator** performs cross-boundary verification on injection/vulnerability findings:
+
+1. **Filter**: From all findings, select those involving:
+   - Injection vulnerabilities (SQL, command, XSS) where input origin is in another agent's scan scope
+   - Authentication/authorization checks where the guard is in a different directory slice
+   - Sensitive data exposure where the data source and the exposure point are in different slices
+
+2. **Verify**: For each Critical or High finding:
+   - Read the **upstream code** (where input enters or is sanitized)
+   - Check: is the input actually sanitized before reaching the flagged consumption point?
+   - If sanitized → downgrade: Critical → Low, High → Low (append "verified: input sanitized at {location}")
+   - If NOT sanitized → keep severity, enrich with full data flow path
+
+3. **Output**: Append verification summary before Output Results:
+   ```
+   Cross-Boundary Check: {N} injection/vulnerability findings verified
+   ├─ Confirmed: {M} (severity kept — no upstream sanitization)
+   ├─ Downgraded: {K} (false positive — sanitized upstream)
+   └─ Skipped: {J} (single-file scope, no cross-boundary flow)
+   ```
+
 ### 3. Security Check Items
 
 #### A. Injection (A03:2021)

package/commands/triage.md

@@ -145,6 +145,20 @@ Task("Deep triage PR #{number}", subagent_type: "afc:afc-pr-analyst",
 
 If `--deep` flag was specified, run Phase 2 for **all** PRs regardless of Phase 1 classification.
 
+### 3.5. Cross-PR Coupling Detection
+
+After Phase 1 (and Phase 2 if applicable) results are collected, detect file-level coupling between PRs:
+
+1. Extract changed file lists from each PR's diff (already available from Phase 1 agent outputs)
+2. For each file, check if it appears in multiple PRs' changed file lists
+3. If shared files are found, annotate affected PRs with a coupling flag:
+   ```
+   COUPLING: PR #{A} and PR #{B} both modify src/shared/utils.ts
+   ```
+4. Include coupling information in the consolidated report's Priority Actions table and per-PR details
+
+This helps identify merge-order dependencies and potential conflict risks that no single-PR agent can detect.
+
 ### 4. Consolidate Triage Report
 
 Merge Phase 1 and Phase 2 results into a single report:

package/docs/phase-gate-protocol.md

@@ -1,6 +1,6 @@
-# Phase Completion Gate (3 Steps)
+# Phase Completion Gate (3–4 Steps)
 
-After each Phase completes, perform **3-step verification** sequentially:
+After each Phase completes, perform **3–4 step verification** sequentially (Step 2.5 is conditional):
 
 ## Step 1. CI Gate
 
@@ -29,6 +29,17 @@ Quantitatively inspect changed files within the Phase against `{config.code_styl
 - If issues found → fix immediately, then re-run CI Gate (Step 1)
 - If no issues → `✓ Phase {N} Mini-Review passed`
 
+## Step 2.5. Integration/E2E Gate (conditional)
+
+When the phase contains **behavioral changes** (call order modifications, error handling changes, state mutation changes — not pure additions or style fixes):
+
+1. Check if `{config.test}` includes integration or E2E tests
+2. If yes → run `{config.test}` and verify pass
+3. If fail → debug-based RCA (same protocol as Step 1)
+4. If `{config.test}` is empty or has no E2E coverage → skip with note: `⚠ No E2E test configured — behavioral changes not integration-tested`
+
+This gate is skipped for phases with only additive changes (new files, new functions with no existing callers).
+
 ## Step 3. Auto-Checkpoint
 
 After passing the Phase gate, automatically save session state:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "all-for-claudecode",
-  "version": "2.7.0",
+  "version": "2.7.1",
   "description": "Claude Code plugin that automates the full dev cycle — spec, plan, implement, review, clean.",
   "bin": {
     "all-for-claudecode": "bin/cli.mjs"