@lovek4d/kickflip 0.5.0 → 0.5.3

package/CONTEXT.md

@@ -31,7 +31,7 @@ The machine the hub and its sessions run on, a Mac or a Linux machine. Its **hub
 _Avoid_: the Mac, server (for the machine)
 
 **Sidebar**:
-The list of every site beside each board and hub page: New version with Reload when the hub’s code changed since the app loaded, else, on an npm install, Update available · Upgrade while npm has a newer kickflip, which runs `kickflip update` once no builder runs ([the hub offers a newer kickflip from npm](docs/adr/2026-11-03-1521-the-hub-offers-a-newer-kickflip-from-npm.md)), then Hub, then Turn on notifications when needed, then Pages (sites that aren't boards), then Boards with their status words, lane chips, waiting counts and **context window** (its owner session's last reported percent, e.g. “62% ctx”, from `~/.claude/kickflip/context/<session>.json`, which the status line writes; dimmed with its age once ten minutes old; none on cards or for subagents; a board not listening at 95% or more reads **context full**, and the hub board's session gets `/compact` typed into its tmux pane once ([a board session compacts before its context fills](docs/adr/2026-11-03-1823-a-board-session-compacts-before-its-context-fills.md))). The last row of Boards is **New board**, a + tile opening a sheet that chooses a GitHub repo from the list or a pasted GitHub link or `owner/name`, then its branch, Name, optional What it’s for and Tickets (Internal · INT by default); a line under the repo field points a repo already on the host at `kickflip join` in its folder. Start is the confirm: the hub starts the board’s session itself once the request passes its checks; a muted, non-link row shows its name, its three start steps (**cloning**, **starting orchestrator**, **landing it**) on the board's phase bars, and the step with its seconds, cloning with git's percent, until its route joins and the row turns into the board's ([a new board shows its start steps and live clone progress](docs/adr/2026-11-04-1914-a-new-board-shows-its-start-steps-and-clone-progress.md)). When claude fails to start, or after 15 minutes without a join, it keeps the board's name in red with **failed to start** under it ([the hub starts a new board's session itself](docs/adr/2026-10-31-0137-the-hub-starts-a-new-boards-session.md)); tapping it opens a sheet with the clone or session error line, what the start used, Dismiss and **Retry**, which starts it again from the same record ([a failed start retries from its sheet](docs/adr/2026-11-02-2006-a-failed-start-retries-from-its-sheet.md)). Hub carries notification problems and the tools’ 5-hour usage bars under its sub line, and a moon after its name while pushes are held or snoozed, whose tooltip says until when; the whole row opens the hub page and stays selected on the hub page and its settings modals. Boards and Pages stay apart wherever sites are listed. The header's logo toggles it at every width; it carries no count, and shows a plain accent dot while a new version waits. From 900px it is a rail, which its own logo collapses out of sight until the header's logo brings it back; narrower, it is a drawer. Its header reads Kickflip. Below 900px every page header is a bottom bar, and the drawer header sits at its foot under New board; desktop headers stay at the top ([phone headers sit at the bottom, with boards nearest the thumb](docs/adr/2026-10-31-1532-phone-headers-sit-at-the-bottom.md)). In the **app shell** it is mounted once, beside every view and framed page, and a site's row swaps the view in place. `/` opens this device's **last board**, which the app shell stores as each board opens, never a page ([a sidebar of every board replaces the hub home](docs/adr/2026-10-29-1639-a-sidebar-of-every-board-replaces-the-hub-home.md), [one app for the whole hub](docs/adr/2026-10-29-2005-one-app-for-the-whole-hub.md)).
+The list of every site beside each board and hub page: New version with Reload when the hub’s code changed since the app loaded, else, on an npm install, Updated to v<version> · Restart once the hub has pulled a newer kickflip from npm by itself, whatever runs; Restart restarts the hub and reloads the page ([the hub pulls a new version itself and offers Restart](docs/adr/2026-11-05-2200-the-hub-pulls-a-new-version-itself-and-offers-restart.md)), then Hub, then Turn on notifications when needed, then Pages (sites that aren't boards), then Boards with their status words, lane chips, waiting counts and **context window** (its owner session's last reported percent, e.g. “62% ctx”, from `~/.claude/kickflip/context/<session>.json`, which the status line writes; dimmed with its age once ten minutes old; none on cards or for subagents; a board not listening at 95% or more reads **context full**, and the hub board's session gets `/compact` typed into its tmux pane once ([a board session compacts before its context fills](docs/adr/2026-11-03-1823-a-board-session-compacts-before-its-context-fills.md))). The last row of Boards is **New board**, a + tile opening a sheet that chooses a GitHub repo from the list or a pasted GitHub link or `owner/name`, then its branch, Name, optional What it’s for and Tickets (Internal · INT by default); a line under the repo field points a repo already on the host at `kickflip join` in its folder. Start is the confirm: the hub starts the board’s session itself once the request passes its checks; a muted, non-link row shows its name, its three start steps (**cloning**, **starting orchestrator**, **landing it**) on the board's phase bars, and the step with its seconds, cloning with git's percent, until its route joins and the row turns into the board's ([a new board shows its start steps and live clone progress](docs/adr/2026-11-04-1914-a-new-board-shows-its-start-steps-and-clone-progress.md)). When claude fails to start, or after 15 minutes without a join, it keeps the board's name in red with **failed to start** under it ([the hub starts a new board's session itself](docs/adr/2026-10-31-0137-the-hub-starts-a-new-boards-session.md)); tapping it opens a sheet with the clone or session error line, what the start used, Dismiss and **Retry**, which starts it again from the same record ([a failed start retries from its sheet](docs/adr/2026-11-02-2006-a-failed-start-retries-from-its-sheet.md)). Hub carries notification problems and the tools’ 5-hour usage bars under its sub line, and a moon after its name while pushes are held or snoozed, whose tooltip says until when; the whole row opens the hub page and stays selected on the hub page and its settings modals. Boards and Pages stay apart wherever sites are listed. The header's logo toggles it at every width; it carries no count, and shows a plain accent dot while a new version waits. From 900px it is a rail, which its own logo collapses out of sight until the header's logo brings it back; narrower, it is a drawer. Its header reads Kickflip. Below 900px every page header is a bottom bar, and the drawer header sits at its foot under New board; desktop headers stay at the top ([phone headers sit at the bottom, with boards nearest the thumb](docs/adr/2026-10-31-1532-phone-headers-sit-at-the-bottom.md)). In the **app shell** it is mounted once, beside every view and framed page, and a site's row swaps the view in place. `/` opens this device's **last board**, which the app shell stores as each board opens, never a page ([a sidebar of every board replaces the hub home](docs/adr/2026-10-29-1639-a-sidebar-of-every-board-replaces-the-hub-home.md), [one app for the whole hub](docs/adr/2026-10-29-2005-one-app-for-the-whole-hub.md)).
 _Avoid_: hub home, switcher, nav
 
 **Switch mode**:
@@ -63,7 +63,7 @@ The word on the Hub row of the sidebar and the hub page's Health card: **healthy
 _Avoid_: broken, hub health
 
 **Integration readiness**:
-What each integration needs before its features can run: the Hub page’s Integrations section between Health and Boards lists GitHub, Codex, Linear, Slack, Tailscale and Notifications in that order. A row reading ready says what passed; one reading not ready is orange and says what is missing, how to fix it and which features wait. A board session reports whether Claude’s Slack connector is available; the hub shares the same readiness and words with feature gates ([integrations show readiness, and features wait until theirs is ready](docs/adr/2026-11-02-1118-integrations-show-readiness-and-features-wait.md)).
+What each integration needs before its features can run: the Hub page’s Integrations section between Health and Boards lists GitHub, Codex, Linear, Slack, Tailscale and Notifications in that order. A row reading ready says what passed; one reading not ready is orange and says what is missing, how to fix it and which features wait. Slack is ready while Hub’s Slack token is saved and Slack hasn’t refused it; the hub shares the same readiness and words with feature gates ([integrations show readiness, and features wait until theirs is ready](docs/adr/2026-11-02-1118-integrations-show-readiness-and-features-wait.md)).
 _Avoid_: integration health, availability
 
 **Usage reading**:
@@ -78,6 +78,10 @@ _Avoid_: buffer threshold, quota guard
 The Usage card's Opus · Auto · Sonnet control, opening Claude's block: `claudeModel` in `~/.claude/kickflip/settings.json`, default Auto. It decides which model builds a card Claude builds: Opus or Sonnet always, or under Auto the card's own `--model`, else Sonnet for a card `--size small` and Opus for the rest. `builder pick` prints it with why, and a build's `builder start` refuses a `--model` it rules out. Codex builds, prototypes and grills don't read it ([usage picks Opus, Auto or Sonnet for Claude builders, and builder pick says which and why](docs/adr/2026-11-03-1526-usage-picks-opus-auto-or-sonnet-for-claude-builders.md)).
 _Avoid_: Opus builders, allow Opus
 
