opencodex devlog 混合式完成判定（Hybrid Reclass）方法论：从 `_plan` 到 `_fin` 的归档决策实践

本篇技术指南基于 opencodex 仓库内 devlog 治理实践文档（000_interview_package.md）展开，系统讲解该仓库如何在大规模规划单元（_plan）中判定"哪些工作单元真正完成、可以移入_fin归档，哪些仍有核心残留必须留在_plan"的决策方法。读完本文，你将掌握一套可复用的HYBRID 混合式完成判定标准（KEEP / MOVE_WITH_MEMO / BLOCKED 三态标签）、核心残留与延迟抛光的区分准则，以及伴随归档动作生成 inventory、residual-active 备忘录与最终目录树的完整执行链路。

背景：为什么 devlog 需要"重新分类"

opencodex 仓库的 devlog/README.md 明确规定了规划笔记的存放规则：

• _plan/—— 仍处于开放状态的单元，每个单元一个目录，内含按十进制编号的文档（000_计划、030_验证、090/100收尾等）；
• _fin/—— 已关闭的单元，其最终结论（DONE、NOOP、BLOCKED、NEEDS_HUMAN及原因）已被记录后，才允许移入；
• _chase/—— 用于外部参考材料（如各上游客户端协议的 parity 对照资料）。

260723_ambiguous_reclass_interview这一单元要解决的问题是：当_plan下积累了数十个新旧混杂的工作单元时，如何批量、可审计地判定每个单元的去向。文档记录了一次以 "Clarification（澄清）" 模式进行的决策会话（Session019f8e04-4172-7260-982d-891794bdbd98），其 Loop archetype 为spec-satisfaction——即"由子代理验证的残留分类来定义完成（done）"，而不是靠主观感觉收尾。

核心方法论：HYBRID 混合式完成策略

采访过程经历多轮冲突消解后，最终把完成策略收敛为HYBRID（混合式），其核心思想是："完成"不是一个二值判断，而是把每个单元拆成"核心残留（core residual）"与"延迟抛光（deferred polish）"两部分，分别对待。

这一策略直接解决了旧式归档的两个痛点：

1. 全部搬走（激进策略）：会把未完成的单元伪装成已完成，污染_fin的可信度；
2. 全部留下（保守策略）：会让已具备充分证据、仅剩收尾杂项的单元长期滞留_plan，归档效率低下。

HYBRID 的落地要点（来自采访包的 Settled answers）如下：

判定准则：Core vs Deferred Rubric（可复用清单）

文档中最具实操价值的部分是"核心残留 vs 延迟抛光"的判定规则表。它给出了哪些情况必须阻止归档、哪些情况可以带备忘归档的明确判据：

核心残留（KEEP in_plan，永不移动）

• 必要实现仍处于待完成/未实现状态：单元宣称的功能代码还没落地；
• 存在显式开放队列且这正是单元存在的目的：例如开放 PR / issue 的 triage 仍在进行中，队列未清空；
• 验证清单为空且没有任何实测结果：单元声称已完成，但拿不出测量数据；
• 纯计划型单元，没有任何执行证据：只有计划文档，没有代码、测试或合并记录支撑。

延迟抛光（MOVE + residual memo 允许）

• 被明确命名的范围外残留（named out-of-scope residual）：比如"GUI shadow-intercept 字符串不在本次范围"；
• 代码落地后的后续 GUI / 文档打磨：功能已上线，剩下的是界面文案或文档微调；
• 被接受的已知限制（accepted known limitation）：团队明确接受该限制，不阻塞交付；
• 已有代码+测试证据、但延迟做 live smoke：实时冒烟测试可以后补，不构成完成性障碍。

这套规则的意义在于把"感觉上做完了"转化为可核查的判据：KEEP 的四条全部指向"证据缺失或目的未达成"，MOVE 的四条全部指向"证据已具备、剩余项不阻塞"。

采访包结构：一次规范决策会话的产物

000_interview_package.md本身就是一个可复制的"决策包"模板，包含：

1. Settled answers（定稿答案）：5 条，覆盖策略、分支、目标集、残留处理、验证要求；
2. Dimension readiness（维度就绪度表）：对 Goal / Constraint / Success criteria / Ontology 四个维度打分（满分 3），并列出各自的 Knowns：
   • Goal（目标）：对整个_plan在 f655/dev 上重新分类；只把 hybrid 合格单元移入_fin；记录残留；
   • Constraint（约束）：只在 f655 工作树内操作；不碰产品代码；不 push；不覆盖（no clobber）；嵌套 git 永不移动；主预览 checkout 不动；
   • Success criteria（成功标准）：核心残留被阻断；延迟抛光可携带备忘录移动；必须有子代理验证；inventory + 移动日志 + residual 备忘录构成证据；
   • Ontology（本体）：标签体系 KEEP / MOVE_WITH_MEMO / BLOCKED；单元居所_planvs_fin；residual-active.md作为中央备忘录。
3. OPEN ASSUMPTIONS（开放假设，记录但不阻塞）：4 条，包括"采访/会话追踪器留在主仓库.codexclaw/，文件移动在 f655 工作树执行"、"目的地冲突时跳过并上报、绝不覆盖"、"旧计划文档中的历史矛盾是分类输入而非阻塞"、"当前主 checkout 在 Plan/Build 期间保持preview"；
4. Scan rounds（扫描轮次）：R1–R3 暴露分支/策略冲突并由后续回答消解；R4 定稿包，剩余项是 Plan 落地 + 逐单元子代理验证；
5. Next（下一步）：等待用户 fork（Proceed / 更多问题 / 暂停）。

这种"先对齐维度、再记录假设、最后分轮扫描消解冲突"的流程，保证了大批量归档决策的可追溯性——每一个 KEEP 或 MOVE 结论都能反查到对应证据。

执行产物：residual-active 备忘录与最终目录树

配合采访包，仓库中保留了完整的执行证据链，这三份文档共同构成了"移动必须留下审计痕迹"的落地：

• 010_f655_residual_active.md（与260723_dev_plan_hybrid_sweep/residual-active.md内容一致）：中央备忘录，记录测量时间戳、工作树、HEAD、策略，并把 12 个单元逐一分类；
• 020_f655_inventory.md：12 个单元的 inventory 清单，逐行标注MOVE/OK或KEEP；
• 040_f655_final_tree.md：移动后的最终目录树快照。

MOVE_WITH_MEMO 的实际判定（5 个单元）

KEEP in_plan的实际判定（7 个单元）

这 7 个 KEEP 单元的判定完美对应 rubric 中的四类核心残留——没有一条是基于主观印象，全部锚定在具体文件的证据状态上。

关键约束与操作纪律

采访包中反复强调的约束值得单列，因为它们决定了归档操作的安全边界：

1. 分支纪律：移动只在 f655 工作树执行，主 checkout 保持在preview，避免污染预览分支；
2. No clobber 原则：目标目录若已存在同名单元，跳过并上报，绝不覆盖——这防止了归档操作破坏已有记录；
3. 嵌套 git 永不移动：与 devlog/README.md 的 Submodule hygiene 规则一致——嵌套.git会成为父索引中的160000gitlink，破坏actions/checkout；
4. 移动前验证：核心残留为 0 才可移动，且验证必须由子代理完成（对应 Loop archetype 的 spec-satisfaction 定义）；
5. 安全边界：devlog 目录是公开的，未披露的安全发现、草稿公告、exploit 路径绝不允许出现在_plan/_fin中——公开即披露，历史难以清除。

可复制性：这套方法论适用于什么场景

HYBRID reclass 方法论并不局限于 opencodex 自身，它可以被任何以"目录即状态"方式组织工程笔记的仓库复用：

• 当你的_plan目录积累了大量跨批次、新旧混杂的工作单元时，先用 dimension readiness 表对齐 Goal / Constraint / Success criteria / Ontology 四个维度；
• 为每个单元建立"证据 + 残留"双栏评审，用 KEEP / MOVE_WITH_MEMO / BLOCKED 三态标签标注；
• 移动时同步生成 inventory、residual-active 备忘录、final tree 三件套，确保任何人在三个月后仍能复现"为什么这个单元被搬走/被留下"；
• 把"已有代码+测试证据"与"只有计划无执行"作为最强的两类信号，前者允许带备忘移动，后者必须留下。

对于正在管理大型 AI 协作仓库、或希望为自身项目建立可审计归档流水线的团队，这套"核心残留阻断、延迟抛光带备忘放行"的混合策略，是一个经过真实批次（12 个单元、5 移 7 留）验证的实操模板。