Reading long tickets: remove the named third-party quote stripper Both pages cited Mailgun's talon by name and quoted a figure for how often it succeeds. The argument does not need it: every mail client marks a quoted chain differently, plenty do not mark it at all, and a forward can look identical to a reply - so any approach is wrong some of the time, which is the whole reason a wrong boundary has to cost a click rather than a fact. Quoting another project's failure rate is not something we want in our docs.
Login Screen Designer: the page the README has been linking to since it shipped Found while auditing which features have both a user and a developer page: the README links to Login-Screen-Designer and the page never existed. A broken link in the front door of the project. Login-Screen-Designer what it does, and how to get back in Login-Screen-Designer-Developer-Guide why it cannot be injected into The dev guide leads with the rule the whole feature exists to enforce — THE ADMINISTRATOR SUPPLIES VALUES, NEVER SYNTAX — and with the line not to cross: no custom CSS field and no custom HTML field, however often it is asked for, because every guarantee is void the moment one exists and it would be void for anyone who compromises an admin account, not just for the admin. Snippets are quoted verbatim and checked. The ones that teach something are the strict colour regex ("starts with #" is not validation — `#fff; background: url(…)` starts with # too), validation running at RENDER as well as at save so a value that arrived by another route still cannot reach the page, and the sprintf `%%` bug that produced valid-but-wrong CSS on the server while the preview, built without sprintf, produced the right thing — a preview disagreeing with the page being the one failure that design exists to rule out. The user page documents ?nobranding=1 prominently, because a safety valve nobody knows about is not one, and states plainly that it skips no authentication.
Reading long tickets: split into user + two developer guides, with real code Ed's ask: dev articles should carry actual code snippets of the important bits with explanations, and splitting into two dev pages is fine. Reading-Long-Tickets user-facing, no internals Reading-Long-Tickets-Developer-Guide the three automatic behaviours Ticket-AI-Reading-Developer-Guide the summary and the briefing Both dev guides open with the invariant Ed asked to be made explicit: NOTHING EVER DELETES CONTENT. Stated as checkable properties rather than a slogan — no DELETE or UPDATE of a body anywhere in either feature, the full body of every message including a flagged duplicate is in the JSON and the DOM, a refresh writes version n+1, and everything survives the feature being switched off. Verified by grep, not asserted. Both also name the one boundary honestly: stripInboundThread() at INGESTION stores only the new part of an inbound reply. Nothing on either page does that, but a developer chasing "where did the rest of the email go?" needs to be sent to the right file rather than left trusting a promise the system does not keep end to end. Every snippet is quoted verbatim from the source and checked (18/18) rather than written from memory. The ones that earn their place are the bugs that nearly shipped: measuring the shadow root instead of the host (zero-tall <style> as first child, so nothing would ever have collapsed, silently); reading nextElementSibling after appendChild has already moved the node; and the missing busy guard that made every click during a minute-long wait a fresh paid call.