@pzy560117/codex-harness 0.1.3 → 0.1.5

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/harness-surface-sync/references/current-repo-sync-matrix.md

@@ -1,110 +1,150 @@
-# Current Repo Sync Matrix
-
-Use this matrix to decide where the real edit belongs and which copies must be refreshed afterwards.
-
-## 1. Root Runtime And Driver Truth Sources
-
-Canonical source:
-
-- repo root:
-  - `AGENTS.md`
-  - `tools/install/bootstrap-codex-harness.ps1`
-  - `tools/harness/codex-loop.ps1`
-  - `tools/harness/doctor.ps1`
-  - `tools/harness/verify.ps1`
-  - `.codex/task-run-profile.json`
-  - `.codex/prompts/*.md`
-  - `tools/harness/templates/project-task-template.json`
-  - `docs/harness/*`
-  - `docs/testing/*`
-
-Typical mirrors:
-
-- `.agents/*`
-- `docs/codex-harness-engineering/templates/runtime/*`
-- `.agents/docs/codex-harness-engineering/templates/runtime/*`
-- `docs/codex-harness-engineering/templates/docs/*` or `templates/testing/*` when the source is under `docs/harness/*` or `docs/testing/*`
-
-## 2. Active Role Rules
-
-Canonical source:
-
-- `.codex/rules/agents.md`
-
-Typical mirrors:
-
-- `docs/codex-harness-engineering/templates/config/rules/agents.md`
-- `docs/codex-harness-engineering/templates/package-assets/rules/agents.md`
-- `.agents/docs/codex-harness-engineering/templates/config/rules/agents.md`
-- `.agents/docs/codex-harness-engineering/templates/package-assets/rules/agents.md`
-
-## 3. Human-Facing Harness And Package Docs
-
-Canonical source:
-
-- `docs/codex-harness-engineering/*.md`
-
-Typical mirrors:
-
-- `docs/codex-harness-engineering/templates/package-assets/docs/codex-harness-engineering/*.md`
-- `.agents/docs/codex-harness-engineering/templates/package-assets/docs/codex-harness-engineering/*.md`
-
-Special case:
-
-- `docs/harness/spec-to-ui-to-code-workflow.md` often also feeds:
-  - `docs/harness/spec-to-ui-to-code-workflow.md`
-  - `docs/codex-harness-engineering/spec-to-ui-to-code-workflow.md`
-  - `docs/codex-harness-engineering/templates/docs/spec-to-ui-to-code-workflow.md`
-  - package-assets doc mirrors
-
-## 4. Template Config
-
-Canonical source:
-
-- `docs/codex-harness-engineering/templates/config/*`
-
-Typical mirrors:
-
-- `.agents/docs/codex-harness-engineering/templates/config/*`
-
-Common targets:
-
-- `codex-config.toml`
-- `codex-readme.md`
-- `codex-agent-roles.md`
-- `global-AGENTS.md`
-- `agents/*.toml`
-
-## 5. Package-Assets Workflows
-
-Canonical source:
-
-- `docs/codex-harness-engineering/templates/package-assets/workflows/*`
-
-Typical mirrors:
-
-- `.agents/docs/codex-harness-engineering/templates/package-assets/workflows/*`
-
-## 6. Package-Assets Root Docs
-
-Canonical source:
-
-- `docs/codex-harness-engineering/templates/package-assets/root/*`
-
-Typical mirrors:
-
-- `.agents/docs/codex-harness-engineering/templates/package-assets/root/*`
-
-## 7. Repo Skills
-
-Canonical source for active usage:
-
-- `.agents/skills/<skill-name>/...`
-
-Distribution mirrors:
-
-- `docs/codex-harness-engineering/templates/package-assets/skills/<skill-name>/...`
-- `docs/codex-harness-engineering/templates/package-assets/skills/<skill-name>/...`
-- `.agents/docs/codex-harness-engineering/templates/package-assets/skills/<skill-name>/...`
-
-When a skill is created or updated, refresh the package distribution copies before considering the task done.
+# Current Repo Sync Matrix
+
+Use this matrix to decide where the real edit belongs and which copies must be refreshed afterwards.
+
+If the target repository is a thin install project and `docs/harness/*`, `docs/testing/*`, or `docs/knowledge/*` are absent from the project root, inspect the same relative paths under `packageRoot` from `.codex-harness/state/config.json`.
+
+## 1. Root Runtime And Driver Truth Sources
+
+Canonical source:
+
+- repo root:
+  - `AGENTS.md`
+  - `bootstrap-codex-harness.ps1`
+  - `codex-loop.ps1`
+  - `doctor.ps1`
+  - `verify.ps1`
+  - `.codex/task-run-profile.json`
+  - `.codex/prompts/*.md`
+  - `project-task-template.json`
+  - `docs/harness/*`
+  - `docs/testing/*`
+
+Typical mirrors:
+
+- `agent/*`
+- `.agents/*`
+- `agent/docs/codex-harness-engineering/templates/runtime/*`
+- `.agents/docs/codex-harness-engineering/templates/runtime/*`
+- `agent/docs/codex-harness-engineering/templates/docs/*` or `templates/testing/*` when the source is under `docs/harness/*` or `docs/testing/*`
+
+Special runtime-governance case:
+
+- `scripts/harness/harness-governance-check.ps1` is a root runtime governance script.
+- Required mirrors:
+  - `docs/codex-harness-engineering/templates/scripts/harness/harness-governance-check.ps1`
+  - `docs/codex-harness-engineering/templates/package-assets/scripts/harness/harness-governance-check.ps1`
+- If its behavior changes subdirectory `AGENTS.md` auto-refresh, also refresh:
+  - `docs/codex-harness-engineering/templates/docs/governance-auto-repair.md`
+  - `docs/codex-harness-engineering/templates/package-assets/docs/harness/governance-auto-repair.md`
+  - `agent/docs/codex-harness-engineering/implementation-flow.md`
+  - `agent/docs/codex-harness-engineering/templates/package-assets/docs/codex-harness-engineering/implementation-flow.md`
+
+## 2. Active Role Rules
+
+Canonical source:
+
+- `.codex/rules/agents.md`
+
+Typical mirrors:
+
+- `agent/.codex/rules/agents.md`
+- `agent/docs/codex-harness-engineering/templates/config/rules/agents.md`
+- `agent/docs/codex-harness-engineering/templates/package-assets/rules/agents.md`
+- `.agents/docs/codex-harness-engineering/templates/config/rules/agents.md`
+- `.agents/docs/codex-harness-engineering/templates/package-assets/rules/agents.md`
+
+## 3. Human-Facing Harness And Package Docs
+
+Canonical source:
+
+- `agent/docs/codex-harness-engineering/*.md`
+
+Typical mirrors:
+
+- `agent/docs/codex-harness-engineering/templates/package-assets/docs/codex-harness-engineering/*.md`
+- `.agents/docs/codex-harness-engineering/templates/package-assets/docs/codex-harness-engineering/*.md`
+- `cli/package-source/docs/codex-harness-engineering/*.md` after syncing CLI package source
+
+Special case:
+
+- `docs/harness/spec-to-ui-to-code-workflow.md` often also feeds:
+  - `agent/docs/harness/spec-to-ui-to-code-workflow.md`
+  - `agent/docs/codex-harness-engineering/spec-to-ui-to-code-workflow.md`
+  - `agent/docs/codex-harness-engineering/templates/docs/spec-to-ui-to-code-workflow.md`
+  - package-assets doc mirrors
+
+## 4. Template Config
+
+Canonical source:
+
+- `agent/docs/codex-harness-engineering/templates/config/*`
+
+Typical mirrors:
+
+- `.agents/docs/codex-harness-engineering/templates/config/*`
+- `cli/package-source/docs/codex-harness-engineering/templates/config/*` after syncing CLI package source
+
+Common targets:
+
+- `codex-config.toml`
+- `codex-readme.md`
+- `codex-agent-roles.md`
+- `global-AGENTS.md`
+- `agents/*.toml`
+
+## 5. Package-Assets Workflows
+
+Canonical source:
+
+- `agent/docs/codex-harness-engineering/templates/package-assets/workflows/*`
+
+Typical mirrors:
+
+- `.agents/docs/codex-harness-engineering/templates/package-assets/workflows/*`
+- `cli/package-source/docs/codex-harness-engineering/templates/package-assets/workflows/*` after syncing CLI package source
+
+## 6. Package-Assets Root Docs
+
+Canonical source:
+
+- `agent/docs/codex-harness-engineering/templates/package-assets/root/*`
+
+Typical mirrors:
+
+- `.agents/docs/codex-harness-engineering/templates/package-assets/root/*`
+- `cli/package-source/docs/codex-harness-engineering/templates/package-assets/root/*` after syncing CLI package source
+
+## 7. Repo Skills
+
+Canonical source for active usage:
+
+- `.agents/skills/<skill-name>/...`
+
+Distribution mirrors:
+
+- `agent/skills/<skill-name>/...`
+- `agent/docs/codex-harness-engineering/templates/package-assets/skills/<skill-name>/...`
+- `.agents/docs/codex-harness-engineering/templates/package-assets/skills/<skill-name>/...`
+
+When a skill is created or updated, refresh the `agent/skills` copy and both package distribution copies before considering the task done.
+
+## 8. CLI Package Source
+
+Canonical source:
+
+- repo root files included by `cli/lib/release/package-source-layout.js`
+
+Required refresh step:
+
+- run `node tools/release/sync-cli-package-source.mjs`
+
+Expected targets:
+
+- `cli/package-source/install-manifest.json`
+- `cli/package-source/tools/install/*`
+- `cli/package-source/docs/codex-harness-engineering/templates/context/*`
+- `cli/package-source/docs/codex-harness-engineering/templates/docs/*`
+- `cli/package-source/docs/codex-harness-engineering/templates/package-assets/*`
+
+If a change is intended to ship through the npm CLI package, updating root templates alone is incomplete until `cli/package-source/` is refreshed.

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/harness-surface-sync/references/stale-patterns.md

