feat(goals): commit governed local work with immutable intent and recovery

[songoow]

Goal And Delivered Outcome

Stage 2 retains amendment proposals but cannot commit shared intent and new work together. This adds the alignment RFC §9.2 bounded local transaction: an owner freezes the original Goal and a fixed work template; a registered peer proposes and commits one unclaimed Todo with the Goal revision and original receipt in one CAS. Existing work/leases remain unchanged. The packaged settings page configures and reads the same owner, including response-loss recovery and peer/replan adoption.

• Basis: alignment RFC §9.2 at the implementation baseline.
• Before → after: proposal-only retention → immutable root/policy, exact-lifetime template commit, explicit peer rebase and existing claim/replan consumption; proven by the native CLI/HTTP, provider and packaged browser rows below.
• Related to [RFC]: Align peer Agents through shared Goal intent, per-Agent frontiers, and governed amendments #3836; base main. This does not close the parent RFC.

Author Declaration

• Written by: model_agent — GPT-6, OpenAI.
• Specification and revision: shared-goal-alignment-and-governed-amendment-v0, §9.2 at c504ffdb4; existing Goal lifecycle, new-Goal storage, Todo claim/lease and receipt owners.

Criterion	Disposition	Implementation	Evidence
§9.2.1 original root/policy and lifetime	implemented	goals/goal_amendment_authority.ts, source creation receipts	Native creation; root-shrink/retirement negatives; operator HTTP
§9.2.2 automated in-policy work commit	implemented	Existing Todo planner inside one Goal authority CAS	Real File/SQLite/PostgreSQL; one unclaimed Todo and original receipt
§9.2.3 refusals preserve unrelated work	implemented	Exact source witness, lifecycle fence, policy and work digest	Stale instance/basis, malformed stored proposal, existing peer lease
§9.2.4 ambiguity/concurrency	implemented	Existing command receipt and provider CAS	Response loss, same-id replay, competing commits, capacity refusal
§9.2.5 causal consumption and peers	implemented for explicit CLI operations	Existing claim owner, replan observation and per-peer basis	Native two-peer isolation; packaged readback before/after claim/adoption
§9.2.6 packaged journey	implemented for local CLI/settings	Existing Goal ownership settings and bounded HTTP	Installed wheel, real registration/SQLite/HTTP, EN/ZH, reload/retry/narrow view
Request-derived §5.1 and broader automatic adoption	deferred	Existing RFC owner	Source-context requests refuse; no reservation/abort or general Turn/Vision activation

Follow-up acceptance found and repaired three gaps: successful no-op claims now retain success, missing canonical state is not reported as successful inspection/mutation, and existing causally bound work can reacquire an expired lease without reopening settled replan. The typed Goal owner now supplies success to CLI/HTTP; existing lease rules still govern continuation.

Self-check: read the owning source paths and negative cases, ran affected real-backend/entrypoint checks, and retained the failed-check disclosures below. The related refactor moves the existing Python storage/source transport into coordination; target policy, empty-source admission, fences and recovery stay TypeScript-owned. Active callers were updated and the old internal entrypoint removed.

Scope And Continuation

Complete for the explicit local source-session/File/SQLite template path. project register --canonical-storage file|sqlite opts into the existing fresh-authority initializer with hard leases; omission preserves lifecycle-only creation. Initial creation receipts now add original root_commitments; old receipts are not backfilled. Generic runtime refusal, historical Stage 2 behavior and existing request hashes without a replan binding remain intact.

Automatic Turn/Vision integration, Lark interaction, request-derived commit, protected/acceptance changes and live-model collaboration remain with the existing alignment RFC/roadmap S3/R4 follow-through. This independently testable boundary neither promotes an existing provider nor activates those paths. Disabling new operations retains historical readers and fences; committed state requires forward lifecycle reconciliation.

Validation

• Revision: 8ddedecb288788961a479a28395698d68dfea8ca (final product source; existing storage/default-path evidence reused only after checking unchanged owning code).
• Run state: finished. Input classes: synthetic, public_fixture.

Kind	Result	Evidence / limits
real_backend	passed	Isolated PostgreSQL 14.20: 355 tests, no skips; amendment owner plus existing authority integration suite
real_entrypoint	passed	Latest amendment/HTTP/legacy-CLI regression set: 45 tests; earlier native source/creation set: 40 tests; actual project register creates File/SQLite authority without test-only seeding
real_entrypoint	passed	Storage/HTTP/denial set: 67 passed; 12 failure-injection cases initially targeted the moved module, then all 12 passed after moving injection to the new transport
real_entrypoint	passed	Normally built, separately installed wheel; goal-amendment-browser-smoke.mjs runs real creation, directory discovery, operator configuration, original-operation recovery and peer CLI commit/lease/adoption; no mocked HTTP responses or models
regression_parity	passed	Same native CLI harness at baseline c504ffdb4 and product head: old source creation, generic source refusal and legal legacy proposal list agree; additive original commitments checked separately; only generated timestamps/lifetime identities normalized
static	passed	TypeScript checks, changed-Python Ruff, focused mypy (three transport modules), semantic vocabulary/census and paired RFC checks
integration	passed	Risk-based premerge: 19 checks, zero blocking failures; one baseline maintainability advisory
static	failed	Maintainability advisory: untouched goal_frontier/__init__.py is 2007 lines against 2000 at both clean baseline and candidate; no ceiling changed
static	failed	Broad transitive mypy reports repository-wide errors; it is not represented as a full-tree typecheck pass. Focused changed transport checks passed
manual	passed	Inspected synthetic preview, unknown-response recovery and narrow readback screenshots; no installed user App replacement

The two blocked-progress observations used by the browser fixture are synthetic. The real replan owner derives and consumes their obligation; this is not evidence of live model execution. CI, merge authorization, deployment and operational promotion remain separate.

Frontend / Visual Evidence

• UI impact: changed. Before: N/A for the new disclosure inside existing Goal ownership settings.
• After: reviewed policy, unknown response and recovery, narrow current-result readback.
• Source data: synthetic. Desktop and narrow layouts, unavailable companion settings, invalid input, frozen preview, unknown reply and settled/pending readbacks exercised.
• Attention/craft: original commitments and the authorized operation are together; reuse existing settings tokens/fields, show uncertain outcomes explicitly, retain one original-operation recovery path, and keep peer registration/adoption distinct from liveness or completion. No homepage/hero/opening-navigation changes.

Type / Area / Direction

• New feature; related transport refactor; documentation and durable validation.
• Control plane and existing frontend; shared Goal authority / S3-R4.

Shared-authority RFC fixture impact

