Product Parity Backlog

# Product Parity Backlog

**Goal:** Make the Sprinter Platform capable of fully replicating any vertical product (investor monitoring, research assistant, portfolio intelligence, etc.) through DB configuration alone — zero custom code. Every item below is a **general-purpose platform feature** that benefits all tenants.

**Methodology:** Cross-referenced against ChatGPT's 52-item audit, Ember codebase analysis, live app screenshots, and current platform capability inventory. Items are ranked by `Impact / Effort` ratio with quick wins first.

**Constraint:** No product-specific code. No hardcoded slugs. Everything is config-driven and generalizable.

---

## Current Platform Capabilities (What Already Exists)

Before reading the gaps, here's what the platform already handles:

| Capability | Status | Config Surface |
|---|---|---|
| Entity types (schema-driven) | Complete | `entity_types.json_schema` + `config.fields` |
| Views (list, workspace, tabs, regions) | Complete | `views` table with blocks, regions, tabs |
| Navigation (recursive tree, sources) | Complete | `nav_configs` table, NavNode tree |
| Theming (colors, fonts, density, radius) | Complete | `tenant_settings` key=theme, ThemeConfig |
| Blocks (27 types) | Complete | BlockConfig in views |
| Form flows (wizard/stepper) | Complete | `form-flow` block type with steps |
| Three-panel layout | Complete | `layout_preset: "three-panel"` in views |
| Resizable panels | Complete | `ResizablePanelGroup` component |
| Agent system (DB + code agents) | Complete | `agents` table + config |
| AI chat with agent selection | Complete | Chat picker, agent tools |
| Document upload + processing | Complete | Documents feature |
| Extraction (field-level, agent-driven) | Complete | `config.fields.*.extraction` |
| Response/criteria system | Complete | `criteria_sets` + `entity_responses` |
| Multi-tenant with tenant switching | Complete | `user_tenants`, proxy middleware |
| Entity relations + connections | Complete | `entity_relations` + connection-list blocks |
| Command palette (global search) | Complete | `components/app-shell/command-palette.tsx` |
| Activity logging | Complete | `activity` block, activity feed |
| Card system with accent colors | Complete | `CardConfig` with field display |
| Status banners | Complete | `status-banner` block type |
| Charts (radar, bubble, line, bar) | Complete | chart block types |
| Comments | Complete | Comments feature |
| Tenant settings cascade | Complete | default → tenant → user |
| Container/workspace entities | Complete | `ContainerConfig` |
| PDF viewer | Complete | `pdf-viewer` block |
| Entity graph visualization | Complete | `entity-graph` block |

---

## Backlog

### Tier 1: Quick Wins (High Impact, Low Effort)

These can each be done in under a day and have outsized UX impact.

---

#### 1. Nav source `agents` should include DB-managed tenant agents

**Type:** Bug fix / Platform improvement
**Impact:** 5 | **Effort:** 1 | **Quick Win:** Yes

**Problem:** Sidebar "Agents" source only shows code-defined agents from the registry. Tenants with DB-only agents see "No agents configured" even when agents exist.

**Solution:** Update the `agents` nav source resolver in `features/navigation/` to query the `agents` table for the active tenant, merging results with code-defined agents.

**Definition of Done:**
- Nav source type `agents` returns both code-defined and DB-managed agents for current tenant
- Agent items link to `/admin/agents/{id}` or open chat with that agent
- Works for all tenants, not just specific ones

**Dependencies:** None
**Confidence:** High

---

#### 2. View tab switcher preserves tenant URL prefix

**Type:** Bug fix
**Impact:** 4 | **Effort:** 1 | **Quick Win:** Yes

**Problem:** Clicking view tabs on entity list pages drops the `/t/{tenantSlug}/` prefix, breaking navigation for non-default tenants.

**Solution:** Use `tenantUrl()` from `features/tenant/constants.ts` when generating view tab hrefs.

**Definition of Done:**
- View tab navigation preserves tenant-scoped URLs (`/t/{slug}/...`)
- Works in both sidebar links and in-page view switcher
- No regression for default tenant (no prefix)

**Dependencies:** None
**Confidence:** High

---

#### 3. Data table density modes (compact / default / spacious)

**Type:** Platform enhancement
**Impact:** 5 | **Effort:** 2 | **Quick Win:** Yes

**Problem:** Data tables always render at the same density. Analyst-heavy products need dense tables; consumer products need airy ones. The theme system already has `DENSITY_OPTIONS = ["compact", "default", "spacious"]` but tables don't consume it.

**Solution:** Wire the density preference from `ThemeConfig.density` into the data table component. Compact: `py-1 text-xs`, Default: `py-2 text-sm`, Spacious: `py-3 text-base`. Also expose as a per-view override in view config.

**Definition of Done:**
- Data table respects tenant-level density setting from theme config
- Per-view density override via view config
- User can toggle density in table toolbar
- Row heights, font sizes, and padding adjust per mode
- Sticky headers remain sticky at all densities

**Dependencies:** Theme system (exists)
**Confidence:** High

---

#### 4. Per-tenant branding: logo, app name, favicon

**Type:** Platform enhancement
**Impact:** 5 | **Effort:** 2 | **Quick Win:** Yes

**Problem:** Sidebar shows hardcoded "Sprinter" branding. Tenants can't customize the product name, logo, or favicon to match their brand identity.

**Solution:** Add `branding` key to `tenant_settings`:
```ts
type BrandingConfig = {
  appName?: string;        // Sidebar header text
  logoUrl?: string;        // Custom logo image URL
  logoIcon?: string;       // Icon name from icon map (alternative to URL)
  faviconUrl?: string;     // Custom favicon
  tagline?: string;        // Optional subtitle under app name
}
```

