v0.1.0 dependency tree and implementation order #21

New issue

Open

opened 2026-04-16 20:22:35 +00:00 by claude-desktop · 0 comments

claude-desktop commented

2026-04-16 20:22:35 +00:00

Collaborator

Purpose

Tracking issue for the v0.1.0 milestone. Gives agents the full dependency graph so they can stack PRs instead of waiting serially.

Every implementation issue in this milestone has a ## Dependencies footer with its direct Blocked by / Blocks edges. This issue owns the full tree.

Dependency graph

Layer 0 — pure foundations (no deps)
  #3  Config ..................... area:config
  #4  Event sourcing core ........ area:eventsourcing
  #8  Git (GitCore) .............. area:git         [shapes used by #6]
  #10 Terminal manager ........... area:terminal    [shapes used by #6]

Layer 1 — depend on Layer 0 types
  #5  SQLite persistence ......... area:persistence   <-- #4 (OrchestrationEvent)
  #6  IPC types and channels ..... area:ipc           <-- #4, #8 (GitCommand), #10 (TerminalCommand)
  #11 Provider adapter ........... area:provider      <-- #3 (paths), #4 (ProviderEvent)

Layer 2 — architecture keystone
  #7  OrchestrationEngine ........ area:engine        <-- #4, #5, #6

Layer 3 — reactors (need Reactor trait from #7)
  #9  Checkpoint reactor ......... area:git           <-- #3, #4, #7, #8
  #12 Provider reactor ........... area:engine        <-- #4, #7, #11

Layer 4 — frontend bootstrap
  #13 App shell (GTK4/RELM4) ..... area:frontend      <-- #3, #6, #7

Layer 5 — frontend views (need AppModel from #13)
  #14 Sidebar .................... area:frontend      <-- #13
  #15 Chat view .................. area:frontend      <-- #13, #11
  #16 Diff view .................. area:frontend      <-- #13, #8
  #17 Terminal view .............. area:frontend      <-- #13, #10
  #18 Keybindings ................ area:frontend      <-- #13, #3

PR stacking strategy

Agents must stack PRs rather than block waiting for merges:

A downstream issue opens its PR against the branch of its upstream issue, not against main.
Example: the branch for #5 (issue-5-sqlite) is cut from issue-4-event-sourcing; the PR targets issue-4-event-sourcing as base.
When #4 merges into main, #5's PR is rebased and retargeted at main.
This lets Layer 1/2/3 work proceed in parallel even though types aren't merged yet.

Branch naming: issue-<N>-<slug>.

Recommended execution order

Wave 1 (parallel, can all start now): #3, #4, #8, #10
Wave 2 (stacked on Wave 1): #5, #6, #11
Wave 3: #7 (keystone — blocks frontend)
Wave 4: #9, #12, #13 (can parallelize once #7 lands)
Wave 5: #14, #15, #16, #17, #18 (parallel on top of #13)

Agent assignment heuristic

Grunt (complex / architectural): #4, #7, #9, #11, #12, #13, #15
Peon (well-scoped): #3, #5, #6, #8, #10, #14, #16, #17, #18

Assignment will proceed in waves to respect the "max 5 in flight" rule.

## Purpose Tracking issue for the v0.1.0 milestone. Gives agents the full dependency graph so they can **stack PRs** instead of waiting serially. Every implementation issue in this milestone has a `## Dependencies` footer with its direct `Blocked by` / `Blocks` edges. This issue owns the full tree. ## Dependency graph ```text Layer 0 — pure foundations (no deps) #3 Config ..................... area:config #4 Event sourcing core ........ area:eventsourcing #8 Git (GitCore) .............. area:git [shapes used by #6] #10 Terminal manager ........... area:terminal [shapes used by #6] Layer 1 — depend on Layer 0 types #5 SQLite persistence ......... area:persistence <-- #4 (OrchestrationEvent) #6 IPC types and channels ..... area:ipc <-- #4, #8 (GitCommand), #10 (TerminalCommand) #11 Provider adapter ........... area:provider <-- #3 (paths), #4 (ProviderEvent) Layer 2 — architecture keystone #7 OrchestrationEngine ........ area:engine <-- #4, #5, #6 Layer 3 — reactors (need Reactor trait from #7) #9 Checkpoint reactor ......... area:git <-- #3, #4, #7, #8 #12 Provider reactor ........... area:engine <-- #4, #7, #11 Layer 4 — frontend bootstrap #13 App shell (GTK4/RELM4) ..... area:frontend <-- #3, #6, #7 Layer 5 — frontend views (need AppModel from #13) #14 Sidebar .................... area:frontend <-- #13 #15 Chat view .................. area:frontend <-- #13, #11 #16 Diff view .................. area:frontend <-- #13, #8 #17 Terminal view .............. area:frontend <-- #13, #10 #18 Keybindings ................ area:frontend <-- #13, #3 ``` ## PR stacking strategy Agents **must** stack PRs rather than block waiting for merges: 1. A downstream issue opens its PR against the **branch of its upstream issue**, not against `main`. 2. Example: the branch for #5 (`issue-5-sqlite`) is cut from `issue-4-event-sourcing`; the PR targets `issue-4-event-sourcing` as base. 3. When #4 merges into `main`, #5's PR is rebased and retargeted at `main`. 4. This lets Layer 1/2/3 work proceed in parallel even though types aren't merged yet. Branch naming: `issue-<N>-<slug>`. ## Recommended execution order - **Wave 1 (parallel, can all start now):** #3, #4, #8, #10 - **Wave 2 (stacked on Wave 1):** #5, #6, #11 - **Wave 3:** #7 (keystone — blocks frontend) - **Wave 4:** #9, #12, #13 (can parallelize once #7 lands) - **Wave 5:** #14, #15, #16, #17, #18 (parallel on top of #13) ## Agent assignment heuristic - **Grunt** (complex / architectural): #4, #7, #9, #11, #12, #13, #15 - **Peon** (well-scoped): #3, #5, #6, #8, #10, #14, #16, #17, #18 Assignment will proceed in waves to respect the "max 5 in flight" rule.

claude-desktop added this to the v0.1.0 milestone

2026-04-16 20:22:35 +00:00

claude-desktop added the

area:scaffold

label

2026-04-16 20:22:35 +00:00

claude-desktop changed title from ~~v0.1.0 dependency tree & implementation order~~ to v0.1.0 dependency tree and implementation order

Rows
Columns