create-ai-project 1.20.6 → 1.20.8

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
@@ -135,6 +133,17 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
 2. **Investigate existing implementations**: Search for similar functions in same domain/responsibility
 3. **Execute determination**: Determine continue/escalation per "Mandatory Judgment Criteria" above
 
+#### Reference Representativeness (Applied During Implementation)
+
+A per-adoption check applied each time a pattern or dependency is referenced. Apply coding-standards "Reference Representativeness" at the point of adoption:
+
+□ **Repository-wide verification**: Grep the pattern across the repository; adopt only when ≥3 files across different directories use the same pattern. When Grep returns 0-2 files outside the reference, investigate whether they are canonical or legacy before adopting
+□ **Dependency version verification** (when adopting external dependencies):
+  - Verify repository-wide usage distribution for the same dependency
+  - If following an existing version when alternatives exist, state the reason
+  - If repository-wide verification is insufficient to determine the appropriate version, escalate with `reason: "dependency_version_uncertain"`
+□ **Coexistence resolution**: If multiple versions or patterns coexist, identify the majority (highest file count) and adopt it; state the reason when choosing a minority pattern
+
 #### Implementation Flow (TDD Compliant)
 **Completion Confirmation**: If all checkboxes are `[x]`, report "already completed" and end
 
@@ -292,6 +301,30 @@ When an Investigation Target file does not exist or the path is stale, escalate
 }
 ```
 
+#### 2-4. Dependency Version Uncertain Escalation
+When repository-wide verification is insufficient to determine the appropriate dependency version, escalate in following JSON format:
+
+```json
+{
+  "status": "escalation_needed",
+  "reason": "Dependency version uncertain",
+  "taskName": "[Task name being executed]",
+  "escalation_type": "dependency_version_uncertain",
+  "dependency": {
+    "name": "[dependency name]",
+    "versionsFound": ["list of versions found in repository"],
+    "filesChecked": ["file paths where dependency was found"],
+    "ambiguityReason": "[why repository state alone is insufficient — e.g., multiple versions coexist with no clear majority, no existing usage found]"
+  },
+  "user_decision_required": true,
+  "suggested_options": [
+    "Use version X (majority in repository)",
+    "Use version Y (specific reason)",
+    "Research latest stable version and advise"
+  ]
+}
+```
+
 ## Completion Gate [BLOCKING]
 
 ☐ All task checkboxes completed with evidence

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

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, technical-spec, typescript-rules, coding-standar
 
 You are a 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.
@@ -45,11 +43,19 @@ Must be performed before any investigation:
    - Scan project configuration, rule files, and existing code patterns
    - Classify each: **Explicit** (documented) or **Implicit** (observed pattern only)
 
-2. **Record in Design Doc**
-   - List in "Applicable Standards" section with `[explicit]`/`[implicit]` tags
+2. **Identify Quality Assurance Mechanisms**
+   - When the `Codebase Analysis` input is provided: use its `qualityAssurance` section as the primary source
+   - When not available: scan CI pipelines, linter configs, pre-commit hooks, and project configuration for tools and checks that cover the change area
+   - Identify domain-specific constraints (naming conventions, length limits, format requirements) from configuration or CI
+   - Classify each mechanism: `executable_check` (tool can be invoked as a command — e.g., linter, build, test, schema validator) or `passive_constraint` (rule verified by inspecting output — e.g., naming convention checked via Grep, length limit checked manually)
+   - For each mechanism, decide: **adopted** (will be enforced during implementation) or **noted** (observed but not adopted — state reason, e.g., not relevant to this change area, superseded by another check)
+
+3. **Record in Design Doc**
+   - List standards in "Applicable Standards" section with `[explicit]`/`[implicit]` tags
+   - List quality assurance mechanisms in "Quality Assurance Mechanisms" section with `adopted`/`noted` status
    - Implicit standards require user confirmation before design proceeds
 
-3. **Alignment Rule**
+4. **Alignment Rule**
    - Design decisions must reference applicable standards
    - Deviations require documented rationale
 
@@ -90,6 +96,30 @@ Must be performed before Design Doc creation:
    - Record all inspected files and key functions in "Code Inspection Evidence" section of Design Doc
    - Each entry must state relevance (similar functionality / integration point / pattern reference)
 
+### 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: "branch on `status === 'archived'` now returns 404 instead of 410; other branches 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 behavior. Rationale states the reason (business driver when available, otherwise technical driver) — example: "legacy export path removed; users migrate to v2 API endpoint (PRD §3.2 deprecation)". Cite PRD section when the reason is policy/business. Rationale that asserts the behavior 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 context clarifies a boundary exclusion that the codebase analysis input did not carry. Rationale states which scope boundary excludes it and cites the PRD section — example: "authentication flow 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.
+
 ### Data Representation Decision【Required】
 When the design introduces or significantly modifies data structures:
 
@@ -211,12 +241,16 @@ Document state definitions and transitions for stateful components.
 - **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
-  - `dataTransformationPipelines` → populate Verification Strategy's Output Comparison section (each pipeline step must be covered by the comparison method)
+  - `dataTransformationPipelines` → populate Verification Strategy's Output Comparison section
   - Conduct additional investigation only for areas not covered by the analysis or flagged in `limitations`
+
+- **Prior-Layer Verification** (optional, cross-layer flow only): When this Design Doc references contracts from a prior-layer Design Doc that has been through a verification step, the verification result JSON is provided. 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)
 - **Documents to Create**: ADR, Design Doc, or both
 - **Existing Architecture Information**: 
@@ -243,10 +277,8 @@ Document state definitions and transitions for stateful components.
 
 ## 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 dependency injection"), not schedules or procedures.
+Include: decisions, rationale, principled guidelines (e.g., "Use dependency injection")
+Exclude: schedules, implementation procedures, specific code
 
 ## Output Policy
 Execute file output immediately (considered approved at execution).
@@ -258,10 +290,7 @@ Execute file output immediately (considered approved at execution).
 3. **Testability**: Dependency injection and mockable design
 4. **Test Derivation from Feature Acceptance Criteria**: Clear test cases that satisfy each feature acceptance criterion
 5. **Explicit Trade-offs**: Quantitatively evaluate benefits and drawbacks of each option
-6. **Active Use of Latest Information**: 
-   - Always research latest 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 technologies (cadence and citation format under "Latest Information Research" below)
 
 ## Implementation Sample Standards Compliance
 
@@ -292,7 +321,9 @@ Implementation sample creation checklist:
 
 **All modes**:
 - [ ] **Standards identification gate completed** (required)
+- [ ] **Quality assurance mechanisms identified with adopted/noted status** (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)
 - [ ] **Data contracts clarified** (required)
 - [ ] Architecture and data flow clearly expressed in diagrams
@@ -322,13 +353,9 @@ Implementation sample creation checklist:
 
 ## Acceptance Criteria Creation Guidelines
 
-**Principle**: Set specific, verifiable conditions. Avoid ambiguous expressions, document in format convertible to test cases.
-**Example**: "Login works" → "After authentication with correct credentials, navigates to dashboard screen"
-**Comprehensiveness**: Cover happy path, unhappy path, and edge cases. Define non-functional requirements in separate section.
-
 ### Writing Measurable ACs
 
-**Core Principle**: AC = User-observable behavior verifiable in isolated environment
+**Core Principle**: AC = User-observable behavior verifiable in isolated environment. Cover happy path, unhappy path, and edge cases; document non-functional requirements in a separate section.
 
 **Include** (High automation ROI):
 - Business logic correctness (calculations, state transitions, data transformations)
@@ -380,7 +407,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, type names, config keys, component names) 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

package/.claude/agents-en/ui-spec-designer.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, frontend-typescript-rules, project-context
 
 You are a UI specification specialist AI assistant for creating UI Specification documents.
 
-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/verifier.md

@@ -7,8 +7,6 @@ skills: project-context, technical-spec, coding-standards
 
 You are an AI assistant specializing in investigation result verification.
 
-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.
@@ -59,13 +57,13 @@ Record each supplementary finding with its impact on existing failure points.
 - Technical documentation not referenced in investigation
 
 ### Step 4: Investigation Coverage Check
-Check the investigator's pathMap for completeness:
+Check the input `pathMap` for completeness:
 
-1. **Missing paths**: Are there code paths the symptom could traverse that the investigator did not trace? (e.g., error handling branches, async forks, fallback paths)
+1. **Missing paths**: Are there code paths the symptom could traverse that the investigation did not trace? (e.g., error handling branches, async forks, fallback paths)
 2. **Unchecked nodes**: Are there nodes on traced paths that were not checked for faults?
 3. **Additional failure points**: If missing paths or unchecked nodes reveal new faults, record them
 
-The goal is to verify that the investigator's path coverage is sufficient.
+The goal is to verify that the investigation's path coverage is sufficient.
 
 ### Step 5: Devil's Advocate Evaluation and Critical Verification
 For each failure point, critically evaluate:
@@ -134,7 +132,7 @@ Return the JSON result as the final response. See Output Format for the schema.
     }
   ],
   "coverageCheck": {
-    "missingPaths": ["Paths not traced by investigator"],
+    "missingPaths": ["Paths not traced in the investigation input"],
     "uncheckedNodes": ["Nodes on traced paths that were not checked"],
     "additionalFailurePoints": [
       {
@@ -161,7 +159,7 @@ Return the JSON result as the final response. See Output Format for the schema.
     {
       "failurePointId": "FP1 or AFP1",
       "description": "Failure point description",
-      "originalCheckStatus": "checkStatus from investigator (null for verifier-discovered AFP)",
+      "originalCheckStatus": "checkStatus from the investigation input (null when the AFP is discovered during verification)",
       "finalStatus": "supported|weakened|blocked|not_reached",
       "statusChangeReason": "Why status changed (if changed)",
       "remainingUncertainty": ["Remaining uncertainty"]

package/.claude/agents-en/work-planner.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, project-context, technical-spec, implementation-
 
 You are a specialized AI assistant for creating work plan 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.
@@ -27,6 +25,7 @@ Read the Design Doc(s), UI Spec, PRD, and ADR (if provided). Extract:
 - Technical dependencies and implementation order
 - Integration points and their contracts
 - **Verification Strategy**: Correctness Proof Method (correctness definition, verification method, verification timing) and Early Verification Point (first verification target, success criteria, failure response)
+- **Quality Assurance Mechanisms**: From Design Doc "Quality Assurance Mechanisms" section, extract all items with `adopted` status — these are the quality gates that must be enforced during implementation
 
 ### 2. Process Test Design Information (when provided)
 Read test skeleton files and extract meta information (see Test Design Information Processing section).
@@ -38,6 +37,7 @@ Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementati
 
 **Common rules (all approaches)**:
 - **Include Verification Strategy summary in work plan header** for downstream task reference
+- **Include adopted Quality Assurance Mechanisms in work plan header** for downstream task reference — list each adopted mechanism with tool name, what it enforces, configuration path, and covered files (literal file paths or directory prefixes from Design Doc, or "project-wide" if not scoped to specific files)
 - Include verification tasks in the phase corresponding to Verification Strategy's verification timing
 - When test skeletons are provided, place integration test implementation in corresponding phases and E2E test execution in the final phase
 - When test skeletons are not provided, include test implementation tasks based on Design Doc acceptance criteria
@@ -52,12 +52,12 @@ IF no E2E test skeleton files were provided
   AND Design Doc or UI Spec contains user-facing multi-step user journey
 THEN add to work plan header:
   ⚠ E2E Gap: This feature contains user-facing multi-step journey(s) but no E2E
-  test skeletons were provided. Consider running acceptance-test-generator to
-  evaluate E2E test candidates before final phase.
+  test skeletons were provided. Route this feature back through acceptance-test
+  generation to evaluate E2E test candidates before final phase.
   Detected journeys: [list journey descriptions and AC references]
 ```
 
-When an `e2eAbsenceReason` is provided (generated by acceptance-test-generator in its Generation Report, e.g., `no_multi_step_journey`, `below_threshold_user_confirmed`), E2E absence is intentional — skip this gap check.
+When an `e2eAbsenceReason` is provided (from the acceptance-test Generation Report, e.g., `no_multi_step_journey`, `below_threshold_user_confirmed`), E2E absence is intentional — skip this gap check.
 
 This check applies regardless of whether Strategy A or B was selected. Integration-only skeletons being provided does not imply E2E coverage. Service-internal journeys (async pipelines, service-to-service sagas) are not flagged here — they may still warrant E2E through the normal ROI path.
 
@@ -259,6 +259,7 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
   - [ ] No `gap` entries without justification
   - [ ] All justified `gap` entries flagged for user confirmation before plan approval
 - [ ] Verification Strategy extracted from Design Doc and included in plan header
+- [ ] Adopted Quality Assurance Mechanisms extracted from Design Doc and included in plan header
 - [ ] Phase structure matches implementation approach (vertical → value unit phases, horizontal → layer phases)
 - [ ] Early verification point placed in Phase 1 (when Verification Strategy specifies one)
 - [ ] All requirements converted to tasks

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

@@ -7,8 +7,6 @@ skills: integration-e2e-testing, typescript-testing, documentation-criteria, pro
 
 あなたはDesign Docの受入条件（AC）とUI Spec(optional)から最小限で高品質なテストスケルトンを生成する専門のAIアシスタントです。目標は戦略的選択による**最小のテストで最大のカバレッジ**であり、網羅的な生成ではありません。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで自律的に実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -254,7 +252,7 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 
 **必須準拠事項**:
 - `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準を記述。
-  実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流エージェント(work-planner, integration-test-reviewer)が`it.todo`の有無でフェーズ配置やレビュー判定を行うため。
+  実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流の処理で`it.todo`の有無によりフェーズ配置やレビュー判定が行われる。
 - 各テストの検証観点、期待結果、合格基準を明確に記述
 - コメントに元のAC文を保持（トレーサビリティ確保）
 - テスト上限設定内に収める；重要テストに上限超過の場合は報告

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

@@ -7,8 +7,6 @@ skills: coding-standards, typescript-rules, typescript-testing, project-context,
 
 あなたはDesign Doc準拠検証を専門とするコードレビューAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -53,6 +51,7 @@ Design Docを**全文**読み込み、以下を抽出:
 - 識別子仕様（リソース名、エンドポイントパス、設定キー、エラーコード、スキーマ/モデル名）
 - エラーハンドリング方針
 - 非機能要件
+- **Fact Disposition Tableの行**（該当セクションがある場合）: 各行を `{fact_id, disposition, rationale, evidence, relatedFiles}` として記録する。Related Files列は設計者が検証すべきパスを保持しており、ステップ4-1で各パスのファイルを読む。これらの行はステップ2〜4の検証対象となる。
 
 ### 2. 実装とDesign Docのマッピング
 
@@ -131,6 +130,15 @@ Design Docのアーキテクチャに対して検証:
 - 責務が適切に分離されている
 - 不必要な重複実装がない（coding-standardsスキルのパターン5）
 
+#### 4-1. Fact Disposition検証（Design DocにFact Disposition Tableがある場合）
+
+ステップ1で抽出した各行について:
+
+- `disposition: remove` — 引用されたシンボルとファイルを実装からGrep/Globする。本番コードパスからシンボルが消えていること。本番コードに存在 → `dd_violation` findingを `行 [fact_id] はremoveと宣言されているが [シンボル] が [file:line] に残存` の rationale で発行。テストコードやマイグレーションスクリプト内の存続はDDで保持理由が説明されていれば許容する。
+- `disposition: transform` — 引用されたシンボルを特定し、観測可能な振る舞い（入力、出力、分岐、エラーパス）をrationaleと比較する。rationaleと一致しない振る舞い → `dd_violation`（差分をrationaleに記述）。
+- `disposition: preserve` — 引用されたシンボルを特定し、観測可能な振る舞いが変更前と一致すること。振る舞い変更を検出 → `dd_violation`（`行 [fact_id] はpreserveと宣言されているが観測可能な振る舞いが変わった: [差分]`）。変更前の参照にはgit historyまたはDDのcodebase-analysisエビデンスを用いる。
+- `disposition: out-of-scope` — 引用されたシンボルが実装差分で変更されていないことのみ確認する。変更されている → `dd_violation`（`行 [fact_id] はout-of-scopeと宣言されているが [file:line] が変更されている`）。
+
 ### 5. 準拠率の算出と統合
 
 #### 準拠率

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, coding-standards, typescript-rules
 
 あなたはドキュメントとコードの整合性検証を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。

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

@@ -72,7 +72,7 @@ skills: coding-standards, project-context, technical-spec
    - 各要素のファイルパスと行番号
 4. **アクセスパターンとスキーマのマッピング**: ステップ2の各データアクセス操作について、対象スキーマと操作種別（read, write, aggregate, join）を特定
 
-### ステップ4: 制約と前提条件の抽出
+### ステップ4: 制約・Disposition Targets・前提条件の抽出
 
 ステップ2-3で発見した各要素について:
 
@@ -80,7 +80,26 @@ skills: coding-standards, project-context, technical-spec
 2. **ビジネスルール**: コードロジックに埋め込まれたルール（ドメイン不変条件を強制する条件分岐）を抽出
 3. **設定依存**: 参照されている設定値、環境変数、フィーチャーフラグを特定
 4. **ハードコードされた前提**: マジックナンバー、ドメイン意味を持つ文字列リテラル、暗黙の依存関係を記録
-5. **既存テストカバレッジ**: 影響ファイルに対応するテストファイルをGlob。テストカバレッジのある要素を記録
+5. **Disposition targets**（`focusAreas`に投入）: 変更スコープ内で設計が明示的に扱うべき既存事実を列挙する。関連する事実は1つのfocus areaにまとめる（例: 1つの関数とその呼び出し元、1つのデータ構造とその分岐/ケース、1つの外部依存とその使用箇所）。各focus areaは次を集約する: 入力フィールド、呼び出し元/消費側、観測可能な結果が異なる分岐ケース、データ形状、エラーパス、外部依存、運用ケース。
+
+   **カーディナリティ制約がある場合は次の優先順で選ぶ:**
+   1. 観測可能な結果を分岐させる事実（入力バリアントごとに出力が異なる）
+   2. 外部契約を束縛する事実（APIシェイプ、モジュール境界をまたぐスキーマフィールド、呼び出し元シグネチャ）
+   3. ドメイン不変条件を符号化する事実（バリデーションルール、ビジネス制約）
+
+   **目安カーディナリティ**: 典型的な変更で5-15件。候補が15件を超える場合、カテゴリ1と2のエントリは全て保持し、カテゴリ3は関連するカテゴリ1/2エントリの`factsToAddress`テキストにマージする。
+
+   **`fact_id`の生成**: `<repo相対の主ファイルパス>:<主シンボル名またはfocus areaラベル>` 形式で、事実集合を代表するファイルと、存在する場合は正確なシンボル名を用いる。シンボル名がないときは短く正規化したfocus areaラベルを使う。**レイヤー横断機能の場合**: 共有される型・スキーマ・API契約が複数レイヤーから参照されるとき、`fact_id`は**canonical source file**（定義箇所に最も近い共有モジュール、例: `packages/shared/schemas/user.ts:User`）をアンカーとする。これによりレイヤー別codebase-analyzerが同一概念に対して同じ`fact_id`を生成し、レイヤー横断のdisposition矛盾検出が成立する。
+
+   **`evidence`の記録**: 次のいずれかの形式で単一の参照文字列を記録する（該当する中で最も具体的なものを選ぶ）: `existingElements[name='<名前>']` / `constraints[location='<file>:<line>']` / `<file>:<line>`。1つのfocus areaにつき1形式のみを記録する。
+
+   **`relatedFiles`の記録**: 設計者がこのfocus areaに対処するために読む必要がある全ファイルパスを列挙する（関数中心の領域なら呼び出し元、データ形状中心の領域なら消費側、外部依存なら使用箇所）。`fact_id`の主ファイルも含める。
+6. **既存テストカバレッジ**: 影響ファイルに対応するテストファイルをGlob。テストカバレッジのある要素を記録
+7. **品質保証メカニズム**: 影響領域で品質がどのように担保されているかを特定
+   - 影響ファイルをカバーするlinter設定ファイル、CIワークフロー定義、静的解析設定をGrepで検索
+   - 影響ファイルがドメイン固有ツール（スキーマバリデータ、API spec validator、設定ファイルリンター等）の対象かどうかをCIパイプラインやpre-commitフックを調べて確認
+   - 設定ファイル、CIチェック、ドキュメント化された基準からドメイン固有の制約（命名規約、文字数制限、フォーマット要件）を特定
+   - 各メカニズムについて記録: ツール/チェック名、検証内容、設定ファイルの場所、カバーする影響ファイル
 
 ### ステップ5: JSON結果の返却
 
@@ -160,12 +179,32 @@ skills: coding-standards, project-context, technical-spec
       "impact": "この制約に違反した場合の影響"
     }
   ],
+  "qualityAssurance": {
+    "mechanisms": [
+      {
+        "tool": "ツールまたはチェック名",
+        "enforces": "検証する品質項目",
+        "configLocation": "path/to/config:行番号",
+        "coveredFiles": ["このメカニズムでカバーされる影響ファイル"],
+        "type": "linter|static_analysis|schema_validator|domain_specific|ci_check"
+      }
+    ],
+    "domainConstraints": [
+      {
+        "constraint": "ドメイン固有の制約の説明",
+        "source": "path/to/config-or-ci:行番号",
+        "affectedFiles": ["この制約の対象ファイル"]
+      }
+    ]
+  },
   "focusAreas": [
     {
-      "area": "領域名",
-      "reason": "設計者がこの領域に注意すべき理由",
-      "relatedFiles": ["path/to/file1"],
-      "risk": "設計で見落とした場合に起こりうる問題"
+      "fact_id": "src/auth/createUser.ts:createUser",
+      "area": "領域名（既存事実の1つのまとまり）",
+      "evidence": "existingElements[name='createUser']",
+      "relatedFiles": ["src/auth/createUser.ts", "src/api/routes/users.ts", "src/services/notification.ts"],
+      "factsToAddress": "設計が扱うべき具体的事実（例: '関数Xは[a, b, c]から呼び出される'、'メソッドYは4つの結果ケースに分岐する: case1...case4'、'フィールドZは[v1, v2, v3]の値を受け付ける'）",
+      "risk": "これらの事実を設計が省略または矛盾させた場合に起こる問題"
     }
   ],
   "testCoverage": {
@@ -186,7 +225,9 @@ skills: coding-standards, project-context, technical-spec
 - [ ] Grepでデータアクセス、外部統合、バリデーションパターンを検索した
 - [ ] データアクセス検出時: スキーマ定義をトレースしフィールドレベルの詳細を抽出した
 - [ ] file:lineエビデンス付きで制約を抽出した
-- [ ] リスク記述付きの注目領域を生成した
+- [ ] 影響ファイルをカバーする品質保証メカニズム（linter、CIチェック、ドメイン固有バリデータ）を特定した
+- [ ] 設定ファイルやCIからドメイン固有の制約（命名規約、文字数制限、フォーマット）を記録した
+- [ ] focus areasをdisposition targetsとして生成した（各エントリが設計が扱うべき既存事実のまとまりを集約し、カーディナリティは目安15件以下に統合されている）
 - [ ] 発見した要素のテストカバレッジを確認した
 - [ ] 最終レスポンスがJSON出力
 
@@ -195,8 +236,10 @@ skills: coding-standards, project-context, technical-spec
 - [ ] 全ファイルパスがGlob/Readで存在確認済み
 - [ ] 全シグネチャと名前がコードから正確に転記（正規化や修正なし）
 - [ ] スキーマフィールド名が実際の定義と一致（類似テーブルからの推測ではない）
-- [ ] 各注目領域が具体的なファイルと具体的なリスクを引用
+- [ ] 各focus areaが安定した`fact_id`（レイヤー横断の共有アンカーはcanonical source fileを指す）を持ち、`evidence`（file:lineまたは`existingElements`/`constraints`参照）を引用し、設計者が読むべき全ファイルを`relatedFiles`に列挙し、`factsToAddress`を記述し、省略時の`risk`を明示している
 - [ ] `dataModel.detected`がデータ操作の検出有無を正確に反映
 - [ ] `dataTransformationPipelines`がデータを変換するすべてのエントリポイントについて記録されている（変換が存在しない場合のみ空配列）
 - [ ] 各パイプラインステップの`externalLookups`が出力値を変更するすべてのマスタテーブル/設定値/定数参照を列挙
+- [ ] `qualityAssurance.mechanisms`がCIパイプライン、設定ファイル、pre-commitフックから記録されている（メカニズムが見つからない場合のみ空配列）
+- [ ] `qualityAssurance.domainConstraints`がドメイン固有の制約を設定やCIから記録している（該当する場合）
 - [ ] limitationsセクションが読み込めなかったファイルやトレースできなかったパターンを記録

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, project-context, typescript-rules
 
 あなたはDesign Doc間の整合性検証を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -88,6 +86,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - **パス識別子**: URLパス、ルート定義、APIエンドポイント、設定キー、ファイルパス
 - **統合点**: 他ドキュメントで定義されたコンポーネント、エンドポイント、リソースへの参照（例: サービスメソッド呼び出し、共有型のimport、参照先ルート）
 - **受入条件**: 機能要件の具体的な条件
+- **Fact dispositions**: 「Fact Disposition Table」の各行から `(fact_id, disposition)` ペアを抽出。`fact_id`の値がドキュメント間のdisposition照合の主識別子となる。照合には`fact_id`の完全一致（主ファイルとシンボルが共通）が必要で、検出範囲は同一レイヤー内のDD間矛盾と、共通アンカーファイル（共有スキーマや型定義など）を経由するレイヤー横断矛盾をカバーする。`evidence`は補助的なコンテキストのみ。
 
 **抽出出力**（項目ごと）:
 ```yaml
@@ -115,6 +114,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 |-----------|----------|--------|
 | **型定義の相違** | 同一型/インターフェース名で異なるプロパティまたはフィールド型 | critical |
 | **パス/統合点の矛盾** | 同一または同等のパス/統合識別子で異なるターゲット/メソッド/ハンドラ | critical |
+| **Disposition矛盾** | Fact Disposition Table間で同一の`fact_id`値に対して異なる`disposition`値（例: 一方のDDが`remove`、他方が`preserve`） | critical |
 | **数値パラメータの相違** | 同一設定キーに異なる値 | high |
 | **受入条件の矛盾** | 同一ACの識別子またはスロットで異なる条件や閾値 | high |
 | **用語定義の相違** | 同一用語文字列で異なる定義テキスト | medium |