用途：当代码评审发现的缺陷无法在当前 PR 中修复时，按该流程创建规范记录、带完整上下文并关联父 issue 的追踪 issue。核心原则是“没有缺陷会消失，每次延期都被追踪”，延期必须创建追踪 issue。
何时可以延期：仅限超出 PR 范围的架构改动、需要基础设施或配置变更的外部依赖、会导致主版本升级的破坏性变更、与当前工作逻辑无关的独立问题。评判标准是不能用“以后修”“问题很小”“不是我的问题”“够好了”作为不追踪的理由。
流程：先确认确实无法在当前 PR 修复且有合适延期理由；再整理缺陷内容、问题原因、代码位置、严重程度与延期原因；然后用模板创建追踪 issue，标题形如 [Finding] … (from #[PARENT])，正文包含 Origin 属性表（Parent Issue、Parent PR、Finding ID、Severity、Review Criterion、Depth）、Finding Details（描述、文件与行号、函数、影响、证据代码）、Why Deferred（类别与理由）、Acceptance Criteria 和 Links，标签为 review-finding、spawned-from:#[PARENT]、depth:[N] 及严重程度。可用 gh issue create 创建，必要时先 gh label create 再 gh issue edit 添加标签；随后更新评审工件中的 Findings Deferred 表格；若延期阻碍父 PR，则给父 issue 加 status:awaiting-dependencies 并发布 deviation 评论。
追踪 issue 生命周期：它是独立的一等 issue，走完整 issue 驱动开发流程，需接受自身评审，可再产生延期并递增 depth，独立关闭，不随父 issue 自动关闭。depth 表示嵌套层级，3 及以上需标记并提示可能存在系统性问题。
集成：由 apply-all-findings、comprehensive-review 等调用；引用 issue-lifecycle 与 issue-driven-development 流程。其他实现细节、具体配置或收费信息暂未提供。