fix(todo): revise declarations and edit complete requirements in place

[loopx-agent]

Correcting an owned Task should not require lease bookkeeping or copying truncated requirements into another form. Workbench now offers Edit requirements → Save requirements in the existing Task inspector: it loads the complete source, prepares/applies the existing typed action internally, and verifies the stored text. One save is the write decision; concurrent changes retain the draft, and a lost successful reply is reconciled from the original action journal.

The same proposal repairs declared work requirements: a hard-lease owner can revise repository/scopes/capabilities and retire the old grant atomically, then continue notes, pause/resume, deferral and later corrections without acquiring execution. Editing requirements prose preserves the current lease. Changing execution declarations retires it and still requires fresh admission for future execution. Saving text grants no execution and starts/stops no process.

Journey and ownership

Before: complete requirements were readable but not editable in the inspector; the bounded list omitted text after 500 characters. Ordinary declaration corrections could leave administration blocked by old repository history.

After: open the owned local Task, edit its exact body, save once, and read back the same source. Preparation absorbs provider revision and registry fingerprint; the user supplies no lease key or protocol fields. A stale source is refused before writing, an intervening commit still fails native CAS, and the original draft remains available for comparison. During editing, the save action replaces competing management/completion controls; cancel/save restores them. Desktop keyboard and 390px paths return to the same Task without a generic approval page.

The existing TS canonical Todo/lease/CAS/receipt owners remain the decision authority. Python echoes the existing canonical update basis and adapts the existing Chat transport; no second decision owner/provider is added. The bounded refactor shares one update-basis decoder and one Task-target check across apply/recovery, and returns the actual typed action outcome to the editor. Unchanged caller paths retain their prior presentation. This follows the ordinary-operation contract in canonical lease lifecycle and the roadmap's S3/S5 ownership boundaries.

Compatibility: optional todo.update.review_basis reuses loopx_chat_canonical_update_basis_v0. Source-bound text uses the existing action journal's 8,000-character envelope; quick edits without that basis keep the 400-character bound. Oversized bodies remain fully readable and cannot be truncated into a save. Legacy, remote, unidentified, unassigned and unavailable sources remain read-only. The existing Todo apply path additionally reconciles missing successful responses through its original journal; it does not repeat the business mutation. CLI declaration behavior changes are explicit in the bilingual reference; Lark actions are unchanged.

Visual evidence

Actual packaged first view while editing a long synthetic Task; the textarea is scrolled to its final acceptance clause. The workbench's existing chrome is unchanged. The original body is shown once, with the exact target owner available below. No private Goal, benchmark trajectory or production state appears in these screenshots.

At 390px, a real intervening canonical write is refused and the draft remains intact. The recovery control reads the current requirements before another save; no false success or horizontal page scrolling.

Validation and limits

Current head: 6b5d24b1b03fd95a3cd4c598cfaab8425c2a9409; main baseline: cd148933bb0cb00232cb3cc494f898a171ffe36c.

• Real File/SQLite CLI/Chat/HTTP suite on b05ed149137d6c8457c5ff7c71a5b15affed9e88 (backend and tests unchanged since): 20 passed, covering complete body and tail, side-effect-free preview, applied replay, stale-source refusal, malformed basis, prior quick-edit bound, concurrent writers, and preserved hard lease. The four exact-source cases passed again after adding the 8,001-character refusal; original text is never truncated. The initial pre-fix source read failed its missing-basis regression. An invalid write-test fixture was replaced with the existing canonical creation fixture; no delivery check was relaxed.
• Fresh bundle build/source verification and full packaged task-inspector-return passed on the current head. Its new editing path uses a real disposable File authority and Chat HTTP backend for one-save readback, conflict/draft recovery and dropped successful responses. Even when the journal is also unavailable, repeated readback attempts retain the original operation; reconnect reads its receipt with no additional apply. Navigation/status is synthetic. Exact-reader error/mismatched identity/late response and pointer/keyboard/focus recovery also pass on desktop/390px. No active Goal is a fixture; no model or benchmark job is launched.
• Full packaged typed-actions regression passed on the current head alongside the exact-source editing scenario. Dashboard typecheck, CSS token check, changed-Python Ruff, advisory-before-full semantic inventory, 26-path public-boundary scan, bilingual RFC check, diff checks and all nine DCO trailers passed.
• The existing declaration-owner qualification at 4085d78ce527ab6254f1e6a56dbfb6889917cfd6 remains separately identified: 178 Python cases and 596 TS cases including disposable real PostgreSQL 16.15. Its five production TS files are unchanged in this update. Those counts, its earlier quality receipt and premerge result are not new-head reruns or independent approval.
• Current-head independent review, remote CI and exact-head quality/premerge qualification remain separate. The packaged build retains its existing large-chunk advisory. Installed-App adoption, live-model behavior, complete task-management coverage and broader Lark/frontend declaration editing remain unverified continuation boundaries. This PR is a normal completed author proposal; no merge, installation or release is claimed.

