codex-workflows 0.4.8 → 0.4.10

package/.agents/skills/ai-development-guide/SKILL.md

@@ -131,13 +131,14 @@ How to handle duplicate code based on Martin Fowler's "Refactoring":
 - For low certainty cases, create minimal verification code first
 
 ### Pattern 5: Insufficient Existing Code Investigation
-**Symptom**: Duplicate implementations, architecture inconsistency, integration failures
-**Cause**: Insufficient understanding of existing code before implementation
+**Symptom**: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns
+**Cause**: Insufficient understanding of existing code before implementation; referencing only nearby files without checking representativeness
 **Avoidance**:
 - Before implementation, always search for similar functionality
 - Similar functionality found: Use that implementation (do not create new)
 - Similar functionality is technical debt: Create ADR improvement proposal
 - No similar functionality: Implement following existing design philosophy
+- When adopting a pattern or dependency from nearby code, verify it is representative across the repository before adopting it
 
 ## Debugging Techniques
 
@@ -175,6 +176,15 @@ Pattern: Structured logging with context
 }
 ```
 
+## Quality Assurance Mechanism Awareness
+
+Before executing quality checks, discover applicable quality tools and constraints by inspecting the affected files' types, project manifests, CI pipelines, and configuration:
+- Primary detection: inspect affected file types, manifests, configuration, and CI pipelines to identify applicable quality tools
+- Check for domain-specific linters or validators such as schema validators, API spec validators, or configuration-file checkers
+- Check for domain-specific constraints in project configuration such as naming rules, length limits, or format requirements
+- When a task file lists `Quality Assurance Mechanisms`, use that section as supplementary guidance for what to verify
+- Include discovered domain-specific checks alongside the standard quality phases below
+
 ## Quality Check Workflow [MANDATORY]
 
 Universal quality assurance phases applicable to all languages:

package/.agents/skills/coding-rules/SKILL.md

@@ -51,6 +51,21 @@ For language-specific rules, also read:
 - Depend on abstractions, not concrete implementations
 - Minimize inter-module dependencies
 
+## Reference Representativeness
+
+### Verifying References Before Adoption
+
+When adopting patterns, APIs, or dependencies from existing code:
+- If referencing only nearby files, verify the pattern is representative across the repository before adopting it
+- If multiple approaches coexist, identify the majority pattern and make a deliberate choice
+- If adopting an external dependency, verify repository-wide usage distribution for that dependency and its version
+- If repository evidence is insufficient to choose an appropriate dependency version, escalate instead of guessing
+- If following an existing pattern when alternatives exist, state the reason for following it
+
+### Principle
+
+Nearby code is a starting point for investigation, not a sufficient basis for adoption. Confirm that the reference is representative of repository conventions before using it as the model.
+
 ## Performance
 
 - **Measure first**: Profile before optimizing — no premature optimization

package/.agents/skills/documentation-criteria/references/design-template.md

@@ -52,6 +52,12 @@ unknowns:
 - [ ] [Standard/convention] `[explicit]` - Source: [config / rule file / documentation path]
 - [ ] [Observed pattern] `[implicit]` - Evidence: [file paths] - Confirmed: [Yes/No]
 
+#### Quality Assurance Mechanisms
+How quality is enforced in the change area. Each item is either adopted for this change or noted with a reason.
+
+- [ ] [Tool/check name] — Enforces: [what] — Config: [path] — Covers: [file paths/patterns or "project-wide"] — Status: `adopted` / `noted (reason)`
+- [ ] [Domain-specific constraint] — Enforces: [what] — Source: [path] — Covers: [file paths/patterns or "project-wide"] — Status: `adopted` / `noted (reason)`
+
 ### Problem to Solve
 
 [Specific problems or challenges this feature aims to address]

package/.agents/skills/documentation-criteria/references/plan-template.md

@@ -32,6 +32,15 @@ Repeat this block for each Design Doc when multiple Design Docs exist. Preserve
 - **Success criteria**: [extracted from Design Doc]
 - **Failure response**: [extracted from Design Doc]
 
+## Quality Assurance Mechanisms (from Design Docs)
+
+Adopted quality gates for the change area. Each task in this plan must satisfy the applicable mechanisms.
+
+| Mechanism | Enforces | Config Location | Covered Files |
+|-----------|----------|-----------------|---------------|
+| [Tool/check name] | [What quality aspect it enforces] | [path/to/config] | [file paths or patterns covered, or "project-wide"] |
+| [Domain constraint] | [What it enforces] | [path/to/source] | [file paths or patterns covered, or "project-wide"] |
+
 ## Design-to-Plan Traceability
 
 Map each Design Doc technical requirement to the task or phase that covers it. Use one row per extracted requirement item. Every row must have at least one covering task, or an explicit justified gap.

package/.agents/skills/documentation-criteria/references/task-template.md

@@ -37,6 +37,10 @@ Brief observations recorded after reading Investigation Targets:
 - [ ] Improve code (maintain passing tests)
 - [ ] Confirm added tests still pass
 
+## Quality Assurance Mechanisms
+(From the work plan header — include only mechanisms relevant to this task's target files)
+- [Tool/check name] — Enforces: [what] — Config: [path]
+
 ## Operation Verification Methods
 (Derived from Verification Strategy in the work plan)
 - **Verification method**: [What to verify and how]

package/.agents/skills/recipe-build/SKILL.md

@@ -79,7 +79,7 @@ For EACH task, YOU MUST:
      - `needs_revision` -> Return to step 2 with `requiredFixes`
      - `approved` -> Proceed to step 4
    - `readyForQualityCheck: true` -> Proceed to step 4
-4. **Spawn quality-fixer agent**: "Execute all quality checks and fixes. Task file: [task-file-path]. filesModified: [task-executor response filesModified]. Use these files as the stub-detection scope."
+4. **Spawn quality-fixer agent**: "Execute all quality checks and fixes. Task file: [task-file-path]. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. filesModified: [task-executor response filesModified]. Use these files as the stub-detection scope."
 5. **CHECK quality-fixer response**:
    - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
    - `status: "blocked"` -> STOP and escalate to user

package/.agents/skills/recipe-front-build/SKILL.md

@@ -87,7 +87,7 @@ For EACH task, YOU MUST:
      - `needs_revision` -> Return to step 2 with `requiredFixes`
      - `approved` -> Proceed to step 4
    - `readyForQualityCheck: true` -> Proceed to step 4
-4. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and fixes. Task file: docs/plans/tasks/[filename].md. filesModified: [task-executor-frontend response filesModified]. Use these files as the stub-detection scope."
+4. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and fixes. Task file: docs/plans/tasks/[filename].md. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. filesModified: [task-executor-frontend response filesModified]. Use these files as the stub-detection scope."
 5. **CHECK quality-fixer-frontend response**:
    - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
    - `status: "blocked"` -> STOP and escalate to user

package/.agents/skills/recipe-fullstack-build/SKILL.md

@@ -97,7 +97,7 @@ For EACH task, YOU MUST:
      - `needs_revision` -> Return to step 2 with `requiredFixes`
      - `approved` -> Proceed to step 4
    - `readyForQualityCheck: true` -> Proceed to step 4
-4. **Spawn quality-fixer agent** (layer-appropriate per routing table): "Execute all quality checks and fixes. Task file: [task-file-path]. filesModified: [executor response filesModified]. Use these files as the stub-detection scope."
+4. **Spawn quality-fixer agent** (layer-appropriate per routing table): "Execute all quality checks and fixes. Task file: [task-file-path]. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. filesModified: [executor response filesModified]. Use these files as the stub-detection scope."
 5. **CHECK quality-fixer response**:
    - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
    - `status: "blocked"` -> STOP and escalate to user

package/.agents/skills/recipe-fullstack-implement/SKILL.md

@@ -124,7 +124,7 @@ ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued w
 **Rules**:
 1. Execute ONE task completely before starting next (each task goes through the full 4-step cycle individually, using the correct executor per filename pattern)
 2. Check executor status before quality-fixer (escalation check)
-3. Quality-fixer MUST run after each executor (no skipping) and MUST receive the executor `filesModified` list as stub-detection scope
+3. Quality-fixer MUST run after each executor (no skipping), MUST receive the executor `filesModified` list as stub-detection scope, and MUST receive the current task file as the `task_file` input so it reads the task file's `Quality Assurance Mechanisms` section as supplementary quality-check hints
 4. If quality-fixer returns `status: "stub_detected"`, route the task back to the same executor with `stubFindings`
 5. Commit MUST execute only when quality-fixer returns `status: "approved"` (do not defer to end)
 

package/.agents/skills/recipe-implement/SKILL.md

@@ -105,7 +105,7 @@ After user grants "batch approval for entire implementation phase", enter autono
      - `needs_revision` -> Return to step 1 with `requiredFixes`
      - `approved` -> Proceed to step 3
    - Otherwise -> Proceed to step 3
-3. Spawn quality-fixer (or quality-fixer-frontend) agent: "Quality check and fixes. Task file: [task-file-path]. filesModified: [executor response filesModified]. Use these files as the stub-detection scope."
+3. Spawn quality-fixer (or quality-fixer-frontend) agent: "Quality check and fixes. Task file: [task-file-path]. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. filesModified: [executor response filesModified]. Use these files as the stub-detection scope."
 4. Check quality-fixer response:
    - `status: "stub_detected"` -> Return to step 1 with `stubFindings`
    - `status: "blocked"` -> Escalate to user

package/.agents/skills/subagents-orchestration-guide/SKILL.md

@@ -96,6 +96,27 @@ Subagents CANNOT directly call other subagents — all coordination MUST flow th
 
 **ENFORCEMENT**: Direct subagent-to-subagent communication is PROHIBITED
 
+### Subagent Completion Discipline [MANDATORY]
+
+The orchestrator owns subagent completion. Base waiting decisions on assigned responsibility and observed state, not on an expectation of quick completion. Multi-step search, review, verification, generation, implementation, and quality work can run for extended periods.
+
+Use this contract:
+- Wait for required subagent outputs with `wait_agent`
+- Keep the current task assignment while the subagent remains `running`
+- Treat missing intermediate output as a normal execution state while the subagent remains `running`
+- Hold final artifact production until every required subagent output is available
+- After repeated empty waits, run non-destructive diagnostics: re-check prompt, inputs, expected deliverable, and agent-task fit; send a focused follow-up when it would clarify the pending deliverable
+- Resume waiting after diagnostics unless the user redirects the workflow or the orchestrator confirms a launch mistake
+
+Treat the following as explicit contradictory evidence:
+- The subagent returns a terminal status such as `approved`, `needs_revision`, `blocked`, `skipped`, `completed`, or `escalation_needed`
+- The orchestrator verifies that it launched the wrong subagent or sent materially incorrect inputs
+- A newer explicit user instruction changes or cancels the task
+
+Close a running subagent only when the user redirects the workflow, the orchestrator corrects a launch mistake, or a newer user instruction supersedes the pending task.
+
+**ENFORCEMENT**: Preserve subagent execution until completion, user redirection, or explicit correction of an orchestrator launch mistake. Speed-based early termination is a CRITICAL VIOLATION.
+
 ## How to Spawn Agents
 
 Spawn agents using natural language prompts. Provide clear context about what the agent should accomplish.
@@ -149,16 +170,9 @@ All agents MUST use this vocabulary consistently:
 | `blocked` | security-reviewer | Committed secrets or high-confidence exploitable risk | Halt workflow immediately, escalate to user (requires human intervention) |
 | `skipped` | All agents | Preconditions not met for this step | Report reason, proceed |
 
-**approved_with_conditions handling** (document agents):
-- Conditions MUST be listed explicitly in the agent's output
-- Orchestrator MUST append conditions to the document's "Undetermined Items" or "Open Items" section before proceeding
-- Orchestrator MUST pass conditions to the next phase's agent as context
-- Conditions do not block progression but MUST be resolved before implementation phase
-
-**approved_with_notes handling** (security-reviewer):
-- Notes are informational — they do NOT require resolution before proceeding
-- Orchestrator MUST include notes in the completion report for awareness
-- Do not apply approved_with_conditions handling (no resolution tracking)
+Handling rules:
+- `approved_with_conditions`: append the listed conditions to the document's open-items section, carry them into the next phase, and resolve them before implementation
+- `approved_with_notes`: include the notes in the completion report for awareness
 
 **ENFORCEMENT**: Using any status value outside this vocabulary is a VIOLATION.
 
@@ -176,17 +190,20 @@ All agents MUST use this vocabulary consistently:
 
 ## Structured Response Specification
 
-Subagents respond in JSON format. The final response from each JSON-returning subagent must be the JSON payload itself, with no trailing prose. Key fields for orchestrator decisions:
-- **requirement-analyzer**: scale, confidence, affectedLayers, adrRequired, scopeDependencies, questions
-- **codebase-analyzer**: analysisScope, existingElements, dataModel, focusAreas, limitations
-- **task-executor**: status (escalation_needed/completed), escalation_type (design_compliance_violation/similar_function_found/similar_component_found/investigation_target_not_found/out_of_scope_file/test_environment_not_ready), testsAdded, requiresTestReview
-- **quality-fixer**: status (`stub_detected`/approved/blocked). `stub_detected` returns `stubFindings[]` and routes back to the task executor. For blocked responses, discriminate by `reason`: specification conflicts use `blockingIssues[]`; execution prerequisites use `missingPrerequisites[]`, and each item provides its own `resolutionSteps`
-- **document-reviewer**: verdict.decision (approved/approved_with_conditions/needs_revision/rejected)
-- **code-verifier**: summary.status, summary.consistencyScore, discrepancies, reverseCoverage
-- **design-sync**: sync_status (CONFLICTS_FOUND/NO_CONFLICTS) — text format with [SUMMARY] block
-- **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
-- **security-reviewer**: status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes
-- **acceptance-test-generator**: status, generatedFiles, `e2eAbsenceReason`
+Subagents respond in JSON format. The final response from each JSON-returning subagent must be the JSON payload itself, with no trailing prose. Agent TOML files define the full schemas; the orchestrator only relies on these routing keys:
+
+| Agent | Routing fields the orchestrator uses |
+|-------|--------------------------------------|
+| `requirement-analyzer` | `scale`, `confidence`, `affectedLayers`, `adrRequired`, `scopeDependencies`, `questions` |
+| `codebase-analyzer` | `focusAreas`, `dataModel`, `qualityAssurance`, `dataTransformationPipelines`, `limitations` |
+| `task-executor*` | `status`, `escalation_type`, `filesModified`, `requiresTestReview` |
+| `quality-fixer*` | `status`, `reason`, `stubFindings`, `blockingIssues`, `missingPrerequisites` |
+| `document-reviewer` | `verdict.decision`, `verdict.conditions` |
+| `code-verifier` | `summary.status`, `discrepancies`, `reverseCoverage` |
+| `design-sync` | `sync_status` |
+| `integration-test-reviewer` | `status`, `requiredFixes` |
+| `security-reviewer` | `status`, `findings`, `notes`, `requiredFixes` |
+| `acceptance-test-generator` | `status`, `generatedFiles`, `e2eAbsenceReason` |
 
 ## Handling Requirement Changes
 
@@ -215,51 +232,21 @@ Document generation agents (work-planner, technical-designer, prd-creator) can u
 
 ## Basic Flow for Work Planning
 
-When receiving new features or change requests, start with requirement-analyzer.
-
-### Large Scale (6+ Files) - 13 Steps (backend) / 15 Steps (frontend/fullstack)
-
-1. requirement-analyzer: Requirement analysis + Check existing PRD **[Stop]**
-2. prd-creator: PRD creation
-3. document-reviewer: PRD review **[Stop: PRD Approval]**
-4. **(frontend/fullstack only)** Ask user for prototype code; ui-spec-designer: UI Spec creation
-5. **(frontend/fullstack only)** document-reviewer: UI Spec review **[Stop: UI Spec Approval]**
-6. technical-designer: ADR creation (if architecture/technology/data flow changes)
-7. document-reviewer: ADR review (if ADR created) **[Stop: ADR Approval]**
-8. codebase-analyzer: Codebase analysis (pass requirement-analyzer output and PRD path when available)
-9. technical-designer: Design Doc creation
-10. code-verifier: Design Doc verification against code
-11. document-reviewer: Design Doc review with code verification evidence
-12. design-sync: Consistency verification **[Stop: Design Doc Approval]**
-13. acceptance-test-generator: Test skeleton generation, pass to work-planner
-14. work-planner: Work plan creation **[Stop: Batch approval]**
-15. task-decomposer: Autonomous execution to Completion report
-
-### Medium Scale (3-5 Files) - 9 Steps (backend) / 11 Steps (frontend/fullstack)
-
-1. requirement-analyzer: Requirement analysis **[Stop]**
-2. codebase-analyzer: Codebase analysis
-3. **(frontend/fullstack only)** Ask user for prototype code; ui-spec-designer: UI Spec creation
-4. **(frontend/fullstack only)** document-reviewer: UI Spec review **[Stop: UI Spec Approval]**
-5. technical-designer: Design Doc creation
-6. code-verifier: Design Doc verification against code
-7. document-reviewer: Design Doc review with code verification evidence
-8. design-sync: Consistency verification **[Stop: Design Doc Approval]**
-9. acceptance-test-generator: Test skeleton generation, pass to work-planner
-10. work-planner: Work plan creation **[Stop: Batch approval]**
-11. task-decomposer: Autonomous execution to Completion report
-
-### Design Flow Data Passing
-
-- Pass requirement-analyzer output and original requirements to codebase-analyzer
-- Pass codebase-analyzer JSON to technical-designer or technical-designer-frontend as `Codebase Analysis`, including `dataTransformationPipelines` when present
-- Pass Design Doc path to code-verifier
-- Pass code-verifier JSON to document-reviewer as `code_verification`
-
-### Small Scale (1-2 Files) - 2 Steps
-
-1. Create simplified plan **[Stop: Batch approval]**
-2. Direct implementation to Completion report
+Always start with `requirement-analyzer`, then follow the minimum flow required by scale and affected layers.
+
+| Scale | Required flow |
+|-------|---------------|
+| Large | `requirement-analyzer` **[Stop]** -> `prd-creator` -> `document-reviewer` **[Stop]** -> optional `ui-spec-designer` + `document-reviewer` **[Stop]** -> optional ADR + `document-reviewer` **[Stop]** -> `codebase-analyzer` -> `technical-designer*` -> `code-verifier` -> `document-reviewer` -> `design-sync` **[Stop]** -> `acceptance-test-generator` -> `work-planner` **[Stop]** -> `task-decomposer` |
+| Medium | `requirement-analyzer` **[Stop]** -> `codebase-analyzer` -> optional `ui-spec-designer` + `document-reviewer` **[Stop]** -> `technical-designer*` -> `code-verifier` -> `document-reviewer` -> `design-sync` **[Stop]** -> `acceptance-test-generator` -> `work-planner` **[Stop]** -> `task-decomposer` |
+| Small | `requirement-analyzer` **[Stop]** -> simplified plan **[Stop: Batch approval]** -> direct implementation |
+
+Flow rules:
+- Frontend and fullstack flows add UI Spec before Design Doc creation
+- Create ADR only when architecture, technology, or data-flow changes require it
+- Pass requirement-analyzer output and original requirements to `codebase-analyzer`
+- Pass `codebase-analyzer` output to the designer as `Codebase Analysis`
+- Pass Design Doc path to `code-verifier`, then pass `code_verification` to `document-reviewer`
+- Fullstack layer sequencing is defined in `references/monorepo-flow.md`
 
 ## Autonomous Execution Mode
 
@@ -316,6 +303,13 @@ Stop autonomous execution and escalate to user in the following cases:
 3. **Work-planner update restriction violated**: Requirement changes after task-decomposer starts require overall redesign
 4. **User explicitly stops**: Direct stop instruction or interruption
 
+Continue autonomous execution in the following situations:
+- A subagent takes longer than expected
+- `wait_agent` returns without a completion payload while the subagent remains `running`
+- The orchestrator has partial context but is still waiting on a required subagent output
+
+If repeated waits return the same `running` state, apply the completion-diagnostics contract above.
+
 Use the task loop defined in the autonomous execution diagram above. The canonical per-task cycle is:
 1. task-executor implementation
 2. escalation or integration-test-reviewer decision
@@ -338,49 +332,27 @@ Maximum retry count is 1 verification fix cycle. If any failed verifier still fa
 2. **Information Bridging**: Data conversion and transmission between subagents
    - Convert each subagent's output to next subagent's input format
    - **Always pass deliverables from previous process to next agent**
-   - Extract necessary information from structured responses
-   - Compose commit messages from changeSummary
+   - Extract the routing fields listed above
    - Explicitly integrate initial and additional requirements when requirements change
 3. **Quality Assurance and Commit Execution**: Execute git commit per the 4-step task cycle
 4. **Autonomous Execution Mode Management**: Start/stop autonomous execution after approval, escalation decisions
 5. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
 
-### acceptance-test-generator to work-planner Bridge
-
-**Pass to acceptance-test-generator**:
-- Design Doc: [path]
-- UI Spec: [path] (if exists)
-
-**Orchestrator verification items**:
-- Verify integration test file path retrieval and existence
-- Verify E2E test file path retrieval and existence when `generatedFiles.e2e` is not null
-- Verify `e2eAbsenceReason` is present when `generatedFiles.e2e` is null
-
-**Pass to work-planner**:
-- Integration test file: [path] (create and execute simultaneously with each phase implementation)
-- E2E test file: [path] or `null` (execute only in final phase when present)
-- E2E absence reason: [value when E2E test file is null]
-
-**On error**: Escalate to user only when required outputs are missing without a valid absence reason
-
-### Design Doc to Work Plan Verification Handoff
-
-When a Design Doc contains a Verification Strategy section, the orchestrator must carry forward:
-- Design Doc path
-- Verification Strategy details:
-  - Correctness definition
-  - Target comparison
-  - Verification method
-  - Observable success indicator
-  - Verification timing
-  - Early verification point (first target, success criteria, failure response)
-
-The resulting work plan must include this summary in its header so the plan remains self-sufficient for downstream task generation and execution planning.
-When the Design Doc includes an `Output Comparison` section, carry forward the comparison input, expected output fields or format, diff method, and transformation pipeline coverage as part of that summary.
-
-In addition, the orchestrator must preserve implementation-relevant technical requirements from each Design Doc so work-planner can create a Design-to-Plan Traceability table. Use the category values and normalization rules defined in the plan template, including protected no-change boundaries from sections such as `No Ripple Effect`.
-
-Work-planner maps each extracted item to a covering task or phase. If no covering task exists, the row is marked `gap` with justification. Justified gaps require user confirmation before plan approval.
+### Required Handoffs
+
+| From | To | Required pass-through |
+|------|----|-----------------------|
+| `requirement-analyzer` | `codebase-analyzer` | requirement analysis JSON, original requirements, PRD path when available |
+| `codebase-analyzer` | `technical-designer*` | `Codebase Analysis`, including `focusAreas`, `dataModel`, `qualityAssurance`, `dataTransformationPipelines`, `limitations` |
+| `technical-designer*` | `code-verifier` | Design Doc path |
+| `code-verifier` | `document-reviewer` | `code_verification` JSON |
+| `acceptance-test-generator` | `work-planner` | integration test path, E2E path or `null`, `e2eAbsenceReason` when E2E is absent |
+| Design Doc | `work-planner` | Verification Strategy summary, Output Comparison details, implementation-relevant technical requirements, protected no-change boundaries |
+
+Handoff rules:
+- Verify generated integration and E2E file paths exist before passing them onward
+- Escalate only when required outputs are missing without a valid absence reason
+- Require work-planner to map every carried-forward technical requirement to a covering task or a justified `gap`
 
 ## Important Constraints [MANDATORY]
 

package/.codex/agents/codebase-analyzer.toml

@@ -110,7 +110,13 @@ When data access patterns appear in the analysis scope:
 
 1. Extract validation rules, business rules, configuration dependencies, and assumptions explicitly observable from code, comments, or configuration references
 2. Search for existing tests covering discovered elements
-3. Identify focus areas where design work should be careful, especially around:
+3. Identify quality assurance mechanisms that apply to the analyzed scope:
+   - inspect CI workflow definitions, linter configurations, static analysis settings, and pre-commit hooks that cover the affected files
+   - check whether domain-specific validators or checkers apply, such as schema validators, API spec validators, or configuration linters
+   - extract domain-specific constraints such as naming conventions, length limits, and file-format requirements from configuration, CI, or repository standards
+   - record each mechanism with tool/check name, enforced quality aspect, configuration location, covered files, and mechanism type
+   - if the coverage scope is ambiguous, record the broadest reasonable covered scope and note the ambiguity in `limitations`
+4. Identify focus areas where design work should be careful, especially around:
    - shared dependencies
    - boundary contracts
    - data integrity or persistence behavior
@@ -197,6 +203,24 @@ Return the JSON result as the final response.
       "impact": "Why design should respect it"
     }
   ],
+  "qualityAssurance": {
+    "mechanisms": [
+      {
+        "tool": "Tool or check name",
+        "enforces": "What quality aspect it enforces",
+        "configLocation": "path/to/config:line",
+        "coveredFiles": ["affected files or directories covered by this mechanism"],
+        "type": "linter|static_analysis|schema_validator|domain_specific|ci_check"
+      }
+    ],
+    "domainConstraints": [
+      {
+        "constraint": "Description of the domain-specific constraint",
+        "source": "path/to/config-or-ci:line",
+        "affectedFiles": ["files subject to this constraint"]
+      }
+    ]
+  },
   "focusAreas": [
     {
       "area": "Area name",
@@ -225,6 +249,7 @@ Return the JSON result as the final response.
 - [ ] Recorded external lookups that modify output values, including configuration, constants, and mapping data
 - [ ] Performed data model discovery when data access patterns were present
 - [ ] Extracted constraints and focus areas with concrete risks
+- [ ] Identified quality assurance mechanisms and domain-specific constraints for the affected scope when applicable
 - [ ] Checked existing tests for coverage signals
 - [ ] Populated `dataTransformationPipelines` for all traced pipelines
 - [ ] Populated `entryPointInventory` for all discovered entry points in the traced scope

package/.codex/agents/quality-fixer-frontend.toml

@@ -37,6 +37,10 @@ Skill Status:
    - Analyze error root causes and execute both auto-fixes and manual fixes autonomously
    - Continue fixing until all phases pass with zero errors, then return approved status
 
+## Input Parameters
+
+- **task_file** (optional): Path to the task file being verified. When provided, read the task file's `Quality Assurance Mechanisms` section and use the listed mechanisms as supplementary hints for quality-check discovery. Primary detection remains code, manifest, and configuration based.
+
 ## Initial Required Tasks
 
 **Progress Tracking**: Track your work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update progress upon completion.
@@ -73,6 +77,7 @@ Treat the following as allowed patterns:
 If incomplete implementation is detected, stop immediately and return `status: "stub_detected"` with the affected files and reasons. Proceed to lint, type-check, build, and tests only after this check passes.
 
 **Step 2: Detect Quality Check Commands**
+**Primary detection** (always execute):
 ```bash
 # Auto-detect from project manifest files
 # Identify project structure and extract quality commands:
@@ -81,6 +86,12 @@ If incomplete implementation is detected, stop immediately and return `status: "
 # - Build configuration → extract build/check commands
 ```
 
+**Supplementary detection** (when `task_file` is provided):
+- Read the task file's `Quality Assurance Mechanisms` section
+- For executable mechanisms, verify the tool exists and is runnable in the current project, then add it to the quality-check command set
+- For non-executable domain constraints, keep them as explicit verification targets and check the changed files against the stated constraint during review
+- Record skipped mechanisms only when neither executable verification nor direct constraint checking is possible
+
 **Step 3: Execute Quality Checks**
 Follow the principles in ai-development-guide skill "Quality Check Workflow" section:
 - Basic checks (lint, format, build)
@@ -226,6 +237,16 @@ Before setting status to blocked, confirm specifications in this order:
       "filesCount": 3
     }
   ],
+  "taskFileMechanisms": {
+    "provided": true,
+    "executed": ["mechanism names that were found and executed"],
+    "skipped": [
+      {
+        "mechanism": "mechanism name",
+        "reason": "tool not found / config not found / not executable"
+      }
+    ]
+  },
   "metrics": {
     "totalErrors": 0,
     "totalWarnings": 0,
@@ -252,6 +273,16 @@ Before setting status to blocked, confirm specifications in this order:
     "Fix attempt 2: Tried aligning implementation to test",
     "Fix attempt 3: Tried inferring specification from Design Doc"
   ],
