refactor(sandbox-policy): remove capability family registries

.agents/notes/implemented/feature/2026-07-30-current-sandbox-policy-context.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write .agents/notes/implemented/feature/2026-07-30-current-sandbox-policy-context.md
-2026-07-30-current-sandbox-policy-context.md: 87b67ede9576dafc8151925e676d789f1f5a160e
-2026-07-30-current-sandbox-policy-context.zh.md: fd0c5161174c5e94439bc13a9be240c43502b5f5
+2026-07-30-current-sandbox-policy-context.md: 093f9a8a0b58256bb4f2301cc62fa83629de4fbd
+2026-07-30-current-sandbox-policy-context.zh.md: 729ea9d50c7dbbfa027e1cad11929ae1c2b379b1

.agents/notes/implemented/feature/2026-07-30-current-sandbox-policy-context.md

@@ -12,9 +12,9 @@ The sandbox policy already enforced and logged each session's file-effect mode,
 
 `dsh-sandbox-policy`, the owner of mode and workspace-root resolution, registers one `sandbox:policy` cache-safe context contribution. Every agent request resolves the active session directly through `ctx.sandboxPolicy.resolve({ session })`; there is no denial-history scan or process-local “last told” state.
 
-Enforcing backends register independently disposable `filesystem`, `bash`, or `terminal` family contributions with the policy owner. The contribution names only registered families in canonical order, and is empty without one. This is current need, not a future extension: the shipped headless inheritance composition combines sandboxed filesystem tools with unfenced one-shot bash, while the persistent-tools composition combines sandboxed filesystem tools and terminal commands without a sandboxed one-shot bash executor. A blanket statement would be false in both.
+The policy contribution is capability-neutral and present for every agent session. It does not maintain a second inventory of mounted backends or tools; model-visible schemas remain the authority for available operations, while the context conditions its claims on any available operation that the DSH file sandbox enforces. The [capability-neutral policy context decision](../simplification/2026-07-31-capability-neutral-sandbox-policy-context.md) supersedes the earlier family-registration mechanism while retaining this note's cache-safe delivery and durable snapshot design.
 
-The contribution states only facts shared by every enforcement dialect for each registered family. `read-only` says those operations cannot modify files in the standing mode. Tool owners separately register a family only when their real schema and execution path offer an approved wider retry; the read-only text adds anti-refusal guidance only for the intersection of enforced and escalatable families. `workspace-write` states the canonical session workspace with non-exclusive wording and summarizes, without enumerating, that some platform temporary areas may also be writable. `danger-full-access` says the DSH file sandbox does not restrict those operations. Backend-selected temporary paths, `/dev/null`, runner readiness, and other policy domains are absent because `resolve()` cannot establish them at request assembly.
+The contribution states only facts shared by every enforcement dialect. `read-only` says an available sandbox-enforced operation cannot modify files in the standing mode and directs the model to try an available tool normally, then follow any denial and escalation guidance that tool returns. `workspace-write` states the canonical session workspace with non-exclusive wording and summarizes, without enumerating, that some platform temporary areas may also be writable. `danger-full-access` says the DSH file sandbox does not restrict file modifications by available operations. Backend-selected temporary paths, `/dev/null`, runner readiness, exact tool availability, and other policy domains are absent because `resolve()` cannot establish them at request assembly.
 
 The existing `dsh-system-prompt` assembly now has ordered dynamic contexts alongside stable system sections and tool schemas. After assembling one step, agent-loop renders all active contexts as one full snapshot with an explicit supersession statement. It appends a sourced `user/message` only when no retained snapshot exists, the bytes changed, compaction removed the retained message, or the final contribution disappeared and needs one clearing snapshot. The snapshot is appended after existing history and before `step/start`, so a changed policy preserves the preceding system-and-conversation cache prefix. The session event itself reconstructs the exact model input; `request/header` remains byte-identical when only policy context changes.
 
