Close 7 of 9 pre-launch teardown findings: hash-chain the Mode B audit log, make the licence enforceable, restore the readiness gate

[thecelestialmismatch]

Summary

An adversarial pre-launch teardown found nine defects. Seven are fixed here. Every one still open is a founder dashboard action with no code involved.

The headline: the product sells "a SHA-256 tamper-evident audit trail, generated from a 14-day run in your own environment", and Mode B could not produce one. proxy/storage.ts created proxy_events with no hash column, no previous-hash column and no signature. The only createHash("sha256") in the entire proxy tree hashed the licence key. The chain lived exclusively in lib/audit/seed-anchor.ts and Supabase migrations 029/030 — inside the Vercel plane CLAUDE.md itself declares not CUI-safe.

So the tamper-evidence sat in the one place a CUI customer is told not to send CUI, and the deployment the claim actually covers produced a flat table anyone with the volume mounted could edit with sqlite3. An SSP artifact generated from that table is inadmissible — which is what blocks the RPO/MSP co-sell in Phase 5 of the calendar.

Closes #

What was fixed

#	Finding	Resolution
1	/demo reported every CUI and PHI finding at 2× and published "90" patterns on a page whose header reads 53	One registry; guard holds the line on arrays, scan output and source text
2	Mode B had no hash chain — the claim had nothing behind it	SHA-256(prev_hash ‖ canonical(event)), GET /v1/audit/verify, 14 tests that tamper for real
3	Licence unenforceable by construction — license.valid computed and discarded; any network failure minted plan:"pro"; /api/license/validate never existed	Enforced; Ed25519-signed offline licence for Mode C; endpoint built
4	Compose bound 0.0.0.0:8080 — a plaintext CUI endpoint on the customer's LAN	127.0.0.1:8080:8080, reverse-proxy path documented
5	/v1/stats and /v1/baselines unauthenticated while every sibling route was guarded	Admin token required, compared constant-time
6	Image shipped a C toolchain, the dev tree and compiled tests	Multi-stage; dependency tree 47 MB vs 139 MB
7	Daily pre-flight returned green under every failure it detects	Token-gated /api/health/ready; public probe untouched
8	Sample PDF dated to the last deploy	Origin-rendered, CDN-cached daily
9	SECURITY.md disclosure link was a 404	Absolute; 47 root relative links, 0 broken

The licence bypass could not simply be deleted. license.ts returned {valid:true, plan:"pro"} on any network failure — one line in /etc/hosts was an unlimited Pro licence — but that branch was air-gapped Mode C's only licensing path, and its own test file said so while naming the successor it was waiting for. Deleting it would have traded a monetization leak for a broken deployment mode. So the capability is replaced: HOUNDSHIELD_OFFLINE_LICENSE carries an Ed25519-signed entitlement verified locally with no network, bound to the licence key's hash so it is inert to anyone who does not also hold that key, with a mandatory expiry. scripts/issue-offline-license.mjs issues one; round-tripped against the compiled proxy. Offline operation is now granted rather than achieved by unplugging a cable.

The health endpoint was a documentation bug, not a code bug. CLAUDE.md's pre-flight says /api/health reports degraded state; the route returns {status:"ok"} unconditionally and health-liveness-contract.test.ts locks it that way deliberately. Both positions are right. The public probe is untouched; the capability lives in a new token-gated route that 404s an anonymous caller, a wrong token and an unset token identically, so it is never an oracle. This also re-homes lib/health/service-status.ts — a complete, tested readiness module written for exactly this and orphaned when the route was narrowed, whose only remaining consumer was its own test file.

Change type

• Bug fix
• New capability
• Security hardening
• Documentation or developer-experience improvement
• Refactor or maintenance
• Breaking change

Impact and operating considerations

• Authentication, sessions, identity, or authorization
• Sensitive-data handling, logging, telemetry, or outbound requests
• Proxy detection, policy evaluation, block/quarantine behavior, or performance
• Database schema, migrations, retention, or access controls
• Deployment, environment variables, integrations, or scheduled work
• Evidence, reporting, or audit-chain behavior

Operational impact, threat-model note, and rollback plan:

Detection behaviour is unchanged. Every pattern that fired before still fires; only the duplicate evaluation is gone. Counts fall from 2 to 1 — asserted in both directions.

