universal-dev-standards 5.5.0 → 5.6.0

package/bundled/ai/options/testing/integration-testing.ai.yaml

@@ -17,7 +17,7 @@ characteristics:
   scope: Multiple components working together
   speed: "<1 second per test"
   isolation: Partial (may use real dependencies)
-  pyramid_percentage: 20%
+  coverage_policy: "Behavior-completeness ratchet (XSPEC-178) — no fixed % floor. See full-coverage-testing.ai.yaml."
 
 rules:
   - id: test-integration-points
@@ -86,4 +86,4 @@ tools:
     - MockServer
     - nock (Node.js)
 
-coverage_target: "Critical paths and integration points"
+coverage_target: "All critical paths AND integration points — not just happy path. Ratchet CI enforced. (XSPEC-178)"

package/bundled/ai/options/testing/unit-testing.ai.yaml

@@ -11,7 +11,7 @@ characteristics:
   scope: Single function or method
   speed: "<100ms per test"
   isolation: Complete (no external dependencies)
-  pyramid_percentage: 70%
+  coverage_policy: "Behavior-completeness ratchet (XSPEC-178) — no fixed % floor. See full-coverage-testing.ai.yaml."
 
 rules:
   - id: test-one-thing
@@ -71,7 +71,7 @@ when_not_to_write:
   - Testing trivial getters/setters
   - Testing third-party libraries
 
-coverage_target: "80% of business logic"
+coverage_target: "Behavior-completeness: happy/edge/error path per public function. Ratchet CI — coverage can only increase. (XSPEC-178 — deprecated fixed 80% threshold)"
 
 tools:
   javascript: [Jest, Vitest, Mocha]

package/bundled/ai/standards/browser-compatibility-standards.ai.yaml

@@ -0,0 +1,63 @@
+# Browser Compatibility Standards - AI Optimized
+# Source: core/browser-compatibility-standards.md
+
+id: browser-compatibility-standards
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/browser-compatibility-standards.md
+  description: Browser/device support matrix, Playwright automation, and release gate for frontend projects; N/A for CLI/backend
+
+requirements:
+  REQ-1:
+    id: REQ-BC-001
+    title: Explicit Support Matrix
+    rule: >
+      Frontend projects MUST declare an explicit browser support matrix in
+      .browserslistrc and in Playwright project config. At minimum define Tier-1
+      (full support, release blocking) and Tier-2 (partial, WARN) browsers.
+      Tier-1 default: Chrome/Firefox/Safari/Edge latest + latest-1; iOS Safari
+      latest + latest-1; Android Chrome latest.
+    rationale: >
+      Implicit "supports all browsers" is untestable; an explicit matrix defines
+      scope for both engineering and QA.
+
+  REQ-2:
+    id: REQ-BC-002
+    title: Viewport Coverage
+    rule: >
+      Automated tests MUST cover at minimum three viewport widths: 360px (mobile),
+      768px (tablet), 1280px (desktop). No critical flow must be broken at any
+      Tier-1 browser × viewport combination.
+    rationale: >
+      Missing mobile viewport tests produce broken UX for the majority of
+      mobile users who represent 50%+ of web traffic globally.
+
+  REQ-3:
+    id: REQ-BC-003
+    title: Real iOS Device Testing
+    rule: >
+      For release candidates, Safari must be tested on real iOS devices (not
+      simulators only). WebKit on iOS Simulator diverges from real device WebKit
+      in rendering and API behaviour.
+    rationale: >
+      Simulator-only iOS testing misses a significant class of WebKit rendering
+      bugs that only manifest on real hardware.
+
+  REQ-4:
+    id: REQ-BC-004
+    title: Release Gate
+    rule: >
+      Tier-1 browser matrix pass rate MUST be 100% (no test failure = release block).
+      Tier-2 must be ≥ 95% (WARN if below). This is Dimension 9 (Tier-3) in
+      release-readiness-gate.md. Mark N/A for CLI, backend API, and mobile native projects.
+    rationale: >
+      100% Tier-1 requirement is appropriate because unsupported behavior in
+      a declared Tier-1 browser is a support commitment violation.
+
+quick_reference:
+  tier1_default: "Chrome, Firefox, Safari, Edge (latest + latest-1); iOS Safari; Android Chrome latest"
+  viewport_minimum: "360px, 768px, 1280px"
+  automation: "Playwright matrix config; BrowserStack/Sauce/LambdaTest for cross-OS"
+  na_when: "CLI-only, backend API, mobile native (non-web)"
+  release_readiness_dimension: "Dim 9, Tier-3"

package/bundled/ai/standards/contract-testing-standards.ai.yaml

@@ -0,0 +1,62 @@
+# Contract Testing Standards - AI Optimized
+# Source: core/contract-testing-standards.md
+
+id: contract-testing-standards
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/contract-testing-standards.md
+  description: Consumer-driven contract testing standard with release gate integration; applies to projects with API consumers
+
+requirements:
+  REQ-1:
+    id: REQ-CT-001
+    title: Consumer-Driven Flow
+    rule: >
+      For projects with API consumers, contracts MUST be published by consumers
+      to a Pact Broker (or equivalent). Providers MUST verify all active consumer
+      contracts in CI. The `can-i-deploy` command MUST return exit 0 before
+      any provider deployment.
+    rationale: >
+      Provider-only contract tests miss the most common class of contract bug:
+      the provider ships a change it considers non-breaking, but consumers assumed
+      different response structure.
+
+  REQ-2:
+    id: REQ-CT-002
+    title: Schema Matchers Not Literals
+    rule: >
+      Consumer contracts MUST use schema matchers (like(), eachLike(), integer(),
+      string(), email()) rather than exact literal values. Only assert fields
+      the consumer actually uses.
+    rationale: >
+      Literal value matching causes brittle contracts that break on realistic data
+      variation without indicating any real compatibility issue.
+
+  REQ-3:
+    id: REQ-CT-003
+    title: Backward Compatibility Window
+    rule: >
+      Minor releases MUST maintain N-1 consumer contract compatibility.
+      Major releases require a deprecation period: notify consumers, keep old
+      contract active until all consumers migrate, then archive.
+    rationale: >
+      Consumers cannot always upgrade in lockstep; the N-1 window allows them
+      one release cycle to migrate without service disruption.
+
+  REQ-4:
+    id: REQ-CT-004
+    title: Release Gate
+    rule: >
+      All active consumer contracts MUST be green before deploying a provider
+      to production. This is Dimension 4 (Tier-3) in release-readiness-gate.md.
+      Mark N/A when the project has no API consumers.
+    rationale: >
+      A red consumer contract means a deployed provider will break that consumer
+      in production — this is a hard release blocker, not a warning.
+
+quick_reference:
+  applies_when: "project has API consumers (service-to-service, frontend-to-backend, public API)"
+  gate: "can-i-deploy exit 0 before provider deploy; N-1 compat required"
+  broker_tag_convention: "main, production, <feature-branch>"
+  release_readiness_dimension: "Dim 4, Tier-3"

package/bundled/ai/standards/cross-flow-regression.ai.yaml

