kit-46-standalone-hub: A hub that runs on its own (devteam.mjs hub), and dashboards that leave the hub to the image when its ENV says so

README.md

@@ -41,7 +41,7 @@ docs/devteam/
 
 **What matters most.** The supervisor judges each goal's impact against the project's strategy and rates every question it asks (how much rides on the answer, how soon, and which other questions an answer would settle). The kit counts the rest (tickets held up, a default) and orders the Inbox from it, with the next best step on top and the reason on every card; `devteam.mjs next` prints the same. The order is computed on every read and stored nowhere. The owner corrects a goal's impact with their own value, and it stands.
 
-**Many projects, one machine.** Each project has its own tmux session (`devteam-<project>-<6 hex of its path>`, saved in `run/tmux-session`) and its own dashboard port: the next free one in 4321–4345, saved in `run/dashboard-port` and reused. Any running dashboard also serves the hub at http://127.0.0.1:4320: a tab per instance on the machine (its name, with a badge when its Inbox has something), that instance's own dashboard under the selected tab, and one "Notify me" for new Inbox items across all of them. It opens on its **Overview** tab: a card per project saying whether it is building, moving, fully blocked on your answers (or partly: some tickets wait, the rest can move), stalled, idle or parked, with its kit version (amber when behind the newest one running here), Inbox count, workers, the goal it is on, tickets merged of planned, what needs you, and twelve weeks of commits on main (in every repo the project spans), laid out like GitHub's contribution graph. Each card has **Run**, **Drain** and **Park** for that project's fleet, and the page has **Park all** and **Resume all**; Park asks twice. The hub's server does nothing in any project: for Run, Drain and Park the page asks that project's dashboard, in its frame, and the dashboard does it as a click there would, for its parent page only. The Overview also has the dashboard's **Threads** dock, and there every thread is with the machine's **operator** (`process/operator.md`), the session that looks after the machine and not a repo: start one from the dock, or hold Shift and click a card, its name, a stat, a line that needs you or the headline (**Pin** does the same for a finger), and a numbered pin stays on what it is about. This is the one thing the hub's server keeps and the one thing it does: the threads are in `~/.devteam/operator/threads.jsonl` (on a box, `~/operator/threads.jsonl`), each of your turns is typed into the operator's session as one line marked as yours by way of the hub, and the operator answers with `operator-thread reply`, which the open card shows as text. On a laptop there is no operator until you write to one: your first message, or **Start the operator** in the dock, starts it in a tmux session of its own (`devteam-home`, window `operator`; `tmux attach -t devteam-home`), with this project's `agent_command` (or `DEVTEAM_OPERATOR_COMMAND`), `DEVTEAM_ROLE=operator` and `operator.md` as its prompt, and never a second one. The first time, Claude Code asks whether to trust that folder, and nothing answers that for you: the reply to your first message says so, the dock says the operator is at a dialog, and you answer it in that session. The session is the operator's whatever its window is called, and when tmux doesn't answer the hub starts nothing. A thread is talk with the operator, never an answer to a question: decisions stay in each project's Inbox. Each dashboard, served by its own repo's kit, stays on its own address inside the hub's frame, and may be framed only by itself and the hub, so whatever is served at the hub's address can steer every fleet on the machine: an owner who finds something else on port 4320 should not open it (a dashboard notes it in `run/dashboard.log`). A dashboard answers only on the address it serves (`127.0.0.1` and `localhost`, or the `--host` it was started with), and the hub only on its own: a page elsewhere gets nothing, not even a read, and the hub takes a thread turn only from its own page (the browser's `Origin` and `Sec-Fetch-Site` must both say so). That keeps other sites out, not other programs: on a laptop anything running as you can post to the hub or to a dashboard, or type into a tmux pane, your own fleets' sessions included, so the operator reads a thread line as it reads its terminal and confirms with you anything only you may do. On a box you are never on the machine, and every agent runs as the hub's own user, so the hub takes a thread turn there only when the box's gateway signed it, with a key only the gateway's own user can read; anything sent from the box itself is refused. The operator checks each turn with `box-thread show`, which says which ones the gateway signed, and still confirms with you, in its own window, anything only you may do: an agent there can still type into its terminal. The same goes the other way: any agent there can write a reply as the operator's, so read the operator's replies as a report, as you read an alert.
+**Many projects, one machine.** Each project has its own tmux session (`devteam-<project>-<6 hex of its path>`, saved in `run/tmux-session`) and its own dashboard port: the next free one in 4321–4345, saved in `run/dashboard-port` and reused. Any running dashboard also serves the hub at http://127.0.0.1:4320: a tab per instance on the machine (its name, with a badge when its Inbox has something), that instance's own dashboard under the selected tab, and one "Notify me" for new Inbox items across all of them. On a laptop the hub is whichever dashboard took the port first; `devteam.mjs hub` serves it alone, retrying while anything else holds the port (its log is `~/.devteam/hub-4320.log`). On a box whose image sets `DEVTEAM_IMAGE_HUB`, the image's own kit serves the hub and dashboards don't: a dashboard on this release or later leaves the port alone, and says so in `run/dashboard.log`. The gap left is a project still on an older kit, which can take the port in the moment the image's hub restarts, until that project adopts the release. It opens on its **Overview** tab: a card per project saying whether it is building, moving, fully blocked on your answers (or partly: some tickets wait, the rest can move), stalled, idle or parked, with its kit version (amber when behind the newest one running here), Inbox count, workers, the goal it is on, tickets merged of planned, what needs you, and twelve weeks of commits on main (in every repo the project spans), laid out like GitHub's contribution graph. Each card has **Run**, **Drain** and **Park** for that project's fleet, and the page has **Park all** and **Resume all**; Park asks twice. The hub's server does nothing in any project: for Run, Drain and Park the page asks that project's dashboard, in its frame, and the dashboard does it as a click there would, for its parent page only. The Overview also has the dashboard's **Threads** dock, and there every thread is with the machine's **operator** (`process/operator.md`), the session that looks after the machine and not a repo: start one from the dock, or hold Shift and click a card, its name, a stat, a line that needs you or the headline (**Pin** does the same for a finger), and a numbered pin stays on what it is about. This is the one thing the hub's server keeps and the one thing it does: the threads are in `~/.devteam/operator/threads.jsonl` (on a box, `~/operator/threads.jsonl`), each of your turns is typed into the operator's session as one line marked as yours by way of the hub, and the operator answers with `operator-thread reply`, which the open card shows as text. On a laptop there is no operator until you write to one: your first message, or **Start the operator** in the dock, starts it in a tmux session of its own (`devteam-home`, window `operator`; `tmux attach -t devteam-home`), with this project's `agent_command` (or `DEVTEAM_OPERATOR_COMMAND`), `DEVTEAM_ROLE=operator` and `operator.md` as its prompt, and never a second one. The first time, Claude Code asks whether to trust that folder, and nothing answers that for you: the reply to your first message says so, the dock says the operator is at a dialog, and you answer it in that session. The session is the operator's whatever its window is called, and when tmux doesn't answer the hub starts nothing. A thread is talk with the operator, never an answer to a question: decisions stay in each project's Inbox. Each dashboard, served by its own repo's kit, stays on its own address inside the hub's frame, and may be framed only by itself and the hub, so whatever is served at the hub's address can steer every fleet on the machine: an owner who finds something else on port 4320 should not open it (a dashboard notes it in `run/dashboard.log`). A dashboard answers only on the address it serves (`127.0.0.1` and `localhost`, or the `--host` it was started with), and the hub only on its own: a page elsewhere gets nothing, not even a read, and the hub takes a thread turn only from its own page (the browser's `Origin` and `Sec-Fetch-Site` must both say so). That keeps other sites out, not other programs: on a laptop anything running as you can post to the hub or to a dashboard, or type into a tmux pane, your own fleets' sessions included, so the operator reads a thread line as it reads its terminal and confirms with you anything only you may do. On a box you are never on the machine, and every agent runs as the hub's own user, so the hub takes a thread turn there only when the box's gateway signed it, with a key only the gateway's own user can read; anything sent from the box itself is refused. The operator checks each turn with `box-thread show`, which says which ones the gateway signed, and still confirms with you, in its own window, anything only you may do: an agent there can still type into its terminal. The same goes the other way: any agent there can write a reply as the operator's, so read the operator's replies as a report, as you read an alert.
 
 **Artifacts.** Any session can draw an artifact, a page that shows the owner an idea instead of describing it: a UI mock, a flow, a mock docs site, a 3D model. It lives in `project/artifacts/<slug>/` and lands with the PR it was drawn in; the dashboard's **Library** lists landed ones and live drafts from every worktree beside the link registry, and opens each in a centered viewer or its own tab. An artifact loads its own files and pinned libraries from cdnjs, jsdelivr and unpkg, runs sandboxed with no other network and no reach into the dashboard, and sends nothing back: a decision on one is a question that links it, by name and inline (`[[name]]`). The owner can ask for one ("draw me a mock docs site"), and planners draw them for any goal with UI or a flow. `devteam.mjs artifact new|check`, `artifacts`. On a cloud box the owner can also publish a landed artifact to anyone, at `public.box.example.com/<project>/<slug>/` (below).
 