One behaviour change operators must know about. A proxy with a licence key set that cannot verify it now returns 402 instead of serving. Previously it served with a self-minted Pro licence. Air-gapped installs need HOUNDSHIELD_OFFLINE_LICENSE + HOUNDSHIELD_LICENSE_PUBLIC_KEY; the 402 body names both. Deliberately unchanged: with no licence key configured the proxy still runs — that is the free demo and the evaluation path, and hard-gating the MIT proxy is a pricing decision, not a security fix. It is now named (source: "evaluation") rather than indistinguishable from paid Pro.

Existing databases upgrade in place. Chain columns are added by ALTER TABLE and left nullable. Pre-chain rows are reported UNVERIFIABLE, never as tampered — retro-hashing records whose integrity was never protected would be manufacturing evidence, which is the precise failure this change exists to prevent.

New environment variables, all optional, all fail-closed when unset: HOUNDSHIELD_ADMIN_TOKEN (falls back to the licence key as before, now warned about and reported by /health), HOUNDSHIELD_OFFLINE_LICENSE, HOUNDSHIELD_LICENSE_PUBLIC_KEY, HEALTH_DIAGNOSTIC_TOKEN (unset ⇒ /api/health/ready 404s).

Rollback: every commit reverts independently. No migration, nothing to sequence.

Validation

• Web plane: npx tsc --noEmit
• Web plane: npm run lint
• Web plane: npm run test:coverage
• Web plane: npm run build
• Proxy: npm run lint
• Proxy: npm run test:coverage
• Proxy: npm run bench
• Manual verification (below)
• Documentation-only validation (links, commands, and claims checked)

Results and manual verification:

tsc --noEmit          exit 0
eslint                0 errors, 35 warnings (pre-existing, none in changed files)
test:coverage         224 files, 3116/3116 passed  (was 223 / 3099)
build                 succeeded; /api/reports/sample now ƒ Dynamic, was ○ Static
proxy lint            exit 0
proxy test:coverage   6 files, 120/120 passed      (was 92)
                      stmts 74.33% branches 62.62% lines 75.63%
                      (was 70.54 / 59.14 / 71.81)
proxy bench           p99 0.705 ms over 2000 cold scans (budget 10 ms) — PASS
verify-no-leaks       --self-test PASS, scan PASS
verify-structure      PASS
root markdown links   47 relative, 0 broken
dependency tree       47 MB prod-only vs 139 MB full  (du -sh, measured)

Every guard was proved to discriminate, the way verify-no-leaks --self-test does:

• Pattern registry — reintroduce either call site → the source guard names the file and the counts go expected 2 to be 1. That is the bug reproduced as a number: one CAGE code in the demo script's own prompt, counted twice.
• Audit chain — the suite doesn't verify data it just wrote. It runs UPDATE (turn a BLOCKED CUI event into ALLOWED), DELETE, a forged insert with an invented digest, and a backdated timestamp, asserting each produces the specific verdict — BROKEN_ROW for an in-place edit, BROKEN_LINK for a deletion.
• Offline licence — 14 tests, mostly rejections: wrong signing key, payload edited after signing, token lifted from another customer, expired, non-date expiry, no public key, unreadable public key, malformed, non-JSON payload.
• Readiness route — anonymous, wrong token, unset token, blank token, a prefix of the real token and a superstring of it, plus assertions that the failure body names neither the header nor the variable nor any service key.
• Pricing dormancy — added an import, watched the guard fail by filename, removed it.

Offline licence round-tripped end to end against the compiled proxy, not just unit tests: issue-offline-license.mjs --new-keypair → issue → validateLicense() returns {valid:true, org_id:"org_rt", plan:"enterprise", source:"offline-token"}, and the same token against a different licence key returns valid:false.

Two things could not be verified here, and neither is claimed:

• No Docker daemon in this environment, so no image-size figure is asserted — only the measured 139 MB → 47 MB dependency tree, which is the dominant term. CI builds the image on every proxy PR.
• Live HTTP probing of houndshield.com is refused by the audit environment (403 to CONNECT). No claim in the teardown asserts a live response code.

Review checklist

• The change is focused and does not include unrelated refactoring.
• Tests cover changed behavior, or the omission is explained above.
• No credentials, customer data, sensitive prompts, or production exports were added.
• Public claims are scoped, evidence-based, and consistent with the selected deployment boundary.
• Documentation and configuration guidance were updated where needed.
• Database migrations, configuration changes, and rollout dependencies are documented where applicable.
• I performed a self-review and addressed obvious failure paths.

