feat(dashboard): add editable organization business context

.agents/skills/databuddy-internal/SKILL.md

@@ -151,7 +151,7 @@ Read [codebase-map.md](./references/codebase-map.md) when you need deeper routin
 - Integration catalog logos: use filled Simple Icons SVG path data (or equivalent filled brand SVG), store the path on each item as `iconPath`, render it through a shared logo tile with `bg-secondary/60`, `border-border/70`, `text-foreground`, and `fill="currentColor"`, then use brand color only as a small accent bar (`accent` or `accentClassName: "bg-foreground/70"` for black/near-black brands). Avoid raw brand-black icons or mixed line/filled icon sets that disappear in dark mode.
 - Organization integrations settings should stay list-first and operational: coming-soon integrations are static rows, Slack is the only expandable row for now, and connected integrations need obvious lifecycle controls such as uninstall/disconnect in the row details.
 - MCP setup UI should mirror the governed write metadata in `packages/ai/src/ai/mcp/tools.ts`: default to `read:data`, then expose explicit action bundles for workspace actions, feature flags, and short links with their required scopes and confirmation behavior.
-- Dashboard UI must use `apps/dashboard/components/ds` primitives exactly; feature code must not use raw form/control elements (`button`, `input`, `select`, `textarea`, native dialogs), Base UI/Radix primitives, or ad hoc styled controls directly. If a variant is missing, add or extend the DS component first. For menu-style folder/status/filter/sort/action pickers, use `components/ds/dropdown-menu.tsx`; use `Select` only when the established pattern is explicitly a select/combobox. Read `apps/dashboard/components/ds/README.md` before creating new dashboard UI.
+- Dashboard primitives now live in `packages/ui/src/components` and are consumed through `@databuddy/ui` (`@databuddy/ui/client` for client-only components); the old `apps/dashboard/components/ds/README.md` path no longer exists. Read the corresponding shared component implementation before extending UI. Dashboard UI must use these shared primitives exactly; feature code must not use raw form/control elements (`button`, `input`, `select`, `textarea`, native dialogs), Base UI/Radix primitives, or ad hoc styled controls directly. If a variant is missing, add or extend the DS component first. For menu-style folder/status/filter/sort/action pickers, use `components/ds/dropdown-menu.tsx`; use `Select` only when the established pattern is explicitly a select/combobox. Inspect the shared component APIs in `packages/ui/src/components` before creating new dashboard UI.
 - `DropdownMenu.GroupLabel` must be rendered inside `DropdownMenu.Group`; Base UI throws `MenuGroupRootContext is missing` when labels are placed directly under `DropdownMenu.Content`.
 - Traffic Trends chart annotations should use a chart-adjacent annotation rail for dense data; avoid in-plot labels, tall lines, or floating dots that compete with the chart tooltip/data layer.
 - Flags list rows (`app/(main)/websites/[id]/flags/_components/flags-list.tsx`) are clickable containers with nested controls; mark nested controls with `data-row-interactive="true"` and have the row ignore those targets instead of relying on broad cell-level `stopPropagation`.

.agents/skills/frontend-design/SKILL.md

@@ -10,7 +10,7 @@ The user provides frontend requirements: a component, page, application, or inte
 
 ## Repository UI Guardrail
 
-When working inside the Databuddy dashboard (`apps/dashboard`), the existing design system is mandatory and overrides the generic creative guidance below. Read `apps/dashboard/components/ds/README.md` and build feature UI from `apps/dashboard/components/ds` primitives exactly. Do not use raw form/control elements (`button`, `input`, `select`, `textarea`, native dialogs), Base UI/Radix primitives, or one-off styled controls in feature components. If the needed API or variant is missing, add or extend the DS primitive first.
+When working inside the Databuddy dashboard (`apps/dashboard`), the existing design system is mandatory and overrides the generic creative guidance below. Build feature UI from `@databuddy/ui` primitives and inspect their APIs in `packages/ui/src/components`. The former `apps/dashboard/components/ds/README.md` path no longer exists. Do not use raw form/control elements (`button`, `input`, `select`, `textarea`, native dialogs), Base UI/Radix primitives, or one-off styled controls in feature components. If the needed API or variant is missing, add or extend the DS primitive first.
 
 For Databuddy dashboard pickers, use `DropdownMenu` for menu-style folder/status/filter/sort/action choices. Use `Select` only when the established pattern is truly a select/combobox. Product dashboard surfaces should stay consistent, dense, and operational rather than exploratory or marketing-styled.
 

.github/workflows/ci.yml

@@ -181,6 +181,13 @@ jobs:
           CLICKHOUSE_URL: http://default:@localhost:8123
           NODE_ENV: test
         run: bun run test
+      - name: Business context integration
+        env:
+          NODE_ENV: test
+          BUSINESS_CONTEXT_INTEGRATION_TESTS: "true"
+        run: |
+          bun test packages/services/src/organization-business-context.integration.test.ts packages/services/src/organization-business-context-hardening.integration.test.ts
+          bun test packages/auth/src/organization-metadata.integration.test.ts
       - name: Insights integration
         env:
           NODE_ENV: test