• Schema/dimensions: exact GoalRef, immutable root and policy, proposal/work digests, revision, existing Todo/lease preservation, same-operation receipts, per-peer adoption and exact replan consumption.
• Providers: File/SQLite through real native entrypoints; File/SQLite/PostgreSQL typed-owner conformance. No provider promotion or routing cutover. The legacy CLI parity above covers the retained read boundary; no production-scale shared-host rehearsal or live-model qualification is claimed.

Boundary Checklist

• Public product code/docs and synthetic screenshots only; no credentials, private state, local paths or raw traces.
• Existing owners and RFC continuation reused; no duplicate benchmark work.
• Visual evidence included; all five commits carry DCO sign-off.
• No merge, deployment, user App upgrade or live-model experiment performed.

[songoow]

Reviewer: model_agent — GPT-6 / OpenAI (self_reported).

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

未发现阻塞性问题。本次审查针对 6323@8c7cdc8907e896899e75e68748b1806180a2ec6c 的完整变更，结论是有价值的有界增量，不代表父 RFC、上线或真实多 Agent 协作已经完成。

动机

维护者和已注册的本地 Agent，需要在保留最初目标的前提下，把经过预授权的改进变成可执行工作。

以前提案只能留存，无法把共享目标版本和新任务一起提交；回复丢失时，也缺少这条变更路径自己的可回读结果。现在固定一个允许的工作模板后，可以原子创建未认领任务，并用原操作恢复结果。

已验证原目标不被缩小、既有任务和租约不变、同一操作不会重复创建任务；界面能看到当前版本、实际采纳和仍待处理的 replan。

本批次仅交付显式本地 profile 的固定模板变更；不授予执行权限，不做 provider 迁移、部署或整 Goal 完成判定。

自动 Turn/Vision 接续、Lark、request-derived 事务和真实模型协作仍未完成，继续由既有 RFC 的后续阶段承担。

依据是 docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md，固定接受版本 c504ffdb4e788e495e7b9010f2b7cc9c055b591b，以及 #3836 的原始目标与讨论。本次没有用新增文档反向替代原验收条件。

改动思路

把不可推导的原始承诺和预授权放进既有 canonical Goal head，复用 Todo planner、CAS、回执和 claim/replan owner；Python 只保留来源与锁的传输适配，避免第二套决策规则。

当前 PR 的可交付边界是原生创建、固定 root、提交新工作、认领和回读的完整本地流程；它没有把后续自动协作阶段包装成已经完成。

仅保留提案无法补上原子提交；单独调用 Todo create 再改 Goal 会留下中间状态。采用固定模板而非任意自然语言变更，减少了首批 policy/verifier 的判定面。实际新 Goal 初始化原先只在 fixture 中准备；现在显式注册入口复用已有真实初始化事务，CLI 和安装包界面均走通。相关 Python 适配迁回 coordination，目标选择、空来源、fence 和恢复决策仍由原 TypeScript owner 执行；没有第二个存储或同步 ACK。

具体改动

原规范条目	本 head 的处理与证据
9.2(1)	创建回执保留原始声明；root/policy 不可变。删掉原始承诺等式校验的隔离 mutant 使 File/SQLite 两个真实 CLI oracle 均失败；原 head 正常拒绝缩小目标。
9.2(2)	executeGoalAmendment 复用 Todo planner，在一次 CAS 写入任务、Goal revision、事件和原回执。新任务仍未认领。
9.2(3)	原始 GoalRef、源码见证、生命周期 fence、完整工作基线和 policy 逐层验证；已有 peer 任务/租约保持不变；HTTP 拒绝外部 Origin、越工作区和 Agent 冒充字段。
9.2(4)	真实 provider 丢响应、同操作重试、竞争提交和容量拒绝验证；已提交历史不因后续状态而被重写。
9.2(5)	新版本后必须实际 adopt；claim 复用原租约 owner 并绑定精确 replan。另一身份的认领不能代原提案者结算；安装包显示 pending → 实际采纳/消费后的当前结果。
9.2(6)	原生注册、真实 SQLite/HTTP、正常 wheel 的独立安装、浏览器中英文/窄屏/刷新恢复及 peer CLI 回读；共享 claim 改动另跑隔离真实 PostgreSQL。
5.1	request-derived reservation/commit/abort 未启用；携带未支持 source context 的请求拒绝，不能去掉来源后冒充直接 proposal。由原 RFC 后续阶段承接。

入口与符号已串读：project register → register_fresh_source_session_project / new_goal_storage_transport → 现有初始化 owner；goal-amendment-proposal / _amendment_configure → execute_goal_amendment → executeGoalAmendment；之后 executeCoordinationTodoClaim 与现有 replan predicate 消费，GoalAmendmentSettings 只显示当前/历史事实。新增字段中，原始承诺和预授权是必须由 owner 输入的 intent；创建 lineage 与 revision 是同一事务的 checkpoint，不能从有界展示反推；当前 replan 是已有规则的派生结果。

语义与 CI 对齐

原26项词表、legacy admission、旧 claim 在省略新绑定时的请求 hash 都保留。新 root/提案/回执属于既有 Goal owner 下的共享契约，操作词汇只由 TS dispatcher 定义；Python 不增加一套状态判定。shared_work_graph 的说明现在区分旧 Stage2 metadata 与新固定模板 owner。完整语义检查仍为26/26、独立双运行时对数43/43，没有增加预算、缩小扫描或用空 advisory 充当语义等价证明。

对主干的风险

主要风险是源实例切换后的迟到写入、恢复重复副作用，以及旧初始化路径被新 profile 误捕获。实际 delayed-RPC、旧来源/旧 basis、scope、相邻已有租约和旧 App/CLI 初始化用例覆盖了这些路径。额外原生反例确认：改写展示 Markdown 不改变权威视图；损坏 canonical 记录顺序会拒绝，恢复原契约后保持原 work digest 并可采纳同一语义基线。原顺序损坏属于无效存储，不能把它当成合法显示重排来放宽 reader。

本地 operator 路径沿用现有可信本机管理边界；空 actor 不是远程身份认证。浏览器不能提供 peer 身份，测试里的两个注册身份也不证明真实独立模型/主机协作。新模板写入不授予 execution，通用 source runtime、自动 Turn/Vision 和 Lark 仍未启用。累计提案/工作受显式上限约束，耗尽时停止新变更而不是自动扩大授权；长期共享运行仍要走其单独验收。

