aiwcli 0.10.2 → 0.11.0

package/dist/templates/cc-native/.claude/settings.json

@@ -1,185 +1,175 @@
-{
-  "statusLine": {
-    "type": "command",
-    "command": "python .aiwcli/_shared/scripts/status_line.py"
-  },
-  "permissions": {
-    "allow": [],
-    "deny": []
-  },
-  "env": {},
-  "enabledPlugins": {},
-  "fileSuggestion": {
-    "type": "command",
-    "command": "python .aiwcli/_shared/hooks/file-suggestion.py"
-  },
-  "methods": {
-    "cc-native": {
-      "ides": [
-        "claude"
-      ],
-      "installedAt": "2026-01-29T01:59:02.558Z"
-    }
-  },
-  "hooks": {
-    "SessionStart": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_shared/hooks/session_start.py",
-            "timeout": 5000
-          }
-        ]
-      }
-    ],
-    "SessionEnd": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_shared/hooks/session_end.py",
-            "timeout": 5000
-          }
-        ]
-      }
-    ],
-    "PreCompact": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_shared/hooks/pre_compact.py",
-            "timeout": 5000
-          }
-        ]
-      }
-    ],
-    "UserPromptSubmit": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_shared/hooks/user_prompt_submit.py",
-            "timeout": 10000
-          }
-        ]
-      },
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_cc-native/hooks/plan_questions_early.py",
-            "timeout": 3000
-          }
-        ]
-      }
-    ],
-    "PostToolUse": [
-      {
-        "matcher": "*",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_shared/hooks/context_monitor.py",
-            "timeout": 5000
-          }
-        ]
-      },
-      {
-        "matcher": "TaskCreate",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_shared/hooks/task_create_capture.py",
-            "timeout": 3000,
-            "async": true
-          }
-        ]
-      },
-      {
-        "matcher": "TaskUpdate",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_shared/hooks/task_update_capture.py",
-            "timeout": 3000,
-            "async": true
-          }
-        ]
-      },
-      {
-        "matcher": "Bash|Edit",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_cc-native/hooks/suggest-fresh-perspective.py",
-            "timeout": 5000
-          }
-        ]
-      },
-      {
-        "matcher": "AskUserQuestion",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_cc-native/hooks/add_plan_context.py",
-            "timeout": 3000
-          }
-        ]
-      }
-    ],
-    "PermissionRequest": [
-      {
-        "matcher": "ExitPlanMode",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_shared/hooks/archive_plan.py",
-            "timeout": 5000
-          }
-        ]
-      }
-    ],
-    "PreToolUse": [
-      {
-        "matcher": "^TaskCreate$",
-        "hooks": [
-          {
-            "type": "prompt",
-            "prompt": "Evaluate this TaskCreate call for atomicity. Tasks become ISC criteria checked during verification — vague criteria cannot be verified, so precision matters. A well-specified task includes: (1) Explicit file paths like 'src/lib/auth.py' instead of 'the file above' or 'as discussed', (2) Specific function or component names instead of pronouns like 'it' or 'the function', (3) Clear expected state or behavior that is binary-testable in 2 seconds, (4) Concrete scope — one concern per task, not compound goals. If all four criteria are met and an agent with zero conversation history could verify the task was completed, return ok:true. If any criterion is missing, return ok:false with a response like: 'Missing context: [list each gap — e.g., no file path specified for the auth module, expected behavior is vague: what does fix the bug mean specifically, compound task should be split into separate criteria]'. When returning ok:false, end your response with: 'Retry: Re-invoke TaskCreate with a revised subject and description that address the gaps above.' This directive ensures the calling agent corrects and retries rather than abandoning the task."
-          }
-        ]
-      },
-      {
-        "matcher": "^Task$",
-        "hooks": [
-          {
-            "type": "prompt",
-            "prompt": "The sub-agent receives ONLY the prompt text — no conversation history, no prior context.\n\nCheck 1 — Dangling References: Does the prompt use pronouns or demonstratives that ONLY make sense with prior conversation? Violations: 'the file we looked at', 'as discussed above', 'that approach we chose', 'the error from earlier', 'fix the issue mentioned above'. NOT violations: relative paths ('_output/', 'src/lib/'), search terms ('context-manager', 'auth module'), directory exploration ('find files matching X'), tool names, or any concrete noun — even if imprecise. Only flag references that are truly UNRESOLVABLE without conversation history.\n\nCheck 2 — Implicit Contract: Does the prompt have ANY discernible goal? 'Explore the _output directory and find context files' IS a clear goal. 'Search for hooks that handle Task events' IS a clear goal. 'Read and summarize all files in X' IS a clear goal. Only flag if the prompt is truly goalless — e.g., a sentence fragment with no verb, or pure context with no request.\n\nIf both checks pass, return ok:true. When in doubt, pass — false negatives (letting a vague prompt through) are far less costly than false positives (blocking legitimate work).\n\nWhen returning ok:false, end your response with: 'Retry: Re-invoke the Task tool with a revised prompt that resolves the issues above.'"
-          }
-        ]
-      },
-      {
-        "matcher": "^Task$",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_cc-native/hooks/add_plan_context.py",
-            "timeout": 5000
-          }
-        ]
-      },
-      {
-        "matcher": "ExitPlanMode",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "python .aiwcli/_cc-native/hooks/cc-native-plan-review.py",
-            "timeout": 600000
-          }
-        ]
-      }
-    ]
-  }
-}
+{
+  "statusLine": {
+    "type": "command",
+    "command": "bun .aiwcli/_shared/scripts/status_line.ts"
+  },
+  "permissions": {
+    "allow": [],
+    "deny": []
+  },
+  "env": {},
+  "enabledPlugins": {},
+  "fileSuggestion": {
+    "type": "command",
+    "command": "bun .aiwcli/_shared/hooks-ts/file-suggestion.ts"
+  },
+  "methods": {
+    "cc-native": {
+      "ides": [
+        "claude"
+      ],
+      "installedAt": "2026-01-29T01:59:02.558Z"
+    }
+  },
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_shared/hooks-ts/session_start.ts",
+            "timeout": 5000
+          }
+        ]
+      }
+    ],
+    "SessionEnd": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_shared/hooks-ts/session_end.ts",
+            "timeout": 5000
+          }
+        ]
+      }
+    ],
+    "PreCompact": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_shared/hooks-ts/pre_compact.ts",
+            "timeout": 5000
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_shared/hooks-ts/user_prompt_submit.ts",
+            "timeout": 10000
+          }
+        ]
+      },
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_cc-native/hooks/plan_questions_early.ts",
+            "timeout": 3000
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_shared/hooks-ts/context_monitor.ts",
+            "timeout": 5000
+          }
+        ]
+      },
+      {
+        "matcher": "TaskCreate",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_shared/hooks-ts/task_create_capture.ts",
+            "timeout": 3000,
+            "async": true
+          }
+        ]
+      },
+      {
+        "matcher": "TaskUpdate",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_shared/hooks-ts/task_update_capture.ts",
+            "timeout": 3000,
+            "async": true
+          }
+        ]
+      },
+      {
+        "matcher": "AskUserQuestion",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_cc-native/hooks/add_plan_context.ts",
+            "timeout": 3000
+          }
+        ]
+      }
+    ],
+    "PermissionRequest": [
+      {
+        "matcher": "ExitPlanMode",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_shared/hooks-ts/archive_plan.ts",
+            "timeout": 5000
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "^TaskCreate$",
+        "hooks": [
+          {
+            "type": "prompt",
+            "prompt": "Evaluate this TaskCreate call for atomicity. Tasks become ISC criteria checked during verification — vague criteria cannot be verified, so precision matters. A well-specified task includes: (1) Explicit file paths like 'src/lib/auth.py' instead of 'the file above' or 'as discussed', (2) Specific function or component names instead of pronouns like 'it' or 'the function', (3) Clear expected state or behavior that is binary-testable in 2 seconds, (4) Concrete scope — one concern per task, not compound goals. If all four criteria are met and an agent with zero conversation history could verify the task was completed, return ok:true. If any criterion is missing, return ok:false with a response like: 'Missing context: [list each gap — e.g., no file path specified for the auth module, expected behavior is vague: what does fix the bug mean specifically, compound task should be split into separate criteria]'. When returning ok:false, end your response with: 'Retry: Re-invoke TaskCreate with a revised subject and description that address the gaps above.' This directive ensures the calling agent corrects and retries rather than abandoning the task."
+          }
+        ]
+      },
+      {
+        "matcher": "^Task$",
+        "hooks": [
+          {
+            "type": "prompt",
+            "prompt": "The sub-agent receives ONLY the prompt text — no conversation history, no prior context.\n\nCheck 1 — Dangling References: Does the prompt use pronouns or demonstratives that ONLY make sense with prior conversation? Violations: 'the file we looked at', 'as discussed above', 'that approach we chose', 'the error from earlier', 'fix the issue mentioned above'. NOT violations: relative paths ('_output/', 'src/lib/'), search terms ('context-manager', 'auth module'), directory exploration ('find files matching X'), tool names, or any concrete noun — even if imprecise. Only flag references that are truly UNRESOLVABLE without conversation history.\n\nCheck 2 — Implicit Contract: Does the prompt have ANY discernible goal? 'Explore the _output directory and find context files' IS a clear goal. 'Search for hooks that handle Task events' IS a clear goal. 'Read and summarize all files in X' IS a clear goal. Only flag if the prompt is truly goalless — e.g., a sentence fragment with no verb, or pure context with no request.\n\nIf both checks pass, return ok:true. When in doubt, pass — false negatives (letting a vague prompt through) are far less costly than false positives (blocking legitimate work).\n\nWhen returning ok:false, end your response with: 'Retry: Re-invoke the Task tool with a revised prompt that resolves the issues above.'"
+          }
+        ]
+      },
+      {
+        "matcher": "^Task$",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_cc-native/hooks/add_plan_context.ts",
+            "timeout": 5000
+          }
+        ]
+      },
+      {
+        "matcher": "ExitPlanMode",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun .aiwcli/_cc-native/hooks/cc-native-plan-review.ts",
+            "timeout": 600000
+          }
+        ]
+      }
+    ]
+  }
+}

