Going Live Properly: The Plan (9 October 2026, revised the same day)

What this is. The step-by-step plan that follows from PRODUCTION-RESEARCH-2026-10-09.md, sized for a pilot: the one server and one database already decided in docs/27, about $66 a month at the start and about $103 at 1,000 students a year in (§2), plus the things that are nearly free and matter most: logs you can search, alarms that reach a phone, deploys with no outage, backups you have proven you can restore, and cookies that cannot leak across subdomains.

It has three parts:

• Part A: what you do by hand, every step spelled out, each with a check that proves it worked.
• Part B: what the agent builds, cleans up and updates, every item with its files and its "done when".
• Part C: the order, the gates, the runbooks and what is parked.

Status: the decisions in §1 were approved on 11 October 2026. Sections 3 to 7 explain the four that needed working out: videos, releases, retention and the night window, and how the plan grows. Nothing is built yet. Part A starts with the account steps (A-steps 1 to 14), and every later phase begins only after the gate before it is ticked by a named person.

1. Decisions first (Gate 0)

2. What it all costs

Everything this plan uses, priced in US East. "1,000 students" means 1,000 active students, each writing about 100 checked posts, comments and messages a month, uploading 3 photos, and 1 in 5 posting a 1.5-minute video (the same usage as docs/27 §12). All of it is paid from the AWS credits.

What we use from day one

The only line that grows on its own is files: storage adds about $1.15 a month for every month at 1,000 students. The retention numbers in §5 slow that: the full-quality originals, about half of it, go after 30 days. The monthly server swap (§6) adds about 5 cents a month.

Not used (the trigger to reconsider each is in C5): the frame-by-frame video check ($18 to $22 a month at 1,000 students) and Amazon Transcribe (Whisper does this job).

GuardDuty's line is an estimate between about $5 and $13: it depends on how busy the account is, which nobody knows until it runs. Its free first month shows the real figure; D10's alarms are set with room for the high end.

The credits. About $5,000 (docs/18). At $66 a month they last about 6 years; at $103, about 4 years.

Words used in sections 3 to 7

India's rules appear below even though the pilot is in the US. They apply once we have Indian users, and we follow them now so nothing has to change when that happens (DEADLINES-AND-DATA-2026-10-07.md explains each).

3. How videos are checked (D7)

Three things happen to every video, and no AI decides anything about the pictures.

1. Our own server writes down what is said. Whisper (speech-to-text that runs on our server, so the audio never leaves it) turns the sound into text. That text, together with any captions the student typed, goes through the same writing check as a post. A spoken phone number or a spoken threat is caught the same way a written one is.
2. A person watches every video before anyone else can see it. No video goes live on an AI's say-so, however clean its transcript is.
3. Known child-abuse material is matched against shared lists once the founder's applications to those programmes (NCMEC's list, Microsoft's PhotoDNA, Google's CSAI Match; D11) are approved. This compares a fingerprint of the video with material NCMEC and others have already confirmed. It is matching, not an AI judging what it sees.

One detail to know. The photo check (an Amazon AI that looks for nudity and violence, switched on at launch once Amazon is told not to keep our pictures, A-step 11) also looks at one picture per video: the sheet of 30 small stills that our server makes for the reviewer. It costs about $1 per 1,000 videos and works exactly like the photo check: it never approves or rejects anything, and if it sees something, that video moves to the front of the reviewer's list. This is not the frame-by-frame check D7 rules out, which would look at every second of every video for about $90 per 1,000 videos. If you would rather it left videos alone, it is a one-line change.

4. Releasing a new version without an outage (D5)

The idea. We never stop the running version to start the new one. The new version starts next to it on the same server, proves itself first on automatic checks and then on a small share of real visitors, and only then takes over. The old version stays running, unused, for half an hour, so we can switch back in seconds. Big companies call the small-share step a "canary" (a few go first) and the two-copies idea "blue/green". We do both on one server, because one is all we need yet.

The steps. One command (deploy.sh) runs all of them and stops at the first problem.

A release takes about 15 minutes, then the half hour with the old version kept warm. Release on a working morning when someone can watch. Never release on a Friday evening or just before the lunchtime rush.

The website (the part that runs in the browser) follows only once the server has fully switched. New files are added next to the old ones, which stay for 30 days, so a tab that is already open keeps working. The app checks for a newer version every 10 minutes and whenever the tab comes back into view. When it finds one, it says "A new version of Thnkrr is ready" and switches quietly the next time the student changes page, never in the middle of typing.