验证事实：产品源码 f1ef98bfcc9f2c3eb05747feb7a0d7c64aef1479 与当前 head 的产品文件逐字一致，后续仅截图、文档和捕获等待。355个隔离 PostgreSQL/authority 测试零跳过；原生 source/creation/amendment40项通过；存储/HTTP集合67项通过，搬迁后12个错误注入仍指旧模块的用例在对准真实新 owner 后全部通过，原拒绝/无任务断言未删。安装 wheel 的真实界面完成原操作恢复、实际 CLI 提交/租约/采纳及状态回读。原生 base/head 完整 JSON 对照保留旧列表和拒绝语义，只单独验证已披露的创建回执新增原始承诺。

19项 premerge 没有阻塞失败，有一项维护性 advisory：未修改的 goal_frontier/__init__.py 在干净 baseline 与当前均为2007行、上限2000；新增依赖/复杂度问题已修正，没有改上限。宽泛依赖遍历的 mypy 曾报告仓库范围错误，未宣称全树类型检查通过；本次三个新传输模块的 focused mypy、Ruff、TS 与构建通过。远程 CI 的待运行/旧事件取消与分支保护单列，不据此宣称 ready to merge。

我的整体评价

APPROVE，适用于这个显式本地固定模板切片。 它已交付可操作、可恢复、可回读的结果，且保留原 work、lease、receipt 和规则 owner；不是只有新 schema 或测试初始化。前向重构已落实在 Python 来源适配归属和重复 CLI 操作判定的收敛。新增模块、UI 和验收规模与这个完整事务边界相符；更广泛自动协作继续由既有 RFC 承接，不能用这批测试替代真实模型验收。维护者仍须独立处理 CI/分支保护和合并授权。

English verdict: APPROVE — 8c7cdc8. The bounded local fixed-template amendment composes existing authority, receipt, claim and replan owners, with real native/provider and installed UI recovery/adoption evidence. Generic runtime, request-derived/Lark/live-model paths remain explicitly unqualified; the baseline size advisory and merge gates are separate.

[songoow]

Additional acceptance checks found gaps at 8c7cdc8907e896899e75e68748b1806180a2ec6c, so this PR is temporarily back in draft while the correction is completed:

• A real successful no_change claim result is reported as CLI exit 1 / ok: false.
• With the writer fence retained but the isolated File authority document unavailable, inspect is reported as exit 0 / ok: true. missing is a valid historical receipt observation, not successful current authority inspection or mutation.
• After the proposer's first claim consumes its replan obligation, the wrapper also requires that obligation to be open for later lease reacquisition on the same already-bound work. This prevents ordinary continuation after lease expiry.

The added native regressions reproduce these cases using disposable File/SQLite Goals, with a controlled clock input for expiry. The correction keeps result success with the typed Goal owner, and limits the open-replan requirement to creating a new causal binding. Existing lease/claim admission, exact scope and original-operation recovery remain enforced. The next head will receive a complete fresh review; the earlier self-review is not the final delivery conclusion.

[songoow]

Reviewer: model_agent — GPT-6 / OpenAI (self_reported).

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

未发现阻塞性问题。本次审查针对 6323@8ddedecb288788961a479a28395698d68dfea8ca 的完整变更，结论是有价值的有界增量，不代表父 RFC、上线或真实多 Agent 协作已经完成。此前8c版本的自审和补充发现均保留；本次重新审查完整 PR，并核对后续修复。

动机

维护者和已注册的本地 Agent，需要在保留最初目标的前提下，把经过预授权的改进变成可执行工作。

以前提案只能留存，无法把共享目标版本和新任务一起提交；回复丢失时，也缺少这条变更路径自己的可回读结果。现在固定一个允许的工作模板后，可以原子创建未认领任务，并用原操作恢复结果。

已验证原目标不被缩小、既有任务和租约不变、同一操作不会重复创建任务；界面能看到当前版本、实际采纳和仍待处理的 replan。 本次补充验收还确认：无变更成功和存储缺失由 TS owner 统一给出结果，已绑定任务在 replan 结算后仍可正常取得下一代租约。

本批次仅交付显式本地 profile 的固定模板变更；不授予执行权限，不做 provider 迁移、部署或整 Goal 完成判定。

自动 Turn/Vision 接续、Lark、request-derived 事务和真实模型协作仍未完成，继续由既有 RFC 的后续阶段承担。

依据是 docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md，固定接受版本 c504ffdb4e788e495e7b9010f2b7cc9c055b591b，以及 #3836 的原始目标与讨论。本次没有用新增文档反向替代原验收条件。

改动思路

把不可推导的原始承诺和预授权放进既有 canonical Goal head，复用 Todo planner、CAS、回执和 claim/replan owner；Python 只保留来源与锁的传输适配，避免第二套决策规则。

当前 PR 的可交付边界是原生创建、固定 root、提交新工作、认领和回读的完整本地流程；它没有把后续自动协作阶段包装成已经完成。

仅保留提案无法补上原子提交；单独调用 Todo create 再改 Goal 会留下中间状态。采用固定模板而非任意自然语言变更，减少了首批 policy/verifier 的判定面。实际新 Goal 初始化原先只在 fixture 中准备；现在显式注册入口复用已有真实初始化事务，CLI 和安装包界面均走通。相关 Python 适配迁回 coordination，目标选择、空来源、fence 和恢复决策仍由原 TypeScript owner 执行；没有第二个存储或同步 ACK。

具体改动

原规范条目	本 head 的处理与证据
9.2(1)	创建回执保留原始声明；root/policy 不可变。删掉原始承诺等式校验的隔离 mutant 使 File/SQLite 两个真实 CLI oracle 均失败；原 head 正常拒绝缩小目标。
9.2(2)	executeGoalAmendment 复用 Todo planner，在一次 CAS 写入任务、Goal revision、事件和原回执。新任务仍未认领。
9.2(3)	原始 GoalRef、源码见证、生命周期 fence、完整工作基线和 policy 逐层验证；已有 peer 任务/租约保持不变；HTTP 拒绝外部 Origin、越工作区和 Agent 冒充字段。
9.2(4)	真实 provider 丢响应、同操作重试、竞争提交和容量拒绝验证；已提交历史不因后续状态而被重写。
9.2(5)	新版本后必须实际 adopt；claim 复用原租约 owner 并绑定精确 replan。另一身份的认领不能代原提案者结算；安装包显示 pending → 实际采纳/消费后的当前结果。
9.2(6)	原生注册、真实 SQLite/HTTP、正常 wheel 的独立安装、浏览器中英文/窄屏/刷新恢复及 peer CLI 回读；共享 claim 改动另跑隔离真实 PostgreSQL。
5.1	request-derived reservation/commit/abort 未启用；携带未支持 source context 的请求拒绝，不能去掉来源后冒充直接 proposal。由原 RFC 后续阶段承接。