@@ -48,16 +48,16 @@ The cache-safe delivery rework then supplied a separate, non-statistical accepta
 
 **Repeat tool schemas or plan guidance in the context.** Rejected because those surfaces already have owners and independent lifecycles. Approval current state joins the snapshot only because the same `/permission` switch changes it and leaving its system section would retain the cache defect.
 
-**Keep Candidate A after the cache-safe move.** Rejected by the neutral real-provider task: the model returned a pure text refusal and made no tool call despite the existing bash attempt guidance. Candidate B states no escalation mechanics itself; it tells only families whose tools actually advertise a wider retry not to infer impossibility from the standing label, then delegates denial and escalation behavior back to those tool owners.
+**Keep Candidate A after the cache-safe move.** Rejected by the neutral real-provider task: the model returned a pure text refusal and made no tool call despite the existing bash attempt guidance. The surviving anti-refusal principle states no escalation mechanics itself; it tells the model not to infer impossibility from the standing label, then delegates denial and escalation behavior back to the available tool.
 
 **Keep sandbox mode absent because a standing mode label once caused preemptive refusal.** Rejected because a fresh Web request otherwise exposes mutation tools while withholding their standing policy, producing false capability claims before the first operation. The earlier live measurement remains a required counter-test: five of twelve turns ended without a tool call under `Bash commands run under the "read-only" file sandbox.` The committed tool-owned attempt guidance postdates that measurement, so the replacement is selected through a new positive-control experiment under the current tool contract rather than assuming the old and current conditions match.
 
-**A separate model-context package.** Rejected because Cordis services can observe current runtime contributions directly and the existing assembly service can order them. A new package would add a shallow composition seam and documentation/gate surface around the same request boundary.
+**A separate model-context package.** Rejected because the policy owner can resolve current session state directly and the existing assembly service can order it. A new package would add a shallow composition seam and documentation/gate surface around the same request boundary.
 
 **Enumerate writable temporary roots.** Rejected because the backend is selected later at `confine()`: bwrap, Landlock, Seatbelt, and the in-process filesystem fence do not grant one common temporary-path set. Host-specific paths in a standing request would be both unstable and overclaimed.
 
 ## Consequences
 
-A model can answer what registered file operations the standing mode governs before probing a tool, and the next request after `/permission` reflects the committed mode. The stable system prompt no longer changes for sandbox or approval state; a changed full context snapshot is append-only after retained history, and unchanged state adds no message. Older snapshots remain in history but are explicitly superseded by the latest full snapshot. The statement is guidance, not an enforcement guard: runtime safety still comes from the registered filesystem, one-shot bash, and terminal backends consuming the same resolved policy.
+A model receives the standing file policy before probing a tool, and the next request after `/permission` reflects the committed mode. The stable system prompt no longer changes for sandbox or approval state; a changed full context snapshot is append-only after retained history, and unchanged state adds no message. Older snapshots remain in history but are explicitly superseded by the latest full snapshot. The statement is guidance, not an enforcement guard: runtime safety still comes from filesystem, one-shot bash, and terminal backends consuming the same resolved policy.
 
-Focused tests pin all modes, family combinations, contribution disposal, canonical roots, switch timing, context ordering, clearing, stable request headers, and byte stability across different `TMPDIR` values. Keyless assembled snapshots pin the durable context message through real Loader compositions, including all three families. Keyless replay owns the neutral denial-to-escalation trajectory; it is a structural regression proof, not wording-selection evidence.
+Focused tests pin all modes, canonical roots, switch timing, service disposal, context ordering, clearing, stable request headers, resume, and byte stability across different `TMPDIR` values. Keyless assembled snapshots pin the durable context message through real Loader compositions. Keyless replay owns the neutral denial-to-escalation trajectory; it is a structural regression proof, not wording-selection evidence.

.agents/notes/implemented/feature/2026-07-30-current-sandbox-policy-context.zh.md