**Definition of Done:**
- Sidebar header shows tenant's `appName` instead of "Sprinter" when configured
- Logo renders from `logoUrl` or `logoIcon`
- Favicon can be overridden per tenant
- Falls back to platform defaults when not configured
- Admin panel has Branding section to configure

**Dependencies:** Tenant settings system (exists)
**Confidence:** High

---

#### 5. Configurable entity list empty states

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 1 | **Quick Win:** Yes

**Problem:** Empty entity lists show generic "No items" text. Products need context-specific empty states with icons, descriptions, and CTAs.

**Solution:** Add optional `emptyState` to entity type config:
```ts
emptyState?: {
  icon?: string;
  title?: string;
  description?: string;
  ctaLabel?: string;
  ctaAction?: "create" | "import" | "link";
}
```

**Definition of Done:**
- Entity list pages render configured empty state instead of generic fallback
- Icon, title, description, and CTA button are all config-driven
- CTA opens create dialog, import flow, or external link based on `ctaAction`
- Works on all view modes (table, grid, kanban)

**Dependencies:** None
**Confidence:** High

---

#### 6. Status chip component with config-driven variants

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 1 | **Quick Win:** Yes

**Problem:** Entity fields that represent statuses (connected, disconnected, healthy, error, pending) render as plain text. Products need colored status chips with icons.

**Solution:** Add `displayType: "status"` to FieldConfig with a `statusMap`:
```ts
statusMap?: Record<string, {
  label?: string;
  color: "success" | "error" | "warning" | "info" | "muted";
  icon?: string;
}>
```
The entity card, data table, and field-card blocks render status fields as colored badges.

**Definition of Done:**
- Fields with `displayType: "status"` render as colored chips in all contexts
- Status map is configurable per field in entity type config
- Works in data tables (column renderer), entity cards, and field-card blocks
- Ships with built-in mappings for common values (active/inactive, healthy/error, etc.)

**Dependencies:** None
**Confidence:** High

---

#### 7. Inline health/alert banners on entity detail pages

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 1 | **Quick Win:** Yes

**Problem:** Entity detail pages can't show contextual alerts (e.g., "credentials expiring", "3 fields need review", "extraction failed"). The `status-banner` block exists but isn't dynamically driven.

**Solution:** Enhance `status-banner` block to accept config for:
- `condition`: field name + operator + value (e.g., `status == "needs_reauth"`)
- `variant`: success | warning | error | info
- `message`: template string with `{field}` interpolation
- `dismissible`: boolean
- `action`: optional CTA button

**Definition of Done:**
- Status banner block evaluates conditions against entity content
- Only renders when condition is met
- Message interpolates entity field values
- Optional CTA links to relevant action
- Configurable from view block config, no code changes

**Dependencies:** None
**Confidence:** High

---

#### 8. Field display formatters (currency, percentage, date, URL, email)

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2 | **Quick Win:** Yes

**Problem:** The `displayType` field on FieldConfig exists but only a few formats are implemented. Products need currency, percentage, relative date, URL (clickable link), email, phone, and custom number formatting.

**Solution:** Implement all standard display types in the field value renderer:
- `currency` — `$1,234,567` with configurable currency symbol
- `percentage` — `67.5%`
- `date` — relative ("2 days ago") or absolute
- `url` — clickable link with external icon
- `email` — mailto link
- `phone` — tel link
- `number` — with configurable decimal places and separators
- `bytes` — `1.2 GB`
- `duration` — `3h 45m`

**Definition of Done:**
- All display types render correctly in data tables, entity cards, and field-card blocks
- `formatDisplayValue()` utility handles all types
- Display type is configurable per field in entity type config
- No code changes needed to add new format to a field

**Dependencies:** None
**Confidence:** High

---

#### 9. Entity type icon and color in all surfaces

**Type:** Platform enhancement
**Impact:** 3 | **Effort:** 1 | **Quick Win:** Yes

**Problem:** Entity types have `icon` and `color` in config but these aren't consistently used across sidebar nav, entity cards, list headers, breadcrumbs, and detail pages.

**Solution:** Thread entity type icon + color through:
- Sidebar nav items (entity-type nodes)
- List page headers
- Entity card headers
- Breadcrumb components
- Command palette results

**Definition of Done:**
- Entity type icon and color appear consistently in all 5 surfaces
- Falls back gracefully when not configured
- Color uses CSS variables, not hardcoded values

**Dependencies:** None
**Confidence:** High

---

#### 10. Batch actions on entity lists (bulk edit, delete, export)

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2 | **Quick Win:** Yes

**Problem:** Entity list data tables have row selection but no batch action toolbar. Users can't bulk edit, delete, tag, or export selected entities.

**Solution:** Add a sticky batch action toolbar that appears when rows are selected:
- Delete selected (with confirmation)
- Add/remove tags
- Change field value (for enum/select fields)
- Export selected as CSV
- Configurable actions per entity type via config

**Definition of Done:**
- Selection checkbox column on data tables
- Sticky toolbar appears with count when items selected
- Delete, tag, and export actions work
- Tenant can configure additional batch actions per entity type
- All actions are permission-gated

**Dependencies:** None
**Confidence:** High

---

### Tier 2: Foundation Features (High Impact, Moderate Effort)

These take 1-3 days each but unlock major capability.

---

#### 11. Master-detail view layout with filter rail

**Type:** Platform primitive
**Impact:** 5 | **Effort:** 3

**Problem:** The platform has a `three-panel` layout preset in ViewShell but no interactive master-detail pattern where clicking a list item shows its detail in a side panel. This is essential for feed, queue, and monitoring views.

**Solution:** Create a `master-detail` list view variant:
- Left: optional filter rail with faceted filters
- Center: scrollable list (reusing entity data table or card list)
- Right: detail panel showing selected entity's workspace/detail view
- URL state tracks selected item ID
- Resizable panel widths persisted to user preference

