You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: packages/framework/dashboard/components/TicketsPage.SPEC.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,7 @@ The user wants to see the whole backlog — not one project's slice of it — de
12
12
-**Click-to-filter** - clicking a row's topic adds that topic to the filter, clicking its claim marker narrows to claimed tickets; both add to what is already filtered rather than replacing it.
13
13
-**Plan it or work it from the row** - a ticket can be handed to a planning agent or to an unattended work agent without leaving the page.
14
14
-**Queue the whole shown set** - a button beside the page's heading adds every unclaimed shown ticket to the AI queue (a ticket already queued stays as it is), counting on its label what one click adds; no agent starts — the queue's own consumers do that.
15
+
-**Queue plans for the whole shown set** - a sibling button queues one plan ask per shown ticket still to plan — the plan-tickets ask, placed by the ticket's priority — skipping tickets already planned, already queued, or claimed.
15
16
-**Filtered-away tickets are accounted for** - the page says how many tickets the filters hide and offers to clear them; a project the user deselected disappears silently instead.
16
17
17
18
## Business logic
@@ -92,6 +93,22 @@ Once a click has queued the shown set, the button reads "Queued" and rests; any
92
93
93
94
Queueing rather than starting agents keeps the one click cheap and durable: entries are what the framework already picks up on its own, survive anything that interrupts the work, and spend nothing until an agent actually starts. Skipping already-queued tickets matters because a duplicate entry would outlive its agent's check-off as an open entry naming a closed ticket, costing the sweep an agent.
94
95
96
+
### Queue plans for the whole shown set
97
+
98
+
#### User story
99
+
100
+
The user has filtered the backlog to a slice they intend to work soon and wants plans written for all of it first — to read before committing agents — without asking ticket by ticket.
101
+
102
+
#### Business logic
103
+
104
+
Beside the queue-the-shown-set button sits its plan sibling: one click queues, for every shown ticket that has no plan yet and no claim on it, the ask for that ticket's plan — the same wording the plan-tickets preset queues — placed in the AI queue by the ticket's own priority, walked in the shown order. A drain agent reaching such an entry writes the plan. No agent starts from the click.
105
+
106
+
The click leaves alone what queueing again would waste: a ticket whose plan ask is already an open entry (recognized by its exact wording), and a ticket already queued for implementation — its work would land before a trailing plan could matter. The button's label counts only what it will ask for, saying "unplanned" the moment its count differs from the shown tally; hovering explains the mechanics, the worked order, and what is left alone. Once a click has queued the shown set's plans the button reads "Plans queued" and rests until the shown set changes. With nothing left to plan the button is not offered — the queue-the-tickets button stands on its own.
107
+
108
+
#### Rationale
109
+
110
+
Plans are for a human to read before spending agents, so asking for them in bulk is the natural prelude to queueing the same slice for implementation. The asks ride the same queue as everything else so the framework's own consumers pick them up with no new machinery — and the entry deliberately is not a ticket link, since a leading ticket link is what every reader takes as "queued for implementation".
Copy file name to clipboardExpand all lines: packages/framework/dashboard/components/TicketsPage.test.SPEC.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,8 @@ Grouping: the flat mode renders one cross-project list ordered across projects,
8
8
9
9
The page-wide queue-add button: every shown ticket is queued the way the ticket detail page queues one (title as the entry, ticket linked, priority picking the section) and no agent is started; after the click the button reads "Queued" and stays disabled until the shown set changes, when it arms again counting the new set; a ticket an open queue entry already links to is not queued twice, and a checked-off entry does not count as queued; claimed tickets are skipped, with the button's label counting only the unclaimed tickets it will add; and the button is absent when nothing is shown or every shown ticket is claimed.
10
10
11
+
Its plan sibling: every shown ticket still to plan gets one plan ask queued, the ticket named with its priority, with no implementation entry and no agent started; after the click the button reads "Plans queued" and rests; planned and claimed tickets are skipped with the label counting only what is left to plan; a plan ask already queued (recognized by its exact wording) and a ticket already queued for implementation are not asked again; and with every shown ticket planned the plan button is absent while the queue-add still offers.
12
+
11
13
## Before modifying/creating SPEC.md files
12
14
13
15
You must always read and respect https://raw.githubusercontent.com/brillout/sdd/refs/heads/main/sdd.md
0 commit comments