FE-535: SQLite foundation and project persistence

.agents/skills/ln-build/SKILL.md

@@ -40,7 +40,7 @@ Run the project's verification harness. All checks must pass. Commit: `feat: [ta
 
 After the slice lands and verification passes, do all of these before presenting routing options:
 
-1. Mark the slice `done` in `memory/PLAN.md`
+1. Mark the slice `done` in `memory/PLAN.md`. Check `## Dependencies` — if this slice unblocked multiple downstream slices, note them as newly available (some may be parallelizable)
 2. Update assumption confidence in `memory/SPEC.md` §Assumptions — set validated assumptions to `**validated**`, invalidated ones to `**invalidated**` and flag implicated slices in PLAN.md
 3. Add new invariants to `memory/SPEC.md` §Invariants — each structural property now protected by tests. Update `memory/PLAN.md` slice with `Invariants established: I#`
 4. Add any new decisions to `memory/SPEC.md` §Decisions, new assumptions to §Assumptions
@@ -54,7 +54,7 @@ After traceability is complete, present these options to the user (use `tool-ask
 
 | #   | Label            | Target       | Why                                                          |
 | --- | ---------------- | ------------ | ------------------------------------------------------------ |
-| 1   | Scope next slice | `ln-scope`   | More slices remain on the plan                               |
+| 1   | Scope next slice | `ln-scope`   | More slices remain — if multiple were unblocked, name them   |
 | 2   | Review the code  | `ln-review`  | Assess quality after an implementation burst                 |
 | 3   | Revise spec      | `ln-spec`    | Build revealed the spec needs structural revision            |
 | 4   | Revise plan      | `ln-plan`    | Revisit the plan or re-prioritize                            |

.agents/skills/ln-plan/SKILL.md

@@ -20,10 +20,16 @@ If context is thin, run a brief interview (not a full `ln-grill`) to fill gaps.
 
 ## Plan
 
+**Mode detection.** If the user is inserting or reordering specific slices — not replanning from scratch — this is a **patch**. Read PLAN.md, make the targeted edits, then jump to the post-edit checklist (step 5).
+
 1. If `memory/PLAN.md` exists, read it first. Retire completed slices (mark `done`). Assess what remains and what's changed.
 2. Explore the codebase. Identify architectural constraints the slices must respect (routes, schema, auth, third-party boundaries).
 3. Draft or revise phases and slices. Each slice must be independently demoable and independently grabbable where possible. Group into temporal phases. For each, name dependent requirements and assumptions from `memory/SPEC.md`.
 4. Confirm with user — adjust granularity, reorder, split or merge.
+5. **Post-edit checklist** — after any addition, removal, or reordering:
+   - Update the `## Dependencies` ASCII graph to reflect new/changed edges
+   - Update `### Parallelism opportunities` if new concurrent paths opened
+   - Verify every new slice names its requirements, assumptions, invariants to establish, and invariants to respect from SPEC.md
 
 ## Output
 

.agents/skills/ln-scope/SKILL.md

@@ -14,6 +14,8 @@ The behavior to deliver: $ARGUMENTS
 
 If `memory/SPEC.md` exists, use its lexicon and respect its invariants.
 
+**Parallelism check.** If `memory/PLAN.md` exists, check `## Dependencies` and `### Parallelism opportunities`. If the current state (completed slices) unblocks multiple slices, surface them: "Slices X and Y are both unblocked — which to scope?" If the user names one, note the other(s) as available for concurrent work (e.g. a separate agent thread or session).
+
 ## Scope Card
 
 ### Target Behavior

.agents/skills/ln-spec/SKILL.md

@@ -16,6 +16,8 @@ The feature or problem: $ARGUMENTS
 
 ## Procedure
 
+**Mode detection.** If the user provides a specific finding, research result, or decision to record — not a new feature area — this is a **patch**, not a full pass. Skip to step 5.
+
 1. **Capture the problem** from the user's perspective — what they want and *why*. The *why* shapes the solution space.
 2. **Explore the codebase** to verify assertions, understand current state, and find existing patterns. If `memory/SPEC.md` exists, read it first — this is an update, not a blank-slate write.
 3. **Interview** (if understanding is thin), to close remaining gaps. Walk each branch of the design tree. For each question, provide your recommended answer. If the codebase can answer a question, explore it instead of asking. Use `/ln-grill` if it hasn't already been run.
@@ -30,6 +32,16 @@ Write or update `./memory/SPEC.md` following the template at `@resources/spec-te
 
 If `memory/PLAN.md` exists, verify that changed assumptions and decisions still align with affected slices.
 
+### Cross-reference integrity
+
+Every amendment must close its reference chain. After editing, verify:
+
+- **New assumption** → has: dependent decision(s), implicated slice(s) in PLAN.md, validation approach
+- **New decision** → has: dependent assumption(s), supersession note
+- **New invariant** → has: establishing slice in PLAN.md, protecting test (or `manual (outer loop)`), proved decision
+- **New constraint** → has: rationale for exclusion
+- **New feedback loop item** → names the invariant(s) it protects
+
 ## Routing
 
 After filing the spec, present these options to the user (use `tool-ask-question`):

AGENTS.md

@@ -16,6 +16,13 @@ Slices and spikes in `memory/PLAN.md` are the unit of work. When starting one:
 
 One branch per slice/spike. Stacked branches mirror slice dependencies in PLAN.md. Graphite manages the stack; Linear tracks the issue.
 
+### naming conventions
+
+- **Branch**: `ln/{issue-id}-{keywords}` (e.g. `ln/fe-534-walking-skeleton`)
+- **PR title**: `{issue-id | upper}: {Linear issue title in sentence case}` (e.g. `FE-534: Walking skeleton SDK to SSE to React`)
+
+PR descriptions are written only when tying off a branch — not during active development.
+
 ## planning
 
 Two canonical documents in `memory/`:
@@ -37,3 +44,12 @@ The `/ln-*` skills at `.agents/skills/` follow this flow:
 ### verification
 
 Verification strategy is defined per-project in SPEC.md §Verification Design (three-tier feedback loops). The global verification harness in `~/.claude/CLAUDE.md` provides the execution stack.
+
+### manual testing
+
+When a slice requires manual UI testing (outer-loop verification):
+
+1. **Dev server**: use `/tool-cmux` to open a terminal pane, run `npm run dev` there
+2. **Browser**: use `/tool-cdp-cli` to launch Chrome with DevTools Protocol, open the dev URL, and interact (snapshot, fill, click, eval, console)
+
+This keeps the dev server and browser observable without leaving the agent session.

docs/design/schema.dbml

@@ -0,0 +1,176 @@
+// Brunch v2 — Entity Relation Model
+// Produced by ln-grill session 2026-03-31
+//
+// Core idea: the turn tree is the version history. Decisions and assumptions
+// are extracted from turns by an observer agent. Requirements and criteria
+// are downstream projections reviewed in later phases. The active path from
+// HEAD determines which entities are current. No snapshots needed.
+
+// ── Core ───────────────────────────────────────────────────
+
+Table project {
+  id             integer [pk]
+  name           text [not null]
+  active_turn_id integer [ref: > turn.id, note: 'HEAD pointer — current tip of the active branch']
+  created_at     timestamp [default: `CURRENT_TIMESTAMP`]
+  updated_at     timestamp [default: `CURRENT_TIMESTAMP`]
+
+  Note: 'Identity and metadata. No phase cursor — phase resolution lives on turns.'
+}
+
+// ── Conversation tree ──────────────────────────────────────
+
+Table turn {
+  id             integer [pk]
+  project_id     integer [not null, ref: > project.id]
+  parent_turn_id integer [ref: > turn.id, note: 'null = root turn']
+  phase          phase_enum [not null, note: 'Immutable provenance']
+  question       text [not null, note: 'What the interviewing agent asked']
+  why            text [note: 'Why this question matters — strategic grounding for the user']
+  impact         impact_enum [note: 'Signal label for the user']
+  answer         text [note: 'What the user chose or typed. null = unanswered']
+  is_resolution  boolean [not null, default: false, note: 'LLM judgment: this turn completes the phase']
+  created_at     timestamp [default: `CURRENT_TIMESTAMP`]
+
+  Note: 'The commit. Branches on decision revisit. Walk parent_turn_id to root for the active path.'
+}
+
+Table option {
+  id             integer [pk]
+  turn_id        integer [not null, ref: > turn.id]
+  position       integer [not null]
+  content        text [not null]
+  is_recommended boolean [not null, default: false]
+  is_selected    boolean [not null, default: false]
+
+  indexes {
+    (turn_id, position) [unique]
+  }
+
+  Note: 'Structured alternatives presented in a turn. At least two per turn.'
+}
+
+Enum impact_enum {
+  high
+  medium
+  low
+}
+
+Enum phase_enum {
+  scope
+  design
+  requirements
+  criteria
+}
+
+// ── Knowledge entities (extracted by observer agent) ───────
+
+Table decision {
+  id         integer [pk]
+  project_id integer [not null, ref: > project.id]
+  content    text [not null, note: 'What was decided']
+  rationale  text [note: 'Why this was chosen']
+
+  Note: 'A resolved fork in the design tree. Traced to the turn that produced it.'
+}
+
+Table assumption {
+  id         integer [pk]
+  project_id integer [not null, ref: > project.id]
+  content    text [not null, note: 'The falsifiable belief']
+
+  Note: 'A load-bearing belief a decision rests on. Dependency of decisions, not independent.'
+}
+
+Table requirement {
+  id          integer [pk]
+  project_id  integer [not null, ref: > project.id]
+  content     text [not null, note: 'What the system must do']
+  reviewed_at timestamp [note: 'Last confirmed against the current decision graph']
+
+  Note: 'Accumulated during drill-down, confirmed during requirements review phase.'
+}
+
+Table criterion {
+  id             integer [pk]
+  project_id     integer [not null, ref: > project.id]
+  requirement_id integer [not null, ref: > requirement.id]
+  content        text [not null, note: 'Testable condition']
+  reviewed_at    timestamp [note: 'Last confirmed against the current requirement set']
+
+  Note: 'Proposed by agent, confirmed by user during criteria phase.'
+}
+
+// ── Observer linkage (turn → extracted entities) ───────────
+
+Table turn_decision {
+  turn_id     integer [not null, ref: > turn.id]
+  decision_id integer [not null, ref: > decision.id]
+
+  indexes {
+    (turn_id, decision_id) [pk]
+  }
+
+  Note: 'This turn produced this decision.'
+}
+
+Table turn_assumption {
+  turn_id       integer [not null, ref: > turn.id]
+  assumption_id integer [not null, ref: > assumption.id]
+
+  indexes {
+    (turn_id, assumption_id) [pk]
+  }
+
+  Note: 'This turn surfaced this assumption.'
+}
+
+// ── Decision dependency graph ──────────────────────────────
+
+Table decision_parent_decision {
+  decision_id        integer [not null, ref: > decision.id]
+  parent_decision_id integer [not null, ref: > decision.id]
+
+  indexes {
+    (decision_id, parent_decision_id) [pk]
+  }
+
+  Note: 'DAG edge: this decision depends on a prior decision.'
+}
+
+Table decision_parent_assumption {
+  decision_id          integer [not null, ref: > decision.id]
+  parent_assumption_id integer [not null, ref: > assumption.id]
+
+  indexes {
+    (decision_id, parent_assumption_id) [pk]
+  }
+
+  Note: 'This decision is predicated on this assumption.'
+}
+
+// ── Assumption dependency graph ─────────────────────────────
+
+Table assumption_parent_assumption {
+  assumption_id        integer [not null, ref: > assumption.id]
+  parent_assumption_id integer [not null, ref: > assumption.id]
+
+  indexes {
+    (assumption_id, parent_assumption_id) [pk]
+  }
+
+  Note: 'DAG edge: this assumption rests on a prior assumption.'
+}
+
+// ── Requirement provenance ─────────────────────────────────
+
+Table requirement_decision {
+  requirement_id integer [not null, ref: > requirement.id]
+  decision_id    integer [not null, ref: > decision.id]
+
+  indexes {
+    (requirement_id, decision_id) [pk]
+  }
+
+  Note: 'Many-to-many: which decisions gave rise to this requirement.'
+}