stadeummwt/dsh-supreme

🛡️ DSH SUPREME

DeepSeek Harness 的治理层

“ECC 赋予你的 harness 广度。Supreme 赋予它良知。”

CI
suite
probes
verdicts
bench
upstream
leaks
schemas
bundle
license
node

安装 · dsh plugin --profile  add github:stadeummwt/dsh-supreme

概览 · 为何选择 Supreme · 安装 · 七个插件 · 证明墙 · 安全性 · v1.3.1 修复 · 基准测试 · 文档 · 常见问题

📊 概览

下表中的每一行均可重新运行——参见证明墙。

| 指标 | 值 |
|---|---|
| 完整测试套件 | 101/101 项 Level-A 检查 · 5/5 次真实加载器启动 · VERDICT COMPLETE |
| v1.3.1 审查探针 | 465/465，跨 7 个验证器 |
| v1.3 E2E 探针 | 184/184（策略 85 · 工作流 82 · 路由 17） |
| 裁决标记 | 14 个绿色（suite · v131:verify · v13:verify · bundle:verify · composition:verify · v12:verify · v3:verify） |
| 策略基准 A/B/C | 补丁后 0 逃逸 · 良性 75/75 · Astra NOT_RUN（如实标注） |
| 路由器延迟 | ≈ 0.02–0.04 ms / 1k 次决策 · RM0 优先 |
| 密钥哨兵泄露 | 每次运行均为 0 |
| 上游补丁 | 0 —— 固定于 d347e703908d，工作树干净 |
| 许可证 | MIT |

🤔 为何选择 Supreme

DSH 的插件生态（已审查 3,421 个目录条目，2026-09）富含单领域工具——这里一个路由器，那里一个记忆存储，别处一个验证器。每个工具只解决治理的一个切片，并要求你信任它的
Supreme 是相反的设计。 它是一个完整的治理技术栈——成本策略、可观测性、路由、验证、记忆策略、工作流限制、安全审计——将证明视为产品特性：本 README 中的每一项声明都对应一条你可以运行的命令，而每一条硬性规则（拒绝路径、成本门控、密钥擦除）都是确定性代码，而非模型判断。

| 常见的 DSH 插件 | DSH Supreme |
|---|---|
| 解决一个领域的问题 | 七个治理领域，一次安装 |
| “相信输出” | 裁决门控——只有当所有检查都通过时才为 COMPLETE |
| 靠感觉验证配置 | 针对真实 zod schema 的配置键卫生扫描（静默剥离陷阱已关闭） |
| Markdown 证据 | 已发布的 JSON Schemas + 仅追加的 JSONL 证据存储 |
| 触碰核心或猴子补丁 | 零上游补丁——固定上游、工作树干净、每次运行都验证 |
| 安全只是 README 里的一段话 | CI 中的六面安全审计（提示词 · 钩子 · MCP · 权限 · 密钥 · 代理文件） |
| 无 ML 依赖 | 同样无 ML——仅确定性计数、glob 和比较。速度是一项特性：路由决策 ≈ 0.02–0.03 ms / 1k 次迭代 |

本仓库的核心规则： bukti sebenar > klaim——真实证据胜过声明。如果这里的某个陈述无法由你重新运行，它会被标记为声明，而非事实。

⚡ 60 秒安装

该仓库本身就是一个 dsh bundle——无需构建步骤（dist/ 已提交）：

dsh plugin --profile  add github:stadeummwt/dsh-supreme

这会以安全的生产默认值挂载全部七个插件：

PAID / TRIAL routes  → DENIED (hard rule, LAB-only override)
UNKNOWN cost class   → DENIED
commands / network   → OFF by default
router candidates    → you add yours in your own patch layer (last write wins)

零思考路径：一条命令搞定一切

完全不想考虑环境、构建或配置文件？内置的 operator CLI（零依赖）会诊断、安装、组合并启动验证你的设置：

node real/supreme.mjs doctor    # what's missing? (prints a fix line per check)
node real/supreme.mjs setup     # EVERYTHING: builds what's missing, runs the real
dsh plugin add, applies the composition,
boot-probes it → "SUPREME READY"
node real/supreme.mjs verify    # full verification ladder, PASS/FAIL per gate
node real/supreme.mjs setup --composition standard   # core|standard|supreme|lab

setup 是幂等的，并且绝不会修改上游检出。它只会在缺失时克隆 + 固定 + 构建固定的 DSH 上游（可通过 --no-upstream-build 跳过）。

v1.3.2 说明（Windows）： 如果较早版本显示
bundle:verify … obs stats 0 或 composition:verify dataDir 失败——
根本原因已找到并修复（存储引擎会创建其父目录
仅使用 POSIX 分隔符检查；在 Windows 上，每次记录写入都会被
静默丢弃）。重新运行 setup（重建 dist/），然后重新运行
验证器——它们现在还会打印完整的写入器统计信息 + 精确诊断，
而不是一个光秃秃的零。

如果你不需要全部七个，只需再多一行即可选择一个组合：

| 片段 | 启用的插件 | 用途 |
|---|---|---|
| core | policy | 任何配置文件的治理底线 |
| standard | policy · observability · memory · verifier | 日常使用 |
| supreme | 全部七个 | 完整技术栈 |
| lab | 全部七个 + LAB 覆盖 | 仅用于实验——绝不用于生产 |

dsh --profile  \
--patch "$DSH_HOME/profiles//node_modules/dsh-supreme/config/compositions/standard.patch.yml"

🧩 七个治理插件

正好七个。范围是冻结的（AGENTS.md）——没有经过验证的阻塞问题，不得扩大范围。

