Seal managed workspace baseline admission

[zhiiw]

Summary

Seal the M0 managed-workspace baseline admission boundary by composing the merged Git artifact owner and Workspace Version Authority behind one public owner.

• Expose only ManagedWorkspaceOwner.openManagedWorkspaceBaseline(); artifact-only creation and raw receipt issuance remain package-internal.
• Verify a durable Git baseline receipt before accepting canonical workspace RuntimeEvents and SQLite projections.
• Bind runtime.sqlite to the authenticated storage root's durable rootId in schema 8; a copied database, replaced marker, hard link, symlink, or pathname replacement fails closed.
• Revalidate database pathname/identity and the Git receipt after SQLite commit before returning a usable worktree.
• Include source cleanliness, UTF-8 path identity, and case-collision policy in the literal M0 policy hash.
• Preserve exact retry/crash convergence while rejecting receipt, policy, workspace, or projection drift.

Why

The merged foundation PRs establish two independent authorities: Git owns managed artifacts, while immutable RuntimeEvents own runtime acceptance. M0 is the narrow composition gate that proves both authorities describe the same workspace boundary before any worktree becomes usable.

The previous integration branch bound the SQLite file location but not the database content's durable storage-root identity. Copying runtime.sqlite from root A to root B could therefore pass pathname and inode checks. This flat rebuild adds a singleton durable root binding and validates it in the same transaction as baseline acceptance.

Invariant and boundaries

For one authenticated storage root and workspace epoch, a caller receives a managed worktree only after:

1. the Git owner issues and re-verifies a durable baseline receipt;
2. the authority database is bound to the same durable rootId;
3. epoch-opened and baseline-accepted RuntimeEvents plus epoch/version/head projections commit atomically; and
4. post-commit database and Git identities still match.

Any mismatch fails closed. There is no attached-workspace fallback and no Desktop/CLI/runtime-host consumer in this PR.

• Composition owner: ManagedWorkspaceOwner
• Artifact authority: package-internal Git workspace service and receipt capability
• Runtime fact authority: immutable RuntimeEvents
• Atomic boundary: one SQLite transaction for root binding validation, canonical facts, and projections
• Rollback: uncommitted SQLite state disappears; durable Git receipts are reusable by exact retry

Scope limits

This PR does not expose managed worktrees to tools, modify the user's checkout, implement workspace mutation/version advancement, support ignored dependency environments, or enable automatic resume. Those remain later slices.

This is a flat rebuild from upstream/main@bb44e37e6 after #1742 and #1743 merged; it does not merge or cherry-pick the historical integration branch.

Validation

• Core and Storage builds passed.
• Biome and git diff --check passed on all changed production/test files.
• Managed baseline/owner: 20 passed, 5 Windows platform skips.
• Real Git workspace service: 27/27 passed, including create/quarantine process-crash convergence.
• Authority/storage/recovery: 82/82 passed.
• Multiprocess SQLite concurrency: 11/11 passed.
• Operational database cutover: 7/7 passed.

Linux/macOS CI remains the release proof for POSIX SIGKILL, symlink, inode-replacement, whole-root import/adopt, and non-UTF-8 Git-path cases that are skipped or capability-limited on Windows.

中文说明

概要

本 PR 完成 managed workspace M0 的 baseline admission 组合边界：把已经合并的 Git artifact owner 与 Workspace Version Authority 收敛到唯一 public owner 后面。

• public API 只暴露 ManagedWorkspaceOwner.openManagedWorkspaceBaseline()；artifact-only 创建与 raw receipt 发行保持 package-internal。
• SQLite 接受 canonical workspace RuntimeEvents/projection 前，必须先验证 durable Git baseline receipt。
• schema 8 用 singleton runtime_storage_root_binding 将 runtime.sqlite 内容绑定到 authenticated storage root 的 durable rootId；单独复制数据库、替换 marker、hard-link、symlink 或 pathname replacement 全部 fail closed。
• SQLite commit 后再次验证数据库 pathname/物理 identity 与 Git receipt，验证完成前不返回可用 worktree。
• literal M0 policy hash 现在覆盖 source cleanliness、UTF-8 path identity 与 case-collision policy。
• exact retry 与 crash recovery 可以收敛；receipt、policy、workspace 或 projection drift 一律拒绝。

