Repository navigation
fix(todo): qualify strict CLI adapter checks in CI - #7911
Conversation
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEADFor a same-repository clone whose Keep the DCO |
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=max
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机 / Motivation
维护 Todo CLI、Markdown 输出和严格类型检查的开发者。
原17个 kernel 入口通过,并不证明 Todo 两个适配器可通过严格检查;对它们直接检查可复现六条诊断。
当前头消除六条适配器诊断,保留原 kernel 命令和导入行为,并用独立步骤明确检查两个适配器;真实命令和完整返回值对照未发现行为变化。
不认证全仓及 legacy 依赖实现的类型质量,不冒充远端 CI、其他 Python/平台或安装后宿主采用,也不声称长程收益。
改动思路 / Approach
严格选项继续来自既有 pyproject;原 kernel gate 保持,两个适配器单独显式检查。导入异常定义 owner、复用已收窄值和一次读取 correctness 字段,比新增配置、包装器或放宽原检查更小。
当前 PR 交付两个适配器的类型修复和附加 CI 检查范围,既有17入口及产品运行时契约保留。
保持原 strict 配置及17个入口,比把新文件直接扩入全部依赖闭包、再全局忽略错误更准确;新增 step 明确采用 follow-imports=silent,只检查选中模块的实现并利用依赖类型,不宣称依赖实现本身也已通过。没有第二份配置、异常类型或业务决策 owner,也不要求普通 CLI 用户重新配置或增加确认轮次。
具体改动 / Changes
精确 head b8a353d08fd0820bd5e660a8088ee6d6cbd7ccf2,实际基线 58a85d0aae8d35fdcbb75f5c93a25d38d5f5a8e9,完整四文件 +17/-9。独立规范 docs/development/testing-and-quality.md,版本 58a85d0aae8d35fdcbb75f5c93a25d38d5f5a8e9;先读 Local Validation Environment、kernel lane 边界和类型检查零错误要求,再看差异。kernel-contracts — implemented: 原 kernel command/import traversal 保留,新增独立适配器检查而非替换原 gate。mypy — implemented,限定声明的范围: 在正确 source/cwd 和无额外导入路径环境运行,原17和新增2模块均通过,legacy 实现不纳入新资格声明。
关键代码讲解
- todo_error_payload 从定义模块导入既有 TaskLeaseError。旧公共模块的 reexport 与定义是同一个类对象,错误代码、结构化恢复和原权限处理保留。
- append_todo_rollout_event 复用函数已读取并收窄的 identity,提取相同 effect_id;历史 Turn、事件类型和幂等字段不变,没有解析 opaque completion key 或另建身份。
- render_todo_markdown 对 write_intent/apply_result 各读一次后检查 dict;缺失、None、标量和有效映射的完整输出与 base 一致。
- 新增 workflow step 依旧先执行
python -m mypy,再以同一 strict 配置执行显式2文件检查;repair-pattern 行说明环境遮蔽与诊断范围,不增加运行时义务。
对主干的风险 / Risks
独立从实际 workflow YAML 解析两条命令,并去掉 PYTHONPATH/MYPYPATH。在相同 Python3.12.15、mypy目标3.11配置下,base/head 的原17入口均 PASS;新增两模块命令在 base 检出全部六条原诊断,在 head 为零。没有把作者的旧5545条依赖闭包错误、其他解释器或远端 job 当成本轮独立执行。
为了证明不是“让类型检查沉默”,对原 kernel root、todo_event、Markdown 分别使用 mypy 标准 shadow-file 注入同一个非法赋值。三个实际检查都以 exit1 拒绝并报告 assignment 错误;原 tracked 文件未修改。该控制验证原 gate 仍有效,silent 导入标志没有扩成全局设置。
五个 owning runtime 模块在 base/head 各 66 PASS,包含真实 File/SQLite、claim 参数拒绝/恢复、lease/native ownership 与 completion state。另有 18个完整 Markdown/error/event 输入对照,覆盖缺失/非dict/correctness字段、原身份及 canonical lease error;返回内容完整 16483B 相同,没有删字段或归一化诊断。捕获回调中的 Path 用类型和值显式序列化。第一次私有捕获因 Path 序列化失败产生两份空输出,不能证明 parity;修正捕获后才取得上述完整对照。
Ruff、compile、公开边界与 native premerge 6direct+19selected PASS,0failure/advisory/hold。没有查询、轮询或等待远端 CI。PR 当前 merge conflict 和 GitHub 的作者自批准限制单独保留;本 review 用 COMMENTED 承载代码批准结论,不冒称平台 formal APPROVED,更不执行 merge、rebase 或 bypass。
语义与 CI 对齐
复用既有异常定义和收窄值,没有新增状态、公共字段或枚举。CI 新增范围是显式默认行为,已在 step、注释和诊断 skill row 披露;产品 accepted inputs、错误恢复、事件/Markdown、调度和权限未变。compiler failure 是现有 job 的机器 gate,skill row 是开发诊断建议,二者不能混称。原配置和 original17命令未弱化;legacy imported implementations 的未知类型债仍未知。
我的整体评价 / Verdict
APPROVE 当前有界类型修复。 这项内部维护目标已完成;long_horizon 与 user_experience 为 preserved,依据真实现有命令和完整输出对照,不以 CI step 或测试个数代替长期收益。体量与六条实际诊断相称;直接使用原异常 owner、已有 identity 和一次读取是已应用的有界简化,不需要新通用检查器、兼容层或后续仪式性任务。
已检查变更及其 CLI/配置消费者;没有修改渲染组件、布局或产品控件,视觉评审不适用。
真实远端 CI、其他解释器/平台、安装后的 Host 与模型采用未由本轮独立验证。
legacy 导入实现、其他 Python/平台、真实远端 CI 和安装态宿主未由本次独立运行资格化。 作者同账号只能发表 COMMENTED 的批准结论;精确 head 的独立事实、CQR、本地验证、remote readiness 和合并权限分别判断。
English verdict: APPROVE at b8a353d08fd0820bd5e660a8088ee6d6cbd7ccf2 for the scoped type repair and additive adapter gate. The original 17 roots remain intact, six base diagnostics disappear, all three strict fault controls reject, and 66 runtime tests per revision plus 18 complete output pairs preserve behavior. This is a COMMENTED author-account fallback, not formal self-approval or merge authority.
Signed-off-by: huangruiteng <huangrt01@163.com>
b8a353d to
b8fd4e4
Compare
huangruiteng
left a comment
There was a problem hiding this comment.
Reviewer: model_agent · GPT-5 · OpenAI · self_reported
Approval conclusion
精确评审 b8fd4e4d4fab988976e7caa4ba5c55418f8eadd5,基点 be2a5c3537b98053b2e6ee7f4440c83268ca84f5。旧 PR 已在新 main 上重建,冲突消失;当前没有 blocking finding。批准范围是两个既有 Todo adapter 的类型修复和新增 strict CI 检查,不包含 legacy 依赖实现、全仓类型债或远端 CI 的重新认证。
动机 / Motivation
维护 Todo CLI、严格类型检查和失败恢复路径的开发者与 CI 操作者会遇到这组问题。改动前,现有 17 个 kernel root 通过并不代表两个 Todo adapter 通过同一 strict 配置;单独检查会报六条错误。改动后,同一单模块边界为零错误,而原 kernel gate 和导入遍历保持不变。结果是两个 adapter 获得真实 strict 检查,六条 base 诊断消失,CLI 错误投影、rollout identity 与 Markdown 输出仍保持原语义。这不宣称 legacy 依赖实现、全仓类型债、远端 CI 或安装版宿主已经通过。
如果继续维持旧状态,CI 只会告诉维护者那 17 个 kernel 文件正常,却无法阻止 Todo 错误 payload、settlement identity 或 Markdown 的正确性字段再次出现静态类型偏差。当前切片把这些诊断放进与其真实 owner 相邻的适配器中,修复可以直接回滚,不需要数据迁移。
改动思路 / Approach
入口仍是现有 Todo CLI 和 kernel-contracts job;权威状态仍是既有异常定义、已经收窄的 settlement identity 与 Todo payload,没有新增运行时状态机。正向路径是 kernel mypy 先通过,再由新增 step 对 todo_event.py 和 markdown.py 运行同一 strict 配置;负向路径是 adapter 中出现不兼容值或隐式 re-export 时,mypy 以非零退出阻断 job。
Existing adapters and mypy configuration are sufficient; the additive boundary is smaller than expanding the kernel closure or creating a new checker. 该判断保留了异常定义、identity 与 Markdown 输出 owner,也没有新增包装器或第二份配置。Qualify two existing Todo adapters and preserve the original kernel gate, without claiming legacy dependency implementation quality. 因而不把 follow-imports=silent 解读为依赖实现已通过,也不要求普通 Todo 用户增加配置或确认。
具体改动 / Changes
依据是 docs/development/testing-and-quality.md,审查基点为 be2a5c3537b98053b2e6ee7f4440c83268ca84f5。local-validation-environment 已实现:无 PYTHONPATH / MYPYPATH 的当前 main 源码归档能复现原问题,当前 head 的明确命令通过。zero-type-errors 已实现:两个 adapter 在 strict mypy 与 Ruff 下零错误。kernel-static-contracts 已实现:原 17 个 source roots 和 import traversal 未被删除或弱化。
完整 diff 为 4 个文件、+17/-9:两个 Python adapter、一个 CI workflow step 和一条 self-repair 诊断模式。没有新增运行时模块、公共字段、异常类型或配置 owner。
关键代码讲解
todo_error_payload现在直接从local_lease_record.py的定义 owner 导入既有TaskLeaseError。此前依赖task_lease.py的隐式 re-export;类对象、错误代码和后续恢复路径没有改变,但 strict mypy 不再把导入解释成不存在的显式属性。append_todo_rollout_event复用前面已经读取并收窄的identity,从中取得effect_id。历史 Turn、事件类型、缺失 identity 时的 null 行为和幂等字段都保留;没有解析 opaque completion key,也没有生成第二个 identity owner。render_todo_markdown对write_intent和apply_result各读取一次,再按dict类型收窄。缺失、None、标量和有效 mapping 的渲染语义与之前相同,同时消除了None.get(...)的静态歧义。Type-check Todo CLI adapters是新增的显式 machine gate:保留原python -m mypy,随后只检查两个 adapter,并使用--follow-imports=silent分析依赖类型而不宣称其实现质量。workflow YAML 已解析通过。typed_adapter_validation_scope_mismatch只记录这次可复用的诊断经验:不要为了消除大依赖闭包而扩大 kernel root、全局忽略 import 或改写历史失败。
对主干的风险 / Risks
最强回归是“类型检查变绿但语义变了”或“检查通过只是因为把 import 诊断全局静默”。当前证据同时覆盖两个方向:base 在干净源码归档中继续精确产生六条诊断,head 对两个 adapter 零错误;原 kernel gate 仍运行,并且相关 CLI、lease、settlement 和 native ownership 回归为 114 passed。失败 blast radius 限定在 Todo CLI 错误/事件/Markdown 与维护 workflow,回滚只需还原这四个静态文件。
本次还执行了 Ruff、Python compile、workflow YAML 解析、公开边界和最新 main 上的完整 premerge。第一次 premerge 的 semantic scan 因新 worktree 未安装根 npm dev dependencies 而失败;安装 npm ci --ignore-scripts 后,同一 smoke 和完整 premerge 均通过,最终为 6 direct + 19 selected passed,0 failure/hold。这属于环境准备,不是代码失败。
legacy imported implementations 的类型债没有被本轮消除,其他 Python/平台、安装态宿主和完整远端 CI 也未独立验证;这些都保留为明确边界。按 Goal 的 wait_for_ci=false,本轮没有查询、轮询或等待 GitHub CI,最终 merge readiness 单独判断。
语义与 CI 对齐
改动复用既有 TaskLeaseError、settlement identity 和 Todo Markdown,不新增 shared vocabulary、权限或调度语义。新增 workflow step 是机器强制检查;self-repair 表行是诊断建议,两者没有混写。follow-imports=silent 只改变新增 step 的依赖分析方式,原 kernel command 未变;公开边界扫描在 premerge 中通过。legacy 依赖实现仍是未资格化范围,因此本 review 不把新增 strict step 宣称为全仓类型合格。
视觉评审不适用:变更影响 CLI 文本和 CI YAML,没有修改页面、布局或交互。
我的整体评价 / Verdict
APPROVE。原六条诊断在当前 main 的未改源码上可复现,并在当前 head 消失;原 17-root gate、运行时错误恢复、identity 与 Markdown 语义都保留。long_horizon=preserved,因为这些 adapter 仍通过既有恢复与持久化路径工作;user_experience=preserved,因为 CLI 输出和用户操作没有变化,而维护者获得更早、更精确的失败。
体积与问题相称:四项文件、17 行新增,复用既有异常和配置,没有引入抽象层。残余风险只是未资格化的 legacy 依赖、其他平台/解释器、安装态宿主和远端 CI;这些不影响本次有界 adapter 类型修复,但继续限制更广泛的质量声明。
English verdict: APPROVE at b8fd4e4d4fab988976e7caa4ba5c55418f8eadd5. The current main source reproduces six adapter diagnostics; the exact head passes strict mypy with zero errors, the original 17-root gate remains intact, 114 related runtime tests pass, and the rebased 19-selection premerge is green.
Todo CLI 的错误/结算投影与 Markdown 适配器有六条严格类型诊断,原有 CI 登记了 17 个 kernel 入口。本 PR 修复这六处,并给两个适配器增加明确的严格检查边界;原 kernel 命令、17 个入口及其默认依赖检查原样保留。
错误适配器从定义处导入既有
TaskLeaseError,复用已收窄的 settlement identity;Markdown 适配器只读取一次可选 correctness mapping,再按实际类型使用。没有新增异常、运行时决策、配置 owner 或公共输出字段。既有类型配置保留在pyproject.toml,新增 CI step 复用同一 strict 配置:第二条命令严格检查两个选中模块,并解析依赖提供的类型;依赖实现本身的诊断不属于这项新增边界。原有第一条检查继续默认的 import traversal。这是逐步扩展适配器检查,未取得全仓或 legacy 依赖实现的类型资格。
CI 揭示了先前提案的范围问题:旧 head 的 kernel job 将 19 个入口扩展为依赖闭包,报出 5,545 条错误、628 个文件,两个适配器本身没有诊断。在 Python 3.11.17 / mypy 1.20.2 的相同源码归档环境中,原 base 的 17 入口通过,旧 head 重现相同失败。受控实验仅增加源码
PYTHONPATH就让旧 head 显示 19 入口通过;前次本地环境未完整记录,因此不能确定它当时的具体差异,前次通过记录也不能用于宣称 CI 已取得资格。旧失败保留,本轮将新增检查范围明确列出并保留原 gate。验证固定于当前目标 main
be2a5c3537b98053b2e6ee7f4440c83268ca84f5与 headb8fd4e4d4fab988976e7caa4ba5c55418f8eadd5;分支已在最新 main 上重建为单一签名提交,当前 PR 仅 4 个文件的独立差异:PYTHONPATH/MYPYPATH的当前 main 源码归档中运行:新检查在 base 精确复现 6 条原诊断,在当前 head 对两个适配器零错误;原 17 入口检查也通过。旧 head 的 dashboard job 还记录了 lens-switch 超过冻结 1s 预算的失败,本轮未调整该预算或追认通过。其他 Python/平台、安装版宿主、完整长程效果与成本未由本轮取得资格;按当前 Goal 配置,本轮不查询或等待远端 CI,最终 merge readiness 会单独判断。
相邻重构保持在既有两个适配器内:复用异常定义 owner 和收窄值,无需新包装层、通用检查器或 UI。作者修复完整,保持普通 PR;未合入、安装或宣称实际采用。