Coder/deepseek-harness
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor(mode): drop the per-mode tool allowlist — enforce where an enforcer exists

Browse Source 
A ModeDefinition is now exactly { section, access? }; unknown keys (a
tools list included) fail loud at load. What plan mode still does: the
guidance section, the exit_plan_mode visibility rule (plan only, both
soft surfaces), the access cap's bash/resolve-mode clamp, and the two
cap-derived pre-execute guards (the bash trio is withheld when no
confining executor can honor the cap; sandbox escalation is denied
while it holds). The general deny-by-default gate and the assemble
allowlist filter are gone: which tools a mode admits is an effects
question, and a hand-maintained name list mislabels it — it must track
every composed tool and rots silently as tools arrive. The dimension
returns as a consumer of effects self-declaration on tool definitions
(MCP ToolAnnotations as the template) — rationale and restart trigger
archived in the RFC's Alternatives/Deferred; the interim guidance-only
non-shell restraint is priced in Consequences.

Exiting plan is now a pure removal (the exit tool + section), which the
delta encoding CAN express: the re-recorded plan-mode fixture pins one
plan-shaped initial header snapshot plus one header-delta instead of
two snapshots.
This commit is contained in:
kingwl
2026-07-12 23:20:36 +08:00
parent 99650a201b
commit 1fe2f99580
20 changed files with 1995 additions and 1529 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/config-catalog.md
View File

@@ -457,15 +457,14 @@ export interface ModeConfig {
}
/**
* One mode's deployment-configured policy: the guidance section the model sees,
* the allowlist of tool names that stay visible and executable, and an
* optional cap on the sandbox access shell commands run under.
* One mode's deployment-configured policy: the guidance section the model sees
* and an optional cap on the sandbox access shell commands run under. There
* is deliberately no tool allow/deny list — which tools a mode admits is an
* effects question, parked until tool definitions declare their effects.
*/
export interface ModeDefinition {
/** Guidance text rendered as the `mode:policy` prompt section while the mode is in force. */
section: string
/** Allowlist of tool NAMES; names may reference not-yet-registered tools (registration is dynamic). */
tools: string[]
/**
* The widest sandbox access shell commands may run under while this mode is
* in force — a per-call CAP on the bash seam's resolved mode (a
@@ -479,7 +478,7 @@ export interface ModeDefinition {
}
```
Source: [`packages/mode/mode/src/index.ts:115`](../packages/mode/mode/src/index.ts)
Source: [`packages/mode/mode/src/index.ts:118`](../packages/mode/mode/src/index.ts)
## `@deepseek-ai/dsh-repeat-tool-guard`