Run your Dart cycle planning meeting from one table

I want an app my team works through together in our cycle planning meeting, instead of arguing over a board view in Dart. It is one table: the unscheduled backlog on the left, one column per teammate on the right, and a staging area that holds every change until we agree and press Apply.

At the top I pick which dartboard we are planning and set the cycle start and end dates. Use Get User Space Configuration to populate the dartboard picker and to learn this workspace's real statuses, priorities and assignees, so none of those are hardcoded. Use Get Dartboard for the selected board's name and metadata, and show that name as the heading of the table.

The left side is the work waiting to be planned. Pull it with List Tasks scoped to the selected dartboard. The main backlog is tasks in open statuses with no due date, ranked in the order Dart already holds them. Above that, pinned to the top in its own clearly separated Carry over section, show open tasks on the same dartboard whose due date is already in the past. These are last cycle's misses and they have to be placed before new work is added.

Enforce that rule in the interface. While any carry over task is still unplaced, show a persistent banner with the count remaining, and warn me when I drag a fresh backlog task into someone's column before the carry over is cleared. Warn rather than hard block, because sometimes the right answer is to drop a carry over task instead of replacing it.

The right side is one column per teammate, drawn from the assignees in the workspace configuration, with a control to choose which people are in this particular session. Each column shows the work that person is already committed to for this cycle, meaning open tasks on this dartboard assigned to them with a due date inside the cycle window, plus anything I have staged onto them during the meeting. At the top of each column I set a capacity number for that person, and under it a running load total.

Dart has no story points, so do not look for them. Load is open task count weighted by priority. Give each priority a weight, defaulting to critical 3, high 2, medium 1 and low 0.5, and let me edit those weights in a settings panel since workspaces name their priorities differently. The load total is the sum of the weights of the tasks in that column, shown against capacity as something like 7.5 of 9. When load goes over capacity, turn the total and the column header red and keep them red, so the room can see who is overcommitted at a glance.

Dragging a task from the left into a person's column plans it. That does not write to Dart. It stages an Update Task change setting assignee, due date and priority, and a Move Task change setting the task's order within the dartboard so the ranking we agree on survives. Default the due date to the cycle end date and the priority to whatever the task already carries, and let me edit both inline on the staged card. Dragging a card between two people restages it, and dragging it back to the left unstages it entirely.

Keep a visible count of pending changes and a panel listing them in plain language, for example: Rewrite onboarding email, assign to Priya, due 12 June, priority high. Every staged change can be reverted individually. Because nothing is written until Apply, we can try a version of the cycle, look at the load totals, back it out and try another one live in the meeting.

Apply is the only thing that writes. It runs the staged Update Task and Move Task calls, shows progress as it goes, and reports what succeeded and what failed without discarding the plan when something errors, so I can retry just the failures. After a successful apply, the columns refresh from Dart and the staging area empties.

Publish is a separate step I press once the plan is applied and agreed. It posts a per person summary to a Slack channel I pick, using Slack Send a Message: one message with a section per teammate listing what they picked up, their load against capacity, and any carry over they inherited. I also want the reasoning recorded. On any task I can add a short rationale note while we plan, for example why we pushed something or why it went to a particular person, and Publish writes those notes onto the relevant tasks with Create Comment.

Persist the per person capacity numbers, the priority weights and the chosen Slack channel between sessions, so the next cycle starts from the last one's setup. Persist the staged plan too, so a refresh in the middle of the meeting does not lose our work.

One thing to avoid: do not build anything that reports on hours logged in Dart. Dart accepts time tracking entries but offers no way to read them back, so any hours view would be a dead end. Capacity here is a number the planner sets in the app, and load is always derived from open task count weighted by priority.