loopx-project · huangruiteng · Sep 13, 2026 · Sep 13, 2026 · Sep 13, 2026 · Sep 13, 2026
@@ -87,12 +87,13 @@ changes.
 - [Shared Goal Alignment and Governed Amendment Protocol v0](shared-goal-alignment-and-governed-amendment-v0.md)
   ([中文版](shared-goal-alignment-and-governed-amendment-v0.zh-CN.md))
   - **RFC status:** Draft, under maintainer review.
-  - **Delivery on `main`:** Proposal only.
-  - **Current boundary:** Existing peer lanes, unclaimed work, claims/leases,
-    Agent-scoped Goal Vision/Replan, and provider-neutral authority are inputs.
-    A read-only shared-alignment projection, automated amendment policy,
-    verifier boundary, and canonical Goal-amendment transaction have not
-    shipped.
+  - **Delivery on `main`:** Stage 1/2 read-only alignment and proposal-admission
+    foundations implemented; the RFC remains a draft.
+  - **Current boundary:** Current Todo/lease source-basis projection and retained
+    amendment admission have no canonical effect. Full Goal-intent versioning,
+    governed commit policy/verifier, lease-impact handling and Stage 3+
+    qualification remain unshipped. Manager handoff consumes these boundaries;
+    it does not provide another amendment writer.
 - [Goal Direction Baseline v0](goal-direction-baseline-v0.md)
   ([中文版](goal-direction-baseline-v0.zh-CN.md))
   - **RFC status:** Draft, under maintainer review.
@@ -148,6 +149,26 @@ changes.
 
 ## Runtime, Capability, And Collaboration Integration
 
+- [Capable Agent Manager and Semantic Work Handoff v0](capable-manager-semantic-handoff-v0.md)
+  ([中文版](capable-manager-semantic-handoff-v0.zh-CN.md))
+  - **RFC status:** Draft, under maintainer review.
+  - **Delivery on `main`:** Proposal; existing manager/inbox foundations are reused.
+  - **Current boundary:** Proposes ordinary host-tool autonomy, persistent scoped
+    conversations, long-horizon semantic continuation and automatic result delivery.
+    Includes an official Grok Bot study distinguishing availability from goal
+    continuation; M0–M4 and A1–A16 define delivery and acceptance, with explicit
+    alignment, shared-authority and TS migration dependencies.
+    Runtime-profile promotion and generic handoff migration have not shipped.
+
+- [Explicit Todo Continuation — Stage A](cross-session-memory-substrate-v0.md)
+  ([中文版](cross-session-memory-substrate-v0.zh-CN.md))
+  - **Delivery on `main`:** #4094 shipped the explicit local CLI and rich/legacy
+    continuation note with revision-guarded ownership adoption.
+  - **Current boundary:** Registered agents, same host/Goal, lease-free promoted
+    local authority. No generic memory store, automatic host launch, cross-host
+    artifacts or automatic result return. Manager/handoff §5.13 integrates this
+    adapter into M2/M3; the shipped CLI contract remains until replacement qualifies.
+
 - [Single-Owner Local Daemon v0](single-owner-local-daemon-v0.md)
   - **RFC status:** Draft.
   - **Delivery on `main`:** Proposal only; existing Desktop ownership repair is shipped.

@@ -1,5 +1,13 @@
 # Explicit Todo continuation: Stage A
 