@@ -12,9 +12,9 @@ Status: implemented
 
 `dsh-sandbox-policy` 负责解析模式与工作区根目录，并注册一项缓存安全的 `sandbox:policy` 上下文贡献。每次 agent（智能体）请求都通过 `ctx.sandboxPolicy.resolve({ session })` 直接解析当前会话；不存在拒绝历史扫描或进程本地的「上次告知」状态。
 
-强制执行后端会向策略归属方注册可独立释放的 `filesystem`、`bash` 或 `terminal` 家族贡献。该贡献只按规范顺序列出已注册家族，没有家族时为空。这是当前需求，而不是未来扩展：已交付的 headless inheritance 组合将沙箱化文件系统工具与不受围栏约束的一次性 bash 结合，而 persistent-tools 组合则包含沙箱化文件系统工具与终端命令，却没有沙箱化的一次性 bash 执行器。笼统声明在这两种组合中都会失实。
+该策略贡献不依赖具体能力，并存在于每个 agent 会话中。它不会另行维护一份已挂载后端或工具清单；模型可见的 schema 仍是可用操作的权威来源，而上下文会将其声明限定在 DSH 文件沙箱所强制执行的任何可用操作上。[不依赖具体能力的策略上下文决策](../simplification/2026-07-31-capability-neutral-sandbox-policy-context.md)取代了较早的家族注册机制，同时保留本 Agent Note 的缓存安全交付与持久快照设计。
 
-该贡献只说明每个已注册家族的所有强制执行方言所共有的事实。`read-only` 表明这些操作在常驻模式下无法修改文件。只有真实 schema 与执行路径提供经批准的更宽松模式重试时，工具归属方才会另行注册对应家族；只读文本只对既受强制执行又可升权的家族交集添加反预防性拒绝引导。`workspace-write` 用非排他措辞说明规范化的会话工作区，并概述某些平台临时区域可能也可写，而不逐一列举。`danger-full-access` 表明 DSH 文件沙箱不会限制这些操作。后端选择的临时路径、`/dev/null`、runner 就绪状态和其他策略领域都不会出现，因为 `resolve()` 无法在请求组装时确定它们。
+该贡献只说明所有强制执行方言所共有的事实。`read-only` 表明受沙箱强制执行的可用操作在常驻模式下无法修改文件，并指示模型正常尝试可用工具，随后遵循该工具返回的任何拒绝与升权引导。`workspace-write` 用非排他措辞说明规范化的会话工作区，并概述某些平台临时区域可能也可写，而不逐一列举。`danger-full-access` 表明 DSH 文件沙箱不会限制可用操作修改文件。后端选择的临时路径、`/dev/null`、runner 就绪状态、确切的工具可用情况和其他策略领域都不会出现，因为 `resolve()` 无法在请求组装时确定它们。
 
 现有 `dsh-system-prompt` 组装在稳定系统段与工具 schema 之外，还包含有序的动态上下文。组装一个步骤后，agent loop（智能体循环）会将所有活动上下文渲染成一份带显式取代声明的完整快照。仅当不存在保留快照、字节发生变化、压缩（compaction）移除了保留消息，或最后一项贡献消失而需要一份清除快照时，它才会追加一条带来源的 `user/message`。快照追加在现有历史之后、`step/start` 之前，因此策略变化时仍会保留此前的系统与对话缓存前缀。会话事件本身可以重建确切的模型输入；只有策略上下文变化时，`request/header` 仍逐字节相同。
 
@@ -48,16 +48,16 @@ Status: implemented
 
 **在上下文中重复工具 schema 或计划引导。** 不予采用，因为这些接口已有各自归属方和独立生命周期。批准的当前状态加入快照，仅仅是因为同一个 `/permission` 切换会改变它，而把它留在系统段会保留缓存缺陷。
 
