Release Standard

Requirement A use case with unfinished behavior MUST keep its record in draft.

Rationale Draft status prevents incomplete code from claiming released behavior.

Requirement A completed journey MUST connect verified use cases to one observable outcome through a deployed public boundary.

Rationale A passing journey test proves the connected product path.

Requirement A release change MUST run every check selected by its changed backend, frontend, journey, product, domain, API, and extension boundaries.

Rationale Each boundary adds evidence that a narrow test category cannot replace.

Requirement A backend change MUST pass the release build and the backend test suites.

Rationale The release build compiles the solution in release mode. The backend suites are the architecture, integration, and acceptance suites the size requires.

Requirement A frontend change MUST run frozen installation, lint, type checking, tests, and production build checks.

Rationale The frontend requires dependency, static, behavior, and production compilation evidence.

Requirement A journey change MUST run its journey tests.

Rationale Journey changes need evidence through their deployed public boundary.

Requirement A product, domain, or API change MUST pass the reference consumer validator.

Rationale litespec consumer checks metadata, links, and cross-file references.

Requirement A selected project or applicable local extension MUST run its stated verification when affected.

Rationale Extension boundaries add tests and operating evidence beyond the baseline release checks.

Requirement A source change MUST regenerate OpenAPI and frontend API types when it changes their source contract.

Rationale Committed derived contracts remain aligned with the source that defines them.

Requirement A generated application contract MUST be stable and exclude timestamps, machine paths, and nondeterministic ordering.

Rationale Deterministic output makes contract changes reviewable and repeatable.

Requirement A release MUST include only verified use cases and passing deployed journey evidence for its included journeys.

Rationale A use case is verified when every one of its Cases is proved by a passing test. Release evidence proves the included product outcome through its deployed public boundary.

Requirement A release with restricted access MUST provide authentication and authorization.

Rationale Restricted behavior requires a trusted identity and resource-access decision.

Requirement A release MUST provide repeatable schema creation or upgrade, backup instructions, and a tested restore.

Rationale A deployed product needs reproducible data setup and recovery evidence.

Requirement A release MUST provide liveness, readiness, trace-correlated diagnostics, and secrets outside source control.

Rationale Operators need health and diagnostic evidence without exposing secret material.

Requirement A release MUST provide CI, tested deployment and rollback paths, current operating limits, and the runbooks those limits name.

Rationale Repeatable delivery and operation need current execution and recovery records.

Requirement A release MUST create one release record for its immutable artifact.

Rationale The release record connects evidence to the exact deployed artifact.

Requirement A release MUST settle every open decision and external claim it depends on, or exclude the affected behavior from every owning record.

Rationale A declared reduced boundary is valid only when product and release records agree.

Requirement A completion report MUST name exact commands, outcomes, evidence scope, skipped checks, generated differences, scope limits, and covered use cases.

Rationale Reviewers can distinguish completed evidence from unrun or irrelevant checks.

Requirement A release record MUST name source commit and immutable artifact reference.

Rationale These identifiers bind recorded evidence to one reviewed release output.

Requirement A release record MUST list included journeys, use cases, and selected applicable extensions.

Rationale The record defines the behavior boundary for the immutable artifact.

Requirement A release record MUST list build, test, contract, security, journey, schema, backup, deployment, readiness, diagnostics, smoke-test, and rollback results.

Rationale The complete evidence set makes the release supportable by its maintainer.

Requirement A release record MUST list operating limits, alerts, runbooks, known operating conditions, and skipped checks.

Rationale Operating context identifies residual boundaries after release.

Requirement A release record MUST NOT restate a specification or copy a Case.

Rationale Specifications remain the canonical authority for behavior and Cases.

Requirement Accepted debt MUST live as a Known gap with an owner and an end date.

Rationale The gap names its check, which reports until the end date and fails after it. The model page states the Known gap shape.

Requirement A consumer before its first production release MUST keep a readiness record with dated rehearsals, green gates, and a rehearsal owner.

Rationale A release record binds evidence to one artifact, so it has nothing to say before the first artifact exists. The readiness record instead states what proves the product may take data. The rehearsal owner owns the backup and restore rehearsal.

Requirement A release record MUST state its complete behavior and evidence without depending on an earlier release record.

Rationale A reader judges one release from one record. No upgrade guide or earlier record fills a gap in it.