Skip to content

feat(backup): retain owner-exported canonical history for inert recovery - #6669

Merged
huangruiteng merged 4 commits into
mainfrom
codex/recovery-canonical-capture-20261016
Oct 16, 2026
Merged

huangruiteng merged 4 commits into
mainfrom
codex/recovery-canonical-capture-20261016

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

Goal And Delivered Outcome

Author Declaration

  • Written by: model_agent — GPT-6.1 Sol (Codex), OpenAI.

Implemented against

Specification: docs/architecture/rfcs/complete-state-recovery-v0.md at a7da3af6a5d7e9cbf75bd9a44bee26242a746c7d.

Criterion Disposition Owner / evidence
M1 inert inspection and no admission implemented Existing typed audit and packaged HTTP; source-loss/unknown/corrupt/duplicate cases
M2 first configuration/canonical pair with actual content and intervals/dependencies implemented Existing native archive/provider/fence/configuration owners; File/SQLite capture, concurrent append and moved binding cases
M2 complete required-owner closure and online/quiescent/crash profile deferred Quota/Turn, lifetime/effects, scheduler/Host and material/provider rows still need their own exports and reconciliation
M3 controlled adoption and independently accepted continued work out_of_scope No live import, registration, lease/session revival or effect replay

Self-check: read the accepted owner inventory, current main, producer/consumer and native archive contracts. Both pre-change File/SQLite characterization cases fail because no native capture exists; the resulting artifacts now independently restore and audit. No hosted CI was fetched or waited for.

Scope And Continuation

The TypeScript composition reuses exportAuthorityArchive, provider selection, fence decoding and the canonical Todo reader. Python packages the returned private artifacts and transports them to the existing inert verifier. No new capability, provider, profile, activation setting or Python decision owner is introduced.

New ordinary backups add execution.authority_captures; inspection prefers those exports. Missing/damaged captures stay unknown even if the earlier raw copy is readable. A valid native export can remain readable when a raw database fails its independent storage inspection. Historical v0 archives without the new rows and explicit migration-only backups keep their current behavior. These intentional default changes are documented.

The extra logical history copy costs IO and archive space beside the retained raw safety copy; existing archive/history/verifier bounds are unchanged. Every audit remains held / legacy_best_effort, with activation and execution false. The useful, reversible boundary is actual portable authority content, not another manifest-field-only stage. Continue the same RFC owner closure through quota/Turn settlement and real-entrypoint lifetime/effect owners; do not infer a shared epoch from this pair.

The future-facing pass keeps one cohesive owner helper and the existing archive/receipt decoders. The legacy raw reader stays because persisted v0 archives still use it. One bounded quality repair corrected a documentation link label; no speculative recovery framework was added.

Validation

  • Tested revision: c462a552b995b4c27972baa7b205e2b17ca2993d, integrated with main a7da3af6a5d7e9cbf75bd9a44bee26242a746c7d. The final follow-up changes only a reference label; runtime/tests are identical to the integration run.
  • Run state: finished
  • Input classes: synthetic, public_fixture
Check kind Result Evidence / limitation
real_entrypoint / real_backend passed 142 affected Python cases: full producer/verifier, real File and SQLite, source loss, native standalone restore/audit, original receipts, missing owner, corruption, historical v0, SQL-view refusal and scoped cold migration
integration passed 43 TS archive/configuration/recovery cases; real concurrent appends retain the captured prefix, moved selector/fence/store identity refuses capture
real_entrypoint passed Normal frontend and wheel build; 21 installed-wheel cases outside the checkout, including both providers and HTTP upload/verify/history/duplicate/corrupt refusal after source loss
regression_parity passed Both provider characterizations fail before implementation at 88bac4bde2602f5bd737ef6fb22cd672901b47c2; current artifacts restore and original-receipt audit matches. Legacy raw and dedicated migration contracts remain covered
static passed Ruff on four changed Python paths; configured mypy 17 sources; integrated TypeScript typecheck; diff vocabulary advisory and full semantic smoke; public/private scans
integration passed Goal-bound risk canary: 5 direct + 5 selected catalog checks, zero failures/warnings and no manual holds
static passed Exact quality receipt cqr_88fb20191500ee1922e0, fingerprint 88fb20191500ee1922e084041e837e51d296e05285ad74f6fbf65318e433b8fa, 11 files; safe-fix allowed/applied once; 0 blockers, 0 warnings, 1 advisory for extra archive IO/space
manual not_run Hosted CI, non-POSIX/platform qualification, remote providers, full M2 cross-owner/crash drills and M3/Host admission are not claimed