@@ -1,65 +1,65 @@
-# Stale Pattern Checklist
-
-These patterns are high-signal starting points for this repo. Do not replace blindly; inspect context first.
-
-## Process And Testing-Left-Shift Signals
-
-- `Tests are OPTIONAL`
-  - Usually stale for implementation-facing harness workflows.
-- `Stage 17 验证回归` or `Stage 17 Verify / Regression` with no mention of `fresh evidence` or `affected tests`
-  - Usually needs the modern Stage 17 wording.
-- `test-matrix + test-data-plan`
-  - Often stale if it omits acceptance examples, traceability, regression plan, or evidence protocol.
-- text implying tests are first defined during verify/regression
-  - Usually conflicts with the current left-shift model.
-
-## Missing Truth Sources
-
-Look for docs that mention requirements, plan, or verification but omit:
-
-- `ACCEPTANCE_EXAMPLES.md`
-- `TRACEABILITY_MATRIX.md`
-- `TEST_DATA_MATRIX.md`
-- `verify-matrix.md`
-
-Common stale surfaces:
-
-- install docs
-- implementation guides
-- package root README/PACKAGE
-- workflow docs
-- planning docs
-- review prompts / review docs
-
-## Task And Workflow Shape Signals
-
-- tasks/workflows missing Requirement IDs
-- tasks/workflows missing an explicit test mapping or evidence line
-- workflows saying tests are optional for executable changes
-- implementation steps that say “write code then add tests later”
-
-## Install / Validation Signals
-
-- install docs that tell users to build a real `task.json` before testing truth sources exist
-- docs that treat `tools/install/env-check.ps1` as the main install gate when the repo now expects `tools/harness/doctor.ps1` + `tools/harness/verify.ps1`
-
-## Role / Profile Signals
-
-- `test-planner` described only as “test matrix”
-- `test-runner` described only as “reports”
-- no mention of acceptance examples, traceability, affected tests, or fresh evidence in config/role docs
-- high-risk user-visible tasks described with no mention of `e2e-plan.md`
-- code-intelligence / impact-analysis wording that does not mention `repo-map.md`, codemap, or equivalent AI navigation entry
-- failure-triage wording that jumps straight to owner without a primary failure class such as test issue / product bug / requirement change / env-data issue / flaky
-
-## Recommended First Scan
-
-Use `rg` against:
-
-- `docs/codex-harness-engineering`
-- `docs/harness`
-- `docs/codex-harness-engineering/templates`
-- `.agents/docs/codex-harness-engineering/templates`
-- `docs/project-flow`
-
-Then open only the hits that appear semantically stale.
+# Stale Pattern Checklist
+
+These patterns are high-signal starting points for this repo. Do not replace blindly; inspect context first.
+
+## Process And Testing-Left-Shift Signals
+
+- `Tests are OPTIONAL`
+  - Usually stale for implementation-facing harness workflows.
+- `Stage 17 验证回归` or `Stage 17 Verify / Regression` with no mention of `fresh evidence` or `affected tests`
+  - Usually needs the modern Stage 17 wording.
+- `test-matrix + test-data-plan`
+  - Often stale if it omits acceptance examples, traceability, regression plan, or evidence protocol.
+- text implying tests are first defined during verify/regression
+  - Usually conflicts with the current left-shift model.
+
+## Missing Truth Sources
+
+Look for docs that mention requirements, plan, or verification but omit:
+
+- `ACCEPTANCE_EXAMPLES.md`
+- `TRACEABILITY_MATRIX.md`
+- `TEST_DATA_MATRIX.md`
+- `verify-matrix.md`
+
+Common stale surfaces:
+
+- install docs
+- implementation guides
+- package root README/PACKAGE
+- workflow docs
+- planning docs
+- review prompts / review docs
+
+## Task And Workflow Shape Signals
+
+- tasks/workflows missing Requirement IDs
+- tasks/workflows missing an explicit test mapping or evidence line
+- workflows saying tests are optional for executable changes
+- implementation steps that say “write code then add tests later”
+
+## Install / Validation Signals
+
+- install docs that tell users to build a real `task.json` before testing truth sources exist
+- docs that treat `tools/install/env-check.ps1` as the main install gate when the repo now expects `tools/harness/doctor.ps1` + `tools/harness/verify.ps1`
+
+## Role / Profile Signals
+
+- `test-planner` described only as “test matrix”
+- `test-runner` described only as “reports”
+- no mention of acceptance examples, traceability, affected tests, or fresh evidence in config/role docs
+- high-risk user-visible tasks described with no mention of `e2e-plan.md`
+- code-intelligence / impact-analysis wording that does not mention `repo-map.md`, codemap, or equivalent AI navigation entry
+- failure-triage wording that jumps straight to owner without a primary failure class such as test issue / product bug / requirement change / env-data issue / flaky
+
+## Recommended First Scan
+
+Use `rg` against:
+
+- `docs/codex-harness-engineering`
+- `docs/harness`
+- `docs/codex-harness-engineering/templates`
+- `.agents/docs/codex-harness-engineering/templates`
+- `docs/project-flow`
+
+Then open only the hits that appear semantically stale.

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/init-autopilot/SKILL.md