**Definition of Done:**
- New `page_type: "master-detail"` or view layout option
- Filter rail renders faceted filters from entity type schema (enums, tags, dates)
- Clicking a list item loads its detail view in the right panel
- Panel widths are resizable and persisted
- Works on mobile (stacks vertically, detail as a sheet)
- Configurable from view config — no code needed per entity type

**Dependencies:** Resizable panels (exist), ViewShell three-panel (exists)
**Confidence:** Medium

---

#### 12. Per-tenant theme presets (shell appearance)

**Type:** Platform enhancement
**Impact:** 5 | **Effort:** 2

**Problem:** The theme system supports colors, fonts, density, and radius, but there's no concept of named "presets" that a tenant can select. Products need distinct visual identities that go beyond color changes.

**Solution:** Add theme preset capability:
- Presets bundle: colors + font + density + radius + sidebar style
- Built-in presets: "enterprise" (current), "minimal", "dark-analyst", "modern"
- Tenant can select a preset as baseline then override individual values
- Admin UI in Settings > Appearance to browse and apply presets

**Definition of Done:**
- 4+ built-in theme presets with distinct visual identities
- Tenant-level preset selection via `tenant_settings` key=theme
- Individual overrides layer on top of preset
- Preview capability in admin before applying
- Sidebar style (sidebar/icon-rail/floating/inset) is part of the preset

**Dependencies:** Theme system (exists), Nav config (exists)
**Confidence:** High

---

#### 13. Contextual top-bar with tabs, badges, and breadcrumbs

**Type:** Platform enhancement
**Impact:** 5 | **Effort:** 3

**Problem:** The app uses a sidebar-only navigation pattern. Many products need a contextual top bar or secondary navigation within pages — tabs with counts (e.g., "Feed (42)", "Recaps (3 new)", "Feedback (7)"), breadcrumbs showing entity hierarchy, and page-level actions.

**Solution:** Add a configurable page header/top-bar component:
- Breadcrumbs from entity type → entity hierarchy
- Tab navigation with optional badge counts
- Page-level action buttons (configurable)
- Collapsible on scroll
- Config-driven via view config or entity type config

Top bar tabs can source counts from:
- Entity count by type + filter
- Unread/unseen count (requires read-tracking)
- Custom API endpoint

**Definition of Done:**
- View config supports `header.tabs` array with label, href, badge source
- Badge counts update automatically (entity count query or custom)
- Breadcrumbs auto-generate from entity type + parent chain
- Works with all layout presets
- No product-specific references

**Dependencies:** None
**Confidence:** Medium

---

#### 14. Read/seen tracking for entities

**Type:** Platform primitive
**Impact:** 4 | **Effort:** 2

**Problem:** Products that show feeds, queues, or notification lists need to track which items a user has seen/read. This enables "unread count" badges, "mark as read" actions, and "show unread only" filters.

**Solution:** New `entity_reads` table:
```sql
CREATE TABLE entity_reads (
  entity_id uuid REFERENCES entities(id) ON DELETE CASCADE,
  user_id uuid REFERENCES auth.users(id) ON DELETE CASCADE,
  read_at timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (entity_id, user_id)
);
```
- Automatically mark as read when detail view opened
- "Mark as read/unread" action on list items
- Filter by read status in entity list views
- Badge count source for nav items and tabs

**Definition of Done:**
- `entity_reads` table with RLS
- Auto-mark on detail view
- Manual mark read/unread action
- Read status column in data tables (dot indicator)
- Filter by read status in list views
- Nav badge source `unread-count` for entity-type nodes
- Badge auto-updates when items are read

**Dependencies:** None
**Confidence:** High

---

#### 15. Configurable entity card templates

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2

**Problem:** Entity cards use `CardConfig` for field display but the layout options are limited. Products need cards with:
- Header with icon + title + status chip
- Subtitle line with formatted metadata
- Body with 2-3 key field values
- Footer with tags + timestamp + actions
- Accent color strip from entity type or field value

**Solution:** Extend `CardConfig` with layout sections:
```ts
interface CardConfig {
  layout?: "standard" | "compact" | "media" | "stat";
  header?: { titleField, subtitleField, iconField, statusField };
  body?: { fields: string[]; maxLines?: number };
  footer?: { showTags, showTimestamp, actions?: CardAction[] };
  accent?: { field?: string; colorMap?: Record<string, AccentColor> };
  thumbnail?: { field: string; position: "left" | "top" };
}
```

**Definition of Done:**
- 4 card layout presets (standard, compact, media, stat)
- Card sections (header, body, footer) are configurable
- Accent color can be driven by a field value
- Thumbnail/image support with position options
- All configurable from entity type config, no code changes per type

**Dependencies:** Card system (exists)
**Confidence:** High

---

#### 16. Saved filters and filter presets for entity lists

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2

**Problem:** Entity lists support search and column-level sorting but lack saved filter presets. Products need to offer pre-configured filter combinations (e.g., "Needs attention", "Recently updated", "High score") as quick-select options.

**Solution:**
- Add `filters` array to view config:
```ts
interface ViewFilter {
  id: string;
  label: string;
  icon?: string;
  conditions: FilterCondition[];
}
interface FilterCondition {
  field: string;  // "status", "tags", "score", "created_at"
  operator: "eq" | "neq" | "gt" | "lt" | "gte" | "lte" | "contains" | "in";
  value: unknown;
}
```
- Render as filter chips/pills above the data table
- Users can combine multiple filter presets
- Users can save custom filter combinations

**Definition of Done:**
- View config supports `filters` array with conditions
- Filter pills render above data table
- Active filters apply to the entity query
- Users can save custom filter combinations as personal views
- Date-range filter: today, this week, this month, custom range
- Tag filter with multi-select

**Dependencies:** None
**Confidence:** High

---

#### 17. Inline entity actions (quick actions on list items)

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2

**Problem:** Entity list rows have limited actions (click to open). Products need configurable per-row actions like: mark as reviewed, change status, add to collection, trigger extraction, archive.