入口与符号已串读：project register → register_fresh_source_session_project / new_goal_storage_transport → 现有初始化 owner；goal-amendment-proposal / _amendment_configure → execute_goal_amendment → executeGoalAmendment；之后 executeCoordinationTodoClaim 与现有 replan predicate 消费，GoalAmendmentSettings 只显示当前/历史事实。新增字段中，原始承诺和预授权是必须由 owner 输入的 intent；创建 lineage 与 revision 是同一事务的 checkpoint，不能从有界展示反推；当前 replan 是已有规则的派生结果。

补充验收确实发现并修复了旧 head 的三个问题：成功的 no_change 被 CLI 当成失败；当前 authority 缺失被当成成功读取；replan 已消费后，同一已绑定任务无法在租约过期后继续。新 head 把成功判定集中到 TS owner，CLI/HTTP 只转发，并把 open-replan 检查限定在首次建立因果绑定；再次认领和续租仍完整遵守旧 lease/version/epoch 规则。File/SQLite 的对应旧断言失败已经保留，新回归全部通过，三个 provider 的原 lease owner 也验证了下一代租约。

语义与 CI 对齐

原26项词表、legacy admission、旧 claim 在省略新绑定时的请求 hash 都保留。新 root/提案/回执属于既有 Goal owner 下的共享契约，操作词汇只由 TS dispatcher 定义；Python 不增加一套状态判定。shared_work_graph 的说明现在区分旧 Stage2 metadata 与新固定模板 owner。完整语义检查仍为26/26、独立双运行时对数43/43，没有增加预算、缩小扫描或用空 advisory 充当语义等价证明。

对主干的风险

主要风险是源实例切换后的迟到写入、恢复重复副作用，以及旧初始化路径被新 profile 误捕获。实际 delayed-RPC、旧来源/旧 basis、scope、相邻已有租约和旧 App/CLI 初始化用例覆盖了这些路径。额外原生反例确认：改写展示 Markdown 不改变权威视图；损坏 canonical 记录顺序会拒绝，恢复原契约后保持原 work digest 并可采纳同一语义基线。原顺序损坏属于无效存储，不能把它当成合法显示重排来放宽 reader。

本地 operator 路径沿用现有可信本机管理边界；空 actor 不是远程身份认证。浏览器不能提供 peer 身份，测试里的两个注册身份也不证明真实独立模型/主机协作。新模板写入不授予 execution，通用 source runtime、自动 Turn/Vision 和 Lark 仍未启用。累计提案/工作受显式上限约束，耗尽时停止新变更而不是自动扩大授权；长期共享运行仍要走其单独验收。

验证事实：最终产品源码 8ddedecb288788961a479a28395698d68dfea8ca 的相关原生/HTTP/旧 CLI 回归45项通过；隔离 PostgreSQL/authority355项通过、零跳过，包含义务关闭后的 lease epoch2 续行。新 head 的正常 wheel 独立安装后，真实界面再次完成原操作恢复、实际 CLI 提交/租约/采纳及回读。此前存储/初始化证据仅在其 owner/caller 字节未变的部分复用；完整原生 baseline/head 对照仍用于未改变的旧列表、拒绝和默认关闭语义。修改原 root 校验的隔离 mutant 两个真实 backend oracle 均失败，修复后原断言没有删除。

19项 premerge 没有阻塞失败，有一项维护性 advisory：未修改的 goal_frontier/__init__.py 在干净 baseline 与当前均为2007行、上限2000；新增依赖/复杂度问题已修正，没有改上限。宽泛依赖遍历的 mypy 曾报告仓库范围错误，未宣称全树类型检查通过；本次三个新传输模块的 focused mypy、Ruff、TS 与构建通过。远程 CI 的待运行/旧事件取消与分支保护单列，不据此宣称 ready to merge。

我的整体评价

APPROVE，适用于这个显式本地固定模板切片。 它已交付可操作、可恢复、可回读的结果，且保留原 work、lease、receipt 和规则 owner；不是只有新 schema 或测试初始化。前向重构已落实在 Python 来源适配归属、TS 统一结果判定，以及首次因果绑定与后续租约续行的边界。新增模块、UI 和验收规模与这个完整事务边界相符；更广泛自动协作继续由既有 RFC 承接，不能用这批测试替代真实模型验收。维护者仍须独立处理 CI/分支保护和合并授权。

English verdict: APPROVE — 8ddedec. The bounded local fixed-template amendment composes existing authority, receipt, claim and replan owners, with fresh native/provider and installed UI evidence, including no-op/unavailable outcomes and lease continuation after replan settlement. Generic runtime, request-derived/Lark/live-model paths remain explicitly unqualified; the baseline size advisory and merge gates are separate.

[loopx-agent]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; xhigh.

APPROVE — exact head 8ddedecb288788961a479a28395698d68dfea8ca，没有当前阻断项；认可有界本地增量。

动机

需要让多名 Agent 在同一目标下补充工作、同时保留原始要求的维护者 此前提案只被记录，不能提交新工作；现在先固定原始要求和允许的模板，再由 Agent 提案、提交一项未认领任务，并重新确认当前版本。 源码和独立 wheel 的界面都完成了丢回复后的刷新、同一操作重试与回执读取；两名 Agent 的确认及原提案者的 claim 已经由原生 owner 回读。 提交任务和记录版本确认不等于执行任务或整个 Goal 完成；不改变原始目标、验收、权限和停止条件。

这是显式本地 source-session profile 的固定模板增量；通用 Turn/Vision 自动采纳、Lark、验收或权限变更、request-derived reservation/abort 和真实模型协作仍未交付。

改动思路

原始目标、非目标、验收和停止条件从创建时的拥有者声明取得，连同一次预授权 policy 固定在现有 canonical head；没有从可变 Markdown 重建原要求。CLI/HTTP 只转交观察和请求，TS owner 决定准入、当前基线、固定模板和操作结果。成功 commit 用现有 Todo planner 在一次 CAS 中新增一项未认领工作并推进版本，原 Todo/lease 保留。之后 peer 自己 adopt 当前基线，原提案者实际 claim 才由已有 replan 规则消费，保存或提交都不能冒充工作完成。

具体改动

完整 42 文件、+2367/-93，包括不可变 root/固定模板 transaction、源码生命周期与新 Goal 存储接续、共享 claim 因果字段、CLI/HTTP、设置页 schema/交互、中英 RFC/路线与合成图片、provider 和界面验证、IO manifest。接受框架是变更前 c504ffdb4e788e495e7b9010f2b7cc9c055b591b 的 docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md，以及 #3836 关于预授权内普通演进不再逐次询问人的要求：§9.2 首个固定模板、单次 CAS、无关 lease、不确定回复恢复和独立消费逐项满足；整个 Stages4–5 保持开放。