+**Audit log**:
+One JSON line for each call the code makes on its own, with when, the call, the card, its result, the reason and the inputs it read: a board's in its `data/audit.jsonl`, such as the pick a build started on, a pull, a relaunch or an auto-merge, and the hub's own (usage pauses and resumes, Linear moves) in `~/.claude/kickflip/audit.jsonl`. Each keeps the last 30 days. `board.mjs audit [<card>]` and `kickflip audit` print them ([the hub and each board keep an audit log of the calls their code makes](docs/adr/2026-11-05-0913-the-hub-and-each-board-keep-an-audit-log-of-the-calls-their-code-makes.md)).
+_Avoid_: hub.log (the hub's free-text stderr), history
+
 **Board registry**:
 `hub/boards.mjs`, the only hub code that reads a board's `board.json` and wave files. Every hub feature that serves boards (the GitHub check, wakes, rules, the handshake, the not-listening push) takes its boards from it, so a board over the waves and a board over its own file get the same links ([one board registry for every hub feature](docs/adr/2026-10-29-1639-one-board-registry-for-every-hub-feature.md)).
 _Avoid_: board list, wave boards and file boards (as separate code paths)
@@ -125,11 +129,11 @@ The hub resuming a board session as soon as an event lands while that session is
 _Avoid_: auto-resume, respawn, wake (a daily wake is the morning `check-github`)
 
 **Push**:
-A notification from the hub, on the phone or a desktop browser, that opens a page. Each push has a kind, and `hub/push.mjs` `deliver()` refuses any other: `action` when a card's **Action needed** appears or changes, `prompt` for a **pending prompt**, `fault` for what only the owner can fix (a board not listening, a session that didn't come back, an urgent production problem) ([a push goes out only when something waits on the owner, on the hub's schedule](docs/adr/2026-10-29-1639-pushes-only-when-something-waits-on-the-owner.md)). Answers, merges, Stale and other news never push; the threads' unread marks and the board carry them. The board server sends each action push itself, under the card's tag or `topic-<id>` for a Needs you topic, when Action needed appears, changes kind or gains a question ([the board records what it knows, and commands make the rule calls](docs/adr/2026-11-03-0003-the-board-records-what-it-knows-and-commands-make-the-rule-calls.md)). Questions, steps and prototypes go at once; drafts on Ready and Merge go when their tick ends, and one under a card's tag replaces the last and alerts again ([pushes go out by kind, and each arrives on its own](docs/adr/2026-10-29-1639-pushes-go-by-kind-and-each-arrives-on-its-own.md)). When the queue goes out, a board with one queued push gets it as it is, and a board with several gets one summary of what waits on its Needs you then, tagged `summary:<route>` so the newest replaces the last, or nothing when nothing waits ([queued pushes go as one summary per board](docs/adr/2026-11-02-1733-queued-pushes-go-as-one-summary-per-board.md)). Replies don't push; a push that goes out anyway says how many came since the last one. With notifications off every push is dropped; a snooze and Off on weekends hold pushes until they end, and urgent ones go through those holds ([notifications can be off, snoozed, or off on weekends](docs/adr/2026-10-29-1639-notifications-can-be-off-snoozed-or-off-on-weekends.md)). While the owner is **at the host**, an action push goes to the host only ([pushes go to the Mac only while the owner is at it](docs/adr/2026-10-30-1704-pushes-go-to-the-mac-only-while-the-owner-is-at-it.md)).
+A notification from the hub, on the phone or a desktop browser, that opens a page. Each push has a kind, and `hub/push.mjs` `deliver()` refuses any other: `action` when a card's **Action needed** appears or changes, `prompt` for a **pending prompt**, `fault` for what only the owner can fix (a board not listening, a session that didn't come back, an urgent production problem) ([a push goes out only when something waits on the owner, on the hub's schedule](docs/adr/2026-10-29-1639-pushes-only-when-something-waits-on-the-owner.md)). Answers, merges, Stale and other news never push; the threads' unread marks and the board carry them. The board server sends each action push itself, under the card's tag or `topic-<id>` for a Needs you topic, when Action needed appears, changes kind or gains a question ([the board records what it knows, and commands make the rule calls](docs/adr/2026-11-03-0003-the-board-records-what-it-knows-and-commands-make-the-rule-calls.md)). Questions, steps and prototypes go at once; drafts on Ready and Merge go when their tick ends, and one under a card's tag replaces the last and alerts again ([pushes go out by kind, and each arrives on its own](docs/adr/2026-10-29-1639-pushes-go-by-kind-and-each-arrives-on-its-own.md)). When the queue goes out, a board with one queued push gets it as it is, and a board with several gets one summary of what waits on its Needs you then, tagged `summary:<route>` so the newest replaces the last, or nothing when nothing waits ([queued pushes go as one summary per board](docs/adr/2026-11-02-1733-queued-pushes-go-as-one-summary-per-board.md)). Replies don't push; a push that goes out anyway says how many came since the last one. With notifications off every push is dropped; a snooze and Off on weekends hold pushes until they end, and urgent ones go through those holds ([notifications can be off, snoozed, or off on weekends](docs/adr/2026-10-29-1639-notifications-can-be-off-snoozed-or-off-on-weekends.md)). Every push goes to every subscribed device ([every push goes to every device](docs/adr/2026-11-05-2230-every-push-goes-to-every-device.md)).
 _Avoid_: alert, notification (for the act of sending)
 
 **At the host**:
-The owner's presence that keeps pushes off the phone: the host's screen is unlocked and a key or the pointer was used in the last 3 minutes, whatever app is in front (`hub/presence.mjs`). It is read from macOS `ioreg`, so on a Linux host the owner always reads away. Then an action push goes only to the desktop subscriptions, and the phone never gets it later; prompts, faults and urgent pushes still reach the phone, and with no desktop subscription every push does. Otherwise the owner is away and every push goes to every device ([pushes go to the Mac only while the owner is at it](docs/adr/2026-10-30-1704-pushes-go-to-the-mac-only-while-the-owner-is-at-it.md)).
+The owner's presence, which sets the **Check cadence** and the moon: the host's screen is unlocked and a key or the pointer was used in the last 3 minutes, whatever app is in front (`hub/presence.mjs`). It is read from macOS `ioreg`, so on a Linux host the owner always reads away.
 _Avoid_: at the Mac, active, online, desktop app active
 
 **Check cadence**:
@@ -144,8 +148,12 @@ _Avoid_: overnight window, wake times
 The six summary rows below the **hub page**’s health and status: Notifications, Quiet hours, Keep awake, Linear, Rules for every board and Closed boards. Each opens its controls in a centred modal with its own scroll area. Snooze and Keep awake share one duration picker: 1h, 3h, 6h, 1d, Forever and Custom. Keep awake has the hub run `caffeinate -ims` until its end, and is disabled on hosts other than macOS ([snooze and Keep awake share one duration picker](docs/adr/2026-11-02-1402-snooze-and-keep-awake-share-one-duration-picker.md)). Old Hub Settings links open the matching modal over Hub ([hub settings open as modals](docs/adr/2026-11-01-1221-hub-settings-open-as-modals.md)).
 _Avoid_: Hub Settings page, preferences, hub config
 
+**Shared person**:
+Someone else signed in to Tailscale whose login a board's Sharing lists: they see that board, view only, in a shell whose sidebar lists only the boards shared with them, and open its Visit links; the rest of the hub refuses them ([a board is shared view only with a Tailscale login](docs/adr/2026-11-05-2215-a-board-is-shared-view-only-with-a-tailscale-login.md)).
+_Avoid_: guest, viewer, collaborator
+
 **Board Settings**:
-The centred modal opened from a board header’s gear, at every width, which scrolls inside on a phone. It contains only that board’s settings: repo and branch (Change uses the same list and GitHub link search as New board), ticket source, auto-merge, auto-build, auto-pull (Auto implement Todo cards) with Maximum parallel implementers, auto-triage, reviewers, rules and Close board with typed-name confirmation. Closing returns to the same board and open card without another history entry ([hub settings expand in place and board settings open in a modal](docs/adr/2026-10-31-1721-hub-settings-expand-in-place-and-board-settings-open-in-a-modal.md)).
+The centred modal opened from a board header’s gear, at every width, which scrolls inside on a phone. It contains only that board’s settings: repo and branch (Change uses the same list and GitHub link search as New board), ticket source, auto-merge, auto-build, auto-pull (Auto implement Todo cards) with Maximum parallel implementers and planners, auto-triage, reviewers, sharing, rules and Close board with typed-name confirmation. Closing returns to the same board and open card without another history entry ([hub settings expand in place and board settings open in a modal](docs/adr/2026-10-31-1721-hub-settings-expand-in-place-and-board-settings-open-in-a-modal.md)).
 _Avoid_: Settings page
 
 **Codex setting**:
@@ -171,7 +179,7 @@ A board whose session and server have stopped and whose sidebar row is gone, wit
 _Avoid_: deleted board, archived board
 
 **Hub links**:
-What the hub owes a board, each passing or broken: GitHub polling (not on a board on a plain git remote), the repo fetch (on a board with a repo, the hub's last `git fetch` of it worked; when it failed, git's error line and the fix, such as `gh auth setup-git`, or `git ls-remote <link>` on a plain git remote), events (the board is **listening**), daily wakes and reviewer links; whether a device gets pushes is the Notifications integration, not a hub link ([the hub reads Healthy, Degraded or a site down, and notifications leave the board links](docs/adr/2026-11-03-0501-the-hub-reads-healthy-degraded-or-a-site-down.md)). The hub link (the hub runs the code in its files) is the hub's own, shown in amber only on the sidebar's Hub row and the hub page's Health card ([every builder works in a worktree, and the hub's own fault shows once](docs/adr/2026-10-30-1654-every-builder-works-in-a-worktree.md)). The In Review header's GitHub mark, or on a plain git remote the branch mark beside its host/path, opens them as a sheet, red-dotted only while one stays broken past its grace period; until then it is **settling** ([hub links turn red only after a grace period](docs/adr/2026-10-29-1639-hub-links-turn-red-only-after-a-grace-period.md)). A new board tests them with a **handshake**: a `hello` event the session's watcher answers itself, with a Connecting checklist on the board until the watcher answered and GitHub checks reach it, the GitHub step left out on a plain git remote ([one board registry for every hub feature](docs/adr/2026-10-29-1639-one-board-registry-for-every-hub-feature.md)).
+What the hub owes a board, each passing or broken: GitHub polling (not on a board on a plain git remote), the repo fetch (on a board with a repo, the hub's last `git fetch` of it worked; when it failed, git's error line and the fix, such as `gh auth setup-git`, or `git ls-remote <link>` on a plain git remote), events (the board is **listening**), daily wakes and reviewer links; whether a device gets pushes is the Notifications integration, not a hub link ([the hub reads Healthy, Degraded or a site down, and notifications leave the board links](docs/adr/2026-11-03-0501-the-hub-reads-healthy-degraded-or-a-site-down.md)). The hub link (the hub runs the code in its files) is the hub's own, shown in amber only on the sidebar's Hub row and the hub page's Health card ([every builder works in a worktree, and the hub's own fault shows once](docs/adr/2026-10-30-1654-every-builder-works-in-a-worktree.md)). The In Review header's GitHub mark, or on a plain git remote the branch mark beside its host/path, opens them as a sheet, red-dotted only while one stays broken past its grace period; until then it is **settling** ([hub links turn red only after a grace period](docs/adr/2026-10-29-1639-hub-links-turn-red-only-after-a-grace-period.md)). A new board tests them with a **handshake**: a `ping` event the session's watcher answers itself, with a Connecting checklist on the board until the watcher answered and GitHub checks reach it, the GitHub step left out on a plain git remote ([one board registry for every hub feature](docs/adr/2026-10-29-1639-one-board-registry-for-every-hub-feature.md)).
 _Avoid_: health, status, integrations
 
 **Change signal**:
@@ -195,7 +203,7 @@ One step of a **lineup**: a set of its cards that build side by side, each block
 _Avoid_: stage, batch; a builder's phase (reading, building, …) is its progress, not this
 
 **Wave band**:
-A wave shown inside Todo: one band per open **lineup**, then on a board over `~/.claude/waves` one per unfinished wave file, above Todo's cards in no wave ("Not in a wave"). Its head reads its name (the goal as its tooltip, or a long-press popover), its Todo count, "N of M merged" and its started cards, then "Notes ↗ · Triage" (a wave file has only Triage), then Implement for a lineup's next card when it is ready, else "next: #N <why not>". Open, it lists its Todo cards in wave order with step numbers, one per phase, and a ⋯ menu that swaps a card with the Todo card above or below, each taking the other's phase, after one "N done" line. A lineup's next card is its first ready Todo card, so a phase's ready cards take Implement in turn. Only the first band with a ready next card starts open ([waves are bands in Todo, each with its next card's Implement](docs/adr/2026-11-03-1840-waves-are-bands-in-todo.md)).
+A wave shown inside Todo: one band per open **lineup**, then on a board over `~/.claude/waves` one per unfinished wave file, above Todo's cards in no wave ("No wave"; every other lane groups its cards by wave too, a header per wave with cards there and its x/y/k/z counts across lanes, [docs/adr/2026-11-05-0215-every-lane-groups-its-cards-by-wave.md](docs/adr/2026-11-05-0215-every-lane-groups-its-cards-by-wave.md)). Its head reads its name (the goal as its tooltip, or a long-press popover), its Todo count, "N of M merged" and its started cards, then "Notes ↗ · Triage" (a wave file has only Triage), then Implement for a lineup's next card when it is ready, else "next: #N <why not>". Open, it lists its Todo cards in wave order with step numbers, one per phase, and a ⋯ menu that swaps a card with the Todo card above or below, each taking the other's phase, after one "N done" line. A lineup's next card is its first ready Todo card, so a phase's ready cards take Implement in turn. Only the first band with a ready next card starts open ([waves are bands in Todo, each with its next card's Implement](docs/adr/2026-11-03-1840-waves-are-bands-in-todo.md)).
 _Avoid_: Waves section, wave bars, wave filter, pills
 
 **Wave triage**:
@@ -207,7 +215,7 @@ Claude reviewing a board's repo, chosen by `hub/board-repo.mjs` `boardRepo`, wit
 _Avoid_: improvements round, audit (for the whole review), bulb round
 
 **Reviewers**:
-The people who get a board's PR links once they are ready, and the weekday digest. Each board keeps its own in `board.json`, which its Settings modal lists, and a new wave copies them into its own `reviewers`. A remove there is written by the board server; an add waits on the session, which finds the person's Slack and GitHub ids ([the board server removes reviewers itself](docs/adr/2026-11-04-0119-the-board-server-removes-reviewers-itself.md)). Kickflip owns the sent links in each item's `review_link_ts: {<name>: {ts, channel, reactions?}}`; one reader supplies the card, Stale age, hub Slack link and digest, with slack-bridge topic files only as a fallback. The session sends through Claude's Slack connector and records with `board.mjs review sent`, `review react` and `review digest sent`. Hub Slack identity lives in `~/.claude/kickflip/slack.json`, read or set by `board.mjs slack`; its timezone sets the weekday 09:00 digest date ([kickflip owns the reviewer record](docs/adr/2026-11-01-2347-kickflip-owns-the-reviewer-record.md)).
+The people who get a board's PR links once they are ready, and the weekday digest. Each board keeps its own in `board.json`, which its Settings modal lists, and a new wave copies them into its own `reviewers`. The board server writes both an add and a remove: an add picks a Slack member and a GitHub login from lists it fetches with the hub's Slack token and `gh`, and the server opens the DM ([the server adds reviewers from fetched lists](docs/adr/2026-11-05-2100-the-server-adds-reviewers-from-fetched-lists.md), extending [the board server removes reviewers itself](docs/adr/2026-11-04-0119-the-board-server-removes-reviewers-itself.md)). Kickflip owns the sent links in each item's `review_link_ts: {<name>: {ts, channel, reactions?}}`; one reader supplies the card, Stale age, hub Slack link and digest, with slack-bridge topic files only as a fallback. The hub sends them as the owner, through the Slack user token pasted on Hub settings › Slack and kept in `~/.claude/kickflip/secrets.json` beside Linear's key, opening the owner's DM with each reviewer, and records with the writers behind `board.mjs review sent`, `review react` and `review digest sent` ([the hub sends reviewer Slack messages with its own token](docs/adr/2026-11-05-0141-the-hub-sends-reviewer-slack-messages-with-its-own-token.md)). Hub Slack identity lives in `~/.claude/kickflip/slack.json`, read or set by `board.mjs slack`; its timezone sets the weekday 09:00 digest date ([kickflip owns the reviewer record](docs/adr/2026-11-01-2347-kickflip-owns-the-reviewer-record.md)).
 _Avoid_: approvers, watchers
 
 **Finished wave**:
@@ -263,7 +271,7 @@ The one card a work item was spun out of, or none: set when a card is created fr
 _Avoid_: filed from, origin, epic
 
 **Related to**:
-Similar cards that should be cross-referenced, set by hand with `item set --related`, shown on both cards. It neither blocks nor orders anything; Blocked by does that ([cards wait on explicit blocked-by links](docs/adr/2026-10-29-1639-cards-wait-on-explicit-blocked-by-links.md)).
+Similar cards that should be cross-referenced, shown on both cards. The session links a new card in the call that files it: `item set --relate` adds links, `--unrelate` takes them off on both cards, and `--related` replaces the list. Planner and builder briefs list a card's Related to, Parent and deps with their notes, for context ([the orchestrator links a new card when it files it](docs/adr/2026-11-05-0130-the-orchestrator-links-a-new-card-when-it-files-it.md)). It neither blocks nor orders anything; Blocked by does that ([cards wait on explicit blocked-by links](docs/adr/2026-10-29-1639-cards-wait-on-explicit-blocked-by-links.md)).
 _Avoid_: sibling, link (alone)
 
 **Plan waves**:
@@ -275,7 +283,7 @@ _Avoid_: backlog item, todo
 _Avoid_: history, old cards
 
 **Lane**:
-Where a card sits (In Review, Stale, In Progress, Todo, Done, Asks), set by who acts next ([the lane follows who acts next, and a card waiting on the owner says Action needed](docs/adr/2026-10-29-1639-the-lane-follows-who-acts-next.md)). In Progress means a card is building: a running build agent, a **checking** item, or a ready PR whose CI is red, or a red draft on a board that **skips the draft**. A work card that has started building, with a build agent's record, running or finished, a building or fixing status, or a **queued build** ([Build on a blocked card queues it, and blocked, bumped and Action needed leave the badges](docs/adr/2026-11-03-0301-build-on-a-blocked-card-queues-it.md)), never drops back to Todo unless held ([a card moves to In Progress only once building starts](docs/adr/2026-11-03-0202-a-card-moves-to-in-progress-only-once-building-starts.md)). A running grill or prototype agent shows its status line but leaves the card where it is. In Review means finished work waits on a person: the reviewers, or the owner's review of a draft ("Review draft PR #n", whatever its CI), Merge, manual steps or the Done of an ask (see **Action needed**), or of a reopened card. An owner message or a new question on a Done card, merged or not, reopens it: In Progress until Claude answers, then In Review until the owner's Done, its next step "Tap Done once it is settled" ([a message or question on a Done card reopens it until the owner's Done](docs/adr/2026-11-02-1952-a-message-or-question-on-a-done-card-reopens-it.md), [a merged card reopens on a message, and its PR badge shows the PR's state](docs/adr/2026-11-03-1843-a-merged-card-reopens-and-its-pr-badge-shows-the-prs-state.md), [a card waiting only to be closed has no Action needed](docs/adr/2026-11-03-0137-a-card-waiting-only-to-be-closed-has-no-action-needed.md)). A card waiting only on those moves there from In Progress; one Claude still works on stays in In Progress. A card with several PRs, in any repos, sits where its least-ready PR puts it, shows a PR badge for each, and is Done once every PR has merged or closed with at least one merged ([a card holds several PRs across repos](docs/adr/2026-11-03-1904-a-card-holds-several-prs-across-repos.md)). Todo holds work that hasn't started building: the New cards, which wait on Claude ([the + makes a New card, which Claude files, folds or answers](docs/adr/2026-10-29-1639-the-plus-makes-a-new-card.md)), and every work card with no build yet, where its **Implement** shows. Discussion keeps a card there: open questions or a prototype pick, with Action needed, answered or resolved questions, grill and prototype agents, a working mark on a message in its thread and a prototype recorded for it ([a card moves to In Progress only once building starts](docs/adr/2026-11-03-0202-a-card-moves-to-in-progress-only-once-building-starts.md)). A started card that gets a question keeps its lane ([an unstarted card waits on its questions in Todo, and its one action button follows what it waits on](docs/adr/2026-10-30-1309-an-unstarted-card-waits-on-its-questions-in-todo.md)). Each lane has one fixed order, with no sort menu ([each lane has one fixed order](docs/adr/2026-11-03-0223-each-lane-has-one-fixed-order.md)): Todo lists its New cards first, oldest first, then its bumped cards, the latest bump on top ([a card that hasn't started, or is running, can be bumped](docs/adr/2026-10-29-1639-a-card-that-hasnt-started-can-be-bumped.md)), then the rest newest made first; In Progress, its bumped cards first, then by when each came into the lane, its reopening or its latest build agent's start, the newest arrival on top; In Review and Stale by when the PR was first sent to a reviewer, the newest on top; Done by when each card closed, the most recent on top; Asks, the answered asks in their own lane below Done, by when Claude answered, the newest on top. Done and Asks each show 10 cards, then a Show more, the thread's, that adds 10 and says how many are left; a card the owner has open stays shown ([answered asks have their own section below Done, and Done and Asks show 10 cards at a time](docs/adr/2026-11-03-0259-answered-asks-have-their-own-section-below-done.md)). Every card, a New card included, ends with one muted line holding the time its lane sorts by: the time only today, the day too before today ("10/31, 2:49 PM"), and the year too past 365 days. A card with no such time has no time on that line.
+Where a card sits (In Review, Stale, In Progress, Todo, Done, Asks), set by who acts next ([the lane follows who acts next, and a card waiting on the owner says Action needed](docs/adr/2026-10-29-1639-the-lane-follows-who-acts-next.md)). In Progress means a card is building: a running build agent, a **checking** item, or a ready PR whose CI is red, or a red draft on a board that **skips the draft**. A work card that has started building, with a build agent's record, running or finished, a building or fixing status, or an Implement message waiting on the orchestrator ([Implement in the thread queues the card for the orchestrator](docs/adr/2026-11-05-0300-implement-in-the-thread-queues-the-card-for-the-orchestrator.md)), never drops back to Todo unless held ([a card moves to In Progress only once building starts](docs/adr/2026-11-03-0202-a-card-moves-to-in-progress-only-once-building-starts.md)). A running grill or prototype agent shows its status line but leaves the card where it is. In Review means finished work waits on a person: the reviewers, or the owner's review of a draft ("Review draft PR #n", whatever its CI), Merge, manual steps or the Done of an ask (see **Action needed**), or of a reopened card. An owner message or a new question on a Done card, merged or not, reopens it: In Progress until Claude answers, then In Review until the owner's Done, its next step "Tap Done once it is settled" ([a message or question on a Done card reopens it until the owner's Done](docs/adr/2026-11-02-1952-a-message-or-question-on-a-done-card-reopens-it.md), [a merged card reopens on a message, and its PR badge shows the PR's state](docs/adr/2026-11-03-1843-a-merged-card-reopens-and-its-pr-badge-shows-the-prs-state.md), [a card waiting only to be closed has no Action needed](docs/adr/2026-11-03-0137-a-card-waiting-only-to-be-closed-has-no-action-needed.md)). A card waiting only on those moves there from In Progress; one Claude still works on stays in In Progress. A card with several PRs, in any repos, sits where its least-ready PR puts it, shows a PR badge for each, and is Done once every PR has merged or closed with at least one merged ([a card holds several PRs across repos](docs/adr/2026-11-03-1904-a-card-holds-several-prs-across-repos.md)). Todo holds work that hasn't started building: the New cards, which wait on Claude ([the + makes a New card, which Claude files, folds or answers](docs/adr/2026-10-29-1639-the-plus-makes-a-new-card.md)), and every work card with no build yet, where its **Implement** shows. Discussion keeps a card there: open questions or a prototype pick, with Action needed, answered or resolved questions, grill and prototype agents, a working mark on a message in its thread and a prototype recorded for it ([a card moves to In Progress only once building starts](docs/adr/2026-11-03-0202-a-card-moves-to-in-progress-only-once-building-starts.md)). A started card that gets a question keeps its lane ([an unstarted card waits on its questions in Todo, and its one action button follows what it waits on](docs/adr/2026-10-30-1309-an-unstarted-card-waits-on-its-questions-in-todo.md)). Each lane has one fixed order, with no sort menu ([each lane has one fixed order](docs/adr/2026-11-03-0223-each-lane-has-one-fixed-order.md)): Todo lists its New cards first, oldest first, then its bumped cards, the latest bump on top ([a card that hasn't started, or is running, can be bumped](docs/adr/2026-10-29-1639-a-card-that-hasnt-started-can-be-bumped.md)), then the rest oldest made first, so a new card joins the bottom ([new Todo cards join the bottom, so old ones leave first](docs/adr/2026-11-05-2345-new-todo-cards-join-the-bottom.md)); In Progress, its bumped cards first, then by when each came into the lane, its reopening or its latest build agent's start, the newest arrival on top; In Review and Stale by when the PR was first sent to a reviewer, the newest on top; Done by when each card closed, the most recent on top; Asks, the answered asks in their own lane below Done, by when Claude answered, the newest on top. Done and Asks each show 10 cards, then a Show more, the thread's, that adds 10 and says how many are left; a card the owner has open stays shown ([answered asks have their own section below Done, and Done and Asks show 10 cards at a time](docs/adr/2026-11-03-0259-answered-asks-have-their-own-section-below-done.md)). Every card, a New card included, ends with one muted line holding the time its lane sorts by: the time only today, the day too before today ("10/31, 2:49 PM"), and the year too past 365 days. A card with no such time has no time on that line.
 _Avoid_: column, status (status is the item's own field)
 
 **Checking**:
@@ -295,7 +303,7 @@ Who the card is waiting for: the owning session's check, the owner's Ready, the
 _Avoid_: blocked by, assignee
 
 **Card state**:
-What a card made from a **New task** does next, which its session picks and sets with `item set --state`: **ready** (its notes leave the owner nothing to decide, so it can be built; the plan lives only in the notes), **grilling** (questions on the card) or **prototyping** (takes on the card). The board enforces the three: `--state` refuses any other, and ready while the card has an open question. Until it has one, the card reads New beside its ticket id and is never pulled. A Ready card's time line reads a green "ready" in Action needed's place ("10:26 · held · ready · 2 new messages") while nothing blocks it and nothing waits on the owner, and the idle pull takes it like any settled card ([a new card is ready, grilling or prototyping, and reads ready in green when it is](docs/adr/2026-11-03-0516-a-new-card-is-ready-grilling-or-prototyping.md)).
+What a card made from a **New task** does next, which its session picks and sets with `item set --state`: **ready** (its notes leave the owner nothing to decide, so it can be built; the plan lives only in the notes), **grilling** (questions on the card) or **prototyping** (takes on the card). The board enforces the three: `--state` refuses any other, and ready while the card has an open question. Until it has one, the card reads New beside its ticket id and is never pulled. So does a card an agent added with `item add` and no `--state`, which a `card-added` event hands the session to link and file ([the orchestrator links a new card when it files it](docs/adr/2026-11-05-0130-the-orchestrator-links-a-new-card-when-it-files-it.md)). A Ready card's time line reads a green "ready" in Action needed's place ("10:26 · held · ready · 2 new messages") while nothing blocks it and nothing waits on the owner, and the idle pull takes it like any settled card ([a new card is ready, grilling or prototyping, and reads ready in green when it is](docs/adr/2026-11-03-0516-a-new-card-is-ready-grilling-or-prototyping.md)).
 _Avoid_: triage state, status (the wave entry's `status` is a different field)
 
 **Action needed**:
@@ -307,7 +315,7 @@ The owner's ask for a grill or a prototype on a card: the thread composer's fire
 _Avoid_: Grill button, Prototype button (on a card)
 
 **Action button**:
-The open card's one workflow button, which `board/domain.mjs` picks as the card's `actionButton`: **Open questions** (`openQuestions`) while it has open questions or a prototype pick, opening the first; **Mark as done** (`markDone`) on an ask waiting on the owner's Done, sending the same `ask-done` as the thread's Done; otherwise none. A grill or prototype is asked for from the thread's fire and eye (**request**), and the card reads a blue planner line "preheating" while a grill is under way: a grill request not yet handled (replied to, questions posted on the card after it, or a grill agent started after it finished), a running grill agent, or a **grilling** card with no questions posted yet ([a new card is ready, grilling or prototyping, and reads ready in green when it is](docs/adr/2026-11-03-0516-a-new-card-is-ready-grilling-or-prototyping.md)). Open questions win over Mark as done. A Done card has none ([an unstarted card waits on its questions in Todo, and its one action button follows what it waits on](docs/adr/2026-10-30-1309-an-unstarted-card-waits-on-its-questions-in-todo.md)).
+The open card's one workflow button, which `board/domain.mjs` picks as the card's `actionButton`: **Open questions** (`openQuestions`) while it has open questions or a prototype pick, opening the first; **Mark as done** (`markDone`) on an ask waiting on the owner's Done, sending the same `ask-done` as the thread's Done; otherwise none. A grill or prototype is asked for from the thread's fire and eye (**request**), and the card reads a grey "preheating" while a grill or prototype request waits for its planner (not yet replied to, no questions posted on the card after it, and no planner of its kind started after it finished), then a blue planner line "grilling" or "prototyping" once that planner runs ([a card's status word comes from a signal the board checks](docs/adr/2026-11-05-0410-a-card-status-word-comes-from-a-signal-the-board-checks.md)) ([a new card is ready, grilling or prototyping, and reads ready in green when it is](docs/adr/2026-11-03-0516-a-new-card-is-ready-grilling-or-prototyping.md)). Open questions win over Mark as done. A Done card has none ([an unstarted card waits on its questions in Todo, and its one action button follows what it waits on](docs/adr/2026-10-30-1309-an-unstarted-card-waits-on-its-questions-in-todo.md)).
 While the card carries **Action needed**, the button that clears it is orange, in the notice color: the card's `resolvedBy` from `board/domain.mjs`, by the action's kind. A question or a pick makes Open questions orange, the Done of an ask makes Mark as done and the thread's Done orange, a green draft's Ready or manual steps make Review on GitHub orange, and an approved PR's Merge makes Merge orange. A held card's Open questions stay plain. A reopened card waiting only on the owner's Done has its thread's Done primary, in the accent color ([a card waiting only to be closed has no Action needed](docs/adr/2026-11-03-0137-a-card-waiting-only-to-be-closed-has-no-action-needed.md)).
 The button names (`BUTTON`: the action buttons, `github` and `merge`) and the action kinds (`ACTION_KIND`) are two frozen enums in `board/public/ui-enums.js`, which the page loads as a script and `board/domain.mjs` runs in a vm context; code compares against their members, never a bare string.
 _Avoid_: Open items, Action needed (the badge)
@@ -321,13 +329,14 @@ _Avoid_: merge rule, merge policy
 
 A card with no PR lands the same way: with Auto-merge off its builder's `done` stops after the tests, and the card waits in In Review with a Merge button; the tap makes the board server rebase it onto main as it is now, rerun the tests and land it, sending a conflict or a failing test to a headless lander ([a land waits for your Merge](docs/adr/2026-11-04-2100-a-land-waits-for-your-merge.md)).
 
-**PRs**:
-A board setting, `prs` in its `board.json`, on unless set, shown on a GitHub board that builds in its own clone only. On, every card opens a PR, and with no reviewers on the board that PR merges once it is green and clean, with no approval. Off, no PR opens and each card lands on main, which is pushed; Skip the draft and Reviewers are hidden, and turning it off needs Push main granted ([a land waits for your Merge](docs/adr/2026-11-04-2100-a-land-waits-for-your-merge.md)).
-_Avoid_: PR mode, no-PR mode
+**Rebase run**:
+The headless run the board server starts on a card whose open PR, draft or ready, GitHub reads CONFLICTING, once per head and base: in the card's worktree, or one made from the PR's branch, it rebases onto the board's branch, reruns the suite and finishes with `builder done`, which force-pushes the PR's branch with a lease and leaves the PR as it is. The card stays In Review, its status line the run's; one it can't resolve hands the card back with a judgment call, to the orchestrator before the owner. A merge counts the run's push after an approval as trivial when it only replayed the PR's commits, and says so. The GitHub tick no longer rebases ([the board rebases a conflicting PR with a headless run](docs/adr/2026-11-06-0200-the-board-rebases-a-conflicting-pr-with-a-headless-run.md)).
+_Avoid_: rebase lander, conflict fix
 
-**Skip the draft**:
-A board setting, `skip_draft` in its `board.json`, off unless set, shown on a GitHub board only. On, the hub's GitHub check marks a card's draft PR ready for review once its CI passes, and the card waits in In Review with no Action needed until then; off, the draft waits in In Review with Action needed "Review draft PR #n". With **Auto-merge** on too, a builder's PR can merge once reviewers approve it, without the owner seeing it ([a board can skip the draft](docs/adr/2026-11-04-1913-a-board-can-skip-the-draft.md)).
-_Avoid_: auto-ready, skip review
+**Landing**:
+A board's one choice of how a card lands, a section above Auto in Board settings, shown on a GitHub board that builds in its own clone only: **Draft PR** (each card opens a draft PR and waits for the owner to mark it ready), **Ready PR** (the hub's GitHub check marks the draft ready for review once its CI passes) or **Merge** (no PR opens; each card lands on the board's base branch, which is pushed, and turning it on needs Push main granted). Reviewers show only while cards open PRs. The words never say "main", whatever the base branch. **Auto-merge** stays its own switch and covers both: merging an approved PR, and landing a build that waits to merge into the base branch ([Landing is one choice](docs/adr/2026-11-05-0200-landing-is-one-choice-draft-pr-ready-pr-or-merge.md)).
+It is stored as two `board.json` settings, read together: `prs`, on unless set (off is Merge), and `skip_draft`, off unless set (on is Ready PR); `board.mjs settings set prs|skip-draft` sets each. With no reviewers on the board a PR merges once it is green and clean, with no approval ([a land waits for your Merge](docs/adr/2026-11-04-2100-a-land-waits-for-your-merge.md), [a board can skip the draft](docs/adr/2026-11-04-1913-a-board-can-skip-the-draft.md)).
+_Avoid_: PRs switch, Skip the draft, PR mode, no-PR mode, auto-ready
 
 **Review on GitHub**:
 The open card's link to its PR, on every card with an open PR, last on the details list's final line after Notes and Install when present. It reads "Review draft on GitHub ↗" on a draft and "Review on GitHub ↗" once ready, with no PR number, and is orange while a green draft's Ready or manual steps wait on the owner ([a card's external links share the last details line](docs/adr/2026-10-30-2008-a-cards-external-links-share-the-last-details-line.md)).
@@ -350,23 +359,15 @@ The board's `auto_build` setting (the key keeps its name), labelled "Auto serve"
 _Avoid_: Auto-build, build rule
 
 **Implement**:
-The orange Implement last in the open card's workflow row, on a work card still unstarted in Todo, held or not, blocked or not, that has no **Action needed**: the card's `buildable` from `board/domain.mjs`. Its confirm reads "Implement #92? Claude starts its implementer now with the notes as they stand." Owner-facing words call a card's agent an implementer and its `building` status implementing, so Build, Serve and Install only mean the package of a worktree or main; the code keeps `buildable`, `card-build`, the `building` status and builder records ([a Todo card's button reads Implement, and Build and Serve only mean the package](docs/adr/2026-11-03-1549-a-todo-cards-button-reads-implement.md)). On a blocked card it queues a **queued build**, its confirm "Implement #92 once #53 is done?" ([Build on a blocked card queues it, and blocked, bumped and Action needed leave the badges](docs/adr/2026-11-03-0301-build-on-a-blocked-card-queues-it.md)). On a held card it reads "Unhold and implement" in its confirm and the board server clears the hold as Unhold does before the start; a held card outside Todo keeps Unhold ([a held Todo card shows Build in place of Unhold](docs/adr/2026-11-03-0234-a-held-todo-card-shows-build-in-place-of-unhold.md)). It confirms, sends `card-build {key}` and reads "Starting…" while the board server starts the build: the refusals, the builder pick, the worktree and the building mark that `builder start --kind build --worktree` makes. Started, the card is in In Progress reading "starting" until its implementer's first status line, its Next cleared, and the server launches the builder itself, Claude or Codex, from the card's notes, with the thread line "Builder launched on <model> in <worktree>." linking its log; no event wakes the session ([the hub launches every agent from the card](docs/adr/2026-11-04-2130-the-hub-launches-every-agent-from-the-card.md)). A launch that fails puts the card back in Todo showing **Couldn't start implementing**. Refused, the card stays in Todo showing **Couldn't start implementing** ([a Todo card that nothing blocks has Build](docs/adr/2026-11-02-1745-a-todo-card-that-nothing-blocks-has-build.md), [a Build tap starts the build in the board server](docs/adr/2026-11-03-0219-a-build-tap-starts-the-build-in-the-board-server.md), [a card reads starting from its tap, with one dispatched mark](docs/adr/2026-11-03-1718-a-card-reads-starting-from-its-tap-with-one-dispatched-mark.md)). It isn't an app's Build, which runs the **build script**.
+The orange Implement last in the open card's workflow row, on a work card still unstarted in Todo, held or not, blocked or not, that has no **Action needed**: the card's `buildable` from `board/domain.mjs`. Its confirm reads "Implement #92? Claude starts its implementer now with the notes as they stand." Owner-facing words call a card's agent an implementer and its `building` status implementing, so Build, Serve and Install only mean the package of a worktree or main; the code keeps `buildable`, `card-build`, the `building` status and builder records ([a Todo card's button reads Implement, and Build and Serve only mean the package](docs/adr/2026-11-03-1549-a-todo-cards-button-reads-implement.md)). On a blocked card it bumps the card, which stays in Todo reading "waits on #53" with the thread line "Can’t start yet: waits on #53. Bumped to the top of Todo.", its confirm "Implement #92 once #53 is done? It is bumped to the top of Todo until then." ([Todo has no queue](docs/adr/2026-11-05-0802-todo-has-no-queue.md)). The tap starts its build whatever runs: **Maximum parallel implementers** limits only **Auto-pull** ([Todo has no queue](docs/adr/2026-11-05-0802-todo-has-no-queue.md)). On a held card it reads "Unhold and implement" in its confirm and the board server clears the hold as Unhold does before the start; a held card outside Todo keeps Unhold ([a held Todo card shows Build in place of Unhold](docs/adr/2026-11-03-0234-a-held-todo-card-shows-build-in-place-of-unhold.md)). It confirms, sends `card-build {key}` and reads "Starting…" while the board server starts the build: the refusals, the builder pick, the worktree and the building mark that `builder start --kind build --worktree` makes. Started, the card is in In Progress reading "starting" until its implementer's first status line, its Next cleared, and the server launches the builder itself, Claude or Codex, from the card's notes, with the thread line "Builder launched on <model> in <worktree>, session <id>." linking its log; no event wakes the session ([the hub launches every agent from the card](docs/adr/2026-11-04-2130-the-hub-launches-every-agent-from-the-card.md)). Every builder, lander and planner starts through one adapter, which records the agent's session id on the card's builder record ([one adapter launches Claude or Codex](docs/adr/2026-11-05-0128-one-adapter-launches-claude-or-codex.md)). A launch that fails puts the card back in Todo showing **Couldn't start implementing**. Refused, the card stays in Todo showing **Couldn't start implementing** ([a Todo card that nothing blocks has Build](docs/adr/2026-11-02-1745-a-todo-card-that-nothing-blocks-has-build.md), [a Build tap starts the build in the board server](docs/adr/2026-11-03-0219-a-build-tap-starts-the-build-in-the-board-server.md), [a card reads starting from its tap, with one dispatched mark](docs/adr/2026-11-03-1718-a-card-reads-starting-from-its-tap-with-one-dispatched-mark.md)). It isn't an app's Build, which runs the **build script**.
 _Avoid_: card Build, go button, start button
 
