Skip to content

feat(runtime): establish the managed mutation acceptance kernel - #4265

Draft
zhiiw wants to merge 6 commits into
apache:mainfrom
zhiiw:codex/managed-write-edit-stack-v1
Draft

feat(runtime): establish the managed mutation acceptance kernel#4265
zhiiw wants to merge 6 commits into
apache:mainfrom
zhiiw:codex/managed-write-edit-stack-v1

Conversation

@zhiiw

@zhiiw zhiiw commented Aug 30, 2026

Copy link
Copy Markdown
Contributor

Summary

Establish the managed mutation kernel that owns the durable boundary from T1 reservation through terminal settlement and atomic SQLite successor acceptance.

This PR intentionally stops before Gitoxide candidate reopening and accepted-ref repair. Those recovery and projection responsibilities now live in a second stacked delivery so this PR has one primary invariant:

Once a managed Write/Edit T1 is durable, only the owner-scoped managed settlement path may commit its terminal outcome; provider outcome, accepted successor, canonical workspace head, and reservation release are either committed together or not committed at all.

Ownership

  • Runtime owns the original Write/Edit arguments, the bounded pure transform, the immutable provider-result snapshot, and the exact durable response envelope.
  • Execution Stores / SQLite owns the cross-process reservation, terminal transaction, accepted workspace history, and disposable projections.
  • The managed mutation authority owns candidate/no-effect verification through issuer-scoped capabilities; generic RuntimeEvent/T2 writers cannot settle a managed operation.

Atomic boundary

For a successful mutation, SQLite commits the tool outcome, workspace successor fact, canonical head CAS, and reservation release in one transaction. For no-change or a proven no-effect business failure, SQLite commits the terminal outcome and reservation release without advancing the head.

Failure and retry states

  • Pre-T1 admission failure: no reservation and no tool execution.
  • Managed no-change/no-effect: one durable terminal, no head movement.
  • Valid successor: one atomic accepted successor.
  • Missing or conflicting proof: unsettled/fail closed; no generic fallback.
  • Exact historical retry: returns the immutable accepted result even after a later legal head advance.

The no-effect bearer is now bound to its issuing owner, concrete execution store, and durable storage-root identity. Runtime also constructs the terminal outcome once and uses that same immutable event for live publication and durable settlement.

Follow-up boundary

The stacked Gitoxide recovery PR owns durable candidate receipt reopening, accepted-ref projection, active-reservation recovery state, and production-shaped helper crash evidence. It does not widen this PR's SQLite or Runtime authority.

Verification

  • Rebuilt from current upstream/main.
  • git range-diff preserved all six extracted commits exactly.
  • Core, Storage, Runtime, and Runtime Host builds pass in the full stack.
  • Focused mutation/settlement/persistence tests pass.
  • Cross-store no-effect capability forgery is rejected.
  • git diff --check passes.
中文说明

摘要

本 PR 只建立 managed mutation kernel,负责从 T1 reservation 到 terminal settlement 与 SQLite 原子 successor acceptance 的 durable 边界。

Gitoxide candidate 重开与 accepted-ref 修复已经移到第二个 stacked PR。本 PR 只证明一个主要不变量:

managed Write/Edit 的 T1 一旦持久化,只有 owner-scoped managed settlement 才能提交终态;provider outcome、accepted successor、canonical workspace head 与 reservation release 必须同时提交或全部不提交。

Owner

  • Runtime:拥有原始 Write/Edit 参数、有界纯 transform、不可变 provider result snapshot 与精确 durable response envelope。
  • Execution Stores / SQLite:拥有跨进程 reservation、terminal transaction、accepted workspace history 与可重建 projection。
  • Managed mutation authority:通过 issuer-scoped capability 验证 candidate/no-effect;generic RuntimeEvent/T2 writer 无权结算 managed operation。

原子性与失败状态

成功 mutation 在一个 SQLite transaction 中提交 tool outcome、workspace successor fact、canonical head CAS 与 reservation release。no-change 或已证明无副作用的业务失败只提交 terminal outcome 并释放 reservation,不推进 head。

缺少证明或证明冲突时 fail closed,禁止 generic fallback。no-effect capability 已绑定签发 owner、具体 execution store 与 durable storage-root identity;Runtime 只构造一次 terminal outcome,live publication 与 durable settlement 使用同一 immutable event。

后续边界