Two corrections to the teardown itself

Both retracted in the document, visibly, rather than quietly softened — a finding that changes shape without saying so is one no reader can audit.

1. "Nothing has deployed since ⛔ BLOCKED ON A DASHBOARD SETTING — delete the repo-root vercel.json so middleware executes #288." The Vercel API disproved it: dpl_5aN5WbocU36ow… is target: production, state: READY, commit b88b7ee. What the API surfaced instead is worse and was invisible from the repo — three production deployments failed their type check inside one 25-minute window (bfcbe54, 9c9f2b9, ba8bf29), the last ending on TS2339 backupCodes and two pdfjs v6 errors. main took three merges whose build had not passed.

2. "Two contradictory pricing grids ship." They do not. PRICING_PLANS is dormant Stage-2 data with no non-test importer. The risk is latent, not live — and the dormancy was hand-verified in a comment, which is exactly how the 90-vs-53 double count survived its own deletion. It is an assertion now.

What is left — all founder, all dashboard, none of it code

In revenue order, filed in tasks/todo.md:

1. STRIPE_WEBHOOK_SECRET — still unset, so a completed $499 purchase records no order, sends no receipt and raises no alert. One variable, no dependencies, highest value on the system.
2. Open the Payment Link in a browser and confirm it is live at $499 — buy.stripe.com is egress-blocked from every automated environment, so no test can ever check it, and a dead link voids everything else.
3. Apply 035/036/037, then 034 before MARKETING_POSTAL_ADDRESS.
4. HEALTH_DIAGNOSTIC_TOKEN in Vercel — until set, /api/health/ready 404s by design.
5. Branch protection requiring the CI type check — the one setting that would have stopped all three failed production builds.
6. ENCRYPTION_KEY = openssl rand -hex 32 (revives quarantine) and TURNSTILE_SECRET_KEY (makes CAPTCHA escalation real).

Two founder decisions are filed rather than taken: reconciling plans.ts against CLAUDE.md's Stage 2 grid, and whether the MIT proxy should be hard-gated. Deciding either in code would set pricing by side effect — the same reasoning that left the 20%-vs-40% partner ruling alone.

proxy/.env.example is not updated: it is permission-blocked in this environment. Every new variable is documented in docker-compose.yml and README.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_011UNmNvaCuGcZz418MoTyB5

[supabase]

This pull request has been ignored for the connected project qifynzuyrdxmxlumpsrq because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
compliance-firewall-agent	Ready	Preview	Sep 2, 2026 8:28am UTC

[thecelestialmismatch]

CI record: npm audit (prod deps) (compliance-firewall-agent) failed on b430ff6, and is green on 22a53f0.

Not this PR's failure. git diff --stat HEAD~2 -- package.json package-lock.json was empty — the two commits before the fix touch three source files and documentation, no dependency. The check is red on the base branch: it fails on browserslist <=4.28.6 for two advisories, GHSA-c83g-rgw3-j3cx (unbounded memory growth, no cache eviction, eventual OOM) and GHSA-73wf-gq98-2v4g (uncaught crash / prototype write via untrusted browserslist-stats.json custom stats). It also failed on unrelated Dependabot PRs on 2026-09-01, so every PR opened since inherits the red.

Ported rather than waited on. #325 hit the identical failure and reached the identical remediation, and waiting for another PR to merge is still waiting. Applied here as npm audit fix --package-lock-only --omit=dev — lockfile only, 4.28.6 → 4.28.8, a patch bump inside the range the tree already resolves. It no-ops once the base branch carries the same change.

Reproduced before, verified after:

before   npm audit --omit=dev  ->  1 high severity vulnerability
after    npm audit --omit=dev  ->  found 0 vulnerabilities

Re-validated against the new lockfile rather than the stale node_modules: npm ci (861 packages, browserslist resolving to 4.28.8), npx tsc --noEmit clean, npm run lint 0 errors, npm run test:coverage 223 files / 3099 tests passing with the coverage gate met, npm run build succeeded.

No re-run was spent — the fix was pushed instead, and the check went green on its own next run. npm audit (prod deps) (proxy) was cancelled by the failing sibling job on the old head and is also green now.

---

Generated by Claude Code