[ice-black-tea]

Current delivery · 2026-11-15

The write-transaction assessment is complete for the fixed workload. Its goal was to determine whether further safe consolidation is justified, not to require a lower count. A current-master integration recheck confirms 46 commits, 38 with writes, with complete attribution and unchanged model/tool/history and replay assertions. The transaction-boundary document now explains why none of the measured adjacent write boundaries can be transparently merged under the existing contracts. This is not a universal lower bound; no production change was made in the final evidence commit. The broader R3 workload/physical-I/O and designated R8 database-server and application acceptance remain separate, not marked passed.

Head 788a5b64 is Ready; natural CI is pending at publication. Earlier Draft statements and measurements below are historical.

Objective

Reduce repeated short transactions belonging to the same business operation, from the merged 776caf18 baseline. Judge candidates from first principles: who needs each durable fact and when, atomicity, external effects/recovery, read/write relocation and lock cost. A lower count alone is not success. This PR also carries explicit confirmed Task-failure acceptance (R8); existing preload receipt capabilities (R4) are reused rather than reimplemented.

Current slice: confirmed terminal read reuse; write target remains open

• Adds async-owner transaction attribution to the existing fixed two-turn offline probe. It records SQL verbs/tables, bound byte counts and outcomes without parameter values.
• Reproduces 8 model requests, 6 tool effects and 16 history messages with Trace off: 46 total commits / 38 write commits, SELECT 31 / INSERT 129 / UPDATE 44. All 46 transactions now have owner labels. The eight read-only transactions are distinct from the 38 write boundaries.
• Documents exact baseline, per-boundary SQL attribution and correctness obligations in linktools-ai/docs/measurements/transaction-boundaries.md.
• Implements one narrow production change: an initial wait() can reuse the same retained, fully confirmed local terminal-publication helper already used after polling. No new cache or owner. In the held-publication inline-result fixture, one successful late wait changes 3 SELECT / 2 read-only commits → 0 / 0; no receipt remains 3 / 2.
• Current authorization, worker drain/failure, consumer/hold lifetime, absent-receipt source reads and external body readers remain in place. Intentionally, an already-confirmed retained inline result no longer fails merely because its redundant source-result query is unavailable; without that receipt the source failure still propagates.
• No production write transaction has been removed. The original fixed workload remains 46 total / 38 write commits. This read slice does not resolve the write-transaction objective, so the PR remains Draft.
• Explicit none tool-policy diagnostic: 34 total / 26 write commits. This is existing behavior with a different policy, not an optimization; the default fixed baseline remains replay_safe.

Terminal content-read slice: duplicate owner rows

• Head 80c030f1 removes a duplicate owner/additional-record role within one existing content-read query. It retains the same-store/key and physical payload-routing boundaries, fresh owner observation, content validation, hold reconciliation and CAS. No new cache, protocol or transaction.
• Matched fixed two-turn evidence: returned/decoded Execution rows 4 → 2, compact UTF-8 row JSON 13,766 → 6,883 bytes. These are logical JSON bytes, not physical disk/network I/O. SELECT 31 / INSERT 129 / UPDATE 44 and 46 total / 38 write commits remain unchanged.
• Four targeted regressions cover overlap, large rows, absent owners/negative caching, distinct partitions, later batches and the existing typed-payload fallback. The unfixed overlap cases fail; 49 focused tests passed, architecture/Ruff gates passed, and independent review passed. Private phase probes are not part of this code change.
• This is a small returned-row/decode reduction, not completion of the write-transaction goal. Measurement and necessary boundaries.

R3 slice: exact History window metadata

