Queue

[brillout]

Two queues:

• Queue of human interventions needed
  • AI in-progress tasks awaiting user answer
  • AI finished tasks (ready to merge) requiring user review
  • New tickets pending user confirmation (agentic PM automatically proposes new tickets => user confirms)
  • New tasks pending user confirmation (agentic PM automatically proposes new tasks from ticketing => user confirms)
• Queue of confirmed tasks
  • pending tasks
  • future task confirmed by user
  • finished tasks (i.e. history)

[suleimansh]

Design proposal for The Queue.

The two queues are the two human-gated ends of one pipeline. The belt is the confirmed-task flow; the interventions queue is everything waiting on you, at both ends and the middle:

tickets/*.md (goals, #462)
   │ PM proposes
   ▼
TODO-candidates.md   ← interventions: proposed tickets + tasks (unconfirmed)
   │ you confirm / reject
   ▼
TODO.md              ← confirmed tasks (pending + future)
   │ todo-loop drains one at a time
   ▼
run in progress
   ├─ hits AWAIT gate  → interventions: awaiting your answer
   └─ setReadyForMerge → interventions: ready to review
   ▼
merged → LOGS.md / git log   ← confirmed: history

Two takeaways:

1. The interventions queue is mostly a projection, not a store. Awaiting-answer and ready-to-review already exist as live run state across the registry, so we just aggregate them. The only new persistent file is TODO-candidates.md.
2. The confirmed queue is TODO.md, committed = the durable roadmap. History = LOGS.md + git log.

Already built: the per-session TODO backlog + the loop that drains it, and a cross-project queue rollup in the dashboard. New: TODO-candidates.md, the confirm/reject action, and the interventions projection (which #627 notifications fires off).

Three calls before I build:

1. Confirmed queue: promote today's per-session TODO_.agent.md into one durable .the-framework/TODO.md (the per-session file becomes just the slice the loop pulls)? Main fork.
2. TODO-candidates.md: one file, two sections (proposed tickets / proposed tasks), or split?
3. Build the task pipeline first and layer the ticket half (Product Management: ticketing #462, post-MVP) on later?

[brillout]

How about we make it that proposals are just PRs? Then I don't think we need TODO-candidates.

The more we leverage and re-use normal Git flows, the simpler and the nicer the UX, I think.

[brillout]

1. So the current session modifies the global TODO.md and that's the session-created TODO? Sounds good, and it's actually the idea I just wrote.
2. Same: how about it's just PRs towards TODO.md for proposed tasks, and PRs towards tickets/ for proposed tickets.
3. Ok

[suleimansh]

Yes, that's much simpler. Nice idea. Proposals and finished work are both just PRs then, no new file needed.