🛡️ DSH SUPREME

The governance layer for DeepSeek Harness

"ECC gives your harness breadth. Supreme gives it a conscience."

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

At a glance · Why Supreme · Install · The seven plugins · Proof wall · Security · v1.3.1 fixes · Benchmarks · Docs · FAQ

📊 At a glance

Every row below is re-runnable — see the proof wall.

🤔 Why Supreme

DSH's plugin ecosystem (3,421 catalog entries reviewed, 2026-09) is rich in
single-domain tools — a router here, a memory store there, a verifier
somewhere else. Each solves one slice of governance and asks you to trust its
output.

Supreme is the opposite design. It is a full governance stack — cost
policy, observability, routing, verification, memory policy, workflow limits,
security audit — that treats proof as a product feature: every claim in
this README maps to a command you can run, and every hard rule (deny paths,
cost gates, secret scrubbing) is deterministic code, not model judgment.

> The core rule of this repo: bukti sebenar > klaim — real evidence over
> claims. If a statement here can't be re-run by you, it's marked as a claim,
> not a fact.

⚡ 60-second install

The repository is a dsh bundle — no build
step needed (dist/ is committed):

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

That mounts all seven plugins with safe production defaults:

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)

Zero-thought path: one command does everything

Don't want to think about environments, builds, or profiles at all? The
built-in operator CLI (zero dependencies) diagnoses, installs, composes and
boot-proves your setup:

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 is idempotent and never modifies the upstream checkout. It will
clone + pin + build the pinned DSH upstream only if it is missing (skip with
--no-upstream-build).

> v1.3.2 note (Windows): if an earlier version showed
> bundle:verify … obs stats 0 or a composition:verify dataDir failure —
> root cause found and fixed (store engines created their parent directory
> with a POSIX-only separator check; on Windows every record write was
> silently dropped). Re-run setup (rebuilds dist/), then re-run the
> verifiers — they now also print full writer stats + an exact diagnosis
> instead of a bare zero.

Pick a composition in one more line if you don't need all seven:

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

🧩 The seven governance plugins

Exactly seven. The scope is frozen (AGENTS.md) — no scope
creep without a proven blocker.

flowchart TB
subgraph SUP["Supreme plugin layer — project-owned, frozen 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 core — pinned upstream · never modified"]
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

Four support plugins (supreme-minimal-probe, supreme-boot-probe,
supreme-gate-driver, supreme-fake-llm) exist only as test fixtures for
the suite — they never ship in the bundle.

🏁 Proof wall — every verdict runnable

Don't trust this README. Run these:

Level A unit checks      101/101 PASS  (policy 17 · observability 7 · benchmark 11 · router 23
verifier 11 · memory 13 · workflow 19)
v1.3.1 review probes     465/465      (cost 37 · verifier 43 · memory 88 · a2a 63 ·
evidence 82 · outcome-routing 80 · failure-injection 72)
v1.3 E2E probes          184/184      (policy 85 · workflow 82 · routing 17 — real engines,
real pinned-cordis adapters, no upstream build needed)
Real-loader boots        5/5 PASS     (supreme-minimal, core, standard, supreme, lab)
boot times             supreme-minimal ~51–60 ms · core/standard/supreme/lab ~830–990 ms
Keyless scenario         9/9 gates PASS (real DSH session; router picks free route; PAID rejected)
Security                 sentinel leaks = 0 · paid automatic fallback = DISABLED
v1.2/v1.3 audit gates    config-key hygiene PASS · pinned-ref scan PASS ·
six-surface audit PASS (incl. the pinned `workflow/agent-start` seam) ·
schema contract PASS (3 schemas)
Upstream integrity       commit unchanged · worktree clean · patches = 0
Performance              router ≈ 0.02–0.04 ms / 1k · observability serialize ≈ 0.001–0.007 ms / 1k
VERDICT                  COMPLETE

Honesty rule: the real-loader path (real/boot.mjs) is the only
real-integration evidence. The Level-A harness under src/harness/cordis-mini
is a lifecycle fixture — it is never cited as DSH proof.

🔐 Security guarantees

🛡️ v1.3.1 review-hardening

Response to an external v1.3.0 review: 5 findings reproduced → fixed → proven
(each with a failing test on the original code), plus outcome-based routing,
evidence-bound verification, fast path/recovery, and a failure-injection
harness. Full per-issue evidence — reproduction commands, root causes, before/
after outputs, remaining limits, and rollback steps (bash + PowerShell) — lives
in docs/REVIEW-FIXES-v1.3.1.md.

Run it: bun run v131:verify (7 markers, 465 probes) — then read the doc before trusting this table.

📈 Benchmarks v1.3.1

