A note is one thing that broke and the rule left over from it. Deliberately short: if it needs more than three hundred words, it becomes a case study.
Opened in August 2026, all at once. The first five already existed, buried inside the case studies where nobody who did not open the whole page would find them. They are here in short form, with the source cited. From here on this is where new things show up, without redesigning anything.
Didata
Infrastructure
The pooler that hangs instead of failing
Seven deploys in a row died at the 45-minute timeout, with no error message. The cause was the Postgres transaction pooler, which is the right connection for serverless runtime and the wrong one for migrations: it does not support migrate deploy's long DDL transactions, and the command hangs instead of refusing.
The runtime URL and the CLI URL are two variables, not one. And the same variable has to exist on the platform and in CI secrets, because CI runs the same build.
Raising the Server Action body limit broke the build with a type error, and only on the platform's own infrastructure: the local build did not reproduce it. It took about six hours of bisecting to isolate, and the outcome was not being able to raise it.
So the limit stayed at the 1 MB default, no Server Action can take a file, and every upload in the product is a route handler. A whole architecture rule was born from someone else's bug that was never fixed.
A workaround is not a design. It is worth writing down which of the two it is, because whoever arrives later cannot tell, and one day the bug goes away and the rule is left with no reason.
RLS in the database or authorisation in the application
Two of my products, on the same Postgres, with opposite choices. The CRM has 133 row-level-security policies over 29 tables: the database refuses the row, whatever happens in the application. Didata authorises in the application.
The difference is not maturity, it is how many doors exist. The CRM is reached by a dashboard, by a 70-tool MCP server, by token-based public pages and by scheduled jobs. Four doors, and the rule written at each one would be the same rule written four times, drifting apart at the first rush. Didata has one door.
Count the doors before choosing where the rule lives. One door, the application is enough and costs less. More than one, the rule goes down into the database, otherwise it becomes several rules.
The model returns one alternative per question plus a confidence score from 0 to 100. Writing the grade straight through above a threshold would be trivial, and the system does not: suggested and confirmed are distinct states in the database, and the report card only counts what the teacher confirmed. Including the high-confidence ones.
It costs a lot in convenience: an exam of 30 students by 10 questions is 300 readings to accept. The mitigation was not to loosen the rule, it was to make accepting cheaper, with batch confirmation and a queue that surfaces what needs attention. The queue's bias is declared and errs toward caution: a question with no reading at all counts as uncertain.
When the rule hurts, the way out is to lower the cost of obeying it, not to open an exception. The first exception is the one nobody can explain six months later.
On the day of connecting the panel to production, requests hung forever. The server's RPC framework has two independent transports, and the resource I was calling had only registered one of them. The event went out and nobody was listening. No error, no timeout, no log.
The fix was one line. The diagnosis was not, because a silent failure does not tell you where to look, and I had tested each side on its own: both passed.
A seam bug does not show up when you test the ends. Before migrating thirteen screens, one smoke test crossing the whole stack, from HTTP down to the database, just once.