核心不变量

调用者只有在以下四项全部成立后才能得到 managed worktree：

1. Git owner 发行并重新验证 durable baseline receipt；
2. authority database 与同一个 durable rootId 绑定；
3. epoch-opened / baseline-accepted RuntimeEvents 与 epoch/version/head projections 在一个 SQLite transaction 中提交；
4. commit 后数据库与 Git identity 仍然一致。

任何不一致都 fail closed；本 PR 不提供 attached fallback，也不接入 Desktop、CLI 或 runtime-host。

范围边界

本 PR 不把 managed worktree 暴露给工具，不修改用户 checkout，不实现 workspace mutation/version advancement，不处理 ignored dependency environment，也不启用自动 resume。这些属于后续切片。

本分支从 upstream/main@bb44e37e6 平铺重建；没有 merge 或 cherry-pick 历史 integration branch。

验证

• Core / Storage build 通过。
• 变更文件通过 Biome 与 git diff --check。
• managed baseline/owner：20 passed，5 个 Windows 平台 skip。
• 真实 Git workspace service：27/27 passed，包含 create/quarantine 真实进程 crash 收敛。
• authority/storage/recovery：82/82 passed。
• SQLite 多进程并发：11/11 passed。
• operational database cutover：7/7 passed。

POSIX SIGKILL、symlink、inode replacement、whole-root import/adopt 与 non-UTF-8 Git path 的最终发布证据由 Linux/macOS CI 承担。

[zhiiw]

Addressed the remaining M0 admission blocker and the CI-only assertion failure in bdb2e538a.

• Added a final assertInteractiveRootOwner() gate after post-commit DB/root binding and Git receipt/artifact verification. A root-marker replacement can no longer publish a usable managed workspace.
• Added a production-shaped failpoint regression at after_post_commit_artifact_verification. It proves the call rejects while the already-committed canonical workspace head remains intact.
• Corrected the Linux CI test that treated a renamed SQLite main file as a self-contained authority database even though the accepted transaction may remain in its pathname-associated WAL. The test now asserts the actual safety property: no usable baseline is returned and the replacement canonical database never receives the accepted head.
• Updated the M0 contracts to state that whole-root adoption currently restores storage-root/SQLite authority only; existing linked-worktree relocation and non-empty legacy DB binding are separate, explicit maintenance protocols.
• Replaced the stale generic-checkpoint/observe-only-Git managed-mode roadmap with M0–M4 Git-native execution, mutation-version, continuation, and product workflow stages. The old route remains attached/legacy research only.

Local verification: @maka/core and @maka/storage builds pass; the focused real-Git M0 baseline suite passes (16 passed, 5 Windows capability skips); Biome and git diff --check pass. The new GitHub Actions run is in progress.

中文说明

已在 bdb2e538a 处理剩余的 M0 admission blocker 与 CI 专属断言问题。

• 在 post-commit DB/root binding 和 Git receipt/artifact 复验之后，增加最终 assertInteractiveRootOwner() 闸门。root marker 被并发替换时，不再可能返回可用 managed workspace。
• 增加 after_post_commit_artifact_verification failpoint 的 production-shaped 回归测试：调用必须拒绝，但已提交的 canonical workspace head 保持不变。
• 修正 Linux CI 测试对 SQLite WAL 的错误假设。被 rename 的 main DB 文件并不是可独立读取的 authority；测试现在验证真正安全不变量：不返回 usable baseline，且 replacement canonical DB 不会得到错误 head。
• 文档明确：whole-root adoption 当前只恢复 storage-root/SQLite authority；既有 linked worktree relocation 与非空 legacy DB binding 都必须是独立、显式的维护协议。
• managed 模式路线已正式换成 Git-native M0–M4；旧 generic checkpoint / observe-only Git 路线只保留为 attached/legacy research。

