Skip to content

Capacity & dependency exceptions

The release gate requires measured behavior against a real SurrealDB history and zero unresolved critical/high dependency advisories. Neither an in-memory benchmark nor an unrecorded “not reachable” judgment is release evidence.

Use a disposable database on the same SurrealDB version and storage class intended for deployment. Never point the harness at a retained or production database: it creates an organization plus the requested number of memories, signals, and circles.

Terminal window
export SURREAL_ENDPOINT=ws://127.0.0.1:8000/rpc
export SURREAL_USER=root
export SURREAL_PASS_FILE=/run/secrets/surreal_password
export SURREAL_PASS="$(cat "$SURREAL_PASS_FILE")"
export SURREAL_IMAGE=surrealdb/surrealdb:v3.2.4
bun run bench:capacity -- \
--rows 1000 \
--iterations 10 \
--concurrency 25 \
--row-bytes 2048 \
--database s21_capacity_$(date -u +%Y%m%dT%H%M%SZ)

The default result uses a collision-safe path such as .gsd/milestones/M001/slices/S21/S21-CAPACITY-RESULT-<uuid>.json; pass --output to select an explicit evidence path. It contains the exact history cardinalities, p50/p95/p99 latency, final response bytes, storage query count and fingerprints, heap delta, adapter/connection topology, queue depths, Surreal EXPLAIN FULL output, runtime versions, source revision, and pass/fail reasons. It contains no credentials or query bindings.

The command exits nonzero when any fixed budget is exceeded:

Budget Default gate
Each history at least --rows
Endpoint p95 2,500 ms
Final JSON response 1,048,576 bytes
Storage queries per request 32
Per-request heap delta 64 MiB
Adapter connections 1
Embedding queue depth 0
Pending webhook outbox 0

Treat a query-count increase as a likely N+1 regression even when latency still passes. Compare the fingerprints and plans with the last accepted artifact. A table scan over a large filtered history needs either an index justified by the captured plan or a written reason and a tighter cardinality bound. Do not raise a threshold merely to make a shared runner green; rerun on an idle host first and record why the workload or deployment SLO changed.

After review, archive the JSON with the image ID, source-file digest manifest, Surreal image digest, and test logs. Remove the disposable benchmark database using an authenticated Surreal operator session only after the artifact is safely archived.

CI installs from the frozen Bun lock and the hash-locked Hermes Python environment, then runs both ecosystem scanners. Reproduce the exact commands from .github/workflows/ci.yml; do not audit an unrelated global environment.

Terminal window
bun install --frozen-lockfile
bun audit
# In the clean, hash-locked Hermes verification environment:
python -m pip check
python -m pip_audit --progress-spinner off --format json --output hermes-pip-audit.json

Regenerate a lock only as part of a reviewed dependency upgrade. A scanner outage, unparseable report, skipped package, or unlocked install is a failed gate, not “zero advisories.” Archive the scanner versions and raw machine-readable reports.

Critical/high advisories block release unless a time-bounded exception is explicitly approved. Store one record per advisory with all of the following:

  • advisory identifier, affected and resolved versions, package, ecosystem, and lock digest;
  • named owner and approving security reviewer;
  • concrete reachability evidence from the shipped artifact: import/call path, enabled feature and configuration, input trust boundary, and a reproducer or negative test;
  • affected images, CLIs, plugins, build jobs, and deployment profiles;
  • compensating controls and monitoring, with a test showing each control is active;
  • upgrade/removal plan, tracking issue, review date, and expiry no later than 30 days.

“We do not use it” is not reachability evidence. Build-only dependencies still require a supply-chain analysis; optional/runtime packages require proof against the actual packaged artifact and enabled configuration. If evidence is incomplete, treat the advisory as reachable.

At expiry, on a severity increase, or when the dependency/configuration changes, the exception automatically lapses and the release gate closes. Remove the exception once the fixed lock passes both scanners; retain the old record in the audit archive rather than rewriting its history.