🛡️ DSH SUPREME

📊 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 <your-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 <your-profile> \
  --patch "$DSH_HOME/profiles/<your-profile>/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.

🧬 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).

📦 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 <your-profile> add /path/to/dsh-supreme
# …or straight from GitHub
dsh plugin --profile <your-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/<name>/ 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.

📤 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.

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/<name>/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

📜 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.