The build journey

The premise. The plans held an organisation's products inside one Accounts and organisations module, at accounts.tutelora.app. The Architect stopped the work to clarify: an architecture like Atlassian's, with a central account at id.tutelora.com, each product keeping its domain, organisations registered with no product information, and a dedicated subscription subsystem.

What was found. Atlassian's own pages bore that out, with detail: it runs organisations apart from id, signing up for an app creates an organisation too, and what's sold, what's running and who may use it are separate concerns. In Atrium almost nothing had to change, because tenant already had no product columns. The cost is in the products, above all Campus.

The plan. reji/plans/2026-11-06-IA-identity-architecture.md. The spec is unedited, because its diagrams show the old design too; reji/docs/spec-amendments.md records what overrides it.

The premise. The spec sets an order for the modules and gives its reasons. Asked to justify that order, the honest test was whether its reasons hold against what the products have actually built, so the apps were read before a word of the justification was written.

What was found. Most of what the spec describes already runs in Campus: phone sign-in by SMS code, phone-only accounts, about 4,600 lines of SMS with wallets and sender IDs, a chain of mail providers, vouchers, three payment gateways. So most of Atrium is extraction from a live product, not new work.

How it was checked. An agent surveyed the apps; the claims that decide the order were then read by hand in each app's code, with file and line in the plan. The system map's data was checked by script: every flow node and edge points at something real.

The plan. reji/plans/2026-11-06-M00-atrium-master-plan.md.

The premise. Step 0 of the spec's build plan evaluates TuteCore against what a shared platform needs. TuteCore was built for apps people use, and Atrium's main users are other apps.

What was found. Of the twelve items, none ships as it stands: seven are part-way and five missing. An API token must belong to a person and a membership, so a product's server can't hold one. Every route answers on every host, so tutel.ink would serve the login page. An account reaches a membership only while the two hold the same e-mail.

The plan. reji/plans/2026-11-06-AF-atrium-foundation.md, drafted and not approved. Later that day the Architect set the rule that the TuteCore repository isn't changed, so everything here is built in Atrium.

The premise. Atrium starts from TuteCore. The first step was a clone of tutelora/core, but TuteCore's own runbook says a new app starts from a tagged release: its history stays its own, and with the clone's origin still pointing at Core, a plain push from this folder would have gone into the starter pack.

The premise. Before anyone can pay, Atrium has to know what each product sells, for how much, and what each offering allows; and, as the Architect asked, nobody pays for a product until its billing is switched on, unless the company agrees otherwise with one organisation.

The plan. TB2: paying through Paystack’s hosted page, with the billing role’s pages at id.

The premise. With Clavis built, the next module was Tabula: how the company charges its own customers. Its discussion opened with what it is, what stays in the product, and how things carry on if Atrium is away.

The plan. Plan TB §6.1: six slices, TB1 to TB6.

The premise. Plan IA asked for a security assessment before id is first deployed, because one breach of it would reach every product. With every slice of Clavis built, it was time.

The plan. reji/docs/SECURITY_ASSESSMENT_ID.md: its Priority 1 is the next work on id, before it's deployed.

The premise. Products keep their own roles (CL-16), so they need to add people, know them, and know when they leave, without Atrium learning what each person does inside them.

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md §6.1; next, CL9, the docs and the security assessment of id.

The premise. The Architect chose Google, Microsoft and passkeys for the first version (CL-10). They had to fit the rules already set: one account per person, and nothing that makes an account by the back door.

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md §6.1; next, CL8, the products' side of the API.

The premise. With sign-in, products and organisations in place, a person needs somewhere of their own at id: to get to their products, manage how they sign in, see where they're signed in, and make an account a school set up for them their own.

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md §6.1; next, CL7, Google, Microsoft and passkeys.

The premise. A school that uses portal.jaeda.edu.gh for Campus mustn't be able to point the same name at Loop, and an address nobody has proved must open nothing.

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md §6.1; next, CL6, the account and organisation pages at id.

