Skill-BidCreater/references/outline-stage.md

目录阶段规则

目标

目录阶段先产出一份完整 canonical outline 用于门禁检查，再拆成两份正式目录：

• work/final_outline_technical.json
• work/final_outline_business_other.json

若未通过定稿门禁，则停止目录输出，不生成任何正式双目录，也不生成目录 Word。

目录总门禁 (Outline Master Gates)

1. 如果该 AI 支持子代理功能，则必须创建子代理来生成 canonical outline 或其技术投影视图。 2. 主代理必须充当质检员。主代理在接收到子代理的目录后，必须执行叶子节点合法性检查。 3. 一票否决权：只要发现技术目录停留在“方案”“概述”等二级节点，未下钻到具体的“原则、架构、内容、模块、流程”，主代理必须将其打回，要求子代理重写，绝不允许放行。 4. 被否决重新修改目录结构时，坚决杜绝为了通过检验而做的适配修改，必须生成符合本 skill 要求、适配招标文件的专业目录结构。 5. 门禁检查对象是 canonical outline 或 `final_outline_technical.json`，不是商务及其他中的技术占位目录。

最小流程

1. 根据读取到的 rfp/ 主文档和当前项目候选材料，建立评分点、风险点、证据点和正式交付边界，形成 canonical outline 骨架。
2. 继续下钻到当前证据支持的最深安全层级。
3. 子代或主代理生成 canonical outline 后，主代理运行 scripts/outline_linter.py 检查。
4. 若有 ERROR：把报告，尤其是 [ERROR][code] 路径 | breadcrumb | message 原样发回子代理，让它只修目录，不写正文，并重试。
5. 直到 linter 通过，再用 write-large-json 落盘：
   • work/final_outline_technical.json
   • work/final_outline_business_other.json
6. 再分别执行 render-outline --bundle technical 和 render-outline --bundle business-other。

拆分规则

1. 技术标目录保留完整技术展开结构，不得压缩成占位。
2. 商务及其他目录保留 business/other 目录，并在技术内容应出现的位置保留技术占位。
3. 若招标文件明确规定分册、分标或顺序，技术占位必须出现在原规定位置。
4. 若招标文件未明确规定位置，则默认在 unified/canonical outline 中技术部分入口位置保留一个一级占位章节。
5. 商务及其他中的技术占位节点必须满足：
   • workflow_bucket=other
   • 稳定占位 ID
   • 可渲染为目录与正文中的转引说明
6. 商务及其他中的技术占位不能成为技术门禁放行依据。

抽象标题处理与下钻强制约束（核心规则）

以下标题列为默认非法终点，绝对禁止作为技术标叶子节点直接写正文： [技术方案, 服务方案, 实施方案, 服务保障及措施, 售后服务和质保期服务计划, 项目理解, 解决方案, 系统设计, 平台建设方案, 系统建设方案, 总体方案, 培训方案, 运维方案]

当遇到上述标题时，必须强制下钻。下钻不能是单一的，不能只有一个子标题，必须形成完整的结构化切面。 必须包含但不限于以下维度的同级子标题：

• 原则与目标
• 架构与设计
• 模块与内容
• 流程与机制
• 计划与验收
• 保障与风控

错误示例（严禁此类浅层结构，发现即打回）：

5. 技术方案 5.1 方案概述 5.2 实施方案 5.3 售后服务

正确示例（技术标必须模仿此颗粒度与深度继续下钻）：

5. 技术方案 5.1 总体设计方案 5.1.1 总体设计原则（安全性、扩展性、规范性等） 5.1.2 总体架构设计（分层架构图解） 5.1.3 关键技术路线选型 5.2 核心系统建设内容（下钻到具体模块） 5.2.1 数据中心模块功能实现 5.2.2 接口与数据流向设计 5.3 实施与交付计划 5.3.1 实施阶段划分与里程碑 5.3.2 资源配置与人员安排 5.4 技术难点分析与应对预案

商务及其他中的技术占位不适用上述“继续下钻”要求，但只能是占位，不得承载技术正文。

强制自检清单 (Pre-Output Checklist)

在物理生成双正式目录之前，AI 或主代理必须在对话框中输出以下自我检查单，所有项为“是”才可调用写入工具：

【目录深度强制自检】
1. 是否存在直接以“技术方案”或“实施方案”作为叶子节点的章节？(要求：否)
2. 技术类章节是否已经下钻到第三级或第四级？(要求：是)
3. 技术方案下，是否同时包含了[原则]、[架构]、[内容/模块]？(要求：是)
4. 所有的评分点是否都已在目录中体现？(要求：是)
5. 双目录是否都已从同一 canonical outline 拆分，并保持稳定节点 ID？(要求：是)
6. 商务及其他中的技术节点是否只保留占位，不承载技术正文？(要求：是)

定稿门禁

正式双目录必须同时满足：

1. canonical outline 中评分点、风险点、证据点都有承载位。
2. 技术标中的抽象标题已下钻，直到能承载正文为止。
3. 商务及其他中的技术部分只保留占位，位置正确。
4. 显式章节、附表、附件承载位没有被无故遗漏。
5. 标题层级、编号、归属关系合法，防止自动或手动编号混淆。
6. 每个最终目录叶子节点都已标注 workflow_bucket。
7. 不得用“目录已经想好”或“逻辑上已定稿”代替文件存在检查。