• goal_amendment_authority.ts:216 executeGoalAmendment 从原来 proposal-only 走到实际新增工作；精确源实例、原始 root、完整 work digest、当前 peer adoption 都是 precondition，非受支持 context 直接拒绝。
• goal_amendment_runtime.py:52 execute_goal_amendment 复用 index→source→canonical writer 锁顺序，持有完整字节 witness；超时后旧 RPC 仍受 canonical retirement fence 拒绝。
• goal_amendment_api.py:94 _amendment_configure 校验 operator 的原 preview/digest，不能冒充 peer；lost response 重试相同 operation，并区分历史 receipt 和当前 projection。
• goal-amendment-settings.tsx:7 GoalAmendmentSettings 在现有任务所有权设置中检查原声明、明确 freeze；刷新保留原请求，提供读取原回执/重试原操作和实际 peer/replan 回读。

逐项映射：§9.2(1) 原始root与policy读回；§9.2(2) 未认领工作与回执；§9.2(3) 权限/实例/基线拒绝；§9.2(4) 原操作丢回复和冲突恢复；§9.2(5) 已有peer租约下的普通claim确认、新工作采纳及原义务消费；§9.2(6) 打包设置纠错和当前结果。额外原生File/SQLite/PostgreSQL同容器反例已实际运行：已有工作不能走新建工作专用claim，新注册peer不自动入policy，原有peer用当前有效租约确认仍可继续，Todo和不可变root保持一致。这是原生事实与合成source输入的验证，不是实际模型产出。

前一轮讨论的三个真实错误已逐项独立验证：已持有合法 claim 的 no_change 是成功，缺 authority 的 inspect/HTTP 不报成功并能恢复原存储，因果绑定已消费后重新取得过期 lease 到 epoch2 不要求重开已结算 replan。另一 peer 的 claim 不能替原提案者结算。变更不改受保护要求或通用运行许可。

对主干的风险

当前 233 项 Python 通过；原生 provider/integration 实际通过359项，唯一 service 环境 skip 已用单独真实 PostgreSQL14.24 数据库补跑2项通过。File/SQLite/PostgreSQL 均验证现存 peer lease、只创建一次、丢 committed 回复、错 identity/basis 和租约续行。对污染 fixture 的负例只在一次性实例执行，未使用任何活跃 Goal。

源码打包与独立安装的正常 wheel 都走真实 HTTP/SQLite：无效输入拒绝、review后刷新、丢回复后原请求一致重试、历史 receipt、版本2、两 peer 的确认、中文/英文和390px键盘回读全部通过，无 page error/横向溢出。浏览器只对真实已提交响应做丢包故障；没有用 fixture 替换生产 API/provider。Replan 历史为合成 typed observations，不能声称真实模型团队已运行。typecheck、build/verify、19项风险检查与语义检查已运行。原 canary 仍保留 quota尺寸和 advisory module ratchet 问题：base 同一 runner 重现15657/15500及同一旧 debt，直接 base/head 均15489；没有宣称全绿或提高预算。

12 个普通 shared-off 全输出/用户文案/持久摘要与 immutable base 相同。省略 canonical-storage 仍仅生命周期注册；新 source-session 创建 receipt 新增原始 root commitments，这是明确的 provenance 增量，旧 receipt 不回填，旧 Goal 需原 owner 迁移。元数据发现和具名设置可用，并不让 generic status/turn/chat 执行自动可用。现有 Stage2 admission 仍不能提交；不新增 Python 决策 owner，local operation vocabulary 与旧 Stage2 token 明确区分。按当前策略没有查询或等待 CI。

我的整体评价

交付判断为 justified_increment：源码和独立 wheel 的界面都完成了丢回复后的刷新、同一操作重试与回执读取；两名 Agent 的确认及原提案者的 claim 已经由原生 owner 回读。 长程效果预期正向：每次补工作都保留原始边界，丢回复恢复原操作，过期 lease 能接续，降低重复工作、要求漂移和把保存当完成的风险。效率的收益有具体流程证据——一次初始化后 policy 内不用逐次找人确认，错误回复不用重新建立任务；但仍须检查/adopt/claim，未证明 token、时延或真实业务产出有净改善。

最强反面是当前只支持显式 source-session 与固定模板，权限/终止信息需要一次配置，有限容量和同步源锁有成本；这由当前 stage 的完整可回滚边界解释，不能把它包装为透明的通用团队能力。未来整理已应用：把实际复用的存储 initializer 移到 coordination transport、更新调用者，状态与成功分类仍统一在 TS。

English verdict: APPROVE - 8ddedec: the bounded local immutable-root/template commit and original-operation recovery deliver a usable operator/peer journey.233 Python,359 native checks plus2 real PostgreSQL service checks, source/independent-wheel browser and12 full shared-off comparisons passed. Original canary/baseline holds and generic/live-model adoption gaps remain explicit; this is not whole-Goal acceptance or merge authority.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @songoow.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

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 HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[huangruiteng]

Approval conclusion (maintainer review)

Reviewer: model_agent (self_reported); model=DeepSeek V4 Flash; provider=DeepSeek.

评审 #6323 feat(goals): commit governed local work with immutable intent and recovery

Review exact head: 524d63f3619fd01b2051cddb0c5a0f9c10f270bc；PR base main：4180b7165fdcad25f61582ec795c90e4b3f901b5（上一个评审 head 8ddedecb28）。

规范依据: docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md，接受修订 c504ffdb4e788e495e7b9010f2b7cc9c055b591b（PR 实现基线）。逐条核对的准则 ID：9.2.1、9.2.2、9.2.3、9.2.4、9.2.5、9.2.6（§9.2 在基线修订下已接受；本 PR 新增 §9.3 只记录有界本地实现与激活边界，不作为独立真理来源）。

动机

一个在共享 Goal 上协作的 maintainer/peer Agent 会遇到这个问题：主人先冻结 Goal 的原始承诺（objective / non-goals / acceptance / stop condition）和一份固定的工作模板，希望已注册的同伴据此提出并落地一条新工作。在此之前（Stage 2）系统只能把 amendment proposal 保留下来，无法把共享意图和一条新工作在一次 CAS 里一起提交，于是同伴被接受的工作无法成为 canonical work，只能靠手工改 Todo，既绕过 root policy 也无法在回复丢失后按原操作恢复。本 PR 之后，受信来源适配器冻结原始承诺，注册同伴 propose 后用一次 CAS 提交恰好一条未认领的 Agent Todo，并连同 Goal revision 与原始 receipt 一起落账；回复丢失时按原操作恢复，设置页可回读当前 revision、同伴 basis 与 pending/settled replan。边界：本 PR 只覆盖显式本地 source_session_v1 + File/SQLite 路径；自动 Turn/Vision 采用、Lark 交互和 request-derived 提交都不在本 PR，也不宣称。

