chore(test): Feishu report readability + skill audit + CI hardening

.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "TapTap 插件库 - 面向 AI 开发工具的工作流自动化插件集",
-    "version": "0.1.40",
+    "version": "0.1.41",
     "pluginRoot": "./plugins"
   },
   "plugins": [
@@ -50,7 +50,7 @@
       "name": "test",
       "source": "./plugins/test",
       "description": "QA 工作流插件，提供需求评审与澄清、测试用例生成（含冗余对评审）、用例评审、变更分析、代码级测试生成（单元/集成）、需求回溯（含冒烟测试模式）、Bug 修复分析等 QA 全流程 Skill",
-      "version": "0.0.8",
+      "version": "0.0.9",
       "author": {
         "name": "TapTap AI Team"
       },

CHANGELOG.md

@@ -1,5 +1,60 @@
 # Changelog
 
+## 0.1.41
+
+### Test Plugin (0.0.9)
+
+**requirement-review**
+
+- Optimized 10 readability issues in Feishu reports based on real samples; rebuilt `TEMPLATES.md` for `report.md`
+- Fixed 5 Feishu docx import compatibility issues + 4 structural issues (TOC, section numbering, intent table, chat output) after live import testing
+- Fixed `rr_summary.json` writing illegal `review_mode` values like `single_agent_serial` (schema enum is now enforced)
+
+**test-case-review**
+
+- Added `TEMPLATES.md` (8-section strict template for `review_summary.md`); previously had no report template
+- Added §0 case-readiness verdict and §6 fix to-dos grouped by case ID (bold ID + `· ` prefix to preserve hierarchy after Feishu flattens nested bullets)
+
+**change-analysis**
+
+- Added `TEMPLATES.md` constraining multi-doc Feishu output (`code_change_analysis.md` + `test_coverage_report.md`); introduced bidirectional cross-references and per-line `[实证]/[推测]` confidence tagging
+
+**requirement-traceability**
+
+- Added smoke-test mode `report.md` template (6 sections); previously PHASES 5S.2 only constrained JSON output, no markdown template
+- Added §0 overall confidence summary + §2 numerator/denominator titles + §3.2 explicit untraced changes
+- Fixed broken anchor `#coverage_reportjson` → `#traceability_coverage_reportjson` in PHASES.md
+
+**Skill audit phase 1-3 follow-ups (8-dimension cross-skill review)**
+
+- Bound `testcase.schema.json` on 5 `*_cases.json` output declarations across `test-case-generation` / `test-case-review` / `change-analysis` `contract.yaml` (was implicit via CONVENTIONS.md inheritance; now machine-checkable)
+- Added demand-driven vs change-driven gating in `test-case-generation` and `change-analysis` SKILL descriptions + reverse SKIP cross-references between `change-analysis` and `requirement-traceability`
+- Marked `review_result.json` as LLM-friendly non-strict JSON in `test-case-review/SKILL.md` (verdict object, not `TestCaseList`; deliberately not schema-bound)
+- Synced `testcase.schema.json` from ai-case Pydantic source: `Step.expected` is now required (allows empty string); previously had `default=''` so callers could omit it. MCP tool input_schema auto-reflects this constraint at LLM tool-call time
+- Relaxed `test_method` from required to optional in `CONVENTIONS.md` to match Pydantic (which was already Optional; documentation was lagging) — supplementary case producers may omit it
+- Cross-referenced `contracts/known-collisions.yaml` from `requirement-traceability/PHASES.md` Phase 6 and `PIPELINES.md` to clarify that trace Phase 6 writeback and `metersphere-sync mode=execute` share the same `metersphere_helper.py writeback-from-fv` helper as two coexisting entry points (auto vs manual mode), not duplicate implementations
+- Added `re_entry_phase` + `requirement_change_summary` optional inputs to `qa-workflow` for "rerun after requirement change" scenarios, passthrough to `test-case-generation`
+- Updated README selection guide to surface the demand-driven (tcg) vs change-driven (ca) split; dropped stale "v0.0.10+" version gates from architecture features section
+- Added quickstart note in `requirement-clarification/SKILL.md` clarifying that `output/*.json` files are pre-shipped format samples, not runtime artifacts
+- Added inline annotation in `agents/` tree (README + `_shared/AGENT_PROTOCOL.md`) explaining why files in `plugins/test/agents/` are not auto-registered as Claude/Codex subagents (no YAML frontmatter; loaded explicitly via Task tool calls inside skills)
+
+**Test plugin audit + CI hardening**
+
+- Extended `tests/validate.sh` from 5 to 9 check categories: SKILL frontmatter ↔ directory, handoffs targets, subagent_type targets, references/ paths, contract.yaml cross-skill consistency
+- Resolved 8 contract output collisions: renamed `risk_assessment.json` → `bug_risk_assessment.json` (change-analysis), split `test_execution_report.json` → `unit_/integration_test_execution_report.json`, split `supplementary_cases.json` → `change_/review_supplementary_cases.json` (canonical kept by test-case-generation)
+- Added `contracts/known-collisions.yaml` whitelist with self-binding "review protocol" rule
+- Removed 3 zombie agents (`forward-tracer`, `reverse-tracer`, `failure-classifier`) and cleaned up 13 dead references across SKILL/PHASES/TEMPLATES/protocol files
+- Honest dependencies: `shared-tools/requirements.txt` now lists actual deps (pycryptodome, pyyaml, jsonschema, python-dotenv, aiohttp); new `feedback/requirements.txt` declares aiohttp; `feedback/contract.yaml` env_vars now match scripts (`FEISHU_PLUGIN_ID/SECRET/USER_KEY`)
+- Standardized `-h/--help` UX across 5 shared helper scripts (previously `--help` was sent as a network query in `search_mrs.py`)
+- Extracted `integration-test-design` 5-phase content into standalone `PHASES.md` (SKILL.md trimmed 387 → 252 lines, aligned with unit-test-design style)
+- Schema validation expanded from 1 to 5 schemas (testcase / ca-summary / defect-list / rr-summary / smoke-test-report) with ~30 negative cases
+- Synced stale filename references across PIPELINES.md (8), README.md (7), test-case-review/TEMPLATES.md (2), change-analysis/TEMPLATES.md (2), change-analysis/contract.yaml (1) following the contract renames above
+
+### Marketplace
+
+- Bumped version from 0.1.40 to 0.1.41
+- Updated test plugin to version 0.0.9
+
 ## 0.1.40
 
 ### Test Plugin (0.0.8)

README.en.md

@@ -85,7 +85,7 @@ One-click configuration for MCP, auto-update, and development environment templa
 | spec    | 0.1.8   | Spec-Driven Development workflow plugin                                                              |
 | git     | 0.1.16  | Git workflow automation plugin (commit/push/MR + dual-mode code review + remote platform ops)        |
 | sync    | 0.1.30  | Dev environment config sync plugin (MCP + LSP + Hooks + Claude Skills)                               |
-| test    | 0.0.8   | QA workflow plugin (requirement clarification/test case generation/change analysis/traceability/code-level test generation) |
+| test    | 0.0.9   | QA workflow plugin (requirement clarification/test case generation/change analysis/traceability/code-level test generation) |
 
 
 See the README.md in each plugin directory for detailed documentation.

README.md

@@ -85,7 +85,7 @@ mkdir -p .claude && echo '{
 | spec    | 0.1.8 | Spec-Driven Development 工作流插件                                     |
 | git     | 0.1.16 | Git 工作流自动化插件（提交/推送/MR + 自动代码审查 + 远程平台操作）            |
 | sync    | 0.1.30 | 开发环境配置同步插件（MCP + LSP + Hooks + Claude Skills） |
-| test    | 0.0.8 | QA 工作流插件（需求澄清/测试用例生成/变更分析/需求回溯/代码级测试生成） |
+| test    | 0.0.9 | QA 工作流插件（需求澄清/测试用例生成/变更分析/需求回溯/代码级测试生成） |
 
 
 详细说明请查看各插件目录下的 README.md。

plugins/test/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "test",
   "description": "QA 工作流插件，提供需求评审与澄清、测试用例生成（含冗余对评审）、用例评审、变更分析、代码级测试生成（单元/集成）、需求回溯（含冒烟测试模式）、Bug 修复分析等 QA 全流程 Skill",
-  "version": "0.0.8",
+  "version": "0.0.9",
   "author": {
     "name": "TapTap AI Team"
   }

plugins/test/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "test",
-  "version": "0.0.8",
+  "version": "0.0.9",
   "description": "QA 工作流插件，提供需求评审与澄清、测试用例生成（含冗余对评审）、用例评审、变更分析、代码级测试生成（单元/集成）、需求回溯（含冒烟测试模式）、Bug 修复分析等 QA 全流程 Skill",
   "author": {
     "name": "TapTap AI Team"

plugins/test/AI_CODING_BEST_PRACTICES.md

@@ -3,6 +3,9 @@
 > 借助 `claude-plugins-marketplace` 的 test 插件进行需求开发和测试验证的标准方法。
 >
 > 本文档聚焦**怎么把 test 插件用起来**，不复述各 skill 的内部机制 — 那些请直接参考 skill 的 `SKILL.md`。
+>
+> **受众**：使用 test 插件做完整需求开发的工程师 / Tech Owner。
+> **不是**：skill 运行的强制依赖文件 — 删除本文不影响任何 skill 执行（仅 README 引用过）。
 
 ## 谁该读这份文档
 

plugins/test/CONTRACT_SPEC.md

@@ -2,6 +2,9 @@
 
 本文件定义 test 插件中 `contract.yaml` 的结构和编写规则。每个 skill 目录下必须包含一个 `contract.yaml`，声明该 skill 的输入输出接口，供编排层和开发者使用。
 
+> **受众**：新增 / 修改 skill 的开发者；contract.yaml 一致性自动校验工具（`shared-tools/scripts/validate_contracts.py`，由 `tests/validate.sh` Check 14 在 CI 强制执行）的依据。
+> 撞名输出（多个 skill 声明同名文件）会被 Check 14 直接 fail；设计认可的"primary + fallback"或"共享 helper"模式可加入 [contracts/known-collisions.yaml](contracts/known-collisions.yaml) 白名单，须附 `reason` + `enforcement` 说明。
+
 ## 与 SKILL.md 的关系
 
 - `SKILL.md` 是给 AI Agent 读的执行指令，描述分析逻辑和工具调用方式

plugins/test/CONVENTIONS.md

@@ -462,13 +462,13 @@ requirement-clarification → clarified_requirements.json (functional_point.conf
 
 | Skill | 前缀 | 用途 |
 | --- | --- | --- |
-| requirement-clarification | `FP-1` / `FP-2` ... | 功能点编号 |
-| test-case-generation (review 阶段) | `RP-1` / `RP-2` ... | 需求验证点编号 |
+| requirement-clarification | `FP-1` / `FP-2` ... | 功能点编号（澄清阶段产出，主键） |
+| test-case-generation / test-case-review（understand 阶段，无上游时 fallback） | `RP-1` / `RP-2` ... | 需求验证点编号 |
 | requirement-traceability | `R-1` / `R-2` ... | 需求点编号（对照代码变更） |
 
 三套编号是同一批需求在不同 skill 作用域下的**独立编号**，不要求一一对应。它们描述的是同一份需求的不同视角：
 - `FP-` 是澄清阶段识别的功能点（可能粒度较粗）
-- `RP-` 是评审阶段从需求文档中提炼的验证点（可能更细）
+- `RP-` 是用例生成 / 评审阶段从需求文档自行提炼的验证点（仅当无上游 `requirement_points.json` 时才产出）
 - `R-` 是追溯阶段从需求中提取的映射锚点（有上游 FP- 时直接继承作为主键，R- 作为别名）
 
 > v0.0.7 起合并 verification-test-generation：traceability 直接消费 `final_cases.json`（`case_id` 形如 `M1-TC-01`），不再独立生成 `VC-` 编号的中间用例。
@@ -507,7 +507,7 @@ requirement-clarification → clarified_requirements.json (functional_point.conf
 | `title` | string | 是 | 用例标题，纯业务描述。禁止包含：内部编号、优先级前缀（P0/P1/P2/P3）、测试方法或分类前缀（如「等价类-有效类：」「等价类-无效类：」「场景法：」等）、来源前缀（如「[补充]」「【补充】」「[新增]」等）。这些信息已由 `priority`、`test_method` 和 `source` 字段承载 |
 | `module` | string | 是 | 模块名称（不带编号前缀） |
 | `priority` | string | 是 | P0 / P1 / P2 / P3 |
-| `test_method` | string | 是 | 等价类划分 / 边界值分析 / 场景法 / 错误推测法 / 判定表法 / 状态迁移法 / 探索性测试法 |
+| `test_method` | string | 否 | 等价类划分 / 边界值分析 / 场景法 / 错误推测法 / 判定表法 / 状态迁移法 / 探索性测试法。test-case-generation 必填；test-case-review、change-analysis 输出 supplementary cases 时可缺省 |
 | `confidence` | number | 否 | 用例置信度（0-100），评分标准见「量化置信度评分」。test-case-generation 阶段生成 |
 | `review_confidence` | number | 否 | 评审置信度（0-100），test-case-generation review 阶段冗余对评审后生成 |
 | `source` | string | 否 | 用例来源：`generated`（生成阶段产出）/ `supplementary`（评审补充）。test-case-generation output 阶段标记 |

plugins/test/PIPELINES.md

@@ -4,6 +4,9 @@
 
 概要描述见 [README.md](README.md#快速开始)。
 
+> **受众**：实现编排层 / pipeline 的开发者。
+> **不是**：skill 运行的强制依赖文件 — 各 skill 的 `contract.yaml` 已是机器可读的接口定义，本文是给人读的跨 skill 链路全景图。
+
 ## 链路 A — 功能测试全流程
 
 ```
@@ -56,6 +59,8 @@
     └─→ ms_sync_report.json (含执行回写统计)
 ```
 
+> **与 trace Phase 6 writeback 的关系**：上图描述的是手动模式调用入口；自动模式（qa-workflow）下 writeback 由 `requirement-traceability` 内部 Phase 6 触发，不显式调 `metersphere-sync mode=execute`。两入口共享同一 helper，互斥执行。共享/互斥规则详见 [`contracts/known-collisions.yaml`](contracts/known-collisions.yaml) 的 `forward_verification.enriched.json` 条目。
+
 ### 数据流映射
 
 | 上游 Skill | 输出文件 | 下游 Skill | 输入参数 |
@@ -120,11 +125,11 @@
 ```
 [unit-test-design / integration-test-design]
     │
-    └─→ test_execution_report.json (verify 阶段产出)
+    └─→ unit_test_execution_report.json / integration_test_execution_report.json (verify 阶段产出)
         │
         ▼
 [test-failure-analyzer]
-    │  消费: test_execution_report.json + 代码 diff
+    │  消费: unit_test_execution_report.json / integration_test_execution_report.json + 代码 diff
     │
     ├─→ failure_analysis.json
     └─→ action_plan.md
@@ -136,8 +141,8 @@
 
 | 上游 Skill | 输出文件 | 下游 Skill | 输入参数 |
 |---|---|---|---|
-| unit-test-design | `test_execution_report.json` | test-failure-analyzer | `test_report` |
-| integration-test-design | `test_execution_report.json` | test-failure-analyzer | `test_report` |
+| unit-test-design | `unit_test_execution_report.json` | test-failure-analyzer | `test_report` |
+| integration-test-design | `integration_test_execution_report.json` | test-failure-analyzer | `test_report` |
 
 ---
 
@@ -152,7 +157,7 @@ Story 场景:
     ├─→ change_analysis.json
     ├─→ code_change_analysis.md
     ├─→ change_coverage_report.json
-    └─→ supplementary_cases.json (可选)
+    └─→ change_supplementary_cases.json (可选)
 
 Bug 场景:
 [change-analysis]
@@ -161,7 +166,7 @@ Bug 场景:
     ├─→ change_analysis.json
     ├─→ code_change_analysis.md
     ├─→ change_fix_analysis.json
-    └─→ risk_assessment.json
+    └─→ bug_risk_assessment.json
 ```
 
 ### 可选上游
@@ -171,7 +176,7 @@ Bug 场景:
 | requirement-clarification | `clarified_requirements.json` | change-analysis | `clarified_requirements` |
 | requirement-clarification | `requirement_points.json` | change-analysis | `requirement_points` |
 | test-case-generation | `final_cases.json` | change-analysis | `existing_test_cases` |
-| test-case-review | `supplementary_cases.json` | change-analysis | `existing_test_cases` |
+| test-case-review | `review_supplementary_cases.json` | change-analysis | `existing_test_cases` |
 
 ---
 
@@ -184,7 +189,7 @@ Bug 场景:
     │
     ├─→ review_result.json
     ├─→ tc_review_detail.md
-    └─→ supplementary_cases.json (可选)
+    └─→ review_supplementary_cases.json (可选)
 ```
 
 ---
@@ -246,12 +251,15 @@ work_dir/
 ├── traceability_matrix.json       (requirement-traceability)
 ├── traceability_coverage_report.json  (requirement-traceability)
 ├── forward_verification.json      (requirement-traceability)
-├── risk_assessment.json           (requirement-traceability / change-analysis Bug)
+├── risk_assessment.json           (requirement-traceability)
+├── bug_risk_assessment.json       (change-analysis Bug)
 ├── change_analysis.json           (change-analysis)
 ├── code_change_analysis.md        (change-analysis, 中间文件)
 ├── change_coverage_report.json    (change-analysis Story)
 ├── change_fix_analysis.json       (change-analysis Bug)
-├── supplementary_cases.json       (change-analysis / test-case-review)
+├── supplementary_cases.json       (test-case-generation, canonical)
+├── change_supplementary_cases.json (change-analysis)
+├── review_supplementary_cases.json (test-case-review)
 ├── review_result.json             (test-case-review)
 ├── tc_review_detail.md            (test-case-review)
 ├── api_contract_report.json       (api-contract-validation)