The package gate initially rejected a stale bundle after integration; the standard frontend rebuild and normal wheel build then passed. No build bypass or capacity increase was used. Validation covers actual producer content, source-loss consumer behavior, original receipts, refusal and compatibility; compound worst-case cost remains unqualified.

Frontend / Visual Evidence

  • UI impact: none — existing Settings/Capability Center recovery workflow, audit classifications and controls are reused. No layout, first viewport or configuration editor changed.
  • Existing packaged HTTP journey verified against the real owners, including source loss and recovery/error readback; no new visual claim.

Type of Change

  • New feature
  • Documentation update
  • Test update

LoopX Area

  • Control plane
  • Capability or extension

Technical Direction

  • Complete-state recovery RFC M2 first owner pair; M2/M3 qualification remains open.

Shared-authority RFC fixture impact

  • No canonical writer, selection, promotion or compatibility projection is changed. Actual File/SQLite owner exports and receipt readback are covered; a legacy/File/PostgreSQL promotion rehearsal is not applicable to this local read-only capture increment.

Boundary Checklist

  • Public-safe code, docs and synthetic fixtures only; no private state, raw traces, local paths or credentials.
  • No maintainer-owned benchmark jobs launched or duplicated.
  • Scope stays within the existing recovery owner increment.
  • UI impact is none.
  • Every contribution and integration commit has a DCO sign-off.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
…cal-capture-20261016

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval). Exact-head COMMENTED self-review; no independent approval or merge authority claimed.

动机

用户为本地 Goal 创建完整备份、随后原工作目录失效时,需要从保存的内容核对未完成工作和原操作回执。现有原始副本可能包含完整历史;这次让同一次备份同时保存可由既有恢复命令独立检查的原生历史导出。失源后可以直接核验、恢复该导出到全新隔离 store,并逐项核对原操作回执;捕获来源缺失或依赖变化时明确保持未知。本次不恢复执行身份、租约、会话或外部操作,也不把局部导出当作完整恢复资格。M2 仍缺选定 Goal 的完整必要 owner 闭包、跨 owner profile 和相应故障演练;M3 与 Host 准入继续开放。这里的价值是把原生内容及其依赖纳入一次备份和既有检查流程,减少失源后手工拼装 provider 文件的成本;并非声称原有 raw copy 没有历史。

改动思路

缺口在完整备份与既有原生历史导出之间;复用 archive/provider/fence/Todo owner 即可接通真实内容,无需新恢复框架。当前 PR 只交付可独立恢复的历史内容及其捕获依赖,完整 owner 闭包、profile 和执行准入仍保持开放。TypeScript 组合层调用既有原生导出器,以存储自身确认的完整历史前缀为内容,记录实际区间、配置摘要、runtime、selector 和 writer fence;Python 只打包返回的私有文件。检查端继续复用既有归档、provider、fence 和 Todo decoder,不能用字段存在代替内容验证。

场景 当前准确 head 的结果
捕获时继续正常追加 保存捕获 cursor 对应的完整前缀,后续追加保留在来源
selector、fence 或 store 身份移动 不发布该原生捕获,记录未知
raw 已复制后来源消失 不初始化来源,不把较早 raw copy 冒充本次原生成功
原生导出损坏、raw 仍可读 原生 owner 保持未知,不静默回退
旧 v0 或专用迁移备份 保留原有 raw / 受限迁移路径

这是代码与真实 provider 时序测试的对照。配置和 canonical 的局部证据仍不是跨 owner 的同一时刻;其余必要 owner 未闭合,报告继续 held,所有激活和执行标记为 false。

具体改动

准确 head c462a552b995b4c27972baa7b205e2b17ca2993d,base/main a7da3af6a5d7e9cbf75bd9a44bee26242a746c7d,11 路径 +586/-17。五个产品文件、四个验证文件、两份文档组成完整的 producer → 惰性消费者 → 独立恢复/回执审计增量。main 的 Todo 默认优先级和 Windows CI 更新通过正常合入保留在共同祖先,PR diff 未混入那十四个上游路径。

规范依据为 docs/architecture/rfcs/complete-state-recovery-v0.md,接受基线 a7da3af6a5d7e9cbf75bd9a44bee26242a746c7d。M1 inert/held/no-admission 保持 implemented;Canonical work inventory row 的实际原生内容、区间和依赖是本次 implemented;M2 完整必要 owner 闭包及 profile 仍 deferred;M3 身份/effect 准入和原入口独立验收 out_of_scope。RFC 更新的是已实现边界,没有改写 entry/exit 来制造完成。

