@pzy560117/codex-harness 0.1.3 → 0.1.4

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/speckit-tasks/SKILL.md

@@ -9,42 +9,42 @@ description: Generate an actionable, dependency-ordered tasks.md for the feature
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 与用户的生成汇报、任务摘要、MVP 建议全部使用简体中文。
-- 实际写入仓库的 `tasks.md` 必须使用简体中文。
-- 即使模板原文是英文，实际落盘时也要把 Phase 标题、Goal、Independent Test、Checkpoint、说明文字改写成中文。
-- 保留不能随意翻译的机器敏感标记与技术标识，例如 `_Requirements: ..._`、`FR-001`、任务 ID、HTML `<!-- id: XX -->`、路径、命令。
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的生成汇报、任务摘要、MVP 建议全部使用简体中文。
+- 实际写入仓库的 `tasks.md` 必须使用简体中文。
+- 即使模板原文是英文，实际落盘时也要把 Phase 标题、Goal、Independent Test、Checkpoint、说明文字改写成中文。
+- 保留不能随意翻译的机器敏感标记与技术标识，例如 `_Requirements: ..._`、`FR-001`、任务 ID、HTML `<!-- id: XX -->`、路径、命令。
 
 ## Outline
 
 1. **Setup**: Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
 
-2. **Load design documents**: Read from FEATURE_DIR:
-   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)
-   - **Testing truth sources**: acceptance-examples.md, requirements-testability-review.md, verify-matrix.md, test-strategy.md, test-manifest.json when present
-   - **Optional**: data-model.md (entities), contracts/ (API endpoints), research.md (decisions), quickstart.md (test scenarios)
-   - Note: Not all projects have all documents. Generate tasks based on what's available.
-
-3. **Execute task generation workflow**:
-   - Load plan.md and extract tech stack, libraries, project structure
-   - Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)
-   - If data-model.md exists: Extract entities and map to user stories
-   - If contracts/ exists: Map endpoints to user stories
-   - If research.md exists: Extract decisions for setup tasks
-   - If test-manifest.json or verify-matrix.md exists: Map requirement testability, test layers, test files, commands, blockers, gaps, and evidence paths into task fields
-   - If requirements-testability-review.md marks a requirement as `Blocked`, do not generate a task that closes that formal `FR-*`; generate blocker/evidence work first
-   - If the feature mentions predefined OSS stacks or real external systems: schedule environment/blocker/integration tasks before UI or BFF tasks
-   - If a story is `integration` / `production` and spans external systems, connectors, BFF/API, or UI, decompose it into acceptance-sized slices instead of one epic-style task
-   - Prefer 4-6 tasks for an integration-heavy story: blocker/evidence readiness, contract projection, real connector path, bridge/policy metadata, upper-layer aggregation or UI consumption, final integration transcript
-   - If one candidate task would simultaneously close blockers, implement real connectors, add BFF/API/UI, and write final evidence, split it before continuing
-   - Generate tasks organized by user story (see Task Generation Rules below)
-   - Generate dependency graph showing user story completion order
-   - Create parallel execution examples per user story
-   - Validate task completeness (each user story has all needed tasks, independently testable)
-   - If a story still collapses into a single oversized task, regenerate it with finer acceptance boundaries before writing `tasks.md`
+2. **Load design documents**: Read from FEATURE_DIR:
+   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)
+   - **Testing truth sources**: acceptance-examples.md, requirements-testability-review.md, verify-matrix.md, test-strategy.md, test-manifest.json when present
+   - **Optional**: data-model.md (entities), contracts/ (API endpoints), research.md (decisions), quickstart.md (test scenarios)
+   - Note: Not all projects have all documents. Generate tasks based on what's available.
+
+3. **Execute task generation workflow**:
+   - Load plan.md and extract tech stack, libraries, project structure
+   - Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)
+   - If data-model.md exists: Extract entities and map to user stories
+   - If contracts/ exists: Map endpoints to user stories
+   - If research.md exists: Extract decisions for setup tasks
+   - If test-manifest.json or verify-matrix.md exists: Map requirement testability, test layers, test files, commands, blockers, gaps, and evidence paths into task fields
+   - If requirements-testability-review.md marks a requirement as `Blocked`, do not generate a task that closes that formal `FR-*`; generate blocker/evidence work first
+   - If the feature mentions predefined OSS stacks or real external systems: schedule environment/blocker/integration tasks before UI or BFF tasks
+   - If a story is `integration` / `production` and spans external systems, connectors, BFF/API, or UI, decompose it into acceptance-sized slices instead of one epic-style task
+   - Prefer 4-6 tasks for an integration-heavy story: blocker/evidence readiness, contract projection, real connector path, bridge/policy metadata, upper-layer aggregation or UI consumption, final integration transcript
+   - If one candidate task would simultaneously close blockers, implement real connectors, add BFF/API/UI, and write final evidence, split it before continuing
+   - Generate tasks organized by user story (see Task Generation Rules below)
+   - Generate dependency graph showing user story completion order
+   - Create parallel execution examples per user story
+   - Validate task completeness (each user story has all needed tasks, independently testable)
+   - If a story still collapses into a single oversized task, regenerate it with finer acceptance boundaries before writing `tasks.md`
 
 4. **Generate tasks.md**: Use `.agents/.specify/templates/tasks-template.md` as structure, fill with:
    - Correct feature name from plan.md
@@ -54,41 +54,41 @@ You **MUST** consider the user input before proceeding (if not empty).
    - Phase 2+: One phase per user story (in priority order from spec.md)
    - Each phase includes: Goal, Independent Test, implementation tasks
    - Final Phase: Polish & cross-cutting concerns
-   - All tasks must follow the strict task format (see Task Format Rules below), including testing fields for behavior/integration work
-   - Dependencies section with ASCII dependency graph + User Story dependency table
-   - Implementation strategy section (MVP first, incremental delivery)
-
-5. **Report**: Output path to generated tasks.md and summary:
-   - Total task count
-   - Task count per user story
-   - Stories intentionally kept as a single task (with explicit justification)
-   - Parallel opportunities identified
-   - Independent test criteria for each story
-   - Suggested MVP scope (typically just User Story 1)
-   - Format validation: Confirm ALL tasks follow the required format
+   - All tasks must follow the strict task format (see Task Format Rules below), including testing fields for behavior/integration work
+   - Dependencies section with ASCII dependency graph + User Story dependency table
+   - Implementation strategy section (MVP first, incremental delivery)
+
+5. **Report**: Output path to generated tasks.md and summary:
+   - Total task count
+   - Task count per user story
+   - Stories intentionally kept as a single task (with explicit justification)
+   - Parallel opportunities identified
+   - Independent test criteria for each story
+   - Suggested MVP scope (typically just User Story 1)
+   - Format validation: Confirm ALL tasks follow the required format
 
 ## Task Format Rules
 
-**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.
-
-**CRITICAL**: Default to one clear task boundary per round. Do not generate tasks that implicitly require the implementation agent to read the entire feature and finish everything in one pass.
-
-**CRITICAL**: For `integration` / `production` stories, do not collapse the whole story into one giant `T001`-style task. A task should usually correspond to one acceptance checkpoint and be small enough to split into 3-7 flat Plan mode substeps.
-
-**Testing is left-shifted**: Do not wait until `/speckit.implement` or `/speckit.verify` to invent test scope. Use `acceptance-examples.md`, `requirements-testability-review.md`, `verify-matrix.md`, `test-strategy.md`, and `test-manifest.json` when they exist.
-
-**Tests are contextual, not optional by default**:
-- Documentation-only tasks may use documentation validation such as `git -c core.safecrlf=false diff --check`.
-- Behavior-changing tasks should include test file / command mapping or explicitly mark `TEST-GAP`.
-- Bugfix tasks must include a failing test, failure transcript, or reproducible failure evidence.
-- `integration` / `production` tasks must include evidence paths and at least one non-unit verification layer when applicable.
-
-### 集成型 Story 拆分规则
-
-- 如果一个故事同时涉及 `TBD-*` 阻塞、真实 connector、BFF/API 聚合、页面消费和最终证据，必须拆成多个任务，不要压成一个 epic 任务。
-- 推荐拆分顺序是：环境或 blocker 证据 -> contract projection / schema mapping -> real connector / read-write path -> bridge / policy / metadata / RBAC -> BFF/API/UI 消费 -> 联调 transcript / 失败态证据。
-- 如果一个任务同时承担 3 类以上职责，默认视为粒度过粗，应继续拆分。
-- 如果某个故事最终只保留 1 个任务，必须在任务说明或生成汇报里给出明确理由，例如“本轮只做 blocker note”或“当前切片仅包含单文件修复”。
+**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.
+
+**CRITICAL**: Default to one clear task boundary per round. Do not generate tasks that implicitly require the implementation agent to read the entire feature and finish everything in one pass.
+
+**CRITICAL**: For `integration` / `production` stories, do not collapse the whole story into one giant `T001`-style task. A task should usually correspond to one acceptance checkpoint and be small enough to split into 3-7 flat Plan mode substeps.
+
+**Testing is left-shifted**: Do not wait until `/speckit.implement` or `/speckit.verify` to invent test scope. Use `acceptance-examples.md`, `requirements-testability-review.md`, `verify-matrix.md`, `test-strategy.md`, and `test-manifest.json` when they exist.
+
+**Tests are contextual, not optional by default**:
+- Documentation-only tasks may use documentation validation such as `git -c core.safecrlf=false diff --check`.
+- Behavior-changing tasks should include test file / command mapping or explicitly mark `TEST-GAP`.
+- Bugfix tasks must include a failing test, failure transcript, or reproducible failure evidence.
+- `integration` / `production` tasks must include evidence paths and at least one non-unit verification layer when applicable.
+
+### 集成型 Story 拆分规则
+
+- 如果一个故事同时涉及 `TBD-*` 阻塞、真实 connector、BFF/API 聚合、页面消费和最终证据，必须拆成多个任务，不要压成一个 epic 任务。
+- 推荐拆分顺序是：环境或 blocker 证据 -> contract projection / schema mapping -> real connector / read-write path -> bridge / policy / metadata / RBAC -> BFF/API/UI 消费 -> 联调 transcript / 失败态证据。
+- 如果一个任务同时承担 3 类以上职责，默认视为粒度过粗，应继续拆分。
+- 如果某个故事最终只保留 1 个任务，必须在任务说明或生成汇报里给出明确理由，例如“本轮只做 blocker note”或“当前切片仅包含单文件修复”。
 
 ### Task Item Format (REQUIRED)
 
@@ -113,17 +113,17 @@ Every task MUST strictly follow this structure:
 4. **[P] marker**: Include ONLY if parallelizable (different files, no dependencies)
 5. **[USn] label**: REQUIRED for user story phase tasks only (US1, US2, ...)
 6. **📋 规格参考**: Link to source document and section
-7. **_Requirements_**: Italic, list of FR/NFR codes from spec.md
-8. **✅ 验收标准**: Measurable acceptance criteria
-9. **📁 文件清单**: Files to create/modify (with full paths)
-10. **🧪 测试文件**: Required for behavior-changing tasks, or `TEST-GAP` with reason
-11. **🔴 RED 命令**: Required for bugfix/TDD tasks; recommended for behavior-changing tasks
-12. **🟢 GREEN 命令**: Command expected to pass after implementation
-13. **📌 受影响测试**: Affected tests or regression commands
-14. **📎 证据文件**: Evidence path for integration/production tasks
-15. **🧪 验证层**: unit / component / contract / integration / e2e / visual / downstream
-16. **🔍 自检命令**: Minimal executable task completion proof
-17. **📝 执行内容**: Detailed implementation steps or method list
+7. **_Requirements_**: Italic, list of FR/NFR codes from spec.md
+8. **✅ 验收标准**: Measurable acceptance criteria
+9. **📁 文件清单**: Files to create/modify (with full paths)
+10. **🧪 测试文件**: Required for behavior-changing tasks, or `TEST-GAP` with reason
+11. **🔴 RED 命令**: Required for bugfix/TDD tasks; recommended for behavior-changing tasks
+12. **🟢 GREEN 命令**: Command expected to pass after implementation
+13. **📌 受影响测试**: Affected tests or regression commands
+14. **📎 证据文件**: Evidence path for integration/production tasks
+15. **🧪 验证层**: unit / component / contract / integration / e2e / visual / downstream
+16. **🔍 自检命令**: Minimal executable task completion proof
+17. **📝 执行内容**: Detailed implementation steps or method list
 
 **Icons reference**:
 - 📋 = 规格参考 (spec reference)
@@ -165,13 +165,13 @@ Each Phase MUST have:
 - Tasks following the format above
 - **Checkpoint**: Completion criteria at phase end
 
-Phase ordering:
-- **Phase 1**: Setup (project initialization and infrastructure)
-- **Phase 2+**: User Stories in priority order (P1, P2, P3...)
-  - Within each story: Structure → Data → Logic → Interface → Verification
-  - For `integration` / `production` stories, prefer: blocker/evidence → connector → logic/aggregation → interface → verification
-  - Each phase should be a complete, independently testable increment
-- **Final Phase**: Polish & Cross-Cutting Concerns
+Phase ordering:
+- **Phase 1**: Setup (project initialization and infrastructure)
+- **Phase 2+**: User Stories in priority order (P1, P2, P3...)
+  - Within each story: Structure → Data → Logic → Interface → Verification
+  - For `integration` / `production` stories, prefer: blocker/evidence → connector → logic/aggregation → interface → verification
+  - Each phase should be a complete, independently testable increment
+- **Final Phase**: Polish & Cross-Cutting Concerns
 
 ### Dependencies Section (REQUIRED)
 
@@ -180,8 +180,8 @@ Must include:
 2. **User Story dependency table** (Story | 依赖 | 所在 Phase)
 3. **并行机会** listing which Phases/tasks can run in parallel
 
-## Next Steps
-
-- `/speckit.analyze` - Run a project analysis for consistency
-- `/speckit.implement` - Start the implementation in phases
-- `/speckit.verify` - Run feature-level verification after implementation completes
+## Next Steps
+
+- `/speckit.analyze` - Run a project analysis for consistency
+- `/speckit.implement` - Start the implementation in phases
+- `/speckit.verify` - Run feature-level verification after implementation completes

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/speckit-verify/SKILL.md

@@ -1,142 +1,144 @@
----
-name: speckit-verify
-description: Run feature-level verification from test-manifest.json, tasks.json, verify-matrix.md, and current git diff.
----
-
-## User Input
-
-```text
-$ARGUMENTS
-```
-
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 与用户的验证进展、失败归因、完成汇报全部使用简体中文。
-- 实际写入仓库的 `verify-report.md`、`docs/evidence/<feature>/verify.md` 和 `test-manifest.json` 状态更新必须使用简体中文说明。
-- 保留 `FR-001`、`AE-001`、`TEST-GAP`、路径、命令、exit code 等机器敏感标记原样不变。
-
-## Goal
-
-`/speckit.verify` 是 feature 完成后的验证线，不替代需求阶段测试左移，也不替代实现期 test-first。它只负责：
-
-- fresh evidence
-- affected tests
-- baseline / required commands
-- P0/P1 regression confirmation
-- failure triage
-
-如果当前 feature 还没有 `acceptance-examples.md`、`requirements-testability-review.md`、`verify-matrix.md`、`test-strategy.md` 或 `test-manifest.json`，不要临时猜测试范围；先回到 `/speckit.plan` 补齐。
-
-## Workflow
-
-1. Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse:
-   - `FEATURE_DIR`
-   - `FEATURE_SPEC`
-   - `IMPL_PLAN`
-   - `TASKS`
-
-2. Load only the verification inputs:
-   - `FEATURE_DIR/test-manifest.json`
-   - `FEATURE_DIR/tasks.json`
-   - `FEATURE_DIR/verify-matrix.md`
-   - `FEATURE_DIR/requirements-testability-review.md`
-   - `FEATURE_DIR/test-strategy.md`
-
-3. Validate readiness before running commands:
-   - `test-manifest.json` parses as JSON.
-   - All completed `integration` / `production` tasks have evidence paths.
-   - No formal requirement needed for this verification is `Blocked`.
-   - `TEST-GAP` entries are either intentionally accepted by delivery mode or converted into follow-up tasks.
-   - Every command about to run is concrete and executable from repo root.
-   - If the repository has `task.json`, `package.json` scripts, and `docs/testing/verify-matrix.md`, verify that critical test scripts are mapped to task ids and evidence boundaries before treating release evidence as complete. A release gate is not enough by itself when individual practices such as API / DB / worker / query / file / sample / mock-local / object-storage smoke are not mapped.
-   - If a guard test such as `tests/mock-local/test-practice-matrix.test.mjs` exists, include its owning command, usually `npm run test:mock-local`, in the verification command set when `task.json`, `package.json`, `tests/`, `docs/testing/verify-matrix.md`, release gate wording, or evidence boundaries changed.
-
-4. Build the verification command set:
-   - Baseline commands from `test-manifest.json.baseline.commands`.
-   - Required commands from each relevant requirement in `test-manifest.json.requirements`.
-   - Affected tests inferred from `git diff --name-only`, `tasks.json`, and `verify-matrix.md`.
-   - Always include `git -c core.safecrlf=false diff --check`.
-
-   For driver-first repositories with root `task.json`, also infer affected tests from:
-
-   - each changed task's `test_command`
-   - `package.json` scripts referenced by changed tasks or verify-matrix rows
-   - test practice mapping guard tests, when present
-   - release scripts that aggregate lower-level practices, without allowing the aggregate to hide unmapped test scripts
-
-5. Execute commands from repo root:
-   - Record command, exit code, start/end time, and compact output.
-   - Stop on hard failure unless the failure is explicitly documented as pre-existing baseline failure.
-   - Do not mark a failed requirement as verified.
-
-6. Write verification outputs:
-   - `FEATURE_DIR/verify-report.md`
-   - `docs/evidence/<feature>/verify.md`
-
-7. Update `test-manifest.json`:
-   - Set `baseline.status` to `passed`, `failed`, or `blocked`.
-   - For each requirement, set status-like fields if present; if absent, add `verificationStatus`.
-   - Preserve existing requirement IDs, blockers, paths, and command arrays.
-
-8. Report:
-   - commands run
-   - passed / failed / skipped count
-   - affected tests
-   - requirements verified
-   - unresolved blockers or `TEST-GAP`
-   - next action: proceed, create follow-up tasks, or return to plan/tasks
-
-## Output Template
-
-`verify-report.md` should use this structure:
-
-```md
-# Verify Report: <feature>
-
-## Summary
-
-| Field | Value |
-| --- | --- |
-| Feature | |
-| Delivery Mode | |
-| Result | Passed / Failed / Blocked |
-| Generated At | |
-
-## Commands
-
-| Command | Exit Code | Result | Evidence |
-| --- | --- | --- | --- |
-
-## Requirement Verification
-
-| Requirement ID | Testability | Commands | Evidence Path | Result | Notes |
-| --- | --- | --- | --- | --- | --- |
-
-## Affected Tests
-
-| Changed Path | Selected Tests | Reason |
-| --- | --- | --- |
-
-## Failure Triage
-
-| Failure | Likely Owner | Root Cause | Next Action |
-| --- | --- | --- | --- |
-```
-
-## Hard Gates
-
-- Invalid or missing `test-manifest.json` blocks verification.
-- `integration` / `production` requirements with unresolved blockers remain `blocked`.
-- Missing evidence paths for completed `integration` / `production` tasks block verification.
-- Required commands failing without a documented pre-existing baseline failure block verification.
-- `TEST-GAP` cannot be silently treated as verified.
-- In driver-first repos, critical test scripts without task ownership or verify-matrix evidence boundaries block release completion.
-- mock/local rehearsal, docker/mock release, and external live validation cannot be collapsed into one evidence category.
-
-## Next Steps
-
-- `/speckit.tasks` - create follow-up tasks for failed verification or `TEST-GAP`
-- `/speckit.implement` - fix failed tasks one boundary at a time
-- `/speckit.verify` - rerun after fixes
+---
+name: speckit-verify
+description: Run feature-level verification from test-manifest.json, tasks.json, verify-matrix.md, and current git diff.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的验证进展、失败归因、完成汇报全部使用简体中文。
+- 实际写入仓库的 `verify-report.md`、`docs/evidence/<feature>/verify.md` 和 `test-manifest.json` 状态更新必须使用简体中文说明。
+- 保留 `FR-001`、`AE-001`、`TEST-GAP`、路径、命令、exit code 等机器敏感标记原样不变。
+
+## Goal
+
+`/speckit.verify` 是 feature 完成后的验证线，不替代需求阶段测试左移，也不替代实现期 test-first。它只负责：
+
+- fresh evidence
+- affected tests
+- baseline / required commands
+- P0/P1 regression confirmation
+- failure triage
+
+如果当前 feature 还没有 `acceptance-examples.md`、`requirements-testability-review.md`、`verify-matrix.md`、`test-strategy.md` 或 `test-manifest.json`，不要临时猜测试范围；先回到 `/speckit.plan` 补齐。
+
+如果仓库是 thin install 项目且 `docs/testing/*` 不在项目根，先读取 `.codex-harness/state/config.json`，再到 `packageRoot` 下查同路径 testing truth sources。
+
+## Workflow
+
+1. Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse:
+   - `FEATURE_DIR`
+   - `FEATURE_SPEC`
+   - `IMPL_PLAN`
+   - `TASKS`
+
+2. Load only the verification inputs:
+   - `FEATURE_DIR/test-manifest.json`
+   - `FEATURE_DIR/tasks.json`
+   - `FEATURE_DIR/verify-matrix.md`
+   - `FEATURE_DIR/requirements-testability-review.md`
+   - `FEATURE_DIR/test-strategy.md`
+
+3. Validate readiness before running commands:
+   - `test-manifest.json` parses as JSON.
+   - All completed `integration` / `production` tasks have evidence paths.
+   - No formal requirement needed for this verification is `Blocked`.
+   - `TEST-GAP` entries are either intentionally accepted by delivery mode or converted into follow-up tasks.
+   - Every command about to run is concrete and executable from repo root.
+   - If the repository has `task.json`, `package.json` scripts, and `docs/testing/verify-matrix.md`, verify that critical test scripts are mapped to task ids and evidence boundaries before treating release evidence as complete. A release gate is not enough by itself when individual practices such as API / DB / worker / query / file / sample / mock-local / object-storage smoke are not mapped.
+   - If a guard test such as `tests/mock-local/test-practice-matrix.test.mjs` exists, include its owning command, usually `npm run test:mock-local`, in the verification command set when `task.json`, `package.json`, `tests/`, `docs/testing/verify-matrix.md`, release gate wording, or evidence boundaries changed.
+
+4. Build the verification command set:
+   - Baseline commands from `test-manifest.json.baseline.commands`.
+   - Required commands from each relevant requirement in `test-manifest.json.requirements`.
+   - Affected tests inferred from `git diff --name-only`, `tasks.json`, and `verify-matrix.md`.
+   - Always include `git -c core.safecrlf=false diff --check`.
+
+   For driver-first repositories with root `task.json`, also infer affected tests from:
+
+   - each changed task's `test_command`
+   - `package.json` scripts referenced by changed tasks or verify-matrix rows
+   - test practice mapping guard tests, when present
+   - release scripts that aggregate lower-level practices, without allowing the aggregate to hide unmapped test scripts
+
+5. Execute commands from repo root:
+   - Record command, exit code, start/end time, and compact output.
+   - Stop on hard failure unless the failure is explicitly documented as pre-existing baseline failure.
+   - Do not mark a failed requirement as verified.
+
+6. Write verification outputs:
+   - `FEATURE_DIR/verify-report.md`
+   - `docs/evidence/<feature>/verify.md`
+
+7. Update `test-manifest.json`:
+   - Set `baseline.status` to `passed`, `failed`, or `blocked`.
+   - For each requirement, set status-like fields if present; if absent, add `verificationStatus`.
+   - Preserve existing requirement IDs, blockers, paths, and command arrays.
+
+8. Report:
+   - commands run
+   - passed / failed / skipped count
+   - affected tests
+   - requirements verified
+   - unresolved blockers or `TEST-GAP`
+   - next action: proceed, create follow-up tasks, or return to plan/tasks
+
+## Output Template
+
+`verify-report.md` should use this structure:
+
+```md
+# Verify Report: <feature>
+
+## Summary
+
+| Field | Value |
+| --- | --- |
+| Feature | |
+| Delivery Mode | |
+| Result | Passed / Failed / Blocked |
+| Generated At | |
+
+## Commands
+
+| Command | Exit Code | Result | Evidence |
+| --- | --- | --- | --- |
+
+## Requirement Verification
+
+| Requirement ID | Testability | Commands | Evidence Path | Result | Notes |
+| --- | --- | --- | --- | --- | --- |
+
+## Affected Tests
+
+| Changed Path | Selected Tests | Reason |
+| --- | --- | --- |
+
+## Failure Triage
+
+| Failure | Likely Owner | Root Cause | Next Action |
+| --- | --- | --- | --- |
+```
+
+## Hard Gates
+
+- Invalid or missing `test-manifest.json` blocks verification.
+- `integration` / `production` requirements with unresolved blockers remain `blocked`.
+- Missing evidence paths for completed `integration` / `production` tasks block verification.
+- Required commands failing without a documented pre-existing baseline failure block verification.
+- `TEST-GAP` cannot be silently treated as verified.
+- In driver-first repos, critical test scripts without task ownership or verify-matrix evidence boundaries block release completion.
+- mock/local rehearsal, docker/mock release, and external live validation cannot be collapsed into one evidence category.
+
+## Next Steps
+
+- `/speckit.tasks` - create follow-up tasks for failed verification or `TEST-GAP`
+- `/speckit.implement` - fix failed tasks one boundary at a time
+- `/speckit.verify` - rerun after fixes