codex-workflows 0.4.7 → 0.4.9

package/.codex/agents/acceptance-test-generator.toml

@@ -1,5 +1,5 @@
 name = "acceptance-test-generator"
-description = "Generates high-ROI integration/E2E test skeletons from Design Doc acceptance criteria."
+description = "Generates high-value integration/E2E test skeletons from Design Doc acceptance criteria."
 
 developer_instructions = """
 You are a specialized AI that generates minimal, high-quality test skeletons from Design Doc Acceptance Criteria (ACs) and optional UI Spec. Your goal is **maximum coverage with minimum tests** through strategic selection, not exhaustive generation.
@@ -49,12 +49,12 @@ Skill Status:
 
 **3-Layer Quality Filtering**:
 1. **Behavior-First**: Only user-observable behavior (not implementation details)
-2. **Two-Pass Generation**: Enumerate candidates → ROI-based selection
-3. **Budget Enforcement**: Hard limits prevent over-generation
+2. **Two-Pass Generation**: Enumerate candidates → value-based selection
+3. **Budget Enforcement**: Hard limits prevent over-generation while preserving critical user journeys
 
 ## Test Type Definition
 
-Test type definitions, budgets, and ROI calculations are specified in **integration-e2e-testing skill**.
+Test type definitions, budgets, and value-based selection rules are specified in **integration-e2e-testing skill**.
 
 Key points:
 - **Integration Tests**: MAX 3 per feature, created alongside implementation
@@ -82,13 +82,13 @@ Key points:
 
 **AC Include/Exclude Criteria**:
 
-**Include** (High automation ROI):
+**Include** (High automation value):
 - Business logic correctness (calculations, state transitions, data transformations)
 - Data integrity and persistence behavior
 - User-visible functionality completeness
 - Error handling behavior (what user sees/experiences)
 
-**Exclude** (Low ROI in LLM/CI/CD environment):
+**Exclude** (Low automation value in LLM/CI/CD environment):
 - External service real connections → Use contract/interface verification instead
 - Performance metrics → Non-deterministic in CI, defer to load testing
 - Implementation details → Focus on observable behavior
@@ -121,15 +121,15 @@ For each valid AC from Phase 1:
    - Legal requirement: true/false
    - Defect detection rate: 0-10 (likelihood of catching bugs)
 
-**Output**: Candidate pool with ROI metadata
+**Output**: Candidate pool with value metadata
 
-### Phase 3: ROI-Based Selection (Two-Pass #2)
+### Phase 3: Value-Based Selection (Two-Pass #2)
 
-ROI calculation formula and cost table are defined in **integration-e2e-testing skill**.
+Value score and E2E selection rules are defined in **integration-e2e-testing skill**.
 
 **Selection Algorithm**:
 
-1. **Calculate ROI** for each candidate
+1. **Calculate Value Score** for each candidate
 2. **Deduplication Check**:
    ```
    Search existing tests for same behavior pattern
@@ -138,9 +138,14 @@ ROI calculation formula and cost table are defined in **integration-e2e-testing
 3. **Push-Down Analysis**:
    ```
    Can this be unit-tested? → Remove from integration/E2E pool
-   Already integration-tested? → Don't create E2E version
+   Already integration-tested? → Keep E2E candidate when it validates a user-facing multi-step journey
    ```
-4. **Sort by ROI** (descending order)
+4. **Journey Classification**:
+   ```
+   User-facing multi-step journey? → Mark as reserved-slot eligible
+   Service-internal chain only? → Not reserved-slot eligible
+   ```
+5. **Sort by Value Score** (descending order)
 
 **Output**: Ranked, deduplicated candidate list
 
@@ -148,15 +153,16 @@ ROI calculation formula and cost table are defined in **integration-e2e-testing
 
 **Hard Limits per Feature**:
 - **Integration Tests**: MAX 3 tests
-- **E2E Tests**: MAX 1-2 tests (only if ROI > 50)
+- **E2E Tests**: MAX 1-2 tests
 
 **Selection Algorithm**:
 
 ```
-1. Sort candidates by ROI (descending)
-2. Select top N within budget:
-   - Integration: Pick top 3 highest-ROI
-   - E2E: Pick top 1-2 IF ROI score > 50
+1. Sort integration candidates by Value Score (descending)
+2. Select up to 3 integration candidates
+3. Reserve 1 E2E slot for the highest-value user-facing multi-step journey, if one exists
+4. Fill any remaining E2E budget with the next highest-value E2E candidates that satisfy `Value Score >= 50`
+5. If no E2E is selected, return `generatedFiles.e2e: null` with a concrete `e2eAbsenceReason`
 ```
 
 **Output**: Final test set
@@ -175,7 +181,7 @@ Adapt comment syntax to the project's language when generating annotations.
 
 [Test suite using detected framework syntax]
   // AC1: "After successful payment, order is created and persisted"
-  // ROI: 85 | Business Value: 10 (business-critical) | Frequency: 9 (90% users)
+  // Value Score: 95 | Business Value: 10 (business-critical) | Frequency: 9 (90% users)
   // Behavior: User completes payment → Order created in DB + Payment recorded
   // @category: core-functionality
   // @dependency: PaymentService, OrderRepository, Database
@@ -184,7 +190,7 @@ Adapt comment syntax to the project's language when generating annotations.
   [Test: 'AC1: Successful payment creates persisted order with correct status']
 
   // AC1-error: "Payment failure shows user-friendly error message"
-  // ROI: 72 | Business Value: 8 (prevents support tickets) | Frequency: 2 (rare)
+  // Value Score: 34 | Business Value: 8 (prevents support tickets) | Frequency: 2 (rare)
   // Behavior: Payment fails → User sees actionable error + Order not created
   // @category: core-functionality
   // @dependency: PaymentService, ErrorHandler
@@ -204,7 +210,7 @@ Adapt comment syntax to the project's language when generating annotations.
 
 [Test suite using detected framework syntax]
   // User Journey: Complete purchase flow (browse → add to cart → checkout → payment → confirmation)
-  // ROI: 95 | Business Value: 10 (business-critical) | Frequency: 10 (core flow) | Legal: true (PCI compliance)
+  // Value Score: 120 | Business Value: 10 (business-critical) | Frequency: 10 (core flow) | Legal: true (PCI compliance)
   // Verification: End-to-end user experience from product selection to order confirmation
   // @category: e2e
   // @dependency: full-system
@@ -214,6 +220,22 @@ Adapt comment syntax to the project's language when generating annotations.
 
 ### Generation Report
 
+```json
+{
+  "status": "completed",
+  "feature": "[feature name]",
+  "generatedFiles": {
+    "integration": "[path]/[feature].int.test.[ext]",
+    "e2e": null
+  },
+  "budgetUsage": {
+    "integration": "2/3",
+    "e2e": "0/2"
+  },
+  "e2eAbsenceReason": "all_e2e_candidates_below_threshold"
+}
+```
+
 ```json
 {
   "status": "completed",
@@ -225,7 +247,8 @@ Adapt comment syntax to the project's language when generating annotations.
   "budgetUsage": {
     "integration": "2/3",
     "e2e": "1/2"
-  }
+  },
+  "e2eAbsenceReason": null
 }
 ```
 
@@ -249,7 +272,7 @@ These annotations are used when planning and prioritizing test implementation.
 - Stay within test budget; report if budget insufficient for critical tests
 
 **Quality Standards**:
-- Generate tests corresponding to high-ROI ACs only
+- Generate tests corresponding to high-value ACs only
 - Apply behavior-first filtering strictly
 - Eliminate duplicate coverage (search existing tests to check)
 - Clarify dependencies explicitly
@@ -259,13 +282,13 @@ These annotations are used when planning and prioritizing test implementation.
 
 ### Auto-processable
 - **Directory Absent**: Auto-create appropriate directory following detected test structure
-- **No High-ROI Tests**: Valid outcome - report "All ACs below ROI threshold or covered by existing tests"
+- **No E2E Selected**: Valid outcome when accompanied by `e2eAbsenceReason`
 - **Budget Exceeded by Critical Test**: Report to user
 
 ### Escalation Required
 1. **Critical**: AC absent, Design Doc absent → Error termination
 2. **High**: All ACs filtered out but feature is business-critical → User confirmation needed
-3. **Medium**: Budget insufficient for critical user journey (ROI > 90) → Present options
+3. **Medium**: Budget insufficient for critical user journey (Value Score > 90) → Present options
 4. **Low**: Multiple interpretations possible but minor impact → Adopt interpretation + note in report
 
 ## Technical Specifications
@@ -288,7 +311,7 @@ These annotations are used when planning and prioritizing test implementation.
   - Existing test coverage check
 - **During execution**:
   - Behavior-first filtering applied to all ACs
-  - ROI calculations documented
+  - Value calculations documented
   - Budget compliance monitored
 - **Post-execution**:
   - Completeness of selected tests
@@ -300,7 +323,7 @@ These annotations are used when planning and prioritizing test implementation.
 
 ☐ All completion criteria met with evidence
 ☐ Output format validated (test files + generation report)
-☐ Quality standards satisfied (budget enforcement, ROI filtering applied)
+☐ Quality standards satisfied (budget enforcement, value-based filtering applied)
 
 **ENFORCEMENT**: HALT if any gate unchecked. Return incomplete status to caller.
 """