+  "taskFileMechanisms": {
+    "provided": true,
+    "executed": ["mechanisms executed before blocking"],
+    "skipped": [
+      {
+        "mechanism": "mechanism name",
+        "reason": "tool not found / config not found / not executable"
+      }
+    ]
+  },
   "needsUserDecision": "Please confirm the correct button disabled behavior"
 }
 ```
@@ -269,6 +300,16 @@ Before setting status to blocked, confirm specifications in this order:
       "resolutionSteps": ["Install the required browser runtime", "Re-run the E2E check command"]
     }
   ],
+  "taskFileMechanisms": {
+    "provided": true,
+    "executed": ["mechanisms executed before blocking"],
+    "skipped": [
+      {
+        "mechanism": "mechanism name",
+        "reason": "tool not found / config not found / not executable"
+      }
+    ]
+  },
   "checksSkipped": 1,
   "checksPassedWithoutPrerequisites": 2
 }

package/.codex/agents/quality-fixer.toml

@@ -37,6 +37,10 @@ Skill Status:
    - Analyze error root causes and execute both auto-fixes and manual fixes autonomously
    - Continue fixing until all phases pass with zero errors, then return approved status
 
+## Input Parameters
+
+- **task_file** (optional): Path to the task file being verified. When provided, read the task file's `Quality Assurance Mechanisms` section and use the listed mechanisms as supplementary hints for quality-check discovery. Primary detection remains code, manifest, and configuration based.
+
 ## Initial Required Tasks
 
 **Progress Tracking**: Track your work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update progress upon completion.
@@ -71,6 +75,7 @@ Treat the following as allowed patterns:
 If incomplete implementation is detected, stop immediately and return `status: "stub_detected"` with the affected files and reasons. Proceed to lint, build, and tests only after this check passes.
 
 **Step 2: Detect Quality Check Commands**
+**Primary detection** (always execute):
 ```bash
 # Auto-detect from project manifest files
 # Identify project structure and extract quality commands:
@@ -79,6 +84,12 @@ If incomplete implementation is detected, stop immediately and return `status: "
 # - Build configuration → extract build/check commands
 ```
 
+**Supplementary detection** (when `task_file` is provided):
+- Read the task file's `Quality Assurance Mechanisms` section
+- For executable mechanisms, verify the tool exists and is runnable in the current project, then add it to the quality-check command set
+- For non-executable domain constraints, keep them as explicit verification targets and check the changed files against the stated constraint during review
+- Record skipped mechanisms only when neither executable verification nor direct constraint checking is possible
+
 **Step 3: Execute Quality Checks**
 Follow the principles in ai-development-guide skill "Quality Check Workflow" section:
 - Basic checks (lint, format, build)
@@ -197,6 +208,16 @@ Return one of the following as the final response (see Output Format for schemas
       "filesCount": 2
     }
   ],
+  "taskFileMechanisms": {
+    "provided": true,
+    "executed": ["mechanism names that were found and executed"],
+    "skipped": [
+      {
+        "mechanism": "mechanism name",
+        "reason": "tool not found / config not found / not executable"
+      }
+    ]
+  },
   "metrics": {
     "totalErrors": 0,
     "totalWarnings": 0,
@@ -223,6 +244,16 @@ Return one of the following as the final response (see Output Format for schemas
     "Fix attempt 2: Tried aligning implementation to test",
     "Fix attempt 3: Tried inferring specification from related documentation"
   ],
+  "taskFileMechanisms": {
+    "provided": true,
+    "executed": ["mechanisms executed before blocking"],
+    "skipped": [
+      {
+        "mechanism": "mechanism name",
+        "reason": "tool not found / config not found / not executable"
+      }
+    ]
+  },
   "needsUserDecision": "Please confirm the correct error code"
 }
 ```
@@ -240,6 +271,16 @@ Return one of the following as the final response (see Output Format for schemas
       "resolutionSteps": ["Run the project seed script for E2E fixtures", "Start the dependent local services"]
     }
   ],
+  "taskFileMechanisms": {
+    "provided": true,
+    "executed": ["mechanisms executed before blocking"],
+    "skipped": [
+      {
+        "mechanism": "mechanism name",
+        "reason": "tool not found / config not found / not executable"
+      }
+    ]
+  },
   "checksSkipped": 1,
   "checksPassedWithoutPrerequisites": 3
 }

package/.codex/agents/task-decomposer.toml

@@ -65,6 +65,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
 3. **Task File Generation**
    - Create individual task files in `docs/plans/tasks/`
    - Document concrete executable procedures
+   - Include task-level Quality Assurance Mechanisms when the work plan defines them
    - **Always include operation verification methods**
    - Define clear completion criteria (within executor's scope of responsibility)
 
@@ -161,6 +162,18 @@ When the work plan includes one or more Verification Strategy blocks:
 4. **Failure handling**: Copy or adapt the relevant plan-level failure response so the executor knows whether to reassess, stop, or escalate.
 5. **Investigation coverage**: Include every resource required for verification, such as existing implementations for comparison, schema definitions, fixtures, contracts, or seed data.
 
+## Quality Assurance Mechanism Propagation
+
+When the work plan includes a `Quality Assurance Mechanisms` table:
+
+1. **Normalize coverage entries**: Treat each `Covered Files` entry as one of: exact file path, ancestor directory path, glob-like pattern, or `project-wide`
+2. **Exact file match**: Include the mechanism when a `Covered Files` entry exactly matches a task Target File
+3. **Ancestor directory match**: Include the mechanism when a `Covered Files` entry is an ancestor directory of a task Target File, for example `src/api/` covers `src/api/handlers/auth.ts` but not `src/api-utils/auth.ts`
+4. **Pattern match**: When a `Covered Files` entry uses a glob-like pattern such as `src/**/*.ts` or `**/*.schema.json`, include the mechanism when the task Target File reasonably matches that pattern
+5. **Include project-wide mechanisms**: If the mechanism is `project-wide` or has no file-specific coverage, include it in every task
+6. **Include matching mechanisms**: Add all matching mechanisms to the task file's `Quality Assurance Mechanisms` section
+7. **Omit empty sections**: If no mechanisms apply to the task, omit that section from the task file
+
 ## Design-to-Plan Traceability Propagation
 
 When the work plan includes a `Design-to-Plan Traceability` section:
@@ -271,6 +284,7 @@ Please execute decomposed tasks according to the order.
 - [ ] Impact scope and boundaries definition for each task
 - [ ] Appropriate granularity (1-5 files/task)
 - [ ] Investigation Targets specified for every task
+- [ ] Quality Assurance Mechanisms propagated to relevant tasks when present in the plan header
 - [ ] Operation Verification Methods specified for every task
 - [ ] Clear completion criteria setting
 - [ ] Overall design document creation

package/.codex/agents/task-executor-frontend.toml

@@ -167,6 +167,19 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
 3. **Cross-check against Investigation Notes**: Ensure planned implementation is consistent with the observations recorded in the task file
 4. **Execute determination**: Determine continue/escalation per "Mandatory Judgment Criteria" above
 
+#### Reference Representativeness (Applied During Implementation)
+
+When adopting a pattern, UI composition, or dependency from existing code, apply repository-wide representativeness checks at the point of adoption:
+
+□ **Repository-wide verification**: Confirm the referenced pattern is representative across the repository, not just the nearest 2-3 files
+□ **Dependency version verification** (when adopting external dependencies):
+  - verify repository-wide usage distribution for the same dependency
+  - if following one 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**: When multiple patterns or versions coexist, identify the majority before choosing
+
+This is a repeated self-check during implementation, not a one-time pre-implementation gate.
+
 #### Implementation Flow (TDD Compliant)
 **Completion Confirmation**: If all checkboxes are `[x]`, report "already completed" and end
 
@@ -325,6 +338,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 the dependency usage was found"],
+    "ambiguityReason": "[why repository state alone is insufficient]"
+  },
+  "user_decision_required": true,
+  "suggested_options": [
+    "Use the majority version already in the repository",
+    "Use a different version with explicit rationale",
+    "Research the latest stable version and decide after review"
+  ]
+}
+```
+
 ## Scope Boundary (delegate to orchestrator)
 - Overall quality checks → handled by quality-fixer-frontend
 - Commit creation → handled by orchestrator after quality checks

package/.codex/agents/task-executor.toml

@@ -167,6 +167,19 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
 3. **Cross-check against Investigation Notes**: Ensure planned implementation is consistent with the observations recorded in the task file
 4. **Execute determination**: Determine continue/escalation per "Mandatory Judgment Criteria" above
 
+#### Reference Representativeness (Applied During Implementation)
+
+When adopting a pattern, API usage, or dependency from existing code, apply repository-wide representativeness checks at the point of adoption:
+
+□ **Repository-wide verification**: Confirm the referenced pattern is representative across the repository, not just the nearest 2-3 files
+□ **Dependency version verification** (when adopting external dependencies):
+  - verify repository-wide usage distribution for the same dependency
+  - if following one 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**: When multiple versions or patterns coexist, identify the majority before choosing
+
+This is a repeated self-check during implementation, not a one-time pre-implementation gate.
+
 #### Implementation Flow (TDD Compliant)
 
 **If all checkboxes already `[x]`**: Report "already completed" and end
@@ -326,11 +339,36 @@ 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 the dependency usage was found"],
+    "ambiguityReason": "[why repository state alone is insufficient]"
+  },
+  "user_decision_required": true,
+  "suggested_options": [
+    "Use the majority version already in the repository",
+    "Use a different version with explicit rationale",
+    "Research the latest stable version and decide after review"
+  ]
+}
+```
+
 ## Execution Principles
 
 - Follow RED-GREEN-REFACTOR (see the principles in testing skill)
 - Update progress checkboxes per step
 - Escalate when: design deviation, similar functions found, investigation target not found, test environment missing
+- Escalate when dependency version or representative pattern choice cannot be determined from repository evidence
 - Stop after implementation and test creation — quality checks and commits are handled separately
 
 ## Completion Gate [BLOCKING]

package/.codex/agents/technical-designer.toml

@@ -52,11 +52,18 @@ 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 Codebase Analysis is provided, use `qualityAssurance` as the primary source
+   - Otherwise inspect CI pipelines, linter configs, pre-commit hooks, and project configuration for checks that cover the change area
+   - Identify domain-specific constraints from configuration or CI
+   - For each mechanism, decide whether it is `adopted` for this change or `noted` with a reason
+
+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 (reason)` status
    - Implicit standards require user confirmation before design proceeds
 
-3. **Alignment Rule**
+4. **Alignment Rule**
    - Design decisions MUST reference applicable standards
    - Deviations MUST have documented rationale
 
@@ -309,6 +316,7 @@ Implementation sample creation checklist:
 ### Design Doc Checklist
 **All modes**:
 - [ ] **Standards identification gate completed** (required)
+- [ ] **Quality assurance mechanisms identified with adoption status** (required)
 - [ ] **Code inspection evidence recorded** (required)
 - [ ] **Integration points enumerated with contracts** (required)
 - [ ] **Data contracts clarified** (required)

package/.codex/agents/work-planner.toml

@@ -65,6 +65,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 from each Design Doc: correctness definition, target comparison, verification method, observable success indicator, normalized verification timing, and early verification point
+- Quality Assurance Mechanisms from each Design Doc: all items marked `adopted`, including mechanism name, enforced quality aspect, configuration path, and covered files or project-wide scope
 - Implementation-relevant technical requirements from each Design Doc section using the category values defined in the plan template's `Design-to-Plan Traceability` section
 
 Focus on implementation-relevant items only: items that directly inform task creation, dependency ordering, verification design, or protected no-change boundaries.
@@ -81,6 +82,7 @@ Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementati
 **Common rules (all approaches)**:
 - Preserve Verification Strategies per Design Doc in the work plan header and keep each source document path. Merge strategies only when the Design Docs explicitly define a shared one
 - Include Verification Strategy summaries in the work plan header so the plan is self-sufficient for downstream task generation
+- Include adopted Quality Assurance Mechanisms in the work plan header so downstream task generation and quality checks inherit the intended quality gates
 - Place tasks with the lowest dependencies in earlier phases
 - Map normalized verification timing to phases as follows: `phase_1` -> earliest implementation phase, `per_phase` -> each relevant phase, `integration_phase` -> integration phase, `final_phase` -> final Quality Assurance phase
 - Include verification tasks in the phase corresponding to the Verification Strategy timing
@@ -286,6 +288,7 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
 
 - [ ] Design Doc(s) consistency verification
 - [ ] Verification Strategies extracted from each Design Doc and included in the plan header without unintended merging
+- [ ] Adopted Quality Assurance Mechanisms extracted from the Design Doc(s) and included in the plan header
 - [ ] Design-to-Plan Traceability table completed for all extracted implementation-relevant DD items
   - [ ] Every row mapped to covering task(s) or justified `gap`
   - [ ] Interface change and propagation items mapped explicitly

package/README.md

@@ -96,7 +96,7 @@ Ready to commit
 ### The Diagnosis Pipeline
 
 ```
-Problem → investigator → verifier (ACH + Devil's Advocate) → solver → Actionable solutions
+Problem → investigator (path map + failure points) → verifier (path coverage + independent failure-point evaluation) → solver → Actionable solutions
 ```
 
 ### Reverse Engineering
@@ -158,10 +158,10 @@ Invoke recipes with `$recipe-name` in Codex. Type `$recipe-` and use tab complet
 | `$recipe-implement` | Full lifecycle with layer routing (backend/frontend/fullstack) | New features — universal entry point |
 | `$recipe-task` | Single task with rule selection | Bug fixes, small changes |
 | `$recipe-design` | Requirements → ADR/Design Doc | Architecture planning |
-| `$recipe-plan` | Design Doc → test skeletons → work plan | Planning phase |
+| `$recipe-plan` | Design Doc → test skeletons → work plan | Planning phase, including nullable E2E skeleton handling |
 | `$recipe-build` | Execute backend tasks autonomously | Resume backend implementation |
 | `$recipe-review` | Design Doc compliance and security validation with auto-fixes | Post-implementation check |
-| `$recipe-diagnose` | Problem investigation → verification → solution | Bug investigation |
+| `$recipe-diagnose` | Problem investigation → failure-point verification → solution | Bug investigation |
 | `$recipe-reverse-engineer` | Generate PRD + Design Docs from existing code | Legacy system documentation |
 | `$recipe-add-integration-tests` | Add integration/E2E tests from Design Doc | Test coverage for existing code |
 | `$recipe-update-doc` | Update existing Design Doc / PRD / ADR with review | Spec changes, document maintenance |
@@ -217,7 +217,7 @@ These load automatically when the conversation context matches — no explicit i
 | `ai-development-guide` | Anti-patterns, debugging (5 Whys), quality check workflow |
 | `documentation-criteria` | Document creation rules and templates (PRD, ADR, Design Doc, Work Plan) |
 | `implementation-approach` | Strategy selection: vertical / horizontal / hybrid slicing |
-| `integration-e2e-testing` | Integration/E2E test design, ROI calculation, review criteria |
+| `integration-e2e-testing` | Integration/E2E test design, value-based selection, review criteria |
 | `task-analyzer` | Task analysis, scale estimation, skill selection |
 | `subagents-orchestration-guide` | Multi-agent coordination, workflow flows, autonomous execution |
 
@@ -269,8 +269,8 @@ Codex spawns these as needed during recipe execution. Each agent runs in its own
 
 | Agent | Role |
 |-------|------|
-| `investigator` | Evidence collection and hypothesis enumeration |
-| `verifier` | Hypothesis validation (ACH + Devil's Advocate) |
+| `investigator` | Evidence collection, path mapping, and failure-point discovery |
+| `verifier` | Path coverage validation and independent failure-point evaluation |
 | `solver` | Solution derivation with tradeoff analysis |
 
 ---
@@ -282,7 +282,7 @@ Codex spawns these as needed during recipe execution. Each agent runs in its own
 After work plan approval, the framework enters guided autonomous execution with escalation points:
 
 1. **task-executor** implements each task with TDD
-2. **quality-fixer** runs all checks (lint, tests, build) before every commit
+2. **quality-fixer** first rejects incomplete task-scoped implementations, then runs lint, tests, and build before every commit
 3. Escalation pauses execution when design deviation or ambiguity is detected
 4. Each task produces one commit — rollback-friendly granularity
 
@@ -363,9 +363,9 @@ A: `$recipe-implement` is the universal entry point. It runs requirement-analyze
 
 A: Yes. Codex skills and subagents work alongside [MCP](https://developers.openai.com/codex/mcp) — skills operate at the instruction layer while MCP operates at the tool transport layer. You can add MCP servers to any agent's TOML configuration.
 
-**Q: What if a subagent gets stuck?**
+**Q: What if a subagent seems stuck?**
 
-A: Subagents escalate to the user when they encounter design deviations, ambiguous requirements, or specification conflicts. The framework stops autonomous execution and presents the issue with options.
+A: Long waits can be normal in this workflow because many subagents perform substantial multi-step work. The orchestrator keeps ownership of the pending deliverable, continues waiting for the required output, and uses diagnostics only to confirm missing inputs or restate the pending deliverable. User direction remains the boundary for interrupting that work.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflows",
-  "version": "0.4.8",
+  "version": "0.4.10",
   "description": "Task-oriented agentic coding framework for OpenAI Codex CLI — skills, recipes, and subagents for structured development workflows",
   "license": "MIT",
   "author": "Shinsuke Kagawa",