fix: harden release artifact checks and fixture isolation

This commit is contained in:
jb
2026-09-19 10:01:23 -04:00
parent 99436225f6
commit 197e6a3a70
7 changed files with 108 additions and 20 deletions
+2 -2
View File
@@ -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.