Release Gate Test Policy

Last Updated: 2026-02-28
Audience: Release owners, reviewers, backend maintainers
Purpose: Standardize release confidence around maintained critical-path suites.

---

Blocking gate (for high-risk stabilization PRs)

Use one command for repeatability:

cd backend
npm run test:release:gate

This executes the curated maintained gate in order:

1. test:invariants
2. test:langchain:regressions
3. Selected integration tests:
   • tests/integration/time-tools.jest.test.ts
   • tests/integration/tools-remaining.jest.test.ts
   • tests/integration/protocol-flows.jest.test.ts

If this gate fails, release is blocked until fixed or explicitly waived by release owner with written rationale.

---

Fast pre-check (optional, non-blocking by itself)

For local iteration before full gate:

cd backend
npm run test:release:gate:quick

This runs invariants + LangChain regressions only.

---

Known-unmaintained suites policy

• Known-broken or unowned legacy suites are non-blocking for release decisions.
• They must not be used as the single release-quality signal.
• Any failure in those suites should create a follow-up remediation item with:
  • owner
  • ETA
  • decision on retirement vs repair

Until repaired and explicitly promoted, they remain informational only.

---

Promotion rule for legacy suites

A legacy suite can become blocking only when all are true:

1. It passes consistently in at least 3 consecutive gate runs.
2. It has a named owner.
3. It has clear failure triage instructions in docs/runbook.

---

Evidence logging for PRs

For high-risk PRs, include in PR notes:

• test:release:gate command output status
• date/time of run
• commit SHA
• any explicit waiver and release-owner approval