@@ -84,21 +84,23 @@ powershell -NoProfile -ExecutionPolicy Bypass -File .\tools/harness/codex-loop.p
 1. 优先执行任务自己的 `test_command`
 2. 若没有 `test_command`，再按项目默认验证方式执行
 3. 验证失败时，禁止标记完成
-4. 代码、`task.json`、`progress.txt` 应尽量放在同一个提交里
-5. 不要回滚与当前任务无关的现有改动
-
-### 测试实践映射防漂移
-
-当任务涉及 `task.json`、`package.json` scripts、`tests/`、`docs/testing/verify-matrix.md`、release gate 或 mock/local/docker/live evidence 边界时，必须先检查并保持测试实践映射：
-
-1. 每个关键 test script 必须有明确 task 归属，不能只有 `package.json` 脚本或只有 release 总门禁。
-2. `task.json` 中相关任务必须写清 `test_command`、需求范围、依赖形态和 evidence 边界。
-3. `docs/testing/verify-matrix.md` 必须有“测试实践到 task 映射”或等价表，列出 test script、task id、需求范围、依赖形态和 evidence 边界。
-4. mock/local rehearsal、docker/mock release、外部 live 验证必须分开描述，不能互相替代。
-5. 如果仓库存在 `tests/mock-local/test-practice-matrix.test.mjs` 或同类守护测试，修改上述文件后必须运行覆盖它的测试命令，例如 `npm run test:mock-local`。
-6. 新增、删除或改名 test script 时，同步更新 task、verify-matrix 和守护测试；否则不得把任务标记为完成。
-
-## 阻塞处理
+4. 代码、`task.json`、`progress.txt` 应尽量放在同一个提交里
+5. 不要回滚与当前任务无关的现有改动
+
+### 测试实践映射防漂移
+
+当任务涉及 `task.json`、`package.json` scripts、`tests/`、`docs/testing/verify-matrix.md`、release gate 或 mock/local/docker/live evidence 边界时，必须先检查并保持测试实践映射：
+
+如果当前仓库是 thin install 项目且 `docs/testing/*` 缺失，先读取 `.codex-harness/state/config.json`，再到 `packageRoot` 下读取对应 testing truth source。
+
+1. 每个关键 test script 必须有明确 task 归属，不能只有 `package.json` 脚本或只有 release 总门禁。
+2. `task.json` 中相关任务必须写清 `test_command`、需求范围、依赖形态和 evidence 边界。
+3. `docs/testing/verify-matrix.md` 必须有“测试实践到 task 映射”或等价表，列出 test script、task id、需求范围、依赖形态和 evidence 边界。
+4. mock/local rehearsal、docker/mock release、外部 live 验证必须分开描述，不能互相替代。
+5. 如果仓库存在 `tests/mock-local/test-practice-matrix.test.mjs` 或同类守护测试，修改上述文件后必须运行覆盖它的测试命令，例如 `npm run test:mock-local`。
+6. 新增、删除或改名 test script 时，同步更新 task、verify-matrix 和守护测试；否则不得把任务标记为完成。
+
+## 阻塞处理
 
 遇到下列情况立即停止自动续跑：
 

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/log-analysis-optimization/SKILL.md

