【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文基于 OpenCodex 仓库devlog归档流程中的030阶段文档Execute safe _fin moves for FINISHED only完整讲解只移动已收尾FINISHED计划单元的安全移动协议其判定前提、移动算法、四条安全红线以及如何用移动日志与终态树验证形成可审计的闭环。读完后你将掌握一套可直接复用于长周期开发笔记/计划目录的归档方法论并能看懂 OpenCodex 2026-07-23 这次真实清扫中 10 个单元的完整移动证据链。背景devlog 的 _plan / _fin 双区模型OpenCodex 的 devlog 说明 定义了开发工作记录的目录契约_plan/—— 仍在进行中的单元units每个单元一个目录内部用十进制编号文档组织_fin/—— 已收尾的单元。只有当单元的终态结果DONE、NOOP、BLOCKED或带理由的NEEDS_HUMAN被记录后才从_plan/移入此处_chase/—— 为对比研究抓取的外部参考材料。仓库的 结构索引生成器 也在输出中固化了同一规则Development work is recorded indevlog/units —_plan/while open,_fin/once closed。也就是说_plan → _fin的移动不是简单的整理文件而是一次状态机迁移一个单元只有在证据上被判定为已完成后才能进入归档区。030文档正是这次迁移的执行规范。本次清扫所属的工作单元是 260723_codexrs_realtime_subagent_devlog_sweep其总体目标是把 codex-rs 实时/子代理研究的发现落档为持久研究单元同时把所有已收尾的_plan单元安全地搬迁到_finACTIVE/AMBIGUOUS 单元留在原地并保留证据。030 阶段的目标只移动 FINISHED 行030_fin_moves.md 的核心目标只有一句话Move only inventory rows labeled FINISHED. Leave ACTIVE/AMBIGUOUS.它操作的对象是上游020分类阶段产出的盘点矩阵inventory matrix。该矩阵为_plan下每个条目以及根目录非元单元产出一行记录列定义为path | type(dir/file) | label | evidence_paths | residual | destination_free | notes其中 label 三值分类为FINISHED / ACTIVE / AMBIGUOUS。移动阶段不重新判定标签只消费标签——这是判定与执行分离的关键设计分类阶段020_classify_inventory.md负责从活文件证据中给出标签与证据路径移动阶段负责按标签执行机械操作。移动算法先查后移移动后复核文档给出的伪代码如下# for each FINISHED name: if [ -e devlog/_fin/$name ]; then record CONFLICT / UNSAFE; skip else mv devlog/_plan/$name devlog/_fin/$name verify ! -e plan -e fin fi对 stub 文件非目录的单文件单元适用同一条规则。算法结构上有三个要点前置检查pre-check! exists(_fin/name)。目标位置已被占用时记录 CONFLICT/UNSAFE 并跳过绝不覆盖。这对应总计划 000_plan.md 中的成功标准 C4every FINISHED move has pre-check! exists(_fin/name)。执行mv同文件系统内移动见下文同文件系统优先规则。后置检查post-check! -e plan -e fin即源已消失且目标存在两者必须同时成立才算 OK。这一前后双重断言使得每次移动都有可回放的状态证据而不是仅凭命令退出码。四条安全红线的逐条解读030 文档的 Safety 小节列出四条禁令每一条都在仓库其他位置有明确的工程动机1. Neverrm -rf归档移动只允许 rename 语义。devlog/是公开仓库见 devlog/README.mdThis directory is public, so a commit is a disclosure the moment it is pushed, and the history is impractical to purge删除类操作不可逆任何一步走错都无法通过 git 以外的手段恢复单元内容而mv失败时单元仍完整位于_plan下。2. Never overwrite_findestination_fin代表已关闭的终态记录。若目标已存在说明要么之前的移动未完成、要么两个单元撞名——两种情况都属于需要人工介入的异常CONFLICT/UNSAFE自动覆盖会造成证据丢失或两个单元的记录互相污染。前置检查中的destination_free列矩阵中逐行核对devlog/_fin/name就是为了在执行前把这类冲突暴露出来。3. Never move nested git treesopencode-cursor、_chase这条规则的依据来自 devlog/README.md 的 Submodule hygiene 一节嵌套的.git目录会在父索引中变成160000gitlink破坏所有人的actions/checkout同时opencode-cursor和_chase/本身是外部研究/克隆语料不是 OpenCodex 的计划单元不满足收尾判定永远不参与归档移动。在真实盘点矩阵中这两处都被显式标注为do not auto-move nested git/research corpora见 020_inventory_matrix.md 末两行。4. Prefermvwithin same filesystemdevlog/_plan与devlog/_fin位于同一文件系统。跨文件系统mv实际是复制 删除两步操作中间态存在源在目标不在的窗口同文件系统内mv是 rename 系统调用接近原子失败时不会留下半移动状态。FINISHED 判定的保守门槛上游门槛如何保护移动阶段030阶段之所以敢只按标签执行是因为上游分类阶段Amendment A1/A2见 000_plan.md把完成的门槛刻意收紧了要求显式终态工件只有存在带实测结果的终态工件如040_loop_closeout.md的 DONE 记录 提交号、release train 的实测 npm tag才允许标 FINISHED空验证清单不算完成证明形如050_final_verification.md的空 checklist 明确不构成 finish proof——这正是矩阵中被判 AMBIGUOUS 的false-finish trap例如260722_pr_review_strategy050是空清单无实测最终验证结果残留开放队列保持 ACTIVEtriage 类单元若 040 记录里还有未关闭的 PR/issue 队列如260722_star_surge_triage即使活动日志很完整也判 AMBIGUOUSstub 特例空目录和极小的非单元 stub 文件在目标位置空闲destination-free时可按 STUB-FINISHED 归档——这是 FINISHED 标签下唯一允许无内容证据的类别因为证据本身就是size97/empty directory。这些判例在 020_inventory_matrix.md 中逐行落地28 个条目中 ACTIVE 11、AMBIGUOUS 8、FINISHED 10。移动候选清单Move candidates (FINISHED only)小节恰好列出 10 个dest_freeTrue的名称与移动结果一一对应。实测证据链10 次移动全部 OK本次清扫的真实执行结果记录在 030_moves.json 中这是一个结构化的逐移动记录字段包括path、type、label、evidence、residual、dest_free、result、reason。10 个条目全部为label: FINISHED、dest_free: true、result: OK、reason: moved。其中有代表性的两类stub 文件devlog/_plan/260712_cla证据为stub file size97备注STUB-FINISHED tiny non-unit file完整单元devlog/_plan/260722_issue_bug_sweep证据为040_merge_readiness_review CI green merge-readyresidual 为user decision for main/preview out of unit残留项已被显式标注为单元外事项。同名的文本日志 030_move_log.md 提供了带时间戳的逐条记录Measured: 2026-07-23T08:23:13.857476Z- 260712_cla → OK (moved) dest_free_preTrue - 260712_claudecode_webs → OK (moved) dest_free_preTrue ... - 260723_overnight_pr_review → OK (moved) dest_free_preTrue每条都显式记录了dest_free_preTrue即前置检查通过的事实与 030 算法的 CONFLICT 分支形成对照如果任何一条出现dest_free_preFalse这里应当出现 SKIP/CONFLICT 而不是 OK。终态验证从移动成功到树正确040_final_tree.md 对每个被移动名称执行后置断言格式为plan_absentTrue fin_presentTrue OK10 个名称全部通过。该文件随后给出两个关键计数第 31 行## Counts: remaining_plan15 fin_total213 OVERALL: PASS这正好对上 030 文档的 Accept criteria移动日志列出每次移动尝试及其 OK/SKIP/CONFLICT 结果→030_move_log.md与030_moves.json双重记录移动后_plan下零 FINISHED 行→ 剩余 15 个条目2 个松散文件 13 个 ACTIVE/AMBIGUOUS 目录与矩阵中全部非 FINISHED 行一致ACTIVE/AMBIGUOUS 仍在_plan或根下→ 如260701_codex-catalog-split999_status明确声明保留在_plan、260722_pr_review_strategy空清单陷阱、根级opencode-cursor与_chase嵌套 git 树均原样保留。验证用的复核命令清单写在 040_verify_closeout.md 中可在本地直接复现只读检查不改动仓库ls devlog/_plan | sort ls devlog/_fin | rg 260723_codexrs|260723_issue_fixes|260722_star_surge|260722_issue_bug || true test -d devlog/_plan/260723_codexrs_realtime_subagent_devlog_sweep rg -n FINISHED|ACTIVE|AMBIGUOUS devlog/_plan/260723_codexrs_realtime_subagent_devlog_sweep/020_inventory_matrix.md注意该单元随后自身也完成了收尾因此在本仓库中已位于devlog/_fin/下上述命令中的_plan路径应按当前实际位置调整。可复用的检查单把 030 文档及其上下游证据提炼出来任何维护开放/归档双区结构的仓库都可以照此执行一轮安全归档先盘点后移动为每个条目产出path | type | label | evidence | residual | destination_free行FINISHED 标签必须引用具体证据路径020_classify_inventory.md 的接受标准No FINISHED label without evidence path cited。保守完成门槛要求带实测结果的终态工件空 checklist、残留开放队列一律降级为 ACTIVE/AMBIGUOUS。逐条执行前置dest_free检查 →mv同文件系统→ 后置plan_absent fin_present断言冲突即 SKIP绝不覆盖、绝不删除。留下双证据结构化 JSON供程序审计 文本日志供人阅读每条记录时间戳与dest_free_pre。终态树验证计数剩余开放条目与归档总数确认零 FINISHED 残留在_plan输出 OVERALL PASS/FAIL。这套流程在 OpenCodex 这次清扫中的完整产出物——计划、盘点矩阵、移动 JSON、移动日志、终态树——全部保存在 devlog/_fin/260723_codexrs_realtime_subagent_devlog_sweep/ 下从 000 到 040 编号连续构成一个可完整回溯的审计样本。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐OpenCodex 维护实录codex-rs Realtime 与 Subagent 契约研究及 devlog _plan → _fin 归档清扫单元OpenCodex 维护实录codex rs Realtime 与 Subagent 契约研究及 devlog _plan → _fin 归档清扫单元 本文基OpenCodex devlog 单元闭合判定实战_plan → _fin 混合重分类与 f655 清单扫描OpenCodex devlog 单元闭合判定实战_plan → _fin 混合重分类与 f655 清单扫描 本篇基于 OpenCodex 仓库 devlogOpenCodex OpenAI Provider 三层硬化收尾审计18 个 Cycle 的合并终局、13 命令门禁与 _plan→_fin 归档OpenCodex OpenAI Provider 三层硬化收尾审计18 个 Cycle 的合并终局、13 命令门禁与 _plan → _fin 归档 本篇技上一篇Linux 内核 KCSANKernel Concurrency Sanitizer详解动态数据竞争检测的原理、配置与调试实战下一篇老游戏吃不满新显卡DLSS Swapper 快速替换 DLSS 版本创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考