本地验证：core/storage build 通过；real-Git M0 suite 16 通过、5 个 Windows 能力限制跳过；Biome 与 git diff --check 通过。新的 GitHub Actions 正在运行。

[zhiiw]

Follow-up from the new Linux CI run (7fd8cac3c): the final root check initially used a fresh active-lease assertion. That correctly caught marker replacement, but it also rejected an operation that had already been admitted while owner.close() was waiting for it to drain.

The final fence now uses a root-identity guard captured from the authenticated lease during owner construction. This preserves both invariants:

1. closing immediately rejects new admission but lets already-admitted work drain; and
2. the final return gate still revalidates the physical root and durable marker identity before publishing the workspace.

The existing owner-drain regression and the new post-commit marker-replacement regression both pass locally. A new CI run has started.

中文说明

新的 Linux CI 暴露了一个生命周期细节：最初的最终检查重新要求 active lease，虽然能抓住 marker 替换，却会误杀 owner.close() 正在等待 drain 的已 admission 操作。

现在改为在 owner 构造时，从已认证 lease 捕获 root identity guard，并在最终返回前调用。这样同时保持两条不变量：

1. closing 立即拒绝新 admission，但已 admission 的工作可以正常 drain；
2. 返回 workspace 前仍会重新验证物理 root 与 durable marker identity。

现有 owner drain 测试与新增 post-commit marker replacement 测试均已在本地通过；新的 CI run 已启动。

[zhiiw]

CI is now fully green on head 7fd8cac3c: changes, typecheck, test, e2e, and storybook all pass. The Linux owner-drain regression and the final root-identity admission fence are both covered by the successful test job.

中文说明

当前 head 7fd8cac3c 的 CI 已全部通过：changes、typecheck、test、e2e、storybook 全绿。Linux 下的 owner drain 回归与最终 root identity admission 闸门都已由成功的 test job 覆盖。

[likun666661]

有一个当前会阻止合并的 SQLite migration 冲突需要处理：

PR head 7fd8cac3c 把 runtime_storage_root_binding 放在 schema migration 8：
https://github.com/maka-agent/maka-agent/blob/7fd8cac3c20d45a198b22b2df7cbaa8014c1b166/packages/storage/src/sqlite-runtime-schema.ts#L244-L255

但最新 main@1caea265（#1994）已经把 migration 8 用于 headless_task_run_events：
https://github.com/maka-agent/maka-agent/blob/1caea265cb4b93382b1c7640c4044c73022ea12c/packages/storage/src/sqlite-runtime-schema.ts#L240-L251

因此这里不能只做普通的 conflict resolution，否则可能出现 user_version = 8、但两个表只存在一个的数据库状态。建议：

1. rebase 到最新 main，并保留 main 的 migration 8；
2. 将 runtime_storage_root_binding 顺延为 migration 9，同时把 SQLITE_RUNTIME_SCHEMA_VERSION 更新为 9；
3. 增加 current-main v8 → v9 的升级回归测试，并同步 legacy schema rewind fixtures；
4. 重新跑 schema、managed baseline、crash/recovery 和 SQLite multiprocess concurrency suites。

我本地用 git merge-tree origin/main HEAD 复核，目前除 schema 文件外，index.ts 以及 3 个 recovery/runtime test 文件也存在 content conflict。当前 head 的 CI 虽然是 green，但覆盖的是旧 base，rebase 后需要重新验证。

[zhiiw]

Resolved the schema-number collision and rebased the PR onto current main@1ec3107f4.

• kept main's headless_task_run_events as runtime migration 8
• moved runtime_storage_root_binding to migration 9 and set the runtime schema version to 9
• added a populated v8 → v9 regression that preserves a real headless task event and verifies the new binding table
• updated schema 4/6 rewind fixtures and the locked-version migration mock for migrations 8 and 9
• resolved the public-surface conflict without re-exporting the package-internal Git artifact service or the deleted legacy project-session migration
• updated the architecture/extraction docs to record the schema 8/9 ownership

Verification:

• storage build/typecheck passed
• v8 → v9 RED reproduced as 8 !== 9, then passed after the migration fix
• schema + runtime store + multiprocess concurrency: 48/48 passed after the final rebase
• managed baseline/owner, recovery persistence, workspace authority, and crash/recovery focused suites passed locally; platform-gated Windows crash/symlink cases remained skipped as designed

中文说明

已解决 migration 编号冲突，并把 PR 变基到当前 main@1ec3107f4。

• 保留 main 的 migration 8：headless_task_run_events
• 将 runtime_storage_root_binding 顺延到 migration 9，并把 runtime schema version 更新为 9
• 新增 populated v8 → v9 回归：保留真实 headless task event，同时验证 binding 表被创建
• 同步 schema 4/6 rewind fixtures，以及锁内重读版本的 migration mock
• 解决 public API 冲突：不重新导出 package-internal Git artifact service，也不带回已被 main 删除的 project-session migration
• 同步架构与 extraction ledger 中 schema 8/9 的职责说明

最终变基后，schema、runtime store 与多进程并发测试 48/48 通过；managed baseline/owner、recovery persistence、workspace authority 与 crash/recovery 定向套件也已通过。本机 Windows 按设计跳过需要 POSIX crash/symlink 能力的用例。

[zhiiw]

Rebased once more onto current main@df6cc8c35 after the storage CI failure.

The six failing storage cases were not new failures in the managed-workspace change: they were migration-fixture and backup-error expectations already corrected on main by #2016. Replaying this PR onto current main brings those fixes in without duplicating them here.

Post-rebase verification:

• @maka/core and @maka/storage build successfully
• the previously failing intent-claim, supervisor-wake, session migration, and operational backup cases now pass
• runtime schema/store and SQLite multiprocess concurrency suites pass, including the populated v8 → v9 migration
• the only local focused-test failure is an existing Windows run of a POSIX sandbox-path fixture; it is unrelated to this diff and runs under the expected platform semantics in Linux CI
• git diff --check passes

中文说明

在 storage CI 失败后，已再次变基到当前 main@df6cc8c35。

六个失败并不是 managed workspace 改动引入的新回归，而是 main 后续 #2016 已修复的 migration fixture 与 backup error 断言问题。此次通过变基直接继承 main 的修复，没有在本 PR 中复制补丁。

变基后：core/storage build 通过；此前失败的 intent claim、supervisor wake、session migration、operational backup 用例已通过；runtime schema/store 与 SQLite 多进程并发用例通过，其中包含 populated v8 → v9 升级测试。唯一的本地失败是 Windows 执行 POSIX sandbox path fixture 的既有平台差异，与本 PR diff 无关；git diff --check 通过。

[zhiiw]

Resolved the latest main conflict and rebased #1872 onto main@7dcffb6c9.

The only content conflict was the SQLite multiprocess child fixture. The resolution preserves both sides of the contract:

• main's operational_open_only path, shared operational database lease, and close lifecycle
• Seal managed workspace baseline admission #1872's root-binding step and concurrent workspace-baseline commit modes

Verification after the rebase:

• @maka/core and @maka/storage build successfully
• runtime schema + runtime store: 37/37 passed
• SQLite multiprocess concurrency: 12/12 passed, including both concurrent fresh operational WAL initialization and concurrent baseline admission
• git diff --check passes
• the real-Git managed owner suite did not complete within 90 seconds on this Windows host and emitted no failure; Linux CI is running the authoritative platform-shaped check

中文说明

已解决最新 main 冲突，并将 #1872 变基到 main@7dcffb6c9。

唯一的内容冲突位于 SQLite 多进程 child fixture。解决时同时保留了两侧契约：

• main 的 operational_open_only、统一 operational database lease 与关闭生命周期；
• Seal managed workspace baseline admission #1872 的 root binding，以及 workspace baseline 并发提交模式。

变基后 core/storage build 通过；runtime schema + runtime store 37/37 通过；SQLite 多进程并发 12/12 通过，同时覆盖 fresh operational WAL 并发初始化和 baseline admission 并发；git diff --check 通过。真实 Git managed owner 套件在本机 Windows 90 秒内未结束且没有失败输出，最终以正在运行的 Linux CI 平台测试为准。