-**缓存安全迁移后仍保留 Candidate A。** 不予采用，因为中性的真实提供方任务中，尽管已有 bash 尝试引导，模型仍以纯文本拒绝，且没有调用工具。Candidate B 本身不说明任何升权机制；它只针对那些工具确实公开更宽松模式重试的家族，说明不能从常驻标签推断操作不可能完成，然后把拒绝与升权行为交还给这些工具归属方。
+**缓存安全迁移后仍保留 Candidate A。** 不予采用，因为中性的真实提供方任务中，尽管已有 bash 尝试引导，模型仍以纯文本拒绝，且没有调用工具。保留下来的反预防性拒绝原则本身不说明任何升权机制；它告诉模型不要从常驻标签推断操作不可能完成，然后把拒绝与升权行为交还给可用工具。
 
 **继续省略沙箱模式，因为常驻模式标签曾引发预防性拒绝。** 不予采用，因为新的 Web 请求否则会暴露变更工具，却隐去这些工具的常驻策略，导致模型在首次操作前错误声称自身能力。先前的线上测量仍是必须执行的反证测试：使用 `Bash commands run under the "read-only" file sandbox.` 时，十二个轮次中有五个没有调用工具。已提交的工具归属方尝试引导晚于该测量，因此应通过当前工具契约下的新阳性对照实验选择替代文案，而不能假设旧条件与当前条件相同。
 
-**独立的模型上下文包。** 不予采用，因为 Cordis 服务可以直接观察当前运行时贡献，现有组装服务也可以对它们排序。新包只会围绕同一个请求边界引入浅层组合 seam 和额外的文档／门禁表面。
+**独立的模型上下文包。** 不予采用，因为策略归属方可以直接解析当前会话状态，现有组装服务也可以对其排序。新包只会围绕同一个请求边界引入浅层组合 seam 和额外的文档／门禁表面。
 
 **枚举可写临时根目录。** 不予采用，因为后端要到稍后的 `confine()` 才会选定：bwrap、Landlock、Seatbelt 和进程内文件系统围栏并不授予一套共同的临时路径。常驻请求中的主机特定路径既不稳定，也会作出过度承诺。
 
 ## 后果
 
-模型可以在试探工具前回答常驻模式管辖哪些已注册文件操作，且 `/permission` 后的下一个请求会反映已提交的模式。稳定的系统提示词不再随沙箱或批准状态变化；变化后的完整上下文快照会在保留的历史之后仅追加，状态不变时不增加消息。较旧的快照仍保留在历史中，但最新的完整快照会明确取代它们。该声明是引导，而不是强制执行护栏：运行时安全仍来自已注册的文件系统、一次性 bash 与终端后端消费同一项解析完成的策略。
+模型在试探工具前就会收到常驻文件策略，且 `/permission` 后的下一个请求会反映已提交的模式。稳定的系统提示词不再随沙箱或批准状态变化；变化后的完整上下文快照会在保留的历史之后仅追加，状态不变时不增加消息。较旧的快照仍保留在历史中，但最新的完整快照会明确取代它们。该声明是引导，而不是强制执行护栏：运行时安全仍来自文件系统、一次性 bash 与终端后端消费同一项解析完成的策略。
 
-聚焦测试固定了所有模式、家族组合、贡献释放、规范化根目录、切换时机、上下文顺序、清除、稳定的请求 header，以及不同 `TMPDIR` 值下的字节稳定性。无密钥的组装快照通过真实 Loader 组合固定持久上下文消息，包括全部三个家族。无密钥回放负责固定中性的拒绝到升级轨迹；它是结构回归证明，而不是措辞选型证据。
+聚焦测试固定了所有模式、规范化根目录、切换时机、服务释放、上下文顺序、清除、稳定的请求 header、恢复，以及不同 `TMPDIR` 值下的字节稳定性。无密钥的组装快照通过真实 Loader 组合固定持久上下文消息。无密钥回放负责固定中性的拒绝到升级轨迹；它是结构回归证明，而不是措辞选型证据。

.agents/notes/implemented/simplification/2026-07-31-capability-neutral-sandbox-policy-context.i18n.yaml

