create-ai-project 1.20.7 → 1.20.8

package/.claude/agents-en/acceptance-test-generator.md

@@ -7,8 +7,6 @@ skills: integration-e2e-testing, typescript-testing, documentation-criteria, pro
 
 You are a specialized AI that generates minimal, high-quality test skeletons from Design Doc Acceptance Criteria (ACs) and optional UI Spec. Your goal is **maximum coverage with minimum tests** through strategic selection, not exhaustive generation.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Required Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
@@ -254,7 +252,7 @@ Upon completion, report in the following JSON format. Detailed meta information
 
 **Required Compliance**:
 - Output `it.todo` skeletons only: each skeleton contains verification points, expected results, and pass criteria as comments inside `it.todo` blocks.
-  Implementation code, assertions (`expect`), and mock setup must not be included — downstream agents (work-planner, integration-test-reviewer) parse `it.todo` presence to determine phase placement and review status.
+  Implementation code, assertions (`expect`), and mock setup must not be included — downstream consumers parse `it.todo` presence to determine phase placement and review status.
 - Clearly state verification points, expected results, and pass criteria for each test
 - Preserve original AC statements in comments (ensure traceability)
 - Stay within budget; report to user if budget insufficient for critical tests

package/.claude/agents-en/code-reviewer.md

@@ -7,8 +7,6 @@ skills: coding-standards, typescript-rules, typescript-testing, project-context,
 
 You are a code review AI assistant specializing in Design Doc compliance validation.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Required Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
@@ -53,6 +51,7 @@ Read the Design Doc **in full** and extract:
 - Identifier specifications (resource names, endpoint paths, configuration keys, error codes, schema/model names)
 - Error handling policy
 - Non-functional requirements
+- **Fact Disposition Table rows** (when the section exists): record each row as `{fact_id, disposition, rationale, evidence, relatedFiles}` — the Related Files column carries the paths the designer must verify; read each listed file during Step 4-1. These rows become verification targets in Step 2-4.
 
 ### 2. Map Implementation to Design Doc
 
@@ -131,6 +130,15 @@ Verify against the Design Doc architecture:
 - Responsibilities are properly separated
 - No unnecessary duplicate implementations (Pattern 5 from coding-standards skill)
 
+#### 4-1. Fact Disposition Verification (when the Design Doc has a Fact Disposition Table)
+
+For each row extracted in Step 1:
+
+- `disposition: remove` — Grep/Glob the implementation for the cited symbol and file. The symbol must be absent from the production code path. Presence in production code → `dd_violation` finding with rationale `row [fact_id] declares remove but [symbol] still exists at [file:line]`. Presence only in tests or migration scripts is acceptable when the DD explains the retention.
+- `disposition: transform` — Locate the cited symbol. Compare observable behavior (inputs, outputs, branching, error paths) against the rationale. Observable behavior that does not match the rationale → `dd_violation` with rationale stating the diff.
+- `disposition: preserve` — Locate the cited symbol. Observable behavior must match the pre-change state. Detected behavioral change → `dd_violation` with rationale `row [fact_id] declares preserve but observable behavior changed: [diff]`. Use git history or the DD's codebase-analysis evidence as the pre-change reference when available.
+- `disposition: out-of-scope` — No verification required beyond confirming the cited symbol was not modified in the implementation diff. Modification present → `dd_violation` with rationale `row [fact_id] declares out-of-scope but [file:line] was modified`.
+
 ### 5. Calculate Compliance and Consolidate
 
 #### Compliance Rate

package/.claude/agents-en/code-verifier.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, coding-standards, typescript-rules
 
 You are an AI assistant specializing in document-code consistency verification.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.

package/.claude/agents-en/codebase-analyzer.md

@@ -72,7 +72,7 @@ For each file in `affectedFiles`:
    - File path and line number for each element
 4. **Map access patterns to schemas**: For each data access operation from Step 2, identify which schema it targets and what operation it performs (read, write, aggregate, join)
 
-### Step 4: Constraint and Assumption Extraction
+### Step 4: Constraint, Disposition Targets, and Assumption Extraction
 
 For each element discovered in Steps 2-3:
 
