Loading…
Everything through v3.x is shipped — see the version history on the Overview. This page is the forward plan.
v1 visitor flow + owner area · v2 machine access (PATs, OAuth 2.0 + PKCE, MCP server, TS compile-on-save, Generate-with-Claude) · v3 self-hosted rrweb replay, version history + rollback, HMAC webhooks, CSV export, ⌘K palette, MCP-parity · v3.x IDE shell, full observability, and collaboration + live co-editing (Collaboration).
The only unbuilt items from the original roadmap are custom CNAME per link and (held) multi-seat orgs.
Two tracks, built in the order below (interleaved by value + how cleanly each lands on the current code). C1 hot-lead alerts, C2 section-heatmap overlay, D1 member roles, and D4 threaded comments have shipped; C1.1/C3/C4/D2/D3/D4 inline remain.
Memo already captures rich engagement (sections, signals, scores, persistent identity). v4 turns that from reporting into action.
| # | Feature | Status | Notes |
|---|---|---|---|
| C1.0 | Hot-lead alerts | Shipped | The derive-cross-visit-signals cron now persists the return / share_detected signals it derives (previously computed and discarded — so they never reached the Activity feed) and emails the project owner (Resend) the moment a new, fresh one fires. Dedup is durable + free: the visit_signals UNIQUE(visit_id, kind) row means a signal alerts exactly once, and a genuinely new qualifying visit re-alerts; a 24h freshness gate stops a first-run/backfill storm. Pure logic (lib/alerts/hot-lead.ts) is unit-tested. |
| C1.1 | deep_read alerts + opt-out + Slack | In progress | Adds deep_read to HOT_LEAD_KINDS (beacon path fires per-visit, not just cron), per-owner notification prefs (alertDeepRead bool, slackWebhookUrl text on the users table), a settings UI toggle, and a Slack transport alongside the existing Resend email. Migration required. |
| C2 | Section-heatmap overlay | Shipped | Renders the per-section engagement (captured via data-memo-section) as a heat overlay on the deck preview (?heatmap=1 on the owner preview route + components/analytics/SectionHeatmap.tsx), with a "View on deck" link from the performance view. |
| C3 | Funnels, cohort retention, deck-vs-deck | In progress | Recharts surfaces comparing decks, drop-off funnels, and return cohorts over the Mongo time-series. First-visit-week groupings as cohort buckets, retention % grid over weekly/monthly cadence. |
| C4 | CRM push | Planned | Webhook/native sync of visit + signal data into a HubSpot/Salesforce deal record. Extends the existing webhook layer. |
Extends the shared-ownership + live-editing foundation just shipped in Collaboration.
| # | Feature | Status | Notes |
|---|---|---|---|
| D1 | Member roles | Shipped | Graded owner / admin / editor / viewer roles on project_members.role (lib/auth/roles.ts: WRITE_ROLES / MANAGE_ROLES / DELETE_ROLES, DEFAULT_INVITE_ROLE = "editor"). requireProjectWriteAccess / requireProjectManageAccess / requireProjectDeleteAccess (lib/api/ownership.ts) gate the publish / notes / upload / version-rollback / rename routes; viewers get read-only. Invite + Collaborators UI choose the role. canWrite is propagated from the session role into EditorShell, FileTree (context-menu + keyboard shortcuts gated), and ChangesPanel (commit / stage / revert hidden for viewers). |
| D2 | Space-level collaboration | Planned | An accessibleSpaceIds companion so collaborators see a shared project's data-room/space visits, not just link visits (closes the scope gap noted in Collaboration). |
| D3 | Live "who's viewing now" | Planned | Extend the Yjs awareness/presence layer beyond the editor — owners see who's in a deck live. |
| D4 | Deck comments & annotations | Shipped (threaded) / In progress (inline) | Threaded comments shipped (CommentsPanel.tsx — client:only="react" island backed by /api/owner/projects/<id>/comments; any member can create / reply / resolve; managers can delete; commit 8356ecc6). Inline deck annotations (click-to-pin element-level markers on the preview, project_annotations table, pins overlay in the preview pane) are in progress. |
C1 hot-lead alertsD1 member rolesC2 heatmap overlayD4 threaded commentsC1.1 deep_read + opt-out + Slack (in flight) → C3 cohort retention (in flight) → D4 inline pins (in flight) → C4 CRM push → D2 space-level collab → D3 live presence. Each lands behind the green-gate (type-check + tests + build + routes) before the next.
deck.acme.com → memo, the one leftover planned item) + per-owner/space white-label theming (the design system already supports runtime tokens — needs an admin UI) + custom owner-area domain.users.plan column exists), multi-seat orgs.