loopx-agent · Oct 13, 2026 · Oct 13, 2026 · Oct 13, 2026 · Oct 13, 2026 · Oct 13, 2026
@@ -720,6 +720,9 @@ jobs:
           - {suite: installed, shard: 0}
     steps:
       - uses: actions/checkout@v7
+        with:
+          # Cross-version recovery generates originals with a pinned public 1.x source.
+          fetch-depth: 0
       - uses: actions/download-artifact@v7
         with:
           name: chat-bundle-${{ github.sha }}

@@ -150,7 +150,7 @@ const capabilityCopy: Record<WorkspaceLocale, Record<string, LocalizedCopy>> = {
 const fieldCopy: Record<WorkspaceLocale, FieldCopy> = {
   en: {
     new_goal_provider: { label: "New Goal storage provider", description: "File or SQLite; frozen at creation, independently of execution policy." },
-    canonical_creation: { label: "Create canonical authority", description: "Future Goals only. Disabled retains the post-promotion target; failures require the original creation retry." },
+    canonical_creation: { label: "Create canonical authority", description: "Required for new Goals in 2.0. An older disabled setting remains visible until you enable it; existing Goals require import." },
     new_goal_handoff_mode: { label: "New Goal execution policy", description: "soft_claim or hard_lease, used with canonical creation. Agents inherit the Goal policy; tool authority is unchanged." },
     runtime_profile: { label: "Runtime profile", description: "Restricted keeps scoped LoopX reads only. Trusted owner enables normal host tools while protected operations retain separate checks." },
     selection_policy: { label: "Selection policy", description: "Preferred allows an explicit user choice; pinned rejects another executor; flexible permits fallback only inside the eligible pool." },
@@ -185,7 +185,7 @@ const fieldCopy: Record<WorkspaceLocale, FieldCopy> = {
   },
   "zh-CN": {
     new_goal_provider: { label: "新 Goal 的存储 provider", description: "选择 File 或 SQLite；创建时固定，与执行策略分别选择。" },
-    canonical_creation: { label: "建立 canonical 权威存储", description: "仅影响此后新建的 Goal。关闭时仅固定晋升后的目标；失败须重试原创建操作。" },
+    canonical_creation: { label: "建立 canonical 权威存储", description: "2.0 新建 Goal 必须启用。旧的关闭设置会保留显示，需自行启用；已有 Goal 需导入。" },
     new_goal_handoff_mode: { label: "新 Goal 的执行策略", description: "canonical 创建使用 soft_claim 或 hard_lease。Agent 继承 Goal 策略；不授予工具权限。" },
     runtime_profile: { label: "运行模式", description: "restricted 仅使用受限 LoopX 读取；trusted_owner 开放常规宿主工具，但受保护操作仍单独校验。" },
     selection_policy: { label: "选择策略", description: "preferred 允许用户显式改选；pinned 拒绝其他执行器；flexible 只在已授权资源池内回退。" },

@@ -382,8 +382,8 @@ export function MachineConfigurationSettings({ section, onChanged }: { section:
             <section className="personal-capability-behavior-note">
               <ShieldCheck aria-hidden size={18} />
               <div><strong>{locale === "zh-CN" ? "仅影响此后创建的 Goal" : "Future Goals only"}</strong><p>{locale === "zh-CN"
-                ? "启用 canonical 创建后，新 Goal 直接建立权威存储，并采用所选执行策略；失败时须重试原创建操作。关闭时仅固定晋升后的目标存储。已有 Goal 的升级仍需备份、停止写入和结算租约；这里不授予工具权限。"
-                : "With canonical creation enabled, new Goals establish authority with the selected execution policy; retry the original operation after failure. Disabled only freezes the post-promotion target. Existing Goals still require backup, stopped writers and settled leases for upgrade; this setting grants no tool permissions."}</p></div>
+                ? "2.0 新建 Goal 必须启用 canonical 创建，并采用所选执行策略。旧的关闭设置不会自动改变；启用后再重试创建。已有 Goal 需备份、停止写入并导入；这里不迁移已有数据，也不授予工具权限。"
+                : "2.0 requires canonical creation with the selected execution policy. An older disabled setting is not changed automatically; enable it before retrying creation. Back up, stop writers and import existing Goals separately. This setting neither migrates existing data nor grants tool permissions."}</p></div>
             </section>
           ) : null}
 

@@ -102,7 +102,68 @@ unpromoted callers remain in ordinary mutation, bootstrap/creation opt-out,
 team-plan, Monitor, ownership/source lease and active capture/binding. Reuse
 their typed admission/transaction owners; treat retained source capture,
 historical receipts and permanent document IO as recovery obligations.
-The existing delivery Todos should carry these concrete exits:
+The 2.0 alpha implementation now removes the normal Todo/Monitor source writers,
+unused line-update helpers and four Todo capture producers, sharing typed refusal across cold-source
+entrypoints while keeping original lease release, team-plan receipts and outbox
+drain. This candidate changes v0/disabled creation admission and fresh legacy
+ownership grants intentionally; it does not change the compatible 1.x line.
+The normal-wheel import/consumer matrix, packaged Settings enable/refusal/readback,
+real PostgreSQL conformance and risk canary have focused passing evidence. The
+native source-lease regression matrix now restores independently frozen 1.x
+artifacts instead of recreating retired writers. It covers interrupted fence
+recovery, lock-token renewal, stale generation rejection and later-write
+protection; acquired intent alone cannot mint a new legacy execution grant.
+Retained Monitor and outbox recovery tests now generate originals with a pinned
+public 1.x Git source and execute inspection, drain and receipt settlement with
+the current receiver. A source intent stopped before its business commit is
+retained for import/reconciliation; it cannot authorize a new 2.0 source write.
+Current consumer fixtures use canonical authority, while registered-peer legacy
+assignment and original result shapes are checked only as historical receipts.
+Bounded qualification, lease-fence caller parity and management interleavings
+now also consume pinned historical originals. Current explicit drain owns the
+rollback/rebootstrap and corrupt-history races; it cannot count as another
+primary mutation or report delivery into a superseded generation. Current
+pre-import lease acquisition remains refused, and post-import canonical lease
+CAS, transfer, release and caller envelopes keep their original assertions.
+Observable CLI consumers now exercise both real File and SQLite authority across
+absent, disabled and enabled historical capture settings. Dry-run and rejection
+checks include the canonical head and journal; accepted no-op mode intents retain
+a receipt, while their exact retry leaves that journal unchanged. Bootstrap
+replacement and terminal writes on an unmigrated source refuse before mutation;
+current release still settles a genuine pre-upgrade lease.
+The shared-authority recovery ladder now identifies its immutable 1.x producer
+revision separately from the current receiver. Current drain survives process
+death at commit, cursor and cleanup boundaries on those original entries; source
+replacement, rollback, archive/audit and bounded history checks retain their
+assertions. Original handoff/acquire races retain recoverable receipts, while
+current File/SQLite races independently prove quiescence and policy admission
+against one canonical head. Legacy-source overrides refuse before writing.
+These are executable recovery and current-consumer checks, not sustained
+operation or substitutes for the independent installed/natural-trial gates.
+The callerless Python lifecycle authorization chain and its facade exports are
+retired. Canonical File/SQLite entrypoints qualify claim eligibility, immutable
+rejection, actor/delegation and lease fences; configuration-time grant validation
+and registry fact transport retain their active callers. New delegated terminal
+receipts retain the accepted authority reason; original receipt recovery preserves
+historical results and rejects a changed reason under the same operation identity.
+This closes that private decision chain, not the remaining monitor/handoff caller
+families, installed import journey or sustained SQLite qualification.
+The remaining actor-module Monitor, binding and terminal consumers now use real
+File/SQLite authority. Imported completions without a typed continuation expose
+an integration gap: the completion reducer permits explicit repair, but the
+outer terminal no-op path discarded that commit. The terminal transaction now
+honors that existing repair decision and retains its original operation receipt;
+shared provider tests cover rejection, preview, replay and subsequent closeout.
+Canonical completion releases its lease atomically, so response-loss recovery
+replaces the obsolete separate-release failure seam. A completed ordinary Todo
+cannot be reopened through metadata update, and fresh unmigrated claims refuse
+without changing the source. These are explicit 2.0 boundaries, not parity with
+the retired Markdown writer's split claim/lease and reopen behavior. Historical
+receipt recovery, broader CI and installed/natural-trial acceptance stay separate.
+The backend configuration catalog now describes the same 2.0 creation boundary.
+Exact-head review, core-developer trial and release authorization remain open. Retained outbox recovery and source
+lease release are concrete remaining callers, not grounds for keeping normal
+Todo producers. The existing delivery Todos should carry these concrete exits:
 
 - Qualify the installed import/backup/recovery journey for the declared source
   matrix; importer implementation is already present and is not a missing-code

@@ -217,11 +217,11 @@ if (rejection === "claim_owner_mismatch") {
 }
 ```
 
-这是同一 `authority` 决策中的片段，不是新的调用接口。未晋升源适配器
-`mutation_authority.py::authorize_todo_lifecycle_mutation` 仍在 owner mismatch 后
-读取并规范化 registry grant，再通过 `authority_core.decide` 调用同一 TS owner；
-canonical 事务也复用该 owner。Python facts、grant 校验和 receipt 投影保留，
-不再经由无人调用的单项 grant 查询。
+这是同一 `authority` 决策中的片段，不是新的调用接口。canonical 事务复用
+该 TS owner；`mutation_authority.py::todo_lifecycle_facts` 只传递 registry facts，
+grant 的按需校验和执行授权由事务统一决定。配置入口仍用
+`normalize_todo_lifecycle_authority` 校验输入。旧 Python 生命周期授权分支及其
+无人调用的 facade 导出已删除；未晋升源须先导入 canonical 才能执行普通写入。
 
 这份 grant 有四个边界：