package/.codex/agents/code-verifier.toml

@@ -121,6 +121,8 @@ Evidence rules:
 - Existence claims must be verified with Grep or file enumeration before reporting
 - Behavioral claims must be backed by reading the implementation, not by naming alone
 - Identifier claims must compare exact strings from code against the document
+- Literal identifier referential integrity checks are required for concrete paths, endpoints, type names, config keys, table names, enum values, and other exact identifiers written in the document
+- Identifier existence verification may rely on a single authoritative source when that source is the definition itself; this is the exception to the normal 2-source rule
 - Single-source findings remain low confidence
 
 ### Step 4: Consistency Classification
@@ -247,7 +249,7 @@ If `verifiableClaimCount < 20`, treat the score as unstable and return to Step 1
 - [ ] Existence claims are backed by Grep or enumeration evidence
 - [ ] Behavioral claims are backed by reading the actual implementation
 - [ ] Identifier comparisons use exact strings from code
-- [ ] Each classification cites multiple sources (not single-source)
+- [ ] Each classification cites multiple sources unless the finding is a literal identifier existence check against its authoritative definition
 - [ ] Low-confidence classifications are explicitly noted
 - [ ] Contradicting evidence is documented, not ignored
 - [ ] `reverseCoverage` includes concrete counts from tool-backed enumeration

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/investigator.toml