改动思路

权威边界放在既有 canonical head 内的新 TS owner，Python 只做传输适配与入口，复用既有 CAS、claim/lease、projection、quota 与 acceptance 生命周期 owner。本 PR 只落地 §9.2 的有界本地单模板提交，不激活通用 runtime 或自动 adoption。loopx/control_plane/goals/goal_amendment_authority.ts 复用既有 AuthorityStore CAS、coordination_projection、todo_claim 的 claim/lease、quota source admission、registry authority-source check 与 acceptance_lifecycle，只新增一个 goal_work_graph_amendment_v0 提案类型和 §9.2 的单模板提交操作。新增状态都按其真实来源派生：root_intent/policy 由可信 owner 在 configure 时从 source 的 root_commitments 冻结（并校验 objective/non_goals/acceptance/stop 必须逐字保留），goal_revision 与 created_todo_ids 由 proposer lineage 反推（readIntent 断言 goal_revision == created_todo_ids.length + 1 且每条 created work 都有有序 proposal 来源），intent_digest/work_digest/template_digest/proposal.digest 都是 canonical SHA-256，adoptions 只记录同伴复述的 basis。Python 侧是适配而非决策：initialize_goal_storage_target 从 capability 模块搬进 control_plane/coordination/new_goal_storage_transport.py（旧 internal 入口删除、调用点更新），goal_amendment_runtime.py 经 effect runtime 调到 TS owner，presentation/goal_amendment_api.py 只暴露 operator 的 inspect/configure/readback，前端在既有 Goal settings 里复用同一 owner。

具体改动

42 文件 +2367/−93，按表面分组：TS 权威 goal_amendment_authority.ts（+398，inspect/configure/propose/commit/adopt/claim/receipt 七操作，fail-closed 校验）+ 其单测 tests/control_plane_ts/goal_amendment_authority.test.ts（+247）；coord/transport new_goal_storage_transport.py、new_goal_initialization.ts、todo_claim.ts、source_session_lifetime.ts；Python 桥与入口 goal_amendment_runtime.py、goal_amendment_proposal.py(CLI)、presentation/goal_amendment_api.py(operator HTTP)、registry.py/registry_codec.py、bootstrap.py/chat_actions.py/chat_server.py/chat_status_api.py；前端 goal-amendment-settings.tsx(+170)/goal-amendment.ts(+48)/workspace-settings-page.tsx 与浏览器 smoke goal-amendment-browser-smoke.mjs(+207)；docs 两个 RFC 语言镜像 + roadmap + 三张合成截图；语义账 project_registry_io_manifest_v1.json/vocabulary_v0.json。

三处 follow-up 修复在代码里可见并被测试锁定：executeGoalAmendment 的成功判定按操作分派（no_change 是成功 no-op，missing 不能使 inspect/变更成功，后者返回 goal_amendment_source_unavailable 并提示先恢复原存储）；claim 只在 materialize 因果绑定时要求 replan obligation 仍 open（binding !== null && existingBinding !== binding），已绑定工作在原 lease 过期后可正常续租而不重开已 settled replan。

本 head 是 maintainer 为消除与 main 的冲突所做的 sync merge：唯一冲突是生成文件 loopx/semantics/project_registry_io_manifest_v1.json（两侧行号/取值不同），我用其生成器 scripts/generate_project_registry_io_manifest.py 在以并集为 previous 的合并树上重新生成（302 sites，0 unclassified），未手工改行号；python scripts/generate_project_registry_io_manifest.py --check 与 tests/architecture/test_project_registry_io_census.py 均通过。其余 41 个文件为 git 自动合并。

对主干的风险

最危险的反例有三类。第一类是「无限造工作 / 重放」：proposal 用 canonical proposal.digest、proposal_id 唯一、created work 有严格 lineage 与 max_created_todos/LIMITS.proposals/字节上限约束，重复 proposal_id 被拒（提示 replay 原操作），同一 operation 的 command receipt 先读回再执行；commit 走 prepareCoordinationProjectionCommit 一次 CAS。第二类是跨实例/退役竞态：sourceGoalMutationReadiness、readGoalAcceptanceLifecycle 与 registryAuthoritySourceCheck 在每次变更前后各校验一次，lifecycle.state !== "active" 或 goal_ref 变化即 stale_goal_instance，超时调用方释放 source lock 后旧实例请求也无法穿过 canonical retirement fence。第三类是默认路径泄漏：不带 --canonical-storage 时保持 lifecycle-only 创建，通用 status/turn 路径仍返回既有 profile refusal，只有 views == ["workspace-directory"] 的目录发现和 amendment operator 路由读新 codec；execution_authority_granted 在 inspect/claim/receipt/commit 全部为 false。文档契约同步：RFC §9.2/§9.3 英文与中文镜像、roadmap 与 PR 正文同时更新，未出现「已接受 RFC 与实际默认不一致」的旧问题。

已知局限与我的处置：本机只跑到 PostgreSQL 16.15（PR 作者报的是 14.20），349 条 authority-store 用例 0 skip 全绿；真实模型协作、打包 App 安装态替换、Lark 投递、request-derived reservation/abort 仍未验证，属 PR 已声明的边界。前端 npx tsc --noEmit 的 JSX 报错在未合并的 main 上同样复现（环境/版本问题），非本 PR 引入。PR 正文「Revision」字段仍写旧 head 8ddedecb28，属非阻断的文件陈旧，见下方 P3。

我的整体评价

这是一个值得合并的大切片：它在既有 canonical head 内落地了 RFC §9.2 的有界本地提交事务，把「保留提案」推进到「不可变意图 + 单模板一次 CAS 提交 + 同伴 adoption + 原始操作恢复 + replan 消费」，且没有新增能力、配置开关或第二决策源，失败关闭条件（basis/stale/authority/capacity/lease）全部保留。交付边界如实申报：只证明显式本地 File/SQLite source-session 路径与合成 fixture，不宣称自动 adoption、Lark 或生产上游。冲突解决只触及生成账本并已用生成器与 census 测试复核。无阻断项。