| # | 插件 | 服务 | 它强制执行的内容 |
|---|---|---|---|
| 1 | supreme-policy | supremePolicy | 成本类别 / 风险 / 委托准入。UNKNOWN 成本 ⇒ 拒绝。付费和试用覆盖仅限 LAB。Unicode 污点 + 编码 blob 检测与拒绝。带可见性配置文件和风险门控的 CoT 存在性门控。拒绝规避（deny_retry）防护。能力类别门控。 |
| 2 | supreme-observability | supremeObservability | 基于官方 DSH 事件接缝的仅追加 JSONL 元数据日志。允许列表字段，秘密哨兵擦除，故障开放。 |
| 3 | supreme-benchmark | supremeBenchmark | 可复现的任务/运行/评分 JSONL 证据；为路由器提供输入的按模型聚合；commitHash + irVersion 来源绑定；evidenceBacked 反消极怠工标志。 |
| 4 | supreme-router | supremeRouter | 确定性选择：8 个硬门控 → 加权评分 → RM0 优先成本类别规则 → unscoredEvidenceWeight 反消极怠工降权 → 可选的验证器失败驱动的努力节奏调节。将 CapabilitySignal 标签带入决策。 |
| 5 | supreme-verifier | supremeVerifier | 确定性验证器注册表（精确文本 · 正则 · JSON · 文件 · 命令）。证据 > 模型自信。 |
| 6 | supreme-memory-policy | supremeMemoryPolicy | 记忆选择策略：置信度下限、注入上限、相关性排序、有界仅追加笔记账本（含凭据的笔记在准入时被拒绝）。 |
| 7 | supreme-workflow-policy | supremeWorkflowPolicy | ctx.subagents / ctx.workflowEngine 何时/如何运行：限制、降级阶梯、glob 路径作用域（阻止优先于允许）、针对 HIGH 风险任务的验证器门控关闭、A2A 联系图 + 越权审计。 |

flowchart TB
subgraph SUP["Supreme 插件层 — 项目自有，冻结的 7 个"]
P["supreme-policy"]
O["supreme-observability"]
BM["supreme-benchmark"]
R["supreme-router"]
V["supreme-verifier"]
M["supreme-memory-policy"]
W["supreme-workflow-policy"]
end
subgraph CORE["DSH 核心 — 固定上游 · 永不修改"]
C["ctx.llm · ctx.sessions · ctx.systemPrompt · ctx.tokenMeter · ctx.credentials · ctx.subagents · ctx.workflowEngine"]
end
P --> C
O --> C
BM --> C
R --> C
V --> C
M --> C
W --> C
P -. consults .-> V
P -. consults .-> R
P -. consults .-> W
O -. optional .-> V
O -. optional .-> W
BM -. history .-> R
V -. evidence .-> W

四个支持插件（supreme-minimal-probe、supreme-boot-probe、
supreme-gate-driver、supreme-fake-llm）仅作为该套件的测试夹具存在
——它们永远不会随 bundle 发布。

🏁 证明墙 — 每个判定都可运行

不要相信这个 README。运行这些：

| 命令 | 判定标记 | 它证明了什么 |
|---|---|---|
| bun run suite | COMPLETE | 101/101 个 Level-A 检查 + 5/5 个真实加载器启动 + v1.2/v1.3/v1.3.1 审计门 |
| bun run v131:verify | V131_COST_FIX_VERIFIED · V131_VERIFIER_FIX_VERIFIED · V131_MEMORY_FIX_VERIFIED · V131_A2A_FIX_VERIFIED · V131_EVIDENCE_BINDING_VERIFIED · V131_OUTCOME_ROUTING_VERIFIED · V131_FAILURE_INJECTION_VERIFIED | 审查加固端到端：成本预派发拒绝、符号链接防护根、JSON-schema 严格性、内存隔离、A2A 注册表、证据过期、结果路由、故障注入（465 个探针 — 见 docs/REVIEW-FIXES-v1.3.1.md） |
| bun run v13:verify | V13_POLICY_E2E_COMPLETE · V13_WORKFLOW_E2E_COMPLETE · V13_ROUTING_E2E_COMPLETE | 全部 7 个 v1.3 ASTRA 特性端到端：真实引擎 + 真实固定 cordis 适配器（85 + 82 + 17 个探针） |
| bun run bundle:verify | BUNDLE_E2E_COMPLETE | 真实 dsh plugin add → reconciler → 启动 → 13 个服务 → 用户补丁覆盖胜出 → 干净释放 |
| bun run composition:verify | COMPOSITIONS_E2E_COMPLETE | 全部 4 个片段：服务存在与不存在、相对 dataDir 直写 |
| bun run v12:verify | V12_E2E_COMPLETE | 每个 v1.2 配置键到达其服务 + 功能探针（污点拒绝、努力升级/恢复、路径作用域、关闭门、账本） |
| bun run v3:verify | V3_CONFIG_REVIEW_EVIDENCE | 静默剥离陷阱，实时：错误配置丢失 5/6 个键 → 修正后的配置强制执行 6/6 |

Level A 单元检查      101/101 通过  （策略 17 · 可观测性 7 · 基准 11 · 路由器 23
验证器 11 · 记忆 13 · 工作流 19）
v1.3.1 审查探针     465/465      （成本 37 · 验证器 43 · 记忆 88 · a2a 63 ·
证据 82 · 结果路由 80 · 故障注入 72）
v1.3 E2E 探针          184/184      （策略 85 · 工作流 82 · 路由 17 — 真实引擎，
真实固定版本 cordis 适配器，无需上游构建）
真实加载器启动        5/5 通过     （supreme-minimal、core、standard、supreme、lab）
启动时间             supreme-minimal ~51–60 ms · core/standard/supreme/lab ~830–990 ms
无密钥场景         9/9 门禁通过 （真实 DSH 会话；路由器选择免费路由；PAID 被拒绝）
安全性                哨兵泄漏 = 0 · 付费自动回退 = 已禁用
v1.2/v1.3 审计门禁    配置键卫生 通过 · 固定引用扫描 通过 ·
六面审计 通过（包括固定的 workflow/agent-start 接缝）·
模式契约 通过（3 个模式）
上游完整性       提交未更改 · 工作树干净 · 补丁 = 0
性能              路由器 ≈ 0.02–0.04 ms / 1k · 可观测性序列化 ≈ 0.001–0.007 ms / 1k
结论                  完成