Author: OpenAI GPT-6 family; exact serving variant not verified.

[loopx-agent]

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

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

Exact head: 796d1b8

动机

执行者已经领取过任务，随后需要纠正任务的仓库、写入范围或能力声明。
旧入口在保留租约后拒绝修订，释放租约也不能解除要求有效执行证明的死结；当前 head 让首次修订成功，但修改仓库后，继续改备注、暂停或再次修订仍被旧仓库历史挡住。
独立 CLI 已确认首次范围修订、旧授权释放及新授权读回；仓库修订后的继续管理失败，尚未得到可持续使用的完整结果。
本次评审不认证 Workbench 要求编辑、打包或安装后的 App、进程终止、跨主机持续运行，也不授予合并或升级权限。

这不是要求用户先完成整个前端或跨主机迁移再修 CLI。原有公开参数确有可复现的死结，修复有价值；阻断项是本次新增的合法仓库状态随即破坏已有的普通本人操作。

改动思路

修订与旧授权退休必须在同一 provider CAS 内完成；沿用现有 Todo、lease 与 receipt owner 比新建 grant、工作流或 Python 决策源更小且更可回滚。
当前 PR 的合理边界是既有 CLI 与共享 Todo owner 的完整修订事务；Workbench 的呈现绑定及安装采纳可由现有责任人继续，不能把它们当成本次源码结果已完成。

四个生产文件各有明确责任：新 lifecycle helper 识别有限修订意图并计算旧授权退休；admission 仍先检查注册、认领、绑定和排除；原 update owner 负责当前 head、规范化、预览、来源复核与 CAS；recovery 只给诊断，不刷新错误 proof 或自动领取。新 receipt 字段保存本次修订结果，重放返回历史结果，不恢复执行权。

当前缺口出在两个正确局部规则的组合：仓库修订应保留旧授权的仓库；但这个旧授权已经 released，不能再把它与新声明不同当作普通管理操作的执行冲突。源码中的 repository 比较没有区分这两种用途。

同一已注册、仍持有原 claim 的执行者	独立观察
活跃或已释放旧租约后的首次范围修订	基线四例失败，当前 head 四例成功；旧授权释放，新领取仍单独准入
仓库未变时，释放后改备注或暂停	基线、head 各四例成功
A 上领取，声明改为 B，随后不领取而继续管理	head 的四类后续操作均拒绝；File/SQLite CLI 与三种真实 provider 一致

表格是已执行的对照摘要，不把作者测试声明或历史批准当成本次验收。

具体改动

关键代码讲解

• isOwnerWorkRequirementsRevision 复用七个既有工作声明字段，只允许 agent 的 open/blocked/deferred 本人或未认领任务，附带普通 text/note/priority/evidence/reason；ownership、依赖、终态和验证转换仍走原 owner。
• workRequirementsRevisionRejection 核对保留 owner、claim 和 repository；第 37–38 行对已经 released 的旧仓库仍拒绝，形成下述 P1。显式 proof 则在外层先按当前有效代际严格校验。
• planWorkRequirementsRevision 比较规范化后的声明，实际变化才调用既有 release materializer；相同要求保留原 lease，修改不改变原 key、版本、epoch、scope 和冻结仓库。
• executeCoordinationTodoUpdate 将 Todo 修改和退休 mutation 放进同一 CAS；预览不写，原 receipt 的重放恢复 transition，原 operation id 改意图仍拒绝。task_lease_proof.ts 的新增内容只解释失败恢复，没有代办 acquire。

