U3 — The Scribe

An in-page chat plus a browser extension, treated as "the same pattern on two surfaces" — the richest unbuilt design here. Four findings, three of them hard platform constraints anyone building an extension needs before they start.

File to an inbox, never edit directly

The architectural decision: "A chat that reads page content and holds a write key is a confused deputy by construction, with the page as untrusted input and the write as the privileged action." The brief notes this is "the ambient authority problem this corpus has now traced three times," and that filing to a staging area "removes it entirely while preserving the loop."

The permissions answer, better than the ask

The founder's memo wanted a mode without per-site permission prompts. It exists: activeTab combined with scripting grants access to the current page "only when the user explicitly invokes the extension," with no install-time warning, and published guidance says this replaces broad host permissions for most use cases. The alternative produces the "read and change all your data on all websites" warning and "may require an in-depth review that delays publishing." Recommended manifest shape: activeTab, scripting, storage, no host permissions at all, with optional host permissions requested at runtime only if a later feature proves it necessary.

The consequence is designed-around rather than lamented: "because access is granted on invocation, the extension cannot watch pages in the background. Everything it does is user-initiated. For a feedback and observation tool that is exactly right." This is the opposite of the recorder's requirement, which needs document_start in MAIN world precisely to see page load — two extensions, two correct and incompatible permission postures. The choice follows from whether the tool observes continuously or acts on invocation.

The narrow remote-code rule

The platform prohibits remotely hosted code: "All extension logic must be part of the package: no scripts fetched from a server, no libraries from a CDN, and no bundled library that dynamically fetches code."

It says nothing about data. The brief is explicit on the split: the extension "may fetch vault content and render it, because that is data"; it may not fetch a vault application and execute it, "because that is remotely hosted code."

So exactly one idea dies — reusing the vault app runtime by loading vault-hosted apps into the extension — settled early "because it changes what code is shared with the vault web application and what has to be bundled separately." Two shapes survive: bundle your own client and treat vaults purely as data, or open the vault app in a normal tab or sandboxed frame with the extension as launcher rather than host.

What is emphatically not ruled out is a vault as the extension's storage — which the same brief reaches for two sections later, on where chat history should live: "the durable copy belongs in the inbox vault anyway." See U6.

Hold a channel, not a key

"A login does not solve key storage but only moves it." A write-only channel to a feedback vault sidesteps key storage entirely for the primary use case. Read this next to U4, which reaches the same destination from the opposite direction — U3 avoids holding a key; U4 holds one but treats the store as an untrusted transport.