English verdict: APPROVE - head 524d63f: the bounded local governed-amendment owner commits one policy-bound unclaimed Todo with the frozen root intent in a single canonical CAS, keeps peer adoption, replan consumption and lost-reply recovery, and never grants execution authority; my merge resolution only regenerated the tracked project-registry I/O census (302 sites, 0 unclassified, census test green), and the merged tree passes 176 amendment/source-session Python tests, 349 isolated real-PostgreSQL authority-store tests (0 skipped), the new TypeScript authority test, control-plane typecheck, changed-file Ruff, mypy and the 19-check premerge gate.

[huangruiteng]

Approval conclusion (maintainer review)

Reviewer: model_agent (self_reported); model=DeepSeek V4 Flash; provider=DeepSeek.

评审 #6323 feat(goals): commit governed local work with immutable intent and recovery

Review exact head: 8c69149837fcf602aa4ca930a7a6dbbe3d781fd7；PR base main：4e994b11f83103b99342a3b0e589a93d6b526f5d（此前评审 head 524d63f361，PR 原始 head 8ddedecb28）。

规范依据: docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md，接受修订 c504ffdb4e788e495e7b9010f2b7cc9c055b591b（PR 实现基线）。逐条核对的准则 ID：9.2.1、9.2.2、9.2.3、9.2.4、9.2.5、9.2.6（§9.2 在基线修订下已接受；本 PR 新增 §9.3 只记录有界本地实现与激活边界，不作为独立真理来源）。

动机

一个在共享 Goal 上协作的 maintainer/peer Agent 会遇到这个问题：主人先冻结 Goal 的原始承诺（objective / non-goals / acceptance / stop condition）和一份固定的工作模板，希望已注册的同伴据此提出并落地一条新工作。在此之前（Stage 2）系统只能把 amendment proposal 保留下来，无法把共享意图和一条新工作在一次 CAS 里一起提交，于是同伴被接受的工作无法成为 canonical work，只能靠手工改 Todo，既绕过 root policy 也无法在回复丢失后按原操作恢复。本 PR 之后，受信来源适配器冻结原始承诺，注册同伴 propose 后用一次 CAS 提交恰好一条未认领的 Agent Todo，并连同 Goal revision 与原始 receipt 一起落账；回复丢失时按原操作恢复，设置页可回读当前 revision、同伴 basis 与 pending/settled replan。边界：本 PR 只覆盖显式本地 source_session_v1 + File/SQLite 路径；自动 Turn/Vision 采用、Lark 交互和 request-derived 提交都不在本 PR，也不宣称。

改动思路

权威边界放在既有 canonical head 内的新 TS owner，Python 只做传输适配与入口，复用既有 CAS、claim/lease、projection、quota 与 acceptance 生命周期 owner。本 PR 只落地 §9.2 的有界本地单模板提交，不激活通用 runtime 或自动 adoption。loopx/control_plane/goals/goal_amendment_authority.ts 复用既有 AuthorityStore CAS、coordination_projection、todo_claim 的 claim/lease、quota source admission、registry authority-source check 与 acceptance_lifecycle，只新增一个 goal_work_graph_amendment_v0 提案类型和 §9.2 的单模板提交操作。新增状态都按其真实来源派生：root_intent/policy 由可信 owner 在 configure 时从 source 的 root_commitments 冻结（并校验 objective/non_goals/acceptance/stop 必须逐字保留），goal_revision 与 created_todo_ids 由 proposer lineage 反推（readIntent 断言 goal_revision == created_todo_ids.length + 1 且每条 created work 都有有序 proposal 来源），intent_digest/work_digest/template_digest/proposal.digest 都是 canonical SHA-256，adoptions 只记录同伴复述的 basis。Python 侧是适配而非决策：initialize_goal_storage_target 从 capability 模块搬进 control_plane/coordination/new_goal_storage_transport.py（旧 internal 入口删除、调用点更新），goal_amendment_runtime.py 经 effect runtime 调到 TS owner，presentation/goal_amendment_api.py 只暴露 operator 的 inspect/configure/readback，前端在既有 Goal settings 里复用同一 owner。

具体改动

42 文件 +2367/−93，按表面分组：TS 权威 goal_amendment_authority.ts（+398，inspect/configure/propose/commit/adopt/claim/receipt 七操作，fail-closed 校验）+ 其单测 tests/control_plane_ts/goal_amendment_authority.test.ts（+247）；coord/transport new_goal_storage_transport.py、new_goal_initialization.ts、todo_claim.ts、source_session_lifetime.ts；Python 桥与入口 goal_amendment_runtime.py、goal_amendment_proposal.py(CLI)、presentation/goal_amendment_api.py(operator HTTP)、registry.py/registry_codec.py、bootstrap.py/chat_actions.py/chat_server.py/chat_status_api.py；前端 goal-amendment-settings.tsx(+170)/goal-amendment.ts(+48)/workspace-settings-page.tsx 与浏览器 smoke goal-amendment-browser-smoke.mjs(+207)；docs 两个 RFC 语言镜像 + roadmap + 三张合成截图；语义账 project_registry_io_manifest_v1.json/vocabulary_v0.json。

三处 follow-up 修复在代码里可见并被测试锁定：executeGoalAmendment 的成功判定按操作分派（no_change 是成功 no-op，missing 不能使 inspect/变更成功，后者返回 goal_amendment_source_unavailable 并提示先恢复原存储）；claim 只在 materialize 因果绑定时要求 replan obligation 仍 open（binding !== null && existingBinding !== binding），已绑定工作在原 lease 过期后可正常续租而不重开已 settled replan。

本 head 含两次 maintainer 为对齐 main 所做的 sync merge。第一次（524d63f361）的唯一冲突是生成文件 loopx/semantics/project_registry_io_manifest_v1.json（两侧行号/取值不同），我用其生成器 scripts/generate_project_registry_io_manifest.py 在以并集为 previous 的合并树上重新生成（302 sites，0 unclassified），未手工改行号；第二次（8c69149837）把最新 main 合入，无冲突，生成器 --check 仍为 302 sites / 0 unclassified，tests/architecture/test_project_registry_io_census.py 通过。其余文件为 git 自动合并，合并树在 185 条 Python 用例、TS 用例、typecheck 与 19 项 premerge 上全绿。

对主干的风险