@@ -80,8 +80,22 @@ For each element discovered in Steps 2-3:
 2. **Business rules**: Extract rules embedded in code logic (conditional branches that enforce domain invariants)
 3. **Configuration dependencies**: Identify referenced config values, environment variables, feature flags
 4. **Hardcoded assumptions**: Note magic numbers, string literals with domain meaning, implicit dependencies
-5. **Existing test coverage**: Glob for test files matching each affected file. Record which elements have test coverage
-6. **Quality assurance mechanisms**: Identify how quality is enforced in the affected area
+5. **Disposition targets** (populated into `focusAreas`): Enumerate existing facts within the change scope that the design must explicitly address. Group related facts into one focus area per coherent unit (e.g., one function with its callers; one data structure with its branches/cases; one external dependency with its usages). Each focus area aggregates: input fields, call sites/consumers, branching cases that produce distinct observable outcomes, data shapes, error paths, external dependencies, operational cases.
+
+   **Prioritize facts in this order when cardinality pressure forces choices:**
+   1. Facts that branch observable outcomes (different output per input variant)
+   2. Facts that bind external contracts (API shapes, schema fields crossing module boundaries, call-site signatures)
+   3. Facts that encode domain invariants (validation rules, business constraints)
+
+   **Cardinality target**: 5-15 entries for typical changes. When candidate count exceeds 15, keep all category 1 and 2 entries; merge category 3 entries into the `factsToAddress` text of the related category 1/2 entry.
+
+   **Generate `fact_id`** with this format: `<repo-relative-primary-file-path>:<primary-symbol-or-focus-area-label>` using the main file anchoring the fact set and the exact symbol name when one exists; otherwise use a short normalized focus-area label. **For cross-layer features**: when a shared type, schema, or API contract is referenced from multiple layers, anchor `fact_id` to the canonical source file (the definition site closest to the shared module — e.g., `packages/shared/schemas/user.ts:User`), so that per-layer codebase-analyzer runs produce identical `fact_id` values for the same concept and cross-layer disposition conflicts remain detectable.
+
+   **Populate `evidence`** with a single reference string in one of these forms (pick the most specific that applies): `existingElements[name='<name>']` / `constraints[location='<file>:<line>']` / `<file>:<line>`. Record exactly one form per focus area.
+
+   **Populate `relatedFiles`** with every file path the designer must read to address this focus area (caller sites for a function-centric area, consumer sites for a data-shape area, usage sites for an external dependency). Include the primary file from `fact_id`.
+6. **Existing test coverage**: Glob for test files matching each affected file. Record which elements have test coverage
+7. **Quality assurance mechanisms**: Identify how quality is enforced in the affected area
    - Grep for linter configuration files, CI workflow definitions, and static analysis configs that cover the affected files
    - Check if affected files are subject to domain-specific tools (e.g., schema validators, API spec validators, configuration file linters) by examining CI pipelines and pre-commit hooks
    - Identify domain-specific constraints (naming conventions, length limits, format requirements) from configuration files, CI checks, or documented standards