**Solution:** Add `rowActions` to entity type config or view config:
```ts
interface RowAction {
  id: string;
  label: string;
  icon?: string;
  type: "update-field" | "create-relation" | "trigger-workflow" | "delete";
  config: Record<string, unknown>;
  confirmation?: string;
  permission?: string;
}
```

**Definition of Done:**
- Row action dropdown (three-dot menu) on data table rows
- Actions are config-driven per entity type or per view
- `update-field` sets a content field value (e.g., mark as reviewed)
- `create-relation` links to another entity via picker
- Actions are permission-gated
- Toast feedback on success/error
- Keyboard shortcut support for common actions

**Dependencies:** None
**Confidence:** High

---

#### 18. Configurable dashboard with drag-and-drop block placement

**Type:** Platform enhancement
**Impact:** 5 | **Effort:** 3

**Problem:** The dashboard page (`/dashboard`) has a hardcoded layout. Tenants can't customize which KPI blocks, charts, tables, or feeds appear on their dashboard. Products need very different dashboards.

**Solution:** Make the dashboard a workspace view:
- Dashboard is a `views` record with `page_type: "workspace"`
- Tenant admin can configure dashboard blocks via the view editor
- Drag-and-drop block reordering
- Pre-built dashboard block types: stat-cards, chart, ranking, entity-feed, activity, recent-items

**Definition of Done:**
- Dashboard reads from a tenant-scoped view record
- Admin can add/remove/reorder dashboard blocks
- 6+ dashboard-appropriate block types available
- Default dashboard view auto-created for new tenants
- Individual users can customize their dashboard (user-scoped view override)

**Dependencies:** View editor (exists)
**Confidence:** Medium

---

#### 19. Entity list column configuration via entity type config

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2

**Problem:** Data table columns are auto-generated from JSON schema. Products need control over: which columns appear by default, column order, column widths, column formatting, and column labels.

**Solution:** Add `listConfig` to entity type config:
```ts
interface EntityTypeListConfig {
  defaultColumns?: string[];       // Which fields to show by default
  columnOrder?: string[];          // Display order
  columnWidths?: Record<string, number>;  // px widths
  columnLabels?: Record<string, string>;  // Override labels
  defaultSort?: { field: string; direction: "asc" | "desc" };
  searchableFields?: string[];     // Which fields are searchable
}
```

**Definition of Done:**
- Entity list pages respect `config.listConfig` for column selection and ordering
- Column widths persist when user resizes
- Default sort respects config
- Search targets configured searchable fields
- Falls back to auto-generate from schema when not configured

**Dependencies:** None
**Confidence:** High

---

#### 20. Notification system (in-app + optional email)

**Type:** Platform primitive
**Impact:** 4 | **Effort:** 3

**Problem:** The platform has no notification system. Products need: extraction completion alerts, credential expiry warnings, recap delivery, entity update notifications, and agent heartbeat results.

**Solution:**
- `notifications` table: `id, tenant_id, user_id, type, title, body, metadata, read_at, created_at`
- Notification bell in header with unread count
- Notification drawer/panel
- Notification preferences per user (which types to receive)
- Optional email delivery via webhook or Resend
- Platform events that create notifications (configurable):
  - Extraction complete
  - Entity created/updated (for watched entities)
  - Agent heartbeat result
  - Workflow node completed
  - Comment mention

**Definition of Done:**
- `notifications` table with RLS
- Bell icon with unread count in app header
- Notification drawer with mark-as-read
- At least 5 notification event types
- User preferences for notification types
- Configurable per tenant (which events generate notifications)

**Dependencies:** None
**Confidence:** Medium

---

### Tier 3: Capability Unlocks (High Impact, Higher Effort)

These take 3-5 days each but unlock entire product categories.

---

#### 21. Source provider registry and connector framework

**Type:** Platform infrastructure
**Impact:** 5 | **Effort:** 3

**Problem:** Products that monitor external data (news, filings, social, RSS) need a standard way to define source providers, configure connections, track health, and normalize ingested content.

**Solution:** Platform-level source abstraction:
- `source_providers` entity type (or dedicated table) with: name, type (rss/api/scrape/email), auth_type, health_status, last_success, last_error, config
- Connector interface: `fetch() → NormalizedContent[]`
- Built-in connectors: RSS, webhook receiver, manual upload
- Health monitoring via heartbeat
- Content normalization schema: title, body, source_url, published_at, author, provider_id, raw_payload

**Definition of Done:**
- Source provider management in admin
- RSS connector that creates entities from feed items
- Webhook receiver that accepts POST payloads and creates entities
- Health status tracking with last success/failure timestamps
- Normalized content schema applied to all ingested items
- Config-driven: tenant configures providers, no code per source

**Dependencies:** Inngest (exists)
**Confidence:** Medium

---

#### 22. Credential vault with connection testing

**Type:** Platform infrastructure
**Impact:** 4 | **Effort:** 3

**Problem:** Products connecting to external services need secure credential storage, connection testing, and reauth flows. Currently credentials are modeled as entities but with no actual secret storage or validation.

