docs(windows): define sandbox backend security contract

[liugddx]

English Version

Summary

• Define the Windows sandbox threat model, enforcement contract, delivery gates, and adversarial evidence requirements.
• Add paired English and Chinese RFCs.
• Ground the architecture in pinned primary-source reviews of Microsoft APIs, OpenAI Codex, Gemini CLI, Chromium, Claude Code, and OpenCode.
• Revise the proposed baseline after source review to use dedicated sandbox identities, restricted tokens, Job Objects, private desktops, explicit handles, ACL reconciliation, and identity-scoped network policy.
• Retain AppContainer as a W0 comparison target instead of claiming that it has already been selected.
• Refresh the sandbox README to reflect the implemented Linux bubblewrap backend.

Design Status

This PR is the complete Phase 4 security design baseline for #2142, but it is not yet a frozen implementation specification and does not enable Windows restricted profiles.

Three W0 gates remain explicit:

1. Extract or adapt the Apache-2.0 Codex Windows sandbox component, or build a Maka-owned implementation.
2. Freeze the setup, identity, ACL ledger, protocol, upgrade, uninstall, and crash-recovery schemas.
3. Select and prove WFP, verified Windows Firewall rules, or a combination for network denial.

The RFC estimates W0 through W3 at 7 to 12 weeks for one experienced engineer. If W0 validates the proposed baseline, the managed read-only Read, Glob, and Grep milestone is estimated at roughly 3 to 5 weeks.

Research Boundary

The survey is representative, not exhaustive. It includes projects that ship a native agent-oriented Windows sandbox, a mature Windows process sandbox, or an explicit public Windows isolation contract. Closed or undocumented implementations are not treated as evidence. Every repository observation is pinned to a reviewed commit.

Verification

• git diff --check upstream/main...HEAD
• Reviewed the current Maka SandboxManager, Linux bubblewrap, macOS Seatbelt, diagnostics, filesystem worker, and Runtime Host composition.
• Reviewed pinned source trees for Codex, Gemini CLI, Chromium, and OpenCode, plus the public Claude Code repository and documentation.
• Verified that the current revision's full GitHub CI passes, including Windows baseline and Windows recovery.

This revision changes documentation only. The clean local workspace intentionally has no installed dependencies; GitHub CI is authoritative for repository tests.

Related to #2142. This PR does not close the umbrella issue.

---

中文版

中文版

概要

• 定义 Windows 沙箱的威胁模型、强制执行契约、交付阶段和对抗性验证要求。
• 增加配套的中文与英文 RFC。
• 基于固定提交版本的一手资料修订架构，调研范围包括 Microsoft 官方 API、OpenAI Codex、Gemini CLI、Chromium、Claude Code 和 OpenCode。
• 源码调研后，将拟议基线调整为：专用沙箱身份、受限令牌、作业对象、私有桌面、显式句柄、ACL 协调以及基于身份的网络策略。
• AppContainer 保留为 W0 阶段的对比候选，不提前宣称已经定案。
• 修正沙箱 README 中已经过时的 Linux bubblewrap 实现状态。

设计状态

本 PR 是 #2142 第四阶段完整的安全设计基线，但还不是已经冻结的实现规格，也不会启用 Windows 受限权限配置。

W0 阶段仍有三个明确的准入条件：

1. 评估抽取或适配采用 Apache-2.0 许可证的 Codex Windows 沙箱组件，或者采用 Maka 自有实现。
2. 冻结安装、身份、ACL 台账、通信协议、升级与卸载的数据结构及崩溃恢复方案。
3. 在 WFP、经过验证的 Windows 防火墙规则或两者组合中完成选型，并提供网络拒绝的有效性证据。

RFC 当前估算：一名有经验的工程师完成 W0 至 W3 约需 7 至 12 周。如果 W0 证明拟议基线可行，托管 Read、Glob、Grep 的只读里程碑约需 3 至 5 周。

调研边界

本次是代表性调研，不声称穷尽所有热门项目。纳入标准是：已经交付面向智能体的原生 Windows 沙箱、拥有成熟的 Windows 进程沙箱，或者公开了明确的 Windows 隔离契约。闭源或没有公开文档的实现不作为实现证据；所有仓库结论均固定到已经审查的提交版本。

验证

• git diff --check upstream/main...HEAD
• 已审查 Maka 当前的 SandboxManager、Linux bubblewrap、macOS Seatbelt、诊断机制、文件系统工作进程及 Runtime Host 组合方式。
• 已审查固定版本的 Codex、Gemini CLI、Chromium、OpenCode 源码树，以及 Claude Code 的公开仓库和文档。
• 当前修订的 GitHub CI 已全部通过，包括 Windows baseline 和 Windows recovery。

本次修订仅修改文档。本地工作区按要求保持无依赖的干净状态，仓库测试以 GitHub CI 为准。

关联 #2142。本 PR 不会关闭该总任务。

[liugddx]

Closing this proposal as superseded by #2961.

#2961 records the Windows CI-backed AppContainer decision, carries the updated English and Chinese RFCs, and implements the packaged fail-closed Runtime path. The original #2940 proposal kept AppContainer as a W0 comparison target and therefore is no longer the current implementation baseline.

Progress and the remaining platform-support gates continue in #2142.

关闭原因：本提案已由 #2961 取代。#2961 根据 Windows 实测选定 AppContainer，包含更新后的中英文 RFC 及实际 Runtime 集成；#2142 继续跟踪尚未完成的 Windows 正式支持门槛。