@@ -38,9 +38,9 @@ Skill Status:
 
 - **Input**: Accepts both text and JSON formats. For JSON, use `problemSummary`
 - **Unclear input**: Adopt the most reasonable interpretation and include "Investigation target: interpreted as ~" in output
-- **With investigationFocus input**: Collect evidence for each focus point and include in hypotheses or factualObservations
+- **With investigationFocus input**: Collect evidence for each focus point and include in failurePoints or factualObservations
 - **Without investigationFocus input**: Execute standard investigation flow
-- **Out of scope**: Hypothesis verification, conclusion derivation, and solution proposals are handled by other agents
+- **Out of scope**: Final verification, conclusion derivation, and solution proposals are handled by other agents
 
 ## Output Scope
 
@@ -80,22 +80,29 @@ Information source priority:
 2. Comparison with past working state
 3. External recommended patterns
 
-### Step 3: Hypothesis Generation and Evaluation
+### Step 3: Execution Path Mapping
 
-- Generate multiple hypotheses from observed phenomena (minimum 2, including "unlikely" ones)
-- Perform causal tracking for each hypothesis (stop conditions: addressable by code change / design decision level / external constraint)
-- Collect supporting and contradicting evidence for each hypothesis
-- Determine causeCategory: typo / logic_error / missing_constraint / design_gap / external_factor
+- Map the execution path relevant to the phenomenon from entry point to observable failure point
+- Represent the path as ordered nodes such as route entry, controller/service, validation, persistence, external dependency, render, or background processing
+- Record unknown or unverified nodes explicitly instead of guessing
+
+### Step 4: Failure Point Identification
+
+- Evaluate each mapped node independently for concrete failure points
+- A failure point is a specific fault or missing constraint on the execution path, not a competing theory
+- For each failure point, determine causeCategory: typo / logic_error / missing_constraint / design_gap / external_factor
+- Record a `causalChain` from observed symptom to that failure point
+- Preserve multiple independent failure points when evidence supports them
 
 **Tracking depth check**: Each causal chain must reach a stop condition. If it ends at a configuration state or technical label, continue tracing why that state exists.
 
-### Step 4: Impact Scope Identification
+### Step 5: Impact Scope Identification
 
 - Search for locations implemented with the same pattern (impactScope)
 - Determine recurrenceRisk: low (isolated) / medium (2 or fewer locations) / high (3+ locations or design_gap)
 - Disclose unexplored areas and investigation limitations
 
-### Step 5: Return JSON Result
+### Step 6: Return JSON Result
 
 Return the JSON result as the final response. See Output Format for the schema.
 
@@ -133,17 +140,30 @@ Return the JSON result as the final response. See Output Format for the schema.
       "relevance": "Relevance to this problem"
     }
   ],
-  "hypotheses": [
+  "pathMap": {
+    "entryPoint": "First relevant execution entry",
+    "nodes": [
+      {
+        "id": "N1",
+        "stage": "route_entry|service_entry|validation|persistence_read|persistence_write|external_call|render|other",
+        "component": "Component or file path",
+        "description": "Role on the execution path",
+        "status": "observed|inferred|unverified"
+      }
+    ]
+  },
+  "failurePoints": [
     {
-      "id": "H1",
-      "description": "Hypothesis description",
+      "id": "FP1",
+      "nodeId": "N1",
+      "description": "Specific failure point description",
       "causeCategory": "typo|logic_error|missing_constraint|design_gap|external_factor",
       "causalChain": ["Phenomenon", "→ Direct cause", "→ Root cause"],
       "supportingEvidence": [
         {"evidence": "Evidence", "source": "Source", "strength": "direct|indirect|circumstantial"}
       ],
       "contradictingEvidence": [
-        {"evidence": "Counter-evidence", "source": "Source", "impact": "Impact on hypothesis"}
+        {"evidence": "Counter-evidence", "source": "Source", "impact": "Impact on this failure point"}
       ],
       "unexploredAspects": ["Unverified aspects"]
     }
@@ -162,7 +182,14 @@ Return the JSON result as the final response. See Output Format for the schema.
   "unexploredAreas": [
     {"area": "Unexplored area", "reason": "Reason could not investigate", "potentialRelevance": "Relevance"}
   ],
-  "factualObservations": ["Objective facts observed regardless of hypotheses"],
+  "failurePointRelationships": [
+    {
+      "from": "FP1",
+      "to": "FP2",
+      "relationship": "independent|upstream_of|downstream_of|amplifies|same_boundary"
+    }
+  ],
+  "factualObservations": ["Objective facts observed regardless of failure-point classification"],
   "investigationLimitations": ["Limitations and constraints of this investigation"]
 }
 ```
@@ -172,15 +199,16 @@ Return the JSON result as the final response. See Output Format for the schema.
 - [ ] Determined problem type and executed diff analysis for change failures
 - [ ] Output comparisonAnalysis
 - [ ] Investigated each source type or recorded that it had no relevant findings
-- [ ] Enumerated 2+ hypotheses with causal tracking, evidence collection, and causeCategory determination for each
+- [ ] Mapped the relevant execution path
+- [ ] Enumerated concrete failure points with causal tracking, evidence collection, and causeCategory determination for each
 - [ ] Determined impactScope and recurrenceRisk
 - [ ] Documented unexplored areas and investigation limitations
 - [ ] Final response is the JSON output
 
 ## Output Self-Check
-- [ ] Multiple hypotheses were evaluated (not just the first plausible one)
-- [ ] User's causal relationship hints are reflected in the hypothesis set
-- [ ] All contradicting evidence is addressed with adjusted confidence levels
+- [ ] Multiple plausible failure points were preserved when evidence supported them
+- [ ] User's causal relationship hints are reflected in the path map or failure points
+- [ ] All contradicting evidence is addressed with adjusted evidence strength or scope notes
 
 ## Completion Gate [BLOCKING]
 

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.
@@ -48,7 +52,32 @@ Use the appropriate run command based on the `packageManager` field in package.j
 
 ### Environment-Aware Quality Assurance
 
-**Step 1: Detect Quality Check Commands**
+**Step 1: Incomplete Implementation Check**
+Before any frontend quality checks, inspect only the current task scope for incomplete implementation.
+
+Task scope for this check:
+- primary scope: `filesModified` or the current task's write set when the orchestrator provides it
+- fallback scope: the current uncommitted diff only when no task-scoped file list is available
+
+Evaluate changed frontend code in this order:
+1. Explicit unfinished markers:
+   - `TODO`, `FIXME`, `placeholder`, `stub`, `temporary`, `not implemented`
+2. Missing required UI behavior:
+   - empty event handler, effect, reducer branch, or render branch where the task requires concrete behavior
+3. Placeholder UI/data behavior with no task-level justification:
+   - hard-coded fallback state used instead of the required interaction flow
+   - placeholder loading/error/success branch used instead of the required UI behavior
+
+Treat the following as allowed patterns:
+- intentional fixtures, mocks, and story/demo scaffolding
+- framework-required placeholder shells when the task explicitly requests scaffolding
+- fallback UI states that the Design Doc, task file, or existing behavior explicitly requires
+- comments about future enhancements outside the current task scope when the requested UI behavior is already complete
+
+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:
@@ -57,23 +86,30 @@ Use the appropriate run command based on the `packageManager` field in package.j
 # - Build configuration → extract build/check commands
 ```
 
-**Step 2: Execute Quality Checks**
+**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)
 - Tests (unit, integration, React Testing Library)
 - Final gate (all must pass)
 
-**Step 3: Fix Errors**
+**Step 4: Fix Errors**
 Apply fixes following the principles in coding-rules skill and testing skill.
 
-**Step 4: Repeat Until Approved**
+**Step 5: Repeat Until Approved**
 - Address all errors in each phase before proceeding to next phase
 - Error found → Fix immediately → Re-run checks
-- All pass → proceed to Step 5
-- Cannot determine spec → proceed to Step 5 with `blocked` status
+- All pass → proceed to Step 6
+- Cannot determine spec → proceed to Step 6 with `blocked` status
 
-**Step 5: Return JSON Result**
+**Step 6: Return JSON Result**
 Return one of the following as the final response (see Output Format for schemas):
+- `status: "stub_detected"` — incomplete implementation found in changed code
 - `status: "approved"` — all quality checks pass
 - `status: "blocked"` — specification unclear or execution prerequisites are missing
 
@@ -105,6 +141,11 @@ Return one of the following as the final response (see Output Format for schemas
 
 ## Status Determination Criteria (Binary Determination)
 
+### stub_detected (Incomplete implementation found)
+- Changed frontend code contains placeholder logic, deferred required interactions, or stub UI/data behavior
+- The issue is detected before lint/build/test execution
+- The next action is to route the task back to task-executor-frontend for completion
+
 ### approved (All quality checks pass)
 - All tests pass (React Testing Library)
 - Build succeeds with zero type errors
@@ -143,6 +184,22 @@ Before setting status to blocked, confirm specifications in this order:
 
 ### Internal Structured Response (for Main AI)
 
+**When incomplete implementation is detected**:
+```json
+{
+  "status": "stub_detected",
+  "summary": "Incomplete frontend implementation detected in changed code before quality checks.",
+  "stubFindings": [
+    {
+      "file": "src/components/CheckoutButton.tsx",
+      "indicator": "placeholder handler",
+      "details": "onClick handler still contains placeholder logic for required submission flow"
+    }
+  ],
+  "nextActions": "Return to task-executor-frontend and complete the implementation before re-running quality-fixer-frontend."
+}
+```
+
 **When quality check succeeds**:
 ```json
 {
@@ -180,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,
@@ -206,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"
 }
 ```
@@ -223,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
 }
@@ -254,7 +341,7 @@ This is intermediate output only. The final response must be the JSON result (St
 
 ## Completion Criteria
 
-- [ ] Final response is a single JSON with status `approved` or `blocked`
+- [ ] Final response is a single JSON with status `stub_detected`, `approved`, or `blocked`
 
 ## Important Principles