v3.1.0 — Canary-ready baseline

The stable baseline of the canary delivery, and everything a canary rollout needs.

Release identity

• Every response, errors and docs included, carries X-App-Version and X-App-Track (stable or canary).
• /api/... without a version serves the newest version the build has: v2 in this release.

Traffic splitting

• An Application Load Balancer in front of two EC2 machines, one per track, each with its own image.
• Weighted forward between the two target groups, set by canary_weight; a rule sends x-canary: true to the canary at any weight.
• Image tags in ECR are immutable: a commit SHA always names the same image.

Safe schema for two versions at once

• The schema is built from the entities only on an empty database; production never synchronizes, so an older build can never drop what a newer one added.
• Both tracks seed under a PostgreSQL advisory lock.

Observability and automatic abort

• Fault injection on the canary only: x-fault: error (500) or x-fault: latency (+1.5 s).
• The API publishes memory and movements recorded (the business metric) to CloudWatch, per track.
• A CloudWatch dashboard compares stable and canary side by side; two alarms watch the canary's errors and latency.
• canary/slo.json: versioned promote / pause / abort thresholds, read by both the alarms and the gate.
• Canary workflow: deploy (stage 0, header only), promote (10% → 50% → 100% under load, judged by canary/gate.ts, automatic rollback on abort), rollback.

Verified on AWS: a 50% weight split 87 / 113 out of 200 requests; a promotion with injected errors aborted at 10% (423 canary requests, all 5xx, alarm fired) and the canary went back to 0%.