诚实规则： 真实加载器路径（real/boot.mjs）是唯一的
真实集成证据。src/harness/cordis-mini 下的 Level-A 测试装置
是一个生命周期夹具——它绝不被引用为 DSH 证明。

🔐 安全保证

| 保证 | 机制 | 证明 |
|---|---|---|
| 机密绝不通过可观测性泄漏 | 对允许列表字段进行机密哨兵擦除，故障开放写入路径 | 套件：每次运行 sentinelLeaks = 0 |
| 受污染的工具参数无法派发 | Unicode 类别扫描（零宽 / 双向 / BOM / 标签）+ 通过上游 tools/pre-execute 的 taintPolicy: DENY | V12_E2E_COMPLETE 功能探针 |
| 拒绝命令确实会阻止它 | 拒绝规避防护：对已拒绝调用的同形重试被拒绝（deny_retry）——签名携带名称/类型，绝不携带值 | V13_POLICY_E2E_COMPLETE 探针 |
| 隐藏载荷无法搭载在工具参数中 | 编码块扫描（≥256 字符的 base64/hex 连续段），仅类名 + 长度 | V13_POLICY_E2E_COMPLETE 探针 |
| 自我声明的能力标签无法换取权限 | capabilityClassGate ENFORCE/AUDIT；LAB 允许列表受下限约束；标签仅起限制作用 | V13_POLICY_E2E_COMPLETE 探针 |
| 代理间通道保持在声明的图上 | allowedContacts 有向边；图外被审计（a2a_contact），DENY 在事实发生前阻止 | V13_WORKFLOW_E2E_COMPLETE 探针 |
| 委托无法悄悄超出其任务 | 越权审计：风险上限 + 审批门禁 + 路径范围，不含值 | V13_WORKFLOW_E2E_COMPLETE 探针 |
| 基准分数无法欺骗路由器 | evidenceBacked 标志（验证器通过规则）+ 固定的 unscoredEvidenceWeight 降权 | V13_ROUTING_E2E_COMPLETE 探针 |
| 值绝不会在审计事件中被回显 | 污点/接触/越权事件仅携带类名、ID 和级别 | 代码 + 套件检查 |
| 付费模型绝不会意外触发 | UNKNOWN 成本 ⇒ 拒绝；allowPaid 在 LAB 之外被拒绝；无自动回退 | 无密钥场景门禁 9/9 |
| 破坏性委托被限定范围 | blockedPaths > allowedPaths glob 强制执行；DENY_ALL 密钥策略 | 套件检查 15（工作流） |
| 高风险工作无法跳过验证 | requireVerifierPassOnClose 证据门禁 | V12_E2E_COMPLETE 探针 |
| 供应链保持锁定 | 扫描外部引用；上游提交 + irVersion 绑定到运行记录中 | 锁定引用扫描通过 |
| 你自己的审计，离线进行 | 六面审计：提示词 · 钩子 · MCP · 权限 · 密钥 · 代理文件 | 套件检查通过 |

🛡️ v1.3.1 审查加固

对外部 v1.3.0 审查的回应：5 项发现已复现 → 已修复 → 已证明
（每项都在原始代码上有一个失败测试），外加基于结果的路由、
证据绑定验证、快速路径/恢复，以及故障注入
测试框架。完整的逐问题证据——复现命令、根本原因、修复前/
修复后输出、剩余限制，以及回滚步骤（bash + PowerShell）——见
docs/REVIEW-FIXES-v1.3.1.md。

| # | 严重性 | 发现（v1.3.0） | 修复（v1.3.1） |
|---|---|---|---|
| A | P1 | 付费/未知模型的 LLM 请求在无成本检查的情况下被派发 | 在 agent/request 处预派发拒绝 + llm/stream 兜底；拒绝时零适配器调用；生产 RM0 中 UNKNOWN 被拒绝；LAB 例外契约保留 |
| B | P1 | allowedRoots 内的符号链接逃逸了文件哈希验证器 | 在任何读取之前对根和目标进行原生 realpath 验证；遍历/同级前缀/缺失文件被拒绝；竞态减少（并非竞态防护——已记录） |
| C | P1 | latestSelection 在会话/任务之间共享（内存污染） | 选择绑定到（会话，任务）；未知身份 → 空；有界 LRU + 在结束/取消/释放时清理 |
| D | P2 | copy_file {target: b.txt} 被误分类为代理间接触 | 受信任通信工具注册表门控接收方提取；事后发出保持仅检测 |
| E | P2 | JSON Schema additionalProperties:false 被静默忽略（误报通过） | 确定性验证器：不支持的键 → ERROR/UNAVAILABLE，绝不静默降级 |

运行它：bun run v131:verify（7 个标记，465 个探针）——然后在信任此表之前阅读文档。

📈 基准测试 v1.3.1

跨三个标签的策略执行差异——相同的运行器、相同的数据集，
阈值在评估之前冻结，开发集 + 留出集输入不相交：

| 标签 | 设置 | 结果 |
|---|---|---|
| A | 测试框架不含 Supreme | 30 次成本策略绕过 |
| B | Supreme v1.3.0（审查修复前） | 90 次逃逸（成本 30 · 内存 15 · 符号链接 15 · A2A 误拒 15 · schema 误通过 15） |
| C | Supreme v1.3.1 | 0 次逃逸——所有类型 · 良性通过 75/75 · 开销 ≈ 10 ms/组（中位数 93 对 82 ms） |