@@ -0,0 +1,61 @@
+# Cross-Flow Regression Standards - AI Optimized
+# Source: core/cross-flow-regression.md
+
+id: cross-flow-regression
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/cross-flow-regression.md
+  description: Cross-flow regression testing complementing per-flow Multi-Gate; verifies inter-flow state correctness and CUJ pass rates
+
+requirements:
+  REQ-1:
+    id: REQ-CFR-001
+    title: CUJ Suite Required per Release
+    rule: >
+      Every release candidate MUST run the full Critical User Journey (CUJ) regression
+      suite. CUJs are end-to-end sequences spanning ≥ 2 flows that share state or are
+      commonly executed sequentially. CUJ pass rate MUST be ≥ 95%.
+    rationale: >
+      Per-flow Multi-Gate testing proves intra-flow correctness; cross-flow tests catch
+      state contamination bugs that only manifest when flow outputs become the next
+      flow's inputs.
+
+  REQ-2:
+    id: REQ-CFR-002
+    title: Retrigger on Flow Spec Change
+    rule: >
+      When any flow's §2.4 Decision Points or Terminal States are modified, the full
+      CUJ regression suite MUST re-run as a pre-merge check — not just tests for the
+      changed flow. This prevents silent regressions in downstream flows.
+    rationale: >
+      A change to one flow's terminal states can produce different intermediate state
+      that breaks a previously passing downstream flow.
+
+  REQ-3:
+    id: REQ-CFR-003
+    title: Sequential State Threading
+    rule: >
+      CUJ tests MUST use sequential state threading: a shared `ctx` object accumulates
+      state across flows within a single test describe block. State MUST NOT be reset
+      between steps of the same CUJ. Each CUJ MUST have its own isolated ctx.
+    rationale: >
+      Resetting state between steps masks cross-flow contamination; independent ctx
+      per CUJ prevents CUJ-to-CUJ interference from masking bugs.
+
+  REQ-4:
+    id: REQ-CFR-004
+    title: Release Gate
+    rule: >
+      CUJ pass rate ≥ 95% = PASS. 90–95% = WARN (document specific failed CUJs).
+      < 90% or any business-critical flow combo failure = FAIL (release blocked).
+      This is Dimension 6 (Tier-2) in release-readiness-gate.md.
+    rationale: >
+      90% threshold accounts for environment-specific flakiness while ensuring
+      the vast majority of user journeys are verified end-to-end.
+
+quick_reference:
+  boundary_with_flow_based_testing: "flow-based-testing = intra-flow; cross-flow-regression = inter-flow"
+  cuj_trigger: "every release candidate + any flow §2.4 change"
+  pass_rate_target: "≥ 95% overall; 100% for business-critical combos"
+  release_readiness_dimension: "Dim 6, Tier-2"

package/bundled/ai/standards/full-coverage-testing.ai.yaml

