Skip to content
bitzorcas
中EN

Concept

ADR 0002: Production readiness gates

Manifest-driven production readiness — the legacy module ratchet, adapter readiness guard, Docker contract matrix, template upgrade map, and operations runtime surface.

Last updated

Status

Accepted.

Context

After extension intake was productized, pre-release risk still depended on human judgment — legacy allowlists, default adapters, Docker contract coverage, template upgrade flow, and ops visibility. Checklists drift when modules, ports, jobs, or template structure change.

Decision

Make production readiness manifest-driven and machine-reviewable. Each runtime surface maps to a governance manifest or gate that fails closed when stale: the legacy module allowlist (0001-module-governance-legacy-ledger.json, a ratchet that can only shrink), the default-adapter production risk ledger (0002-production-adapter-readiness.json, enforced by ProductionAdapterReadinessGuard), Docker contract tests (tagged Category=Docker, run in a two-stage CI matrix), the template upgrade map (0004-template-upgrade-map.json), and the operations runtime surface (0003-operations-runtime-surface.json).

A ProductionBlocker adapter may not run in Production/Staging — it must explicitly fail closed or disable the feature. One-time phase/RC/GA acceptance reports are not the long-term source of truth; that returns to manifests, runbooks, and architecture tests.

Consequences

Adding a module, adapter, Docker contract, template version, or runtime surface requires syncing the relevant manifest and adding tests so the gate fails closed. API Shell and local slices keep fast feedback; the Docker matrix offers optional strong verification. Changing gate semantics requires an ADR revision; merely adding manifest entries does not.

See also

100%

Scroll or use controls to zoom · drag when enlarged · double-click for 100% / 200%