A way to write to the board from the browser

Two wants, one underlying problem:

• A comment box at the bottom of a ticket, so a question raised in a ticket can be answered where it was asked instead of in chat.
• A one-line input on /current-projects to open a ticket — "look into building out ai news page, and naming convention for articles" — so work starts from a ticket rather than getting one written afterwards.

Both are the same feature underneath: write to the board from a browser, as Michael and nobody else.

What makes it awkward

The board is files in git, and that is not incidental — "moving a ticket means editing the file and committing it, so the board and the history of how it got this way are the same object." Every page is statically prerendered at build time. There is no database, no session, no login, and the only server code on the site is one read-only weather proxy.

So a comment box needs three things the site currently has none of: somewhere to put the text, a way to know it is Michael typing, and a way for the change to reach a page that was built minutes ago.

Options, roughly in order of how much they cost

1. GitHub Issues as the comment store. A ticket page links to, or embeds, an issue thread. Auth, identity and history are GitHub's problem. The board stays files; the conversation lives next to the commits. Costs a round trip to another site, and the comments are not really on scofti.com.
2. A commit-backed form. The box posts to a route handler that commits the comment into the ticket's .mdx via the GitHub API and lets the push redeploy. Keeps the "board and history are the same object" promise exactly. Needs a token and a single-user auth check, and a comment takes a deploy to appear.
3. A small datastore. Comments in a KV or Postgres, read at request time on the ticket page. Comments appear instantly and the ticket page stops being fully static. Breaks the promise above: the board's state would live in two places.
4. Local-only authoring. No web UI at all — a CLI or a dev-only form that writes the file directly. Nothing ships to production, nothing needs auth. Solves the ticket-creation want, not the answer-a-question-from-anywhere one.

Not yet decided

Which of these, and whether comments belong in the ticket file itself or beside it. Worth settling before any of it is built, because 2 and 3 pull in opposite directions on what the board is.