全部 6 项阈值 PASS。安全回归（良性拒绝）会阻止晋升。

- 方法、限制与清理记录：benchmarks/BENCH-v1.3.1.md
- 先定阈值后评估：benchmarks/THRESHOLDS-v1.3.1.json · 原始运行：benchmarks/runs/
- 自行重跑：bun real/bench-v131.mjs --label C --reps 1 → BENCH_C_THRESHOLDS_PASS
- Astra (GPT-6)：NOT_RUN——没有经过验证的公开评估数据；绝不
伪造（研究笔记）。这是一个
策略执行基准测试，不是模型质量排名。

🧬 v1.3 ASTRA 加固特性

来自 ASTRA-1 待办清单的七项确定性加固特性
（research/gpt6-astra-2026-09.md §7）。
无 ML，无新依赖——每项特性都在无密钥套件中经过引擎检查，并由
bun run v13:verify 端到端验证（真实引擎 + 真实固定 cordis
适配器）。共享标签契约 CapabilitySignal
{ capabilityClass?, cotVisibility? } 由 supreme-policy 导出，并由路由器
携带（从不强制执行）。

supreme-policy——四项特性（配置表）

| 配置键 | 默认值 | 含义 |
|---|---|---|
| cotVisibilityProfiles | {} | routeId → 预期 CoT 可见性。声明为 none 的路由绝不因 cot_missing 拒绝——ENFORCE 降级为仅审计（空 CoT 模型无法被强制产生轨迹）。解析顺序：显式信号 > profile > verbose。 |
| riskGatedCoT | false | ENFORCE 仅适用于 HIGH 风险工具（确定性命令/网络/写入名称分类器）；非 HIGH 工具保持 AUDIT。 |
| denyCircumventionGuard | true | 对已被拒绝调用的同形态重试会以原因码 deny_retry 拒绝。签名仅编码参数名称 + 类型——值永远无法进入其中。首次调用不受影响；resetDenyCircumvention(sessionId) 是逃生通道。 |
| enableEncodingScan | false | 审计/拒绝工具参数中 ≥256 字符的 base64/hex 串（encoding_blob；仅参数名称 + 串长度）。扩展了 v1.2 污点面：同一事件，同一 taintPolicy。 |
| capabilityClassGate | 'OFF' | 对携带 capabilityClass 的请求进行门控：AUDIT 记录，ENFORCE 拒绝未获批准的类别。未标记的请求始终原样通过。 |
| sanctionedCapabilityClasses / labCapabilityClassAllowlist | [] / [] | 批准列表；LAB 允许列表是附加性的，且仅在 LAB 底线上生效。没有隐式 ROUTINE 豁免——自我声明的标签只能限制，绝不能授予。 |

supreme-workflow-policy——两项特性（配置表）
| 配置键 | 默认值 | 含义 |
|---|---|---|
| agentContactPolicy / allowedContacts | 'LOG_ONLY' / [] | A2A 联系图：由 agent id/角色构成的有向 { from, to } 边（空 = 惰性）。图外的 spawn/message 联系会被审计为 a2a_contact；在 'DENY' 下，事前 tools/pre-execute 瀑布会以 a2a_contact_denied 拒绝。Emit 模式接缝为 DETECT-only。 |
| maxRiskLevel / approvalRequiredFor | 'HIGH' / [] | 越权审计：超出风险上限的委托、列出但未带审批标志的任务类别，或 v1.2 范围之外的路径，都会被审计为 overreach_suspected（标签、级别、标志、配置 glob —— 绝不涉及内容）。 |

supreme-router + supreme-benchmark — 反沙袋（配置表）

| 配置键 | 插件 | 默认值 | 含义 |
|---|---|---|---|
| requireEvidenceForScores | benchmark | false | 没有 verifier-PASS 证据的分数声明会在分数 + 运行上被标记为 evidenceBacked: false（仅标记 —— 分数绝不重写；当验证迟到时会重新评估）。 |
| unscoredEvidenceWeight | router | 1 | 对无证据基准声明的固定乘性降权（例如 0.5 会将此类分数减半）；id + 因子记录在决策 + unscored_evidence 事件上（仅 id）。1 = 关闭，向后兼容。 |
| — | router | — | 将候选上的 capabilityClass / cotVisibility 标签携带到选定的 RouteDecision 上（携带者，而非执行者）。 |

组合片段（v1.3 姿态）

| 片段 | v1.3 键 |
|---|---|
| core | denyCircumventionGuard: true 固定（唯一默认开启项）；其他一切继承 OFF 默认值 |
| standard | enableEncodingScan: true + capabilityClassGate: AUDIT —— 仅审计，无法阻止 |
| supreme | 相同的仅审计策略姿态 + requireEvidenceForScores: true + 工作流键固定为保持行为的默认值 |
| lab | 强制执行演示：capabilityClassGate: ENFORCE + labCapabilityClassAllowlist、cotVisibilityProfiles + riskGatedCoT、声明的联系图 + maxRiskLevel: MEDIUM、unscoredEvidenceWeight: 0.5 |

🧬 v1.2 治理功能

确定性。无 ML。无新运行时依赖。每个功能都绑定到真实的固定上游接缝，并附带引擎检查 + 启动级证明
（bun run v12:verify）。

supreme-policy — unicode 污染拒绝 + CoT 存在性门控

上游在记录后冻结工具参数（包装器只能更改
exec.signal），因此可强制执行的宿主侧姿态是通过官方 tools/pre-execute 接缝实现的检测 → 审计 →
拒绝（{ kind: 'deny',
reason } —— 上游物化错误结果；Supreme 绝不伪造
工具输出）：