• R3 commit 9bb77e84 batches the transcript head and seek hint in their existing owner transaction for nonempty, positive-offset windows. No public API, durable format, cache policy, lock or transaction-boundary change.
• An upstream synthetic 2-model-request / 12-tool-delivery fixture measures one exact History query, not the whole execution: without ordinary caching 12 → 11 SELECT, 7 → 7 read commits; with a warm ordinary cache 10 → 9 SELECT, 5 → 5 read commits. Cold-reopen queries also save one SELECT; both content modes agree.
• Authorization, head integrity, missing/malformed hint fallback, bounded object reads, pagination and same-version reopen remain covered. A stronger root/child snapshot counterfactual was removed because it added a source read on the warm-cache path.
• 155 focused tests passed, the baseline I/O-budget negative control reproduced two metadata queries, configured repository Ruff and diff checks passed, and independent static review passed. Measurement scope and reproduction.
• This is a SELECT reduction only. The 38-write objective is unchanged. Exact tool filtering can still materialize unrelated messages, and include_content=False still suppresses content after projection. Broader R3 queries, storage growth and designated application validation are not complete.
• A matched independent synthetic control at ad9d2c3153e412aa098dd76de61d877a854e14ea and 082b09527f417fcea3c7adc9f6684e768592f626 passed public start/wait, call/return identity and order, two-page exact reads, content-inclusive controls, same-version reopen, missing selectors and tenant rejection. The identical probe ran in the same Python/dependency environment: 2 cases passed on each pin. Warm exact reads confirm 12 → 11 SELECT and 7 → 7 read commits per query; transcript decoder input volume is unchanged. Cold reads also save one SELECT. This is a read-window comparison, not whole-execution, physical disk/network I/O, or write-transaction improvement.
• Further exact-read investigation is evidence only, not another production optimization. The current format has no proven complete body-free occurrence manifest: metadata-only output still requires ordered transcript identities, part kinds, Skill receipts and interrupted/replay semantics, in addition to event status/timing. An operation receipt does not prove a delivered transcript occurrence; existing Native result references still load their source message. Pending parts do not establish final part order.
• A bounded ideal-manifest counterfactual omitted source loading and its integrity checks; it is not an implementation or a net-cost result. No new locator/index, durable format, cache or transaction was added. Content-inclusive, Trace-off, pending/recovery, unknown-outcome and repeated-call-ID paths are not validated by that counterfactual. The metadata-only candidate is parked pending a coherent owner/validation contract, rather than weakening existing behavior.

R8: explicit acceptance of confirmed partial Task failure

• R8 commit 082b0952 adds TaskEffectResolution("failed", error_code=..., safe_details=...) through the existing Task/Execution owners. The explicit graph-control request must retain the admitted principal, expected fence and idempotency identity; diagnostics are bounded to 8 KiB.
• Already-performed effects remain recorded. Graph/node/execution converge to failure without publishing successful dependencies or replaying completed effects. Repeated confirmation must preserve the accepted error and diagnostics.
• Automatic reconciliation returning failed remains recovery-required; this does not turn an ordinary exception or unknown effect into confirmed failure.
• For a propagate failure with a bound, unsettled sibling, the request rejects with TASK_NOT_READY. The owner must first use the existing explicit run.cancel(...) operation and wait for drain/settlement, then retry failure acceptance. This patch does not automatically cancel siblings.
• Rebased on the R3 head: 64 focused tests passed through the repository gate; the final exact-tree run repeated 7 new cases successfully (overlapping, not 71 distinct tests). Architecture/Ruff gates and independent static review passed.
• Coverage includes local SQLite/exclusive-writer and regular SQLite routes, response loss after execution or graph publication, reopen/idempotency, principal/fence rejection, concurrent confirmation, and a second independent SQLite connection/launcher refusing acceptance before sibling drain.
• Real MySQL/PostgreSQL and the full distributed multi-worker acceptance matrix remain unverified. This slice is not a claim that all R8 deployment acceptance is complete.

R4: reuse existing structured Skill receipts

• Existing SkillReadReceipt support from #293 already exposes preload deliveries in History.read_model_interactions(...) via request["preload_skill_reads"], together with the enclosing execution/run/model-request identity.
• Successful explicit load_skill reads expose additional resource receipts through HistoryItem.skill_read. Resources not delivered, or not actually entering the request, do not receive fabricated read receipts.
• No new SDK production patch is needed for this requirement. Application wiring and acceptance of the existing public receipts remain integration work, not a new upstream implementation.

Candidate findings

• Admission/activation: early activation changes delayed-worker takeover; delaying it to the first Native request moves authority past model/context/capability preparation. No unchanged-contract consolidation is established.