Policy-enforcement delta across three labels — same runner, same datasets,
thresholds frozen before evaluation, dev + held-out inputs disjoint:

All 6 thresholds PASS. Safety regressions (benign denials) block promotion.

• Method, limits and cleanup record: benchmarks/BENCH-v1.3.1.md
• Thresholds-then-evaluate: benchmarks/THRESHOLDS-v1.3.1.json · raw runs: benchmarks/runs/
• Re-run yourself: bun real/bench-v131.mjs --label C --reps 1 → BENCH_C_THRESHOLDS_PASS
• Astra (GPT-6): NOT_RUN — no verified public evaluation data; never
  fabricated (research note). This is a
  policy-enforcement benchmark, not a model-quality ranking.

🧬 v1.3 ASTRA-hardening features

Seven deterministic hardening features from the ASTRA-1 backlog
(research/gpt6-astra-2026-09.md §7).
No ML, no new deps — every feature is engine-checked in the keyless suite and
proven end-to-end by bun run v13:verify (real engines + real pinned-cordis
adapters). The shared label contract CapabilitySignal { capabilityClass?, cotVisibility? } is exported by supreme-policy and
carried (never enforced) by the router.

supreme-policy — four features (config table)

supreme-workflow-policy — two features (config table)

supreme-router + supreme-benchmark — anti-sandbagging (config table)

Composition fragments (v1.3 posture)

🧬 v1.2 governance features

Deterministic. No ML. No new runtime deps. Every feature binds to a real
pinned upstream seam and ships with engine checks + boot-level proof
(bun run v12:verify).

supreme-policy — unicode taint denial + CoT presence gate

Upstream freezes tool arguments after logging (wrappers may change only
exec.signal), so the enforceable host-side posture is detect → audit →
deny through the official tools/pre-execute seam ({ kind: 'deny', reason } — upstream materializes the error result; Supreme never fabricates
tool output):

supreme-router — RM0-first + effort pacing

supreme-workflow-policy — surgical path scope + verifier-gated close

supreme-memory-policy — bounded ledger + instinct-style gates

supreme-benchmark — provenance binding + published schemas

Run records accept commitHash (40-hex sha or UNAVAILABLE) and irVersion
— malformed values are rejected by validation, so routing evidence stays bound
to the code that produced it.

• schemas/suite-report.schema.json ·
  benchmark-record.schema.json ·
  ledger-note.schema.json — third
  parties can validate reports/records; a suite check keeps schemas and code
  from drifting.
