quality-release

Think Through Quality & Release Readiness

Overview

Production guidance for verification. Each reference paper captures the gap between "tests pass" and "production-safe": races that only appear under real isolation, failures that only appear when dependencies die, load targets with no workload model, and releases that never walked the cross-cutting checklist.

Core principle: Evidence, not assertion. Every quality or performance claim needs a test, measurement, or drill that would have failed if the claim were false — including the failure paths users and operators will actually hit. A plan is not executed evidence, and a waiver does not change what the evidence says.

Domain Law

NO 'DONE' CLAIM WITHOUT:
1. the minimum required primary paper(s) for the verification type selected from the context table;
2. a named workload, failure, or interleaving the tests must force;
3. the pre-release checklist walked for the changed surface;
4. every claim assigned an evidence state and bound to the exact subject tested;
5. every touched sibling-skill boundary and exception closed under the
   Release Decision Gate below — never silently waived.

When to Use

Use this skill when:

• planning tests for a backend feature and choosing the test pyramid shape;
• building test data that respects constraints, tenancy, and privacy;
• writing concurrency tests that force real interleavings with barriers;
• designing failure tests: crashes between steps, dependency outages, malformed inputs;
• defining load/performance tests with realistic targets, sustained soak, and burst;
• investigating or preventing performance regressions;
• validating scaling behavior and limit assumptions;
• checking resource management: pools, file descriptors, memory, cleanup;
• evaluating compression trade-offs for payloads and storage;
• walking the cross-cutting pre-release checklist;
• reviewing a release exception, waiver, risk acceptance, or "ship anyway" request;
• reviewing whether a change is actually production-ready.