完整差异是九文件 +324/-8：四个生产文件、四个验证文件和一份文档。测试把旧的 blanket-rejection 断言改成原子退休及无关任务/lease 不变的正向断言；文档中英均披露仅 hard-lease 改默认行为，soft-claim 不变。

评审在读实现前采用既有 docs/reference/canonical-lease-renew.md，固定规范修订 04b929a；没有用本 PR 新写的修订章节反证实现正确：

• Repository-relative scope identity：已实现；旧 grant 的仓库与 scope 保留，新 acquire 绑定新声明，不能改写历史或从 cwd 推断仓库。
• Ordinary task operations：未满足；本人备注、暂停不应要求领取执行租约，仓库修订产生的新状态让这两条既有路径失败。修复要求见 P1。
• Commit, retry and readback：已实现；当前 provider CAS、原始 receipt、相同意图重放、变更意图拒绝及丢响应/并发测试通过。
• Provider and delivery boundary：源码边界已覆盖；共享 TS owner 和真实 File/SQLite/PostgreSQL 已核验，Workbench 呈现和安装采纳继续保留，未把 provider 成功当作完整产品迁移。

对主干的风险

[P1] 已释放的旧仓库历史仍阻断后续本人操作

在仓库 A 上领取 lease，执行本 PR 支持的 todo update --task-repository B 后，Todo 已是 B，旧 lease 正确地保留 write_repository=A 并变成 released。此时同一 owner、不带执行 proof，再调用 --required-write-scope、--note、--status blocked --reason ...，或把仓库再纠正为 C，全部返回 lease_repository_divergence。拒绝不写状态或回执，但工作也无法继续管理。

根因是新 helper 第 37–38 行无条件把历史 repository 当作当前执行仓库；普通 copy/pause 的既有 admission 也会拒绝该新产生的 A/B 组合。备注恢复甚至建议 acquire 新 lease，重新引入本 PR 正要消除的执行准入舞步。若 B 仍需纠正，不能把“先取得 B 的新执行”当作正确恢复。

在既有 typed owner 中区分本人已释放的历史仓库与当前执行约束：保留旧仓库/key/version/epoch/scopes，不为普通修订、备注或暂停强制领取新执行；继续拒绝外来历史、错误显式 proof 和真实有效执行的仓库漂移。
在现有行政 CLI 与跨 File/SQLite/真实 PostgreSQL 测试中加入 A 上领取→修订为 B→不领取新租约而改范围/备注/暂停/再次纠正仓库；这些操作应成功，旧历史不变，旧 proof 仍拒绝。

独立验证保留正反两面：七个完整 Python 模块 90 passed；九个 TypeScript 模块 1267 passed、0 skipped，包含完整真实隔离 PostgreSQL 16.2、File/SQLite conformance、行政修改、repository、soft-claim 和重放。相同私有 CLI harness 在基线四个原缺陷案例失败、四个旧行政控制成功；head 八个正向/控制通过，但新增继续管理的八例全部失败。独立 native harness 又在三种实际 provider 中各复现四种拒绝，三个语义测试失败。当前 P1 没有被测试数量或通过的首步覆盖掉。

控制面类型检查、Ruff、DCO/diff、双语 RFC 检查、advisory 后的完整语义扫描通过。标准 premerge 的五个直接检查和十八个选定检查均通过，九路径公开边界扫描无命中；总体仍退出 1、quality_stale_receipt，评审工作区旧范围质量回执未获本次资格，不能称整个门禁通过，也不据此否定作者其他工作区的回执。首次辅助验证的路径/fixture 准备错误已保留并修正，未删除断言或放宽预算。依策略未查询 CI。

语义与 CI 对齐

工作声明复用既有 typed vocabulary，work_requirements_transition 是既有 Todo result/receipt 的可选语义扩展，不是新 capability 或权限。静态 advisory 无候选不证明语义等价；当前明确违反的是已释放历史与普通任务操作的边界，需在同一 typed owner 修正并补连续操作回归。显式错误 proof、外来 holder、注册撤销、CAS 竞争、默认 provider 和 soft-claim 的约束应继续保持。对照的四十二个未变 soft-claim/输入契约测试在基线也全数通过。

