Skip to main content

Dependencies

In the current product, dependency ordering shows up mainly inside Architect-generated suggested tasks for an epic. Each suggested task can declare that another task must happen first, and dreeft uses that information when it creates and runs child coder tasks.

Where dependencies exist today​

The current UI does not expose a separate general-purpose card-to-card dependency editor. Instead:

  • Architect writes suggested tasks with dependsOn relationships.
  • Implement all turns those suggestions into child cards.
  • Child cards run in dependency order inside the shared epic execution.

Why this matters​

This lets the product:

  • start foundation work before feature slices
  • keep later tasks queued until earlier ones complete
  • preserve a readable mapping from architecture to implementation order

Parent and child behavior​

When you run an epic:

  • the parent card stays the main review and discussion surface
  • the child cards show execution slices inside the coder column
  • queued child cards wait until their predecessors are finished

Best practices​

  • Keep Architect-generated task graphs shallow when possible.
  • Review and dismiss out-of-scope suggested tasks before clicking Implement all.
  • Use epic mode when you want one shared branch and one shared PR across related implementation steps.