feat(lifeboard): shell, family profiles and the tap layer

[ivanmkc]

The stack

#	PR	What it adds	Tests at this point
1	#311	A real localStorage for the test suite on Node 25	viewer 747
2	#312	@ivanmkc/termchart-canvas; injectable interact transport	canvas 473 · viewer 278
3	#313	lifeboard PWA: fact log, boards, service worker	lifeboard 36
4	#314	Shell, family profiles, tap layer	lifeboard 82
5	#315	The agent turn, four providers, Connections	lifeboard 142
6	#316	Packs, recipes, shopping-list arithmetic	lifeboard 231
7	#317	Provenance and lineage	lifeboard 257
8	#318	Calendar, Gmail, mail triage	lifeboard 301
9	#319	The bridge and long jobs	cli 314 · lifeboard 320
10	#310	Proactivity, scheduled boards, Google sign-in	cli 320 · lifeboard 343
11	#320	Persistence audit fixes: multi-tab, stale builds, no-storage boot	lifeboard 350
12	#321	User guide, bridge setup, QA guide, persistence audit	lifeboard 350
13	#322	A plan for third-party integrations (docs only)	unchanged
14	#323	A practice drill a board can define: audio + Q&A	canvas 485 · lifeboard 372
15	#325	Export and restore	lifeboard 389
16	#326	Draft a message, approve it, then send	lifeboard 399
17	#327	Hand long work to the Mac	lifeboard 406
18	#328	A Packs screen, and authoring one by describing it	lifeboard 418
19	#329	Activity — what changed, who changed it, undo	lifeboard 428
20	#330	Four defects found reviewing the stack	cli 323 · lifeboard 431

Every branch in the stack was checked out on its own and verified independently: npm install, tsc --noEmit for every package, npm test across the workspace, and the offline e2e where it exists. All twenty are green — no branch depends on a later one to build or pass. Full viewer e2e (11 suites, 106 assertions) was run on #312 as the behaviour-preservation evidence for the extraction.

---

Stack position: 4 of 10. Base: lifeboard/02-foundation.

Generalises the log from one collection to many, and builds the shell on it.

Why the generalisation is here rather than later. Every subsystem after this one needs to persist something — profiles, events, contacts, recipes, packs, jobs. A store per collection would give each its own idea of who wrote what and when, which is exactly what provenance cannot be reconstructed without.

The shell is three regions that never move: rail, board, console. Only the board area is ever redrawn, so a slow or failed turn cannot leave you without a way to navigate or to type.

Profiles scope by space — shared plus your own — as a filter over one log rather than separate stores, so moving something to the shared list is a field change and not a migration. A PIN is a speed bump, and the UI says so in those words rather than implying security it does not have.

The tap layer keeps two things apart that are easy to conflate: a mutating tap writes the store, redraws synchronously and never calls a model; an asking tap starts a turn. Conflating them is how an app spends money and three seconds on ticking a box.

A bug the e2e caught, not a refactor. Two concurrent apply calls both read the same highest sequence number and minted colliding keys, so IndexedDB rejected the second and the write was silently lost. A tick and the transcript line describing it are exactly that pair. Writes are now serialised, with a regression test.

Verified: 82 unit tests, offline e2e extended to cover the console line and undo.

🤖 Generated with Claude Code