Boring technology, defended choices

Double-submission guards don't check and then insert — they insert against a unique index and let the database decide. Check-then-insert loses to the concurrent tap, every time, because each call is its own transaction.

And a replay asks rather than silently swallowing, because editing and resubmitting is a legitimate thing to do. The re-rendered form carries a fresh token, so its own double-tap is caught too.

One screen uses a server-side token for the case where a duplicate is permanent — a burned asset id that ends up painted on a van — and plain JavaScript for the case where a duplicate is merely untidy.

Consistency would have put the permanent case on JavaScript. The choice is made by failure mode, not by tidiness.

The job tracker has five filters, a card view and five preset chips — and no saved views, no per-user configuration. A query string is the view, a preset is a named link, and adding another one costs a label. Bookmarkable, pasteable, and there is no per-user state to migrate later.

A companion check runs at import: the app refuses to start if the six lifecycle phases ever stop exactly partitioning the fifteen statuses. A sixteenth status cannot quietly disappear from the board.

The platform hands us the revision identifier. Its presence simultaneously switches on a year-long cache lifetime for static files and appends the revision to every static URL the app generates. Not one template changed, and not one asset was missed.

The two halves cannot be separated — a long cache lifetime on its own would strand iPads on stale JavaScript for a year — so a test asserts they appear and vanish together. A new deploy means new asset URLs, which means a guaranteed cache miss, and the miss is the refresh.

Drive calls made while rendering a page run on a much shorter budget than Drive calls that write something — because a wedged render pins one of only four worker threads, and a tech staring at a spinner on cell signal is a support call.

The honest limit is written down next to it: a library default upstream makes the tighter budget a soft ceiling, not a guarantee. Recording that is cheaper than someone later discovering it and distrusting the whole note.

Some operations retry hard and then fail open; others try twice, briefly, and then refuse. Which posture applies is chosen per path by what a wrong answer costs. Refusing on a read failure is right where a mistake writes a payroll record; it is wrong where a mistake merely blocks the button that creates a customer in QuickBooks over one flaky minute.

Constraints make half-set rows impossible: a person record must attach to a company, a "waiting" record must carry a reason, a completed record must carry a completion date. A partial unique index enforces one pending signature request per job and document.

One constraint reads "zero or more" rather than "greater than zero", and the comment explains why: a baseline reading of zero is a brand-new machine. The same lesson bit us elsewhere — one shared validator was correct for an interval and wrong for a baseline, and stayed invisible for three slices because its error message was about intervals too. The fix was to split it, not to add a flag.

To prove every web address is locked to the right kind of user, the test parses the guard out of the source text, dispatches the real route, and asserts the two agree. The obvious alternatives were rejected on the record: reading the guard off the running function proves only that the route carrying the guard carries the guard, and a hand-maintained table of expected answers is the same author discipline moved one directory away.

It also states its own limit. It proves the routes are gated as declared; it says nothing about whether the declarations are right. The only evidence for that is a hand-check — and the slice wrote down that the hand-check does not renew itself.

Every sign-in to DUDE is checked against a signed claim that the account belongs to our Workspace domain. One domain-locked door is what makes every screen behind it safe. Adding a client login would make each screen's safety depend on which door the request came through — across everything ever built.

So the client portal is a separate repository with a separate deploy. The reasoning is mechanical, not philosophical: this project deploys its working tree, so code living together rides in each other's production images, and with no continuous integration the repository boundary is the only isolation that cannot be crossed by accident. The conditions that would reverse the decision are written down beside it.