docs: record human decisions on Linux keyring policy, retention defaults, review gate

docs/ELECTRON-OFFLINE-ENGINE-DESIGN.md

@@ -1269,28 +1269,31 @@ stage.
     primary keys, the purge ordering (key before file), lazy materialisation, and the F1–F49 failure
     table.
 
-### Open questions for the human
+### Open questions for the human — resolved 2026-08-04
 
-1. **If Stage A item 6 shows an unsigned build loses its Keychain item across updates**, does the
+1. **If Stage A item 6 shows an unsigned build loses its Keychain item across updates** — left open
-   encrypted store ship anyway (re-bootstrapping after each update — bandwidth, not data loss), or
+   deliberately; this is an empirical Stage A outcome, not something to decide blind. Resolve once
-   wait on VNCprodbuild step 9 (Apple Developer ID, already a human-owned purchase)? This is the one
+   Stage A actually runs and reports what happens.
-   Stage A outcome that could change the plan rather than just an implementation detail.
+2. **Linux with no keyring (`basic_text`, §6.3.1 / E3): refuse outright.** Decided — matches this
-2. **Linux with no keyring (`basic_text`, §6.3.1 / E3):** refuse outright, or offer an explicit
+   design's own "cheapest wrong answer" philosophy (§ discussion of `safeStorage`'s silent-downgrade
-   opt-in that records the downgrade? Refusing is the safe default and what this design specifies;
+   landmine): an honest failure beats a store that looks encrypted but isn't. No opt-in path in v1.
-   an opt-in is defensible for a single-user machine with full-disk encryption. Affects a real
+3. **Concrete retention defaults: same as the mobile design's defaults.** Decided —
-   segment — AppImage users on minimal window managers.
+   `offlineEnvelopeDays: 365`, `offlineBodyDays: 30`, MB cap on bodies matching mobile's default
-3. **Concrete retention defaults** — `offlineEnvelopeDays` ≫ `offlineBodyDays` and the MB cap on
+   (§ mobile M§2.1's shipped numbers). Consistent behavior across platforms for v1; revisit only if
-   bodies only are settled (M§2.1); the *numbers* are not recorded anywhere. Two constants; the
+   desktop usage patterns actually show it's too narrow — don't widen speculatively.
-   design is value-independent. Same open question M ends on.
+4. **§2.5 single-socket follow-up: not scheduled for v1.** Stays a gated follow-up as designed —
-4. **Does the follow-up in §2.5 (collapse to one socket per account by having the renderer listen to
+   don't collapse to one connection until the engine's own connection is proven in production.
-   the local server instead of Stalwart) get scheduled?** It would retire the renderer's WS
+5. **Stage A as its own PR ahead of the offline engine: not decided separately** — proceed with the
-   circuit-breaker path as dead code and halve the connection count, but it makes a working
+   implementation sequence as designed (Stage A is the first step regardless of PR boundaries); the
-   notification path depend on the new one, so it is deliberately not in v1.
+   human can split the PR at merge time if desired, this doesn't block starting work.
-5. **Should this land as its own PR ahead of the offline engine?** Stage A is pure verification and
-   §10.3's `app.requestSingleInstanceLock()` (E7) plus §8.4's cooperative quit are improvements to
-   the shell on their own merits, independent of any offline store.
 
-None of these blocks starting Stage A.
+Also decided: **this design goes through an independent adversarial review next**, matching the
+mobile engine's process (design → review → implementation), before any implementation code is
+written — same reasoning as before: this is the same class of highest-stakes, hardest-to-undo
+component (a persistent, encrypted, multi-account local store), and the review process caught real
+critical bugs in the mobile design that this document's own author-side verification did not.
+
+None of these blocks starting the review.
 
 ---