| 配置键 | 默认值 | 含义 |
|---|---|---|
| enableUnicodeSanitization | true | 扫描工具参数中的零宽 / 双向隔离 / 双向覆盖 / 标签码点（U+200B–200F、U+2060–206F、U+202A–202E、U+FEFF、U+E0000–E007F） |
| logTaintAttempts | true | 记录 taint_detected 事件——仅记录类名，值绝不会被回显 |
| taintPolicy | LOG_ONLY | DENY 会在分发前拒绝该调用 |
| reasoningTracePolicy | OFF | AUDIT 在助手消息未携带推理轨迹时记录 cot_missing；ENFORCE 还会拒绝该会话的工具调用（ENFORCE 在 CORE 底线上被拒绝） |

supreme-router — RM0 优先 + 努力节奏控制

| 配置键 | 默认值 | 含义 |
|---|---|---|
| costFirst | true | 仅对最便宜且符合条件的成本类别评分——FREE_CONFIRMED 胜过历史记录更好但受速率限制的对等项；所有候选者的硬门控证据均被保留 |
| effortPacing.enabled | false | 在固定的 agent/request 接缝上进行确定性的 costClass → reasoningEffort 映射（固定的 DeepSeek 级别：off / low / high / max） |
| effortPacing.escalateOnVerifierFail | true | 仅由验证器 FAIL 证据通过 reportVerifierOutcome() 驱动的一步升级（low → high）——绝不依赖模型自信；PASS 可恢复 |

supreme-workflow-policy — 精准路径范围 + 验证器门控关闭

| 配置键 | 默认值 | 含义 |
|---|---|---|
| allowedPaths / blockedPaths | [] / [] | 用于委托的零依赖 glob 范围（ 跨段，/? 保持在段内）；被阻止的始终优先；空允许列表 = 不受限制 |
| requireVerifierPassOnClose | false | 高风险任务只有在记录了验证器 PASS 证据时才能关闭 |

supreme-memory-policy — 有界账本 + 本能式门控

| 配置键 | 默认值 | 含义 |
|---|---|---|
| ledgerEnabled | false | 可选启用的有界、仅追加 JSONL 笔记账本（ledgerDir、ledgerFileName、ledgerMaxEntries）——包含凭据的笔记在准入时被拒绝 |
| minConfidence | 0.7 | 低于此置信度的笔记绝不会被注入（ECC 本能类比——记录的是证据质量，而非自我评估） |
| maxInjected | 6 | 每次选择的硬上限 |
| relevanceRanking | true | 在优先级之前进行确定性的任务词元重叠排序（计数，而非 ANN） |

supreme-benchmark — 来源绑定 + 已发布模式

运行记录接受 commitHash（40 位十六进制 sha 或 UNAVAILABLE）和 irVersion
——格式错误的值会被验证拒绝，因此路由证据始终绑定
到产生它的代码。

- schemas/suite-report.schema.json ·
benchmark-record.schema.json ·
ledger-note.schema.json — 第三
各方可以验证报告/记录；套件检查可防止 schema 和代码发生漂移。
- 套件还会运行 config-key 卫生检查（每一行随附的 YAML 都会根据插件的真实 zod schema 进行验证——静默剥离陷阱始终关闭）、pinned-ref 扫描，以及 六面安全审计。

📦 作为 dsh bundle 安装

该仓库本身就是 bundle：package.json 声明了 dsh.bundle.patch →
cordis.patch.yml，它会将七个冻结插件作为 profile 行插入。任何 profile 都可以通过官方插件流程采用 Supreme：

from a local checkout…
dsh plugin --profile  add /path/to/dsh-supreme
…or straight from GitHub
dsh plugin --profile  add github:stadeummwt/dsh-supreme

prove an install end-to-end (real CLI install + boot + layering checks)
bun run bundle:verify
prove the v1.2 config surface end-to-end
bun run v12:verify
prove the v1.3 ASTRA-hardening features end-to-end (all three verifiers)
bun run v13:verify

该 bundle 以安全的生产默认值挂载这七个插件（PAID /
TRIAL 被拒绝，commands/network 关闭，零 router 候选）。从你自己的 profile patch
层扩展候选、项目知识和 workflow 限制——composer 会按行 id 应用 last write wins，因此用户配置
始终优先于 bundle 默认值。四个 support/fixture 插件不属于
该 bundle：它们永远不会进入用户 profile。

组合片段随附于
config/compositions/ ——这是 bundle 世界中与 manifest 驱动的安装 profile 相对应的
类似物。每个片段都会按 id 对 bundle 行进行 UPDATE 补丁（整体替换 config，对组合之外的行使用 disabled: true），并且不重复声明 name，因此它保持
与安装位置无关。端到端验证全部四个片段：
bun run composition:verify → COMPOSITIONS_E2E_COMPLETE。

注意：dsh plugin add 要求 PATH 中有 pnpm；从 GitHub 安装无需
prepare 构建即可工作，因为 dist/ 已提交。片段路径相对于 dsh 进程工作目录——可从你自己的 patch 层覆盖任意行。

🏗️ 架构

┌────────────────────────────────────────────────────────────────────┐
│  Next.js dashboard (project app) — PROJECTION only, owns no state  │
│  GET/POST /api/supreme/  (dev/LAB only)                           │
└──────────────────────────────┬─────────────────────────────────────┘
│ reads suite reports / triggers runs
┌──────────────────────────────▼─────────────────────────────────────┐
│  SUPREME PLUGIN LAYER (dsh-supreme/dist/plugins, project-owned)    │
│  policy · observability · benchmark · router · verifier ·          │
│  memory-policy · workflow-policy  (+ 4 support/fixture plugins)    │
│  Cordis conventions: name/inject/Config(Standard Schema)/apply     │
└──────────────────────────────┬─────────────────────────────────────┘
│ 注入：官方 DSH 服务名称
┌──────────────────────────────▼─────────────────────────────────────┐
│  DSH CORE（固定上游——永不修改）                                    │
│  ctx.llm · ctx.sessions · ctx.systemPrompt · ctx.tokenMeter ·      │
│  ctx.credentials · ctx.subagents · ctx.workflowEngine              │
│  事件：session/* · agent/request* · tools/execute ·                │
│          subagent/* · workflow/*                                   │
└────────────────────────────────────────────────────────────────────┘

依赖方向（无环，强制约束）：

DSH 核心服务         →  Supreme 插件          （注入接缝）
supremePolicy        →  verifier、router、workflow-policy
supremeObservability →  router、verifier（可选）、workflow-policy
supremeBenchmark     →  router                 （router 读取历史记录；benchmark 绝不依赖 router）
supremeVerifier      →  workflow-policy        （参考验证证据）

固定上游

| 项目 | 值 |
|---|---|
| 仓库 | https://github.com/deepseek-ai/deepseek-harness |
| 固定提交 | d347e703908d0406b7a7ef80e3a0e594d86b2215（master，标签 dsh-v0.1.3-alpha.1） |
| DSH 版本 | 0.1.3-alpha.1 |
| 内置 Cordis | 4.0.2（vendor/cordis） |
| 上游工作树 | 保持原始状态——UPSTREAM_CORE_MODIFIED = NO，补丁数量 0 |
| 工具链 | Node v24（v24.19.0）、pnpm 11.7.0、Bun 1.3.14（打包器） |

本项目对固定的上游检出目录为只读。它在运行时解析：
DSH_UPSTREAM_ROOT 环境变量覆盖 → 同级目录 ../deepseek-harness →
项目内 node_modules/.upstream/deepseek-harness。优先使用同级目录位置：
某些上游构建（pnpm + 声明生成）会拒绝位于 node_modules 目录下的检出。
所有 Supreme 代码都位于项目自有路径中。

组合（配置文件）

| 配置文件 | 捆绑包 | 挂载的 Supreme 插件 |
|---|---|---|
| supreme-minimal | 无（裸 Loader） | 仅最小探针 |
| core | @deepseek-ai/dsh-base | 最小探针、启动探针、supreme-policy（CORE） |
| standard | @deepseek-ai/dsh-base | + observability、memory-policy、verifier |
| supreme | @deepseek-ai/dsh-base | 全部 7 个 + fake-llm + gate-driver（SUPREME 策略） |
| lab | @deepseek-ai/dsh-base | 全部 7 个 + fake-llm + gate-driver，仅限 LAB 的覆盖（allowPaid: true、allowCommands: true、maxConcurrentAgents: 4） |

完整层级图 + 已验证的真实 API 证据表：
docs/architecture/ARCHITECTURE.md。

🚀 从源码构建与验证

前置条件：Node ≥ 24、pnpm 11.7.0（上游构建）、Bun ≥ 1.3。命令
假定仓库根目录（发布时为 dsh-supreme/；在配套的
Next.js 工作区内，测试套件会自动检测两种布局）。

1. 安装依赖
bun install

2. 克隆固定的 DSH 上游（默认查找位置：同级目录 ../deepseek-harness；
任何位置都可以通过 DSH_UPSTREAM_ROOT 生效——避免将其嵌套在 node_modules 下）
git clone https://github.com/deepseek-ai/deepseek-harness.git ../deepseek-harness
git -C ../deepseek-harness checkout d347e703908d0406b7a7ef80e3a0e594d86b2215

3. 构建锁定版本的上游库——官方 tsconfig 依赖图，内存分批处理
（对 217 个引用的宿主依赖图执行一次 tsc -b 需要约 4 GB 余量；分批
运行器将每次调用控制在 2 GB 以下）
npm run build:upstream

4. 将所有 Supreme 插件打包到 dist/（每个插件一个 ESM 文件；zod 外部化）
PLUGINS="supreme-policy supreme-observability supreme-benchmark supreme-router \
supreme-verifier supreme-memory-policy supreme-workflow-policy \
supreme-minimal-probe supreme-boot-probe supreme-gate-driver supreme-fake-llm"
for p in $PLUGINS; do
bun build src/plugins/$p/index.ts \
--outfile dist/plugins/$p/index.mjs \
--format esm --target node --external zod
done

每个 dist 包仅将 zod 和 Node 内置模块外部化；@deepseek-ai/cordis
仅作为被擦除的类型导入出现。已验证此确切命令能够逐字节复现已提交的
dist/plugins/supreme-policy/index.mjs。

真实启动（唯一的真实集成证据）

通过真实的锁定版本 DSH Loader 启动任意组合，并干净地释放。
--setup 会从 config/ 将 profile 安装到 $DSH_HOME/profiles// 下。
node real/boot.mjs --profile supreme-minimal --setup
node real/boot.mjs --profile core         --setup
node real/boot.mjs --profile standard     --setup
node real/boot.mjs --profile supreme      --setup
node real/boot.mjs --profile lab          --setup

每次运行都会打印一个 JSON 结果（bootMs、disposeMs、services 存在性
映射、gate 结果），并在任何失败时以非零状态退出。Gate 标记会追加到
data/real/ 下——每个 profile 的预期标记请参见运行手册。

套件执行

bun run suite            # 完整套件，包括 5 次真实启动（需要已构建的上游）
bun run suite:json       # 机器可读的 SuiteReport
bun run suite:keyless    # 仅 Level A——无需上游即可运行；判定保持为
PARTIAL（REAL_BOOT_SKIPPED、UPSTREAM_CHECKOUT_UNAVAILABLE）
bun run suite:keyless:ci # 无密钥模式，使用适合 CI 的退出码：当且仅当判定为 PARTIAL
且仅存在已记录的无密钥阻塞项时为 0——任何真实
失败（UNIT/泄漏/卫生/审计/schema）仍会失败

只有当所有强制 gate 都通过（verdict: COMPLETE）时，套件才会以 0 退出。
任何失败都会打印确切的阻塞 gate。

HTTP API（仪表盘投影——仅限 dev/LAB）

Next.js 应用在套件之上暴露了一个轻量、以读取为主的投影。它不拥有
任何运行时状态；运行记录存放在内存存储中（最近 20 次运行），并且
在生产环境中禁用套件执行（NODE_ENV=production 会返回 403，
除非设置 SUPREME_ENABLE_SUITE=1）。
| 端点 | 方法 | 行为 |
|---|---|---|
| /api/supreme/status | GET | 套件范围（冻结的 7 个插件、组合）、上游提交/清洁度、DSH/cordis 版本、运行时信息。始终安全。 |
| /api/supreme/report | GET | 内存中最后一次 SuiteReport；如果尚未运行则返回 404（先执行 POST /api/supreme/suite/run）。 |
| /api/supreme/suite/run | POST | 执行完整套件（包括 5 次真实启动）。仅限 dev/LAB — 在生产环境中未设置 SUPREME_ENABLE_SUITE=1 时返回 403。 |
| /api/supreme/suite/runs/:id | GET | 一条运行记录（runId、startedAt、durationMs、完整报告）；未知 id 返回 404。 |

实现：src/app/api/supreme/* + src/lib/supreme-suite.ts
（项目应用，位于 dsh-supreme/ 之外）。

📤 分发（手动、由所有者驱动）

仓库政策：不代所有者向第三方仓库发起拉取请求。
准备好的提交产物位于
distribution/：

- awesome-dsh-entry.yml — 可直接用于目录的条目（单文件，类别为
security，仅使用符合验证器要求的键）。
- SUBMISSION-GUIDE.md — 在 dsh-market 上上架实际如何运作（它
从 awesome-dsh-plugin 目录自动获取数据）、预检门禁
清单、确切的手动提交命令，以及 npm 发布说明。

GitHub 仓库已经带有 dsh-plugin 主题和一个 dsh.bundle
清单，因此上架唯一剩下的步骤就是所有者选择进行的
手动单文件 PR。

📁 目录布局

dsh-supreme/                      (repo root as published)
├── README.md                  ← this file
├── VISION.md                  ← original v1 project vision (frozen architecture contract)
├── CHANGELOG.md
├── AGENTS.md                  ← engineering rules for future agents
├── SOURCE-OF-TRUTH.md         ← upstream integrity record (historical + current)
├── LICENSE                    ← MIT (v1.2)
├── package.json               # suite/boot/build/verify scripts (zod + yaml deps)
├── assets/                    # README hero/footer SVGs (self-contained, dark + light)
├── schemas/                   # published JSON Schemas (suite report, benchmark, ledger)
├── benchmarks/                # v1.3.1 policy-enforcement benchmark (runner, datasets, thresholds, runs)
├── .github/workflows/ci.yml   # keyless + full suite on push/PR (v1.2)
├── config/
│   ├── supreme-minimal.cordis.yml   # bare-Loader probe gate
│   ├── core.cordis.yml              # CORE composition
│   ├── standard.cordis.yml          # STANDARD composition
│   ├── supreme.cordis.yml           # SUPREME composition (all 7)
│   ├── lab.cordis.yml               # LAB composition (LAB-only overrides)
│   ├── examples/                    # corrected config example (provenance noted)
│   └── compositions/                # 4 overlay fragments (core/standard/supreme/lab)
├── distribution/                    # manual submission artifacts (no auto-PRs)
│   ├── awesome-dsh-entry.yml        # 目录条目草稿（单个文件）
│   └── SUBMISSION-GUIDE.md          # 由所有者驱动的上架操作指南
├── real/
│   ├── supreme.mjs            # 即插即用 CLI：doctor · setup · verify（单条命令）
│   ├── lib/obs-proof.mjs      # 共享的确定性可观测性证明（轮询 + 刷新 + 诊断）
│   ├── boot.mjs               # 真实 DSH 启动测试装置（Loader + 根纤程 dispose）
│   ├── bundle-verify.mjs      # E2E：真实 CLI 安装 + 分层（BUNDLE_E2E_COMPLETE）
│   ├── composition-verify.mjs # E2E：4 个组合片段（COMPOSITIONS_E2E_COMPLETE）
│   ├── v3-config-verify.mjs   # E2E：静默剥离证明（V3_CONFIG_REVIEW_EVIDENCE）
│   ├── v12-config-verify.mjs  # E2E：v1.2 配置表面 + 探针（V12_E2E_COMPLETE）
│   ├── v13-policy-verify.mjs  # E2E：v1.3 策略特性，85 个探针（V13_POLICY_E2E_COMPLETE）
│   ├── v13-workflow-verify.mjs# E2E：v1.3 A2A + 越权，82 个探针（V13_WORKFLOW_E2E_COMPLETE）
│   ├── v13-routing-verify.mjs # E2E：v1.3 标签 + 反放水，17 个探针（V13_ROUTING_E2E_COMPLETE）
│   ├── v131-.mjs             # E2E：7 个评审修复验证器 — cost-enforce · verifier-hardening ·
│   │                          # memory-isolation · a2a-falsepositive · evidence-binding ·
│   │                          # outcome-routing · failure-injection（共 465 个探针）
│   ├── bench-v131.mjs         # 基准测试运行器（--label A|B|C、--reps、--out）
│   └── build-batched.sh       # 内存分批的官方上游构建
├── dist/plugins//index.mjs    # 由真实 Loader 加载的 bun 构建 ESM 包
├── data/
│   ├── observability/observability.jsonl   # 运行时元数据日志
│   ├── benchmark/benchmark.jsonl           # 路由证据存储
│   └── real/.markers.jsonl                # 启动/门控标记（已验证证据）
├── src/
│   ├── plugins/               # 每个插件包含 engine.ts（纯逻辑）+ index.ts（Cordis 适配器）
│   │   ├── supreme-policy/  supreme-observability/  supreme-benchmark/
│   │   ├── supreme-router/  supreme-verifier/  supreme-memory-policy/
│   │   ├── supreme-workflow-policy/
│   │   └── supreme-minimal-probe/  supreme-boot-probe/  supreme-gate-driver/  supreme-fake-llm/
│   ├── suite/                 # runner.ts + cli.ts + engine-checks.ts + config-hygiene.ts
│   │                          # + surface-audit.ts + schema-contract.ts + harness.ts
│   └── harness/cordis-mini/   # 仅 Level-A 生命周期夹具（绝不作为 DSH 证明引用）
├── research/                  # ECC 剖析 + ASTRA-1 + README v2 研究（证据基础）
└── docs/
├── REVIEW-FIXES-v1.3.1.md # v1.3.1 评审加固的逐问题证据
├── architecture/ARCHITECTURE.md
├── decisions/ADR-0000 … ADR-0007
└── runbooks/              # install、build、test、boot-、upgrade-pinned-dsh、rollback

📖 文档地图

| 文档 | 内容 |
|---|---|
| AGENTS.md | 冻结范围、上游规则、Cordis 约定、归属表、验证要求 |
| docs/architecture/ARCHITECTURE.md | 分层图、已验证的真实 API 证据表、事件接缝、组合分层 |
| docs/decisions/ | ADR-0000（fixture 历史）+ ADR-0001…0007（每个重大决策一份） |
| docs/runbooks/ | 安装、构建、测试、启动 core/standard/supreme/lab、升级固定版 dsh、回滚 |
| docs/REVIEW-FIXES-v1.3.1.md | 5 项评审发现：复现、根因、修复、前后对比、限制、回滚 |
| benchmarks/BENCH-v1.3.1.md | 基准测试方法、阈值、结果、清理记录 |
| research/ | ECC 剖析（253,948★）+ ASTRA-1 剖析 + v3 计划评审 + README v2 研究 |
| SOURCE-OF-TRUTH.md | 上游完整性记录（历史 + 当前） |
| 各插件 README | src/plugins//README.md — 用途、配置表、契约、安全边界 |
| CHANGELOG.md | 带每个版本证据标记的版本历史 |

❓ 常见问题

Supreme 会修改 DeepSeek Harness 吗？

不会。固定的上游工作树保持原封不动 — UPSTREAM_CORE_MODIFIED =
NO，补丁数量 0，每次套件运行都会重新验证。Supreme 是一个普通的
Cordis 插件层，消费官方服务和事件接缝。

这里面有 AI 驱动的东西吗？

没有。每个门禁都是确定性代码 — 计数、glob 匹配、字符串
比较、zod 校验。这就是为什么路由器在约 0.02–0.03 ms 内做出决策，也是为什么
结果今天就能在你的机器上复现。

为什么 UNKNOWN 成本会拒绝该模型？

因为未分类的路由就是未经审计的支出路径。supreme-policy
将其视为硬性 DENY；付费/试用类别需要显式的仅限 LAB 的
覆盖。RM0 优先路由随后会确定性地优先选择 FREE_CONFIRMED 候选。

我可以只用 policy 插件吗？

可以 — 那就是 core 片段。或者
standard 用于日常驱动的
四个。片段是你自己配置文件上的一行式覆盖层。

如果我的配置有拼写错误或未知键怎么办？

v1.2 套件运行 config-key 卫生扫描：每一行随附的 YAML 都会
根据插件的真实 zod schema 进行校验，因此“启动通过但你的
治理键被静默剥离”的陷阱（在
V3_CONFIG_REVIEW_EVIDENCE 中已实机证实）始终关闭。

它能在离线 / 气隙环境中工作吗？

六面审计、污点扫描、账本以及所有套件检查都完全
离线且确定性。真实启动需要在本地检出已固定的上游版本——运行时无网络调用。

为什么 Supreme 尚未被列入 dsh-market？

列入需要向目录提交一个单文件 PR，而本仓库的政策是此类 PR 由所有者手动发起（参见
distribution/SUBMISSION-GUIDE.md）。
其他一切均已准备就绪。

📜 诚实的局限性

- 通过 real/boot.mjs 的真实加载器路径是唯一的真实集成证据；Level-A 生命周期测试装置（src/harness/cordis-mini）只是一个夹具，绝不会被引作 DSH 证明。
- 在未构建已固定上游的情况下，无密钥套件的判定诚实地为 PARTIAL（REAL_BOOT_SKIPPED）——它不会伪造完整性。
- 基准测试衡量的是策略执行（绕过/逃逸次数），而非模型质量或智能；Astra 标签在设计上为 NOT_RUN，直到存在经过验证的公开数据为止。
- 延期事项（已记录，并未遗忘）：HNSW 风格的内存索引和 Archify 风格的 schema 迁移不在冻结的七项范围之内。
- 路由器候选默认为空（默认零）：你从自己的补丁层添加模型。Supreme 管理选择；它不预选提供商。

以证据为先构建。Bukti sebenar > klaim.

如果 Supreme 强化了你的测试装置，请考虑为仓库加星——这能帮助其他 DSH 用户发现治理工具。

⬆ 返回顶部