session framework · decision artifact · 2026-08-15
You said you're not loving the discussion board as the place your decisions get documented — you'll decide in chat, and you want each decision page to carry a Decisions section at the top once you've ruled. That part is done and already in force (details below). This page brings you the three follow-on calls, with a recommendation on each: whether an "approve" button on the published page is worth building (short answer: on the public site, no — and here's the honest reasoning), whether there should be a single chronological log of every decision (yes — generated automatically, never hand-maintained), and whether the roadmap needs another tracker (no — it needs the surfaces it has to read from one source of truth).
“I'd like you to update the artifacts with a 'decisions' section at the top when I decide something.”
Resolved and implemented same day (this section is the shape it produced): when you decide something — in chat, in a thread, anywhere — the decision page gets a Decisions section at the top, before everything else, recording the date, where you said it, your words verbatim, which questions it resolves, and what happened next, with implementation links added as they land. The page's README and the decisions index move to "Decided" in the same commit. The rule is now part of the decisions-lane contract, binding every future artifact; the blockers-list page got the first such section today.
“I'm good with recs in https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-15-decision-recording/ File a requirement for a local 'decisions app' associated with the dashboard.”
All three calls adopted as recommended. No approve button goes on the public site — deciding in chat stays the lane, and the click-to-decide idea moves to your machine instead of the public page (call 1). The chronological log of every decision is built, live and derived — a generator reads the Decisions sections off every artifact at each deploy and assembles the Decisions page; the deploy now fails outright if an artifact the index calls decided carries no such section, so a missing decision breaks the build instead of quietly disappearing from the log (call 2). No new tracker is stood up; the roadmap's waiting-on-you list, the local dashboard, and the daily briefing all read from that one generated feed (call 3).
The local click-to-decide surface — the one variant this page said was worth building — is now filed as a requirement rather than a nice-to-have.
“will s-todo work here to surface my todo list? i also think the hub page needs an update. Let's work on that now. I basically want it to be my todo list with blockers included. Go ahead and work on the new page where you open decision artifacts in a main area and then have a sidebar where i can make decisions. Keep a persistent header. I feel like we want a new local only folder in the project to own the obs db. Let's call the local page the Operations Dashboard (or just dashboard) and call the public page with roadmap, news, etc the hub.”
This expands call 1 from "file it as a nice-to-have" into build it now, and it fixes the vocabulary. The Operations Dashboard is the local page on your machine; the hub is the public site carrying the roadmap, news and artifacts. The dashboard is not a decisions viewer with a list attached — it is your todo list, and the blockers (the hands-on-keyboard items) belong on it alongside the release candidates and the open decisions. Decision artifacts open in a main area, you answer in a sidebar, and a header persists across it. A new local-only folder in the project owns the observation store behind it, under the same storage reasoning the blockers list settled this morning: kept out of anything the deploy publishes, with a guard rather than discipline.
Filed as requirement #180, and the first working version was built the same day.
Everything on this page is now answered. The pages below are kept as the reasoning that produced those answers.
Three sentences. Decision pages now work well enough that you answer them in chat minutes after reading — but the record of what you decided has been living in a discussion board you don't enjoy using, one thread per decision, findable only if you remember it exists. Today you decided the record should live in the decision page itself; that is done and this page is written under the new rule. What remains is plumbing: whether the page itself could take your click, where the one-glance history of all decisions lives, and whether any of this needs yet another tracking surface.
You suspected this might be "too clunky in GitHub Pages." The suspicion is correct, and it's worth being precise about why, because the reason kills some options and spares one. A published page is static: it cannot write anywhere by itself. Every "approve in the doc" scheme is therefore really a scheme for where the click's write goes — and the site is public, so whatever receives that write must also know the click came from you and not from anyone else who opened the URL. That authentication requirement, not the button, is the real cost. The honest menu:
| Scheme | How it would work | Effort | What breaks |
|---|---|---|---|
| A prefilled GitHub link | An "Approve" button opens a new GitHub issue with the decision text pre-filled; you just press submit, signed in as yourself. | Hours. No moving parts. | GitHub only supports pre-filling new issues, not comments on an existing thread — so every click mints a new issue an agent must then sweep, close, and transcribe. And the final submit still happens inside the GitHub UI you're trying to leave. Cheap, but it recreates the board with extra steps. |
| A form posting to a small endpoint | The page posts your click to a serverless function that writes the decision via the GitHub API. | Days, plus permanent care and feeding. | The endpoint holds a write credential reachable from a public page, so it needs real login (an OAuth flow, session handling) to stop a stranger's click from becoming your signature. That's a small product, not a button — and it puts an approval-forgery surface on the public internet to save you one chat message. |
| A choice encoded in a link | Clicking "adopt all" puts your answer in a URL or clipboard string that you paste to an agent. | Hours. | Nothing writes anywhere — it's a ceremonious way to compose the chat message you would have typed anyway. Harmless, pointless. |
| The local dashboard (the one real option) | The same decision pages, served on your machine by the session dashboard's local server, get real approve/revise buttons — a local page can write, and a click there is necessarily yours because it's your machine. | Modest, and the pattern is already proven: the roadmap-audit work validated exactly this click-stage-submit loop on a local server this month. | Only works at your desk — no phone, no away-from-machine approvals. Those keep falling through to chat, which works everywhere. |
Don't build approval into the published site — "not worth it" is the answer there. Deciding in chat is already the fastest honest channel you have, and as of today the artifact records it durably. If click-to-decide ever earns its keep, extend the local dashboard's proven pattern to decision pages — that's the only variant where the click is cheap, authentic, and yours. File it as a nice-to-have, not now.
One place that answers "what have I decided, when, and where's the follow-through?" — today that requires walking the decisions index table or remembering eleven separate threads. The real question is not whether to have a log (yes) but who maintains it, because a log is only trustworthy if it cannot drift from the pages it summarizes.
Derived, at deploy time. One agent increment: the generator, a "Decisions" page on the site, and a deploy-validation line so a malformed Decisions section fails the build loudly instead of publishing a wrong log.
You wondered — "or maybe not." Taking a position rather than deferring: not. Count the tracking surfaces that already exist: the roadmap page (with its "waiting on you" section), the project board, the goals pages, the decisions index, and — proposed in the parallel session-model design — a daily briefing. Every one of them has drifted at some point precisely because each was maintained separately. The failure mode you're feeling is not "too few trackers," it's "the trackers don't share a source of truth."
No new tracker. Instead, the decision log's generated data (call 3) becomes the one source the existing surfaces read: the roadmap page's "waiting on you" section shows open decisions from it, and the daily briefing — whose design is in flight in the session-model artifact — takes a "decisions" line from the same data. That briefing design already proposes the surface where pending decisions reach you each morning; this page deliberately specs no competing surface, it hands that design its data feed. (the session-model artifact · its Q&A thread)