docs: a plan for third-party integrations (MCP, not connectors)

[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: 13 of 14. Base: lifeboard/11-docs. Documentation only — no code changes.

A plan for reaching Gmail, Drive, Dropbox, Maps and everything after them, plus how to reuse T3 Code rather than rewrite it. Full text: docs/lifeboard/integrations-plan.md.

The finding: we have been building the expensive version of a solved problem. src/google/ is a hand-rolled OAuth client, calendar client and Gmail client — several hundred lines, per provider, that we now own forever. Dropbox would be that again. Maps would be that again.

Meanwhile the bridge already runs Claude Code, Codex CLI and Gemini CLI, and those are already MCP clients. Any MCP server the household has configured is reachable through the agent we are already talking to, authenticated as them, with no connector code from us.

Three tiers, in preference order:

1. Through the bridge to the agent's own MCP servers — no integration code, auth stays where the person already granted it.
2. Remote MCP over HTTP from the browser — same surface for a no-bridge install; one OAuth dance against a standard rather than a bespoke client per provider.
3. Hand-rolled in the browser — the exception, justified only for calendar read and mail triage, which must work offline and deterministically. That is what src/google/ already is, and it should stop there.

What is genuinely ours to build: tool discovery and invocation on the bridge; a permission model reusing the pack uses allow-list and the existing trust ladder; and source adapters, because a fact arriving through a tool with no deep link silently degrades the lineage view to "came from somewhere". That last one is the piece most likely to be skipped and most likely to matter.

On reusing T3 Code: the part worth reusing is the driver table — which binaries exist, which flags produce non-interactive output, what "signed out" looks like on stderr. It is empirical and goes stale, and a shared project maintains it better than we can. The plan is: read their licence first, prefer taking it as data rather than code, attribute, and contribute back. I could not evaluate their licence or source in this session — no network — so that is a sequence to follow, not a conclusion about their code.

Four unknowns are stated rather than papered over, including the one the plan hinges on: whether the CLI agents allow direct tool invocation of their MCP servers, or only conversational use. Step 0 is verifying them.

No verification claims: this PR changes no code. Suites unchanged.

🤖 Generated with Claude Code