Skip to content

DEPENDENCIES.md

Latest commit

 

History

History
326 lines (239 loc) · 8.78 KB

DEPENDENCIES.md

File metadata and controls

326 lines (239 loc) · 8.78 KB

Dependencies and Gates

Beads includes a full dependency system for ordering work and a gate system for bridging external conditions (PR merges, CI runs, timers) into the dependency graph.

Adding Dependencies

# issue-2 depends on issue-1 (issue-1 blocks issue-2)
bd dep add issue-2 issue-1

# Shorthand: issue-1 blocks issue-2
bd dep issue-1 --blocks issue-2

# Alternative flags (equivalent)
bd dep add issue-2 --blocked-by issue-1
bd dep add issue-2 --depends-on issue-1

When issue-1 is open, issue-2 won't appear in bd ready. Once issue-1 is closed, issue-2 unblocks automatically.

Removing Dependencies

bd dep remove issue-2 issue-1
bd dep rm issue-2 issue-1        # alias

Dependency Types

Dependencies have a type that determines whether they block work.

Blocking types (affect bd ready):

Type Meaning Example
blocks (default) B cannot start until A closes Task ordering
parent-child Children blocked when parent blocked Epic hierarchies
conditional-blocks B runs only if A fails Error handling paths
waits-for B waits for all of A's children Fanout aggregation

Non-blocking types (graph annotations only):

Type Meaning
related Informational link
tracks Tracks progress of another issue
discovered-from Found during work on another issue
caused-by Root cause link
validates Test or verification link
supersedes Replaces another issue

Specify with --type:

bd dep add issue-2 issue-1 --type tracks
bd dep add issue-2 issue-1 --type caused-by

Finding Ready Work

bd ready shows issues with no open blocking dependencies:

bd ready

Output:

📋 Ready work (1 issues with no blockers):

1. [P1] bd-a1b2: Set up database

An issue is ready when ALL of its blocking dependencies are closed.

# Filter ready work
bd ready --priority 1              # By priority
bd ready --label backend           # By label
bd ready --assignee alice          # By assignee
bd ready --unassigned              # Unassigned only
bd ready --type task               # By issue type
bd ready --sort oldest             # Oldest first

Viewing Blocked Issues

bd blocked

Shows every blocked issue and what blocks it. Use after closing an issue to see what just unblocked.

Visualizing Dependencies

Dependency Tree

bd dep tree issue-id                    # What does this issue depend on?
bd dep tree issue-id --direction=up     # What depends on this issue?
bd dep tree issue-id --direction=both   # Both directions
bd dep tree issue-id --status=open      # Only open issues
bd dep tree issue-id --max-depth=3      # Limit depth
bd dep tree issue-id --format=mermaid   # Mermaid.js output

Dependency Graph

bd graph issue-id                       # Single issue DAG
bd graph --all                          # All open issues

# Output formats
bd graph --compact issue-id             # One line per issue
bd graph --box issue-id                 # ASCII boxes with layers
bd graph --dot issue-id | dot -Tsvg > graph.svg   # Graphviz
bd graph --html issue-id > graph.html   # Interactive D3.js

The graph organizes issues into layers:

  • Layer 0: No dependencies (can start immediately)
  • Layer 1: Depends on layer 0
  • Higher layers: Depend on lower layers
  • Same layer: Can run in parallel

Dependency List

bd dep list issue-id                    # What does this depend on?
bd dep list issue-id --direction=up     # What depends on this?
bd dep list issue-id --type=tracks      # Filter by type

Cycle Detection

bd dep cycles

Beads also rejects cycles at write time — bd dep add checks for cycles before committing.

Cross-Repo Dependencies

Dependencies can reference issues in other beads rigs:

bd dep add local-issue external:other-project:remote-issue

External dependencies always block. When the remote issue closes, bd ready reflects the change (checked at query time).

Gates

Gates are special issues that block dependent work until an external condition is met. They bridge the gap between beads (which tracks work) and external systems (which track code, CI, or time).

