用途：这是一套流程卫生规则，而非流程本身，用于管理 Backlog → Investigation（按需）→ FID（epic）→ Jira tickets → To Do → Implementation → review → approval → merge 这条流水线，避免同一事实散落成多个互相矛盾的记录。核心原则：每个事实只存在一个地方，推进工作意味着移动记录而不是复制记录。
主要能力与要点：
- 从 Backlog 取项时明确选择路径——直接开 ticket、先做调查、或带明确触发条件地搁置；FID 建立后删除对应 Backlog 条目，若上下文只在 Backlog 页面，先迁入 FID 再删。调查结论为“不构建”时也要删除 Backlog 条目，但把决策和理由记录在 FID 或调查页上。
- 每个 FID 对应一个 Jira epic，标题体现编号对应关系，如 FID-7 — <short name>；两者双向链接；由 FID 拆出的每个 ticket 都以该 epic 为 parent，不允许孤儿 ticket。
- FID 页面上维护 ticket 登记表（key、summary、status 及一行说明），作为人的视图；状态以 Jira 为准，冲突时改页面而非改 Jira；只在三个时刻更新：ticket 创建、状态实质变化、ticket 被加入或移出 FID 范围。
- 新 ticket 若属于既有 FID，需挂到该 epic、加入登记表；若是实现中发现的问题，用一行说明来源；若不属于该 FID，则放回 Backlog 走正常路径。
- 标记“完全实现”要求满足全部验收标准，包括负向与边界情况；每条负向标准须能指出强制执行它的具体机制（filter、guard、check），否则不算 Done；确认改动已落地并有在缺少该改动时会失败的测试覆盖；有意不满足的标准需在 ticket 上说明并获接受。资料提及 2026-07-30 对 30 个 ticket 的审计发现 13 个至少有一项未满足标准，几乎都是负向情况。
- 关闭 FID 的条件是所有 ticket 为 Done 或带理由明确推迟；页面上记录交付了什么、砍掉什么及原因、kill condition 是否触发、以及日期；停更的 FID 应标注为历史记录。
适用场景：使用 Confluence FID 页面与 Jira epic/ticket 管理开发工作的团队。限制：机械部分（建 epic、挂 parent、同步登记表、标记孤儿 ticket 与过期登记表）可自动化，但路径选择、标准是否满足、推迟是否可接受等判断不应自动化；文中未提供安装命令、代码、具体工具实现、收费或平台信息。