我的整体评价

REQUEST_CHANGES。真实旧死结得到部分修复，代码放置与规模合理，四个生产文件没有新增平行 authority。长期工作的判断为 regression：首次提交后形成的合法状态阻断后续修订；用户体验同样为 regression：连备注和暂停也要重新争取执行资格。修好当前 P1 后再做完整 exact-head 复评，不应只补一条首次成功测试。

面向下一次变更的简化检查认可当前 65 行生命周期 helper 的局部归属；下一步应在现有 repository/行政 admission 边界表达“当前授权”和“保留历史”，无需另建框架、绕过验证或把旧仓库改写成新仓库。Workbench 后续绑定的分期边界合理，当前未完成之处仍由既有责任人接续，不是增加一个新审批关卡。

历史经验中“走到有用结果与后续继续”的建议已用于本次连续操作反例；它只是审查方法，未继承旧结论，也没有证明记忆调用改善质量。安装后的界面、真实模型、进程 drain 和长期部署仍未验证。

English verdict: REQUEST_CHANGES - 796d1b8 fixes the first hard-lease requirement revision, but changing repository A to B leaves released A history blocking later scope edits, notes, pause and another correction. Independent File/SQLite CLI and real PostgreSQL/File/SQLite owner probes reproduce the dead end despite 90 Python and 1267 TS tests passing. Preserve frozen history and strict proof/foreign-owner fences while restoring inert owner operations; CI was not consulted.

[loopx-agent]

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: 4085d78

动机

受影响的是已经领取任务、随后需要纠正仓库或工作要求的任务 owner。原来即使只想补充写入范围，也可能必须先领取、修改、释放；此前版本虽允许首次修订，却把 A 仓库的已释放历史当成 B 仓库当前执行约束，导致随后改备注、暂停或再次纠正仓库也失败。
本 head 的可观察结果是一次事务修订声明并退休旧授权，然后同一 owner 可以继续普通管理；需要实际执行时再独立取得新授权。
剩余缺口是 Workbench 工作要求编辑、安装后的采用以及更广的任务旅程；本次只资格化既有 CLI、Chat API 和共享 owner 的完整前置事务，不把源码修复当作这些后续工作已完成。

这是合理的 CLI/共享规则增量，直接解除现有参数的死结。没有要求用户为改备注取得执行权，也没有把要求变更当成自动授权或终止进程。

改动思路

声明、执行授权与保留历史是三个不同用途。任务声明可以由合法 owner 修订，旧 lease 的 key、版本、epoch、scope 和冻结仓库必须保留；它已经 released 时，普通管理不应再拿其旧仓库阻断当前声明。实际执行仍走严格仓库和有效 proof 校验。

架构判断是保留现有 TS Todo admission、work requirements、release materializer、repository rule、provider CAS 与 receipt owner。新增生命周期 helper 只规划声明变化及旧授权退休；三个行政调用者共用一个很窄的 released-history 判断，执行路径继续用原严格规则。这个边界完整覆盖“首次修订后还能继续管理”，也便于独立回滚，没有新增 store、Python 决策源或自动 acquire。

同一已注册、仍持有 claim 的 owner	本轮实际结果
有效或已释放旧授权后修改范围	base 四例失败，head 四例成功；旧授权退休，fresh acquire 独立准入
仓库未变、释放后改备注或暂停	base/head 四个控制案例均通过
A 上领取，声明改 B，再不领取而改 scope、备注、暂停或 B→C	head 的八个真实 File/SQLite CLI 反例全部通过
File、SQLite、真实 PostgreSQL 的同一连续操作	三个独立 native 场景全部通过，均保留旧冻结仓库
旧 proof、外来 holder、未释放的仓库漂移或冲突 CAS	当前完整 provider 测试保持拒绝和无副作用

表格绑定上述精确 head，记录实际执行比较；旧版本结论没有被当作当前通过证据。

具体改动

关键代码讲解