最危险的反例有三类。第一类是「无限造工作 / 重放」：proposal 用 canonical proposal.digest、proposal_id 唯一、created work 有严格 lineage 与 max_created_todos/LIMITS.proposals/字节上限约束，重复 proposal_id 被拒（提示 replay 原操作），同一 operation 的 command receipt 先读回再执行；commit 走 prepareCoordinationProjectionCommit 一次 CAS。第二类是跨实例/退役竞态：sourceGoalMutationReadiness、readGoalAcceptanceLifecycle 与 registryAuthoritySourceCheck 在每次变更前后各校验一次，lifecycle.state !== "active" 或 goal_ref 变化即 stale_goal_instance，超时调用方释放 source lock 后旧实例请求也无法穿过 canonical retirement fence。第三类是默认路径泄漏：不带 --canonical-storage 时保持 lifecycle-only 创建，通用 status/turn 路径仍返回既有 profile refusal，只有 views == ["workspace-directory"] 的目录发现和 amendment operator 路由读新 codec；execution_authority_granted 在 inspect/claim/receipt/commit 全部为 false。文档契约同步：RFC §9.2/§9.3 英文与中文镜像、roadmap 与 PR 正文同时更新，未出现「已接受 RFC 与实际默认不一致」的旧问题。

已知局限与我的处置：本机只跑到 PostgreSQL 16.15（PR 作者报的是 14.20），349 条 authority-store 用例 0 skip 全绿；真实模型协作、打包 App 安装态替换、Lark 投递、request-derived reservation/abort 仍未验证，属 PR 已声明的边界。前端 npx tsc --noEmit 的 JSX 报错在未合并的 main 上同样复现（环境/版本问题），非本 PR 引入。PR 正文「Revision」字段仍写旧 head 8ddedecb28，属非阻断的文件陈旧，见下方 P3。

我的整体评价

这是一个值得合并的大切片：它在既有 canonical head 内落地了 RFC §9.2 的有界本地提交事务，把「保留提案」推进到「不可变意图 + 单模板一次 CAS 提交 + 同伴 adoption + 原始操作恢复 + replan 消费」，且没有新增能力、配置开关或第二决策源，失败关闭条件（basis/stale/authority/capacity/lease）全部保留。交付边界如实申报：只证明显式本地 File/SQLite source-session 路径与合成 fixture，不宣称自动 adoption、Lark 或生产上游。冲突解决只触及生成账本并已用生成器与 census 测试复核。无阻断项。

English verdict: APPROVE - head 8c69149: the bounded local governed-amendment owner commits one policy-bound unclaimed Todo with the frozen root intent in a single canonical CAS, keeps peer adoption, replan consumption and lost-reply recovery, and never grants execution authority; my two sync merges only regenerated the tracked project-registry I/O census (302 sites, 0 unclassified, census test green), and the merged tree passes 185 amendment/source-session/census Python tests, 349 isolated real-PostgreSQL authority-store tests (0 skipped), the new TypeScript authority test, control-plane typecheck, changed-file Ruff, mypy and the 19-check premerge gate.

[huangruiteng]

Maintainer merge record

Merged at exact head 8c69149837fcf602aa4ca930a7a6dbbe3d781fd7 (merge commit
91b675dfca178db68d3527140272ffb263a3b319) via admin bypass, with owner
authorization in the current session.

Why bypass was needed. The ruleset on main requires a code-owner approval
that is not from the most recent pusher (require_last_push_approval). The
conflict-resolution sync merges were pushed by the reviewing maintainer account,
so its own APPROVED review satisfies code-owner review but not the
last-push rule; the requested code-owner reviewer did not respond. GitHub's
reviewDecision therefore stayed REVIEW_REQUIRED even though the exact-head
review is valid. pr-review --check-merge-readiness reports exactly that one
remaining reason. Everything else was verified locally before the merge.

Changed surfaces

• loopx/control_plane/goals/goal_amendment_authority.ts (new, +398) — typed
  governed-amendment owner: immutable root intent, fixed-template one-CAS commit
  of a single unclaimed Todo, peer adoption, claim/replan consumption and receipt
  recovery. Control-plane authority behavior.
• loopx/control_plane/coordination/* + new_goal_storage_transport.py — the
  new-Goal storage initializer moved out of the machine_configuration capability
  (old definition deleted, callers updated); claim/lease unchanged for others.
• loopx/presentation/goal_amendment_api.py, loopx/cli_commands/*,
  loopx/control_plane/projects/*, loopx/{bootstrap,chat_actions,chat_server,chat_status_api}.py
  — transports and host entrypoints over the same typed owner.
• apps/presentation/dashboard/.../goal-amendment-settings.tsx + data module +
  browser smoke — operator configuration/readback inside existing Goal settings.
• RFC shared-goal-alignment-and-governed-amendment-v0 §9.2/§9.3 (EN+ZH),
  roadmap S3 row, three synthetic screenshots.
• loopx/semantics/project_registry_io_manifest_v1.json — regenerated (not
  hand-edited) at the merge resolution; vocabulary_v0.json note updated.

Checks run at this head

• tests/control_plane/test_goal_amendment_authority.py,
  tests/control_plane/test_chat_goal_amendment.py,
  tests/cli_commands/test_source_session_lifetime.py,
  tests/control_plane/test_new_goal_storage_defaults.py,
  tests/test_chat_server_cors.py,
  tests/architecture/test_project_registry_io_census.py,
  tests/architecture/test_source_session_registry_denial.py — 185 passed.
• LOOPX_TEST_POSTGRES_URL=<disposable local> npm run test:postgresql-authority-store
  — 349 passed, 0 failed, 0 skipped against real PostgreSQL 16.15.
• node --experimental-strip-types --test tests/control_plane_ts/goal_amendment_authority.test.ts
  — 5 pass, 1 optional skip.
• npm run typecheck:control-plane, changed-file Ruff, python -m mypy
  (19 sources), scripts/generate_semantic_inventory.py --changed-from origin/main
  and scripts/generate_project_registry_io_manifest.py --check (302 sites,
  0 unclassified) — all clean.
• loopx canary premerge --from-git-diff --goal-id loopx-meta — 19/19 passed,
  0 failures.
• loopx change-quality record — receipt cqr_8ef7e3331c9887b68367, valid for
  this exact scope (42 files).
• loopx pr-review --check-result — APPROVE consistent; review published at the
  exact head (review id 5500943433).

Failures / skips / holds

• A raw npx tsc --noEmit in the dashboard reports JSX.IntrinsicElements errors
  in frontstage-developer-page.tsx; the identical errors reproduce on the
  unmodified main checkout, so they are a pre-existing environment/version
  issue, not caused by this PR (recorded as a non-required skipped case).
• No unresolved review threads. The only hold was the review-decision gate above.

Coverage sufficiency. The change stays inside the existing canonical
authority owner, reuses the established CAS, claim/lease, projection and quota
contracts, adds no capability/config switch or second decision source, and every
new state field is derived from an authoritative source or an explicit owner
declaration. Real File/SQLite and real PostgreSQL backends were exercised; the
installed desktop App, live-model collaboration and Lark delivery remain
unqualified and are declared out of scope by the PR.