Explanation

Explanation

Background and rationale — why the harness works the way it does. These pages give the reasoning behind the design; load-bearing calls live in each design's amendment log under Designs, and the structural map is under Architecture.

What's here

• Product intent — what problem the harness solves and for whom.
• Auto-detect + auto-configure — why first-session config proposes-then-approves, and why it lives in project.json.
• How the pieces fit — the narrative of how phases, adapters, templates, and scripts interact.
• GitHub Projects integration — why and how the harness writes to ProjectsV2.
• Auto-orchestration — why the memory skills became a push surface, and how the briefing + idle chain + phase dispatch never nag.
• Single-repo state mode — how the harness degrades gracefully to repo-local state when no vault is reachable.
• Memory↔process seam — why a process talks to the engine through a small stable client, and why that dependency is one-directional.
• Memory↔storage seam — why the engine reads and writes through verbs that hand back an opaque locator, never a filesystem path, why the default backend is bare markdown on-device, and why the synced vault is a wrap over existing state that moves no data (V5-1 parts 1–4).
• Soft composition and hard composition — why enhances: and requires: are disjoint, what the capability resolver does, and why it is "vocabulary, not wire."

See also

Designs · Architecture · Home