• isOwnerWorkRequirementsRevision 复用既有七个工作要求字段，限定合法非终态 agent Todo 及 owner。允许普通正文、备注、证据、原因和优先级随行，归属、依赖、验证和真实状态转换仍走各自 owner。
• workRequirementsRevisionRejection 与 ownerAdministrativeRepositoryRejection 区分同一 claim owner 的 released 历史和当前执行约束。先验证仓库字段，再仅为这个历史分支豁免 divergence；损坏值、他人历史与未释放的漂移仍拒绝。
• planWorkRequirementsRevision 在规范化后比较原要求，真实变化才使用原 release materializer；完全相同的要求不退休 lease。转换结果是派生回执，不是另一份授权。
• todoUpdateAdmissionRejection 保留公共注册、claim、binding/exclusion 及显式 proof 准入；proof 只要被提供，就仍固定精确的当前有效代际，不会静默换成无 proof 请求。普通备注、延期与暂停才使用上述行政历史规则。
• executeCoordinationTodoUpdate 把 Todo 修改、lease 退休和原 receipt 放进同一 CAS。预览不写，原 operation 重放返回历史 transition，不撤销后来工作；recovery 文本只指导检查，不代办执行。

完整差异十文件 +444/-11，包含五个生产文件、四个测试文件与一份双语参考文档。测试不再把所有要求修改笼统视为错误，而验证真实退休、连续操作、无关数据不变、错误 proof、外来历史、注册撤销和 CAS。文档明确披露仅 hard-lease 的默认行为变化，以及 soft-claim 不变。

评审先读固定的 docs/reference/canonical-lease-renew.md，规范修订 fdf03ec，再读实现：

• Repository-relative scope identity：已实现。原仓库与 scope 是不可变历史，新执行绑定修订后的仓库；行政编辑不把旧仓库改写为新仓库。
• Ordinary task operations：当前 head 已实现旧 P1 缺失的连续管理。独立 CLI 与三 provider 反例覆盖 A→B 后继续 scope/note/pause/repository；完整旅程还覆盖恢复、延期、再次恢复和 fresh acquisition。
• Commit, retry and readback：已实现。现有 provider CAS、原意图 identity、预览、历史 replay、丢响应及并发约束保留；历史 replay 不恢复旧执行权。
• Provider and delivery boundary：当前 CLI、Chat API 与共享 File/SQLite/PostgreSQL 规则已验证。Workbench 要求编辑与安装采用继续保留，不能从 provider 成功推断更广任务迁移完成。

对主干的风险

最大风险是 released-history 例外渗入执行准入，或为了让管理继续而改写旧 lease。当前 helper 仅由三个行政判断使用；显式旧 proof 仍严格拒绝，未释放的漂移即便已过期也不被放过，foreign/corrupt/excluded/bound/CAS 负例保持不写。真实仓库修订后，新 acquire 才冻结新仓库和新 generation。暂停或修订不会停止外部进程，后续 effect fencing 仍是独立责任。

本轮七个完整 Python 模块 90 passed，覆盖真实 CLI、Chat 准备/采用与 stale-basis 拒绝；九个完整 TS 模块 1288 passed、0 skipped，包括真实隔离 PostgreSQL 16.2、File/SQLite 与完整 planning conformance。额外相同私有 CLI harness 在 base 的四个原缺陷案例失败、四个控制通过；本 head 的十六例全部通过。原 private native counterexample 也在三种真实 provider 中全部通过。PostgreSQL 的自有实例已停止，端口及 PID 读回关闭。

基线的四十二个 soft-claim/公开输入用例与 head 中同一组均通过。控制面类型检查、Ruff、advisory 后完整语义检查、双语/diff、五个提交 DCO 和十路径公开边界扫描通过。标准 premerge 的 5 个直接检查与 18 个选定检查通过；总体仍退出 1，评审工作区的 quality_receipt_missing 没有被作者另一 checkout 的 CQR 替代。

另外，tests/control_plane_ts/content_digest_single_owner.test.ts 在固定 base 与本 head 均 16 pass / 1 fail，失败身份和详情同为 trajectory_assessment.ts:41 的重复摘要匹配。测试及因果源文件逐字节一致，本 PR 的声明/lease 管理不经过该 matcher；改动不引入这项失败。它仍是需要原 owner 修复的红项，并未修改断言、限额或例外名单。

既有 Workbench 的普通任务恢复入口和目标变更模板已检查：后者不是本次单任务要求编辑器。没有新增 UI 源码、首页或 CTA；本轮没有重新执行浏览器和安装后的 App，作者的打包场景声明没有替代独立 CLI/Chat owner 证据。本轮未获取或等待 CI，未合并、安装或撤销历史 review。

