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.

Since this was written

Two of the three missing pieces now exist. The site has a session and a login — the holocron is password-gated, the cookie is checked server-side, and there are already API routes that refuse a request without it. So "a way to know it is Michael typing" is solved; it is the same gate the drop uses.

That leaves somewhere to put the text, and getting it onto a page that was built minutes ago. Option 2 is the one that got cheaper.

A look to keep in mind

assets/references/board-checklist-look.png — a checklist Michael had built on another project, kept here as a reference for how it reads, not as a model for how it works. Nothing about its implementation applies.

What is worth taking from it:

• Filter pills carrying live counts, so the shape of the work is legible before reading a single row.
• A status control on the row itself, rather than a column a ticket has to be moved between by hand.
• A build stamp at the top, naming which deploy the list is being judged against — a ticket in QA only means something against a specific one.

The question it raises is the one this ticket already asks. A dropdown implies anyone can change the state, and the board's state is a committed file. The shape Michael floated: the page renders flat for everyone, and the controls appear only for a request carrying the holocron session — the same reader sees a different page depending on whether the site knows who they are.

It is deliberately not stored in public/. The reference is a work screenshot carrying another company's ticket identifiers, and this ticket's own page is public.

Closed October 1, not done

Pushed out. Nothing above was built: there is no comment box and no input on /current-projects, and the board is still written by editing files. Which of the four options, and where comments would live, is as undecided as it was.