test-designlisted

# 测试用例设计 为 `$target` 下的 `$module` 模块，或某个 L2 需求 suite 生成 Markdown 测试用例。 输出目录：`$suite_dir`。优先使用 `test_workspace/suites/{target}/{suite}/` 或用户指定的任意 suite 目录，并在后续 `test-scaffold` / `test-codegen` 中由 `suite.yaml` 绑定 target/module。 ## 前置：读取项目配置 优先读 `aitest_config/aitest.yaml`，获取： - `workspace.paths.*` — 知识库、用例、suite、文档等目录路径 - `targets.registry` / `modules.registry` — 已登记 target/module 的位置 - `codegen.*` — 模块缩写、断言规则、默认请求字段等 codegen 约束 读取 `aitest_config/aitest.yaml` 获取 workspace 路径、codegen 默认规则和 target/module registry 配置。 读取 `test_workspace/targets/{target}/target.yaml`（存在时），获取公开接口、route/schema 搜索模式、默认 generated/reports 目录等 target 级信息。 ## 执行流程 ### 第一步：读取规范和上下文 1. 读 `{paths.test_spec}`（TEST_SPEC），建立： - 编号规则和模块缩写对照表 - 优先级定义（P0/P1/P2） - 质量红线（Q1-Q10） - 排除场景列表（生成时跳过） - 关注场景列表（生成时必须覆盖） - 已知陷阱列表（生成时逐条自检，避免重犯已知错误模式） **硬约束**：在模块缩写对照表中查找 `$module` 对应的缩写。如果该模块未在表中登记，**停止执行**，提示用户先在 TEST_SPEC 的"模块缩写对照表"中补登记，避免编号冲突。同一 workspace 存在多个 target 时，仍以 `$target/$module` 作为定位范围。 2. 读 `{paths.l0_architecture}`（L0），从模块索引表中找到 `$module` 对应的： - L1 文档路径 - 关联的 L2 文档路径 3. 读目标 L1 文档，提取： - 输入/输出定义（请求体结构、字段、类型）— 作为用例"输入"字段的结构基准 - 如果 L1 或 L0 链接了 proto/OpenAPI 文件，读取该文件获取完整的请求/响应字段定义 - 业务规则（逐条编号） - 错误场景 - 可观测状态 - "已有测试覆盖"章节（已覆盖/未覆盖维度） 4. 读关联 L2 文档，提取： - 新增/变更规则 - 测试重点 - "已有测试覆盖"章节 5. 搜索已有用例，确定编号起点： - 新结构优先搜索已指定 suite 目录、`test_workspace/suites/` 中绑定该 module 的 suite，以及 `aitest.yaml.workspace.paths.suites_dir` - 找到该模块缩写的最大 TC 序号，新用例从 +1 开始 6. 读 `ait