• Native/Execution terminal: current Native confirmation and SnapshotSavedEvent happen before Runtime output validation/cleanup. Existing lifecycle/capability receipts do not supply a safe pending Native view or all-exit settlement protocol; simple staging is excluded.

• Final response/terminal snapshot: messages match, but step advances 3→4. A temporary counterfactual saves one descriptor INSERT per turn, no transaction; bodies already share a source. No production change proposed.

• Terminal preparation: one read-only transaction per turn depends on real history/head/replay metadata. Eliminating it requires preparation/publication restructuring across owners, not blindly moving external preparation inside a write transaction.

• Native producer CAS and tool-result/native-event publication already share their respective write transaction. There is no separate guard commit to delete in this measured path. These findings do not prove 38 is a universal minimum.

• Additional Trace-on/tool-heavy check at 530df312, using the same two-turn semantic assertions and explicit synchronous Trace: all 6 tool-result recorder calls perform one write commit each; nested fallback tool-start calls already do no SQL. Of 18 tool-start invocations, only the 6 real pre-tool starts write. All 8 model-start and 8 model-complete recorder calls also perform one write commit each. No same-action duplicate write was established, so no extra staging/batching layer is proposed. This is a separate Trace-on configuration, not a reduction of the default 38 writes.

• For representative application comparisons, keep the declared tool effect policy fixed and count effect admission/settlement separately. replay_safe is not effect-free; read-only hints alone do not justify removing durable effect boundaries.

• A separate one-Task SQLite probe at e03710cc checked the final dependency-hold release through the real service and retention owner. The action used 5 total commits / 2 write commits, 9 SELECT and 2 UPDATE. The first cleanup attempt returned false while the durable hold remained and used 2 read-only commits / 2 SELECT; the later attempt succeeded. This identifies read overhead, not a redundant write transaction. No reordering is proposed without preserving cleanup ownership and cancellation/failure settlement; the original 38-write workload is unchanged. The private bounded probe passed once; it is not distributed-backend or full-workload acceptance.

Necessary boundaries and non-goals

No database transaction across model/tool calls or user hooks; preserve producer/CAS fences, same-version recovery, cancellation, unknown outcomes, deferred tools, authorization and observation visibility. Do not change auto_recover, merge retention before late holds settle, or introduce a parallel model-fact owner. Useful small query projections remain allowed. Wider IO and application acceptance remain separate from this synthetic upstream fixture.

Validation

• Read-reuse slice: 65 focused receipt/retention/exact-context tests passed; final receipt suite with opt-in SQL measurement 15 passed (overlapping, not 80 distinct tests). Fixed default probe 1 passed, unchanged 46/38 and 31/129/44 SQL totals. Original replay/history/effect assertions retained.

• Earlier separate effect-free diagnostic: 1 passed, differing policy explicitly recorded, not a candidate improvement.

• Repository manage Ruff gate and git diff --check: passed.

• Independent review of the read-reuse production change, regressions and measured scope passed with no must-fix. Public evidence and reproduction instructions are in the measurement document.

• Prior exact head fc92b8d6 natural CI 43539839206: 21/21 success.

• Natural CI 43541287384 at 530df312 exposed 3 distinct incomplete test fixtures across both Python versions: they bypassed construction and omitted the already-existing retained-publication default. 52a9edb6 adds that None initialization only; production code, authorization/timeout assertions and timeout values are unchanged. The 3 failures were reproduced before the fix; 135 focused tests passed afterward, including both complete affected files and real-construction receipt/result-read tests. Independent review passed.

• Prior head 52a9edb6 natural pull-request CI 43542147907, attempt 1: 21/21 jobs success, completed at 2026-11-14 01:50:01 UTC. The Trace-on diagnostic also passed its 8-model/6-tool/16-history and replay assertions. No manual CI dispatch/rerun.

• R3 head 9bb77e84 natural pull-request CI 43559195820: 21/21 jobs success.

• Prior exact head 082b0952 natural pull-request CI 43559916299, attempt 1: 21/21 jobs success. No manual dispatch/rerun. The PR remains Draft because the broader R3 objective and designated acceptance are not closed.