关键代码讲解

  1. captureAuthorityBackup,53 行 以 existingOnly 打开真实来源,调用原生 exporter,核对前后依赖和源 lineage。归档自身保证完整前缀,故正常追加不要求冻结所有写入;丢失或移动来源只留下 unknown,既有目标也不会被删掉重建。
  2. decodeAuthorityBackupCapture,103 行 检查 Goal、区间、配置摘要和确定的 artifact 路由,复用既有 recovery 状态。它描述的是历史可读性,不创造可执行租约或新生命周期。
  3. inspectAuthorityBackup,133 行 先核对 sidecar 字节,再由原生 owner 验证整个 transition/receipt chain 和 seal,最后把完整投影交给 canonical Todo reader。原生 seal 与文件字节 SHA 各有 verifier,未被错误互换。
  4. verifyStateRecoveryManifest,115 行 将记录绑定到实际成员和配置/runtime,拒绝 duplicate、错配和原有历史上限溢出;同文件的 owner audit 只在没有新字段的旧 v0 才走旧 raw reader。损坏新内容不会被较早副本掩盖。
  5. execute_state_backup_plan,798 行 只为配置选中的 Goal 请求 owner 内容并打包;effect handler 仅登记这个惰性入口,Python recovery adapter 仅传递保存的行。配置专用、历史计划和专用迁移路径保留原契约。

新增两个测试模块验证真实 File/SQLite 导出、独立恢复及原操作回执,并在真实 scan 间插入追加/依赖变化。既有 recovery 测试保留旧格式场景,明确区分“raw 数据库拒绝查询”和“独立原生导出仍可读”,补充新内容损坏不回退以及失源后的 HTTP 上传、检查、历史重读、重复和损坏输入。文档同时说明额外空间、默认读取变化和剩余资格,未新增 UI 开关。

对主干的风险

主要代价是 raw 安全副本之外再保存一份逻辑历史,增加显式备份的 IO 和空间;原有容量与 verifier 上限未扩大,20,000 条历史和溢出拒绝仍通过。第二个有意变化是新捕获失败会明确保持 unknown,即使较早 raw 仍可读;这避免把两次观察冒充同一次 owner 捕获,已在正文和指南公开。普通写入没有被新 helper 接管,来源缺失时也不会初始化 store。

最强负例是 raw 已有效复制后来源消失、以及原生导出/sidecar 损坏而 raw 仍有效。真实 producer 和 inert verifier 均保持未知;实际 selector/fence/identity 移动测试会删除未发布 staging,并保留来源发生的变化。旧 v0 raw reader 有真实持久输入,保留有依据;专用迁移和配置专用流程通过受影响套件,没有添加无调用点的 resolver 或第二个 receipt owner。

语义与 CI 对齐

复用现有 RecoveryComponentState 与原生 archive schema,新行和内部方法是局部组合契约;没有新状态集合、字符串 denylist 或 prose 决策。绑定、容量和无执行权是机器强制规则,额外 IO 是披露的取舍,未混称 guidance。开发期 advisory 显式包括新 TS 文件,提交后全树 semantic 也通过。按 Goal 策略未查询或等待 hosted CI;未运行的远端 provider、非 POSIX、compound worst case、完整 M2/M3/Host 资格保持未验证,不据此给出资格结论。

我的整体评价

对这个可独立使用和回退的原生内容增量给出 APPROVE 自评。long_horizon 为 improved:原源消失后确实可以恢复内容并核对原回执;user_experience 为 accepted_tradeoff:沿用既有入口,增加空间/IO,并准确展示 unknown,无新增设置或授权轮次。单独的原生 CLI 已能导出一个 store,本 PR 的必要增量在于接入一次完整备份的依赖和既有惰性消费者,而不是重新实现 exporter。

最新 main 组合下 142 项相关 Python、43 项 TS、21 项源码目录外安装态检查通过;正常 frontend/wheel、Ruff、mypy、tsc、语义与公开边界检查通过。包构建曾正确拒绝过期 bundle,正常重建后通过,未使用 bypass;风险 canary 为 5 direct + 5 selected,零失败/告警/manual hold。准确质量回执 cqr_88fb20191500ee1922e0 有效,11 文件,safe-fix 允许并执行一次文档修正,0 blocker、0 warning、1 项额外 IO/空间 advisory。完整 M2/M3 与独立 GitHub 审批、合并授权继续分开处理。

English verdict: APPROVE — bounded native-content increment on c462a552b995b4c27972baa7b205e2b17ca2993d (author-owned COMMENTED self-review). Real File/SQLite exports independently restore and audit original receipts after source loss; moved, missing or corrupt native evidence stays unknown. Full M2/M3/Host qualification, independent approval and merge authority remain separate.

@huangruiteng
huangruiteng merged commit 38914dc into main Oct 16, 2026
26 of 27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants