# Rationalization Table — Worked Example

A single filled-in gray area from a hypothetical `apt:discuss` session on
"Add onboarding persistence for desktop users". Copy this shape into
`.aperant/context/notes/{task-id}.md` under `## Locked Decisions`.

### D-01: Use libSQL for desktop onboarding persistence

**Question:** Which storage backend should power onboarding persistence on the desktop app?
**Mode:** auto

| Option | Pros | Cons | Hidden rationalizations |
|---|---|---|---|
| **A: libSQL (local file)** (picked) | Works offline, matches AGENTS.md's Desktop/Self-hosted row, already wired in `packages/core` | Requires bundling a native module, no cross-device sync | — |
| B: Convex (cloud) | Built-in sync, already in use for Cloud mode | Requires network + auth; breaks AGENTS.md's "Desktop = no auth" rule | "I already wrote the Convex onboarding schema for cloud mode — extending it is less work than building a second persistence path." |
| C: In-memory only | Zero new dependencies, simplest possible | Data lost on restart — violates the 'persistence' requirement | "Users probably won't quit mid-onboarding, so this is fine for v1." |

**Pick:** A — AGENTS.md deployment-mode table mandates libSQL for Desktop and Self-hosted modes; Convex is reserved for authenticated Cloud. `packages/core` already exposes a `TokenStore`-style abstraction we can reuse, so the marginal cost of picking libSQL is near zero.
**Kill criteria:** If a future requirement adds cross-device sync for desktop users without Cloud auth (e.g., "desktop users can continue onboarding on another machine while logged out"), re-open this — libSQL alone cannot satisfy it and we'd need a sync layer or a hybrid backend.
