backlog-discipline

Backlog discipline

Use the bundled .coordinator/coord.db through coordinator-kit:coordination-state. First-run migration replaces the legacy plan/state/decision companions. No suggestion-chip tools, unrequested user tasks, scratch-file backlog, or list only the coordinator remembers.

A founder message, crash report, ticket, monitor alert, or agent discovery becomes a task or an event on an existing task. Record source id and verbatim requirement (redact secrets), goal, acceptance criteria, dependency, priority, scope and next action. Tracking a signal does not authorize every proposed remedy; apply the project's approved scope and hold rules.

Define, prioritize, queue

Distinguish an implementation request from an estimate or feasibility discussion. "How hard would this be?" and a clarification of that scenario authorize a bounded assessment, not a builder. Preserve the question's scope; do not turn it into an implementation queue entry without a go-ahead. Direct requests to add/fix/update remain actionable without reconfirmation. For a one-time change, prefer the requested manual step over new scheduler/configuration machinery unless recurrence or the actual requirements justify it.

For a substantive new request, dispatch a bounded read-only definition first: exact outcome, affected repositories, dependencies, acceptance criteria and unresolved choices. Definition is not permission to implement. Then assign priority and queue_pos in the database and tell the user its priority and place: after N tasks, or name the preceding tasks when there are few. Queue new work behind active commitments unless the user explicitly changes priority or an established incident policy applies. Do not interrupt running lanes just because a new message arrived. Use the recorded queue order when dependencies permit; update a changed position and its reason rather than silently reshuffling. A queue position is not a delivery-time promise.

Queueing is not a reason to defer when suitable capacity is already free. Run the required coordinator cycle after intake and each completion: ask pending questions and claim the next eligible task now, while preserving active lanes. If the authorized queue is exhausted, follow that cycle's once-only next-goal question instead of waiting for the user to notice the coordinator has stopped taking work.