@@ -240,8 +240,8 @@ grep -i "retry" console.log
 
 ---
 
-## 相关 Skills
-
-- `skills/midscene-log-analysis/SKILL.md` - 基础日志分析
-- `skills/midscene-framework/SKILL.md` - 框架开发指南
-- `skills/error-handling/SKILL.md` - 错误处理技巧
+## 相关 Skills
+
+- `skills/midscene-log-analysis/SKILL.md` - 基础日志分析
+- `skills/midscene-framework/SKILL.md` - 框架开发指南
+- `skills/error-handling/SKILL.md` - 错误处理技巧

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/prd-writer-skill/SKILL.md

@@ -38,37 +38,37 @@ description: 撰写产品需求文档(PRD)并生成可交互原型。触发条
 
 使用 [references/prd-template.md](references/prd-template.md) 生成完整 PRD。
 
-### 阶段4：原型生成
-
-本 skill 直接复用同级 [ui-ux-pro-max](../ui-ux-pro-max/SKILL.md) 的脚本和数据，不再维护内嵌副本。
-
-#### Step 1: 生成设计系统
-
-```bash
-python3 ../ui-ux-pro-max/scripts/search.py "<产品类型> <风格>" --design-system -p "项目名"
-```
-
-示例：
-```bash
-python3 ../ui-ux-pro-max/scripts/search.py "travel mobile app" --design-system -p "旅行App"
-python3 ../ui-ux-pro-max/scripts/search.py "SaaS dashboard" --design-system -p "分析平台"
-```
+### 阶段4：原型生成
+
+本 skill 直接复用同级 [ui-ux-pro-max](../ui-ux-pro-max/SKILL.md) 的脚本和数据，不再维护内嵌副本。
+
+#### Step 1: 生成设计系统
+
+```bash
+python3 ../ui-ux-pro-max/scripts/search.py "<产品类型> <风格>" --design-system -p "项目名"
+```
+
+示例：
+```bash
+python3 ../ui-ux-pro-max/scripts/search.py "travel mobile app" --design-system -p "旅行App"
+python3 ../ui-ux-pro-max/scripts/search.py "SaaS dashboard" --design-system -p "分析平台"
+```
 
 #### Step 2: 按需获取详细设计数据
 
