Login Screen Designer: the logo has a maximum height as well as a width Documents the second logo setting, why one control cannot serve both logo shapes, and why both are maxima rather than fixed dimensions (a width with a max-height beside it distorts the image). Dev guide also records that the size control only ever worked on one of the three screens it was offered on - a hardcoded 250px on the portal sign-in page, and a later same-specificity rule winning on the landing page.
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.