test-caselisted

# Outcome 建立或更新可追溯的需求、测试点和 YAML 用例权威，只通过 `kata cases build` 生成派生格式。 ## Routing - 新需求、PRD、设计稿、截图或功能描述：执行 [workflows/create.md](workflows/create.md)。 - 既有 YAML 或 CSV、XLSX、Markdown、XMind、标题同步、格式标准化：执行 [workflows/update.md](workflows/update.md)。 - 只给 feature 目录并要求生成、修复或验证 UI 自动化：转 `ui-automation`。 - ZenTao Bug ID/URL 的 hotfix 回归报告：转 `defect-analyze`；需要正式 YAML 回归用例时返回本 Skill。 ## Steps 1. 查明事实 - 读取需求源、用户指定 feature、已有 `prd/prd.md`、`cases/test-points.md`、`cases/需求名.yaml` 及相关知识和 CLI 状态。 - 不向用户询问可从需求源、路径、CLI 或已有文件查明的事实。 - 完成条件：项目和 `<项目>:<版本目录>/<需求目录名>` 唯一，create/update 分支和证据缺口明确。 2. 确认关键决策 - 只询问需求语义、覆盖取舍、最终发布或不可恢复删除等无法从证据确定且会改变结果的决策。 - 无业务证据的步骤保持待确认，不把历史用例或当前 UI 猜成需求事实。 - 完成条件：PRD、测试点、YAML 权威链的变更范围和排除项明确。 3. 执行 - **写 YAML 前解析客户身份并注入知识与规范**： - 从需求标题/VCS 分支/feature 目录名识别客户编号(如 `ltqc`/`lzlj`/`zszq`)： - **高置信度**(需求标题含明确客户中文名、分支名含客户码、feature 目录含客户名) → 自行确认客户编号，不过问用户 - **低置信度**(标品、不确定所属客户、多客户共享) → 向用户确认客户编号，**确认前先基于知识库/源码验证并给出推荐答案** - 列出可用客户：`kata knowledge list --project <项目>` - 加载用例公共规范与客户专属规范： ```bash kata knowledge read --project <项目> --type standard --customer <客户编号> ``` （`--customer default` 只读公共基线；具体 code 读公共 + 客户专属） - 加载项目业务知识：`kata knowledge read --project <项目> --module <模块>` - 无客户专属文件或文件落后时，**必须按此分支补齐再写用例**： 1) `customers/<code>.md` 缺环境地址或源码分支 → 向用户索要测试环境地址与源码仓库/分支 2) `kata repos prepare --project <项目> --module <模块> --customer <客户>` 拉取源码；对测试环境做 DOM 探测 3) 按 [templates/st