第二个 stacked Gitoxide recovery PR 负责 durable candidate receipt 重开、accepted-ref projection、active reservation recovery state 与真实 helper crash evidence,不会扩大本 PR 的 SQLite/Runtime 权限。

验证

本分支已从最新 upstream/main 重建;六个 extraction commits 经 range-diff 全部精确保留;Core、Storage、Runtime、Runtime Host 构建通过;mutation/settlement/persistence 定向测试通过;跨 store 伪造 no-effect capability 会被拒绝;git diff --check 通过。

@github-actions github-actions Bot added the effort/XL Over 1000 readable lines label Aug 30, 2026
@zhiiw
zhiiw force-pushed the codex/managed-write-edit-stack-v1 branch from cc194db to a6bf8f3 Compare August 30, 2026 14:06
@zhiiw zhiiw changed the title feat(runtime): establish durable Gitoxide Write/Edit acceptance feat(runtime): establish the managed mutation acceptance kernel Aug 30, 2026
@zhiiw

zhiiw commented Aug 30, 2026

Copy link
Copy Markdown
Contributor Author

Thanks — I agree with the ownership diagnosis, but I have kept the delivery at two PRs rather than splitting it into four smaller protocol fragments.

The stack is now organized as follows:

  1. This PR: managed mutation acceptance kernel

    • Runtime owns one bounded immutable result and one terminal response event.
    • The no-effect bearer is scoped to its issuer, concrete execution store, and durable storage-root identity.
    • SQLite owns reservation arbitration and the atomic terminal/successor transaction.
    • Generic T2 remains forbidden after managed T1.
  2. Stacked recovery PR: zhiiw/maka-agent#43

    • Active T1 is reported as gitoxide_managed_mutation_replay_required; projection repair can no longer return already_current while a reservation is live.
    • Post-T2 recovery directly reopens the strict operation-bound candidate receipt. It no longer reads the parent content and calls the current transform again.
    • Only the exact accepted_ref_target_invalid observation enters parent/candidate repair. Timeout, cancellation, corruption, and unrelated helper failures propagate and fail closed.
    • SQLite exact replay reissues the process-local projection capability before the accepted-ref CAS.

I also corrected the recovery claim: a pure transform is invoked at most once per live Runtime execution, but it may be deterministically recomputed after a pre-T2 process loss. The durable guarantee is at most one accepted successor, not exactly-once invocation of a pure function. Once T2/successor is durable, recovery adopts the receipt and does not recompute the transform.

Both branches were rebuilt together from current upstream/main; the 14 extracted commits match one-for-one under git range-diff. This PR is now the five-commit kernel only, while the nine-commit Gitoxide recovery layer is independently reviewable in the stacked Draft.

中文说明

感谢这轮审查。我同意 owner 边界的判断,但没有继续机械拆成四个 PR,而是收敛为两个可独立证明、同时又不会过度碎片化的交付:

  1. 当前 PR:managed mutation acceptance kernel

    • Runtime 只拥有一个有界 immutable result 和一个 terminal response event;
    • no-effect capability 绑定签发 owner、具体 execution store 与 durable storage-root identity;
    • SQLite 负责 reservation 仲裁与原子 terminal/successor transaction;
    • managed T1 后继续禁止 generic T2。
  2. 第二个 stacked recovery PR:zhiiw/maka-agent#43

    • active T1 明确返回 gitoxide_managed_mutation_replay_required,projection repair 不会再误报 already_current
    • post-T2 recovery 直接重开严格、operation-bound 的 candidate receipt,不再读取 parent content 并调用当前 transform;
    • 只有精确的 accepted_ref_target_invalid 才进入 parent/candidate repair;超时、取消、corruption 与其他 helper 错误原样 fail closed;
    • exact replay SQLite successor 后才重签进程内 projection capability,再执行 accepted-ref CAS。

同时修正了恢复合同:pure transform 在一次 live Runtime execution 中最多调用一次,但 pre-T2 进程退出后可以基于同一 durable operation 做确定性重算。真正的 durable 保证是“最多一个 successor 被接受”,不是“纯函数 exactly once”。T2/successor 一旦持久化,恢复只采用 receipt,不再重算 transform。

两个分支已经一起从最新 upstream/main 重建;14 个 extraction commits 在 range-diff 中逐一对应。当前 PR 只保留 5 个 kernel commits,9 个 Gitoxide recovery commits 放在第二个 stacked Draft 中独立审查。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

effort/XL Over 1000 readable lines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant