Outcome
A user can say “start the UI task after the API PR merges” and have that instruction survive browser closure and server restarts. This is the first test of a project coordinator built on Fountain's persistent execution and Switchyard's durable queue.
Proposed priority: exploratory, after basic attention handling (#35). Audience: implementing coding agent. Prove one explicit dependency before designing a general planning system.
First useful version
Save a dependent task with a target project, prompt, prerequisite repository/PR identity, creator, and state. The only initial trigger is an authoritative PR merge. A closed-but-unmerged PR, successful turn, or green CI result must not satisfy it.
When the prerequisite merges, create the dependent track from a pinned base revision containing the merge result, then queue its instruction. Record trigger evidence and the selected revision. If the merge cannot be found in the intended target branch history, pause and explain rather than starting on an unrelated base.
Persist transitions such as waiting, starting, queued, running, completed, cancelled, and needs-attention. Define task completion explicitly; an idle conversation alone is not completion. Reconcile partial track creation and ambiguous prompt delivery without creating a second track or repeating the instruction. Recheck the creator's project access before dispatch.
Allow cancellation while waiting and make already-dispatched work visible; cancelling a dependency is not automatically interrupting its agent. Show which prerequisite is holding the task and link to it.
Implementation starting points
Read apps/switchyard/server/{tracks,prompt-queue,repos,github,db,context}.ts and shared/spec.ts. Inspect how track creation sends its opening turn before designing recovery. Reuse durable delivery and existing capacity handling. Add a server-side scheduler with bounded GitHub polling or verified webhooks; no browser timer may own progress.
Completion checks
- In a disposable Demos workflow, B starts once after A's PR merges with all tabs closed.
- Closing A without merging does not start B.
- Duplicate events and restarts between track creation and queue insertion do not duplicate work.
- The resulting worktree contains A's merge; cancellation, lost access, and unavailable capacity are handled visibly.
- Tests cover these transitions; Switchyard tests/build pass.
Automatic task decomposition, arbitrary dependency graphs, automatic merging, and inferred readiness are outside this issue. Success should justify expanding to multiple prerequisites later.
Outcome
A user can say “start the UI task after the API PR merges” and have that instruction survive browser closure and server restarts. This is the first test of a project coordinator built on Fountain's persistent execution and Switchyard's durable queue.
Proposed priority: exploratory, after basic attention handling (#35). Audience: implementing coding agent. Prove one explicit dependency before designing a general planning system.
First useful version
Save a dependent task with a target project, prompt, prerequisite repository/PR identity, creator, and state. The only initial trigger is an authoritative PR merge. A closed-but-unmerged PR, successful turn, or green CI result must not satisfy it.
When the prerequisite merges, create the dependent track from a pinned base revision containing the merge result, then queue its instruction. Record trigger evidence and the selected revision. If the merge cannot be found in the intended target branch history, pause and explain rather than starting on an unrelated base.
Persist transitions such as waiting, starting, queued, running, completed, cancelled, and needs-attention. Define task completion explicitly; an idle conversation alone is not completion. Reconcile partial track creation and ambiguous prompt delivery without creating a second track or repeating the instruction. Recheck the creator's project access before dispatch.
Allow cancellation while waiting and make already-dispatched work visible; cancelling a dependency is not automatically interrupting its agent. Show which prerequisite is holding the task and link to it.
Implementation starting points
Read
apps/switchyard/server/{tracks,prompt-queue,repos,github,db,context}.tsandshared/spec.ts. Inspect how track creation sends its opening turn before designing recovery. Reuse durable delivery and existing capacity handling. Add a server-side scheduler with bounded GitHub polling or verified webhooks; no browser timer may own progress.Completion checks
Automatic task decomposition, arbitrary dependency graphs, automatic merging, and inferred readiness are outside this issue. Success should justify expanding to multiple prerequisites later.