> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Change management

> Every production change goes through code review, automated security gates, and a deployment gate.

<Info>
  No code reaches production without passing every gate below. No gate can be bypassed by an individual contributor.
</Info>

## Pull request gates

Every PR to `master` must pass:

<Steps>
  <Step title="Linting">
    RuboCop (backend), ESLint + TypeScript strict (frontend), `terraform fmt` + `terraform validate`.
  </Step>

  <Step title="Tests">
    Backend: `parallel_rspec` across 4 shards. Frontend: Vitest across 4 shards. E2E: Playwright smoke tests. **90% / 80% coverage** minimums enforced.
  </Step>

  <Step title="Security scans">
    Brakeman (SAST), bundler-audit, npm audit, Trivy (Terraform), gitleaks, license\_finder. All blocking on medium+ severity.
  </Step>

  <Step title="Type check">
    `tsc --build` for frontend; RBS / Sorbet not yet enabled.
  </Step>

  <Step title="OpenAPI drift check">
    If request specs changed, the OpenAPI spec must be regenerated and the TypeScript types migrated.
  </Step>

  <Step title="Code review">
    At least one approving review from someone other than the author. Security-sensitive changes (policies, auth, encryption, PHI) require an additional reviewer.
  </Step>
</Steps>

## Deployment pipeline

<Steps>
  <Step title="Build">
    On merge to `master`, GitHub Actions builds Docker images for backend and frontend. Images are tagged with the full commit SHA.
  </Step>

  <Step title="Push">
    Images are pushed to GCP Artifact Registry via Workload Identity Federation — no long-lived keys.
  </Step>

  <Step title="Migrate">
    A Cloud Run **migration job** runs database migrations before the new image is promoted.
  </Step>

  <Step title="Deploy">
    Cloud Run deploys the new image with a gradual rollout. Health checks must pass before 100% traffic.
  </Step>

  <Step title="Verify">
    Smoke tests hit the live deployment. Rollback is automatic on failure.
  </Step>
</Steps>

## Strong migrations

The `strong_migrations` gem enforces safe migration practices:

* No removing columns without `safety_assured` and a compatibility window.
* Concurrent index creation for large tables.
* Backfills must be separated from schema changes.
* Any unsafe migration raises `StrongMigrations::UnsafeMigration` in development.

## Rollback

* **Cloud Run revision rollback** — any previous revision can be promoted via one command.
* **Database rollback** — migrations are forward-compatible where possible; destructive rollbacks require a manual runbook and approval.
* **Config rollback** — Terraform state is versioned; any change can be rolled back via re-apply of the previous plan.

## Segregation of duties

* Developers have **read** access to production logs and metrics (via GCP IAM) but **no direct write** access to the database or production Secret Manager values.
* Deployment is performed by the CI/CD pipeline under a deploy-specific service account — no humans hold its credentials.
* Break-glass access for production incidents is granted just-in-time via a documented procedure and audit-logged.

## Infrastructure changes

Terraform applies go through the same PR process — plan review in the PR, apply after merge. Applies are performed via Cloud Build (regional bucket) and the deploy service account.

## Artifact signing (planned)

Image signing with Sigstore/cosign and verification at deploy time is on the roadmap — target Q3 2026.