@@ -0,0 +1,6 @@
+# Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
+# side as of the last confirmed-consistent state. Both languages carry equal authority;
+# after editing either side, bring the other along and re-record with:
+#   pnpm run verify-translation-pairing --write .agents/notes/implemented/simplification/2026-07-31-capability-neutral-sandbox-policy-context.md
+2026-07-31-capability-neutral-sandbox-policy-context.md: d45c6c652fb7a061c2f92b7e03c41cce39da2a30
+2026-07-31-capability-neutral-sandbox-policy-context.zh.md: 9a1bb7a13d934826dddf89b409b25ba892a31ea3

.agents/notes/implemented/simplification/2026-07-31-capability-neutral-sandbox-policy-context.md

@@ -0,0 +1,35 @@
+# Agent Note: Capability-neutral sandbox policy context
+
+Status: implemented
+
+English | [中文](2026-07-31-capability-neutral-sandbox-policy-context.zh.md)
+
+## Problem
+
+The current-policy context originally mirrored runtime composition through separate enforced-family and escalatable-family registries. Six backend, tool, and example call sites contributed `filesystem`, `bash`, or `terminal`; the policy service retained token sets for independent disposal, intersected and ordered the two registries, invalidated prompt assemblies on every lifecycle change, and tested every family combination.
+
+That inventory was neither needed to state the file policy nor authoritative for model-visible capability. A backend contribution could name a family whose model-facing tool was absent or hidden by request scope, while tool schemas already told the model which exact operations were available. The registries therefore widened the public service and lifecycle contract to maintain an approximate English sentence.
+
+## Decision
+
+`dsh-sandbox-policy` contributes one capability-neutral `sandbox:policy` context for every agent session. It derives the text only from `resolve({ session })`; there is no backend or tool family registration API, contribution map, ordering rule, or registration-driven prompt invalidation.
+
+The text conditions capability claims on available operations that the DSH file sandbox enforces. Under `read-only`, it states that such operations cannot modify files in the standing mode and tells the model to try an available tool normally, then follow any denial and escalation guidance that tool returns. Under `workspace-write`, it states the canonical session workspace and the qualified temporary-area allowance. Under `danger-full-access`, it states that the DSH file sandbox does not restrict file modifications by available operations.
+
+Tool schemas remain the authority for which operations are available. Tool results remain the authority for operation-specific denials and approved wider retries. Filesystem, one-shot bash, and terminal implementations continue to resolve and enforce the same per-call policy; only the redundant model-facing capability inventory is removed.
+
+This decision partially supersedes the family-registration and composition-conditioned wording in [the current sandbox policy context decision](../feature/2026-07-30-current-sandbox-policy-context.md). That note remains the owner of cache-safe context delivery, durable snapshot materialization, wording evidence, and the separation between guidance and enforcement.
+
+## Alternatives considered
+
+**Keep the registries but reduce their tests.** Rejected because the public methods, retained lifecycle state, six contribution sites, and approximate capability claim would remain. The combinatorial tests reflected the design cost; they did not create it.
+
+**Derive an exact inventory from the tool registry.** Rejected because current policy needs only a truthful conditional statement, while exact availability already appears in the assembled tool schemas and can vary by request scope. Mapping each schema back to an enforcement backend would introduce another derived relation with no current consumer.
+
+**Omit policy context unless a backend advertises enforcement.** Rejected because it recreates the registration problem and makes policy visibility depend on optional contributors. The conditional wording remains truthful even when no applicable operation is available.
+
+## Consequences
+
+The policy service has one owner-derived context path instead of two public registries and their disposal lifecycle. Capability additions and removals no longer churn the runtime-context snapshot, while mode and workspace changes still do. Exact mode wording, canonical roots, switching, resume, service disposal, and no-agent assembly remain covered; family-combination and contribution-lifecycle tests disappear with the behavior they protected.
+
+The model no longer receives a prose list of sandboxed capability families. It receives exact tool schemas plus one standing file-policy statement. If a future product needs a separate capability inventory, it must be derived from the authoritative per-request assembly rather than reconstructed through backend registration side channels.

.agents/notes/implemented/simplification/2026-07-31-capability-neutral-sandbox-policy-context.zh.md

