fix: harden release artifact checks and fixture isolation

docs/release-safety.md

@@ -1,10 +1,11 @@
 # Release and rollout safety (T01)
 
 This repository uses Gitea Actions for CI. The workflow in `.gitea/workflows/ci.yml`
-only installs the frozen lockfile, runs local tests/check/build, compiles the
-checked-in synthetic reference fixture, and runs an isolated demo web smoke.
-It does not receive deployment credentials, trigger a remote deployment, or
-write a persistent Convex backend.
+installs the frozen lockfile, runs local tests/check/build, compiles the
+checked-in synthetic reference fixture, runs an isolated demo web smoke, and
+prepares a separate Docker/Compose artifact job. It does not receive
+deployment credentials, trigger a remote deployment, or write a persistent
+Convex backend.
 
 ## Server-side rollout gate
 
@@ -45,10 +46,13 @@ closed until they have reviewed enqueue and worker entry points.
 non-secret `x-application-release` response header. Local/fixture runs use
 `local` or `fixture`. Staging and production must provide a non-placeholder
 identifier (normally the source commit or an operator-approved image digest).
-`bun run release:check` rejects placeholder staging/production identifiers,
-unpinned staging/production dashboard images, demo mode in staging/production,
-invalid capability names, and tracked secret-like files. The Dockerfile accepts
-`--build-arg APP_RELEASE_ID=...`; Compose passes the runtime value explicitly.
+`bun run release:check` requires an explicit `RELEASE_ENV` for live runs and
+rejects placeholder staging/production identifiers, unpinned staging/production
+backend/dashboard images or Dockerfile bases, demo mode in staging/production,
+invalid capability names, tracked secret-like files, and managed secret names
+in built browser artifacts. The Dockerfile uses digest-pinned Bun bases and
+accepts `--build-arg APP_RELEASE_ID=...`; Compose passes the runtime value
+explicitly.
 
 ## Isolated local validation
 
@@ -76,8 +80,9 @@ persistent deployment.
 ## Evidence boundaries
 
 Read-only `tea` inspection on 2026-09-19 reported no Gitea workflows or runs
-for `jb/eden`; runner labels and action availability are therefore not
-validated. The workflow is prepared locally but has not run remotely.
+for `jb/eden`; runner labels, Docker availability, and action availability are
+therefore not validated. The workflow is prepared locally but has not run
+remotely.
 No browser automation, OAuth callback failure injection, Convex migration
 rollback, instance-credential backup/restore, key rotation, or live
 revocation/transfer evidence is claimed by this lane. Those remain explicit

docs/roadmap.md

@@ -103,7 +103,7 @@ Keep valuation methods distinct. Never quietly replace an average price with an
 - Add isolated CI for tests/typecheck/build, deployed-artifact checks, migrations and browser flows.
 - Add durable browser regression coverage for native POST forms, OAuth redirect/cookie paths, singleton/array scopes, linking, logout and pending-request resume. Use synthetic providers/users only in isolated test deployments, never the persistent live backend.
 - Version application images; keep backwards-compatible migrations and an explicit rollback procedure.
-- Define and implement server-side rollout gating; it does not exist today. A deployment configuration/capability allowlist may suffice initially, but the mechanism needs approval and tests. Gates must protect routes, assistant dispatch, jobs and subscriptions—not merely hide UI controls.
+- Define and implement server-side rollout gating. T01 provides an approved deployment configuration/capability allowlist with tests; it protects current routes, assistant dispatch, sync entry points and subscriptions. Durable jobs and any new capability still require their own reviewed entry points. Gates must protect server behavior, not merely hide UI controls.
 
 **M0.2 — Dataset capabilities and incremental consent**
 - Extend the model/gate/store contracts for dataset-specific scopes and freshness.
@@ -357,4 +357,4 @@ After the foundations, work items 4–6 (inventory) and 7 (wallet balances) can
 - Unit/property tests for arithmetic and invariants; isolated integration, native-browser and adversarial tenant tests for changed boundaries.
 - Bounded resource use, safe errors, appropriate logs/metrics, retention/deletion behavior and rollback.
 - No real-user write smoke against the persistent deployment; consented live validation is recorded separately from mocks.
-- The server-side rollout/config gate implemented in M0 remains closed to other users until the slice's acceptance gate is met. It is a planned mechanism, not an existing feature. Public signup remains a separate, explicit operator decision.
+- The server-side rollout/config gate implemented in T01 remains closed to other users until the slice's acceptance gate is met. It is an operator-controlled mechanism, not a public-signup decision. Public signup remains separate and explicitly gated.