Part B: what was built, and what is needed to finish it (16 October 2026)
Read this beside the plan, notes/PRODUCTION-PLAN-2026-10-09.md. Every row below names
the part of the plan it comes from, so the two can be read side by side.
The one-minute version
Part B of the plan is the list of things the AI agent (me, Claude, writing this) builds in the code before Thnkrr goes onto Amazon's servers. All of it has been built and tested on this laptop, with one exception the plan itself schedules for later (a one-page summary for the founder, after Gate 3). Nothing is live yet: each piece waits on GitHub as its own proposed change, so it can be reviewed and accepted one at a time.
To call Part B complete, three things need you (Adarsh) and one needs the CTO: a new GitHub key so the website's automatic tests can run again; reviewing and accepting the proposed changes, in the order listed below; choosing how the server scripts get their "fresh machine" proof; and the CTO signing off Gate 1. If you are the CTO, the last one is yours too. Each is spelled out under What I need from you.
Nothing has touched the real Amazon (AWS) account yet. The parts only real AWS can prove are proven later in Part A, as the plan already says.
Who is who, and the plan's codes
I am the AI agent that built Part B. You are Adarsh, who carries out Part A of the plan (the steps done by hand in the AWS console). The CTO and the founder are the two people the plan names to sign off its checkpoints. The pilot is Thnkrr's first run with five schools, which everything here is sized for.
The plan labels its parts like this. B1 to B17 are the things to build (Part B). A-steps 1 to 44 are the things done by hand (Part A); A5 is the plan's section of routine tasks after launch. D1 to D12 are the decisions approved on 11 October 2026 (the plan's §1); D3, for example, is "one front door". § numbers are the plan's numbered sections. Gates are checkpoints where a named person confirms a phase is done before the next starts: Gate 1 is the end of Part B; Gate 2 the end of the AWS set-up (A-steps 16 to 32); Gate 3 the end of the live tests (A-steps 33 to 39). C2 and C3 are the plan's lists of gates and alarms.
Words used here
A branch is a named copy of the code with some changes on it. A pull request (PR) is a proposal to add a branch's changes to the shared code; it can be read, commented on, and accepted ("merged"). dev/pilot is the shared code the pilot will run. There are two code bases: api (the server) and web (the website), so some items have two PRs. CI is the set of automatic tests GitHub runs on every PR. A runbook is a step-by-step guide for one situation, such as an alarm going off. A template is a file that tells AWS what to create, so nobody has to click it together by hand. A drill is a rehearsal of a failure, done on purpose to check that recovery works. Docker runs a small, separate copy of a computer inside this laptop; the "local Ubuntu test machine" below is one of these, running Ubuntu (the same operating system as the real server). A virtual machine (VM) is a fuller version of the same idea, and Multipass is a free program that makes one. ms is a thousandth of a second.
What was built
Each item is on its own branch, built on the one before.
| Plan item | What it does, in plain words | PRs (api / web) | How it was proven |
|---|---|---|---|
| B16, first part (§6) | The server no longer shuts itself down when the database restarts; it waits and carries on | api #21 | A test restarts a real database under a running server |
| B1 (D3) | The server answers at thnkrr.com/api, behind the same front door as the website. There is no api.thnkrr.com | api #22, web #18 | Every test runs with and without the /api address |
| B2 | Sign-in that can't leak to other websites; you're signed out after 14 days unused (12 hours for staff) | api #23, web #19 | Tests for both time limits and for faked sign-ins |
| B3 | The server only accepts visitors who come through Amazon's front door (CloudFront), which adds a password to every request on the way in | api #24 | Tests with the password, without it, and with a fake one |
| B4 | A "ready" check that also asks the database, used by the alarms and by releases | api #25 | Tests for both answers |
| B5 | Searchable logs: every request gets a reference number; passwords, sign-ins and email addresses are hidden; the numbers the alarms need are written in | api #26 | Tests for the hiding, the reference numbers and the alarm numbers |
| B6 | On/off switches the team can flip without a restart (for example "pause video uploads") | api #27, web #20 | A test switches video off and sees the app say so within 30 seconds |
| B7 | The script that sets up a server from nothing, and the AWS templates for storage, the front door, alarms and backups | api #28, web #21 | The set-up script ran twice on the local Ubuntu test machine; the templates pass Amazon's own checking tool, run on this laptop. Not yet on AWS |
| B8 | Converting a long video can't slow the site down | api #29 | A test converts a 15-minute video while the site keeps answering in about 1.5 ms |
| B9 (§4, D5) | New versions go live with no outage. A new version first passes automatic checks, then serves 1 visitor in 10 for 10 minutes, and is pulled back automatically if it misbehaves. Going back takes seconds | api #30, web #22 | Drills on the local Ubuntu test machine with traffic running: a release with a broken page was stopped by the automatic checks, before any visitor reached it; a release failing 5% of requests during its 1-in-10 trial was pulled back after 30 seconds |
| B10 | Search measured at pilot size: about 250 searches a second before it slows; stay on the smallest database for now | api #31, web #23 | A speed test on a database limited to the pilot's size; numbers in docs/28 §1 (the decision record in the api code) |
| B11 (§5, D8) | How long things are kept, and the nightly clean-up (switched off until you've read a trial run); legal holds (the complaints officer can stop anything about a person from being deleted while a case is open); Delete my account; Download my work; deleted things stay deleted even after a backup is restored | api #32 to #35, web #24 to #26 | Tests for each: nothing under a hold is ever deleted; a closed account is hidden at once and deleted after 30 days; the download contains the person's own work; a restore removes again what was deleted |
| B12 | A load test, a release check and the failure drills, ready for Part A | api #36 | The load test ran here: 100 students at once, every answer well inside its limit |
| B16, the rest (§6) | When the server is away for a few minutes: a bar saying "Thnkrr is updating", nobody signed out, half-written posts kept, the complaint and removal forms showing an email address to use, and a planned notice you can set ahead of time | api #37, web #27 | A browser test takes the server away for 2 minutes; the screens were checked at full size |
| B17 (§6, D9) | The monthly swap: a fresh, fully updated server takes over with a few seconds' blip, and the old one is kept switched off for a day so you can go back | api #38 | The swap script was tested against a stand-in for AWS (7 situations, including every way it can fail); the parts that run on the server ran on the local Ubuntu test machine. Not yet on AWS |
| B13 | A runbook for every alarm, plus incidents, who has access, and rebuilding a server; the decision record (docs/28) | api #39 | An independent check against the code found 33 mistakes; all fixed |
| B14 | Tidying: the server instructions now follow the server template | api #40 | Tests |
| B15 | Older documents now point to the new decision record. Still to come, as the plan says: the founder one-pager, after Gate 3 | api #41 | Documents only |
On 16 October, on the final code, every server test passed (790) and every website test passed (156).
While checking the runbooks, real gaps were found and fixed. If no server was doing the background work (the AI checks, emails and videos that run behind the scenes), new posts stayed hidden and no alarm went off; the moderation alarm now goes off when that happens. Failed AI checks and emails that couldn't be sent left no trace in the logs; both now do. The scripts on the server never updated after its first set-up; every release now brings them up to date. And every setting has to live in AWS's settings store (Parameter Store), never only on the server, because the monthly swap builds a fresh server from there.
One more fix, on 16 October. GitHub's automatic tests for the server had been failing on every PR from #29 onward. The cause was one test, not the product: it asks the site "are you ready?" every 50 ms while a video converts, and on GitHub's slower machines it ran long enough to reach the site's own limit of 300 requests a minute. The limit is lifted for that one test (it measures speed, not limits), and the fix was carried through every later branch.
What turned out differently from the plan, and why. Amazon's front door can show only
one "updating" page for the whole site, so there is no separate maintenance.json for
the server's address; the website recognises the page instead. The monthly copy of the
logs runs on the server rather than from an AWS schedule. And the alarms aren't
completely free: Amazon counts every figure an alarm watches, 18 in all with 10 free, so
about $0.80 a month, inside the plan's "about $4" for logging and alarms (§2, D4).
What only real AWS can prove
These were built and tested as far as a laptop allows. Each is proven in Part A, where the plan already has a step for it: the server setting itself up from the template and getting its security certificate (A-steps 21 and 22); the templates creating what they describe (A-steps 24 to 27); the load test on the real machines (A-step 34); the restore drill (A-step 35); and the monthly swap with real traffic (A-step 37, drill 6). Gate 1 doesn't need any of these; they belong to Gates 2 and 3.
What I need from you
To call Part B complete (Gate 1)
The plan's Gate 1 reads: "Part B merged; CI green; scripts and templates proven on a fresh VM; benchmark in docs/28". The benchmark is done. The rest needs these four, in this order.
1. A new GitHub key for the website's tests (a task for you, about 5 minutes). The
website's automatic tests stop before they start because the stored key
THNKRR_API_READ_TOKEN no longer works. It lets the website's tests download the server
code. You need to be an admin of the thnkrr-web repository.
- Make the key: GitHub → your picture → Settings → Developer settings → Personal access
tokens → Fine-grained tokens → Generate new token. Resource owner: CerealNotFound.
Repository access: only
thnkrr-api. Permissions: Contents, read-only. Expiry: one year (put a reminder in your calendar to renew it). - Save it: thnkrr-web → Settings → Secrets and variables → Actions →
THNKRR_API_READ_TOKEN→ Update, paste the key. - Re-run the checks: on each web PR, Checks → Re-run all jobs. They should turn green.
2. Review and merge the PRs, in this order (a task for you). Every PR goes into dev/pilot. Each is built on the one before, so after one is merged the next one shows only its own changes; nothing needs re-pointing. Merge only when the PR's checks are green, and use GitHub's "Create a merge commit" button, not "Squash and merge" (squashing would leave the later PRs repeating the earlier ones' changes). Where a step names an api and a web PR, merge the api one first, then the web one.
| Step | Plan item | Merge |
|---|---|---|
| 1 | B16, first part | api #21 |
| 2 | B1 | api #22, then web #18 |
| 3 | B2 | api #23, then web #19 |
| 4 | B3 | api #24 |
| 5 | B4 | api #25 |
| 6 | B5 | api #26 |
| 7 | B6 | api #27, then web #20 |
| 8 | B7 | api #28, then web #21 |
| 9 | B8 | api #29 |
| 10 | B9 | api #30, then web #22 |
| 11 | B10 | api #31, then web #23 |
| 12 | B11, keeping times and legal holds | api #32, then web #24 |
| 13 | B11, closing an account | api #33, then web #25 |
| 14 | B11, download my work | api #34, then web #26 |
| 15 | B11, the deletion list | api #35 |
| 16 | B12 | api #36 |
| 17 | B16, the rest | api #37, then web #27 |
| 18 | B17 | api #38 |
| 19 | B13 | api #39 |
| 20 | B14 | api #40 |
| 21 | B15 | api #41 |
If a check fails, or GitHub says a PR can't be merged because of a conflict, stop there and tell me in this chat which step; I fix it on that branch and the ones after it.
3. Choose how the server scripts get their "fresh machine" proof (a decision for you). Gate 1 asks for the set-up script and releases to be proven on a fresh VM. So far they ran on the local Ubuntu test machine inside Docker, which behaves like a fresh server for these scripts but is not a VM. Reply in this chat with a, b or c:
- (a) Accept the Docker runs as the proof. The parts only AWS can show are proven at A-steps 21 and 22 anyway.
- (b) Recommended: let me install Multipass (free) on this Mac and repeat the runs on a real VM. About an hour, no cost, and Gate 1 is met exactly as written.
- (c) Approve a small AWS server for about an hour. A few cents, paid from the AWS credits, which the plan treats as real money.
4. The CTO signs off Gate 1 (a task for the CTO). Once 1 to 3 are done, the CTO writes their name and the date on the line "Gate 1 ticked by" at the end of Part B in the plan. Part A's AWS steps (A2, from A-step 16) start after that.
Later, not needed for Part B
| # | What | Kind | By when |
|---|---|---|---|
| 5 | How long posts and comments that people delete themselves are kept. Today they disappear from the site at once and their photos stop being shown, but the text stays in the database until the whole account is deleted, because the plan's §5 sets no time for it | Decision for the founder | Before the nightly clean-up is switched on (A5) |
| 6 | The child-abuse matching setting (D11). The plan says the server must refuse to start until the choice is set (a setting called KNOWN_ABUSE_PROVIDER), and Gate 2 depends on it. It isn't built yet | Decision for the founder (which service), then a build for me | Before Gate 2 |
| 7 | Alarm texts to your Indian phone number. India requires businesses to register text messages (DLT) before they can be sent; until then alarms arrive by email only | Task for you; I can look up AWS's exact steps when you get there | Before A-step 24 |
| 8 | Read the counts from the nightly clean-up's trial run on a copy of the pilot data, before it is switched on | Task for the CTO | After launch (A5) |
| 9 | The founder one-pager (the last part of B15), in plain words with the real numbers | Writing, by me | After Gate 3 |
Sources
notes/PRODUCTION-PLAN-2026-10-09.md: Part B (B1 to B17), Part A steps, §1 decisions, §2 costs, §4 releases, §5 keeping data, §6 the night window, C2 gates, C3 alarms.- thnkrr-api
docs/28-production-ready.md: the decisions with dates, the account facts, the alarms, the search speed test and the load test. - thnkrr-api
deploy/runbooks/(index inREADME.md) anddeploy/README.md. - The PRs: https://github.com/CerealNotFound/thnkrr-api/pull/ followed by the number (21 to 41), and https://github.com/CerealNotFound/thnkrr-web/pull/ followed by the number (18 to 27).
- Amazon CloudWatch pricing page (how alarm figures are counted).