The Problem Gates Solve

When you use Dolt (server or embedded), issue state is decoupled from code state. Closing a beads issue means "work is done" but the code may still be on a feature branch, waiting for PR review:

issue-1: closed in beads     (work done)
PR #42:  open on GitHub      (code not yet on main)
issue-2: blocked by issue-1  (should it start?)

With file-based storage (JSONL), issue updates land atomically with code in the same commit. With Dolt, they don't. Gates solve this by making the dependency wait for the external condition — not just the beads issue status.

Gate Types

Type Condition Auto-Resolution
gh:pr PR merged gh pr view returns MERGED
gh:run CI passes gh run view returns completed + success
timer Time elapsed Current time exceeds timeout
bead Cross-rig issue closed Remote bead status checked
human Manual approval bd gate resolve <id>

Creating Gates

# Wait for PR #42 to merge
bd create --type=gate --title="Wait for PR #42" \
  --await-type=gh:pr --await-id=42

# Wait for CI run
bd create --type=gate --title="Wait for CI" \
  --await-type=gh:run --await-id=12345

# Wait 30 minutes
bd create --type=gate --title="Cooldown" \
  --await-type=timer --await-id=30m

# Wait for a cross-rig bead to close
bd create --type=gate --title="Wait for upstream fix" \
  --await-type=bead --await-id=other-rig:issue-id

# Manual approval gate
bd create --type=gate --title="Deploy approval"

Wiring Gates into Dependencies

A gate is an issue. Wire it into the dependency graph like any other:

# issue-2 waits for the gate (which waits for PR #42)
bd dep add issue-2 <gate-id>

Checking Gates

bd gate check evaluates all open gates and closes resolved ones:

bd gate check                    # Check all gates
bd gate check --type=gh:pr       # Only PR gates
bd gate check --type=gh:run      # Only CI gates
bd gate check --type=timer       # Only timers
bd gate check --dry-run          # Preview without changes
bd gate check --escalate         # Escalate failed gates

Escalation marks gates whose conditions failed (e.g., PR closed without merge, CI run failed) so they surface for attention.

Listing and Inspecting Gates

bd gate list                     # Open gates
bd gate list --all               # Including closed
bd gate show <gate-id>           # Full details

Manual Resolution

For human gates or overrides:

bd gate resolve <gate-id> --reason "Approved by team lead"

Discovering CI Run IDs

When you create a gh:run gate before the run starts, bd gate discover matches gates to GitHub Actions runs using heuristics (commit SHA, branch, timing):

bd gate discover                 # Auto-match gates to runs
bd gate discover --dry-run       # Preview matches
bd gate discover --branch main   # Filter by branch

Automating Gate Checks

Run bd gate check periodically to auto-close resolved gates:

  • CI step: Add to your GitHub Actions workflow
  • Cron: */5 * * * * cd /path/to/repo && bd gate check
  • Agent hook: Run at session start or after PR operations

Recipes

PR Merge Gate (Common)

Agent A finishes work, opens PR, creates a gate so Agent B waits for merge:

# Agent A
bd update issue-1 --status=in_progress
# ... write code, open PR #42 ...
bd create --type=gate --title="Wait for PR #42" \
  --await-type=gh:pr --await-id=42
bd dep add issue-2 <gate-id>
bd close issue-1

# Agent B
bd ready                         # issue-2 not shown (gate open)
# ... PR #42 merges ...
bd gate check                    # gate closes
bd ready                         # issue-2 appears

CI Gate Before Deploy

bd create --type=gate --title="CI green on main" \
  --await-type=gh:run --await-id=<run-id>
bd dep add deploy-task <gate-id>

Epic with Ordered Phases

bd create "Auth System" -t epic
bd create "Design" --parent <epic>
bd create "Implement" --parent <epic>
bd create "Test" --parent <epic>

bd dep add <implement> <design>
bd dep add <test> <implement>

bd dep tree <epic>
bd ready                         # Only "Design" is ready

See Also