@@ -0,0 +1,192 @@
+# Full Coverage Testing Standards - AI Optimized
+# XSPEC-178: Replaces pyramid threshold model with behavior-completeness paradigm
+# Source: core/full-coverage-testing.md
+
+standard:
+  id: full-coverage-testing
+  name: Full Coverage Testing Standards
+  description: Behavior-completeness full coverage paradigm replacing pyramid thresholds. Enforces anti-fake-test rules, STUB marker protocol, ratchet CI, and @ac traceability.
+
+  meta:
+    version: "1.0.0"
+    updated: "2026-05-06"
+    source: core/full-coverage-testing.md
+    replaces: "testing pyramid thresholds (UT≥80%/IT≥70%/E2E happy-path-only)"
+    xspec: "XSPEC-178"
+    description: AI-era full coverage paradigm — cost of writing tests equals cost of writing code, so there is no reason to set lower thresholds for any test layer.
+
+  rationale: |
+    Traditional pyramid thresholds (UT≥80%, IT≥70%) assumed tests were expensive to write.
+    AI code generation eliminates this cost differential — code and tests are produced at the
+    same speed. Therefore: maximize coverage everywhere, with behavior-completeness as the
+    measure, not a percentage floor.
+
+  coverage_model:
+    type: behavior_completeness
+    description: Every public function must have tests for all three behavioral paths
+    required_paths:
+      - id: happy_path
+        description: Normal input produces correct output
+        example: "calculateDiscount(100, 0.1) → 90"
+      - id: edge_case
+        description: Boundary values do not cause unexpected errors
+        example: "calculateDiscount(0, 1.0) → 0 without throwing"
+      - id: error_path
+        description: Invalid input raises clear error or returns error state
+        example: "calculateDiscount(-1, 2.0) → throws ArgumentError"
+
+  ratchet_policy:
+    enabled: true
+    description: Coverage can only increase, never decrease. PR that regresses coverage is blocked.
+    mechanism:
+      - Store baseline in .coverage-baseline.json on main branch
+      - Every PR compares current coverage against baseline
+      - Regression = PR blocked, not merged
+      - Improvement = new baseline set on merge
+    note: No fixed floor threshold. The current coverage IS the threshold.
+
+  rules:
+    # ── Behavior completeness ──────────────────────────────────────
+    - id: three-path-coverage
+      trigger: writing tests for any public function
+      instruction: |
+        Write at least three tests per public function:
+        1. happy_path — normal inputs, expected output
+        2. edge_case — boundary values (zero, max, empty, null)
+        3. error_path — invalid inputs trigger explicit error or error state
+      priority: required
+
+    - id: ac-traceability
+      trigger: writing any test
+      instruction: |
+        Tag each test with the Acceptance Criteria it covers using JSDoc @ac tag.
+        Format: /** @ac AC-ID */ above the test function.
+        If no AC maps to this test, use: /** @ac UNTRACED */
+      priority: recommended
+      example: |
+        /**
+         * @ac AC-US03-2
+         */
+        it('should block PR when coverage regresses', () => { ... })
+
+    # ── Anti-fake test rules ───────────────────────────────────────
+    - id: no-tautology-assertions
+      trigger: writing any test assertion
+      instruction: |
+        FORBIDDEN: Tautology assertions that always pass regardless of behavior.
+        These add false coverage without verifying anything.
+      priority: required
+      forbidden_patterns:
+        - "expect(true).toBe(true)"
+        - "expect(false).toBe(false)"
+        - "expect(result).toBeDefined()  // without specific value"
+        - "expect(result).not.toBeNull()  // without specific value"
+      required_instead: "expect(result).toBe(<specific expected value>)"
+
+    - id: no-mock-business-logic
+      trigger: deciding what to mock
+      instruction: |
+        FORBIDDEN: Mocking core business logic or your own service functions.
+        Mocking your own code means the business logic is never actually executed.
+      priority: required
+      allowed_to_mock:
+        - External HTTP APIs (payment gateways, OAuth providers)
+        - Hardware interfaces (sensors, GPIO, Docker daemon)
+        - Third-party SDKs with no test mode
+        - File system (use tmpdir, not mock)
+      forbidden_to_mock:
+        - Core business calculation functions
+        - Your own service layer methods
+        - Database queries (use in-memory SQLite instead)
+        - Your own utility functions
+
+    - id: mock-must-have-reason
+      trigger: writing any mock/stub/spy
+      instruction: |
+        Every jest.mock(), vi.mock(), jest.spyOn(), or sinon.stub() must be preceded
+        by a comment explaining WHY this dependency must be mocked.
+        Format: // MOCK: <reason — what external dependency and why it cannot be real>
+      priority: required
+      example: |
+        // MOCK: External Stripe payment API — no sandbox available in CI
+        jest.mock('./payment-gateway', () => ({ charge: jest.fn().mockResolvedValue({ id: 'ch_test' }) }))
+
+    # ── STUB marker protocol ───────────────────────────────────────
+    - id: stub-marker-required
+      trigger: writing any temporary/placeholder implementation
+      instruction: |
+        ALL temporary implementations, placeholder functions, and fake returns
+        MUST be marked with the standard STUB marker.
+        Format: // WARNING: STUB — Remove before UAT
+        This marker is scanned by pre-push hooks and deploy.sh.
+        STUB markers block pushes to main and deployments to UAT/production.
+      priority: required
+      example: |
+        // WARNING: STUB — Remove before UAT
+        async function validatePayment(card: Card): Promise<boolean> {
+          return true; // Always approve — replace with real Stripe call
+        }
+
+    - id: coverage-exempt-format
+      trigger: dealing with genuinely untestable external dependencies
+      instruction: |
+        If a dependency truly cannot be tested (hardware, live external API with no sandbox),
+        declare an explicit exemption with a mandatory reason.
+        Format: // COVERAGE_EXEMPT: <specific reason why real test is impossible>
+        This exemption is respected by STUB scanners and will not trigger blocking.
+        The reason MUST be non-empty and specific.
+      priority: required
+      example: |
+        // COVERAGE_EXEMPT: Hardware temperature sensor — no simulation available in CI
+        async function readTemperature(): Promise<number> {
+          return hardwareSensor.read();
+        }
+
+    - id: no-silent-stub
+      trigger: reviewing code before commit
+      instruction: |
+        Stubbed/placeholder code without // WARNING: STUB is a violation.
+        Common patterns to watch for: functions that always return hardcoded values,
+        empty function bodies that should have logic, TODO comments without STUB marker.
+        These will eventually reach production undetected.
+      priority: required
+
+  deployment_gates:
+    pre_push_to_main:
+      action: block
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[STUB-BLOCK] STUB markers detected. Push to main rejected."
+    deploy_to_uat:
+      action: block
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[DEPLOY-BLOCK] STUB markers detected. UAT deployment aborted."
+    deploy_to_production:
+      action: block
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[CRITICAL] Production deployment with STUB markers is strictly prohibited."
+    deploy_to_staging:
+      action: warn
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[STUB-WARN] Deploying with STUB markers to staging. NOT permitted in UAT/production."
+    feature_branch_push:
+      action: warn
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[STUB-WARN] STUB markers found. Must remove before merging to main."
+
+  migration_from_pyramid:
+    deprecated:
+      - "UT ≥ 80% coverage threshold"
+      - "IT ≥ 70% coverage threshold"
+      - "E2E happy-path-only requirement"
+    replaced_by:
+      - "Behavior-completeness: happy/edge/error per public function"
+      - "Ratchet CI: coverage can only increase"
+      - "Anti-fake rules: no tautology, no business-logic mocks"
+      - "STUB protocol: deployment gates on all environments"
+
+physical_spec:
+  type: custom_script
+  validator:
+    command: >
+      test -f scripts/check-stubs.sh && test -f scripts/check-anti-fake-tests.sh
+    rule: "xspec178_enforcement_scripts_present"

