CSF

FLDD 主题包 — 创建指南

版本: v1.0 | 最后修订: 2026-07-07 | 项目: csf-core 🛡️ 规则语义变更须经Owner确认并全程记入日志。 给谁看：参谋长（创建主题包时参考） 什么时候读：FLDD TP 立项阶段，准备撰写主题包三件套时

---

概述

在 FLDD 中的位置：你正在创建的是一个 BT（Business Topic，业务主题）——FLDD 五概念体系的第一层。1 个主题包 = 1 个 BT，在 HQPD（参谋计划与设计）阶段产出，是所有下游工作的锚点。进入 FLDD 执行阶段后，参谋长将主题包拆分为 IT（迭代任务）→ DT（开发任务）→ STB（会话任务书），最终交付开发者。完整管线见 FLDD-开发执行.md。

主题包 = FLDD 中开发者消费的设计契约单元。每个主题包包含三个文件：

文件	角色	读者
package.md	设计契约 — 开发者实现所需的全部设计信息	开发者（主要）+ 参谋长（维护）
sources.md	出处对账 — 每条断言到上游 spec/arch 的可追溯映射	参谋长（审计）+ 开发者（验证）
verify.md	验收记录 — 本包的质量检查过程与结论	参谋长 + Owner

---

§1 package.md — 设计契约

必需章节

章节	内容	说明
frontmatter	主题包名、拓扑层（L0-L3，见项目架构文档）、象限（A/B/C/D，见项目架构文档）、创建日期、维护者、状态	状态：🟢定稿 / 🟡草稿 / 🔴待修
§1 主题包定位与使用方式	本包是什么、解决什么/不解决什么、与共识层去重边界、前置主题包依赖	开发者读这一节就知道本包的角色和边界
正文契约	按主题包类型组织——组件清单、接口契约、数据模型、业务规则等	这是开发者编码的直接依据
反向纪律（末尾）	“开发者不应做 X / 应做 Y” 的显式约束清单	防止常见误用

格式要点

• frontmatter 用 --- 包围的 YAML 块
• 每条契约必须有单一权威来源（在 sources.md 中可追溯）
• “零新业务约束”承诺：若本包内容 100% 来自既有 arch/domain，在 §1 显式声明
• 与共识层有重叠的内容 → 标注”引用共识层 §X，本处复述为开发者便利”（共识层 = 项目全局共享的设计约束，如 design-tokens、通用组件规范等，具体定义见项目架构文档）

---

§2 sources.md — 出处对账

必需章节

章节	内容
§1 资料源总表	每条来源：源文件 + 抽取了哪节 + 落在 package.md 的哪节
§2 逐断言对账	按主题包内容逐条：断言内容 → 出处（精确到段号或行号）

格式要点

• 出处引用精确到文件 + 段落（如 arch/组件图.md §2.7.1 #1）
• 资料源标注优先级：P0 必读 / P1 配套
• 每条断言一行，不可合并不同出处的断言

---

§3 verify.md — 验收记录

必需章节

章节	内容
三态表	package.md / sources.md / verify.md 各自的状态
W 协议选定	本包走 W-跳过 / W-轻 / W-重？理由？（W-协议详见 W-协议.md）
自检公式	自洽性（内部无矛盾）/ 封闭性（所有外引可追溯）/ 精简性（无冗余）
验收清单	V-01~V-0N，每项一条验收判据
灵魂关键词	参谋长从 package+sources 提炼 ≤5 条核心主张 → Owner 核对
待事项	本包内未闭合的遗留事项 + 触发时点 + 负责人

格式要点

• 灵魂关键词是 W-轻的核心机制：提炼本包最关键的 5 条主张，Owner 用业务直觉核对
• 待事项 ≠ 备忘区——备忘区放”不影响本包正确性但需要后续跟踪”的事；待事项放”本包内容依赖但尚未完成”的事
• 验收清单每项必须是可判定的（是/否），不接受”部分完成”

---

§4 示例参考

新项目参谋长可参照本指南的格式规范和信息密度要求来撰写自己的主题包。主题包三件套（sources / verify / tasks）的完整范例见 FLDD-开发执行.md 中的示例。

This site is open source. Improve this page.