docs/devteam-dev/tickets/kit-46-standalone-hub/baseline-box.txt

@@ -0,0 +1,23 @@
+Baseline on the cloud box at main 5c2a77b (no code change yet), 2026-11-14, run with the session's devteam env removed (m-20261114-214804017-supervisor):
+env -u DEVTEAM_RUN -u DEVTEAM_HOME -u DEVTEAM_ROLE -u DEVTEAM_TICKET -u DEVTEAM_FEATURE -u DEVTEAM_SUPERVISOR -u TMUX -u TMUX_PANE TMUX_TMPDIR=$(mktemp -d) node --test test/hub-overview.test.mjs test/machine.test.mjs test/operator-threads.test.mjs
+not ok 20 - the store: a thread, its turns, closed and opened again, kept beside the operator in no repo
+not ok 21 - a box keeps them in ~/operator, on the disk that outlives a deploy
+not ok 22 - who may write what: the owner starts, says and closes; only the operator replies; no session in a fleet reads or writes
+not ok 23 - what is kept is checked: a turn's size, a title of one line, a subject of the Overview's own shape
+not ok 24 - an owner turn becomes one line in the operator's pane, and only at its prompt
+not ok 25 - on a box the operator is window 0 of home: typed into when it is there, never started when it is not
+not ok 26 - on a box the owner's verbs take only a press the box's gateway signed, and show says which turns it signed
+not ok 27 - a laptop's operator is started once: by the first words or by start, in its own session, with operator.md as its prompt
+not ok 28 - start-once holds under a C locale, with the window renamed, and when tmux gives no answer
+not ok 29 - settings that can't be read fail the start before its lock is taken
+not ok 30 - inside tmux, list, show and reply are the operator's only from its own pane
+not ok 31 - turns sent at the same moment each arrive whole: text then Enter, never text, text, Enter, Enter
+not ok 33 - the hub takes the owner's turns only from its own page, within its caps, and starts the laptop's operator on the first
+not ok 34 - on a box the hub takes a press only with the gateway's signature: a local program with the page's own headers is refused
+not ok 36 - a start's note from a kit that did not name its tmux server is never taken for another session's pane
+# tests 36
+# pass 19
+# fail 15
+# skipped 2
+
+[exited with code 0]