-**Queued section**:
-The one section at the top of Todo that holds the cards waiting for an **implementer slot**: each **Queued build**, and while **Auto-pull** is on every pullable card, ready ones waiting over the cap included. Bumped cards lead it, the latest bump on top; the rest follow oldest first, by the tap's time or else when the card was made, so a card's unbump returns it to that place. Whenever In Progress is under Maximum parallel implementers the board server takes the queue from its top: it starts a Queued build nothing blocks, and starts and launches the build of a ready card. Queued cards take no slot ([In Progress has a Queued section, and the pull takes its top under the cap](docs/adr/2026-11-04-0121-in-progress-has-a-queued-section.md); [Queued sits at the top of Todo](docs/adr/2026-11-04-0150-queued-sits-at-the-top-of-todo.md)).
-_Avoid_: backlog, waiting lane
-
-**Queued build**:
-An Implement the owner tapped on a card an unfinished dep blocks: `queued_at` on its wave entry, with no builder record or worktree, and the thread line "Implement queued: it starts once #53 is done." The card sits in Todo's **Queued section**, its time line reading "blocked by #53" in place of a builder line, and once nothing holds or blocks it and it reaches the queue's top with an **implementer slot** free the board server starts the build as the tap would, from the newest main, and launches its builder. `item set` prints `queued build starts: <key>` for it and sends no `card-unblocked`. A start that is refused or fails sends the card back to Todo with **Couldn't start implementing** ([Build on a blocked card queues it, and blocked, bumped and Action needed leave the badges](docs/adr/2026-11-03-0301-build-on-a-blocked-card-queues-it.md)).
-_Avoid_: pending build, waiting build
-
 **Couldn't start implementing**:
-The thread line, of kind `build-refused`, the board server writes when it refuses an Implement tap, with the reason in the owner's words: paused, or a noted prototype pick that waits on its confirm, or why a **queued build** couldn't start, or a builder launch that failed ("the launch failed (<reason>). Tap Implement to try again."). The Todo card shows it in its status line while it is the card's newest line other than a status line ([a Build tap starts the build in the board server](docs/adr/2026-11-03-0219-a-build-tap-starts-the-build-in-the-board-server.md)).
+The thread line, of kind `build-refused`, the board server writes when it refuses an Implement tap, with the reason in the owner's words: paused, or a noted prototype pick that waits on its confirm, or why a build ready released couldn't start, or a builder launch that failed ("the launch failed (<reason>). Tap Implement to try again."). The Todo card shows it in its status line while it is the card's newest line other than a status line ([a Build tap starts the build in the board server](docs/adr/2026-11-03-0219-a-build-tap-starts-the-build-in-the-board-server.md)).
 _Avoid_: Couldn't start the build, build error, failed start
 
 **Auto-pull**:
-The board's `auto_pull` setting, off by default, which reads "Auto implement Todo cards" in Board settings' Auto section and turns on or off with no confirmation. On, the board server starts and launches the build of the top **pullable** cards in board order, one per **implementer slot** free, on every board change and at start ([auto implement fills In Progress up to Maximum parallel implementers, on every board change](docs/adr/2026-11-04-0057-auto-implement-fills-in-progress-up-to-a-cap.md)): a pullable card is a Ready, unstarted work card that nothing blocks or holds, with no question open or waiting on Claude, no grill under way and no message a session is working on, which waits in the **Queued section** while the switch is on ([the idle pull takes ready cards first, and plans the top card when none is ready](docs/adr/2026-11-03-1631-the-idle-pull-takes-ready-cards-first.md), [a card moves to In Progress only once building starts](docs/adr/2026-11-03-0202-a-card-moves-to-in-progress-only-once-building-starts.md)). The slots are the board's **Maximum parallel implementers** (`max_implementers`, 10 by default, the number beside the switch), less the cards with a running build or waiting in Orchestrator review, less the pulled cards whose build hasn't started; a running grill or prototype and a card waiting on the owner take none ([planners and implementers are two kinds of agent](docs/adr/2026-11-03-1551-planners-and-implementers-are-two-kinds-of-agent.md)). New cards are never pulled, nor a card from an ask still New, grilling or prototyping; a Ready one is ([a new card is ready, grilling or prototyping, and reads ready in green when it is](docs/adr/2026-11-03-0516-a-new-card-is-ready-grilling-or-prototyping.md)). It writes "Pulled in: an implementer slot was free." in the card's thread ([an idle board pulls in its top Todo card](docs/adr/2026-11-02-1754-an-idle-board-pulls-in-its-top-todo-card.md)). While the board is idle (no build running and nothing in Orchestrator review) with nothing pullable, it launches a planner instead, one at a time, on the top Todo card not set Ready that isn't held, owes or awaits no answer and has no planner running, while no card is being grilled or prototyped: a prototype when the card is prototyping, else a grill ([the hub launches every agent from the card](docs/adr/2026-11-04-2130-the-hub-launches-every-agent-from-the-card.md)).
+The board's `auto_pull` setting, off by default, which reads "Auto implement Todo cards" in Board settings' Auto section and turns on or off with no confirmation. On, the board server starts and launches the build of the top **pullable** cards in board order, one per **implementer slot** free, on every board change and at start ([auto implement fills In Progress up to Maximum parallel implementers, on every board change](docs/adr/2026-11-04-0057-auto-implement-fills-in-progress-up-to-a-cap.md)): a pullable card is a Ready, unstarted work card that nothing blocks or holds, with no question open or waiting on Claude, no grill under way and no message a session is working on, taken in Todo's order, bumped first and then oldest first ([the idle pull takes ready cards first, and plans the top card when none is ready](docs/adr/2026-11-03-1631-the-idle-pull-takes-ready-cards-first.md), [a card moves to In Progress only once building starts](docs/adr/2026-11-03-0202-a-card-moves-to-in-progress-only-once-building-starts.md)). The slots are the board's **Maximum parallel implementers** (`max_implementers`, 10 by default, the number beside the switch), less the cards with a running build or waiting in Orchestrator review, less the pulled cards whose build hasn't started; a running grill or prototype and a card waiting on the owner take none ([planners and implementers are two kinds of agent](docs/adr/2026-11-03-1551-planners-and-implementers-are-two-kinds-of-agent.md)). New cards are never pulled, nor a card from an ask still New, grilling or prototyping; a Ready one is ([a new card is ready, grilling or prototyping, and reads ready in green when it is](docs/adr/2026-11-03-0516-a-new-card-is-ready-grilling-or-prototyping.md)). It writes "Pulled in: an implementer slot was free." in the card's thread ([an idle board pulls in its top Todo card](docs/adr/2026-11-02-1754-an-idle-board-pulls-in-its-top-todo-card.md)). Busy board or idle, it also launches a grill on each card that **arrives in Todo**: an open work card in Todo not set Ready or held, with no planner record, no grill or prototype asked for and no questions yet, however it was filed. Up to **Maximum parallel planners** (`max_planners`, 3 by default, the number under the implementers) run at once, less the grills and prototypes running; the rest wait in board order. Each gets one grill, never a prototype straight away, and the card's thread reads "Landed in Todo, so the board started its grill." ([every card arriving in Todo is grilled by the board](docs/adr/2026-11-04-2359-every-card-arriving-in-todo-is-grilled-by-the-board.md), [the hub launches every agent from the card](docs/adr/2026-11-04-2130-the-hub-launches-every-agent-from-the-card.md)).
 _Avoid_: auto-start, idle pickup
 
 **Auto-triage**:
@@ -398,7 +399,7 @@ An agent (Claude Opus, Claude Sonnet, Codex…) working on a work item, which ow
 _Avoid_: worker, bot
 
 **Dispatched record**:
-A builder record open before its agent runs, marked with who opened it: `dispatched: 'tap'` when the owner's Implement tap (or a queued build's start) opened it, `dispatched: 'hub'` when the board server opened it to launch a pulled build or a planner (a grill or a prototype) itself, `dispatched: 'session'` when the session ran `builder start --dispatch` right before it launches some other agent. Either way the card's builder line reads "starting" from then until the agent's first status line. The agent's own `builder start` takes it up: the kind, a Claude model and the worktree stay, the record starts again at now and is no longer dispatched. A `--dispatch` on a record the tap opened changes nothing and prints "already open"; a `builder start --agent <other name>` refuses while the tap's main record is open and not taken up. The session never posts "a builder is working" itself ([the session opens the builder record when it dispatches an agent](docs/adr/2026-11-03-0513-the-session-opens-the-builder-record-when-it-dispatches-an-agent.md), [a card reads starting from its tap, with one dispatched mark](docs/adr/2026-11-03-1718-a-card-reads-starting-from-its-tap-with-one-dispatched-mark.md)).
+A builder record open before its agent runs, marked with who opened it: `dispatched: 'tap'` when the owner's Implement tap (or the start of a build ready released) opened it, `dispatched: 'hub'` when the board server opened it to launch a pulled build or a planner (a grill or a prototype) itself, `dispatched: 'session'` when the session ran `builder start --dispatch` right before it launches some other agent. Either way the card's builder line reads "starting" from then until the agent's first status line. The agent's own `builder start` takes it up: the kind, a Claude model and the worktree stay, the record starts again at now and is no longer dispatched. A `--dispatch` on a record the tap opened changes nothing and prints "already open"; a `builder start --agent <other name>` refuses while the tap's main record is open and not taken up. The session never posts "a builder is working" itself ([the session opens the builder record when it dispatches an agent](docs/adr/2026-11-03-0513-the-session-opens-the-builder-record-when-it-dispatches-an-agent.md), [a card reads starting from its tap, with one dispatched mark](docs/adr/2026-11-03-1718-a-card-reads-starting-from-its-tap-with-one-dispatched-mark.md)).
 
 **Judgment call**:
 A decision a builder makes that its brief didn't settle, recorded on its builder record as it makes it (`builder call <key> "<call>"`, one plain line), or a "Question: …" it asks the session before building. The thread shows a record's calls as one collapsed entry under its agent lines. The session checks them against the owner's words and the other cards and marks the record **verified** (`builder verified`), which finishes a handed-back build in the same step; finishing refuses while a record on the card has a call after that mark. A builder start on a record with unverified calls resumes that build, calls and worktree kept ([a builder records its judgment calls and the session verifies them before land](docs/adr/2026-11-03-0514-a-builder-records-its-judgment-calls-and-the-session-verifies-them.md)).
@@ -409,7 +410,7 @@ A question a running builder puts to the board's session, the **orchestrator**,
 _Avoid_: builder question, check-in
 
 **Stalled**:
-A builder still recorded as running whose last progress, or start before its first progress, was at least 30 minutes ago. Its card's status line turns the needs-you red, and a tap on it nudges Claude, until fresh progress or completion; silence calls for a check, without establishing that the process has failed.
+A builder still recorded as running with no progress line, and no change to its Claude transcript, for at least 10 minutes (counted from its start before its first progress). Its card's status line turns the needs-you red, and a tap on it nudges Claude, until fresh progress or completion; silence calls for a check, without establishing that the process has failed.
 _Avoid_: stuck, hung, failed
 
 **Worktree**:
@@ -429,15 +430,19 @@ An owner message Claude hasn't answered yet ends with **Waiting for Claude…**,
 _Avoid_: comments, chat
 
 **Unread message**:
-A message in a card's thread from Claude (replies included) or GitHub, newer than when this browser last opened that thread. The owner's own lines, their copied-in answers included, other people's Slack lines, and builder, status and ask-link lines are never unread. The card's last line ends with their count in the accent colour, after any hold, as "3:00 PM · held until Wed 9:00 am · 3 new messages", until it is opened.
+A message in a card's thread from Claude (replies included) or GitHub, newer than the card's **read mark**. The owner's own lines, their copied-in answers included, other people's Slack lines, and builder, status and ask-link lines are never unread. The card's last line ends with their count in the accent colour, after any hold, as "3:00 PM · held until Wed 9:00 am · 3 new messages", until it is opened.
 _Avoid_: inbox, notification. "New" names it only in that count's "N new messages"; a New card is an unsorted ask.
 
+**Read mark**:
+How far the owner has read a card: the time of the newest message, question or answer it showed when they last opened it, kept on the board in `data/read.json`, one set for every device, so a card opened on the phone reads on the Mac too. A card new to the board is read up to when the server first sees it, so it badges only what comes after; a card leaving the board, dropped or past the newest 100 Done, loses its mark ([read marks live on the board](docs/adr/2026-11-05-0910-read-marks-live-on-the-board.md)). Every board answer carries it as the card's `readAt`.
+_Avoid_: seen mark, last seen
+
 **Last visit**:
 The board and threads this device last showed, kept in its browser storage. The next visit paints it dimmed at first paint, readable at any age, with the controls that send held until the fresh board lands and replaces it in place, flashing a fading blue border round each lane count, Needs you line or thread message that changed ([the board opens on the last visit](docs/adr/2026-10-29-1639-the-board-opens-on-the-last-visit.md)); a card that changed shows its own sign ([an updated card takes a brief tint](docs/adr/2026-11-02-2354-an-updated-card-takes-a-brief-tint.md)). A board the app shell left fresh and comes back to with no change since paints it live instead ([one app for the whole hub](docs/adr/2026-10-29-2005-one-app-for-the-whole-hub.md)). It paints only under the build that saved it, a hash of the shell's file versions (`hub/shell.mjs` `shellHtml`), so code that changed since never reads it; the page then waits for the fresh board. In code it is the snapshot.
 _Avoid_: cache, offline copy, stale board
 
 **Answer banner**:
-The one line at the top of a board, above Needs you, naming new tasks Claude answered without making work whose answer this browser hasn't seen: "1 answer · <ask>" or "2 answers · <newest> and 1 more". A tap opens the newest one's card; ✕ hides it on this device until a newer answer. No push goes for an answer ([a push goes out only when something waits on the owner, on the hub's schedule](docs/adr/2026-10-29-1639-pushes-only-when-something-waits-on-the-owner.md)).
+The one line at the top of a board, above Needs you, naming new tasks Claude answered without making work whose answer came after the card's read mark: "1 answer · <ask>" or "2 answers · <newest> and 1 more". A tap opens the newest one's card; opening a card anywhere takes its answer off at once, and ✕ marks every answer shown read, on every device. No push goes for an answer ([a push goes out only when something waits on the owner, on the hub's schedule](docs/adr/2026-10-29-1639-pushes-only-when-something-waits-on-the-owner.md)).
 _Avoid_: notification, toast
 
 **Owner question**:
@@ -453,7 +458,7 @@ The group an owner question belongs to; an item's questions use the topic `item:
 _Avoid_: category, section
 
 **Needs you**:
-The orange box at the top of a board listing what waits on the owner, one line per work item, led by the board session's **pending prompts** ([Needs you gathers what waits on the owner, and a topic's questions are answered on one page](docs/adr/2026-10-29-1639-needs-you-gathers-what-waits-and-questions-answer-on-one-page.md)).
+What waits on the owner on a board, led by the board session's **pending prompts** ([Needs you gathers what waits on the owner, and a topic's questions are answered on one page](docs/adr/2026-10-29-1639-needs-you-gathers-what-waits-and-questions-answer-on-one-page.md)). On a phone it is the **deck** at the top of the board: one thing at a time, a tap on a question's option drafting its answer, which Send on Waiting on you sends with its notes, a prompt's buttons answering it on the tap, Skip, a dot per thing waiting, View prototypes on a question with prototypes, and All open questions at its foot. From 900px it is a pane beside the lanes, one orange line per work item over Waiting on you, which arrivals update in place ([Needs you is a deck on a phone and a pane on a desktop](docs/adr/2026-11-05-0408-needs-you-is-a-deck-on-a-phone-and-a-pane-on-a-desktop.md)).
 _Avoid_: inbox, digest
 
 **Pending prompt**:
@@ -461,7 +466,7 @@ A permission prompt or `AskUserQuestion` from a background board session, which
 _Avoid_: permission request, approval, dialog
 
 **Event**:
-A signal that wakes the owning session: something the owner did on a page (an ask, an answer, a button), or a board change such as `card-unblocked {key}` when a waiting card’s last unfinished dependency finishes ([cards wait on explicit blocked-by links](docs/adr/2026-10-29-1639-cards-wait-on-explicit-blocked-by-links.md)), unless its build is a **queued build**, which the board server starts itself ([Build on a blocked card queues it, and blocked, bumped and Action needed leave the badges](docs/adr/2026-11-03-0301-build-on-a-blocked-card-queues-it.md)).
+A signal that wakes the owning session: something the owner did on a page (an ask, an answer, a button), or a board change such as `card-unblocked {key}` when a waiting card’s last unfinished dependency finishes ([cards wait on explicit blocked-by links](docs/adr/2026-10-29-1639-cards-wait-on-explicit-blocked-by-links.md)).
 _Avoid_: action, request
 
 **Rule**:
@@ -494,7 +499,7 @@ The owner asking, from a card's thread or with a question's eye on Waiting on yo
 _Avoid_: mockup request, preview
 
 **Take**:
-One option of an owner question shown as what it would be: a framed prototype, or a diagram of boxes and arrows with what it means in practice. A prototype's take is a key (one capital letter), a label and a file, `public/prototypes/<topic>/<KEY>.js`, whose `render(stage, kit)` draws it into the page's stage. Waiting on you keeps takes in option order with the recommended one tagged: small takes share a grid, while a question with a single take, or with any scrolling or full-screen prototype, shows a choice row above one full-width take, which a choice switches in place, followed by the note and Send ([a question's takes show inline, and back goes one step](docs/adr/2026-10-29-1639-a-questions-takes-show-inline.md), [the board serves every prototype from one template](docs/adr/2026-11-01-1448-the-board-serves-every-prototype-from-one-template.md)).
+One option of an owner question shown as what it would be: a take of a prototype, or a diagram of boxes and arrows with what it means in practice. A prototype's take is a key (one capital letter), a label and a file, `public/prototypes/<topic>/<KEY>.js`, whose `render(stage, kit)` draws it into the page's stage. Waiting on you shows a prototype question's options with a View prototypes button to the prototype page, the full-page viewer that shows one take at a time and drafts a pick for the question's Send; a diagram take draws in the question ([a question's prototypes open in a full-page viewer](docs/adr/2026-11-05-1302-a-questions-prototypes-open-in-a-full-page-viewer.md), [the board serves every prototype from one template](docs/adr/2026-11-01-1448-the-board-serves-every-prototype-from-one-template.md)).
 _Avoid_: variant (the switcher's URL parameter, not the word), mockup
 
 **Kit**:
@@ -525,8 +530,8 @@ Refs in text that Claude or the owner wrote are linked by the renderer, never by
 | `app.html` | The app shell: the sidebar, the view's slot, and its scripts and CSS from `/_hub/app/`, with a board's loads started in its `<head>`; the hub serves it for a browser's load of `/` or a site's page outside try URLs, and every load of a hub page, with the sidebar and its data written in (`hub/shell.mjs` `pageOf`), and the board server for a board's four view paths without them (`shellHtml`) |
 | `router.js` | `AppRouter`: every hub URL as a view and each view as its URL (`ui.test.mjs` tests both), the views the shell mounts in place, framed pages included, and catching taps on links to them and back and forward, with `{idx}` in each history entry and `pushed` on one a push opened; a back arrow goes one step back by them. On the **page tree** each entry also carries `up`, how many of its parents sit under it, which the router writes on every way in, and the arrow goes up a level. It frames the paths `hub/shell.mjs` `pageOf` answers with the shell, which `hub/shell.test.mjs` checks |
 | `shell.js` | `AppShell`: the hub code check that shows New version with an owner-tapped Reload, the sidebar mounted once, one view at a time, asking before leaving an unsaved edit, `/`'s pick of a board, the hub's one stream and which left boards are unchanged, a framed page's URL and title copied to the top, a push tap from `hub/sw.js` or a framed page's view URL (`AppShell.open`) routed in place, and registering `hub/sw.js`, which opens the shell while the host is asleep |
-| `view-settings.js` | Board Settings as a modal over its board, which shell.js mounts: repo and branch (Change uses the same list and GitHub link search as New board), | `view-settings.js` | Board Settings as a modal over its board, which shell.js mounts: repo and branch (Change uses the same list and GitHub link search as New board), ticket source, auto-merge, auto-build, auto-pull (Auto implement Todo cards) with Maximum parallel implementers, auto-triage, reviewers, rules and Close board with its typed-name sheet |
-| `view-questions.js` | Waiting on you as a view: a topic's questions, their takes framed with `?take=` in a fitting grid or a chooser above one full-width frame, which a choice switches in place through the frame's `PrototypeSwitcher.current`, each question's eye, which asks for a prototype of that question, and one Send, which stays while the topic has a question open and otherwise opens the next topic with one, or goes back to the board |
+| `view-settings.js` | Board Settings as a modal over its board, which shell.js mounts: repo and branch (Change uses the same list and GitHub link search as New board), | `view-settings.js` | Board Settings as a modal over its board, which shell.js mounts: repo and branch (Change uses the same list and GitHub link search as New board), ticket source, auto-merge, auto-build, auto-pull (Auto implement Todo cards) with Maximum parallel implementers and planners, auto-triage, reviewers, rules and Close board with its typed-name sheet |
+| `view-questions.js` | Waiting on you as a view: a topic's questions, a prototype question's View prototypes link to its viewer, each question's eye, which asks for a prototype of that question, and one Send, which stays while the topic has a question open and otherwise opens the next topic with one, or goes back to the board |
 | `view-notes.js` | One item's notes, or with `?wave=` a lineup's goal, order and note, as a view, from `GET /api/notes`; the server redirects `plan.html` to `notes.html` |
 | `view-hub.js` | The **hub page** as a view, from `/_hub/api/hub`, refreshed every 30 seconds while it shows; the Usage card, whose Claude model posts `/_hub/settings/claude-model`, Codex share posts `/_hub/settings/codex` and pause line posts `/_hub/settings/pause-at`, with Keep going and Stop banners posting `/_hub/settings/keep-going`, pending prompts of sessions with no board, Send now, then `view-hub-settings.js` below its status |
 | `view-hub-settings.js` | Summary rows opening **hub settings** modals over the hub page, from `/_hub/api/settings`: Notifications with Snooze and Keep awake with their one duration picker (`durationPicker`: chips and a native Custom picker), Quiet hours, Linear (`linear-key.js`’s slot), Rules for every board and Closed boards with Reopen |
@@ -539,14 +544,14 @@ Refs in text that Claude or the owner wrote are linked by the renderer, never by
 | `ui-page-header.js` | `BoardUI.header`, every page's header: the logo (which toggles the sidebar), a back arrow where needed (beside a phone-only logo), the title, then the time and ↻, a board's bulb, and the gear, or a page's own trail. On a page of its own, the back arrow's own script goes one step back, or to its href after a push; in the app shell `router.js` does that. Needs nothing else: `server.mjs` renders each page's `<!--header {…}-->` with it, such as a prototype's, and `hub/hub.mjs` the shell's first sidebar, whose head is one too (`ui-sidebar.js`), each in a vm context |
 | `ui-header.js` | The header's time, or paused until from the shell's pause state, and when it moves, the GitHub status line and its Hub links mark, the Hub links list, the setup checklist, when a refresh asks for a GitHub check, and which board header controls take taps |
 | `ui-threads.js` | Thread messages, with link, status and agent lines, the open card's window over them with its Show more, and the reply form's Done |
-| `ui-questions.js` | Owner question cards with their takes inline and diagrams, answer history, prototype status, a confirm's take link, the topic head's round chip and the Waiting on you topic row; `cardTopics`, which names a card's question topic from its card; `BoardUI.nextQuestion`, the pure move-on rule shared by Send and a prototype pick, and `sentNotice`, the Sent line the board reads on return |
+| `ui-questions.js` | Owner question cards with their View prototypes button and drawn takes, answer history, prototype status, a confirm's line, the topic head's round chip and the Waiting on you topic row; `cardTopics`, which names a card's question topic from its card; `BoardUI.nextQuestion`, the pure move-on rule after a Send, and `sentNotice`, the Sent line the board reads on return |
 | `ui-markdown.js` | The Markdown subset `view-notes.js` renders a card's notes with |
 | `ui-snapshot.js` | The last visit's stored shape and size cap, which threads preload, which controls wait for the fresh board, which lines flash, and what counts as a card's update |
 | `attach.js` | Picking and uploading attachments, each to the site of the board view around its composer |
 | `prototype.html` | The one prototype page: the server fills in a recorded topic's title, header and takes; the stage that contains each take, and the pill's room below it |
-| `prototype-kit.js` | The **kit** and the take loader: each switch ends the last take's cleanup, listeners and timers, renders the next into a fresh stage at the same scroll position, and turns links and forms in the stage into toasts; `prototype-kit.test.mjs` tests it |
-| `prototype-switcher.js` | A prototype page's ‹ take › pill, its keys and `?variant=`, one take alone with `?take=`, `PrototypeSwitcher.current.go(key)` for an in-place switch from Waiting on you, and with `?q=` the pick and note that answer the card's question, then the next open question in its place as a Send moves on, or with none left the board, handed to the app shell when the page is framed in it, with the board’s Sent notice in that top window; uses the shell’s `BoardUI` or loads its question helpers when opened alone; `prototype-switcher.test.mjs` tests its controls and a pick through `mount`, while `ui.test.mjs` owns the move-on rule |
-| `app-core.js` | The view's shared helpers: drafts, seen marks, hiding, and `steady`, which runs a repaint keeping the box being typed in, else the open card's title row, still on screen, and its focus and cursor; where the owner left the board, its scroll and box, kept through `B.keep` and restored after its next first render in the page; re-exports `dialogs.js` as `B.confirm` and `notice` |
+| `prototype-kit.js` | The **kit** and the take loader: each switch ends the last take's cleanup, listeners and timers, renders the next into a fresh stage at the same scroll position, with each box scrolled inside the take scrolled back where the new take draws it, and turns links and forms in the stage into toasts; `prototype-kit.test.mjs` tests it |
+| `prototype-switcher.js` | The full-page viewer's ‹ take › pill, its keys and `?variant=`, and with `?q=` the pick and note drafted for the card's question, then back to that question for its Send, handed to the app shell when the page is framed in it; `prototype-switcher.test.mjs` tests its controls and a pick through `mount` |
+| `app-core.js` | The view's shared helpers: drafts, read marks, hiding, and `steady`, which runs a repaint keeping the box being typed in, else the open card's title row, still on screen, and its focus and cursor; where the owner left the board, its scroll and box, kept through `B.keep` and restored after its next first render in the page; re-exports `dialogs.js` as `B.confirm` and `notice` |
 | `dialogs.js` | `BoardDialogs.confirm` and `notice`, which every board page's dialogs go through, and `fitSheet`, the sheets’ shared phone keyboard handling, `repoSheet` for New board and Repo → Change, and `ticketsControl`, shared by New board and Board Settings, which opens `linear-key.js`’s modal for Linear without a working key; loaded on every page |
 | `rules-editor.js` | `RulesEditor`, the rules list on Board Settings and the Hub page, with its own CSS; `ui.test.mjs` tests its pure parts |
 | `app-threads.js` | Loading a thread, once at a time per card; an open card's thread, its reply box, quick replies and Done |

package/README.md

@@ -53,7 +53,7 @@ To have the hub board's session running in a terminal you can attach to, run `ki
 - `kickflip hub`: attach to the hub board's tmux session
 - `kickflip sessions`: list each board's session
 - `kickflip start <route>` / `resume <route>`: start or resume a board's session
-- `kickflip restart <route>` / `logs <route>`: restart a site or read its log
+- `kickflip restart [route]` / `logs <route>`: restart a site (the hub with no route) or read its log
 - `kickflip close <route>` / `reopen <route>`: close a board and bring it back
 - `kickflip export <route>` / `import <file>`: move a board to another host
 - `kickflip notifications`: set push notifications