package/bundled/ai/standards/release-readiness-gate.ai.yaml

@@ -0,0 +1,77 @@
+# Release Readiness Gate Standards - AI Optimized
+# Source: core/release-readiness-gate.md
+
+id: release-readiness-gate
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/release-readiness-gate.md
+  description: Single aggregated release gate covering 16 quality dimensions with tiered sign-off template and RQM integration
+
+requirements:
+  REQ-1:
+    id: REQ-RRG-001
+    title: 16-Dimension Coverage
+    rule: >
+      Every production release MUST evaluate all 16 quality dimensions defined in
+      core/release-readiness-gate.md. Tier-1 dimensions block release if FAIL.
+      Tier-2 dimensions require documented rationale if WARN. Tier-3 dimensions
+      require rationale if N/A.
+    rationale: >
+      Without explicit multi-dimension coverage, teams pass individual gate checks
+      but ship with unverified quality dimensions, creating systematic blind spots.
+
+  REQ-2:
+    id: REQ-RRG-002
+    title: Release Readiness Sign-off
+    rule: >
+      A Release Readiness Sign-off document MUST be created from the template in
+      core/release-readiness-gate.md for every release tag. It must be stored at
+      .release-readiness/<version>.md. The Overall Decision field must be explicitly
+      set to GO or NO-GO by a named release owner.
+    rationale: >
+      Anonymous or implicit GO decisions remove accountability; the sign-off creates
+      a named, dated, auditable record of the go/no-go decision and its evidence.
+
+  REQ-3:
+    id: REQ-RRG-003
+    title: Tier-1 Hard Block
+    rule: >
+      ANY Tier-1 dimension at FAIL status MUST block production deployment.
+      Tier-1 dimensions are: Security (Dim 2), DB Migration (Dim 5), Operational
+      Readiness (Dim 7), Rollback/DR (Dim 13), Production Smoke (Dim 14).
+    rationale: >
+      Tier-1 dimensions represent existential risks: security vulnerabilities,
+      broken rollback, misconfigured monitoring. No business justification
+      overrides a Tier-1 FAIL.
+
+  REQ-4:
+    id: REQ-RRG-004
+    title: RQM Alignment
+    rule: >
+      The machine-readable Release Quality Manifest (release-quality-manifest.md)
+      MUST include entries for all automated dimensions (a11y_critical, contract_drift,
+      cross_flow_cuj_pass_rate, browser_tier1_pass_rate, capacity_headroom_cpu_pct,
+      smoke_pass_rate, flow_gate_report). The RQM overall field must be PASS or WARN
+      (never FAIL) before deployment.
+    rationale: >
+      Human sign-off and machine manifest are complementary; the manifest enables
+      automated enforcement while the sign-off provides human accountability.
+
+  REQ-5:
+    id: REQ-RRG-005
+    title: Incremental Collection
+    rule: >
+      Release Readiness Sign-off evidence MUST be collected incrementally throughout
+      the release cycle (Gate 0 at PRD, Gate 3 pre-UAT, Gate 4 post-UAT). Creating
+      the sign-off on the day of deployment is an anti-pattern.
+    rationale: >
+      Last-minute sign-offs are rubber stamps; evidence collected late cannot
+      be acted upon without delaying the release.
+
+quick_reference:
+  tier_1_dimensions: "Security, DB Migration, Operational Readiness, Rollback/DR, Production Smoke"
+  tier_2_dimensions: "Performance, a11y, Cross-flow Regression, i18n, Docs, Feature Flags, Multi-Gate Flow"
+  tier_3_dimensions: "Contract Testing, Browser Compat, Capacity, Compliance/Privacy"
+  sign_off_location: ".release-readiness/<version>.md"
+  rqm_integration: "flow_gate_report.json → release-quality-manifest.yaml field flow_gate_report"

