The search-and-add remote ships — editable search terms, a provider palette, and one-click add wired back to the org card
The flow's second microfrontend: every 🔍 on the org card opens a paired search rail with the term in an always-editable bar, providers a chip away (SearXNG preselected, Exa/Tavily/SerpApi as peers), and every result row one ➕ from landing on the launching entity's list — with the card refetching the instant it does.
Phase 3 of Augment From DB Flow: apps/search-and-add (:3016) exists, and the spec's search→add sequence diagram is now real chrome. Click 🔍 next to any list on the org card → the shell opens the orgWorkbench+searchAndAdd pairing (card keeps 55%) → the seeded term sits in an editable bar → results land → one ➕ per row adds to exactly the list that launched the search → the card refetches via augment-it:entity-updated.
What shipped
The remote. TermBar is the standing constraint made chrome — the term is always visible, always editable, Enter re-fires. ProviderPalette renders connectors.inventory as chips (short_label + cost tier, paid tiers dash-bordered, needs-env dark and unclickable, "auto" = registry free-tier-first). ResultRow carries the one-click ➕ with per-row added/error state — re-adds are server-side dedup'd anyway. Auto-fires once per fresh envelope: searches are reads; the gating thesis governs writes, and every write here is one deliberate click.
The launch contract, hardened (D2 refinement). The augment-it:search-request CustomEvent alone is racy — search-and-add mounts asynchronously when its pairing first opens, so a dispatch-then-mount ordering would drop the payload. The envelope therefore ALSO persists to localStorage['augment-it:search-request'] (the repo's established cross-remount pattern); the remote reads it on mount, then listens live. org-workbench's requestSearch() does all three writes in order: localStorage → search-request event → augment-it:navigate {remoteId:'searchAndAdd'}.
Verb routing. org: links/streams/corpus → the three organization.*.add verbs; person: links/corpus → the two person.*.add verbs (persons have no streams — the combination is guarded at both the client and App level). Person-shaped envelopes are fully wired but nothing dispatches them until Phase 4's people reveal.
Seed terms, hardcoded v1 (spec open question stands): links "<name>" LinkedIn · streams "<name>" blog · corpus "<name>" news. The operator rewrites them freely — that's the point of the TermBar.
Proof
svelte-check 0/0 on both remotes; both build plus the shell; :3016/remoteEntry.js → HTTP 200; Phase 1 proof re-run 7/7 (the search.fire + inventory paths this remote consumes). The full browser loop — 🔍 → pairing opens → edit term → swap to Exa → ➕ → card refreshes → dedup on second ➕ — is the operator's walk-through; every scriptable leg beneath it is scripted.
What's next
Phase 4: the people reveal — organization.affiliations rendered as person rows under the org card, nested person links/corpus with their own ➕ and 🔍 (the person-shaped envelopes this remote already routes), and add-person-with-automatic-affiliation via person.affiliate.