@@ -0,0 +1,35 @@
+# Agent Note: 不依赖具体能力的沙箱策略上下文
+
+Status: implemented
+
+[English](2026-07-31-capability-neutral-sandbox-policy-context.md) | 中文
+
+## 问题
+
+当前策略上下文最初通过受强制执行家族与可升权家族两个独立注册表来映射运行时组合。后端、工具与示例中的六个调用点会贡献 `filesystem`、`bash` 或 `terminal`；策略服务保留 token 集合，以便独立释放各项注册，对两个注册表的内容求交集并排序，在每次生命周期变化时使提示词组装失效，并且需要测试覆盖所有家族组合。
+
+这份清单既不是说明文件策略所必需的，也不能作为模型可见能力的权威依据。后端贡献可能声明某个家族，而该家族面向模型的工具并不存在，或被请求作用域隐藏；工具 schema 已经向模型准确说明哪些操作可用。因此，为了维护一句近似的英文说明，注册表扩大了公开服务与生命周期契约。
+
+## 决策
+
+`dsh-sandbox-policy` 为每个 agent（智能体）会话贡献一项不依赖具体能力的 `sandbox:policy` 上下文。上下文文本只根据 `resolve({ session })` 派生；不存在后端或工具家族注册 API、贡献映射、排序规则，也不会因注册变化而使提示词失效。
+
+该文本将能力声明限定于 DSH 文件沙箱所强制执行的可用操作。在 `read-only` 下，它说明这类操作在常驻模式下无法修改文件，并指示模型正常尝试可用工具，随后遵循该工具返回的任何拒绝与升权引导。在 `workspace-write` 下，它说明规范化的会话工作区，以及带有适用条件的临时区域写入许可。在 `danger-full-access` 下，它说明 DSH 文件沙箱不会限制可用操作修改文件。
+
+哪些操作可用仍以工具 schema 为准。针对具体操作的拒绝以及获批后的更宽松模式重试，仍以工具结果为准。文件系统、一次性 bash 与终端实现继续解析并强制执行相同的逐调用策略；移除的只有面向模型的冗余能力清单。
+
+本决策取代了[当前沙箱策略上下文决策](../feature/2026-07-30-current-sandbox-policy-context.md)中关于家族注册与按组合条件化措辞的部分内容。缓存安全的上下文交付、持久快照具体化、措辞证据，以及引导与强制执行之间的边界，仍以该 Agent Note 为归属文档。
+
+## 曾考虑的替代方案
+
+**保留注册表，但减少对应测试。** 不予采用，因为公开方法、保留的生命周期状态、六个贡献点和近似的能力声明仍会存在。组合测试只是体现了这一设计成本，并非成本的成因。
+
+**从工具注册表派生确切清单。** 不予采用，因为当前策略只需要一句符合事实的条件性声明，而确切的可用情况已经体现在组装后的工具 schema 中，并且可能随请求作用域变化。若再把每个 schema 映射回其强制执行后端，就会引入另一项派生关系，而当前没有消费方需要它。
+
+**仅在后端声明会强制执行时提供策略上下文。** 不予采用，因为这会重现注册问题，并使策略是否可见取决于可选贡献方。即使没有可适用的操作，这段带条件的措辞仍然符合事实。
+
+## 后果
+
+策略服务只有一条由归属方直接派生的上下文路径，无需维护两个公开注册表及其释放生命周期。增加或移除能力不再导致运行时上下文快照反复变化，模式和工作区变化仍会触发快照更新。聚焦测试仍覆盖各模式的确切措辞、规范化根目录、模式切换、恢复、服务释放与无 agent 组装；家族组合与贡献生命周期测试则随其所保护的行为一同删除。
+
+模型不再收到以自然语言列出的沙箱能力家族清单，而是收到确切的工具 schema 与一项常驻文件策略声明。未来若产品需要独立的能力清单，该清单必须从权威的逐请求组装结果中派生，不能通过后端注册这种旁路机制重建。