package/bundled/ai/standards/testing.ai.yaml

@@ -4,19 +4,26 @@
 standard:
   id: testing
   name: Testing Standards
-  description: Testing pyramid and recommended coverage ratios with framework options
+  description: Testing structure, FIRST principles, AAA pattern, and framework options. For coverage policy, see full-coverage-testing (XSPEC-178).
   guidelines:
-    - "Follow 70/20/7/3 testing pyramid (UT/IT/ST/E2E)"
     - "Use FIRST principles for unit tests"
     - "Structure tests with Arrange-Act-Assert"
     - "Use meaningful test names"
+    - "See full-coverage-testing.ai.yaml for coverage policy (XSPEC-178)"
 
   meta:
-    version: "2.0.0"
-    updated: "2026-02-04"
+    version: "2.1.0"
+    updated: "2026-05-06"
     source: core/testing-standards.md
     guide: skills/testing-guide/testing-theory.md
-    description: Testing pyramid and recommended coverage ratios with framework options
+    description: Testing structure and principles. Coverage policy moved to full-coverage-testing (XSPEC-178).
+
+  deprecated_rules:
+    - id: pyramid-thresholds
+      description: "70/20/7/3 pyramid ratio and UT≥80%/IT≥70%/E2E happy-path-only thresholds"
+      reason: "AI-era paradigm shift: test generation cost equals code generation cost, so no layer should have a lower threshold. Replaced by behavior-completeness ratchet model."
+      since: "5.5.0"
+      replaced_by: "full-coverage-testing.ai.yaml (XSPEC-178)"
 
   framework_options:
     decision_point: Select testing framework based on project type
@@ -29,25 +36,25 @@ standard:
         best_for: Agile development, CI/CD optimization, rapid iteration
 
   pyramid:
-    ratio: "70/20/7/3"
-    note: "Recommended ratio based on Mike Cohn's test pyramid (empirical, not mandatory). ISTQB defines 4 levels: UT/IT/ST/E2E."
+    ratio: "DEPRECATED — see full-coverage-testing.ai.yaml"
+    note: "The 70/20/7/3 ratio is deprecated as of v5.5.0 (XSPEC-178). Coverage is now governed by behavior-completeness ratchet, not per-layer percentages. Layer names remain valid as organizational categories, not threshold buckets."
     levels:
       - name: Unit Tests (UT)
-        percentage: 70
         scope: Single function/method
         speed: Very fast (<100ms)
+        coverage_policy: "See full-coverage-testing.ai.yaml — ratchet model, no fixed % floor"
       - name: Integration Tests (IT)
-        percentage: 20
         scope: Multiple components interacting
         speed: Fast (<1s)
+        coverage_policy: "See full-coverage-testing.ai.yaml — ratchet model, no fixed % floor"
       - name: System Tests (ST)
-        percentage: 7
         scope: Complete subsystem with stubbed external dependencies
         speed: Medium (<10s)
+        coverage_policy: "See full-coverage-testing.ai.yaml — ratchet model, no fixed % floor"
       - name: E2E Tests
-        percentage: 3
         scope: Full user flows across entire system
         speed: Slow (>10s)