语义与 CI 对齐

本次复用既有 Todo 状态和 work-requirement vocabulary，work_requirements_transition 在原 result/receipt 上描述派生变化，未新建执行权 owner。三个行政调用者共享 released-history 例外，strict repository fence 留在执行侧。hard-lease 默认行为变化在双语文档和相应测试名中公开披露；说明文字没有把强制 proof/CAS 约束降为 guidance。上述基线红项、评审 CQR 与原生合并门禁仍独立保留。

我的整体评价

APPROVE 当前精确 head，旧 796d1b8 上的 P1 在新 head 已由同一独立反例和完整三 provider 旅程验证修复。长期工作判断为 improved：纠正声明后可以继续管理，原请求可重放，历史不会复活。用户体验判断也为 improved，范围是既有 CLI/Chat owner 的普通管理减少无意义的 acquire/edit/release 操作；更广 Workbench 要求编辑和安装采用仍未交付。

面向下一次变更的简化检查已应用：保留 65 行生命周期 helper，并把三处对 released 历史的判断集中于既有 repository owner；没有新建 grant 框架、迁移 store 或第二个 Python 规则。当前前置事务可以独立验证和回滚，其余产品入口由已有任务 owner 接续。

历史经验中“首次成功后还能继续有用工作”的建议用于本次连续操作验证，不继承旧 verdict，也不把经验送达或测试数量当作交付价值。旧公开 review 记录保留；本次源码批准不等于替用户解除所有历史讨论、基线失败、CQR 或 merge-readiness，更不授予合并权限。

English verdict: APPROVE - 4085d78 repairs the prior repository-history dead end while preserving immutable leases and strict execution proof. Independent 90 Python, 1288 TypeScript tests with real PostgreSQL16.2/File/SQLite, sixteen CLI probes and three native continuous-operation probes pass. The identical base/head digest-owner failure and reviewer CQR remain separate merge holds. Broader Workbench/installed adoption is still open; CI was not consulted and no merge is authorized.

[loopx-agent]

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

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

HEAD: 6b5d24b1b03fd95a3cd4c598cfaab8425c2a9409

动机

受影响的是在工作台打开已有本人任务、需要纠正完整要求的用户，以及修订执行声明的任务 owner。此前详情可读完整正文，却不能原位修改；列表只保留前500字符。声明修订还可能被已经释放的旧仓库历史挡住，迫使用户处理与修改要求无关的执行租约。本 head 在原任务详情中加载完整原文，一次保存沿原 typed action 提交并精确读回；并发冲突保留草稿，丢响应沿原操作恢复。普通正文修改保留租约，执行声明修订才在同一事务中退休旧授权。保存不启动或停止进程，不授予执行、合并或安装权限；工作要求声明的更广前端与Lark配置、实际安装采用不在本次通过范围。现有产品责任人仍须继续更广的声明编辑、Lark与安装后采用；这些不被本次正文编辑和共享事务的通过替代。

先读不可变规范：docs/reference/canonical-lease-renew.md，版本 cd148933bb0cb00232cb3cc494f898a171ffe36c，并对照同版 overall roadmap 的 S3/S5/R5 与测试预算规则；没有用本PR新写的文档为自己作证。逐项判断：ordinary_administration：Ordinary task operations: owner copy/pause/resume must not require an execution grant.（implemented）；frozen_execution_history：Repository-relative scope identity: preserve old repository/generation and require fresh execution admission.（implemented）；cas_and_original_recovery：Commit, retry and readback: preserve original operation, provider CAS and strict explicit proof.（implemented）；packaged_task_correction：Roadmap S3/S5: ordinary Task correction reaches a usable packaged interaction with failure recovery.（implemented）；installed_adoption：Installed/Lark and broader declaration-editing adoption remain separate.（deferred）。

改动思路

架构判断是保留原 TS 决策、Python 来源观察与传输、前端交互的边界；正文编辑直接消费既有 action，声明修订在同一 update owner 内退休旧授权，不增加工作流或任务数据库。当前边界同时交付普通正文编辑的实际页面旅程和原有 CLI 声明修订事务；更广声明配置与安装采用继续由既有产品任务承担，不把后端或截图当作整项迁移完成。