-```bash
-# 配色方案
-python3 ../ui-ux-pro-max/scripts/search.py "modern elegant" --domain color
-
-# 字体配对
-python3 ../ui-ux-pro-max/scripts/search.py "professional" --domain typography
-
-# UX 准则
-python3 ../ui-ux-pro-max/scripts/search.py "mobile form" --domain ux
-
-# 技术栈指南
-python3 ../ui-ux-pro-max/scripts/search.py "responsive" --stack html-tailwind
-```
+```bash
+# 配色方案
+python3 ../ui-ux-pro-max/scripts/search.py "modern elegant" --domain color
+
+# 字体配对
+python3 ../ui-ux-pro-max/scripts/search.py "professional" --domain typography
+
+# UX 准则
+python3 ../ui-ux-pro-max/scripts/search.py "mobile form" --domain ux
+
+# 技术栈指南
+python3 ../ui-ux-pro-max/scripts/search.py "responsive" --stack html-tailwind
+```
 
 可用 domain: `style`, `color`, `typography`, `ux`, `product`, `landing`, `chart`
 可用 stack: `html-tailwind`, `react`, `nextjs`, `vue`, `svelte`, `shadcn`, `swiftui`, `react-native`, `flutter`

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/qa-e2e-planner/SKILL.md

@@ -15,17 +15,17 @@ description: 专门扫描前端工程，生成零幻觉、元素级的端到端
 
 严格按照 **"扫描 -> 计划 -> 审核 -> 生成任务"** 的顺序执行，不得越级跳步：
 
-1. **深度扫描组件 (Mock & DOM 提取)**
-   - 若项目存在 `docs/ai/repo-map.md`、`docs/context/repo-map.md` 或同类 codemap，先阅读导航文件定位前端入口、路由、状态源和测试相关目录，再进入具体组件；禁止上来就全仓盲扫。
-   - 必须通过底层文件 API (`find_by_name` / `list_dir` / `view_file`) 全面读取当前正在开发或测试的 Vue/React 视图组件文件。
-   - 提取 `<template>` 中所有的交互式控件，例如：`<button>`、`<input>`、`<select>` 等。
-   - 通过 `grep_search` 或深度读取，检索代码中 `mock`、`MockStateWrapper` 等硬编码虚拟数据的痕迹。
-
-2. **导出标准化测试大纲 (e2e-plan.md)**
-   - 根据收集到的待测点与排雷点，调用模板 `.agents/.specify/templates/e2e-plan-template.md`。
-   - 分章节输出：**代码入口与影响面**、**Mock 排雷清单**、**各页面元素级断言**（即测试用例）、**CRUD 闭环业务流**。
-   - ⚠️ **输出路径强制规范**：必须使用 `write_to_file` 将文件写入**项目根目录**（即与 `frontend/`、`backend/` 同级），路径为 `<项目根路径>/e2e-plan.md`。**绝对禁止**将此文件写入 artifact 目录（`~/.gemini/...`）。
-   - **注意**：大纲生成完毕后必须立即挂起操作。
+1. **深度扫描组件 (Mock & DOM 提取)**
+   - 若项目存在 `docs/ai/repo-map.md`、`docs/context/repo-map.md` 或同类 codemap，先阅读导航文件定位前端入口、路由、状态源和测试相关目录，再进入具体组件；禁止上来就全仓盲扫。
+   - 必须通过底层文件 API (`find_by_name` / `list_dir` / `view_file`) 全面读取当前正在开发或测试的 Vue/React 视图组件文件。
+   - 提取 `<template>` 中所有的交互式控件，例如：`<button>`、`<input>`、`<select>` 等。
+   - 通过 `grep_search` 或深度读取，检索代码中 `mock`、`MockStateWrapper` 等硬编码虚拟数据的痕迹。
+
+2. **导出标准化测试大纲 (e2e-plan.md)**
+   - 根据收集到的待测点与排雷点，调用模板 `.agents/.specify/templates/e2e-plan-template.md`。
+   - 分章节输出：**代码入口与影响面**、**Mock 排雷清单**、**各页面元素级断言**（即测试用例）、**CRUD 闭环业务流**。
+   - ⚠️ **输出路径强制规范**：必须使用 `write_to_file` 将文件写入**项目根目录**（即与 `frontend/`、`backend/` 同级），路径为 `<项目根路径>/e2e-plan.md`。**绝对禁止**将此文件写入 artifact 目录（`~/.gemini/...`）。
+   - **注意**：大纲生成完毕后必须立即挂起操作。
 
 3. **🚧 强制人工Review拦截点 (Mandatory User Review) 🚧**
    - 此时**严禁直接生成 Tasks 或去执行**。

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/qa-e2e-runner/SKILL.md