Three rules make this safe. Each is checked automatically before a release:

1. Database changes only add things during a release. Removing or renaming something happens in a later release, once no running version uses it. For example, a table stops being used in one release and is deleted in the next. A check fails any release whose database change removes or renames something without marking it as that second half.
2. The server keeps answering the previous website the same way. Fields are added, never removed or renamed in the same release. The type definitions the website and server already share make this a check, not a promise.
3. Only one version does background work at a time. A job cut off half-way, such as a video being converted, simply starts again. Every job is already written to be safe to repeat.

During the 10-minute trial, the per-person limits (requests a minute, posts a minute) are counted by each version separately, so they are briefly up to twice as generous. That is harmless for 10 minutes. It gets fixed properly before a second server ever exists (§7, stage 3).

A snapshot first, only when needed. A snapshot is a full copy of the database at one moment. Today the release script asks the person releasing to take one before it changes the database. It will now ask only when a release removes something, because releases that only add things can always be undone by switching back.

5. How long we keep things (D8)

These are our numbers. They meet every legal deadline in DEADLINES-AND-DATA-2026-10-07.md with room to spare, and each one is a single setting, so it can change whenever the founder or the lawyer asks.

Four rules sit behind them:

• While an account is open, we keep what the person made, as LinkedIn does: the profile, posts, comments, connections, photos and videos.
• Where a law sets a minimum, we use the longest one that could apply to us, for everyone. One rule for all users is simpler to run and to explain. It is the same reason we use India's 2-hour removal deadline for everyone.
• Legal holds always win. Anything linked to a child-safety case, a police or court request, an open complaint or appeal, or a lawsuit is kept until that hold ends, whatever the table below says.
• Records staff look at stay in the database until they are deleted, so they always open on screen; nothing has to be fetched back from an archive. The only copies kept elsewhere are server logs and backups, which nobody browses.

Two things make deleting real.

• Backups can't be edited. So we keep a short list of what was deleted: account numbers only, no content. It is kept in file storage outside the database, so restoring an older copy of the database doesn't lose it. If a backup is ever restored, everything on the list is deleted again straight away, so nobody who was deleted comes back.
• Deleting a lot must not slow the site. The clean-up runs at night in small batches, so it never competes with students. Once a table passes about a million rows, it is split by month and an old month is removed in one step (docs/27 §16).

What it costs, or saves. These numbers slow the one cost in §2 that grows on its own: files. The full-quality originals are about half of that growth, and they go after 30 days.

6. The monthly night window (D9)

What needs updating every month. The server's operating system and programs receive security fixes all the time. Most install themselves every night without stopping anything. A few, mainly fixes to the core of the operating system, only take effect after a restart, so once a month the server needs to start fresh. The database receives its own updates from Amazon a few times a year.

When. Sunday, 3:00 to 3:30 am US Eastern: the quietest half hour for US schools, and the pilot schools are in the US. We check it against the first month of real sign-in times, and move it when schools in other time zones join.

The server: replaced, not restarted

Restarting our one server means 1 to 2 minutes with no Thnkrr. So instead we build a fresh, fully updated server, move the site to it, and keep the old one switched off for a day as a spare.

This costs about 5 cents a month: two servers for an hour. And it gives us something for free: every month we prove we can rebuild the server from scratch, which is the disaster drill most small teams never get round to.

It works only if the server holds nothing that exists nowhere else. That is already true for uploads (they go straight to file storage), secrets (Parameter Store) and logs (CloudWatch). One thing needs work: the server's security certificate. The server gets its own name, origin.thnkrr.com. It proves it owns that name through our DNS. So a new server can get its certificate before it takes the address (B17). A video being converted at the moment of the swap needs nothing: it simply starts again.

The database: Amazon's updates, on our schedule

When the server or the database is away for a few minutes

Even with all of the above, something can be away for a few minutes, planned or not. This is what students see then, and what each part needs:

Deadlines keep running through the window. A 2-hour legal clock doesn't stop for our update. That is why the window is half an hour at the quietest time, why the person doing it is the on-call person named in A-step 14, and why its last step is to open the review list and check that nothing urgent arrived.

What this adds up to. Releases and server updates: no outage, at most a few seconds in which a request is repeated. Database version updates: under a minute, a few times a year. Amazon's rare required database fixes: a few minutes, announced ahead. Unplanned failures are rarer. If the server's hardware fails, Amazon moves it to new hardware within minutes (the recovery alarm in A-step 21), or the swap script (B17) builds a new server in about 15 minutes. If the database machine fails, Amazon usually restarts it within minutes. At worst, we restore from backup, which we practise (A-step 35). A standby database (stage 2) cuts that case to about a minute.

7. How this plan grows

The plan above is sized for the pilot. Each step up has a trigger: a measurement that tells us it is time, not a date. Nothing is bought early. C5 lists the detailed triggers for every parked piece.

Stage 2 in more detail. Each piece has its own trigger:

• A standby database when we pass about 300 students or sign the first paid school. Database updates shrink to about a minute, and a broken database machine no longer takes us down.
• A small video server of its own once videos wait more than 15 minutes in school hours, or the site slows while they convert. A single setting, already built, moves video work there.
• A staging server, a copy of production for trying releases first, switched off when unused, from the first paid school or a second engineer.
• A night-and-weekend rota with phone calls. In stage 1 one named person is on call and gets texts. A rota of several people, with calls that move up the chain when nobody answers, is the only reliable way to meet a 2-hour deadline that starts at 2 am.

How releases, monthly updates and retention change along the way:

Part A: What you do by hand

You = the founder or CTO, in the AWS console, the domain's DNS, or a browser. Where a step says "run the script", the agent has written it (Part B) and you paste one command into Session Manager. Each step ends with Check: the thing you must see before moving on. Do them in order.

