The reframe: you don't have 4 feedback tools, you have 1 pipeline with 4 capture surfaces

Right now each tool is built as a vertical silo — it owns its own capture UI, its own data shape, its own auth, and its own destination. That's why it feels like 4 tools. But look at what actually varies vs. what's identical:

The capture payload is ~80% identical across all four — text, optional screenshot, context (URL/section/viewport), author. What genuinely differs is only two axes: who's authoring (anon client vs internal) and where it should route (backlog idea vs design-review vs QA/support queue). Everything else is duplicated, not differentiated.

And you can already see the cost of the silo model in your own code: DevFeedbackWidget.tsx's header says it exists to replace "previously drifting copies" of the same widget. That drift is the symptom of organizing by tool instead of by seam.

What's structurally wrong today

1. Three destinations, no single intake. QuickActions POSTs straight to Notion, the review widget writes Supabase design_feedback (then syncs to Notion), the dev widget hits a separate /api/feedback. Adding the Chrome extension naively makes it four sinks. Every new "capture more data" feature (richer screenshots, console logs, DOM snapshots) then has to be implemented N times.
2. Capture logic is duplicated across languages (vanilla JS pin widget + React dev widget + Swift form) with no shared schema. They drift.
3. The Swift tool bypasses the portal entirely, so it can never benefit from shared routing, dedup, or analytics.

The target shape: thin surfaces → one envelope → one intake → routing

CAPTURE SURFACES CONTRACT INGESTION ROUTING ┌───────────────┐ │ macOS (Swift) │──┐ ├───────────────┤ │ ┌──────────────┐ ┌────────────────┐ ┌─ design review │ Chrome ext │──┼────► │ Feedback │──► │ POST /api/ │──► ├─ backlog (Notion) ├───────────────┤ │ │ Envelope │ │ feedback/intake│ ├─ QA queue │ Review widget │──┤ │ (versioned) │ │ (validate + │ ├─ support ├───────────────┤ │ └──────────────┘ │ fan out) │ └─ Slack/email │ Dev widget │──┘ └────────────────┘ └───────────────┘

Three seams to make explicit:

• One envelope schema — { source, intent, author, context{url,project_id,variant_key,section,viewport,screenshot}, payload, metadata }. Versioned and additive (a metadata jsonb), so "capture more data over time" = add a field, not a new pipeline. You already have the right instinct here — design_feedback.section_context is a jsonb escape hatch. Generalize that.
• One intake endpoint that validates the envelope and routes by intent (idea→backlog, client-review→design_feedback, qa→QA queue, support→support). Auth becomes a per-source concern at the edge (anon token for review, session for internal), not a per-destination one.
• Thin adapters — each surface only does platform-specific capture + auth, then hands a standard envelope to intake. The pin-drop/screenshot logic lives in one shared core the JS surfaces import.

The honest caveat — don't over-unify