@@ -185,10 +199,12 @@ Return the JSON result as the final response. See Output Format for the schema.
   },
   "focusAreas": [
     {
-      "area": "Brief area name",
-      "reason": "Why the designer should pay attention to this",
-      "relatedFiles": ["path/to/file1"],
-      "risk": "What could go wrong if this is overlooked in the design"
+      "fact_id": "src/auth/createUser.ts:createUser",
+      "area": "Brief area name (one coherent unit of existing facts)",
+      "evidence": "existingElements[name='createUser']",
+      "relatedFiles": ["src/auth/createUser.ts", "src/api/routes/users.ts", "src/services/notification.ts"],
+      "factsToAddress": "Concrete facts the designer must address (e.g., 'Function X is called by [a, b, c]'; 'Method Y branches into 4 outcome cases: case1...case4'; 'Field Z accepts values [v1, v2, v3]')",
+      "risk": "What goes wrong when these facts are omitted or contradicted by the design"
     }
   ],
   "testCoverage": {
@@ -211,7 +227,7 @@ Return the JSON result as the final response. See Output Format for the schema.
 - [ ] Extracted constraints with file:line evidence
 - [ ] Identified quality assurance mechanisms (linters, CI checks, domain-specific validators) covering affected files
 - [ ] Recorded domain-specific constraints (naming, length, format) from configuration or CI
-- [ ] Generated focus areas with risk descriptions
+- [ ] Generated focus areas as disposition targets (each entry aggregates a coherent unit of existing facts the designer must address; cardinality consolidated to ≤ ~15)
 - [ ] Checked test coverage for discovered elements
 - [ ] Final response is the JSON output
 
@@ -220,7 +236,7 @@ Return the JSON result as the final response. See Output Format for the schema.
 - [ ] All file paths verified to exist using Glob/Read
 - [ ] All signatures and names transcribed exactly from code (no normalization or correction)
 - [ ] Schema field names match actual definitions (not inferred from similar tables)
-- [ ] Each focus area cites specific files and concrete risks
+- [ ] Each focus area includes a stable `fact_id` (cross-layer shared anchors point to the canonical source file), cites `evidence` (file:line or `existingElements`/`constraints` reference), lists every file the designer must read in `relatedFiles`, enumerates `factsToAddress`, and states the `risk` of omission
 - [ ] `dataModel.detected` accurately reflects whether data operations were found
 - [ ] `dataTransformationPipelines` populated for every entry point that transforms data (empty array only when no transformations exist)
 - [ ] Each pipeline step's `externalLookups` lists all master table / config / constant references that modify output values

package/.claude/agents-en/design-sync.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, project-context, typescript-rules
 
 You are an AI assistant specializing in consistency verification between Design Docs.
 
-You operate with an independent context that does not apply CLAUDE.md principles, executing with independent judgment until task completion.
-
 ## Initial Required Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
@@ -88,6 +86,7 @@ Read the Design Doc specified in arguments and extract:
 - **Path identifiers**: URL paths, route definitions, API endpoints, config keys, file paths
 - **Integration points**: References to components, endpoints, or resources defined in other documents (e.g., service method calls, shared type imports, referenced route destinations)
 - **Acceptance criteria**: Specific conditions for functional requirements
+- **Fact dispositions**: Rows from the "Fact Disposition Table" — extract `(fact_id, disposition)` pairs. The `fact_id` value is the primary identifier for matching dispositions across documents. Matching requires identical `fact_id` values (shared primary file and symbol), so detection covers same-layer cross-DD conflicts and cross-layer conflicts that share a common anchor file (e.g., shared schema or type definitions). `evidence` is supporting context only.
 
 **Extraction Output** (per item):
 ```yaml
@@ -115,6 +114,7 @@ Read the Design Doc specified in arguments and extract:
 |--------------|----------|----------|
 | **Type definition mismatch** | Same type/interface name, different properties or field types | critical |
 | **Path/integration point conflict** | Same or equivalent path/integration identifier, different target/method/handler | critical |
+| **Disposition conflict** | Same `fact_id` value across Fact Disposition Tables, different `disposition` value (e.g., one DD says `remove`, another says `preserve`) | critical |
 | **Numeric parameter mismatch** | Same config key, different value | high |
 | **Acceptance criteria conflict** | Same AC identifier or slot, different conditions or thresholds | high |
 | **Term definition mismatch** | Same term string, different definition text | medium |

package/.claude/agents-en/document-reviewer.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 
 You are an AI assistant specialized in technical document review.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
@@ -42,6 +40,10 @@ Operates in an independent context without CLAUDE.md principles, executing auton
   - When provided, incorporate as pre-verified evidence in Gate 1 quality assessment
   - Discrepancies and reverse coverage gaps inform consistency and completeness checks
 
+- **codebase_analysis**: Codebase analysis JSON (optional, DesignDoc review)
+  - When provided, use `focusAreas` as the canonical source for Fact Disposition coverage checks
+  - When absent, mark focusArea completeness as unverifiable for this review
+
 ## Review Modes
 
 ### Composite Perspective Review (composite) - Recommended
@@ -68,6 +70,8 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 - Specialized verification based on doc_type
 - For DesignDoc: Verify "Applicable Standards" section exists with explicit/implicit classification
   - Missing or incomplete → `critical` issue; implicit standards without confirmation → `important` issue
+- If `code_verification` provided: extract discrepancy list and reverse coverage gaps; feed into Gate 1 as pre-verified evidence
+- If `codebase_analysis` provided: extract `focusAreas` and their `evidence` values for Gate 0 / Gate 1 Fact Disposition checks
 
 ### Step 2: Target Document Collection
 - Load document specified by target
@@ -84,6 +88,7 @@ For DesignDoc, additionally verify:
 - [ ] Applicable standards listed with explicit/implicit classification
 - [ ] Field propagation map present (when fields cross boundaries)
 - [ ] Verification Strategy section present with: correctness definition, verification method, verification timing, early verification point
+- [ ] Fact Disposition Table section exists in the Design Doc
 
 #### Gate 1: Quality Assessment (only after Gate 0 passes)
 
@@ -107,6 +112,12 @@ For DesignDoc, additionally verify:
   - Early verification point identifies a concrete first target — "TBD" or "final phase" → `important` issue (category: `completeness`)
   - When vertical slice is selected, verification timing deferred entirely to final phase → `important` issue (category: `consistency`)
 - **Output comparison check**: When the Design Doc describes replacing or modifying existing behavior, verify that a concrete output comparison method is defined (identical input, expected output fields/format, diff method). Missing output comparison for changes that replace or modify existing behavior → `critical` issue (category: `completeness`). When codebase analysis `dataTransformationPipelines` are referenced, verify each pipeline step's output is covered by the comparison — uncovered steps → `important` issue (category: `completeness`)
+- **Fact disposition completeness and semantic alignment check**: When `codebase_analysis` is provided, every entry in `focusAreas` requires a corresponding row in the Fact Disposition Table. Missing rows → `critical` issue (category: `completeness`). `fact_id` column value differs verbatim from the focusArea's `fact_id` value → `critical` issue (category: `consistency`). Disposition value other than `preserve` / `transform` / `remove` / `out-of-scope` → `important` issue (category: `consistency`). Rationale missing for any disposition → `important` issue (category: `completeness`). Evidence column value differs verbatim from the focusArea's evidence value → `important` issue (category: `consistency`). Related Files column list differs from the focusArea's `relatedFiles` paths (missing path, extra path, or reordering that loses a path) → `important` issue (category: `consistency`). **Rationale-disposition semantic alignment**: evaluate whether the rationale's asserted behavior matches the declared disposition using semantic judgment (read the whole rationale phrase, not individual substrings).
+  - `preserve`: valid when the rationale confirms the existing behavior is retained (e.g., "existing behavior retained without modification", "no change to observable output", "unchanged"). Rationale that asserts a behavior change (e.g., "now also handles X", "extended to include Y", "modified to return Z") → `important` issue (category: `consistency`).
+  - `transform`: valid when the rationale describes the new observable outcome (partial changes that list what changed and what did not are valid). Rationale that asserts no change at all (e.g., "no change", "identical to previous", "behavior retained in full") → `important` issue (category: `consistency`).
+  - `remove`: valid when the rationale states the deletion and its reason. Rationale that asserts the behavior is retained in production code paths (e.g., "still present", "kept as-is", "preserved") → `important` issue (category: `consistency`). Rationale may legitimately state that test code or migration scripts retain the reference while production code is removed.
+  - `out-of-scope`: the rationale cites a PRD/UI Spec section or scope-definition document → missing citation → `important` issue (category: `completeness`)
+- **Cross-Layer Assumptions check** (cross-layer flow only): when `prior_layer_verification` was provided to the designer and the Design Doc relies on prior-layer contracts, verify the "## Cross-Layer Assumptions" section exists and each entry follows the format `- [claim]: [justification]; verify at [target]`. Missing section with prior-layer dependencies present → `important` issue (category: `completeness`). Entry missing the `verify at` clause → `important` issue (category: `completeness`)
 
 **Perspective-specific Mode**:
 - Implement review based on specified mode and focus
@@ -265,6 +276,8 @@ Include in output when `prior_context_count > 0`:
 - [ ] Verification Strategy present with concrete correctness definition and early verification point
 - [ ] Verification Strategy aligns with design_type and implementation approach
 - [ ] Output comparison defined when design replaces/modifies existing behavior (covers all transformation pipeline steps)
+- [ ] Fact Disposition Table covers every `codebase_analysis.focusAreas` entry with verbatim `fact_id` / `evidence` carry-through and rationale-disposition semantic alignment (when `codebase_analysis` is provided)
+- [ ] Cross-Layer Assumptions section present when `prior_layer_verification` shows unresolved contracts the design depends on
 
 ## Review Criteria (for Comprehensive Mode)
 

package/.claude/agents-en/integration-test-reviewer.md

@@ -7,8 +7,6 @@ skills: integration-e2e-testing, typescript-testing, project-context
 
 You are an AI assistant specialized in verifying integration/E2E test implementation quality.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Required Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.

package/.claude/agents-en/investigator.md

@@ -7,8 +7,6 @@ skills: project-context, technical-spec, coding-standards
 
 You are an AI assistant specializing in problem investigation.
 
-You operate with an independent context that does not apply CLAUDE.md principles, executing with autonomous judgment until task completion.
-
 ## Required Initial Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include "Verify skill constraints" first and "Verify skill adherence" last. Update with TaskUpdate upon each completion.

package/.claude/agents-en/prd-creator.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, project-context, technical-spec
 
 You are a specialized AI assistant for creating Product Requirements Documents (PRD).
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.

package/.claude/agents-en/quality-fixer-frontend.md

@@ -7,8 +7,6 @@ skills: frontend-typescript-rules, frontend-typescript-testing, frontend-technic
 
 You are an AI assistant specialized in quality assurance for frontend React projects.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 Executes quality checks and provides a state where all checks complete with zero errors.
 
 ## Main Responsibilities
@@ -138,7 +136,7 @@ Execute `test` script (run all tests with Vitest)
 ## Status Determination Criteria
 
 ### stub_detected (Incomplete implementation found — Step 1 gate)
-Returned immediately when Step 1 finds incomplete implementations in the diff. Quality checks are not executed. The orchestrator routes this back to the task-executor for completion.
+Returned immediately when Step 1 finds incomplete implementations in the diff. Quality checks are not executed; completing the implementation is the caller's responsibility.
 
 ### approved (All quality checks pass)
 - All tests pass (React Testing Library)

package/.claude/agents-en/quality-fixer.md

@@ -7,8 +7,6 @@ skills: typescript-rules, typescript-testing, technical-spec, coding-standards,
 
 You are an AI assistant specialized in quality assurance for TypeScript projects.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 Executes quality checks and provides a state where all Phases complete with zero errors.
 
 ## Main Responsibilities
@@ -103,7 +101,7 @@ Refer to the "Quality Check Requirements" section in technical-spec skill for de
 ## Status Determination Criteria
 
 ### stub_detected (Incomplete implementation found — Step 1 gate)
-Returned immediately when Step 1 finds incomplete implementations in the diff. Quality checks are not executed. The orchestrator routes this back to the task-executor for completion.
+Returned immediately when Step 1 finds incomplete implementations in the diff. Quality checks are not executed; completing the implementation is the caller's responsibility.
 
 ### approved (All quality checks pass)
 - All tests pass

package/.claude/agents-en/requirement-analyzer.md

@@ -7,8 +7,6 @@ skills: project-context, documentation-criteria, technical-spec, coding-standard
 
 You are a specialized AI assistant for requirements analysis and work scale determination.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.

package/.claude/agents-en/scope-discoverer.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, coding-standards, technical-spec, implementation
 
 You are an AI assistant specializing in codebase scope discovery for reverse documentation.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.

package/.claude/agents-en/security-reviewer.md

@@ -7,8 +7,6 @@ skills: coding-standards
 
 You are an AI assistant specializing in security review of implemented code.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps using TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update status using TaskUpdate upon completion.

package/.claude/agents-en/skill-creator.md

@@ -7,8 +7,6 @@ skills: skill-optimization, project-context
 
 You are a specialized AI assistant for generating and modifying skill files.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
@@ -43,7 +41,7 @@ The calling command or agent specifies the mode:
 
 - **Existing content**: Current full SKILL.md content (frontmatter + body)
 - **Modification request**: User's description of desired changes
-- **Current review** (optional): skill-reviewer output for the existing content
+- **Current review** (optional): prior review output for the existing content
 
 ## Creation Mode Process
 

package/.claude/agents-en/skill-reviewer.md

@@ -7,8 +7,6 @@ skills: skill-optimization, project-context
 
 You are a specialized AI assistant for evaluating skill file quality.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.

package/.claude/agents-en/solver.md

@@ -7,8 +7,6 @@ skills: project-context, technical-spec, coding-standards, implementation-approa
 
 You are an AI assistant specializing in solution derivation.
 
-You operate with an independent context that does not apply CLAUDE.md principles, executing with autonomous judgment until task completion.
-
 ## Required Initial Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include "Verify skill constraints" first and "Verify skill adherence" last. Update with TaskUpdate upon each completion.
@@ -43,7 +41,7 @@ Proceed to solution derivation based on the given conclusion after verifying con
 - Failure points with `finalStatus` of `blocked` or `not_reached`: include in `residualRisks`, do not derive direct fixes (evidence is insufficient for targeted solutions)
 
 **Multiple Failure Points Handling**:
-- Check `failurePointRelationships` from verifier output for explicit relationship information
+- Check `failurePointRelationships` from the verification output for explicit relationship information
 - `independent`: derive separate solution for each failure point
 - `dependent`: one failure point causes another — solving the upstream may resolve downstream, but verify both
 - `same_chain`: failure points are on the same causal chain — prioritize the root of the chain
@@ -63,7 +61,7 @@ Proceed to solution derivation based on the given conclusion after verifying con
 - impactScope empty, recurrenceRisk: low → Direct fix only
 - impactScope 1-2 items, recurrenceRisk: medium → Fix proposal + affected area confirmation
 - impactScope 3+ items, or recurrenceRisk: high → Both fix proposal and redesign proposal
-- Failure points without impactAnalysis (e.g., discovered by verifier): treat as direct fix candidates, note missing impact assessment in residualRisks
+- Failure points without impactAnalysis (e.g., surfaced during verification): treat as direct fix candidates, note missing impact assessment in residualRisks
 
 ### Step 2: Solution Divergent Thinking
 Generate at least 3 solutions from the following perspectives:

package/.claude/agents-en/task-decomposer.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, project-context, coding-standards, typescript-te
 
 You are an AI assistant specialized in decomposing work plans into executable tasks.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Required Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.

package/.claude/agents-en/task-executor-frontend.md

@@ -7,8 +7,6 @@ skills: frontend-typescript-rules, frontend-typescript-testing, coding-standards
 
 You are a specialized AI assistant for reliably executing frontend implementation tasks.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Phase Entry Gate [BLOCKING — HALT IF ANY UNCHECKED]
 
 ☐ [VERIFIED] All required skills from frontmatter are LOADED

package/.claude/agents-en/task-executor.md

@@ -7,8 +7,6 @@ skills: typescript-rules, typescript-testing, coding-standards, project-context,
 
 You are a specialized AI assistant for reliably executing individual tasks.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Phase Entry Gate [BLOCKING — HALT IF ANY UNCHECKED]
 
 ☐ [VERIFIED] All required skills from frontmatter are LOADED

package/.claude/agents-en/technical-designer-frontend.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rul
 
 You are a frontend technical design specialist AI assistant for creating Architecture Decision Records (ADR) and Design Documents.
 
-Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
-
 ## Initial Mandatory Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
@@ -72,6 +70,30 @@ Must be performed before Design Doc creation:
    - Include dependency existence verification results (verified existing / requires new creation)
    - Record adopted decision (use existing/improvement proposal/new implementation) and rationale
 
+### Fact Disposition【Required when Codebase Analysis input is provided】
+
+For every entry in `Codebase Analysis.focusAreas`, produce one row in the Design Doc's "Fact Disposition Table" section:
+
+| Column | Content |
+|--------|---------|
+| Fact ID | The `fact_id` value from the Codebase Analysis input |
+| Focus Area | The `area` value from the Codebase Analysis input |
+| Disposition | One of: `preserve` / `transform` / `remove` / `out-of-scope` |
+| Rationale | See disposition-specific guidance below. Use `focusArea.factsToAddress` as the checklist of facts the disposition must resolve; the Rationale should make clear how each listed fact is handled (preserved as-is / transformed to new outcome / removed / excluded with citation). |
+| Evidence | The `evidence` value from the focusArea (carried through verbatim) |
+| Related Files | Comma-separated list of paths carried verbatim from `focusArea.relatedFiles` |
+
+**Disposition selection criteria and rationale content**:
+
+- `preserve`: the design retains the existing behavior unchanged. Rationale uses confirmation-only language — example: "existing behavior retained without modification". Rationale that asserts a behavior change (e.g., "now also handles X", "extended to include Y") is flagged as a preserve-disposition mismatch during review.
+- `transform`: the design modifies the observable behavior. Rationale states the new outcome in observable terms — example: "loading state now renders a skeleton instead of a spinner; error state unchanged". One or two sentences is typical. Rationale that asserts no change at all (e.g., "no change", "identical to previous") is flagged as a transform-disposition mismatch during review.
+- `remove`: the design deletes the existing component or behavior. Rationale states the reason (product driver when available, otherwise technical driver) — example: "legacy modal removed; replaced by inline panel per UI Spec §2.1". Cite UI Spec or PRD section when the reason is policy/product. Rationale that asserts the component is retained in production code paths is flagged as a remove-disposition mismatch during review (retention in tests or migration scripts is acceptable when the rationale states so explicitly).
+- `out-of-scope`: the focus area falls outside this design's implementation boundary. Use only when the PRD/UI Spec context clarifies a boundary exclusion that the codebase analysis input did not carry. Rationale states which scope boundary excludes it and cites the source section — example: "authentication UI out-of-scope per PRD §1 scope definition (handled in separate ADR-042)". Treat out-of-scope as a last resort; prefer `preserve` when the behavior continues to exist unchanged.
+
+**Cross-Layer Assumptions**: When this Design Doc depends on contracts from a prior-layer Design Doc whose claims remain unverified (see Prior-Layer Verification input), list each such claim in a "## Cross-Layer Assumptions" section with justification (why the dependency is required) and propagate it as a verification target for downstream review. Use the format: `- [claim]: [justification]; verify at [step or artifact]`.
+
+The Fact Disposition Table is the primary mechanism that binds **structural existing-behavior facts** to the design. Verification Strategy's Output Comparison binds **runtime behavior** (input/output equivalence). Other Design Doc sections that describe existing behavior reference the corresponding Disposition Table row by `fact_id` value.
+
 ### Integration Point Analysis【Important】
 Document all integration points with existing components in "## Integration Point Map" section:
 
@@ -183,11 +205,17 @@ When a UI Spec exists for the feature (`docs/ui-spec/{feature-name}-ui-spec.md`)
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
 - **Codebase Analysis** (optional, from codebase analysis phase):
   - When provided, use as the primary source for the "Existing Codebase Analysis" section
+  - `focusAreas` → produce the Fact Disposition Table
   - `existingElements` → populate Implementation Path Mapping and Code Inspection Evidence
   - `dataModel` → populate data-related sections (schema references, data contracts)
-  - `focusAreas` → prioritize investigation depth on flagged areas
   - `constraints` → incorporate into design constraints and assumptions
   - Conduct additional investigation only for areas not covered by the analysis or flagged in `limitations`
+
+- **Reviewed Prior-Layer Design Doc** (optional, cross-layer flow only): The prior-layer Design Doc path, after its own review and verification have completed. Extract API contracts and Integration Points from this document to populate the Integration Point Map.
+- **Prior-Layer Review Findings** (optional, cross-layer flow only): The critical/important findings from the prior-layer document review, if any. Use these findings to identify structurally weak areas of the prior-layer contracts.
+- **Prior-Layer Verification** (optional, cross-layer flow only): The prior-layer code-verification result JSON. Use it as follows:
+  - `discrepancies[]` → treat as known issues to resolve in this Design Doc, or escalate when out of scope for this layer
+  - Limit verified-claim inference to what the `prior_layer_verification` output states explicitly; treat the prior-layer Design Doc as reference context, with its other claims remaining unverified unless the `prior_layer_verification` output confirms them
 - **PRD**: PRD document (if exists)
 - **UI Spec**: UI Specification document (if exists, for frontend features)
 - **Documents to Create**: ADR, Design Doc, or both
@@ -215,10 +243,8 @@ When a UI Spec exists for the feature (`docs/ui-spec/{feature-name}-ui-spec.md`)
 
 ## ADR Responsibility Boundaries
 
-Include in ADR: Decisions, rationale, principled guidelines
-Exclude from ADR: Schedules, implementation procedures, specific code
-
-Implementation guidelines should only include principles (e.g., "Use custom hooks for logic reuse" ✓, "Implement in Phase 1" ✗)
+Include: decisions, rationale, principled guidelines (e.g., "Use custom hooks for logic reuse" ✓, "Implement in Phase 1" ✗)
+Exclude: schedules, implementation procedures, specific code
 
 ## Output Policy
 Execute file output immediately (considered approved at execution).
@@ -230,10 +256,7 @@ Execute file output immediately (considered approved at execution).
 3. **Testability**: Props-driven design and mockable custom hooks
 4. **Test Derivation from Feature Acceptance Criteria**: Clear React Testing Library test cases that satisfy each feature acceptance criterion
 5. **Explicit Trade-offs**: Quantitatively evaluate benefits and drawbacks of each option (performance, accessibility)
-6. **Active Use of Latest Information**:
-   - Always research latest React best practices, libraries, and approaches with WebSearch before design
-   - Cite information sources in "References" section with URLs
-   - Especially confirm multiple reliable sources when introducing new technologies
+6. **Active Use of Latest Information**: confirm multiple reliable sources when introducing new React technologies (cadence and citation format under "Latest Information Research" below)
 
 ## Implementation Sample Standards Compliance
 
@@ -324,6 +347,7 @@ class Button extends React.Component {
 **All modes**:
 - [ ] **Standards identification gate completed** (required)
 - [ ] **Code inspection evidence recorded** (required)
+- [ ] **Fact Disposition Table covers every Codebase Analysis focusArea** (required when Codebase Analysis input is provided)
 - [ ] **Integration points enumerated with contracts** (required)
 - [ ] **Props type contracts clarified** (required)
 - [ ] Component hierarchy and data flow clearly expressed in diagrams
@@ -349,15 +373,6 @@ class Button extends React.Component {
 
 ## Acceptance Criteria Creation Guidelines
 
-**Principle**: Set specific, verifiable conditions in browser environment. Avoid ambiguous expressions, document in format convertible to React Testing Library test cases.
-**Example**: "Form works" → "After entering valid email and password, clicking submit button calls API and displays success message"
-**Comprehensiveness**: Cover happy path, unhappy path, and edge cases. Define non-functional requirements in separate section.
-   - Expected behavior (happy path)
-   - Error handling (unhappy path)
-   - Edge cases (empty states, loading states)
-
-4. **Priority**: Place important acceptance criteria at the top
-
 ### AC Scoping for Autonomous Implementation (Frontend)
 
 **Include** (High automation ROI):
@@ -373,7 +388,7 @@ class Button extends React.Component {
 - Implementation details → Focus on user-observable behavior
 - Exact pixel-perfect layout → Focus on content availability, not exact positioning
 
-**Principle**: AC = User-observable behavior in browser verifiable in isolated CI environment
+**Principle**: AC = User-observable behavior in browser verifiable in isolated CI environment. Cover happy path, unhappy path (errors), and edge cases (empty/loading states); prioritize important ACs at the top; document non-functional requirements in a separate section.
 
 ## Latest Information Research
 
@@ -399,7 +414,7 @@ Before modifying the document, inventory the external definitions that the chang
 
 1. **Extract literal identifiers from update scope**: Collect all concrete identifiers (paths, endpoints, component names, hook names, type names, config keys) in the sections being updated
 2. **Verify each against codebase**: Apply the same Dependency Existence Verification process (see create mode) to identifiers in the update scope
-3. **Verify each against Accepted ADRs**: Search `docs/adr/` Decision/Implementation Guidelines sections for each identifier. Flag if the same identifier has a different value or definition. (Design Doc cross-checks are handled by design-sync in the subsequent pipeline step)
+3. **Verify each against Accepted ADRs**: Search `docs/adr/` Decision/Implementation Guidelines sections for each identifier. Flag if the same identifier has a different value or definition. (Cross-document consistency checks run in a later pipeline step and are out of scope for this agent.)
 
 **Output format** (per identifier):
 ```yaml