+        coverage_policy: "All AC must have E2E coverage — not just happy path"
 
   options:
     testing_framework:
@@ -81,9 +88,9 @@ standard:
           best_for: Microservices, API integrations, distributed systems
 
   rules:
-    - id: follow-pyramid
+    - id: follow-full-coverage
       trigger: planning test strategy
-      instruction: Follow 70/20/7/3 recommended ratio for UT/IT/ST/E2E (Mike Cohn empirical, not mandatory)
+      instruction: Follow behavior-completeness model — every public function needs happy/edge/error path tests. Ratchet CI ensures coverage never decreases. See full-coverage-testing.ai.yaml (XSPEC-178).
       priority: required
     - id: first-principles
       trigger: writing tests

package/bundled/core/accessibility-standards.md

@@ -817,12 +817,70 @@ Before Release:
 
 ---
 
+## Release-Blocking Threshold
+
+This section defines the **minimum a11y gate** that must pass before production release (Dimension 3 in `release-readiness-gate.md`, Tier-2).
+
+### Automated Gate (CI — axe-core / Pa11y)
+
+| Severity | Hard Minimum | Warn Band |
+|----------|-------------|-----------|
+| critical | 0 (release blocker) | — |
+| serious | ≤ project-configured threshold (default: 0) | +1–2 → WARN |
+| moderate | advisory, not blocking | — |
+| minor | advisory, not blocking | — |
+
+Run axe-core against every critical user-flow screen before release:
+
+```bash
+npx axe-cli <url> --tags wcag2a,wcag2aa --exit  # non-zero exit if critical/serious
+```
+
+CI must fail the build if `critical > 0` or `serious > configured-threshold`.
+
+### Conformance Level by Project Type
+
+| Project Type | Minimum Conformance | Notes |
+|-------------|-------------------|-------|
+| General web / SaaS | WCAG 2.1 Level AA | Default |
+| Financial, Healthcare, Government | WCAG 2.1 Level AA + Section 508 | Legally mandated |
+| Aspirational / premium brand | WCAG 2.2 Level AA | Recommended |
+
+### Keyboard Navigation Gate (Manual, Pre-UAT)
+
+All critical user flows (as defined in requirement-template §2.4) must be fully operable by keyboard alone:
+- Tab / Shift+Tab: navigate all interactive elements
+- Enter / Space: activate controls
+- Escape: dismiss modals / overlays
+- Arrow keys: navigate menus, tabs, tree views
+
+Gate: 100% of critical flow steps reachable by keyboard; no focus trap.
+
+### Screen Reader Spot Check (Manual, Pre-UAT)
+
+Minimum: 1 critical user flow tested on each of:
+- **Windows**: NVDA + Chrome
+- **macOS**: VoiceOver + Safari
+
+Pass criterion: all steps completable without visual reference; all form errors announced; all dynamic content changes announced.
+
+### Release Sign-off Evidence
+
+The a11y gate contributes to the Release Readiness Sign-off as:
+
+```
+| 3 | Accessibility | PASS | axe report: 0 critical / 0 serious; keyboard pass; SR spot-check VoiceOver OK | QA Lead |
+```
+
+---
+
 ## Related Standards
 
 - [Documentation Writing Standards](documentation-writing-standards.md) - Accessible documentation
 - [Code Review Checklist](code-review-checklist.md) - Accessibility review
 - [Testing Standards](testing-standards.md) - Accessibility testing
 - [Security Standards](security-standards.md) - Authentication accessibility
+- [Release Readiness Gate](release-readiness-gate.md) - Dimension 3: a11y release gate
 
 ---
 

package/bundled/core/branch-completion.md

@@ -156,3 +156,7 @@ If the branch has an associated worktree, the worktree must be cleaned up as par
 - **Superpowers**: [finishing-a-development-branch](https://github.com/obra/superpowers) (MIT)
 - **Git Flow**: Branch lifecycle management
 - **Trunk-Based Development**: Short-lived branches pattern
+
+---
+
+> **Branch completion ≠ Release readiness.** A completed branch means all its own quality gates passed. It does not mean the product is ready to ship. See `release-readiness-gate.md` for the 16-dimension release gate that must pass before production deployment.