• Prior head 80c030f1 natural pull-request CI 43578018551 completed with 19 successful jobs, one failed runtime shard and its failed aggregate. The Python 3.15.2 shard reported one cancel_commit timeout; 2,596 other tests in that shard passed. This was not treated as a green head or retried manually.

Cancellation settlement correction

• Head e03710cc registers an already-cancelling worker in the existing cancellation-request set before its first settlement await, only when that exact task is still the installed worker. A later public cancellation drains the same settlement rather than cancelling it again. No new state, protocol, timeout or effect assumption is added.
• The failure is reproducible with a deterministic interleaving: direct worker cancellation begins durable cleanup, then the public cancellation operation reaches that same worker. The unfixed parent 082b0952 also fails the same regression with WAIT_TIMEOUT and an unknown cancellation result, so this is not attributed to the 80c030f1 returned-row optimization.
• Original provider-count, durable Trace status, cleared-flight and terminal CANCELLED assertions remain. 27 joint-boundary/cancellation-quiescence tests and 15 focused remote-cancel, concurrent-hold, stale-worker and confirmed-Task-cancellation cases passed on Python 3.12.14. Architecture/Ruff gates and independent static review passed. No timeout was widened or assertion relaxed; Python 3.15 is left to natural CI.
• Current exact head e03710cc natural pull-request CI 43579471334 completed with 21/21 jobs successful, including both runtime Python matrices. No manual dispatch/rerun. This is a correctness correction, not another I/O improvement; the 38-write objective and wider acceptance remain open, and the PR remains Draft.

本轮：持久 hold 释放前不做无效清理

同一真实 SQLite 小样例：总提交 5→3，SELECT 9→7，写提交仍为 2。释放持久 hold 和实际终态所有权移交顺序不变；原本过早发起、必然被 hold 阻止的数据库读不执行，先交还瞬态 claim，不丢失释放意图。34 项窄验证通过，包含失败/取消不占死 gate，独立静态复审未发现本切片必须项。当前 head a8b7933512856eda49d7d9debbb77f8fa3540214 仍 Draft，待该 head 自然 CI；不宣称原场景 38 次写提交目标已解决。

修复 a8b79335 的 CI 测试卡住

43589739377 两个回归用例分别依赖错误替身：一处没有接受真实清理回调的 terminal_commit；另一处名为立即终态、实际只持久化 STARTED。两个用例随后无界等事件，掩盖错误。当前提交 4bef82d71e1865b5e99f57fef7122a63d35a848d 只修测试：持久化真实 SUCCEEDED 记录，匹配实际回调契约，断言 durable hold 已移除才启动清理，并在超时后释放和回收任务。失败已分别重现，官方局部入口运行三个文件，共 35 passed，独立静态复审闭环。未修改生产优化、未手动重跑 CI。

最新 CI

43591283468 15/15 成功。实际 checkout 是 bc2ef50，日志确认该合成合并为 head 4bef82d7 + 当时 master 9a9fdecd。保留 Draft：这闭环的是清理顺序修复，整体写事务目标和真实多端数据库验收未由此证明。

Write-count recheck on 2026-11-14

Independent reruns of the fixed SQLite two-turn probe at current master a642b557 and this head both passed. Both returned 31 SELECT, 129 INSERT, 44 UPDATE, 46 total commits and 38 write commits; model, tool, history and replay obligations remained unchanged. The earlier 5→3 focused hold scenario is not a reduction in this two-turn workload. Terminal publication already settles Session in the same commit. The later retention commit preserves the post-terminal dependency-hold window; repository instruction scope also must survive a failed execution barrier CAS. Neither boundary was removed. No new production change; the broader transaction target remains open.

Pending replay original reads

On one real SQLite response with two replayed tool calls, original-message range reads dropped 2 → 1. Reuse is limited to the existing 32-candidate window; the per-call name/argument integrity checks, ordering, cursor freeze and filtering remain. The focused file passed locally (9 tests); exact-head natural CI is separate. This is an R3 read slice only, not a reduction in the two-turn 38 write commits.