The premise. Someone new arrives from a product's "Start free" with nothing: no account, no organisation. They should leave with both, and the product running, without being asked anything the product already tells us.

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md §6.1; next, CL5, addresses.

The premise. The proof showed Passport with a thin layer of Atrium's own could sign one person into products on different domains. This chapter made it Atrium's, to the house rules.

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md §6.1; next, CL4, joining and organisations at id.

The premise. With accounts free of e-mail, the door has to take whatever a person holds: a phone, an e-mail or a username, in one field, and never say whether an account is behind it.

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md §6.1; next, CL3, Atrium as the products' OIDC provider.

The premise. Everything in Clavis stands on one change: an account that needs no e-mail, no password and no organisation. It changes the core model, so the house rule applied: every surface listed, the list agreed, then one pass.

The plan. reji/plans/2026-11-07-CL1-accounts-audit.md; next, CL2, signing in by phone, e-mail or username.

The premise. With the decisions made and sign-in proved, Clavis was drawn: every way in at id, a person's own account, joining, running an organisation, and what a product shows, including Atrium being unreachable.

How it was checked. Every state was opened in light and dark and at phone width; none scrolls sideways, and no word a person reads says "Atrium".

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md §5 and §6.1: nine slices, starting with accounts that need no organisation.

The premise. Clavis rests on one thing nobody had run on this stack: Atrium acting as an OpenID Connect provider for products on their own domains. Plan IA said to prove it before drawing anything, because a failure would change Clavis's shape.

What was weighed. Two ways, on one throwaway branch with its own database, judged by the same nine checks. A: Passport with jeremy379/laravel-openid-connect, about 1,360 lines. B: Passport with a thin layer of Atrium's own, about 220 lines on Passport's hooks.

The plan. reji/plans/2026-11-07-CL-P-oidc-proof.md. Next: Clavis's mockups.

The premise. With the send path built, Clavis was next: one key for every product. Plan IA had settled its shape, so the discussion was about what IA left open.

What was weighed. The Architect questioned three of the recommendations. On roles: Atrium should know nothing of a product's roles. That overturned two recommendations which had quietly needed it, how strong a sign-in must be and who may add people, and both now sit with the product. Atrium keeps only that someone is in an organisation, and three roles for running the organisation itself. On contact numbers: a person's own proven numbers are identity, while what a school types about someone is not, since a clerk's typo would otherwise attach a stranger's phone. On custom domains: one list in Atrium, with the product still serving the traffic, so an outage can't take a school's website down.

The plan. reji/plans/2026-11-07-CL-clavis-accounts.md. Next: a throwaway proof of OIDC on this stack, then the mockups.

The premise. Clavis can’t land without SMS, because Campus’s phone sign-in sends its codes that way. So the first module after the foundation is the smallest part of the company post office: one text, its receipt and its count.

What was weighed. A webhook settles a text once Atrium knows the provider’s ID for it, and a timed-out send has no ID. So unknown stayed, narrowed: a report that matches no ID is matched by number within an hour. It’s never retried and never called failed, since either could double-text or misreport. Campus’s own code refunds a timeout, which is the fault left out.

How it was proven. A test for each driver answer, each state, a retry counting once, a code in no log, another server hearing nothing, and an outside client never going out under the company’s name. Every page was looked at in light, dark and at phone width, and switching provider ran through the real password step. Not proven: no real provider has been called, and nothing calls Atrium yet.

The premise. With the foundation built, it needed a home: a repository, something keeping it up here, and a place to stage it.

What was weighed. cPanel has no Redis and no supervisor, and Campus already solved that: the scheduler starts a worker each minute. Reusing it took one setting. What staging can't show, separate workers and real load, waits for the VPS. The one thing that could stop it is PostgreSQL: Atrium needs 15 or later with pg_trgm, which has to be confirmed on the host.