+## Delivery status and integration direction (2026-09-13)
+
+Stage A shipped in [#4094](https://github.com/huangruiteng/loopx/pull/4094), merge `2ebd921ee989f7c696a7214ba1176d3bd5de6fb3`. The historical filename does not imply that a generic memory substrate shipped. The [capable manager and semantic handoff RFC](capable-manager-semantic-handoff-v0.md#513-integrate-shipped-explicit-continuation-4094) includes this implementation in its M2/M3 refactor scope. That successor remains proposed; this document remains the shipped CLI compatibility and authority reference until its replacement qualifies.
+
+Reuse rich/legacy context and the existing note validator/claim transfer boundary. Receiver acceptance of a suggestion is distinct from `handoff adopt` ownership mutation. Stage A's note is replaceable current Todo state, not a private immutable history. The successor maps authorized context to a recoverable brief, references current work, and supplies general assessment/result/automatic-return relations without adding a memory ledger or copying claim authority. CLI `prepare/inspect/adopt` remains usable during migration; frontend/Lark and automatic host continuation must be qualified separately. Same-host, registered-agent, lease-free restrictions continue to apply to this adapter, not every general request. See successor §5.13 for mappings, migration conditions and retained negative cases.
+
+Language mirror: [中文版](cross-session-memory-substrate-v0.zh-CN.md).
+
 Status: a bounded local CLI workflow. The former general memory-substrate
 proposal is replaced by a cross-agent continuation workflow over the
 canonical Todo authority. It does not freeze a public memory schema.

@@ -1,5 +1,13 @@
 # 显式 Todo 接续：阶段 A
 
+## 交付状态与整合方向（2026-09-13）
+
+Stage A 已在 [#4094](https://github.com/huangruiteng/loopx/pull/4094) 以 `2ebd921ee989f7c696a7214ba1176d3bd5de6fb3` 合并。历史文件名不表示通用 memory substrate 已交付。[强能力管家与语义交接 RFC](capable-manager-semantic-handoff-v0.zh-CN.md#513-整合已交付的显式接续4094) 将本实现纳入 M2/M3 重构范围。后继方案仍是提案；替代路径验收前，本文继续作为已交付 CLI 兼容性及权威边界参考。
+
+复用 rich/legacy context、既有 note validator 与 claim transfer 边界。接收方接受建议不同于 `handoff adopt` 修改所有权。Stage A note 是可覆盖的当前 Todo 状态，不是私有不可变历史。后继方案将有权限的上下文映射为可恢复 brief，引用当前工作，补齐通用 assessment/result/自动回传关系，不新增 memory ledger 或复制 claim authority。迁移期间 CLI `prepare/inspect/adopt` 保持可用；前端/飞书及自动宿主续接单独验收。同机、注册 Agent、无 lease 限制继续适用于此 adapter，不约束所有通用请求。映射、迁移条件和保留负例见后继 §5.13。
+
+语言镜像：[English](cross-session-memory-substrate-v0.md)。
+
 本阶段替代原通用 memory substrate 方案，基于 canonical Todo authority
 交付跨注册 agent 的接续工作流。不冻结通用 memory v0。
 

@@ -3,7 +3,7 @@
 - Status: Draft; under maintainer review
 - Tracking issue: [#3836](https://github.com/huangruiteng/loopx/issues/3836)
 - Date: 2026-09-02
-- Last updated: 2026-09-09
+- Last updated: 2026-09-13
 - Scope: peer Agents collaborating around one shared Goal while preserving
   canonical intent, per-Agent execution frontiers, claim/lease ownership, and
   auditable replan/amendment decisions
@@ -88,6 +88,25 @@ bounded evidence       bounded evidence
        every frontier rebases or gates
 ```
 
+### 1.1 Verified delivery and manager integration checkpoint (2026-09-13)
+
+At `7eb4b7bb1661bd5eff63a8725a33169792d5964b`, the Stage 1 alignment reader
+and Stage 2 proposal admission/retention exist, including #3874 and the
+canonical Todo/lease source convergence in #4143. Their owners are
+`goals/shared_goal_alignment.{py,ts}` and `goal_amendment_proposal.{py,ts}`
+under `loopx/control_plane`. The latter explicitly returns
+`canonical_effect: none`; it has no approved status or commit path.
+These are implemented foundations, not full canonical intent versioning or
+Stage 3–5 acceptance. The RFC remains Draft.
+
+The [manager/handoff RFC](capable-manager-semantic-handoff-v0.md) should reuse
+the alignment reader for work-basis context; amendment admission applies only
+after classification when the request satisfies that admission contract. Its request, brief or
+delivery revision is not a Goal-intent revision. A manager's higher tool
+freedom does not confer shared-amendment authority, and handoff receipt does
+not acknowledge a new Goal on behalf of every peer. Section 9.1 and that RFC's
+M2/A16 define integration; they do not introduce a second amendment policy.
+
 ## 2. Problem and current boundary
 
 LoopX already coordinates execution usefully:
@@ -422,6 +441,37 @@ provider-neutral aggregate requires a separate reviewed transaction boundary.
 `Next Action` remains compatibility prose and a read projection. It is never a
 claim, lease, Goal amendment, replan settlement, or authority decision.
 
+### 9.1 Semantic handoff and execution-route integration
+
+Use the existing alignment projection to supply a receiver's actual work
+basis. In-intent lane replanning stays in the receiver's Vision/Replan path;
+shared changes use this RFC's classification and admission. Stage 2 may
+retain a request-derived proposal, with source/context references and an
+explicit unresolved obligation, but cannot report that the shared Goal changed.
+Missing full intent authority is not repaired by synthesizing a revision from
+the Todo provider head or the event sequence.
+
+The next amendment implementation remains **one bounded Stage 3 work-graph
+commit class**, not broad acceptance/permission rewriting. It must first
+establish the actual canonical intent/policy basis and reviewed transaction
+mapping, then prove exact-basis admission, lease impact, CAS receipt recovery
+and peer frontier rebase. Reuse the [shared authority](shared-goal-authority-state-provider-v0.md)
+storage guarantees and [TS transaction migration](typescript-control-plane-migration-v0.md)
+owner; neither currently grants amendment semantics just by being available.
+
+Manager M1 and ordinary M2 handoff can ship before that commit class. Until
+then, expose proposal/admission and the unavailable-commit boundary while
+unrelated work continues. After qualification, the manager invokes the future
+Stage 3 `GoalAmendmentAuthority` commit owner under its existing policy; no permanent manager-superuser role, mandatory peer
+vote or repeated owner confirmation is added. The manager's result links the
+committed amendment receipt and peer/in-flight disposition. Cross-Goal handoff
+does not merge distinct Goals' intents or authorize either Goal's amendment.
+
+The manager RFC's A16 reuses the existing alignment/amendment fixtures for
+lane/proposal/stale-basis negatives and later qualifies the supported commit
+path. This RFC retains Stage 3–5 implementation and promotion ownership;
+manager readiness cannot silently mark those stages done.
+
 ## 10. Staged delivery
 
 1. **Stage 0 — characterization and RFC.** Record own-lane, unclaimed,

@@ -3,7 +3,7 @@
 - 状态：草案；维护者评审中
 - 跟踪 Issue：[#3836](https://github.com/huangruiteng/loopx/issues/3836)
 - 日期：2026-09-02
-- 最后更新：2026-09-09
+- 最后更新：2026-09-13
 - 范围：多个对等 Agent 围绕同一个共享 Goal 协作，同时保留 canonical
   intent、每个 Agent 的执行 frontier、claim/lease 所有权，以及可审计的
   replan/amendment 决策
@@ -79,6 +79,23 @@ bounded evidence       bounded evidence
           每个 frontier rebase 或被 gate
 ```
 
+### 1.1 已核验交付与管家衔接检查点（2026-09-13）
+
+在 `7eb4b7bb1661bd5eff63a8725a33169792d5964b`，Stage 1 alignment reader
+与 Stage 2 proposal admission/retention 已存在，包括 #3874 和 #4143 的
+canonical Todo/lease 来源收敛。owner 是 `loopx/control_plane` 下的
+`goals/shared_goal_alignment.{py,ts}` 与 `goal_amendment_proposal.{py,ts}`。
+后者明确返回 `canonical_effect: none`，没有 approved 状态或 commit 路径。
+这些是已实现基础，不代表完整 canonical intent 版本化或 Stage 3–5 验收；RFC
+仍是 Draft。
+
+[管家/handoff RFC](capable-manager-semantic-handoff-v0.zh-CN.md) 在接收方评估时
+复用 alignment reader 获取工作基线；仅在分类后且请求符合准入契约时调用 amendment
+admission。它的请求、brief、投递版本不是 Goal-intent revision。
+管家更高的工具自由度不赋予共享 amendment authority；handoff 回执也不代所有
+peer 确认新 Goal。第 9.1 节及该 RFC 的 M2/A16 定义衔接，不新增第二 amendment
+policy。
+
 ## 2. 问题与当前边界
 
 LoopX 已经能较好地协调执行：
@@ -383,6 +400,30 @@ projection 与 proposal contract 交付；把 commit 映射进 provider-neutral
 `Next Action` 继续是 compatibility prose 与 read projection。它永远不是 claim、
 lease、Goal amendment、replan settlement 或 authority decision。
 
+### 9.1 语义交接与执行路线衔接
+
+用既有 alignment 投影给接收方提供真实工作基线。意图内的路线重规划仍走接收方
+Vision/Replan；共享改变走本文分类与准入。Stage 2 可以保留来自请求的 proposal、
+来源/context 引用与明确未结义务，但不能报告共享 Goal 已改变。缺完整 intent
+authority，不能靠从 Todo provider head 或事件序号合成 revision 来补。
+
+下一步 amendment 实现仍是**一个有界 Stage 3 work-graph commit class**，
+不是广泛改验收/权限。先建立真实 canonical intent/policy 基线和经审阅事务映射，
+再证明精确基线准入、lease 影响、CAS 回执恢复、peer frontier rebase。复用
+[shared authority](shared-goal-authority-state-provider-v0.zh-CN.md) 的存储保证与
+[TS 事务迁移](typescript-control-plane-migration-v0.zh-CN.md) owner；两者存在不等于
+已经提供 amendment 语义。
+
+管家 M1 和普通 M2 handoff 可以先于此 commit class 交付。此前明确呈现
+proposal/admission 与提交不可用边界，无关工作继续。验收后，管家按已有 policy
+调用未来 Stage 3 `GoalAmendmentAuthority` commit owner，不添加永久管家超级用户、强制 peer 投票或重复主人确认。管家结果
+关联已提交 amendment 回执与 peer/在途处置。跨 Goal handoff 不合并不同 Goal
+意图，也不授权修改任一 Goal。
+
+管家 RFC 的 A16 复用既有 alignment/amendment fixture 验路线/提案/过期基线负例，
+随后验证已支持 commit 路径。本文保留 Stage 3–5 的实现与晋级责任；管家就绪不能
+悄悄把这些阶段标为完成。
+
 ## 10. 分阶段交付
 
 1. **Stage 0 — characterization 与 RFC。** 记录 own-lane、unclaimed、

@@ -3,7 +3,7 @@
 - Status: Draft, under maintainer review
 - Initially proposed by: NoKV Lab
 - Widened by: LoopX maintainers
-- Date: 2026-08-05; revised 2026-09-12
+- Date: 2026-08-05; revised 2026-09-13
 - Scope: one provider-neutral LoopX authority contract with built-in file,
   optional NoKV, and optional PostgreSQL provider profiles, complementing
   [`host-integration-surface-v0`](../../reference/protocols/host-integration-surface-v0.md)
@@ -43,6 +43,21 @@ explicit shared-authority promotion, only sections covered by the typed
 contract become deterministic compatibility projections; free-form human
 narrative remains outside the coordination head.
 
+### Manager integration checkpoint (2026-09-13)
+
+Source audit at `7eb4b7bb1661bd5eff63a8725a33169792d5964b` confirms the
+`AuthorityStore` seam and the transaction/presentation/journal consolidations
+in #4280, #4283 and #4287. This updates the integration baseline, not the
+qualification evidence or historical provider baselines above. Candidate
+SQLite/PostgreSQL paths, provider-specific holds and the D1–D3 plan remain;
+neither a default source switch nor a shared service is declared shipped.
+
+The [capable manager and semantic handoff RFC](capable-manager-semantic-handoff-v0.md)
+consumes this authority. Its M1 host-tool work and M2 request-ledger refactor
+can proceed without provider promotion. Section 1.4 defines their boundary;
+the [TS execution cards](typescript-control-plane-migration-v0.md#execution-cards-after-the-current-stack)
+still own business-rule consolidation and legacy-caller deletion.
+
 ## Document map and maintenance contract
 
 This RFC separates durable decisions from delivery evidence:
@@ -302,6 +317,41 @@ policy. Stage 5 creates a decision point, not an automatic license transition.
 No source path becomes AGPL-3.0 merely because it implements a shared-authority
 contract or passes a remote-provider canary.
 
+### 1.4 Manager requests and semantic handoff integration
+
+The [manager/handoff RFC](capable-manager-semantic-handoff-v0.md) owns the
+user-facing exchange and general request/assessment/result relations. This
+RFC owns the reviewed coordination state and its commit proof. A semantic
+brief, conversation, delivery attempt or scheduler cursor does not enter the
+v0 coordination head. Relevant evidence is published by its artifact owner
+and referenced at an exact revision and disclosure scope. Sharing a physical
+provider does not merge these logical state families or their access/retention
+contracts.
+
+Each Goal retains one selected authority source. When adoption changes
+Todo/lease/Vision state, handoff invokes that existing owner and links its real
+receipt; consultation or assessment without a work effect does not. A separate request commit
+cannot make that work mutation atomic across stores: persist intent, recover
+the original work receipt, then reconcile the pending relation. Cross-Goal
+requests likewise preserve per-Goal bases and outcomes; they do not require
+a distributed commit or invent one Goal-wide provider revision for both.
+Transport acknowledgement never substitutes for a current claim or fence.
+
+Manager reads and receiver writes must preserve canonical empty/failure
+semantics after promotion, without old-Markdown or lease-file fallback.
+Permanent Markdown presentation remains. The handoff RFC's A15 fixture checks
+these integration boundaries against legacy and explicitly configured canonical
+sources; it does not repeat or replace this RFC's backend conformance, retention,
+recovery, soak or cutover qualification.
+
+The [shared Goal alignment/amendment RFC](shared-goal-alignment-and-governed-amendment-v0.md)
+owns intent-change legality and its future governed commit. Its current
+proposal admission creates no canonical amendment. Neither the manager nor
+the provider becomes that authority. M1–M3 manager work may run in parallel
+with T1–T3/D1/D2; changing storage/profile/source or retiring a whole legacy
+Goal writer still requires the applicable D3/T4 boundary. A new handoff is
+not a provider promotion request.
+
 ## 2. What We Will Do, and What We Will Not
 
 **What this version will do**
@@ -1165,8 +1215,10 @@ is gated by evidence below, not by calendar dates or this PR's merge status.
 | New-Goal default decision (F) | Maintainers accept the qualified profile and canary results, operational diagnostics, backup/restore procedure, release instructions and default-disable path. Ship the default change in a separate disclosed release change. | Apply only to newly created eligible local Goals. Existing explicit file selections remain pinned. Unsupported runtimes/filesystems require an explicit supported choice; no silent backend switch on open failure. |
 | Existing-Goal migration and file retirement | Migrate opt-in cohorts using the reviewed fenced workflow; reconcile receipts, history, projections and rollback after each cohort. Inventory the last file-primary callers and compatibility windows before removing any path. | Each Goal needs explicit migration authority. Retire file as the ordinary primary only after that evidence; retain reference/import/export support until its own callers and retention duties end. |
 
-**Current evidence position.** #4121 is the first milestone, pending maintainer
-acceptance; it is not completion of lane L. Its head pointer is bounded and
+**Current evidence position (rechecked 2026-09-13).** #4121 merged as
+`bde1632bb6f29aeb9a8b4ac23ead3e98ba2f2f55`, delivering the first candidate
+milestone. It remains subject to profile qualification and promotion; it is
+not completion of lane L. Its head pointer is bounded and
 operation/cursor lookups are indexed, but it retains full historical projections
 and counts a covering index for continuity. That count grows with history;
 current/accessed-row digests are checked, not every historical payload per read.