apache · Astro-Han · Sep 3, 2026 · Aug 31, 2026
diff --git a/docs/architecture/agent-graph-stream-scheduling-draft.md b/docs/architecture/agent-graph-stream-scheduling-draft.md
@@ -561,6 +561,8 @@ The current Graph should not be mistaken for a general distributed stream proces
 
 These are deliberate boundaries. They keep Graph useful without moving workflow semantics, resource management, or product presentation into the Agent runtime.
 
+Tracking for the replay timeline and reconcile-history gaps above: [Agent Graph operational topology #2596](https://github.com/apache/maka/issues/2596), [Session Inspector #1625](https://github.com/apache/maka/issues/1625)
+
 ## Graph, Swarm, agent_spawn, and Rive
 
 The four mechanisms solve different coordination problems.

diff --git a/docs/architecture/agent-graph-stream-scheduling-draft.zh-CN.md b/docs/architecture/agent-graph-stream-scheduling-draft.zh-CN.md
@@ -558,6 +558,8 @@ sequenceDiagram
 
 这些都是有意保留的边界。它们让 Graph 有用，同时不把 workflow semantic、resource management 或 product presentation 塞进 Agent runtime。
 
+上述 replay timeline 与 reconcile history 缺口的跟踪：[Agent Graph operational topology #2596](https://github.com/apache/maka/issues/2596)、[Session Inspector #1625](https://github.com/apache/maka/issues/1625)
+
 ## Graph、Swarm、agent_spawn 与 Rive
 
 四种机制解决不同的协调问题。

diff --git a/docs/architecture/bot-onboarding-runtime.zh-CN.md b/docs/architecture/bot-onboarding-runtime.zh-CN.md
@@ -33,6 +33,8 @@ owners:
 
 状态：Current（2026-08-31）
 
+跟踪：[Bot onboarding V1 后续加固 #4327](https://github.com/apache/maka/issues/4327)
+
 ## 1. 目标与边界
 
 Maka 的 IM 接入同时支持两条路径：

diff --git a/docs/architecture/gitoxide-repository-admission-capability-v1.zh-CN.md b/docs/architecture/gitoxide-repository-admission-capability-v1.zh-CN.md
@@ -19,6 +19,8 @@
 
 # Gitoxide repository admission capability v1
 
+完整的 Phase 3/4 workspace continuity 路线见 [Runtime Resume Phase 3/4 Workspace Checkpoint Design](./runtime-resume-phase3-phase4-workspace-checkpoint-design.zh-CN.md)，其交付状态由该设计文档链接的 tracker 统一维护。
+
 状态：Gitoxide repository admission / source-import 的可合并 enabling infrastructure；source import data
 plane 作为同一 PR 内的独立 authority layer 消费该 capability，产品接线仍未完成。
 

diff --git a/docs/architecture/llm-compaction-events-log-projection-draft.md b/docs/architecture/llm-compaction-events-log-projection-draft.md
@@ -447,11 +447,11 @@ Maka has one LLM compaction mechanism and one adjacent current-request rewrite:
 | Mechanism | Source | When it runs | Durable result | Role in this chapter |
 |---|---|---|---|---|
 | History LLM compaction | Safe RuntimeEvent prefix | Manual request, pre-turn capacity, active-turn capacity, or provider overflow | Schema V2 or V3 checkpoint recorded in the AgentRun event ledger | Primary subject |
-| Active Tool Result Prune | Provider-visible Tool Result in the current Turn | Before the next step in the same Turn | Raw result is archived first; placeholder changes only current messages | Primary subject of Chapter 2 |
+| Active Tool Result Prune | Provider-visible Tool Result in the current Turn | Before the next step in the same Turn | Raw result is archived first; a projection transition durably records the replacement | Primary subject of Chapter 2 |
 
 Both preserve canonical source, but they do not create parallel compaction authorities. History compaction always selects a safe RuntimeEvent prefix, generates and validates one replacement, then persists one checkpoint before replay. Trigger-specific code may pin the live head or reserve a verbatim tail; it does not own another planner, summary format, controller, or durable block.
 
-Active Tool Result Prune remains a deterministic non-LLM rewrite. It archives an eligible raw Tool Result before replacing that result in the current provider request. It neither summarizes a span nor creates a checkpoint, and the later history-compaction planner reads the canonical RuntimeEvents rather than treating prune placeholders as source authority.
+Active Tool Result Prune remains a deterministic non-LLM rewrite. It archives an eligible raw Tool Result, appends a durable projection transition to the AgentRun event ledger, and derives the current request from the effective-history reducer. The same reducer supplies later replay, restart, budgeting, and compaction. Prune neither summarizes a span nor creates a checkpoint, and canonical RuntimeEvents remain unchanged.
 
 The placeholder carries a bounded `maka://archive/...` address and instructions for `ArchiveRead`; model replay deterministically reconstructs that address for legacy placeholders. Runtime does not eagerly expand the archived body back into every request. The model calls `ArchiveRead` only when it needs the detail, and the Host validates the Session, hash, and byte size before returning a bounded inspect or query result. A later checkpoint replaces covered placeholders with its summary and intentionally carries no archive roots. The complete Tool Result remains in the canonical RuntimeEvent ledger, but model reachability does not become a permanent cross-checkpoint authority.
 

diff --git a/docs/architecture/llm-compaction-events-log-projection-draft.zh-CN.md b/docs/architecture/llm-compaction-events-log-projection-draft.zh-CN.md
@@ -447,11 +447,11 @@ Maka 只有一套 LLM compaction 机制，以及一个相邻的 current-request
 | 机制 | Source | 发生时机 | Durable result | 本章定位 |
 |---|---|---|---|---|
 | History LLM compaction | 安全的 RuntimeEvent prefix | 手动请求、pre-turn capacity、active-turn capacity 或 provider overflow | Schema V2 或 V3 checkpoint 记录进 AgentRun event ledger | 本章主体 |
-| Active Tool Result Prune | 当前 Turn 的 provider-visible tool result | 同一 Turn 的下一 step 前 | raw result 先归档；placeholder 只改当前 messages | 第二章主体 |
+| Active Tool Result Prune | 当前 Turn 的 provider-visible tool result | 同一 Turn 的下一 step 前 | raw result 先归档；projection transition 持久记录 replacement | 第二章主体 |
 
 两者都保留 canonical source，但不会形成并行的 compaction authority。History compaction 始终选择安全 RuntimeEvent prefix，生成并校验一个 replacement，再先持久化一个 checkpoint、后进入 replay。trigger-specific 代码可以固定 live head 或保留 verbatim tail，但不再拥有另一套 planner、summary format、controller 或 durable block。
 
-Active Tool Result Prune 仍是 deterministic、非 LLM 的 rewrite。它先归档 eligible raw Tool Result，再替换 current provider request 中的该结果。它既不总结 span，也不创建 checkpoint；后续 history-compaction planner 读取 canonical RuntimeEvents，不会把 prune placeholder 当成 source authority。
+Active Tool Result Prune 仍是 deterministic、非 LLM 的 rewrite。它先归档 eligible raw Tool Result，再向 AgentRun event ledger 追加 durable projection transition，并由 effective-history reducer 生成 current request。后续 replay、restart、budgeting 与 compaction 也消费同一 reducer。Prune 既不总结 span，也不创建 checkpoint，canonical RuntimeEvents 保持不变。
 
 Placeholder 携带 bounded `maka://archive/...` 地址和 `ArchiveRead` 指令；model replay 会为 legacy placeholder 确定性补回这个地址。Runtime 不再把 archived body eager-expand 回每次请求。只有模型确实需要细节时才调用 `ArchiveRead`，Host 在返回 bounded inspect/query 结果前校验 Session、hash 与 byte size。后续 checkpoint 会用 summary 替换已覆盖的 placeholder，并且有意不携带 archive roots。完整 Tool Result 仍在 canonical RuntimeEvent ledger 中，但 model reachability 不会变成永久的 cross-checkpoint authority。
 

diff --git a/docs/architecture/managed-dependency-storage-authority-v1.zh-CN.md b/docs/architecture/managed-dependency-storage-authority-v1.zh-CN.md
@@ -26,6 +26,8 @@ base: upstream/main@08bcf324b
 
 # Managed Dependency Storage Authority v1
 
+跟踪：[Managed dependencies #4326](https://github.com/apache/maka/issues/4326)
+
 ## 1. 本 PR 只证明一个不变量
 
 > 同一个 canonical dependency environment identity 最多对应一棵由 Maka 发布、由 artifact 权限域之外的 durable receipt 证明、可在崩溃后收敛重开的依赖树；任何身份、路径、内容或平台证据不可证明时 fail closed。

diff --git a/docs/architecture/mcp-runtime-architecture-draft.zh-CN.md b/docs/architecture/mcp-runtime-architecture-draft.zh-CN.md
@@ -19,9 +19,9 @@
 
 # Maka MCP runtime architecture
 
-状态：remote 与 stdio dual-era V3 implemented（2026-08-25）
+状态：remote 与 stdio dual-era V3 implemented（2026-08-25，见已完成的 [#1650](https://github.com/apache/maka/issues/1650)）
 
-跟踪：[MCP 2026-07-28 dual-era rollout #1650](https://github.com/apache/maka/issues/1650)
+跟踪：[MCP post-V3 roadmap #4329](https://github.com/apache/maka/issues/4329)
 
 ## 1. 目标与边界
 
@@ -151,10 +151,8 @@ timeout 默认值：remote connect 30s、stdio connect 60s、list 15s、call 10m
 11. SEP-2243 定义 partition、bounded warning、safe integer 和 wire 前失败有自动化覆盖；legacy 路径不误启用 modern header 语义。
 12. stdio 省略 protocol 只启动一个 legacy child；`auto`、legacy/modern exact pin、probe/actual 顺序、probe stderr 隔离，以及 probe 前或进行中的 abort 都有真实 child-process fixture 覆盖。
 
-## 8. 后续 backlog
+## 8. 后续路线
 
-- OAuth 2.1 authorization server metadata、PKCE、dynamic client registration 和 Keychain token persistence。
-- resources/templates browse、read、subscribe/unsubscribe 及 host UI。
-- authenticated loopback MCP proxy，供受控 subprocess client 共享 pool。
-- per-server health/backoff/automatic crash recovery 与 finer-grained permission policy。
-- signed remote catalog、last-known-good cache、guided setup schema、package provenance 与 update permission diff。
+Post-V3 工作继续围绕 credential custody、resources/templates、受控 subprocess 复用、server health 与可信分发推进。具体完成状态和剩余交付只在 tracker 中维护，避免本文形成第二份会漂移的 checklist。
+
+跟踪：[MCP post-V3 roadmap #4329](https://github.com/apache/maka/issues/4329)
diff --git a/docs/architecture/runtime-core-architecture-draft.md b/docs/architecture/runtime-core-architecture-draft.md
@@ -142,6 +142,8 @@ RuntimeEvents preserve canonical message semantics for AI interaction, but they
 
 “State-space replay” in this chapter therefore means reconstructing interaction semantics and Runtime state first. A future promise of bit-exact deterministic replay would also require versioning or snapshotting runtime configuration, prompts, the tool catalog, projection policy, and provider request shape. This does not weaken the Event Log; it clarifies why the log is the correct foundation. Message facts remain stable while request materialization can evolve independently.
 
+Tracking: [Recovery-grade RuntimeEvent ledger #615](https://github.com/apache/maka/issues/615)
+
 ## Two lines of intellectual influence
 
 The design has two explicit conceptual roots.
@@ -168,6 +170,8 @@ Before following the main path, separate the three lifecycle concepts that are o
 
 RuntimeEvents still carry `invocationId` as a compatibility and event-correlation field. On the production path it is bound to the Run identity; it no longer implies a separate Invocation lifecycle object or Runner layer.
 
+Tracking: [RuntimeInvocation event spine #4311](https://github.com/apache/maka/issues/4311)
+
 The key distinction is simple: **a Turn is not a Run, and chat messages are not execution state.** A user-visible exchange needs a system-visible execution envelope. Without one, the system can only say that some messages appeared; it cannot reliably say whether the execution actually ended.
 
 ## The execution path around the Event Log
@@ -393,6 +397,8 @@ Continuing execution is a separate path. `safe_boundary_continuation` resumes fr
 
 These are real architecture boundaries, not details to hide. Future Backend decomposition or checkpoint work must preserve request shape, tool visibility, event order, and the terminal invariant before optimizing for smaller files.
 
+Tracking: [`AiSdkBackend` decomposition #3909](https://github.com/apache/maka/issues/3909)
+
 ## Code-reading map
 
 Read the current implementation in this order:

diff --git a/docs/architecture/runtime-core-architecture-draft.zh-CN.md b/docs/architecture/runtime-core-architecture-draft.zh-CN.md
@@ -142,6 +142,8 @@ RuntimeEvent 保存了 AI 交互的 canonical message semantics，但当前并
 
 因此，本章所说的“状态空间回放”首先是**交互语义与 Runtime 状态的可重建性**。如果未来要承诺 bit-exact deterministic replay，还需要对运行配置、prompt、tool catalog、投影策略和 provider request shape 做版本化或快照化。这不是削弱 Event Log 的价值，反而说明它提供了正确的基础：message facts 保持稳定，request materialization 可以独立演进。
 
+跟踪：[Recovery-grade RuntimeEvent ledger #615](https://github.com/apache/maka/issues/615)
+
 ## 两条思想来源
 
 这个设计有两条明确的思想脉络。
@@ -168,6 +170,8 @@ Maka 并不是在进程内实现了 Kafka，也没有声称 RuntimeEventStore
 
 RuntimeEvent 仍保留 `invocationId` 作为兼容与事件关联字段。生产主链把它绑定到 Run 身份；它不再对应单独的 Invocation 生命周期对象或 Runner 层。
 
+跟踪：[RuntimeInvocation event spine #4311](https://github.com/apache/maka/issues/4311)
+
 这里最重要的判断是：**Turn 不是 Run，聊天消息也不是执行状态。** 一个用户可见的回合需要一个系统可追踪的执行封套；否则，系统只能知道“出现过一些消息”，却无法可靠回答“这次执行是否真正结束”。
 
 ## 围绕 Event Log 运转的执行主链
@@ -391,6 +395,8 @@ Maka 当前保护的核心不变量是：
 
 这些不是应该隐藏的实现细节，而是当前架构的真实边界。未来拆分 Backend 或加入 checkpoint 时，首要目标不是减少文件行数，而是保持 request shape、工具可见性、事件顺序和 terminal invariant 不变。
 
+跟踪：[`AiSdkBackend` decomposition #3909](https://github.com/apache/maka/issues/3909)
+
 ## 代码阅读地图
 
 建议按照下面的顺序阅读当前实现：

diff --git a/docs/architecture/runtime-resume-architecture.md b/docs/architecture/runtime-resume-architecture.md
@@ -32,6 +32,8 @@ owners:
 
 # Chapter 8: Resume Is Not Retry—How Maka Continues Safely from Crash Facts
 
+Tracking: [Production Write/Edit recovery #4319](https://github.com/apache/maka/issues/4319), [safe-boundary continuation hardening #4324](https://github.com/apache/maka/issues/4324), [sandbox boundary negotiation #3731](https://github.com/apache/maka/issues/3731)
+
 > This chapter answers a deceptively dangerous question: when Maka crashes while a model is calling a tool, how can a restart tell what happened, what may continue, and what must stop for human attention? The answer is: **recover facts from immutable RuntimeEvents, let one RecoveryResolver classify tool state, and create a new Run only when history, execution, and workspace boundaries are all provably safe. Resume never resurrects the old process or disguises “try again” as recovery.**
 
 This chapter is for engineers entering Maka Runtime for the first time. The first half builds intuition with an interrupted file write. The second half explains Phases 0–4, Desktop and CLI integration, T1/T2, recovery decisions, workspace checkpoints, and the recommended implementation sequence.

diff --git a/docs/architecture/runtime-resume-architecture.zh-CN.md b/docs/architecture/runtime-resume-architecture.zh-CN.md
@@ -32,6 +32,8 @@ owners:
 
 # 第八章：Resume 不是重试——Maka 如何从崩溃事实安全继续
 
+跟踪：[生产级 Write/Edit 恢复 #4319](https://github.com/apache/maka/issues/4319)、[safe-boundary continuation 加固 #4324](https://github.com/apache/maka/issues/4324)、[sandbox boundary negotiation #3731](https://github.com/apache/maka/issues/3731)
+
 > 本章回答一个看起来简单、实际上很危险的问题：Maka 在模型调用工具时崩溃，重启后怎样知道哪些事情已经发生、哪些事情可以继续、哪些事情必须停下来等人处理？核心答案是：**先从不可变的 RuntimeEvent 恢复事实，再由唯一的 RecoveryResolver 判定工具状态；只有历史、执行和 workspace 三条边界都能证明安全时，才创建新的 Run 继续。Resume 从不复活旧进程，也不把“再试一次”伪装成恢复。**
 
 本文面向第一次接触 Maka Runtime 的工程师。前半部分用一个文件写入例子建立直觉，后半部分说明 Phase 0–4、Desktop/CLI 接线、T1/T2、恢复判定、workspace checkpoint 和工程实施顺序。

diff --git a/docs/architecture/runtime-resume-extraction-ledger.zh-CN.md b/docs/architecture/runtime-resume-extraction-ledger.zh-CN.md
@@ -26,6 +26,8 @@
 - PR A 已合并：`upstream/main@086ec99d`（#1521）
 - 当前 PR B 平铺基线：`upstream/main@e4c6ddbf`
 - 当前 PR B 平铺分支：`codex/runtime-continuation-correctness`
+- 跟踪：[生产级 Write/Edit 恢复 #4319](https://github.com/apache/maka/issues/4319)
+- 跟踪：[safe-boundary continuation 加固 #4324](https://github.com/apache/maka/issues/4324)
 
 ## 1. 目的
 

diff --git a/.../architecture/runtime-resume-phase3-phase4-workspace-checkpoint-design.zh-CN.md b/.../architecture/runtime-resume-phase3-phase4-workspace-checkpoint-design.zh-CN.md
@@ -30,6 +30,8 @@
 - 事实权威：immutable RuntimeEvents
 - 主要平台：Linux、macOS；Windows 有限支持
 - 拆分审计：`runtime-resume-extraction-ledger.zh-CN.md`
+- 跟踪：[生产级 Write/Edit 恢复 #4319](https://github.com/apache/maka/issues/4319)
+- 跟踪：[safe-boundary continuation 加固 #4324](https://github.com/apache/maka/issues/4324)
 
 ## 1. 四个正交平面
 
@@ -407,6 +409,8 @@ provider materializer/projection version
 permission/sandbox execution-policy digest（会影响可执行语义时）
 ```
 
+跟踪：[sandbox boundary negotiation #3731](https://github.com/apache/maka/issues/3731)。该 issue 只覆盖 permission/sandbox execution-policy 跨安全续接，不覆盖完整 execution profile 的其余字段。
+
 boundary 证明“继续哪一段事实”，execution profile 证明“按照哪套执行语义继续”。两者必须分开
 摘要并同时匹配；不能在执行时用当前 Session 配置重新生成 target header，从而把 plan 后的模型、
 prompt 或同名工具 schema 漂移悄悄合法化。
@@ -539,6 +543,8 @@ projection reader/rebuild 与升级合同继续保留；它们是历史事实 au
 
 ## 4. Gitoxide managed workspace 后续边界
 
+跟踪：[Gitoxide workspace continuity #4325](https://github.com/apache/maka/issues/4325)
+
 后续强模式必须从 Gitoxide data plane 建立新的 production composition，并分别证明：
 
 - packaged helper 的 trust root、artifact identity 与 bounded invocation；

diff --git a/docs/permission-onboarding-plan.md b/docs/permission-onboarding-plan.md
@@ -23,6 +23,8 @@ Status: **Stage 1 built** (`apps/desktop/src/main/permission-overlay/`,
 `apps/desktop/src/overlay/permission-overlay.*`). Stage 2 is still a proposal.
 Written 2026-07-27 for maka.
 
+Tracking: [macOS permission onboarding Stage 2 #4328](https://github.com/apache/maka/issues/4328)
+
 ## The problem
 
 macOS gates Accessibility and Screen Recording behind TCC, and the stock

diff --git a/docs/side-conversation.md b/docs/side-conversation.md
@@ -436,14 +436,6 @@ failure observed in this pass succeeded when rerun in isolation.
 
 ## Follow-up Work
 
-1. Extract the remaining surface switch into a registered tab descriptor model
-   before adding third-party panel types.
-2. Surface parent status in the panel when the main Session needs input,
-   approval, or completes.
-3. Decide whether an explicit user request should be able to promote a side
-   conversation to a durable ordinary Session before adding write access.
-4. Add commit selection to Review, then hunk-level stage/unstage/revert
-   actions.
-5. Add filesystem watching and multi-repository aggregation to Review.
-6. Add remote-host Terminal creation and a restorable route only after the
-   Runtime can reattach or recreate a terminal honestly across app restart.
+Follow-up work continues to preserve the lifecycle and authority boundaries documented above. Its status and decomposition live in the tracker so this design does not become a second checklist.
+
+Tracking: [Side Conversation follow-ups #4331](https://github.com/apache/maka/issues/4331)
diff --git a/docs/web-search-provider-capability.md b/docs/web-search-provider-capability.md
@@ -225,18 +225,10 @@ search-heavy workflows that value source visibility over cache economics.
 
 ## Follow-up adapters
 
-Add adapters in this order:
-
-1. Add an opt-in `web_search_20260209` capability for Anthropic deployments
-   that support dynamic filtering; retain `20250305` as the compatibility
-   baseline used by Claude Code and third-party Anthropic-compatible services.
-2. Gemini grounding with Google Search.
-3. Z.AI native model tool. Keep its standalone Search API outside the
-   provider-native path.
-4. OpenRouter web plugin.
-5. Mistral Agents and Groq Compound, after defining their cost and result-row
-   projection contracts.
-
 Every adapter must execute in the primary model request, preserve provider tool
 events and citation metadata, keep credential isolation, and retain explicit
 no-fallback behavior.
+
+Adapter status and ordering live in the tracker rather than a duplicate list in this design.
+
+Tracking: [Provider-native web search #4330](https://github.com/apache/maka/issues/4330)