• Suite also runs config-key hygiene (every shipped YAML row validated
  against the plugin's real zod schema — the silent-strip trap stays closed),
  pinned-ref scan, and the six-surface security audit.

📦 Install as a dsh bundle

The repository IS the bundle: package.json declares dsh.bundle.patch →
cordis.patch.yml, which inserts the seven frozen
plugins as profile rows. Any profile can adopt Supreme through the official
plugin flow:

# 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

The bundle mounts the seven plugins with safe production defaults (PAID /
TRIAL denied, commands/network off, zero router candidates). Extend
candidates, project knowledge, and workflow limits from YOUR profile patch
layer — the composer applies last write wins per row id, so user config
always beats bundle defaults. The four support/fixture plugins are NOT part of
the bundle: they never ship into user profiles.

Composition fragments ship under
config/compositions/ — the bundle-world analogue
of manifest-driven install profiles. Each fragment UPDATE-patches the bundle
rows by id (whole-config replacement, disabled: true for rows outside the
composition) and carries no name restatement, so it stays
install-location-independent. Prove all four end-to-end:
bun run composition:verify → COMPOSITIONS_E2E_COMPLETE.

Notes: dsh plugin add requires pnpm on PATH; installing from GitHub works
without a prepare build because dist/ is committed. Fragment paths are
relative to the dsh process working directory — override any row from your
own patch layer.

🏗️ Architecture

┌────────────────────────────────────────────────────────────────────┐
│  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     │
└──────────────────────────────┬─────────────────────────────────────┘
│ inject: official DSH service names
┌──────────────────────────────▼─────────────────────────────────────┐
│  DSH CORE (pinned upstream — never modified)                       │
│  ctx.llm · ctx.sessions · ctx.systemPrompt · ctx.tokenMeter ·      │
│  ctx.credentials · ctx.subagents · ctx.workflowEngine              │
│  Events: session/* · agent/request* · tools/execute ·              │
│          subagent/* · workflow/*                                   │
└────────────────────────────────────────────────────────────────────┘

Dependency direction (acyclic, enforced):

DSH core services    →  Supreme plugins        (injected seams)
supremePolicy        →  verifier, router, workflow-policy
supremeObservability →  router, verifier (optional), workflow-policy
supremeBenchmark     →  router                 (router reads history; benchmark NEVER depends on router)
supremeVerifier      →  workflow-policy        (verification evidence consulted)

Pinned upstream

The pinned upstream checkout is read-only for this project. It is resolved
at runtime: DSH_UPSTREAM_ROOT env override → sibling ../deepseek-harness →
in-project node_modules/.upstream/deepseek-harness. Prefer the sibling
location: some upstream builds (pnpm + declaration emit) reject checkouts
nested under a node_modules directory. All Supreme code lives in
project-owned paths.

Compositions (profiles)

Full layer map + verified real-API evidence table:
docs/architecture/ARCHITECTURE.md.

🚀 Build & verify from source

Prerequisites: Node ≥ 24, pnpm 11.7.0 (upstream build), Bun ≥ 1.3. Commands
assume the repo root (dsh-supreme/ as published; inside the companion
Next.js workspace the suite auto-detects both layouts).

# 1. Install dependencies
bun install

# 2. Clone the pinned DSH upstream (default lookup: sibling ../deepseek-harness;
#    any location works via DSH_UPSTREAM_ROOT — avoid nesting it under node_modules)
git clone https://github.com/deepseek-ai/deepseek-harness.git ../deepseek-harness
git -C ../deepseek-harness checkout d347e703908d0406b7a7ef80e3a0e594d86b2215

# 3. Build the pinned upstream libraries — official tsconfig graph, memory-batched
#    (one tsc -b over the 217-ref host graph needs ~4 GB headroom; the batched
#    runner keeps each invocation under 2 GB)
npm run build:upstream

# 4. Bundle every Supreme plugin to dist/ (one ESM file per plugin; zod external)
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

Each dist bundle externalizes only zod and Node builtins; @deepseek-ai/cordis
appears solely as erased type imports. This exact command was verified to
reproduce the committed dist/plugins/supreme-policy/index.mjs byte-for-byte.

Real boot (the only real-integration evidence)

# Boot any composition through the REAL pinned DSH Loader and dispose cleanly.
# --setup installs the profile under $DSH_HOME/profiles// from config/.
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

Each run prints one JSON result (bootMs, disposeMs, services presence
map, gate results) and exits non-zero on any failure. Gate markers are
appended under data/real/ — see the runbooks for
expected markers per profile.

Suite execution

bun run suite            # full suite incl. 5 real boots (needs the built upstream)
bun run suite:json       # machine-readable SuiteReport
bun run suite:keyless    # Level A only — runs without the upstream; verdict stays
# PARTIAL (REAL_BOOT_SKIPPED, UPSTREAM_CHECKOUT_UNAVAILABLE)
bun run suite:keyless:ci # keyless with CI-friendly exit code: 0 iff verdict is PARTIAL
# with only the documented keyless blockers — any real
# failure (UNIT/leaks/hygiene/audit/schema) still fails

The suite exits 0 only when every mandatory gate passes (verdict: COMPLETE). Any failure prints the exact blocking gates.

HTTP API (dashboard projection — dev/LAB only)

The Next.js app exposes a thin, read-mostly projection over the suite. It owns
no runtime state; runs live in an in-memory store (latest 20 runs) and
suite execution is disabled in production (NODE_ENV=production returns 403
unless SUPREME_ENABLE_SUITE=1).

Implementation: src/app/api/supreme/** + src/lib/supreme-suite.ts
(project app, outside dsh-supreme/).

📤 Distribution (manual, owner-driven)

Repo policy: no pull requests are opened on third-party repositories on the
owner's behalf. Prepared submission artifacts live in
distribution/:

• awesome-dsh-entry.yml — catalog-ready entry (single file, category
  security, validator-conformant keys only).
• SUBMISSION-GUIDE.md — how listing on dsh-market actually works (it
  auto-feeds from the awesome-dsh-plugin catalog), the pre-flight gate
  checklist, the exact manual submission commands, and the npm-publish note.

The GitHub repo already carries the dsh-plugin topic and a dsh.bundle
manifest, so the only remaining step for listing is the manual one-file PR the
owner chooses to make.

📁 Directory layout

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        # catalog entry draft (one file)
│   └── SUBMISSION-GUIDE.md          # owner-driven listing walkthrough
├── real/
│   ├── supreme.mjs            # PLUG-AND-PLAY CLI: doctor · setup · verify (one command)
│   ├── lib/obs-proof.mjs      # shared deterministic observability proof (poll + flush + diagnosis)
│   ├── boot.mjs               # REAL DSH boot harness (Loader + root-fiber dispose)
│   ├── bundle-verify.mjs      # E2E: real CLI install + layering (BUNDLE_E2E_COMPLETE)
│   ├── composition-verify.mjs # E2E: 4 composition fragments (COMPOSITIONS_E2E_COMPLETE)
│   ├── v3-config-verify.mjs   # E2E: silent-strip proof (V3_CONFIG_REVIEW_EVIDENCE)
│   ├── v12-config-verify.mjs  # E2E: v1.2 config surface + probes (V12_E2E_COMPLETE)
│   ├── v13-policy-verify.mjs  # E2E: v1.3 policy features, 85 probes (V13_POLICY_E2E_COMPLETE)
│   ├── v13-workflow-verify.mjs# E2E: v1.3 A2A + overreach, 82 probes (V13_WORKFLOW_E2E_COMPLETE)
│   ├── v13-routing-verify.mjs # E2E: v1.3 labels + anti-sandbagging, 17 probes (V13_ROUTING_E2E_COMPLETE)
│   ├── v131-*.mjs             # E2E: 7 review-fix verifiers — cost-enforce · verifier-hardening ·
│   │                          # memory-isolation · a2a-falsepositive · evidence-binding ·
│   │                          # outcome-routing · failure-injection (465 probes total)
│   ├── bench-v131.mjs         # benchmark runner (--label A|B|C, --reps, --out)
│   └── build-batched.sh       # memory-batched official upstream build
├── dist/plugins//index.mjs    # bun-built ESM bundles loaded by the real Loader
├── data/
│   ├── observability/observability.jsonl   # runtime metadata log
│   ├── benchmark/benchmark.jsonl           # routing evidence store
│   └── real/*.markers.jsonl                # boot/gate markers (verified evidence)
├── src/
│   ├── plugins/               # engine.ts (pure logic) + index.ts (Cordis adapter) per plugin
│   │   ├── 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 lifecycle FIXTURE only (never cited as DSH proof)
├── research/                  # ECC dissection + ASTRA-1 + README v2 research (evidence base)
└── docs/
├── REVIEW-FIXES-v1.3.1.md # per-issue evidence for the v1.3.1 review hardening
├── architecture/ARCHITECTURE.md
├── decisions/ADR-0000 … ADR-0007
└── runbooks/              # install, build, test, boot-*, upgrade-pinned-dsh, rollback

📖 Documentation map

❓ FAQ

Does Supreme modify DeepSeek Harness?

No. The pinned upstream worktree stays pristine — UPSTREAM_CORE_MODIFIED = NO, patch count 0, re-verified on every suite run. Supreme is an ordinary
Cordis plugin layer that consumes official services and event seams.

Is any of this AI-powered?

None. Every gate is deterministic code — counting, glob matching, string
comparison, zod validation. That's why the router decides in ~0.02–0.03 ms and why
results are reproducible on your machine, today.

Why does UNKNOWN cost deny the model?

Because an unclassified route is an unaudited spend path. supreme-policy
treats it as a hard DENY; paid/trial classes require an explicit LAB-only
override. RM0-first routing then prefers FREE_CONFIRMED candidates
deterministically.

Can I use just the policy plugin?

Yes — that's the core fragment. Or
standard for the daily-driver
four. Fragments are one-line overlays on your own profile.

What if my config has a typo or an unknown key?

The v1.2 suite runs a config-key hygiene scan: every shipped YAML row is
validated against the plugin's real zod schema, so the "boot passes but your
governance keys were silently stripped" trap (proven live in
V3_CONFIG_REVIEW_EVIDENCE) stays closed.

Does it work offline / air-gapped?

The six-surface audit, taint scanning, ledger and all suite checks are fully
offline and deterministic. Real boots need the pinned upstream checked out
locally — no network calls at runtime.

Why isn't Supreme listed in the dsh-market yet?

Listing requires a one-file PR to the catalog, and this repo's policy is that
such PRs are made by the owner, manually (see
distribution/SUBMISSION-GUIDE.md).
Everything else is already prepared.

📜 Honest limitations

• The real-loader path via real/boot.mjs is the only real-integration
  evidence; the Level-A lifecycle harness (src/harness/cordis-mini) is a
  fixture and is never cited as DSH proof.
• Keyless suite verdict is honestly PARTIAL (REAL_BOOT_SKIPPED) without a
  built pinned upstream — it does not fake completeness.
• The benchmark measures policy enforcement (bypass/escape counts), not
  model quality or intelligence; the Astra label is NOT_RUN by design until
  verified public data exists.
• Deferred items (documented, not forgotten): HNSW-style memory indexing and
  Archify-style schema migration stay out of scope for the frozen seven.
• Router candidates ship empty (zero-by-default): you add models from your own
  patch layer. Supreme governs choices; it does not preselect providers.

Built proof-first. Bukti sebenar > klaim.

If Supreme hardened your harness, consider starring the repo — it helps other DSH users find governance tooling.

⬆ back to top