Implementation Order

This index defines the recommended build order after the SwiftPM Hello World scaffold. The sequence builds durable state, persistence, and workflows before terminal embedding so later integrations land behind stable app boundaries.

Scaffold Prelude

The initial commit established a SwiftPM scaffold with placeholder models for projects, threads, right-panel mode, and a Hello World layout. Some Plan 01 behavior already exists in code: RightPanelMode.next/previous, AppModel.cycleRightPanelMode*, AppModel.toggleGlobalTerminal, and a Cmd+J command. Plan 01 finishes the missing pieces (full selection state, archive APIs, global navigation history, and Cmd+[ / Cmd+] / Cmd+Shift+[ / Cmd+Shift+] routing) and updates the existing scaffold accordingly.

Ordered Plans

  1. App State And Navigation Spine
  2. SQLite Persistence
  3. Project And Thread Workflows
  4. Layout Shell
  5. Terminal Abstraction
  6. libghostty Integration
  7. Agent CLI Session Binding
  8. File Browser And Fuzzy Search
  9. Right Panel Tool Flows
  10. Behavior E2E Suite
  11. Polish And Hardening
  12. Icon System
  13. Agent Notifications And Thread Status

Sequencing Rule

Implement plans in order unless a later plan is explicitly split into a research-only spike. Each plan MUST leave scripts/build.sh and scripts/test.sh passing before the next plan starts.

Review Triage Rule

External review findings MUST be handled as follows to avoid review loops:

Persistence Strategy

Plan 02 establishes the SQLite store and migrates only what Plan 01 produces (projects, threads, archive state, last selection, right-panel mode per thread) plus the YAML settings boundary. Later plans extend the schema through additive migrations as they produce new durable state:

This avoids persisting columns that have no producer yet.

Testing Strategy

Plans 02–09 ship unit and integration tests inside scripts/test.sh. Plan 10 introduces the script-backed E2E harness (scripts/test-e2e.sh) and retroactively adds behavior coverage for the workflows shipped in earlier plans. Acceptance criteria in earlier plans that name user-visible behavior (panel collapse, mode cycling, opening a file in nvim, launching lazygit, CLI session resume) are validated by unit and integration tests plus a documented manual smoke procedure until Plan 10 lands the harness.

Plans that include manual smoke acceptance criteria (Plan 06, Plan 07) document the smoke procedure in the plan body so manual verification stays consistent until the E2E suite covers them.

Open Decisions

Three product/architecture questions remain open and do not block any plan from starting. Each has a recommended default the plans assume until the decision is finalized:

Requirement References