How it was proven. The agents were bootstrapped, the server was killed and came back on its own, and real mail went through the queue worker.

The premise. The Architect approved the mockups, which opened the gate. The plan's order held: the inherited foundation strengthened first (C1 to C4), then Atrium's own (A1 to A7).

What was built. Worker pools; idempotency keys reserved before a request runs; signed webhooks on the mail engine's catalogue; request IDs through logs, jobs and outbound calls. Then the name, three hosts, the client's record and what it holds, server keys and the first /v1 call, metering and server reports, and the console from the approved mockups, carrying their stylesheet across so the pages match.

How it was proven. 767 tests, 3 skipped, with one running from a product's signed call to the console's figures, and every page looked at in light, dark and at phone width. Not proven: nothing has run on a server, and no product calls Atrium yet.

The premise. Nuntius could send one text; the spec wants a post office: a school’s free texts, then credit it buys, a fee reminder to 600 parents paced to the networks, its own sender name, products’ e-mail from their own domains, and an address that bounces known to every product.

What was found. Campus, Desk and Loop were read first, and their faults checked in the code: in Campus a school could never buy credit (the top-up has no caller), a bulk send was one job sending one number at a time with no pacing, and its SES endpoint would take forged complaints from anyone’s topic; Desk records bounces but never stops a send while its pages say it does.

The plan. Bulk sends paced to the networks, sender names, products’ e-mail and the shared block list (NU3 to NU6).

The premise. Nothing new for anyone to use: what must be true before Atrium is first deployed. id’s own assessment had said it wasn’t ready (no Content Security Policy, uploads served beside the session, no fresh proof before an organisation’s addresses, products or people change), and nobody had yet assessed Atrium as a platform.

The plan. The first deployment waits on the Architect’s cPanel account and DNS. Next in the build: Nuntius’ rest.

The premise. The Architect: “Take over go autonomous. decide the build order and only pause if you need some input from me.” The order and each module’s decisions became Claude’s, still written into the plans and drawn as mockups so they can be read afterwards; the pauses are kept for facts only the Architect holds and for anything outward or irreversible.

The plan. Next, what must be true before the first deployment: id’s Priority 1, and an assessment of Atrium’s own risks.

The premise. TB-22: a chargeback leaves the plan running until the bank decides; the Service defends or accepts; lost, the period ends, a credit note follows, the card is dropped and the organisation hears the outcome, never the dispute.

The plan. Money back is built. Before live money: Paystack’s dispute resolutions confirmed with test keys, and withholding’s review step (Priority 2). The next module waits for its discussion.

The premise. A refund that leaves its tax invoice standing tells the GRA the money is still with the company. TB-20 asks for a credit note once the money has gone, never before, so a refund that fails never leaves a paper to undo.

The plan. TB9: chargebacks, and the money paths reviewed again.

The premise. The review’s first priority was the paths that take money back. The Architect chose to build them before the next module, and decided TB-17 to TB-22 as recommended: the Service alone gives money back, choosing each time what happens to the plan; the amount is suggested and only lowered; a credit note follows only once the money has gone; a wallet Paystack can’t reach is paid by hand and recorded; a chargeback leaves the plan running until the bank decides.

The plan. TB8, credit notes: their own count, issued once the money has gone, cleared through E-VAT. Then TB9, chargebacks, and the review again.

The premise. Code that moves money should be read, before it moves any, by a reader with no stake in how it was built, and every claim that reader makes should be checked against the code before it’s believed.

The plan. Tabula is built. Next, the Architect’s: the facts only they hold (prices, the VAT registration, E-VAT access, live Paystack, the terms), and the priorities the review left.

The premise. Everything built so far waits behind one switch per product. Turning it on must be impossible until the law and the terms allow it, must give every organisation fair notice, must reward those who came first, and must charge nobody a day early.

The plan. TB6: the docs, and a security review of the webhook, the gateway and the invoices.

The premise. Ghana’s law wants every tax invoice issued through the GRA’s own system, with its mark and QR on the paper, and lets a school pay net of what it withholds. A school must still get its paper the moment it pays, whether or not the GRA answers, and a correct deduction must never read as an underpayment.

The plan. TB5: switching billing on for a product, with its notice and founding price.

The premise. A paid plan has to renew without anyone remembering to: a card charged on the day, mobile money reminded in time, a slow payment given its grace, and only then Free, with nothing deleted. And none of it may count against a school while Atrium itself was down.

The plan. TB4: tax invoices and receipts, cleared through the GRA’s E-VAT.

The premise. An organisation’s owner, or the person who pays its bills, should be able to choose a plan and pay for it without Atrium ever touching a card, and a payment must count exactly once, though Paystack can tell Atrium three ways and none of them is certain to arrive.

The plan. TB3: renewals and lapses, with the organisation’s Billing page and the year as a ribbon.

The premise. Everything Atrium does is for products that can’t yet reach it: none signs anyone in through id, hears a webhook or calls /v1. The Architect asked for the client library, and set a rule for the session: Atrium only, and every change another product needs written down for after Atrium is deployed, one product at a time.

What was weighed. Its own repository or a folder in Atrium’s: a folder, proved where its other half lives, its own repository when the first product installs it. A framework package or a bare client: the products are all Laravel 13, so a package that wires itself saves each one the work. How a product ends a session Atrium ended, when Atrium never sees the person’s browser: a row per session, keyed by id’s sid, checked on every page. Whether the recheck fails open or closed: open, so Atrium being away signs nobody out; a definite answer still ends it.

The plan. Atrium deployed (A8 waits on the Architect’s cPanel account and DNS); then each product joins through Legatus, from its own folder, by the register. Tutela, Aerarium and Lector wait for their triggers.

The premise. A voucher is money in a parent’s hand, so before any school sells one, someone who didn’t write Tessera should try to break it: the plan’s last slice, as for Nuntius.

What was weighed. One review or two: two, in parallel, one of redeeming and one of batches with the console, each given the intent and the files but not the author’s view of them. Each finding was checked in the code before it was believed. And the hourly ceiling on misses, whether to stop everyone once it trips or only those who missed: only those who missed, so a guesser can’t shut out parents who type a right code.

The plan. Tessera is built. What follows waits on triggers: the client library when a product connects its server, then Tutela, Aerarium and Lector, each when it’s needed. Waiting on the Architect: Campus’s payment fault, tutel.ink’s DNS, and the SES set-up.

The premise. A school sells admission vouchers, online to a parent who has just paid and on cards a bank sells over the counter; one day GWCL may sell its own. The code is the money: whoever types it gets what it grants, once. Campus already had vouchers, and reading them first found what not to copy. A code was checked outside its transaction and marked used without a condition, so two people could spend one. Guessing was unlimited, behind a public prefix and answers that confirmed a code existed. Lower-case codes always failed. Codes sat in plain text in the table, the e-mailed link and the logs. In passing, a worse fault in Campus’s payments: anyone signed in can mark any pending payment paid.

What was weighed. How long a code: twelve characters from 31 with no look-alikes, about 59 bits, so the lock-out isn’t the only thing between a script and a parent’s money. What the check character should be: Luhn, at first. Whether issuing goes behind the shared idempotency store: no, because it keeps the whole answer, code and all, in plain text, so the same reference gives the same code back from an encrypted copy instead. How to print 50,000 codes: dompdf builds the whole document in memory, so the cards are a PDF written by hand, streamed a page at a time.

The plan. A fresh reader’s review of Tessera’s code paths (TE4). Campus’s payment fault is for the Architect.

The premise. A fee reminder’s link is longer than the text it rides in, and a 160-character text costs money for every part it runs to. The spec’s answer is tutel.ink: short links, trusted because they only ever lead to a school’s own pages. No app had built it: Campus, Desk and Loop all send full addresses.