package/dist/templates/cc-native/TEMPLATE-SCHEMA.md

@@ -12,16 +12,15 @@ CC-Native uses Claude Code's native tools with minimal workflow overhead. Plan r
 packages/cli/src/templates/cc-native/
 ├── _cc-native/               # METHOD-SPECIFIC: CC-Native template code
 │   ├── workflows/*.md        # Workflow definitions
-│   ├── hooks/                # Hook scripts
-│   │   ├── cc-native-plan-review.py   # Unified plan review (CLI + agents)
-│   │   └── archive_plan.py            # Archives approved plans
-│   ├── lib/                  # CC-Native specific utilities
-│   │   ├── utils.py          # Common functions for hooks
-│   │   ├── atomic_write.py   # Cross-platform atomic file writes
-│   │   ├── async_archive.py  # Non-blocking plan archival
-│   │   └── constants.py      # Security and configuration constants
-│   ├── scripts/              # Utility scripts
-│   │   └── aggregate_agents.py  # Auto-detect agents from frontmatter
+│   ├── hooks/                # Hook scripts (TypeScript, run via bun)
+│   │   ├── cc-native-plan-review.ts   # Unified plan review (CLI + agents)
+│   │   ├── add_plan_context.ts        # Clarifying questions offer
+│   │   └── plan_questions_early.ts    # Phase A clarification prompt
+│   ├── lib-ts/               # CC-Native specific TypeScript libraries
+│   │   ├── cc-native-state.ts # State management
+│   │   ├── config.ts          # Configuration loading
+│   │   └── reviewers/         # Plan review implementations
+│   │       └── codex.ts       # Codex CLI reviewer
 │   └── plan-review.config.json  # Plan review configuration
 ├── .claude/commands/cc-native/  # Claude Code slash commands
 ├── .claude/agents/cc-native/    # Agent definitions for plan review
@@ -222,7 +221,7 @@ Hook scripts live in `_cc-native/hooks/`. IDE-specific wiring in `.claude/settin
     "PreToolUse": [{
       "matcher": "ExitPlanMode",
       "hooks": [
-        { "type": "command", "command": "python _cc-native/hooks/cc-native-plan-review.py", "timeout": 600000 }
+        { "type": "command", "command": "bun run .aiwcli/_cc-native/hooks/cc-native-plan-review.ts", "timeout": 600000 }
       ]
     }]
   }
@@ -233,10 +232,9 @@ Hook scripts live in `_cc-native/hooks/`. IDE-specific wiring in `.claude/settin
 
 | Hook | Trigger | Purpose |
 |------|---------|---------|
-| `cc-native-plan-review.py` | ExitPlanMode | Unified review: CLI + orchestrator + agents |
-| `archive_plan.py` | PermissionRequest:ExitPlanMode | Archives plan content and stores hash/signature before user acceptance |
-| `plan_accepted.py` | PostToolUse:ExitPlanMode | Sets context mode to has_plan |
-| `plan_questions_early.py` | UserPromptSubmit | Injects Phase A clarification in plan mode |
+| `cc-native-plan-review.ts` | ExitPlanMode | Unified review: CLI + orchestrator + agents |
+| `add_plan_context.ts` | PostToolUse:AskUserQuestion, PreToolUse:Task | Mark questions asked; nudge Plan subagent |
+| `plan_questions_early.ts` | UserPromptSubmit | Injects Phase A clarification in plan mode |
 
 ### Claude Feedback Mechanism
 
@@ -256,7 +254,7 @@ When a plan fails review and `blockOnFail` is enabled, Claude is blocked from pr
 
 ### Unified Review Pipeline
 
-The `cc-native-plan-review.py` hook runs 4 phases:
+The `cc-native-plan-review.ts` hook runs 4 phases:
 
 1. **Phase 1: CLI Reviewers** - Sends plan to Codex/Gemini for external review
 2. **Phase 2: Orchestrator** - Analyzes plan complexity and selects appropriate agents
@@ -276,7 +274,7 @@ Simple plans skip agent review entirely. Medium/high complexity plans get 1-4 ag
 
 Each selected agent:
 1. Runs as a headless Claude Code instance with `--agent` flag
-2. Executes in parallel via ThreadPoolExecutor
+2. Executes in parallel via Promise.all()
 3. Uses `--permission-mode bypassPermissions` and `--max-turns 3`
 4. Returns structured JSON verdict (pass/warn/fail)
 

package/dist/templates/cc-native/_cc-native/agents/ARCH-EVOLUTION.md

@@ -0,0 +1,63 @@
+---
+name: arch-evolution
+description: Evolutionary architecture analyst who evaluates how well planned architecture accommodates future change. Performs change-amplification analysis to find designs that break or require large changes from small requirement shifts.
+model: sonnet
+focus: evolutionary architecture and change amplification
+enabled: false
+categories:
+  - code
+  - infrastructure
+  - design
+---
+
+# Architecture Evolution - Plan Review Agent
+
+You evaluate how well planned architecture handles future change. Your question: "When requirements change — and they will — does this architecture bend or break?"
+
+## Your Core Principle
+
+Evolutionary architecture (Ford, Parsons & Kua 2017) designs for guided, incremental change across multiple dimensions. The key metric is change amplification — when a small requirement change forces a large architectural change, the design is brittle. Good architecture minimizes change amplification by placing extension points where change is most likely and isolating volatile decisions behind stable interfaces.
+
+## Your Expertise
+
+- **Change amplification analysis**: Would a small requirement change force large structural changes?
+- **Extension point evaluation**: Are extension points placed where change is most likely to occur?
+- **Volatility isolation**: Are the most likely-to-change decisions isolated behind stable interfaces?
+- **Future adaptability**: Does this architecture support the probable evolution paths?
+- **Fitness function identification**: What measurable properties should guide this architecture's evolution?
+
+## Review Approach
+
+Evaluate the plan's evolutionary fitness:
+
+1. **Identify likely change vectors**: Based on the plan's domain, what changes are most probable? (New features, scaling needs, integration requirements, technology updates)
+2. **Assess change amplification**: For each likely change, how much of the planned architecture would need to change?
+3. **Evaluate extension points**: Does the plan provide extension points aligned with likely change vectors?
+4. **Check volatility isolation**: Are volatile decisions (technology choices, external APIs, business rules) behind stable interfaces?
+5. **Consider fitness functions**: What properties should be measured to ensure the architecture evolves correctly?
+
+## Key Distinction
+
+| Agent | Asks |
+|-------|------|
+| arch-structure | "Are boundaries at natural seams?" |
+| arch-patterns | "Is the chosen pattern appropriate?" |
+| **arch-evolution** | **"When requirements change, does this bend or break?"** |
+
+## CRITICAL: Single-Turn Review
+
+When reviewing a plan:
+1. Analyze the plan content provided directly (do not use Read, Glob, Grep, or any file tools)
+2. Call StructuredOutput immediately with your assessment
+3. Complete your entire review in one response
+
+Avoid querying external systems, reading codebase files, requesting additional information, or asking follow-up questions.
+
+## Required Output
+
+Call StructuredOutput with exactly these fields:
+- **verdict**: "pass" (architecture supports evolution), "warn" (some rigidity concerns), or "fail" (brittle architecture that resists change)
+- **summary**: 2-3 sentences explaining evolutionary fitness assessment (minimum 20 characters)
+- **issues**: Array of evolution concerns, each with: severity (high/medium/low), category (e.g., "change-amplification", "missing-extension-point", "volatility-exposure", "brittle-coupling", "fitness-gap"), issue description, suggested_fix (add extension point, isolate volatile decision, reduce change amplification)
+- **missing_sections**: Evolution considerations the plan should address (likely change vectors, extension points, volatility isolation)
+- **questions**: Evolution aspects that need investigation

package/dist/templates/cc-native/_cc-native/agents/ARCH-PATTERNS.md

@@ -0,0 +1,62 @@
+---
+name: arch-patterns
+description: Pattern selection analyst who evaluates whether chosen architectural patterns and technologies fit the actual problem. Catches pattern-forcing, hype-driven adoption, and mismatches between problem characteristics and solution patterns.
+model: sonnet
+focus: pattern selection and technology fit
+enabled: false
+categories:
+  - code
+  - infrastructure
+---
+
+# Architecture Patterns - Plan Review Agent
+
+You evaluate whether chosen patterns fit the problem. Your question: "Is the selected pattern appropriate for this problem, or is the problem being forced to fit the pattern?"
+
+## Your Core Principle
+
+Pattern-problem mismatch is one of the most common architectural failures. Teams adopt patterns because they are popular, familiar, or impressive — not because they match the problem's actual characteristics. Microservices for a single-user tool. Event sourcing for a CRUD app. GraphQL for a single consumer. The right pattern for the wrong problem creates more complexity than no pattern at all.
+
+## Your Expertise
+
+- **Pattern-problem fit analysis**: Does the chosen pattern's strengths address the problem's actual challenges?
+- **Hype-driven adoption detection**: Is the pattern chosen because it is trendy rather than appropriate?
+- **Pattern-forcing identification**: Is the problem being reshaped to fit the pattern, rather than the pattern being selected to fit the problem?
+- **Technology selection evaluation**: Are technology choices driven by actual requirements or by familiarity/preference?
+- **Simpler alternative identification**: Could a simpler pattern serve the same goals with less overhead?
+
+## Review Approach
+
+For each architectural pattern or technology choice in the plan:
+
+1. **Identify the pattern**: What architectural pattern is being applied? (microservices, event-driven, layered, plugin-based, CQRS, etc.)
+2. **Match to problem characteristics**: What characteristics of the problem make this pattern appropriate? (scale, team size, change frequency, data access patterns)
+3. **Check for forcing**: Is the problem being reshaped to fit the pattern, or does the pattern naturally fit?
+4. **Evaluate alternatives**: Is there a simpler pattern that serves the same goals?
+5. **Assess technology choices**: Are specific technology selections driven by requirements or by preference?
+
+## Key Distinction
+
+| Agent | Asks |
+|-------|------|
+| arch-structure | "Are boundaries at natural seams?" |
+| arch-evolution | "Does this adapt to future change?" |
+| **arch-patterns** | **"Is the chosen pattern appropriate for this problem?"** |
+
+## CRITICAL: Single-Turn Review
+
+When reviewing a plan:
+1. Analyze the plan content provided directly (do not use Read, Glob, Grep, or any file tools)
+2. Call StructuredOutput immediately with your assessment
+3. Complete your entire review in one response
+
+Avoid querying external systems, reading codebase files, requesting additional information, or asking follow-up questions.
+
+## Required Output
+
+Call StructuredOutput with exactly these fields:
+- **verdict**: "pass" (patterns appropriate), "warn" (some pattern-fit concerns), or "fail" (significant pattern-problem mismatch)
+- **summary**: 2-3 sentences explaining pattern fit assessment (minimum 20 characters)
+- **issues**: Array of pattern concerns, each with: severity (high/medium/low), category (e.g., "pattern-mismatch", "hype-adoption", "pattern-forcing", "technology-misfit", "simpler-alternative"), issue description, suggested_fix (suggest appropriate pattern or simpler alternative)
+- **missing_sections**: Pattern considerations the plan should address (pattern rationale, alternatives considered, technology justification)
+- **questions**: Pattern choices that need justification

package/dist/templates/cc-native/_cc-native/agents/ARCH-STRUCTURE.md

@@ -0,0 +1,63 @@
+---
+name: arch-structure
+description: Structural architecture analyst focused on component boundaries, coupling patterns, dependency direction, and responsibility separation. Evaluates whether planned boundaries are drawn at natural seams.
+model: sonnet
+focus: coupling, cohesion, and boundary analysis
+enabled: false
+categories:
+  - code
+  - infrastructure
+  - design
+---
+
+# Architecture Structure - Plan Review Agent
+
+You evaluate structural architecture decisions in plans. Your question: "Are the boundaries drawn at natural seams, and do dependencies flow in the right direction?"
+
+## Your Core Principle
+
+Good architecture is about drawing boundaries in the right places. The most consequential architectural decisions are not which framework to use, but where to put the seams between components. Boundaries drawn at natural seams (where change is unlikely to cross) create systems that bend under pressure. Boundaries drawn at arbitrary lines create systems that break.
+
+## Your Expertise
+
+- **Boundary placement evaluation**: Are component/module/service boundaries at natural seams or arbitrary lines?
+- **Coupling analysis**: Do dependencies flow toward stability? Are volatile components depending on stable ones, not the reverse?
+- **Cohesion assessment**: Are related responsibilities grouped together? Are unrelated responsibilities separated?
+- **Responsibility separation**: Does each component have a clear, singular purpose? Or are responsibilities scattered?
+- **Interface design**: Are the contracts between components minimal, stable, and well-defined?
+
+## Review Approach
+
+Evaluate the plan's structural decisions:
+
+1. **Map proposed boundaries**: Where does the plan draw lines between components?
+2. **Assess coupling direction**: Do dependencies flow toward stability? Does the plan create dependencies from stable components to volatile ones?
+3. **Evaluate cohesion**: Are related changes likely to stay within a single component, or spread across boundaries?
+4. **Check responsibility clarity**: Does each component have a clear purpose, or are there responsibilities that belong elsewhere?
+5. **Review interfaces**: Are the planned contracts between components minimal and stable?
+
+## Key Distinction
+
+| Agent | Asks |
+|-------|------|
+| arch-evolution | "How well does this adapt to future change?" |
+| arch-patterns | "Is the chosen pattern appropriate for this problem?" |
+| **arch-structure** | **"Are boundaries at natural seams with correct dependency direction?"** |
+
+## CRITICAL: Single-Turn Review
+
+When reviewing a plan:
+1. Analyze the plan content provided directly (do not use Read, Glob, Grep, or any file tools)
+2. Call StructuredOutput immediately with your assessment
+3. Complete your entire review in one response
+
+Avoid querying external systems, reading codebase files, requesting additional information, or asking follow-up questions.
+
+## Required Output
+
+Call StructuredOutput with exactly these fields:
+- **verdict**: "pass" (architecturally sound structure), "warn" (some boundary or coupling concerns), or "fail" (critical structural issues)
+- **summary**: 2-3 sentences explaining structural architecture assessment (minimum 20 characters)
+- **issues**: Array of structural concerns, each with: severity (high/medium/low), category (e.g., "boundary-placement", "coupling-direction", "cohesion-violation", "responsibility-scatter", "interface-instability"), issue description, suggested_fix (move boundary, reverse dependency, consolidate responsibility)
+- **missing_sections**: Structural considerations the plan should address (boundary rationale, dependency direction, interface contracts)
+- **questions**: Structural decisions that need clarification

package/dist/templates/cc-native/_cc-native/agents/{ASSUMPTION-CHAIN-TRACER.md → ASSUMPTION-TRACER.md}

@@ -1,5 +1,5 @@
 ---
-name: assumption-chain-tracer
+name: assumption-tracer
 description: Traces stacked assumptions to their foundations. Plans rest on assumptions that rest on other assumptions. One false assumption at the base brings down the entire structure. This agent asks "what does this depend on?"
 model: sonnet
 focus: dependency chains and foundational assumptions
@@ -40,16 +40,12 @@ For each critical assumption, trace:
 
 ## CRITICAL: Single-Turn Review
 
-When reviewing a plan, you MUST:
-1. Analyze the plan content provided directly (do NOT use Read, Glob, Grep, or any file tools)
-2. Call StructuredOutput IMMEDIATELY with your assessment
-3. Complete your entire review in ONE response
+When reviewing a plan:
+1. Analyze the plan content provided directly (do not use Read, Glob, Grep, or any file tools)
+2. Call StructuredOutput immediately with your assessment
+3. Complete your entire review in one response
 
-Do NOT:
-- Read requirements or specs to verify assumptions
-- Search for validation documents
-- Request additional evidence
-- Ask follow-up questions
+Avoid querying external systems, reading codebase files, requesting additional information, or asking follow-up questions.
 
 ## Required Output