Hardcode Consulting

Part of the formgate series. What formgate is around 1300 lines of Go across nine files, nothing outside the standard library. Part 1 covered the design decisions: why the emailed OTP had to go, why the sender and recipient come only from config, and how each pipeline step picks a failure direction. This part is the implementation. The whole pipeline lives in one HTTP handler, and the failure directions from Part 1 show up as concrete branches inside it. ...

What formgate is a single Go binary, nothing outside the standard library, one config file. It sits between static marketing sites and SMTP. A public contact form posts JSON to it; formgate decides whether the submission is worth an email, and if it is, delivers it. The mail path is never exposed to the page. It serves twelve sites right now. Why The OTP that amplified spam Static sites still need contact forms, and contact forms need mail. The question is how the form sends mail without putting SMTP credentials inside a public page. ...

What Lunchpad is a Python script that runs on a systemd timer and polls our Plane Postgres database every minute. It looks for deploy requests in task comments, works out which repository and branch they refer to, and performs the full sequence: fetch, merge, push, run the deploy script, and post the result back to the task. A comment like “deploy this to dev” on a Plane task is enough. The rest happens without anyone touching git. ...

Part of the Refresh Token Design series. The Fall-Through The verify endpoint took a six digit code and worked out what it was. If the account had an active authenticator and no emailed code was currently live, check the authenticator. If an emailed code was live, check that instead. It reads like a helpful convenience and it is the ceiling on the whole account. Anything holding a session at the lowest tier can make an emailed code live simply by asking for one. So an account with an authenticator enrolled was still, at any moment of the attacker’s choosing, an account that could be entered with a code from the inbox. ...

Part of the Refresh Token Design series. Two Correct Features Branching says a refresh that cannot prove its device gets a new row of its own, copying the device key from the row it came from, opening at the lowest tier. The honest case is a browser whose storage was cleared, and its road back is to prove a second factor, which rebinds the row to a fresh key. Per request signing says every request carrying a session must be signed by the device key on that session’s row. ...