A1. The account (Phase 0, about half a day plus Amazon's SES wait)

Gate 0 ticked by: founder (decisions), CTO (steps 1 to 14).

A2. The AWS side (Phase 2, about one day; after the agent's Part B is merged)

Gate 2 ticked by: CTO (steps 16 to 32).

A3. Prove it (Phase 3, about two days with the agent)

Gate 3 ticked by: CTO (numbers) and founder (plain-words summary from the agent).

A4. Go live (Phase 4)

Gate 4 ticked by: founder, before the first real school signs up.

A5. Ongoing

Part B: What the agent builds, cleans up and updates

Branch feat/production-ready in worktrees off dev/pilot in both repos; pull requests into dev/pilot. Migrations numbered from 0035 (0031 to 0034 came with the load work), additive only. Each item has its "done when"; the agent reports in plain words at each gate.

B1. Build: /api prefix and one front door

• API_PREFIX setting (production /api), applied in src/server.ts to every route group except the public pages /in/* and /school/*, which stay at the root; CORS only when API_PREFIX is unset (local development).
• Web: src/lib/api.ts reads VITE_API_URL=https://thnkrr.com/api; e2e config parameterised.
• Done when: integration tests pass with the prefix set and unset; the web e2e suite runs against the prefixed API.

B2. Build: cookies and sessions

• Cookie names __Host-thnkrr_session and __Host-thnkrr_csrf in production (no Domain, Path /, Secure); COOKIE_DOMAIN refused when __Host- is on.
• Anti-forgery token: a signed value bound to the session (OWASP signed double-submit), using COOKIE_SECRET.
• Migration: sessions.last_seen_at; idle limit 14 days for members, 12 hours for staff hats; 30-day absolute limit kept; sign-out clears with matching attributes.
• Done when: test/integration/auth-flow.test.ts covers idle expiry (both kinds), a forged token, and an old-format cookie answered with a clean 401.

B3. Build: edge secret on every API route

• The X-Thnkrr-Edge secret is required on /api/* as well as /in/* and /school/*; without it the request is refused with a plain 403 (except /health for the local health check).
• Done when: unit tests in client-ip cover CloudFront-with-secret, forged header, and local health.

B4. Build: health endpoints

• /health unchanged. /health/ready: database reachable, job queue connected, returns the git version and API_PREFIX.
• Done when: tests for both; deploy.sh and the Route 53 health check target /health/ready.

B5. Build: structured logs and request ids

• Replace every console.* under src/ (16 files) with the Fastify logger, child-logged per module.
• Request id from X-Amz-Cf-Id (CloudFront) or generated; returned as X-Request-Id; on every log line; included in the "Something went wrong" message body.
• Redaction: cookies, authorization, set-cookie, email addresses, any field named token, password, secret.
• Request log fields: method, route pattern, status, duration, hashed user id, hashed session id, request id. Slow (> 1 s) at warn, 5xx at error. A startup line with the git version.
• LOG_FILE setting; in production the app writes rotated JSON to /var/log/thnkrr/api.log (via systemd StandardOutput=append:), which the CloudWatch agent collects.
• Metric lines in CloudWatch embedded-metric format: 5xx count, 503 "busy" count, Bedrock error and latency, moderation queue age, video job duration, search latency.
• Done when: a test asserts no console. remains under src/ (scripts excepted); a test asserts the masking of a cookie and an email; metric lines validate.

B6. Build: feature switches

• Migration: feature_flags table; read every 30 seconds; pnpm flag list|set|unset; each change audit-logged.
• Flags: video_uploads, mentor_messaging (env still wins if set), search_fuzzy_fallback, retention_job. The banner is not a flag: it lives in status.json (B16), so it works while the server is away.
• Done when: integration test flips video_uploads off and sees the composer refuse politely within 30 seconds without a restart.

B7. Build: the server scripts and AWS templates (the files you upload or run in Part A)

• scripts/server-setup.sh: everything in docs/27 §14 steps 14 and deploy/README.md "Once" sections as one idempotent script, plus the CloudWatch agent install and its config deploy/cloudwatch-agent.json (api log, Caddy access log, journal errors; memory and disk metrics), plus fetching /thnkrr/prod/* from Parameter Store into /etc/thnkrr/api.env (chmod 600). Ends with "SETUP OK".
• deploy/aws/iam-api-server-policy.json (least privilege, as listed in A-step 19).
• deploy/aws/observability.yml: log groups (90-day retention), metric filters, the 10 alarms from §C3 with runbook links in their descriptions, SNS topic with email and SMS subscriptions, the dashboard, the Route 53 health check on /health/ready, the GuardDuty detector and an EventBridge rule sending its medium and high findings to the SNS topic (D12).
• deploy/aws/storage.yml: the buckets (web, two media, evidence, logs) with their CORS, lifecycle, versioning and Object Lock settings; the three B16 files in the web bucket; the monthly CloudWatch log export (EventBridge Scheduler → CreateExportTask, or the agent's equivalent that needs no Lambda).
• deploy/aws/edge.yml: both CloudFront distributions, behaviours, policies, the SPA function, the response-headers policy (HSTS, CSP, nosniff, referrer policy), an EnableWaf parameter that adds the web ACL with Amazon's Core rule set and Known bad inputs when true.
• deploy/aws/backup.yml: AWS Backup vault with Vault Lock and the monthly plan kept 12 months (§5).
• scripts/publish-web.sh (web repo): build, upload to the web bucket, invalidate /index.html, print "PUBLISHED <sha>".
• deploy/aws/scp-one-region.json and a harmless denied-call example for A-step 11.
• Done when: cfn-lint passes on every template; server-setup.sh runs clean twice on a fresh Ubuntu 24.04 ARM VM (Multipass or an EC2 spot box the CTO approves); each template's parameters are documented in deploy/README.md.

B8. Build: background work cannot starve the API

• Memory cap for the ffmpeg and whisper children (systemd slice MemoryMax or a per-spawn limit); keep nice; video jobs stay one at a time.
• Done when: the video integration test's timing assertion on a concurrent API request holds while a 15-minute test video processes.

B9. Build: releases with no outage (§4)

• scripts/deploy.sh v2: build into /opt/thnkrr/releases/<sha>; db:migrate; start thnkrr-api@<spare port> (3001 ↔ 3002) with a new setting BACKGROUND_WORK=off (serve requests, register no workers); wait for /health/ready; run scripts/smoke.sh --target 127.0.0.1:<port> as a robot account (pnpm staff:smoke-account: a hidden test school, a view-only moderator hat, never shown in staff lists).
• Trial: Caddy lb_policy weighted_round_robin 9 1 across both instances, then caddy reload. scripts/compare-versions.sh reads Caddy's access log per upstream for 10 minutes (5xx share, 95th-percentile time) and reverts the weights automatically on the §4 rule.
• Switch: weights 0/1. Background work hands over through a Postgres advisory lock: the old instance releases it on a signal, the new one takes it, so only one ever holds it. The old instance stays up 30 minutes, then stops. Keep the previous two releases.
• scripts/rollback.sh: swap the weights back (seconds, while the old instance is warm) or start the previous release on the spare port the same way (about a minute).
• scripts/check-migrations.ts in CI: fails on DROP, RENAME, column type changes or SET NOT NULL unless the migration carries a -- second-half: marker; deploy.sh asks the snapshot question only for marked releases.
• CI compares packages/contracts with the last release tag and fails when a field is removed or renamed without the same marker.
• deploy/Caddyfile and deploy/thnkrr-api@.service updated; the Caddy site serves origin.thnkrr.com (B17), not api.thnkrr.com.
• Web: scripts/publish-web.sh uploads new hashed files without deleting old ones, then removes files older than 30 days that the current and previous release don't use; writes version.json. The app reads it every 10 minutes and on tab focus, shows "A new version of Thnkrr is ready", and reloads on the next page change.
• Done when: on the test VM, a curl loop at 20 requests a second across a deploy shows zero failures; a release with one route broken is stopped at step 3; a release failing 5% of requests is reverted at step 4 within a minute; a Playwright test sees the new-version note and the switch on the next page change. The sequence is in deploy/runbooks/deploy.md.

B10. Build: search check at pilot size

• Web: the typing box cancels the previous in-flight request on each keystroke (TanStack Query signal).
• pnpm search:bench --profiles 10000 --users 3000: generates pilot-size data, replays the measured traffic mix, prints median and 95th percentile per query type and the rate at which "busy" first appears.
• Done when: the numbers for a 1-processor, 1 GB Postgres are in docs/28 with the recommendation (stay on db.t4g.micro or move up one size).

B11. Build: the clean-up jobs (§5; switch off until the dry run is read)

• One setting per number in §5, defaults as there. One nightly job runs every rule in batches of 5,000 with a pause between, has a dry-run mode that prints the counts, and writes each run's counts to the audit log. Behind the retention_job flag (B6).
• Every rule skips anything under a hold: a safety case, a legal order, an open complaint or appeal, an account action, or a new legal hold the Grievance Officer can place on a person or an item (a migration; the casework screens get the button).
• Delete my account (member settings) and staff closure: hidden within 24 hours; content gone at 30 days; the legally kept copy moves to a separate locked table readable only by the Safety Admin and Child Safety Lead, deleted after 1 year.
• Download my work (member settings): a zip of the profile, posts, photos and videos; needed before a school leaves.
• Moderation records: the text copy cleared 90 days after an approval; the record deleted after 2 years. Removed content kept 1 year (the code's 180-day constant becomes 365).
• Full-quality originals deleted 30 days after approval, in code rather than an S3 rule, because holds live in the database.
• Notifications after 90 days; expired sessions after 30; pg-boss archiveCompletedAfterSeconds 1 day and deleteAfterDays 30, set explicitly in src/jobs/boss.ts.
• Dormant accounts: the two warning emails, then closure.
• Deletion list: ids of deleted accounts and items, written to thnkrr-logs/deletions/ in S3 (outside the database, so a restore can't roll it back) and kept until the oldest backup has expired (12 months). pnpm restore:replay-deletions is a step in restore-drill.md and rebuild-server.md.
• audit_log rows older than 3 years deleted, except rows linked to a hold.
• Done when: integration tests prove a held item is never deleted by any rule; the restore drill replays the deletion list; a dry run on a copy of the pilot data is read by the CTO before the flag goes on.

B12. Build: load test, smoke test and drills

• load/ folder with k6 scripts for the mix in A-step 34 and a pass/fail report; pnpm load:k6 --target https://thnkrr.com.
• deploy/runbooks/smoke-test.md with the full table for A-step 33, and scripts/smoke.sh for the parts a script can check (/health/ready, a signed-out /in/ link, a dead media link after takedown).
• The failure-drill script for A-step 37 (now including the database reboot and the server swap under traffic) and the expected observations.
• Done when: k6 runs against the local prod-like compose and produces the report; the smoke script passes locally.

B13. Build: runbooks and the decision record

• deploy/runbooks/: the ten alarm runbooks and security.md (§C3), deploy.md, rollback.md, night-window.md, database-upgrade.md, retention.md, restore-drill.md, access.md, incident.md (paging, status page, blameless write-up template), rebuild-server.md, smoke-test.md.
• docs/28-production-ready.md: the decisions with names and dates, the benchmark and load-test numbers, the restore-drill time, the alarm thresholds, the credits facts; indexed in docs/00-overview.md; sources grouped at the end, no inline links.
• Done when: every alarm's description in observability.yml links to its runbook; docs/28 merged.

B14. Clean up

• Remove every console.* under src/ (B5).
• .env.example: COOKIE_DOMAIN PROD line becomes "leave unset (host-only cookies)"; add API_PREFIX, LOG_FILE; EDGE_SHARED_SECRET note covers all API routes; MENTOR_MESSAGING_ENABLED documented as overridden by the flag.
• deploy/README.md rewritten around server-setup.sh, the templates and deploy.sh v2; the old hand-typed install commands removed.
• deploy/Caddyfile: remove the api.thnkrr.com site and access from anywhere but CloudFront.
• Web: remove the api.thnkrr.com assumption anywhere it appears (README, e2e config, env examples).
• CI (.github/workflows/ci.yml in both repos): add the "no console" test, cfn-lint on the templates, and the prefixed-API e2e run; keep everything else.
• Remove the now-unused per-IP fallback comments that describe trustProxy for Caddy-only, replacing them with the CloudFront-only description.

B15. Update

• docs/27: a short note at the top of §7, §11 and §14 saying "replaced by docs/28 for: cookie domain, API address, deploy script, logging, alarms, templates"; nothing erased.
• docs/25 §6: add the pilot-size benchmark numbers and the "stay or resize" conclusion.
• docs/22 §1 and MODERATION-PLAN §6: add the smoke-test and drill references where they list launch checks.
• FOUNDER-UPDATE style one-pager at the platform root after Gate 3, in plain words, with the numbers.

B16. Build: when the server or database is away (§6)

• First, the crash. Give the API's database pool an error listener that logs and never exits (src/db/client.ts). Startup retries the database for up to 2 minutes instead of exiting. Check pg-boss reconnects the same way. Test: an integration test restarts a throwaway Postgres under a running server and sees requests answer "updating" (503) during the restart and succeed after it, with no process restart.
• status.json in the web bucket. pnpm status set "…" --from <time> --until <time> writes it, and pnpm status clear empties it. The app reads it on load, every 5 minutes, and at once when a request can't reach the server.
• "Updating" mode in the web app when requests get no answer or the edge's maintenance reply: the banner, cached data kept on screen, a retry every 20 seconds, the composer keeping its text with the button explaining. A real 401 is still the only thing that signs anyone out.
• CloudFront custom error responses (in edge.yml): /api/* 502, 503 and 504 → /maintenance.json (status 503, 10-second cache); /in/* and /school/* → /maintenance.html.
• The complaint and removal forms show the safety email address when the server can't be reached. deploy/runbooks/night-window.md says the on-call person watches that inbox and enters each arrival in the Orders tab with its received time.
• Done when: a Playwright test stops the API for 2 minutes and sees the banner within 30 seconds, nobody signed out, typed text kept, the banner gone after the API returns, and the legal forms showing the email address.

B17. Build: the monthly server swap (§6)

• deploy/aws/server.yml: a launch template (latest Ubuntu 24.04 ARM image, t4g.medium, role thnkrr-api-server, security group thnkrr-api, IMDSv2 required, user data running server-setup.sh).
• scripts/replace-server.sh (run from CloudShell with the CTO's sign-in): launch from the template; wait for "SETUP OK"; deploy the running release; run smoke.sh against it; pause the Site-down alarm; hand over background work; move the Elastic IP; check https://thnkrr.com/api/health/ready through CloudFront; stop the old server (not terminate) with a delete-after tag; switch the alarm back on, also on failure. Ends with "SWAPPED". --back moves the address back. Each run first deletes stopped servers whose delete-after has passed.
• Caddy's certificate for origin.thnkrr.com by DNS check through Route 53 (Caddy's Route 53 module). The server role may change only that name's validation record. The edge template's origin becomes origin.thnkrr.com.
• server-setup.sh turns on automatic security updates with automatic restart off.
• RDS: automatic minor upgrade off; maintenance window Sunday 07:00 to 07:30 UTC (3:00 am US Eastern). deploy/runbooks/database-upgrade.md walks through Amazon's blue/green upgrade.
• Done when: on the test account, replace-server.sh under the 20-requests-a-second loop shows failures only in the seconds the address moves; --back works; the stopped server is deleted on the next run after 24 hours.

Gate 1 ticked by: CTO, after CI is green on both repos, B7's scripts and templates pass their checks on a fresh VM, and the benchmark numbers are in docs/28.

Part C: Order, alarms, parked items

C1. Order and time

Roughly three working weeks from Gate 0 to a production site that staff can test, at about $48 a month (the firewall's $8 starts the week real students arrive).

C2. Gates

C3. Alarms (all within the 10 free) and their runbooks

C4. Settings that change from docs/27 §11

C5. Parked, with the measurement that would justify each