universal-dev-standards 5.5.0 → 5.6.0

package/bundled/core/flow-based-testing.md

@@ -1,7 +1,7 @@
 # Flow-Based Testing
 
-**Version**: 1.0.0
-**Last Updated**: 2026-05-04
+**Version**: 1.3.0
+**Last Updated**: 2026-05-05
 **Applicability**: All software projects with multi-step workflows
 **Scope**: universal
 **Industry Standards**: ISO/IEC/IEEE 29119-4 (Test Techniques), ISTQB Foundation Syllabus
@@ -118,6 +118,139 @@ describe("Flow Branch: Quota exceeded path", () => {
 
 ---
 
+## Multi-Gate Flow Verification Model
+
+Flow coverage is not a single pre-release check — it is a **progressive verification chain** across the entire SDLC. There are two fundamentally different questions that must be answered at different stages:
+
+| Verification Type | Question | Executor | Timing |
+|------------------|----------|----------|--------|
+| **Coverage** | Are all terminal states tested? | Automated CI | Dev → Staging → Pre-UAT |
+| **Correctness** | Are the terminal state definitions right? | Human UAT | UAT phase |
+
+Confusing the two wastes UAT cycles on technical coverage issues that CI should have caught.
+
+### Gate 0 — PRD Sign-off (Before Implementation Starts)
+
+The three testability elements MUST be written into the PRD before a single line of code is written. Use `templates/requirement-template.md` §2.4 and §9.4:
+
+| Element | PRD Section | When Required |
+|---------|-------------|---------------|
+| Preconditions + Ordered Steps | §2.4 | Flows with ≥ 3 steps |
+| Decision Points list | §2.4 | Every branch condition |
+| Terminal States list | §2.4 | All distinct end states |
+| Decision Table (Each-Choice) | §9.4 | All flows |
+| Upgrade to All-Combinations | §9.4 | Auth / payment / security |
+| UAT acceptance script (pre-filled) | §9.4 | Before PRD approval |
+
+> **Why at PRD stage?** Test engineers cannot derive branch coverage from a spec that only describes the happy path. Discovering missing decision points during test design wastes a full sprint.
+
+### Gate 1 — PR Merge (Per Feature Branch)
+
+Every PR that touches a flow with ≥ 3 steps MUST include automated tests covering the terminal states introduced or modified by that PR. Reviewers block merge if terminal states are added to §2.4 without corresponding tests.
+
+### Gate 3 — Pre-UAT Deployment (Automated + QA Lead Sign-off)
+
+CI must prove coverage completeness **before** UAT begins. UAT is for correctness validation, not technical testing.
+
+Required CI checks:
+- All Decision Table scenarios have a passing automated test
+- Zero terminal states without test coverage
+- Branch coverage ≥ 90% (or project-defined threshold)
+- All-Combinations fully passing for auth / payment / security flows
+
+> Deploying to UAT without Gate 3 forces business stakeholders to act as technical QA — a costly and demoralizing misuse of UAT time.
+
+### Gate 4 — UAT Sign-off (Business Correctness, Pre-Production)
+
+UAT validates that terminal state **definitions are correct** against real business rules, not that they are covered. Use the UAT Acceptance Script in §9.4 (derived directly from the Decision Table — no separate script creation needed):
+
+- Business stakeholders sign off each row (terminal state)
+- If UAT reveals a previously undefined terminal state: add it to §2.4 + Decision Table + automated test, re-run Gate 3, then resume UAT
+- No new terminal states discovered during UAT = strong signal that §2.4 was thorough
+
+### Gate Model Summary
+
+```
+PRD Sign-off
+    │ Gate 0: §2.4 + §9.4 complete (Decision Points, Terminal States,
+    │         Decision Table, UAT script pre-filled)
+    ▼
+Implementation + PR Reviews
+    │ Gate 1: Each PR covering a flow includes terminal state tests
+    ▼
+Staging / Integration
+    │ (no formal gate — CI green is sufficient)
+    ▼
+Pre-UAT Deployment
+    │ Gate 3: CI proves 100% terminal state coverage + branch coverage ≥ 90%
+    ▼
+UAT Execution
+    │ Gate 4: Business sign-off on terminal state correctness
+    │         New terminal states → back to Gate 3 before proceeding
+    ▼
+Production
+```
+
+---
+
+## RQM Integration
+
+Gate 3 (Pre-UAT CI coverage gate) MUST produce a **`flow_gate_report.json`** artifact consumed by the Release Quality Manifest (`release-quality-manifest.md`, field `flow_gate_report`).
+
+### flow_gate_report.json Schema
+
+```json
+{
+  "generated_at": "2026-05-05T04:00:00Z",
+  "commit": "abc1234",
+  "flows": [
+    {
+      "flow_id": "login-authentication",
+      "spec_ref": "docs/specs/SPEC-001.md#2.4",
+      "decision_points": 3,
+      "terminal_states": 7,
+      "gate_0_complete": true,
+      "gate_1_pr_coverage": true,
+      "gate_3": {
+        "all_scenarios_green": true,
+        "terminal_states_covered": 7,
+        "terminal_states_defined": 7,
+        "branch_coverage_pct": 94,
+        "coverage_target": 90,
+        "all_combinations_required": false,
+        "status": "pass"
+      },
+      "gate_4_uat_signoff": true
+    }
+  ],
+  "summary": {
+    "total_flows": 5,
+    "gate_0_complete": true,
+    "gate_1_pr_coverage": true,
+    "gate_3_ci_pass": true,
+    "gate_4_uat_signoff": true,
+    "status": "pass"
+  }
+}
+```
+
+### Generation Script Hook
+
+Add to CI after test run (Gate 3):
+
+```bash
+# scripts/generate-flow-gate-report.sh
+node scripts/generate-flow-gate-report.mjs \
+  --coverage-report coverage/coverage-summary.json \
+  --flow-specs "docs/specs/**/*.md" \
+  --uat-signoffs ".release-readiness/*.md" \
+  --output flow_gate_report.json
+```
+
+The `summary.status` field feeds into `release-quality-manifest.yaml` under `flow_gate_report.status`.
+
+---
+
 ## Quick Reference Checklist
 
 ```

package/bundled/core/full-coverage-testing.md

@@ -0,0 +1,183 @@
+# Full Coverage Testing Standards
+
+> **AI-optimized version**: `ai/standards/full-coverage-testing.ai.yaml`
+> **XSPEC**: XSPEC-178
+> **Replaces**: Pyramid threshold model (UT≥80%, IT≥70%, E2E happy-path-only)
+
+## Overview
+
+Full Coverage Testing is a behavior-completeness paradigm designed for the AI-era, where the cost of generating tests equals the cost of generating code. Traditional pyramid thresholds assumed tests were expensive to write — this assumption no longer holds.
+
+**Core principle**: Every public function must be tested for all three behavioral paths. Coverage is measured by behavior completeness, not percentage floors. CI enforces a ratchet: coverage can only increase, never decrease.
+
+---
+
+## Behavior-Completeness Model
+
+Instead of "80% line coverage", require:
+
+| Path | Description | Example |
+|------|-------------|---------|
+| **Happy path** | Normal input produces correct output | `calculateDiscount(100, 0.1) → 90` |
+| **Edge case** | Boundary values do not cause unexpected errors | `calculateDiscount(0, 1.0) → 0 without throwing` |
+| **Error path** | Invalid input raises clear error or error state | `calculateDiscount(-1, 2.0) → throws ArgumentError` |
+
+Every public function requires all three. This replaces the "80% of business logic" target with a qualitative, behavior-driven requirement.
+
+---
+
+## Ratchet CI Policy
+
+- The current coverage baseline is the minimum acceptable coverage
+- Any PR that decreases coverage is blocked from merging
+- Improvements update the baseline automatically on merge
+- No fixed percentage floor — the coverage achieved today is tomorrow's floor
+
+```bash
+# Stored in .coverage-baseline.json
+{ "line": 91.3, "branch": 88.7, "timestamp": "2026-05-06" }
+
+# PR regression → blocked
+Coverage regression: 91.3% → 89.1%. Ratchet threshold violated.
+
+# PR improvement → baseline updated
+Coverage improved: 91.3% → 92.0%. New baseline set.
+```
+
+---
+
+## Anti-Fake Test Rules
+
+### Forbidden: Tautology Assertions
+
+Assertions that always pass regardless of behavior provide false coverage.
+
+```typescript
+// ❌ FORBIDDEN — always passes, tests nothing
+expect(true).toBe(true)
+expect(result).toBeDefined()  // without specific value
+
+// ✅ REQUIRED — verifies actual behavior
+expect(result).toBe(90)
+expect(result).toEqual({ discount: 10, total: 90 })
+```
+
+### Forbidden: Mocking Core Business Logic
+
+Mocking your own code means the business logic is never actually executed.
+
+```typescript
+// ❌ FORBIDDEN — business logic never runs
+jest.mock('./orderService', () => ({ calculateTotal: jest.fn(() => 100) }))
+
+// ✅ ALLOWED — mock only external dependencies
+// MOCK: External Stripe API — no sandbox available in CI
+jest.mock('./payment-gateway', () => ({ charge: jest.fn().mockResolvedValue({ id: 'ch_test' }) }))
+```
+
+### Required: Mock Reason Comments
+
+Every mock must explain why the dependency cannot be real.
+
+```typescript
+// ❌ FORBIDDEN — no explanation
+jest.mock('./payment-gateway')
+
+// ✅ REQUIRED — explicit reason
+// MOCK: External payment gateway — network dependency, no sandbox in CI
+jest.mock('./payment-gateway', () => ({ ... }))
+```
+
+### Mock Boundary: What Can Be Mocked
+
+| ✅ Allowed to Mock | ❌ Forbidden to Mock |
+|-------------------|---------------------|
+| External HTTP APIs (payment, OAuth) | Core business calculation functions |
+| Hardware interfaces (sensors, GPIO) | Your own service layer methods |
+| Third-party SDKs without test mode | Database queries (use in-memory SQLite) |
+| Docker daemon | Your own utility functions |
+
+---
+
+## STUB Marker Protocol
+
+All temporary/placeholder implementations MUST be marked with the standard STUB marker. This is enforced by pre-push hooks and deploy.sh.
+
+### Marking a STUB
+
+```typescript
+// WARNING: STUB — Remove before UAT
+async function validatePayment(card: Card): Promise<boolean> {
+  return true; // Always approve — replace with real Stripe call
+}
+```
+
+### Exempting a Genuine Limitation
+
+When a dependency truly cannot be tested (hardware, live API without sandbox):
+
+```typescript
+// COVERAGE_EXEMPT: Hardware temperature sensor — no simulation available in CI
+async function readTemperature(): Promise<number> {
+  return hardwareSensor.read();
+}
+```
+
+The exemption reason MUST be non-empty and specific.
+
+### Deployment Gates
+
+| Environment | STUB Present | Action |
+|-------------|-------------|--------|
+| Feature branch push | Yes | ⚠️ Warning (not blocked) |
+| `main` branch push | Yes | ❌ Blocked |
+| Staging deploy | Yes | ⚠️ Warning (not blocked) |
+| UAT deploy | Yes | ❌ Blocked |
+| Production deploy | Yes | ❌ Blocked (critical log) |
+
+---
+
+## AC Traceability
+
+Link each test to its Acceptance Criteria using the `@ac` JSDoc tag:
+
+```typescript
+/**
+ * @ac AC-US03-2
+ */
+it('should block PR when coverage regresses below baseline', () => {
+  // test body
+})
+
+// If no AC maps to this test:
+/**
+ * @ac UNTRACED
+ */
+it('helper utility returns correct format', () => { ... })
+```
+
+CI reports AC coverage rate. If more than 20% of ACs lack `@ac`-tagged tests, a warning is shown.
+
+---
+
+## Migration from Pyramid Model
+
+If your project previously used pyramid thresholds:
+
+1. **Delete** any hardcoded coverage thresholds from `jest.config.js` / `vitest.config.ts` (`coverageThreshold` option)
+2. **Install** `.coverage-baseline.json` with current coverage as the starting ratchet
+3. **Add** `scripts/check-coverage-ratchet.sh` to CI
+4. **Add** `scripts/check-stubs.sh` to deploy.sh and pre-push hook
+5. **Add** `scripts/check-anti-fake-tests.sh` to pre-commit or CI
+
+The ratchet starts at your current coverage. From that point on, it can only increase.
+
+---
+
+## Related Standards
+
+- `testing.ai.yaml` — Test structure, FIRST principles, AAA pattern (pyramid thresholds deprecated here)
+- `unit-testing.ai.yaml` — Unit test scope and organization
+- `integration-testing.ai.yaml` — Integration test patterns
+- `deployment-standards.ai.yaml` — Deploy gate requirements
+- XSPEC-178 — Full specification and implementation phases

package/bundled/core/performance-standards.md

@@ -323,6 +323,70 @@ Analogous to the SRE Error Budget concept, a Performance Budget defines the tole
 
 ---
 
+## Per-Release Capacity Sign-off
+
+This section defines the **capacity gate** that must be satisfied before production release (Dimension 10 in `release-readiness-gate.md`, Tier-3).
+
+### Capacity Forecast
+
+Before each release candidate, produce a capacity forecast based on:
+
+1. **Baseline**: 90-day rolling average of peak TPS and resource utilization (CPU, memory, DB connections, storage growth rate)
+2. **Release impact estimate**: expected traffic delta from new features (e.g., +15% TPS from new notification flow)
+3. **Seasonal adjustment**: any known traffic spikes within the next 30 days (marketing campaigns, seasonal peaks)
+
+### Headroom Thresholds
+
+| Metric | Target (PASS) | Warn Band | Fail Threshold |
+|--------|--------------|-----------|----------------|
+| CPU headroom at projected peak | ≥ 30% | 20–30% | < 20% |
+| Memory headroom | ≥ 25% | 15–25% | < 15% |
+| DB connection pool headroom | ≥ 40% | 25–40% | < 25% |
+| p99 latency vs baseline | ≤ +5% | +5% to +10% | > +10% regression |
+| Error rate at peak load | < 0.1% | 0.1–0.5% | > 0.5% |
+
+### Load Test Requirement
+
+Run the load test scenario defined in the Performance Testing sections above (Soak + Spike test minimum) before finalizing the capacity sign-off:
+
+```bash
+# Example: k6 capacity verification run
+k6 run --vus 500 --duration 20m scripts/perf/soak-test.js
+# Pass criterion: headroom metrics above, p99 within budget
+```
+
+### Sign-off Evidence
+
+The capacity gate requires **two named sign-offs** — both Engineering Lead and SRE Lead:
+
+```markdown
+## Capacity Sign-off — <version>
+
+**Projection date**: YYYY-MM-DD
+**Baseline period**: last 90 days
+
+| Metric | Baseline peak | Projected peak | Headroom | Status |
+|--------|-------------|---------------|----------|--------|
+| CPU | [X]% | [Y]% | [Z]% | PASS/WARN/FAIL |
+| Memory | [X]% | [Y]% | [Z]% | PASS/WARN/FAIL |
+| DB pool | [X]% | [Y]% | [Z]% | PASS/WARN/FAIL |
+| p99 latency | [X]ms | [Y]ms | [±Z]% | PASS/WARN/FAIL |
+
+**Load test artifact**: [link to load test report]
+
+**Eng Lead sign-off**: _______________ Date: __________
+**SRE Lead sign-off**: _______________ Date: __________
+```
+
+### When Tier-3 Applies as N/A
+
+The capacity sign-off is `N/A` (with documented rationale) when:
+- Project has < 100 DAU and no significant traffic growth expected
+- Internal tooling with fixed user count
+- Static content / documentation site
+
+---
+
 ## Related Standards
 
 - [Testing Standards](testing-standards.md) - Performance testing integration
@@ -330,6 +394,7 @@ Analogous to the SRE Error Budget concept, a Performance Budget defines the tole
 - [Logging Standards](logging-standards.md) - Performance logging
 - [Code Review Checklist](code-review-checklist.md) - Performance review
 - [Deployment Standards](deployment-standards.md) - Performance validation pre-deployment
+- [Release Readiness Gate](release-readiness-gate.md) - Dimension 1 (load) and Dimension 10 (capacity)
 
 ---
 

package/bundled/core/release-quality-manifest.md

@@ -16,11 +16,14 @@ A Release Quality Manifest makes quality evidence:
 
 ## Schema
 
+The RQM now covers **16 quality dimensions** matching `release-readiness-gate.md`. Automated gates appear here; human-verified gates appear in the Release Readiness Sign-off document.
+
 ```yaml
 release: vibeops-commercial-1.2.0
 generated_at: "2026-05-05T04:00:00Z"
 commit: "abc1234"
 gates:
+  # ── Automated quality gates ──────────────────────────────
   unit_coverage:
     actual: "73%"
     target: "80%"
@@ -57,7 +60,42 @@ gates:
     actual: true
     target: true
     status: pass
-overall: WARN   # worst gate status (2 warns, no fails)
+  # ── Extended dimensions (aligned with release-readiness-gate.md) ──
+  a11y_critical:             # Dimension 3: axe-core critical violations
+    actual: 0
+    target: 0
+    status: pass
+  a11y_serious:              # Dimension 3: axe-core serious violations
+    actual: 0
+    target: 0
+    status: pass
+  contract_drift:            # Dimension 4: consumer contracts failing (n/a if no consumers)
+    actual: 0
+    target: 0
+    status: pass             # or "n/a" if no API consumers
+  cross_flow_cuj_pass_rate:  # Dimension 6: critical user journey pass rate
+    actual: "100%"
+    target: "95%"
+    status: pass
+  browser_tier1_pass_rate:   # Dimension 9: Tier-1 browser matrix (n/a for non-frontend)
+    actual: "100%"
+    target: "100%"
+    status: pass             # or "n/a" for CLI/backend
+  capacity_headroom_cpu_pct: # Dimension 10: CPU headroom at projected peak (n/a for small projects)
+    actual: "42%"
+    target: "30%"
+    status: pass             # or "n/a" for small-scale projects
+  smoke_pass_rate:           # Dimension 14: post-deploy smoke (populated after staging deploy)
+    actual: "100%"
+    target: "100%"
+    status: pass
+  flow_gate_report:          # Dimension 16: Multi-Gate Flow verification
+    gate_0_complete: true    # all flows with ≥3 steps have §2.4 + §9.4 filled
+    gate_1_pr_coverage: true # all PRs touching flows include terminal-state tests
+    gate_3_ci_pass: true     # Decision Table CI all green; branch coverage ≥ 90%
+    gate_4_uat_signoff: true # UAT sign-off table signed
+    status: pass
+overall: WARN   # worst gate status across all dimensions (2 warns, no fails)
 ```
 
 ## Status Semantics
@@ -68,15 +106,23 @@ overall: WARN   # worst gate status (2 warns, no fails)
 | `warn` | Within acceptable deviation (see per-gate policy) | Document reason; no release block |
 | `fail` | Below hard minimum | **Blocks release** |
 
-### Per-Gate Hard Minimums (Examples)
-
-| Gate | Warn Band | Fail Threshold |
-|------|-----------|----------------|
-| unit_coverage | target - 10pp to target | below target - 10pp |
-| mutation_score | target - 5pp to target | below target - 5pp |
-| sca_critical_cve | — | any critical CVE = fail |
-| container_cve_critical | — | any critical CVE = fail |
-| e2e_pass_rate | target - 3pp to target | below target - 3pp |
+### Per-Gate Hard Minimums
+
+| Gate | Warn Band | Fail Threshold | Release Readiness Dimension |
+|------|-----------|----------------|----------------------------|
+| unit_coverage | target - 10pp to target | below target - 10pp | (core RQM) |
+| mutation_score | target - 5pp to target | below target - 5pp | (core RQM) |
+| sca_critical_cve | — | any critical CVE = fail | Dim 2 (Security) |
+| container_cve_critical | — | any critical CVE = fail | Dim 2 (Security) |
+| e2e_pass_rate | target - 3pp to target | below target - 3pp | (core RQM) |
+| a11y_critical | — | > 0 = fail | Dim 3 (a11y) |
+| a11y_serious | project threshold | project threshold + 1-2 | Dim 3 (a11y) |
+| contract_drift | — | any red consumer contract = fail (if n/a: skip) | Dim 4 (Contract) |
+| cross_flow_cuj_pass_rate | 90–95% | < 90% | Dim 6 (Cross-flow Regression) |
+| browser_tier1_pass_rate | — | < 100% (if n/a: skip) | Dim 9 (Browser Compat) |
+| capacity_headroom_cpu_pct | 20–30% | < 20% (if n/a: skip) | Dim 10 (Capacity) |
+| smoke_pass_rate | — | any smoke failure = fail | Dim 14 (Smoke) |
+| flow_gate_report | gate_3_ci_pass=false | gate_0_complete=false OR gate_4_uat_signoff=false | Dim 16 (Multi-Gate Flow) |
 
 ## Automated Generation
 

package/bundled/core/release-readiness-gate.md

@@ -0,0 +1,184 @@
+# Release Readiness Gate
+
+> **Language**: English | [繁體中文](../locales/zh-TW/core/release-readiness-gate.md)
+
+**Version**: 1.0.0
+**Last Updated**: 2026-05-05
+**Applicability**: All software projects preparing a production release
+**Scope**: universal
+**Industry Standards**: ISO/IEC 25010 (Product Quality), ISTQB Advanced Test Manager
+**References**: `core/release-quality-manifest.md`, `core/flow-based-testing.md`
+
+---
+
+## Purpose
+
+This standard defines a **single, aggregated Release Readiness Gate** that unifies all quality dimensions into one explicit go/no-go decision before production deployment.
+
+Without this gate, quality evidence is spread across 16+ separate standards. Teams pass individual checks but ship with unverified dimensions, because no one document says "you must pass *all of these* before release."
+
+The Release Readiness Gate:
+- **Aggregates** 16 quality dimensions into a tiered checklist
+- **Connects** human sign-off (this document) to machine-readable evidence (`release-quality-manifest.md`)
+- **Distinguishes** blocking criteria from advisory warnings
+- **Scales** via Tier-1 / Tier-2 / Tier-3 classification to fit projects of different types and risk levels
+
+---
+
+## Relationship to Release Quality Manifest (RQM)
+
+| Artifact | Format | Audience | Purpose |
+|----------|--------|----------|---------|
+| **Release Readiness Sign-off** (this document's template) | Markdown checklist | Humans (PM, QA, Eng Lead, Business) | Go/no-go decision, accountability, audit trail |
+| **Release Quality Manifest** (`release-quality-manifest.md`) | YAML/JSON | CI, tooling, customers | Machine-readable aggregation, automated gate enforcement |
+
+These two artifacts are generated **in parallel** for every release. The Sign-off covers human-verified dimensions; the RQM covers automated dimensions. Both must be `PASS` / `WARN` (never `FAIL`) before production deployment.
+
+---
+
+## Tier Classification
+
+| Tier | Requirement | Miss = ? | Who Applies |
+|------|-------------|---------|-------------|
+| **Tier-1** | Must pass; release blocked if `FAIL` | Hard block | All projects |
+| **Tier-2** | Should pass; `WARN` documented with rationale; no block | Documented WARN | All projects |
+| **Tier-3** | Applicable when feature set or domain requires it; `N/A` is valid | N/A accepted | Depends on project type |
+
+---
+
+## 16-Dimension Release Readiness Matrix
+
+| # | Dimension | Tier | Gate Type | Blocking Criterion | Evidence | Standard | Responsible |
+|---|-----------|------|-----------|-------------------|----------|---------|-------------|
+| 1 | **Performance / Load** | 2 | Automated | p95 latency regression > 10%; headroom < 20% | Load test report | `performance-standards.md` | Eng Lead + SRE |
+| 2 | **Security** (SAST/DAST/SCA/secrets) | 1 | Automated | Any Critical/High CVE, SAST High unfixed, secret in diff | SARIF, Trivy, SBOM | `pipeline-security-gates.md` | SecEng / Eng Lead |
+| 3 | **Accessibility (a11y)** | 2 | Automated + Manual | axe-core critical > 0; keyboard nav path broken | axe report, screen reader log | `accessibility-standards.md` §Release-Blocking Threshold | QA + UX |
+| 4 | **API / Contract Testing** | 3 | Automated | Upstream consumer contract red; N-1 compat broken | Pact broker report | `contract-testing-standards.md` | API owner |
+| 5 | **Database Migration** | 1 | Automated | up/rollback/idempotency test fails; data-preservation test fails | `data-migration-testing.md` gate results | `data-migration-testing.md` | DB Lead |
+| 6 | **Cross-flow Regression** | 2 | Automated | Critical user journey pass rate < 95%; business-critical flow combo fails | Cross-flow regression report | `cross-flow-regression.md` | QA Lead |
+| 7 | **Operational Readiness** | 1 | Manual | Runbook missing; alerting unconfigured; no rollback procedure | Runbook link, alert rule review | `runbook-standards.md`, `alerting-standards.md` | SRE / Ops |
+| 8 | **Localization / i18n** | 2 | Automated | MISSING or MAJOR i18n gap in release (semver gap) | `check-translation-sync.sh` output | `translation-lifecycle-standards.md` | i18n Lead |
+| 9 | **Browser / Device Compatibility** | 3 | Automated | Tier-1 browser/device pass rate < 100% | Playwright matrix report | `browser-compatibility-standards.md` | Frontend QA |
+| 10 | **Capacity Sign-off** | 3 | Manual | Headroom < 30% at projected peak; no Eng+SRE sign-off | Capacity forecast + sign-off | `performance-standards.md` §Per-Release Capacity Sign-off | SRE + Eng Lead |
+| 11 | **Compliance / Privacy** | 3 | Manual | GDPR/CCPA violation; audit log missing; retention policy broken | Privacy review checklist | `privacy-standards.md` | DPO / Legal |
+| 12 | **Documentation Completeness** | 2 | Manual | CHANGELOG missing for release; customer-facing docs not updated | CHANGELOG diff, docs review | `changelog-standards.md`, `documentation-lifecycle.md` | Tech Writer / PM |
+| 13 | **Rollback / Disaster Recovery** | 1 | Manual | No tested rollback procedure for this release; RTO > threshold | DR drill record; rollback script | `rollback-standards.md`, `disaster-recovery-drill.md` | SRE |
+| 14 | **Production Smoke / Canary** | 1 | Automated | Post-deploy smoke fails; canary error rate > SLO | Smoke test results; canary dashboard | `smoke-test.md`, `cd-deployment-strategies.md` | SRE / DevOps |
+| 15 | **Feature Flag Governance** | 2 | Manual | Default state not reviewed; kill-switch not tested | Flag audit checklist | `feature-flag-standards.md` | PM + Eng Lead |
+| 16 | **Multi-Gate Flow Verification** | 2 | Automated + Manual | Gate 0 missing for any flow with ≥ 3 steps; Gate 3 CI fail; Gate 4 UAT sign-off missing | `flow_gate_report.json`; UAT sign-off table | `flow-based-testing.md` §Multi-Gate | QA Lead + Business |
+
+> **Note on Tier-3**: Mark as `N/A` when not applicable (e.g., browser matrix for a CLI tool; contract testing for a standalone service with no API consumers). `N/A` requires a rationale comment in the sign-off.
+
+---
+
+## Release Readiness Sign-off Template
+
+> Copy this template for each release. File as `.release-readiness/<version>.md` in the repo root, or attach to the release artifact.
+
+```markdown
+# Release Readiness Sign-off
+
+**Release**: [tag/version]
+**Date**: [YYYY-MM-DD]
+**Environment**: Pre-Production → Production
+**RQM Artifact**: [link or commit SHA]
+
+## Tier-1 Gates (ALL must be PASS)
+
+| # | Dimension | Status | Evidence | Sign-off |
+|---|-----------|--------|----------|---------|
+| 2 | Security (SAST/DAST/SCA) | PASS / FAIL | [link] | [name] |
+| 5 | Database Migration | PASS / FAIL | [link] | [name] |
+| 7 | Operational Readiness | PASS / FAIL | [link] | [name] |
+| 13 | Rollback / DR | PASS / FAIL | [link] | [name] |
+| 14 | Production Smoke/Canary | PASS / FAIL | [link] | [name] |
+
+## Tier-2 Gates (WARN must have rationale)
+
+| # | Dimension | Status | Evidence | Rationale (if WARN) | Sign-off |
+|---|-----------|--------|----------|---------------------|---------|
+| 1 | Performance / Load | PASS / WARN / FAIL | [link] | | [name] |
+| 3 | Accessibility | PASS / WARN / FAIL | [link] | | [name] |
+| 6 | Cross-flow Regression | PASS / WARN / FAIL | [link] | | [name] |
+| 8 | Localization / i18n | PASS / WARN / FAIL | [link] | | [name] |
+| 12 | Documentation | PASS / WARN / FAIL | [link] | | [name] |
+| 15 | Feature Flag Governance | PASS / WARN / FAIL | [link] | | [name] |
+| 16 | Multi-Gate Flow Verification | PASS / WARN / FAIL | [link] | | [name] |
+
+## Tier-3 Gates (N/A with rationale allowed)
+
+| # | Dimension | Status | Evidence | Rationale (if N/A) | Sign-off |
+|---|-----------|--------|----------|---------------------|---------|
+| 4 | API / Contract Testing | PASS / WARN / N/A | [link] | | [name] |
+| 9 | Browser / Device Compat | PASS / WARN / N/A | [link] | | [name] |
+| 10 | Capacity Sign-off | PASS / WARN / N/A | [link] | | [name] |
+| 11 | Compliance / Privacy | PASS / WARN / N/A | [link] | | [name] |
+
+## Overall Decision
+
+- [ ] **GO** — All Tier-1 PASS; all WARN documented; all N/A have rationale
+- [ ] **NO-GO** — One or more Tier-1 FAIL, or undocumented WARN
+
+**Decision made by**: [name, role]
+**Date**: [YYYY-MM-DD]
+```
+
+---
+
+## Status Semantics
+
+| Status | Meaning | Release Impact |
+|--------|---------|----------------|
+| `PASS` | Meets or exceeds all criteria | None |
+| `WARN` | Below target but above hard minimum; rationale documented | Allowed; logged |
+| `FAIL` | Below hard minimum; unresolved | **Blocks release** |
+| `N/A` | Dimension not applicable to this project/release; rationale documented | Allowed |
+
+---
+
+## When to Create the Sign-off
+
+| Milestone | Action |
+|-----------|--------|
+| Release candidate tagged | Create `.release-readiness/<version>.md` from template; fill evidence links |
+| Pre-UAT deployment | Gate 3 CI results populated; Tier-1 automated gates verified |
+| UAT sign-off (Gate 4) | Tier-3 manual gates completed; Multi-Gate Flow row finalized |
+| Production deployment decision | Overall GO/NO-GO decision signed by release owner |
+
+The sign-off is **not** an afterthought — Gate 0 (PRD completeness) and Gate 1 (PR-level tests) must be satisfied long before the sign-off document is created. The sign-off aggregates evidence that was being collected throughout the release cycle.
+
+---
+
+## Anti-Patterns
+
+- **Creating the sign-off the day of deployment** — evidence should be collected incrementally throughout the release cycle
+- **Marking WARN without rationale** — WARN without documented reason is functionally equivalent to ignoring the gate
+- **Skipping Tier-3 entirely without N/A rationale** — if browser testing is omitted for a web app, that must be explicitly justified
+- **Treating the Sign-off as a rubber stamp** — every row requires a named sign-off owner; anonymous collective ownership means no real accountability
+- **Using a shared sign-off for multiple releases** — one sign-off per release tag; do not reuse across versions
+
+---
+
+## See Also
+
+- `release-quality-manifest.md` — machine-readable RQM (the automated counterpart to this sign-off)
+- `flow-based-testing.md` — Multi-Gate Flow Model (Dimension 16)
+- `branch-completion.md` — branch-level gate (prerequisite; not equivalent to release readiness)
+- `verification-evidence.md` — evidence standards (all evidence links must meet this standard)
+- `deployment-standards.md` — post-deploy gate integration
+
+---
+
+## Version History
+
+| Version | Date | Changes |
+|---------|------|---------|
+| 1.0.0 | 2026-05-05 | Initial release: 16-dimension matrix, tiered sign-off template, RQM integration |
+
+---
+
+## License
+
+This standard is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).
+
+**Source**: [universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)