普通意图	现在的路径	保留的边界
修改完整正文	原详情读全文→一次保存→精确读回	不取执行租约，不增加确认页
修订仓库/范围/能力	同一事务改声明并退休旧授权	新执行仍独立准入
并发或回复未知	保留草稿、原proposal与journal，先读回	不借旧proof，不重复业务写入

具体改动

完整26路径均已检查。现有数据adapter导出复用 update-basis decoder，Task详情HTTP提供同一canonical来源的观察；三处Python只规范化可选echo、校验来源并调用原Todo owner。五个生产TS文件完成有限声明修订分类、同CAS退休、transition回执重放及released仓库历史的行政例外；前端、双语参考、既有消费者测试、打包场景和两张合成截图属于同一旅程。

关键代码讲解

• TaskRequest：Loads the exact source and manages only a per-open draft; one save, conflict, original-operation retry, cancel and8000 limit.
• onSaveTodoRequirements：Reuses preview/apply and verifies goal/todo/text when reading the original journal; no new operation during unknown readback.
• isOwnerWorkRequirementsRevision / planWorkRequirementsRevision：Classifies the narrow existing owner intent, compares canonical requirements and uses the existing release record inside the same CAS.
• ownerAdministrativeRepositoryRejection：Validates history first; only the same claim owner with a released grant may administer the revised repository.

对主干的风险

没有发现本范围阻塞。独立当前头138项Python、1262项TS全部通过，TS包含真实隔离PostgreSQL16.15、File与SQLite，0 skip；服务在用后停止。另用同一真实HTTP脚本对照：主干File/SQLite均没有basis且拒绝新echo，本头两种provider均经preview/apply保存900+字符并精确读回。新正文路径不替代400字符quick edit，8001字符及伪造/陈旧basis仍拒绝；正文不退休原lease，声明修订才退休。外来holder、旧/不完整proof、并发CAS、注册撤销、scope及repository历史由完整provider用例保持。

实际打包后用Ego走1280桌面键盘保存和390px冲突恢复：682字符原文与500字符摘要分开，末尾验收不丢；保存一次提交一次；并发写先拒绝且保留草稿，读取当前来源后再保存。真实提交后的502替代回复与journal同时不可读时，重试只读原proposal；恢复后读回原receipt，无第二次apply，0模型Turn。8001字草稿保留、保存禁用，取消不改源。另保留TCP断线时浏览器对同一proposal的HTTP重放观察：原操作未变，canonical写入仅一次；不把这当作页面自身读回分支的证据。

全视口与两张公开合成截图已检查，目标/owner、正文、保存结果和窄屏错误可读，无横向滚动；状态/导航为合成，实际编辑为独立真实File authority与HTTP，非安装态。标准premerge6direct+19selected、bilingual、DCO9提交和26路径公开扫描通过，0 manual hold。source advisory先于完整semantic检查。相关整理复用原decoder和目标校验；不加协议wrapper或第二决策源。

soft-claim及未带新basis的调用保持原路径；新增owned/local/canonical编辑与hard-lease声明规则是明确披露的默认行为改变，不冒称所有输入语义完全相等。当前引用文档的中英内容一致；更广声明前端、Lark、安装及真实模型采用保持未验证。旧4085批准不继承，原已修复的released仓库finding也按本头完整规则和现测重新核对。

我的整体评价

APPROVE。普通修改要求不再要求租约记账或第二轮确认，同时原CAS、claim、显式proof和执行边界仍有效。复用原 TS Todo/lease/CAS 与 Chat journal；有界整理将 update-basis 解码导出复用，并让 apply/recovery 共用目标核对，避免另一份状态或执行 owner。当前边界同时交付普通正文编辑的实际页面旅程和原有 CLI 声明修订事务；更广声明配置与安装采用继续由既有产品任务承担，不把后端或截图当作整项迁移完成。

English verdict: APPROVE - HEAD 6b5d24b; exact-source one-save editing and original-operation recovery verified on packaged UI and real File/SQLite HTTP;138 Python and1262 TS including real PostgreSQL pass. Broader Lark/installed adoption remains separate.