@@ -13,15 +13,15 @@ description: 根据 e2e-plan.md 纯粹地唤起并调度 browser_subagent 进行
 
 ## 工作流 (Workflow)
 
-1. **装载测试计划**
-   - 若项目存在 `docs/ai/repo-map.md`、`docs/context/repo-map.md` 或同类 codemap，先读取导航文件确认页面入口、路由、状态源和关联测试目录，再切入 `e2e-plan.md`。
-   - 解读 `e2e-plan.md` 中的所有元素和交互基准，特别是 **代码入口与影响面**、**10 维度断言** 和 **CRUD 全生命周期测试流水线**。
+1. **装载测试计划**
+   - 若项目存在 `docs/ai/repo-map.md`、`docs/context/repo-map.md` 或同类 codemap，先读取导航文件确认页面入口、路由、状态源和关联测试目录，再切入 `e2e-plan.md`。
+   - 解读 `e2e-plan.md` 中的所有元素和交互基准，特别是 **代码入口与影响面**、**10 维度断言** 和 **CRUD 全生命周期测试流水线**。
 
 2. **执行自动化测试闭环**
    - 唤起执行测试的主程序 (通过 `browser_subagent` 或者关联测试框架驱动如 Playwright/Cypress，取决于本地支持)。
    - 按章节逐页面点击所有的 `<button>`，输入各类异常、边界值至 `<input>` 表单中。
    - 执行生命周期流程：让测试机器人走完从创建 (Create)、查看 (Read)、更新 (Update) 至终结删除 (Delete) 闭环。
 
-3. **收录与报告输出**
-   - 构建 `qa-e2e-report.md` 测试报告文件，对比原计划中的每一个勾选项标记 Pass 或是 Fail。
-   - 如果发生阻断错误（Fail），先按 `TEST_CODE_ISSUE / PRODUCT_BUG / REQUIREMENT_CHANGE / ENV_OR_DATA_ISSUE / FLAKY` 做一级分类，再提供详尽的终端输出日志摘录或页面元素截图证据供研发人员回溯修复。
+3. **收录与报告输出**
+   - 构建 `qa-e2e-report.md` 测试报告文件，对比原计划中的每一个勾选项标记 Pass 或是 Fail。
+   - 如果发生阻断错误（Fail），先按 `TEST_CODE_ISSUE / PRODUCT_BUG / REQUIREMENT_CHANGE / ENV_OR_DATA_ISSUE / FLAKY` 做一级分类，再提供详尽的终端输出日志摘录或页面元素截图证据供研发人员回溯修复。

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/qa-mock-cleaner/SKILL.md

@@ -13,10 +13,10 @@ description: 专门依据 e2e-plan.md 执行前端 Mock 数据依赖的扫除行
 
 ## 工作流 (Workflow)
 
-1. **获取排雷计划**
-   - 若项目存在 `docs/ai/repo-map.md`、`docs/context/repo-map.md` 或同类 codemap，先读取导航文件定位页面入口、Mock 所在目录和真实接口边界。
-   - 读取目标路径中的 `e2e-plan.md` 文件的 "代码入口与影响面"、"Mock 依赖排雷清单" 章节。
-   - 精准定位被指出的那些 `.vue` 页面文件或 `src/mock/` 目录下的拦截文件。
+1. **获取排雷计划**
+   - 若项目存在 `docs/ai/repo-map.md`、`docs/context/repo-map.md` 或同类 codemap，先读取导航文件定位页面入口、Mock 所在目录和真实接口边界。
+   - 读取目标路径中的 `e2e-plan.md` 文件的 "代码入口与影响面"、"Mock 依赖排雷清单" 章节。
+   - 精准定位被指出的那些 `.vue` 页面文件或 `src/mock/` 目录下的拦截文件。
 
 2. **精细化剥离与真实接口替换**
    - 针对文件内的 `<MockStateWrapper>` 进行剥离，改为通过 axios 或 Vue store 调用真实后端接口的错误/加载捕获机制。