**Solution:**
- Supabase Vault integration for encrypted secret storage (or `pgp_sym_encrypt` if Vault isn't available)
- Credential entity type with: provider, auth_type (api_key, oauth2, basic, session), status, last_tested, last_error
- "Test Connection" action that validates credentials against the provider
- Reauth flow for expired tokens
- Credential health monitoring via scheduled jobs

**Definition of Done:**
- Secrets stored encrypted (not in entity content plaintext)
- "Test Connection" button on credential detail pages
- Health status automatically updated
- Expired/failing credentials surface warnings
- Admin can manage all credentials for the tenant
- No provider-specific code in platform — providers declare their auth requirements

**Dependencies:** Source provider registry (#21)
**Confidence:** Medium

---

#### 23. Content clustering and deduplication service

**Type:** Platform infrastructure
**Impact:** 5 | **Effort:** 4

**Problem:** Products that ingest content from multiple sources get duplicates and near-duplicates. Users need same-story clustering, duplicate suppression, and cluster-level summaries.

**Solution:**
- Embedding generation for ingested content (using existing vector infrastructure)
- Cosine similarity clustering with configurable threshold
- Dedup: exact (hash) + near-duplicate (embedding distance)
- Cluster entities auto-created/updated
- Cluster summary generation via LLM
- Configurable per entity type: which fields to embed, similarity threshold

**Definition of Done:**
- Ingested entities get embeddings generated automatically
- Exact duplicates detected and flagged
- Near-duplicates grouped into cluster entities
- Cluster entities have auto-generated summary
- Cluster view in entity list (group by cluster)
- Configurable: embedding fields, similarity threshold, cluster title generation

**Dependencies:** Source provider registry (#21)
**Confidence:** Medium

---

#### 24. Recap/digest generation pipeline

**Type:** Platform infrastructure
**Impact:** 5 | **Effort:** 3

**Problem:** Products need periodic digest generation — summarizing a time period's content into a structured recap entity. This is a key deliverable for monitoring products.

**Solution:** Scheduled recap generation via agent heartbeat:
- Recap template config: which entity types to summarize, time window, grouping, format
- LLM synthesis: top stories, key themes, takeaways
- Recap stored as entity with structured content (sections, highlights, sources)
- Configurable schedule: daily, weekly, custom
- Per-agent recap generation (each agent recaps its domain)

**Definition of Done:**
- Recap generation Inngest function triggered on schedule
- Configurable: entity type scope, time window, grouping field, format template
- Recap entity has structured sections (not just a text blob)
- Sources/references linked to original entities
- Schedule configurable per agent or per tenant
- Works for any entity type, not hardcoded to specific content

**Dependencies:** Agent heartbeat (exists), Inngest (exists)
**Confidence:** Medium

---

#### 25. Feedback and steering rule engine

**Type:** Platform infrastructure
**Impact:** 5 | **Effort:** 3

**Problem:** Products where users give feedback on AI-curated content (relevant/not relevant, reroute, block source) need that feedback to improve future results. Currently feedback entities exist but don't affect behavior.

**Solution:**
- Feedback entity type with standard schema: entity_ref, action (approve/reject/reroute/block), reason, metadata
- Steering rule entity type: condition (source, keyword, entity type), action (boost/suppress/reroute/block), scope (agent/tenant)
- Feedback → steering rule pipeline: certain feedback patterns auto-generate rules
- Extraction prompts incorporate approval rates and rejection reasons
- Source quality scoring based on feedback history

**Definition of Done:**
- Feedback submission UI (thumbs up/down, reroute, block source actions)
- Feedback creates `feedback_event` entities automatically
- High-confidence patterns auto-generate steering rules
- Extraction cross-references feedback when >= N responses exist (already exists)
- Steering rules consumed by source ingestion and content routing
- Dashboard showing feedback trends and rule effectiveness

**Dependencies:** Source provider registry (#21)
**Confidence:** Medium

---

#### 26. Entity routing engine (content → agent assignment)

**Type:** Platform infrastructure
**Impact:** 4 | **Effort:** 3

**Problem:** Products with multiple agents need content automatically routed to the right agent based on keywords, entity relationships, taxonomy, and source rules. Currently agents don't claim content.

**Solution:**
- Agent profile entity type with routing config: tracked keywords, tracked entity relations, include/exclude patterns
- Routing evaluator: when content entity is created, evaluate against all agent profiles
- Routing results stored as relations (agent → content entity)
- Routing explainability: why an item was routed to an agent
- Cross-agent routing: content can be routed to multiple agents

**Definition of Done:**
- Agent routing config (keywords, entity refs, patterns) is config-driven
- New entities evaluated against all agent profiles on creation
- Routing creates relations automatically
- Routing decision logged with explanation
- Routing visible in entity detail (which agents received this)
- Configurable via entity type config or agent config

**Dependencies:** Agent system (exists), Relations (exist)
**Confidence:** Medium

---

#### 27. Saved items / bookmarks / memory

**Type:** Platform primitive
**Impact:** 4 | **Effort:** 2

**Problem:** Users need to save/bookmark entities for later reference, organized into collections. Products use this for "saved research", "watch list", "memory items", etc.

**Solution:**
- `entity_bookmarks` table: entity_id, user_id, collection (optional string), notes, created_at
- "Save" action available on all entity cards and detail pages
- Bookmark sidebar section or dedicated page
- Collections for organizing bookmarks
- Quick access from command palette

**Definition of Done:**
- Save/unsave action on entity cards and detail pages
- Bookmarks page listing all saved items with collection filter
- Collections support (user-created groupings)
- Nav source `favorites` shows bookmarked items in sidebar
- Bookmark count visible on entity type nav items
- Search includes bookmarked items boost

**Dependencies:** None
**Confidence:** High

---

### Tier 4: Polish and Differentiation (Medium Impact)

These improve quality and create competitive advantage.

---

#### 28. Keyboard shortcut system

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2

**Problem:** The platform lacks keyboard shortcuts beyond the command palette (`Cmd+K`). Analyst products need: next/previous item, mark read, save, open detail, search focus, and navigation shortcuts.

**Solution:**
- Global keyboard shortcut system with configurable bindings
- Default shortcuts: `j/k` (prev/next in lists), `s` (save/bookmark), `r` (mark read), `/` (focus search), `e` (edit), `Esc` (close detail panel)
- Keyboard shortcut help overlay (`?`)
- Configurable per tenant (can add custom shortcuts for custom actions)

**Definition of Done:**
- 10+ default keyboard shortcuts for common actions
- `?` opens shortcut help overlay
- Shortcuts work in list views, detail views, and global
- Shortcuts respect focus context (don't fire when typing in inputs)
- Configurable shortcut bindings via tenant settings

**Dependencies:** None
**Confidence:** High

---

#### 29. Article/content reader pane

**Type:** Platform primitive
**Impact:** 4 | **Effort:** 3

**Problem:** Products that ingest articles, filings, or transcripts need a native reader view — clean typography, source metadata, provenance info, and "open in source" action. Currently content renders as raw entity fields.

**Solution:** New `reader` block type:
- Renders a content field as clean, readable article with typography
- Shows source metadata: provider, published date, author, original URL
- "Open in source" button
- Provenance badges (which agent extracted, confidence)
- Print/export action
- Configurable: which content field is the body, which are metadata

**Definition of Done:**
- `reader` block type that renders long-form content with good typography
- Source attribution bar (provider icon, date, author)
- "Open original" button linking to source URL
- Clean reading experience on desktop and mobile
- Configurable field mapping (body field, title field, metadata fields)
- Works with any entity type

**Dependencies:** None
**Confidence:** High

---

#### 30. Virtualized entity lists for large datasets

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 3

**Problem:** Entity lists don't virtualize rows. Large datasets (1000+ items) cause performance issues. Products with high-volume content need smooth scrolling.

**Solution:**
- Integrate `@tanstack/react-virtual` (already installed) into the data table
- Virtual scrolling for table and card/grid views
- Infinite scroll or paginated fetch
- Prefetch next page on scroll near bottom
- Maintain selection state across virtual pages

**Definition of Done:**
- Data table uses virtual scrolling for > 100 items
- Grid/card view uses virtual grid
- Smooth 60fps scrolling with 10,000+ items
- Row selection works across virtual pages
- Search/filter maintains scroll position
- Memory usage stays constant regardless of dataset size

**Dependencies:** `@tanstack/react-virtual` (installed)
**Confidence:** High

---

#### 31. Export/sharing for entity collections

**Type:** Platform enhancement
**Impact:** 3 | **Effort:** 2

**Problem:** Users can't easily export or share filtered entity lists. Products need CSV/PDF export, shareable links with filters, and email sharing.

**Solution:**
- CSV export of current filtered/sorted view
- Shareable view links with filter state encoded in URL
- Collection sharing (existing feature) with better UI
- PDF export of entity detail views
- Copy-to-clipboard for structured data

**Definition of Done:**
- "Export CSV" button on entity list toolbar
- Export includes all visible columns with current filters
- Shareable URL preserves filter/sort/search state
- PDF export of entity detail (print-optimized)
- Copy entity data as formatted text/markdown

**Dependencies:** Collection sharing (exists)
**Confidence:** High

---

#### 32. Enhanced search with faceted results and source-aware ranking

**Type:** Platform enhancement
**Impact:** 5 | **Effort:** 3

**Problem:** The command palette provides basic entity search. Products need: full-text search across entity content fields, faceted results by entity type, source-aware ranking, recent/bookmarked boost, and search within specific entity types.

**Solution:**
- Full-text search using Postgres `tsvector` (entities table already has `fts` column potential)
- Search results grouped by entity type with facet counts
- Ranking factors: relevance, recency, bookmark status, entity score
- Search within entity type (from list page search)
- Search history and suggestions
- Configurable: which fields are indexed, ranking weights

**Definition of Done:**
- Full-text search across entity title, description, and configured content fields
- Results grouped by entity type with counts
- Ranking considers: text relevance, recency, bookmarks, score
- Search page with filters by entity type, date range, tags
- Configurable indexing per entity type
- Search from command palette and from entity list pages

**Dependencies:** None
**Confidence:** Medium

---

#### 33. Agent directory view with health monitoring

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2

**Problem:** Agents are managed only in the admin panel. Products need a user-facing agent directory showing: agent status, last activity, health metrics, and quick actions (pause, trigger, chat).

**Solution:** Agent directory is a standard entity list view:
- Agent listing with: name, status, last heartbeat, tracked entities count, run history
- Quick actions: trigger run, open chat, view config, pause/resume
- Health indicators: last success/failure, run count, error rate
- Configurable via views + entity type config for `agent_profile` type

**Definition of Done:**
- Agent list view showing status, last run, and health
- Quick action buttons on each agent row
- Agent detail view with run history and configuration
- Health indicators (green/yellow/red) based on heartbeat results
- All data from existing `agents` + `agent_heartbeat_runs` tables

**Dependencies:** Agent heartbeat (exists)
**Confidence:** High

---

#### 34. Audit log viewer for entity changes

**Type:** Platform enhancement
**Impact:** 3 | **Effort:** 2

**Problem:** The activity system logs changes but there's no dedicated audit log viewer showing: who changed what, when, with before/after diffs. Products need this for compliance and trust.

**Solution:**
- Audit log page in admin (or per-entity timeline)
- Shows: timestamp, user/agent, action, entity, field-level changes
- Before/after diff view for field changes
- Filter by: user, entity type, action, date range
- Export audit log as CSV

**Definition of Done:**
- Audit log page in admin showing all entity changes
- Per-entity audit timeline (activity block enhanced)
- Before/after diff for field changes
- Filter by user, entity type, action, date range
- Pagination for large audit histories
- Export as CSV

**Dependencies:** Activity system (exists)
**Confidence:** High

---

#### 35. Product analytics and quality telemetry

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2

**Problem:** The analytics system tracks events but doesn't surface product quality metrics. Products need: content open rates, save rates, feedback rates, extraction accuracy, agent performance, and search effectiveness.

**Solution:** Analytics dashboard in admin:
- Event aggregation: views, saves, feedback, exports per entity type
- Agent performance: extractions completed, accuracy rate, processing time
- Search analytics: top queries, zero-result queries, click-through rate
- Source health: items ingested, duplicates detected, quality distribution
- Configurable dashboards using existing chart blocks

**Definition of Done:**
- Admin analytics page with key metrics
- Metrics computed from existing `analytics_events` + `entity_responses`
- Agent performance dashboard
- Daily/weekly/monthly aggregation
- Configurable date range selection
- Export metrics as CSV

**Dependencies:** Analytics system (exists)
**Confidence:** High

---

#### 36. Configurable onboarding flow for new tenants

**Type:** Platform enhancement
**Impact:** 3 | **Effort:** 3

**Problem:** New tenants see an empty platform with no guidance. Products need an onboarding wizard that guides users through: entity type setup, agent configuration, source connection, first data import.

**Solution:** Use the existing `form-flow` block type to create an onboarding flow:
- Stored as a view with `page_type: "workspace"` and form-flow blocks
- Steps: Welcome → Choose entity types → Configure first agent → Connect sources → Import data
- Each step creates/configures real platform objects
- Checklist tracking (similar to Stripe onboarding)
- Dismissible after completion

**Definition of Done:**
- Onboarding flow renders on first login for new tenants
- Steps create entity types, agents, and nav config
- Progress tracked per user
- Dismissible and revisitable from settings
- Configurable: tenant admin can customize onboarding steps
- Uses existing form-flow block type

**Dependencies:** Form-flow block (exists)
**Confidence:** Medium

---

### Tier 5: Infrastructure and Long-term Platform Bets

These are larger investments that create strategic moat.

---

#### 37. Task-based model routing and token budget controls

**Type:** Platform infrastructure
**Impact:** 5 | **Effort:** 3

**Problem:** All AI tasks use the same model. Products need: cheap models for tagging/classification, better models for synthesis/chat, token budget caps per tenant, and fallback chains.

**Solution:**
- Model routing config per task type: extraction, chat, recap, classification, embedding
- Token budget per tenant with alerts and caps
- Model fallback chains: try expensive → fall back to cheaper on budget/error
- Task-level model override in agent config
- Usage dashboard showing cost breakdown by task type

**Definition of Done:**
- Model routing configurable per task type in tenant settings
- Token budget tracking and caps
- Automatic fallback on rate limits or budget exhaustion
- Cost dashboard in admin showing spend by task type
- Agent config can override default model per agent

**Dependencies:** AI cost tracking (exists)
**Confidence:** Medium

---

#### 38. Provenance and decision log model

**Type:** Platform infrastructure
**Impact:** 5 | **Effort:** 3

**Problem:** When AI generates content (extractions, recaps, routing decisions), users need to understand why. There's no standard provenance model linking outputs to inputs and decisions.

**Solution:**
- `field_meta` already tracks extraction sources and confidence
- Extend to: routing decisions, recap sources, chat answer evidence
- Provenance viewer component showing: source documents, extraction prompts, confidence scores
- "Why was this generated?" button on AI-produced content
- Audit trail from output → decision → input

**Definition of Done:**
- Provenance metadata on all AI-generated content
- "View sources" action on extracted fields
- Decision log for routing (why this agent received this content)
- Recap source attribution (which items contributed)
- Provenance visible in entity detail views
- Config-driven: which entity types show provenance

**Dependencies:** Field meta (exists), Extraction (exists)
**Confidence:** Medium

---

#### 39. Prompt/task template registry

**Type:** Platform infrastructure
**Impact:** 4 | **Effort:** 3

**Problem:** AI prompts are embedded in code. Products need admin-visible prompt templates for: extraction instructions, recap format, routing criteria, chat system prompts, and classification rules.

**Solution:**
- Prompt templates stored in DB: name, category, template text, variables, model preference
- Admin UI for editing prompt templates
- Variable interpolation: `{{entity.title}}`, `{{field.name}}`, `{{context.feedback}}`
- Version history for templates
- A/B testing support (multiple templates, random selection, tracking)

**Definition of Done:**
- Prompt templates table with tenant scoping
- Admin UI for CRUD on templates
- Variable interpolation engine
- Templates used by extraction, recap, and routing systems
- Version history showing changes over time
- Existing extraction instructions migrated to templates

**Dependencies:** None
**Confidence:** Medium

---

#### 40. Tenant config studio (admin authoring surface)

**Type:** Platform infrastructure
**Impact:** 5 | **Effort:** 4

**Problem:** Configuring a tenant product requires direct DB manipulation or scripts. Admins need a visual authoring surface for: entity type schemas, field configs, views, navigation, themes, and agents.

**Solution:** Unified admin "Studio" page with:
- Entity type builder with schema editor + field config
- View composer with block palette and drag-and-drop
- Navigation tree editor (already exists partially)
- Theme customizer with live preview (partially exists)
- Agent config editor
- Import/export for full tenant config (backup/restore/clone)

**Definition of Done:**
- Studio page in admin with tabs for each config area
- Entity type builder: add fields, set types, configure extraction, set display options
- View composer: visual block placement, preview
- Config export as JSON (for backup or tenant cloning)
- Config import to restore or clone tenant setup
- All operations go through existing server actions

**Dependencies:** View editor (exists), theme builder (exists)
**Confidence:** Medium

---

#### 41. Connector test harness and health dashboard

**Type:** Platform infrastructure
**Impact:** 4 | **Effort:** 3

**Problem:** Once source connectors exist, silent failures kill trust. The platform needs: per-connector health checks, failure alerting, retry logic, and an operations dashboard.

**Solution:**
- Source health dashboard: last success, last failure, failure rate, queue depth, items processed
- Health check jobs via Inngest cron
- Automatic retry with exponential backoff
- Failure alerting via notification system
- Operations page in admin showing all connector statuses

**Definition of Done:**
- Health dashboard showing all source providers and their status
- Automatic health checks on configurable schedule
- Retry logic with exponential backoff and max retries
- Failure notifications to admin users
- Historical health data (trend charts)
- All config-driven, no provider-specific code in platform

**Dependencies:** Source provider registry (#21), Notification system (#20)
**Confidence:** Medium

---

#### 42. Email connector (inbound)

**Type:** Platform infrastructure
**Impact:** 4 | **Effort:** 3

**Problem:** Products need to ingest content from email (newsletter subscriptions, alert emails, VDR notifications). The platform has no email ingestion pathway.

**Solution:**
- Inbound email webhook endpoint (works with services like Postmark, SendGrid, Mailgun)
- Email → entity creation pipeline: parse subject, body, attachments, sender
- Email routing rules: which emails go to which entity type
- Attachment extraction and document processing
- Configurable: email-to-entity mapping rules

**Definition of Done:**
- Webhook endpoint for receiving inbound emails
- Email parsed into structured entity (subject → title, body → content, attachments → documents)
- Configurable routing: rules for which entity type to create
- Attachment processing via existing document pipeline
- Works with any email forwarding service

**Dependencies:** Source provider registry (#21)
**Confidence:** Medium

---

#### 43. Enhanced entity detail with configurable tab layout

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 2

**Problem:** Entity detail pages use the workspace view system with tabs, but configuring tabs and their content requires direct view manipulation. Products need easy-to-configure detail page layouts with standard tabs.

**Solution:** Entity type config gets a `detailConfig`:
```ts
interface DetailConfig {
  layout?: "tabs" | "stack" | "sidebar-detail";
  tabs?: Array<{
    id: string;
    label: string;
    icon?: string;
    blocks: BlockConfig[];
  }>;
  stickyHeader?: boolean;
  showBreadcrumbs?: boolean;
  showActions?: boolean;
  heroFields?: string[];  // Fields to show prominently in header
}
```

**Definition of Done:**
- Entity type config `detailConfig` controls detail page layout
- Tabs auto-generated from config without manual view creation
- "Overview" tab auto-generated from schema if no config provided
- Standard tabs: Overview, Documents, Activity, Related, Comments
- Config-driven: add/remove/reorder tabs per entity type
- Auto-create workspace view from entity type config on first access

**Dependencies:** View system (exists)
**Confidence:** High

---

#### 44. Timeline / evidence trail view

**Type:** Platform enhancement
**Impact:** 4 | **Effort:** 3

**Problem:** Products need chronological timeline views showing: when things happened, what changed, what evidence supports a conclusion. Currently the activity block shows changes but not as a connected narrative.

**Solution:** New `timeline` block type:
- Chronological events from multiple sources: entity changes, related entity events, extraction results, feedback, comments
- Grouped by date with expanding detail
- Filter by event type
- Connection to entity: "X happened because of Y"
- Visual timeline with icons per event type

**Definition of Done:**
- `timeline` block type rendering chronological events
- Events sourced from: activity log, entity_responses, comments, related entities
- Date grouping with collapsible sections
- Event type icons and color coding
- Configurable: which event sources to include
- Works on any entity type detail page

**Dependencies:** Activity system (exists)
**Confidence:** Medium

---

#### 45. Better-than-baseline UX polish layer

**Type:** Platform polish
**Impact:** 3 | **Effort:** 2

**Problem:** The platform looks like a competent admin tool but lacks the polish that makes products feel premium — intentional empty states, smooth transitions, contextual microcopy, and subtle motion.

**Solution:** Systematic polish pass:
- Skeleton loading for all data-fetching components (standardize pattern)
- Transition animations on page navigation (CSS only, no JS animation library)
- Contextual microcopy on empty states (not just "No items")
- Hover/focus micro-interactions on interactive elements
- Toast notifications with undo support
- Consistent icon usage (size, weight, color)
- Error states with recovery actions
- Loading states that prevent layout shift

**Definition of Done:**
- Skeleton components for: entity list, entity detail, dashboard, chat
- Page transition animations (fade/slide)
- All empty states have icon + description + CTA
- All error states have retry button
- All interactive elements have visible hover/focus states
- No layout shift during loading
- Consistent icon sizing across all surfaces

**Dependencies:** None
**Confidence:** High

---

## Summary Matrix

| Tier | Items | Impact Range | Effort Range | Category |
|------|-------|-------------|-------------|----------|
| 1: Quick Wins | #1-10 | 3-5 | 1-2 | Bugs, display, config |
| 2: Foundation | #11-20 | 4-5 | 2-3 | Layouts, tracking, actions |
| 3: Capability Unlocks | #21-27 | 4-5 | 2-4 | Pipelines, infrastructure |
| 4: Polish | #28-36 | 3-5 | 2-3 | UX, keyboard, export |
| 5: Infrastructure | #37-45 | 3-5 | 2-4 | AI routing, studio, connectors |

**Total items:** 45
**Quick wins (< 1 day):** 10 items
**Foundation (1-3 days):** 10 items
**Capability unlocks:** 7 items
**Polish:** 9 items
**Infrastructure:** 9 items

**Estimated effort to reach 95% product parity:** Items #1-20 (Tier 1 + Tier 2) cover the core UI and configuration gaps. Items #21-27 cover the content pipeline gaps. Together these 27 items achieve approximately 95% parity through config-driven platform features.

---

## What NOT to Build

These items from the ChatGPT audit are **out of scope** for the platform because they are too product-specific or not generalizable:

| Item | Reason to Skip |
|------|----------------|
| Session-assisted premium source ingestion | Too provider-specific, legal/compliance complexity |
| FinDox local browser bridge | Single-provider integration, not generalizable |
| Email-triggered VDR sync | Too specific to PE/VDR workflow |
| Product-specific workspace templates | Config data, not platform code — seed scripts handle this |
| Company-specific thesis dashboard | Config-driven views solve this — no new primitives needed |

These would be solved by the **tenant config studio (#40)** and seed scripts, not by platform code.