What was weighed. Where a link may go: “any Tutelora domain” against the calling product’s own addresses and the school’s verified ones, the narrower, so one product can’t point a link at another’s pages. A 301 against a 302: the 302, so turning a link off works even for someone who tapped it before. Counting every fetch against counting taps: WhatsApp and iMessage fetch a link to draw its preview, and that isn’t a parent.

The plan. tutel.ink’s DNS waits on the Architect. Next in the build order: Tessera, vouchers.

The premise. Nuntius now spends money, the organisations’ on texts and the company’s on codes, and sends in volume. Before anyone is charged, someone who didn’t write it should try to break it: the plan’s last slice.

What was weighed. One review or two: two, in parallel, one of the money and one of the sending, each given the plan’s intent and the files but not the author’s opinion of them, so neither read was anchored. Every finding was then checked against the code before it was believed.

The plan. Nuntius’ rest is built; WhatsApp and inbound replies wait for Desk. Next in the build order: Tutelink, the short links.

The premise. An address that bounces, a parent who marks a school’s e-mail as spam, or one who just wants the reminders to stop: each must be honoured by every product, or one product’s carelessness spoils every product’s sending. Campus took bounce reports from anyone’s SNS topic, so anyone could silence any address; Desk recorded bounces and sent anyway.

What was weighed. Keying the list to an account or to the address: the address, since most parents have none. Unsubscribing on the link’s first open, as the mockup drew it, or asking first: asking, because mail scanners open every link and would unsubscribe people who never chose to; a mail client’s one-click still acts at once. And whether an erasure takes the list with it: no, a suppression list is how someone is never written to again.

The plan. A fresh reader’s review of the money and send paths (NU7), then Tutelink.

The premise. Products send e-mail of their own: fee reminders, receipts, reports. Sent each from its own servers, a bounce or a provider’s outage stops one product while another works; sent from one shared address, one product’s complaints harm them all. Campus had a chain of mailers with quotas; nothing else did.

What was weighed. Editing mailers and their keys on the console against keeping them in the environment, as every mailer’s credentials already are: the environment, with the chain and each mailer’s month shown on the console. SES through its SDK against its SMTP interface: SMTP, so nothing new is installed. Templates for products against their own words: their own words, as texts already move, until a product’s wording needs to live here.

The plan. The shared block list: hard bounces and complaints from SES through SNS with its topic allow-listed, and unsubscribing with one click (NU6); then a fresh reader’s review (NU7).

The premise. A parent trusts a text from “JAEDA SCH” more than one from a company they’ve never heard of. Each SMS provider registers a name by hand, takes days, and sometimes refuses; Campus recorded the names but no school could ask for one, and nobody could see where a request stood.

What was weighed. One request with one state hides that one provider registered the name and another refused it; a row per provider tells the truth. Switching to a new name at once would put texts under a name no provider has approved; keeping the old one until the new one is registered with that provider never leaves a gap.

The plan. Products’ e-mail through Nuntius with a provider chain (NU5), then the shared block list and unsubscribing (NU6), and a fresh reader’s review (NU7).

The premise. A school sends a fee reminder to every parent at once. Campus did that as one job sending one number at a time, with no pacing, no progress and no stop, and a timeout half-way could lose the record of texts already sent. The Architect also settled the money for now: no prices yet, the pilot is free, everything in it complimentary.

What was weighed. Pacing by counting a second’s worth and then waiting let two half-seconds bunch together, and a slow answer was made up with a burst; spacing each text a fixed gap after the last never does either. A send in one job could die mid-way and resend; a cursor written before each text means a run that dies resumes after it, and the text in flight is marked unsure rather than sent twice.

The plan. Sender names asked for at id (NU4), products’ e-mail through Nuntius (NU5), the shared block list and unsubscribing (NU6), then a fresh reader’s review (NU7).