@lovek4d/kickflip 0.10.1 → 0.11.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CONTEXT.md +19 -16
- package/SKILL.md +7 -7
- package/bin/event-lines.mjs +1 -1
- package/board/bin/board.mjs +30 -17
- package/board/domain.mjs +7 -7
- package/board/headless.mjs +8 -8
- package/board/public/app-cards.js +2 -0
- package/board/public/app-header.js +8 -0
- package/board/public/app-lanes.js +43 -19
- package/board/public/app-snapshot.js +1 -2
- package/board/public/app-threads.js +2 -2
- package/board/public/app.html +0 -1
- package/board/public/app.js +25 -27
- package/board/public/col-resize.js +25 -44
- package/board/public/dialogs.js +2 -2
- package/board/public/new-task.js +2 -2
- package/board/public/prompts.js +1 -1
- package/board/public/prototype-kit.js +1 -1
- package/board/public/prototype-switcher.js +3 -8
- package/board/public/prototype.html +2 -6
- package/board/public/router.js +16 -22
- package/board/public/shell.js +3 -39
- package/board/public/style.css +47 -95
- package/board/public/ui-cards.js +29 -22
- package/board/public/ui-enums.js +3 -3
- package/board/public/ui-page-header.js +2 -2
- package/board/public/ui-prompts.js +1 -1
- package/board/public/ui-questions.js +2 -3
- package/board/public/ui.js +10 -2
- package/board/public/view-hub.js +1 -1
- package/board/public/view-questions.js +7 -26
- package/board/server.mjs +18 -18
- package/board/store.mjs +32 -32
- package/hub/hub.mjs +8 -8
- package/hub/prompts.mjs +2 -2
- package/hub/review-send.mjs +1 -1
- package/hub/slack.mjs +4 -2
- package/hub/views.mjs +1 -1
- package/package.json +1 -1
- package/board/public/app-needs.js +0 -248
package/CONTEXT.md
CHANGED
|
@@ -51,7 +51,7 @@ One page's content in the app shell, mounted when its URL opens and unmounted, w
|
|
|
51
51
|
_Avoid_: screen, tab, page (a page is its own document)
|
|
52
52
|
|
|
53
53
|
**Page tree**:
|
|
54
|
-
The levels back climbs in the app shell: a board, its Waiting on you, then a separately opened prototype page tied to one of its questions by `?q=`. On each, the back arrow, the browser's back and a swipe all go up one level: from a prototype to Waiting on you on its question, from there to the board, with the card still open when the owner left the board from that card's thread. However the owner arrives, by a push, a link or a reload, the levels above are written into history under the page first ([Back follows the page tree](docs/adr/2026-10-30-1125-back-follows-the-page-tree.md)).
|
|
54
|
+
The levels back climbs in the app shell: a board, its Waiting on you, then a separately opened prototype page tied to one of its questions by `?q=`. On each, the back arrow, the browser's back and a swipe all go up one level: from a prototype to Waiting on you on its question, from there to the board, with the card still open when the owner left the board from that card's thread. However the owner arrives, by a push, a link or a reload, the levels above are written into history under the page first ([Back follows the page tree](docs/adr/2026-10-30-1125-back-follows-the-page-tree.md)). The tree is the same at every width ([the board has no Needs you deck or pane](docs/adr/2026-11-12-0700-the-board-has-no-needs-you-deck-or-pane.md)).
|
|
55
55
|
_Avoid_: nav stack, breadcrumbs
|
|
56
56
|
|
|
57
57
|
**Hub page**:
|
|
@@ -223,7 +223,7 @@ Claude reviewing a board's repo, chosen by `hub/board-repo.mjs` `boardRepo`, wit
|
|
|
223
223
|
_Avoid_: improvements round, audit (for the whole review), bulb round
|
|
224
224
|
|
|
225
225
|
**Reviewers**:
|
|
226
|
-
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 item file 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 messages per PR, not per card, in each board's `data/pr-slack.json` `{<owner/repo#n>: {head, links: {<name>: {channel, thread_ts, ts, reactions}}, replies}}`: a card holds 1:m PRs, and each PR has 1:m reviewer DMs sharing the same bumps and reactions. Each reviewer's posts from a board go in one thread per Slack day, kept in `data/review-digests.json` ([review posts go into one day thread per board](docs/adr/2026-11-11-1600-review-posts-go-into-one-day-thread-per-board.md)). For 7 days the hub hears that thread: each new message wakes the board's orchestrator, which answers only about the board,
|
|
226
|
+
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 item file 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 messages per PR, not per card, in each board's `data/pr-slack.json` `{<owner/repo#n>: {head, links: {<name>: {channel, thread_ts, ts, reactions}}, replies}}`: a card holds 1:m PRs, and each PR has 1:m reviewer DMs sharing the same bumps and reactions. Each reviewer's posts from a board go in one thread per Slack day, kept in `data/review-digests.json` ([review posts go into one day thread per board](docs/adr/2026-11-11-1600-review-posts-go-into-one-day-thread-per-board.md)). For 7 days the hub hears that thread: each new message wakes the board's orchestrator, which answers only about the board, or files a request for work discussing ([a new task is a conversation](docs/adr/2026-11-12-0500-a-new-task-is-a-conversation.md), [reviewers ask the board in the day thread](docs/adr/2026-11-12-0000-reviewers-ask-the-board-in-the-day-thread.md)). The card, Stale age, hub Slack link and digest read each reviewer's first link across the card's PRs, with an item's older `review_link_ts` and slack-bridge topic files only as a fallback ([Slack sends hang off PRs and go out from the hub tick](docs/adr/2026-11-07-0300-slack-sends-hang-off-prs-and-go-out-from-the-hub-tick.md)). The hub sends them as the owner, through the Slack user token pasted on Hub › Integrations › Slack and kept in `~/.claude/kickflip/secrets.json` beside Linear's key, opening the owner's DM with each reviewer, ending every message with a “- :claude_kickflip:” line (“- :robot_face:” while `emoji.list` doesn't show the emoji, as under a token without `emoji:read`), by which the hub tells its own and the orchestrator's posts from the owner's ([every Slack message ends with a sign-off line](docs/adr/2026-11-12-0400-every-slack-message-ends-with-a-sign-off-line.md)), and records each message as it posts, so a failed one goes again next poll and a posted one never twice ([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 to 17:00 digest window ([kickflip owns the reviewer record](docs/adr/2026-11-01-2347-kickflip-owns-the-reviewer-record.md)).
|
|
227
227
|
_Avoid_: approvers, watchers
|
|
228
228
|
|
|
229
229
|
**Finished item file**:
|
|
@@ -299,7 +299,7 @@ _Avoid_: backlog item, todo
|
|
|
299
299
|
_Avoid_: history, old cards
|
|
300
300
|
|
|
301
301
|
**Lane**:
|
|
302
|
-
Where a card sits (In Review, In Progress, Todo, Done), 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 builder runs on the card: a running build agent, a **checking** item, or a started card between runs; a ready PR whose CI is red, or a red draft on a board that **skips the draft**, waits in In Review reading "Fix the failing CI" until a fix builder starts ([In Progress means a builder runs](docs/adr/2026-11-09-1804-in-progress-means-a-builder-runs.md)). A work card stores its **lane** (todo, progress, review, done, with `lane_at`), which one writer moves with a "Moved to <lane>: <why>" thread line; a card has no status, and held, blocked, merged and dropped are facts beside the lane ([a card stores its lane, and facts replace statuses](docs/adr/2026-11-07-1400-a-card-stores-its-lane-and-facts-replace-statuses.md)). A work card that has left Todo never drops back to it: held, blocked or **bumped out**, its build takes a **card pause** In Progress ([a card pause stops its builder at its next stopping point](docs/adr/2026-11-09-1300-a-card-pause-stops-its-builder-at-its-next-stopping-point.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)). 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 into In Review: "Your reply waits on the orchestrator" until Claude answers, then the owner's Done, its next step "Tap Done" ([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 reopened card goes to In Progress only once a builder starts on it ([In Progress means a builder runs](docs/adr/2026-11-09-1804-in-progress-means-a-builder-runs.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)): every lane but Done lists its bumped cards first, the earliest bump on top ([a bump marks the priority through every lane](docs/adr/2026-11-06-1700-a-bump-marks-the-priority-through-every-lane.md)); Todo then lists 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, after its bumped cards, by when each came into the lane, its reopening or its latest build agent's start, the newest arrival on top; In Review, after its bumped cards, by when the PR was first sent to a reviewer, or a reopened card's reopening, the newest on top; Done by when each card closed, or for an answered ask when Claude last answered, the most recent on top. Done shows 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 fold into the one Done list, the kind shown in the ticket slot](docs/adr/2026-11-09-1430-answered-asks-fold-into-the-one-done-list.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.
|
|
302
|
+
Where a card sits (In Review, In Progress, Todo, Done), 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 builder runs on the card: a running build agent, a **checking** item, or a started card between runs; a ready PR whose CI is red, or a red draft on a board that **skips the draft**, waits in In Review reading "Fix the failing CI" until a fix builder starts ([In Progress means a builder runs](docs/adr/2026-11-09-1804-in-progress-means-a-builder-runs.md)). A work card stores its **lane** (todo, progress, review, done, with `lane_at`), which one writer moves with a "Moved to <lane>: <why>" thread line; a card has no status, and held, blocked, merged and dropped are facts beside the lane ([a card stores its lane, and facts replace statuses](docs/adr/2026-11-07-1400-a-card-stores-its-lane-and-facts-replace-statuses.md)). A work card that has left Todo never drops back to it: held, blocked or **bumped out**, its build takes a **card pause** In Progress ([a card pause stops its builder at its next stopping point](docs/adr/2026-11-09-1300-a-card-pause-stops-its-builder-at-its-next-stopping-point.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)). 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 into In Review: "Your reply waits on the orchestrator" until Claude answers, then the owner's Done, its next step "Tap Done" ([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 reopened card goes to In Progress only once a builder starts on it ([In Progress means a builder runs](docs/adr/2026-11-09-1804-in-progress-means-a-builder-runs.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)). Todo's header has a filter: a funnel opening five boxes (Ready, Discussing, Planning, Blocked, Held), all checked, where an unchecked box hides every Todo card with that property and nothing else; the funnel goes orange and the count reads "N of M" while one is unchecked ([the Todo header has a filter](docs/adr/2026-11-12-0600-the-todo-header-has-a-filter.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)): every lane but Done lists its bumped cards first, the earliest bump on top ([a bump marks the priority through every lane](docs/adr/2026-11-06-1700-a-bump-marks-the-priority-through-every-lane.md)); Todo then lists 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, after its bumped cards, by when each came into the lane, its reopening or its latest build agent's start, the newest arrival on top; In Review, after its bumped cards, by when the PR was first sent to a reviewer, or a reopened card's reopening, the newest on top; Done by when each card closed, or for an answered ask when Claude last answered, the most recent on top. Done shows 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 fold into the one Done list, the kind shown in the ticket slot](docs/adr/2026-11-09-1430-answered-asks-fold-into-the-one-done-list.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.
|
|
303
303
|
_Avoid_: column, status (status is the item's own field)
|
|
304
304
|
|
|
305
305
|
**Checking**:
|
|
@@ -311,7 +311,7 @@ A card the board reads as having had no updates for a while, on the signals it a
|
|
|
311
311
|
_Avoid_: stalled (only the orchestrator's flag), old, overdue
|
|
312
312
|
|
|
313
313
|
**Footer status**:
|
|
314
|
-
The words after the time on a card's last line: held, blocked by,
|
|
314
|
+
The words after the time on a card's last line: held, then blocked by, or the card's **phase** word (every lane but In Progress) when neither is there, then a grey "stale", a grey "held while host recovers", an orange "pausing · <cause>" or a grey "paused · <cause>" in place of held or blocked by ([a card pause stops its builder at its next stopping point](docs/adr/2026-11-09-1300-a-card-pause-stops-its-builder-at-its-next-stopping-point.md)), then an In Progress card's phase bars (owner, gh327-pause; [every lane has phases](docs/adr/2026-11-11-1200-every-lane-has-phases.md)). Action needed, the unread count and a red "stalled", rightmost, go on a row of their own under it, drawn only when it has one ([Action needed and new messages get their own row](docs/adr/2026-11-12-0630-action-needed-and-new-messages-get-their-own-row.md)).
|
|
315
315
|
_Avoid_: time line, status line (the line under the title)
|
|
316
316
|
|
|
317
317
|
**Next step**:
|
|
@@ -323,27 +323,31 @@ Who the card is waiting for: the owning session's check, the owner's Ready, the
|
|
|
323
323
|
_Avoid_: blocked by, assignee
|
|
324
324
|
|
|
325
325
|
**Phase**:
|
|
326
|
-
Where a work card is within its lane, stored on the card beside its lane and written with it ([every lane has phases]({ADR})). Todo: new, grilling, prototyping, staging, ready. In Progress: reading, building, testing, checking, landing, shown only as the progress bar. In Review: draft, reviewers, merge, stale. Done: merged, closed. The settle pass writes In Progress and In Review phases from the builder and the PR, a close writes merged or closed, and a phase change inside one lane writes no thread line. Every lane but In Progress ends the card's last line with the phase word, toned by who acts next: grey new, draft, stale, closed; blue grilling, prototyping; orange staging, "pending review", "pending merge"; green ready; purple merged.
|
|
326
|
+
Where a work card is within its lane, stored on the card beside its lane and written with it ([every lane has phases]({ADR})). Todo: new, discussing, grilling, prototyping, staging, ready. In Progress: reading, building, testing, checking, landing, shown only as the progress bar. In Review: draft, reviewers, merge, stale. Done: merged, closed. The settle pass writes In Progress and In Review phases from the builder and the PR, a close writes merged or closed, and a phase change inside one lane writes no thread line. Every lane but In Progress ends the card's last line with the phase word, toned by who acts next: grey new, draft, stale, closed; blue grilling, prototyping, discussing on the owner's turn; orange staging, "pending review", "pending merge"; green ready; purple merged; grey discussing on the orchestrator's turn.
|
|
327
327
|
_Avoid_: state (the old name of a Todo card's phase), status (the wave entry's `status` is a different field)
|
|
328
328
|
|
|
329
329
|
**Todo phase**:
|
|
330
|
-
What a card made from a **New task** does next: **grilling** (questions on the card), **prototyping** (takes on the card), **staging** (the owner has acted: a Send that left
|
|
330
|
+
What a card made from a **New task** does next: **discussing** (a conversation in its thread, from the orchestrator's first reply: a New task's Discuss, a reviewer's Slack request for work, or a GitHub or Linear issue named in an ask; it reads just "discussing", blue on the owner's turn and grey on the orchestrator's, never goes to In Review, and a discussion the owner settles without a build is closed from there with no ticket), **grilling** (questions on the card), **prototyping** (takes on the card; answering a round returns the card to discussing), **staging** (the owner has acted: a Send that left a grilled card nothing open, an Implement, or a Reply on a ready card, whose words the board wrote into its notes; the orchestrator judges it, first folding a discussed card's agreement into a Build notes section) or **ready** (its notes leave the owner nothing to decide, so it can be built; the plan lives only in the notes). The orchestrator reaches for the next step in one order: keep discussing, a visual once the topic is complicated, a grill or prototype when asked or clearly useful, and Implement only on the owner's explicit word ([a new task is a conversation](docs/adr/2026-11-12-0500-a-new-task-is-a-conversation.md)). Only the board sets staging; the session sets the others with `item set --phase` (`reply` on a New card sets discussing), and ready only from staging, with a `--text` line saying what it checked against the board, or on an Implement ask it files. A finished grill's questions are **screened** first: they wait on the orchestrator, which settles the ones the board already answers, and reach the owner with `question publish` or 15 minutes on ([every signal that wakes the orchestrator says what to do](docs/adr/2026-11-07-0043-every-signal-that-wakes-the-orchestrator-says-what-to-do.md)). A question added on a ready or staging card moves it to grilling. Moving a discussing, staging or ready card to grilling or prototyping starts that round from code ([staging, then ready](docs/adr/2026-11-07-0700-staging-then-ready.md)). The board enforces the five: `--phase` refuses any other, on a card that has left Todo too, and `--state` is refused with a pointer to `--phase`, 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 an older card an agent added with `item add` and no `--phase`, 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)); on a board `item add` now refuses a card with no `--phase` ([a board's lessons live in the product](docs/adr/2026-11-06-1700-a-boards-lessons-live-in-the-product.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 staging card reads an orange "staging" there and is never pulled ([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)).
|
|
331
331
|
_Avoid_: triage state, card state, status (the wave entry's `status` is a different field)
|
|
332
332
|
|
|
333
333
|
**Action needed**:
|
|
334
334
|
The orange words last among the orange ones on a card's time line ("10:26 · held · blocked by #53 · Action needed"), on a card waiting on the owner, in any lane ([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)): an open question or a prototype pick, a green draft's Ready, the Done of an ask, manual steps on an approved PR, with **auto-merge** off an approved PR's Merge, or a **stalled** card's "stalled: <why>", which a message in its thread clears, its Send or Reply orange. It links to the thing to act on. Reviewer waits and held cards get none ([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)), and so does a reopened card waiting only on the owner's Done, which is only waiting to be closed ([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)). An unstarted card with open questions carries it in Todo ([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)).
|
|
335
|
-
_Avoid_: open items, needs you (Needs you is
|
|
335
|
+
_Avoid_: open items, needs you (Needs you is what waits on the owner)
|
|
336
336
|
|
|
337
337
|
**Request**:
|
|
338
338
|
The owner's ask for a grill, a prototype or a **visual** on a card: the thread composer's fire, eye or image, each sending at once, or /grill, /prototype or /visual typed in the box on Reply, sending `grill-more`, `prototype-request` or `visual-request` with whatever was typed; a question's own eye on Waiting on you asks for a prototype of that question. A request with nothing typed is one gray **status line** in the thread, "Grill requested", "Prototype requested" or "Visual requested", keyed `grill`, `prototype` or `visual` as every button without a text box keys its line ([a button without a text box posts a keyed status line](docs/adr/2026-11-06-0021-a-button-without-a-text-box-posts-a-keyed-status-line.md)); one with text is the owner's message carrying it, with that status in the message's footer, and "waiting…" to its right until Claude picks it up, then "thinking…". An answer submitted from Waiting on you is likewise a message whose footer reads "answers submitted". A question asked for a prototype reads "prototype requested", locked, until a question naming it in `round_of` resolves it, and `question resolve` refuses it; a prototype request still waiting 30 minutes on with no prototype agent running comes back to the session as `prototype-overdue` ([a button tap is a status line or a message footer](docs/adr/2026-11-04-2130-a-button-tap-is-a-status-line-or-a-message-footer.md), [a prototype request waits for its prototype](docs/adr/2026-11-04-2130-a-prototype-request-waits-for-its-prototype.md)).
|
|
339
339
|
_Avoid_: Grill button, Prototype button (on a card)
|
|
340
340
|
|
|
341
|
+
**Brief**:
|
|
342
|
+
The orchestrator's handover to a grill, prototype or **visual** agent: what the discussion settled, what is still open, what the agent's questions, takes or page should cover, and the files that matter. Every such launch needs one: a **request**, an arrival in Todo, a gate's yes, a prototype answer with no pick or `item set --phase grilling|prototyping` leaves the card owing it, a `brief` wait for the orchestrator, and `item brief <key> --kind grill|prototype|visual --file <draft.md>` writes it into the card's notes as "Brief for <kind> round N", from which the board launches the agent, which reads it first. While a brief is owed the card reads blue "preheating" (a grill), "planning prototype" or "planning visual"; its agent then reads "grilling", "prototyping" or "generating visual" ([every planner launches from the orchestrator's brief](docs/adr/2026-11-12-0600-every-planner-launches-from-the-orchestrators-brief.md)).
|
|
343
|
+
_Avoid_: briefing (as a status word), the builder's brief (the board's own launch prompt)
|
|
344
|
+
|
|
341
345
|
**Visual**:
|
|
342
|
-
A one-off HTML page that answers the owner in a card's thread visually, such as a diagram, a flow or a comparison. It is not a prototype or a grill: it asks no question, has no takes and leaves the card as it was. The thread's image or /visual (a **request**)
|
|
346
|
+
A one-off HTML page that answers the owner in a card's thread visually, such as a diagram, a flow or a comparison. It is not a prototype or a grill: it asks no question, has no takes and leaves the card as it was. The thread's image or /visual (a **request**) leaves the card owing the orchestrator a visual **brief**, from which the board launches a headless visual agent on Sonnet. The agent runs beside any other agent on the card, as its own record `visual-<its brief's time in ms>`. Its page goes in with `visual add`, to `public/visuals/<card id>/<slug>.html`, a new page each time. The page shows in the thread as a link line, "<title> →", that opens it full page. A card's visual requests are drawn one after another ([a visual is a page an agent draws for a thread](docs/adr/2026-11-05-1921-a-visual-is-a-page-an-agent-draws-for-a-thread.md)).
|
|
343
347
|
_Avoid_: diagram (one kind of visual), prototype (takes for a decision)
|
|
344
348
|
|
|
345
349
|
**Action button**:
|
|
346
|
-
The open card's one workflow button, which `board/domain.mjs` picks as the card's `actionButton`: **Needs you** (`openQuestions`) while it has open questions or a prototype pick, opening the first; otherwise none; an ask waiting on the owner's Done has it in its thread box, beside Reply. A grill or prototype is asked for from the thread's fire and eye (**request**), and the card
|
|
350
|
+
The open card's one workflow button, which `board/domain.mjs` picks as the card's `actionButton`: **Needs you** (`openQuestions`) while it has open questions or a prototype pick, opening the first; otherwise none; an ask waiting on the owner's Done has it in its thread box, beside Reply. A grill or prototype is asked for from the thread's fire and eye (**request**), and the card owes the orchestrator that planner's **brief**, reading a blue "preheating" (a grill) or "planning prototype" until the orchestrator writes it, then a blue planner line "grilling" or "prototyping" once that planner runs; a visual reads "planning visual", then "generating visual" ([every planner launches from the orchestrator's brief](docs/adr/2026-11-12-0600-every-planner-launches-from-the-orchestrators-brief.md)) ([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)). 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)). It reaches the prototypes too, as each is a question on the card with a View prototypes link, Done cards included; there is no Prototypes button ([the Needs you button reaches the prototypes, and the Prototypes button is dropped](docs/adr/2026-11-09-1100-needs-you-button-reaches-the-prototypes.md)).
|
|
347
351
|
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 Questions orange (a pick makes Prototypes orange too), 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 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)).
|
|
348
352
|
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.
|
|
349
353
|
_Avoid_: Open items, Action needed (the badge)
|
|
@@ -468,7 +472,7 @@ _Avoid_: copy, checkout, live folder (for the builder's)
|
|
|
468
472
|
### Talking with the owner
|
|
469
473
|
|
|
470
474
|
**New task**:
|
|
471
|
-
A free-form request or question the owner sends from the board's + button (or by pressing n twice). Code and events call it an **ask**: an `ask` event whose thread is `ask:<event id>`. From the moment it arrives it is a task card, keyed `T-<n>` and titled from its first line, whose thread opens with the owner's message: a **New card** at the top of Todo, a New mark in its ticket slot, with no Action needed, until Claude sorts it one of three ways ([the + makes a New card, which Claude files, folds or answers](docs/adr/2026-10-29-1639-the-plus-makes-a-new-card.md), [every ask is a task card from the moment it arrives](docs/adr/2026-11-09-1900-every-ask-is-a-task-card-from-the-moment-it-arrives.md)): sets its **card state** (`item set --phase`); merges it into the card it's about, which drops the New card, shows its thread in the other card's and names that card in a banner (`item relate-ask`, undone by `ask unfold`); or answers it (`reply <key>`), which
|
|
475
|
+
A free-form request or question the owner sends from the board's + button (or by pressing n twice). Code and events call it an **ask**: an `ask` event whose thread is `ask:<event id>`. From the moment it arrives it is a task card, keyed `T-<n>` and titled from its first line, whose thread opens with the owner's message: a **New card** at the top of Todo, a New mark in its ticket slot, with no Action needed, until Claude sorts it one of three ways ([the + makes a New card, which Claude files, folds or answers](docs/adr/2026-10-29-1639-the-plus-makes-a-new-card.md), [every ask is a task card from the moment it arrives](docs/adr/2026-11-09-1900-every-ask-is-a-task-card-from-the-moment-it-arrives.md)): sets its **card state** (`item set --phase`); merges it into the card it's about, which drops the New card, shows its thread in the other card's and names that card in a banner (`item relate-ask`, undone by `ask unfold`); or answers it (`reply <key>`), which starts its discussion: the card reads **discussing** in Todo, never In Review, and an answer that never goes to build is closed from there ([a new task is a conversation](docs/adr/2026-11-12-0500-a-new-task-is-a-conversation.md)). A Discuss task is answered this way unless it asks for a grill, a prototype or a visual itself; an Implement task is filed ready. Deleting the message of a card still New removes the card. An ask never draws as its own row: the board server files one from before asks arrived as cards as its card, an answered one closed in Done at its answer time ([old asks migrate into cards, and the ask-only records retire](docs/adr/2026-11-09-2000-old-asks-migrate-into-cards-and-the-ask-only-records-retire.md)). An answer that leaves a question open on it keeps it in Todo with Action needed, never in Done, until the owner answers and Claude replies, or it is closed; it stays in Todo while Claude takes up the answer ([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)). When another board fits it better, the owner can have it **moved there** (`ask move`): it becomes a New card on that board reading "Moved from <this board>", and here its unstarted card is dropped, leaving only the ask's thread line linking to it. Folding is within one board; a move is between boards._Avoid_: ask (in what the owner reads), message, prompt, Waiting for Claude strip
|
|
472
476
|
|
|
473
477
|
**Thread**:
|
|
474
478
|
The conversation on one work item: Claude's reports, builders' status lines, the board's status lines, the owner's messages, mirrored GitHub comments, and answers to the item's questions. Every line the board (Kickflip) writes is a status line, a mark and at most 100 characters, red when it is a fault, which alone of them counts as unread; only the orchestrator's own words make a message titled Orchestrator, at most 2000 characters ([the board writes status lines, and only the orchestrator writes messages](docs/adr/2026-11-09-1200-the-board-writes-status-lines-and-only-the-orchestrator-writes-messages.md)). An In Review card's reply form sends with Reply then Done, which closes the card; a Todo card closes from Close, right of Hold in its actions, and an In Progress card has neither, only Send ([Done shows only in In Review, beside Reply](docs/adr/2026-11-05-1918-done-shows-only-in-in-review-beside-reply.md)).
|
|
@@ -477,7 +481,7 @@ An owner message Claude hasn't answered yet ends with **waiting…**, or **think
|
|
|
477
481
|
_Avoid_: comments, chat
|
|
478
482
|
|
|
479
483
|
**Unread message**:
|
|
480
|
-
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.
|
|
484
|
+
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. Their count reads in bold orange as "3 new messages" on the row under the card's footer, after any Action needed, until the card is opened.
|
|
481
485
|
_Avoid_: inbox, notification. "New" names it only in that count's "N new messages"; a New card is an unsorted ask.
|
|
482
486
|
|
|
483
487
|
**Read mark**:
|
|
@@ -513,11 +517,11 @@ The group an owner question belongs to; an item's questions use the topic `item:
|
|
|
513
517
|
_Avoid_: category, section
|
|
514
518
|
|
|
515
519
|
**Needs you**:
|
|
516
|
-
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))
|
|
520
|
+
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)): the hub's count of it per board, and its lines in the hub's needs. The board draws no box of it ([the board has no Needs you deck or pane](docs/adr/2026-11-12-0700-the-board-has-no-needs-you-deck-or-pane.md)): a card waiting on the owner shows its **Action needed**, a pending prompt waits on the hub page, and the board and Waiting on you are a board's two pages at every width, the board header's ? (with the open-question count as its badge) opening Waiting on you, whose check goes back to the board ([Board and Open questions are two pages](docs/adr/2026-11-07-1300-board-and-open-questions-are-two-pages.md)).
|
|
517
521
|
_Avoid_: inbox, digest
|
|
518
522
|
|
|
519
523
|
**Pending prompt**:
|
|
520
|
-
A permission prompt or `AskUserQuestion` from a background board session, which its hook hands to the hub and holds the session on until the owner answers
|
|
524
|
+
A permission prompt or `AskUserQuestion` from a background board session, which its hook hands to the hub and holds the session on until the owner answers on the hub page, which lists every pending prompt, a board session's naming its board: Allow once, Always allow or Deny, or the question's options. Always allow returns the session rule to Claude Code and keeps that same rule in the hub's `prompts.json`, keyed by session id. The hub remembers rules only with a reliable process start time and binds board rules to the current ownership's `owner.since`; ownership commands clear remembered rules and pending prompts for both the old and new sessions, including boardless entries, even while the hub is stopped. A later exact match on its command, absolute path, domain or bare tool name is allowed immediately, with no push or Needs you line; prefixes and globs never widen a match, and `AskUserQuestion` always asks. Rules end when the session stops or its board's owning session changes, and the hub page lists them read-only under the board. With no answer in 10 minutes the call is denied with a note to ask on the card instead ([a background session's prompts and questions come to the phone](docs/adr/2026-10-30-1516-background-sessions-prompts-come-to-the-phone.md)).
|
|
521
525
|
_Avoid_: permission request, approval, dialog
|
|
522
526
|
|
|
523
527
|
**Event**:
|
|
@@ -538,7 +542,7 @@ _Avoid_: unread, queued
|
|
|
538
542
|
|
|
539
543
|
|
|
540
544
|
**Prototype**:
|
|
541
|
-
A page that shows each option of one owner question as it would ship, built from the board's real components fed fake data. An agent records it with `board.mjs prototype add <topic>` in the site's `data/prototypes.json`, with its title, card and takes, and writes only the take files; the board serves `prototype-<topic>.html` from its one template, `board/public/prototype.html`. `question add` accepts a prototype url only for a recorded topic, with option ids a non-empty subset of its take keys in order, without repeats, and every take file written ([the board serves every prototype from one template](docs/adr/2026-11-01-1448-the-board-serves-every-prototype-from-one-template.md)). A **served round** is recorded with `--served <path>`: it has no take files, its page lives in the board's **base prototype worktree** (`~/.claude/kickflip/worktrees/<route>-prototypes`, on main), and its named **states** show as chips in the viewer's bar ([a prototype round is a page in the board's base prototype worktree](docs/adr/2026-11-06-1500-a-prototype-round-is-a-page-in-the-boards-base-worktree.md)). The page is the **viewer**: full bleed with no header, a ✕ that goes back, one take at a time switched by the footer's ‹ › pager, ←/→ or a swipe, Choose this on the footer's second row, and on a card with earlier rounds a Round pill opening a sheet of them ([prototypes have their own button and a full-bleed viewer](docs/adr/2026-11-07-0300-prototypes-have-their-own-button-and-viewer.md)). The footer runs the full width of the bottom edge at every width.
|
|
545
|
+
A page that shows each option of one owner question as it would ship, built from the board's real components fed fake data. An agent records it with `board.mjs prototype add <topic>` in the site's `data/prototypes.json`, with its title, card and takes, and writes only the take files; the board serves `prototype-<topic>.html` from its one template, `board/public/prototype.html`. `question add` accepts a prototype url only for a recorded topic, with option ids a non-empty subset of its take keys in order, without repeats, and every take file written ([the board serves every prototype from one template](docs/adr/2026-11-01-1448-the-board-serves-every-prototype-from-one-template.md)). A **served round** is recorded with `--served <path>`: it has no take files, its page lives in the board's **base prototype worktree** (`~/.claude/kickflip/worktrees/<route>-prototypes`, on main), and its named **states** show as chips in the viewer's bar ([a prototype round is a page in the board's base prototype worktree](docs/adr/2026-11-06-1500-a-prototype-round-is-a-page-in-the-boards-base-worktree.md)). The page is the **viewer**: full bleed with no header, a ✕ that goes back, one take at a time switched by the footer's ‹ › pager, ←/→ or a swipe, Choose this on the footer's second row, and on a card with earlier rounds a Round pill opening a sheet of them ([prototypes have their own button and a full-bleed viewer](docs/adr/2026-11-07-0300-prototypes-have-their-own-button-and-viewer.md)). The footer runs the full width of the bottom edge at every width. It is a page of its own at every width ([the board has no Needs you deck or pane](docs/adr/2026-11-12-0700-the-board-has-no-needs-you-deck-or-pane.md)).
|
|
542
546
|
_Avoid_: mockup, demo page
|
|
543
547
|
|
|
544
548
|
**Prototype round**:
|
|
@@ -615,9 +619,8 @@ Refs in text that Claude or the owner wrote are linked by the renderer, never by
|
|
|
615
619
|
| `app-lanes.js` | Lanes, Done's and Asks' Show more, Done's finished-item-file folds, Todo's **wave bands** with their Implement and Triage, and Plan waves |
|
|
616
620
|
| `new-task.js` | The + button, its new-task sheet and press-n-twice shortcut, on every page of a board |
|
|
617
621
|
| `app-asks.js` | Bump, edit and delete for a New card or pending message, and ⌘↵ in a thread box |
|
|
618
|
-
| `app-needs.js` | The Needs you box, led by the board session's pending prompts |
|
|
619
622
|
| `ui-prompts.js` | A pending prompt's Needs you line: its details, Allow once, Always allow and Deny, or a question's options, Skip and Send |
|
|
620
|
-
| `prompts.js` | `PromptAnswers`, answering pending prompts from their lines on
|
|
623
|
+
| `prompts.js` | `PromptAnswers`, answering pending prompts from their lines on the hub page: which taps send at once, Always allow's confirmation, and the picks a Send waits on |
|
|
621
624
|
| `app-arch.js` | The bulb at the foot of the board and its **architecture review** sheet: the last review, Run with its confirm, what a review waits on, and the bulb's glow while one runs |
|
|
622
625
|
| `app-reader.js` | The **reader sheet**: a run's transcript from its View transcript link (the whole run as rows, each tool call's output on a tap, or the raw log; following it as it grows) and a card's or wave's Notes, opened over the board from their links, closing on ✕, Escape, the dim area or Back |
|
|
623
626
|
| `app-banner.js` | The answer banner, its tap and its ✕ |
|