Loading page
Roadmap
This is generated from scripts/feature-backlog-data.mjs, the same file the app reads. Every card here carries its own acceptance criteria; nothing on this page is summarized or reworded from the source.
In progress · 4
Actively being built
Combine synchronized Gmail, inbound forms/messages, Resend activity, and manual communication into one founder inbox with record context and reply tools.
Build prompts from relevant live records, approved templates, business rules, and cited documents rather than uncontrolled database dumps.
Define one typed provider adapter boundary for scoped connection state, incremental reads, external actions, cursors, rate limits, receipts, reconciliation, health, and canonical service mapping before adding another provider.
Plugin Platform phase 0 of 6. INTEGRATION_ADAPTERS at src/lib/revenue-os/integration-adapters.ts:460 documents itself as the registry every provider-scoped write resolves through, so that a new adapter is one entry rather than hardcoded imports scattered across routes. It has zero call sites. src/app/api/admin/tenant/providers/route.ts:12 imports whatsAppAdapter and hubSpotAdapter directly and calls them from an if/else chain at lines 257 and 301, which is exactly the pattern the comment claims to prevent. This is a prerequisite for plugin-supplied adapters, not cleanup: a plugin can only register into that map once the map is what provider operations actually traverse.
Planned · 45
Committed and ready
Temporarily preserve legacy response shapes while sourcing data from canonical services until parity checks and UI conversion pass.
Finish one visual and interaction system for headers, surfaces, tables, filters, pills, dialogs, drawers, commands, and state feedback across every retained route.
Make the managed backlog feel like a professional delivery tool with stable drag ownership, cross-column previews, reliable persistence, accessible movement, and a portal-based responsive detail editor.
Bring Leads, Contacts, Inbox, Bookings, Clients, Chat Inquiries, Subscribers, Content, Resources, Partners, and Website Grades onto the shared responsive shell and connect revenue-bearing records to canonical contacts, companies, opportunities, activities, tasks, attribution, and Today.
Give the founder one place to define audience, sequence, policy, dry run, activation, enrollment, performance, pause, and exceptions.
Support grounded draft, preview, versioning, send, view activity, accept/decline, expiry, and follow-up from the linked opportunity.
Make every core route retain useful context through refreshes and show actionable loading, empty, degraded, and error states.
Replace the vertical-specific inbound capture function with one generic qualification path that takes an industry playbook as data, so roofing becomes one configuration entry instead of an exported code path that every future installation inherits.
Make search and commands navigate records, create tasks/opportunities, compose messages, open setup actions, and invoke safe AI reads.
Expose safe source-scoped Google workspace sync actions in the Integrations admin surface and preserve truthful busy/error behavior.
Normalize Gmail threads and messages while retaining RFC message IDs, references, provider IDs, participants, and reply headers.
Link participants and conversation context to contacts, companies, opportunities, campaigns, and proposals with review for ambiguity.
Allow UI and AI to propose exact event mutations while requiring founder confirmation of calendar, attendees, time, timezone, and action.
Let the founder save a small allowlist of Drive folders and prove synchronization cannot traverse unrelated content.
Fetch supported document text and metadata, hash content, skip unchanged files, and retain folder and provider provenance.
Retrieve only relevant approved document excerpts for research, briefs, audits, and proposal drafts and return source links.
Persist the approved audience, sender, copy, steps, timing, stop conditions, and daily limit as an immutable executable version.
Show the exact eligible recipients, exclusions, reasons, step timing, limit impact, and representative personalized messages before activation.
Claim due campaign steps internally, re-check policy and stop conditions at send time, enforce daily limits, and record terminal receipts.
Stop future steps on reply, hard bounce, complaint, unsubscribe, manual pause, opportunity conversion, meeting booking, or policy invalidation.
Provide one-click public unsubscribe, standards-compliant headers, durable suppression, and operator-visible receipts.
Verify and process delivered, bounced, complained, opened, and clicked events idempotently and connect hard failures to suppression.
Control draft, sent, viewed, accepted, declined, expired, and superseded states with linked contact, company, and opportunity.
Record public views safely and allow accept or decline without login or payment while preventing duplicate outcomes.
Every input the system has arrives from someone else: a form, a mailbox, a calendar. What the founder himself knows, a constraint a client mentioned, why a deal actually stalled, what was decided and rejected, has nowhere to go. That is the difference between a record of what happened to the business and a second brain. Add a plain capture surface: a note, optionally attached to a contact, company, or opportunity, stored with a date and retrievable later.
The system sees only what arrives through its own forms. Gmail and Calendar sync exist in code but Google has never been connected, and there is nowhere for the founder's own notes to enter at all. A brain whose only sensory input is a contact form cannot be a second one. Connect Workspace, land threads and events as canonical activity through the existing resolver, and add a plain capture surface for notes.
The system knows rows, not things. Ask what was agreed with a client last month or why a deal stalled and there is nowhere to look. Add a chunked, embedded, retrievable knowledge store where every chunk carries its source, its date, and its confidence. This is the single largest gap and the one that makes the phrase second brain mean anything.
Every code path runs because a request arrived or a daily cron fired. Nothing notices a deal gone quiet, a promise unkept, three inquiries from one company, or a reliable client who has gone silent. Add a background loop producing a written synthesis: what changed, what it means, what is at risk, what needs the founder. Prose worth reading, not a digest of row counts.
The inbound responder proved the pattern of a versioned founder-signed policy with an envelope, guardrails, a kill switch, and a recorded decision either way. But it is one module written by hand. Generalise it so adding a policy is declaring config and fixtures rather than writing another module and another test suite. Prove it with two more: a stalled-deal nudge and a commitment keeper.
agent_learning records one bit per run, misattributed across every tool that run touched. Nothing links an action to what happened next: did the reply produce a booking, did the proposed task get done, did the stage move stick or get reverted. Without that link the system accumulates history and never improves, and calling it learning is decoration. Add outcome windows, per-tool attribution, and an eval set per policy.
Audit rows exist for everything and there is nowhere that says, in sentences, what the system did today, why, and what it decided not to do. Trust is the real bottleneck on autonomy rather than capability, and nobody widens the scope of a system whose reasoning they cannot inspect. Build the narrative surface on the audit ledger and agent_runs, both of which already record enough.
Acknowledge a first-touch inbound inquiry within seconds, grounded strictly in what the prospect wrote and the canonical record, executing inside a founder-approved response policy version rather than a per-message approval. The engineering contract permits an external action without per-instance confirmation only from inside an approved policy version, so the responder is not a trusted agent: it is a signed policy carrying the trigger, envelope, guardrails, template, and model, and any material edit bumps the version and suspends sending until re-approval, exactly as activateCampaign already behaves.
Give the founder one importer for pasted notes, copied lists, CSV/TSV, and JSON. Deterministic parsing runs first; OpenRouter proposes normalized contacts and company links; the founder edits, includes/excludes, and approves an immutable reviewed snapshot before canonical writes execute with row-level receipts.
Require explicit in-turn approval for individual sends, stage changes, event mutations, proposal sends, and destructive operations.
Capture founder feedback and real action outcomes as reviewable signals that improve future AI guidance without creating self-modifying behavior or ingesting unsafe instructions.
Choose OpenRouter models by typed workload requirements instead of scattered IDs, with current capability and cost metadata, explicit activation, eval gates, and rollback.
Give each AI surface versioned instructions, source rules, review requirements, curated examples, ambiguity handling, kill switches, and measurable quality outcomes.
Turn canonical changes into a concise, evidence-backed operating brief that tells the founder what changed, what is likely to matter next, why, and the safest next action before a deadline, revenue risk, or system failure becomes urgent.
Summarize sync freshness, job receipts, queue backlog, delivery failures, webhook failures, connection degradation, and alert deliverability.
Notify the founder when syncs, jobs, delivery, webhooks, tokens, or queue freshness breach defined thresholds and link to recovery steps.
Unit-test identity resolution, pipeline rules, task dedupe, priority selection, campaign eligibility/stops, AI impact tiers, and canonical metrics.
Prove a real inbound form creates one canonical identity and opportunity, preserves attribution, appears in Today/Pipeline, and progresses through validated stages.
Exercise Today, Pipeline, Conversations, Campaigns, Proposals, Analytics, Setup Center, Settings, and Feature Board on the deployed founder account.
Turn the production-derived private repository into a credible open-source project with a reproducible newcomer path, explicit licensing and asset boundaries, public-safe operations, automated security hygiene, and a reviewed GitHub community surface.
Split the always-on core (contacts, companies, auth, tenancy, permissions, activity, AI context) from optional modules (proposals, campaigns, bookings, analytics) behind a declared contract, so a self-hoster or template author can enable or omit a capability without forking core logic. This is the prerequisite for business templates and a template directory; do not start those before this contract exists, or every template reinvents its own ad-hoc module boundary.
Blocked · 6
Waiting on a dependency
Unify Gmail personal replies and Resend campaign/transactional sends behind validated services that record provider IDs and terminal results.
Give the founder one discoverable workspace to view, edit, preview, test, publish, restore, compose from, and audit transactional and sequence email without another provider account.
Configure the founder-only Google connection with the minimum Gmail, Calendar, and selected-Drive scopes, then produce successful source receipts.
Persist Gmail history cursors, process oldest unseen work first, report deferred backlog, and safely recover expired cursors.
Import upcoming and recent Google Calendar events idempotently and link attendees to contacts and opportunities.
Reframe Accelerate as the operator that absorbs routine work so teams can do the work only they can do, then rebuild the public homepage and supporting marketing surfaces so they are visually led, short, and free of dollar-ROI theater.
Backlog · 92
Captured, not yet committed
Give every integration, AI rule, notification preference, template, pipeline option, and audit view one authoritative admin surface.
Verify every critical founder workflow without a mouse and at mobile breakpoints, including dialogs, drawers, tables, Kanban, command palette, and toasts.
Document and automate the instance-per-client installation so a new business can be stood up from an empty Supabase project to a green Setup Center without copying any Accelerate data, and prove it with a repeatable smoke test.
Detect revoked credentials, missing scopes, refresh failures, and account changes, and guide the founder through safe reconnection.
Use push notifications when configured, renew watches before expiry, and retain protected scheduled incremental sync as fallback.
Let the founder reply in-thread, link/create records, set next action, create a task, archive locally, and enroll permitted follow-up from one conversation.
Use bounded thread and revenue context to draft replies, classify intent, summarize history, and propose follow-up without taking external action automatically.
Assemble company research, qualification, pipeline history, conversation, proposal state, documents, and stated objectives into an actionable meeting brief.
Prompt after meetings for notes, then extract commitments, tasks, follow-ups, stage suggestions, and proposal inputs for founder review.
Enroll canonical contacts once with auditable eligibility and generate only approved, fact-grounded personalization fields.
Report enrollment, sends, delivery, replies, stops, meetings, proposals, wins, failures, backlog, and recovery actions by approved version.
Preview and confirm the exact recipient, version, public link, subject, and body before sending, then connect the provider receipt.
Generate matching PDFs, expire old versions predictably, and create deduplicated founder follow-up when proposal state changes or stalls.
Extend tenant-owned OpenRouter BYOK with a founder-controlled sponsorship mode for exceptional workspaces, without turning the platform key into an implicit global fallback.
Research a company from approved sources, separate evidence from inference, and identify likely operational revenue leaks relevant to outreach or calls.
Explain which opportunities deserve attention using the deterministic priority policy plus bounded qualitative evidence.
Generate editable outreach and reply drafts from approved facts, templates, campaign policy, and conversation context.
Turn notes and permitted conversation context into summaries, commitments, follow-ups, risks, and stage suggestions for founder review.
Create structured audit and proposal drafts from notes, company research, selected documents, approved offers, and pricing inputs.
Let the founder ask grounded questions about live metrics, failures, setup documentation, and recommended recovery actions.
Give each provider and subsystem a bounded test that proves the intended capability and changes status on failure and recovery.
Apply provider signatures, OAuth state, replay IDs, cron secrets, strict payload validation, and bounded rate limits to every external entry point.
Ensure urgency, channel, quiet hours, and disabled preferences govern real notification creation and delivery rather than settings display only.
Exercise authentication, founder authorization, payload validation, idempotency, transition rejection, provider failure, and truthful errors for every material API.
Prove conversation association and reply controls plus campaign dry-run, activation, due execution, pause, and stop behavior.
Verify proposal send/view/accept/decline and demonstrate that provider failure and recovery change Setup Center truthfully.
Automate critical accessibility assertions and preserve desktop/mobile screenshots for the founder workflow surfaces.
Require typecheck, lint, unit/API/browser tests, build, migration dry run, deployment, and authenticated production smoke evidence in a deliberate release workflow.
Monitor campaign and Workspace jobs, provider receipts, retries, queue freshness, alert delivery, and audit history before increasing automation volume.
Make public booking, Calendly attribution, tenant configuration, Setup Center, and admin guidance agree on one optional activation model with truthful behavioral health and a complete manual fallback.
Give the founder one complete commitments workspace for open, overdue, snoozed, completed, and record-linked tasks while keeping tasks.ts as the only writer and repairing every existing Tasks destination.
Turn ambiguous and unmatched Gmail, Calendar, import, form, and compatibility identities into a bounded founder review queue with evidence-backed link, create, no-match, and defer decisions.
Turn missing attribution, missing owners or next actions, orphan links, impossible stage history, duplicate candidates, and failed reconciliation into exact inspectable records with safe service-owned repair paths.
Make funnel progression, furthest stage reached, time in stage, regressions, stale movement, and forecast inputs derive from canonical stage_events while current-stage reporting remains explicitly current state.
Give the founder one evidence graph from a health alert or failed action to its job, source, webhook, message, action, audit, and provider receipts, with only bounded and explicitly safe recovery operations.
Let the founder set versioned period goals for recorded revenue, qualified inquiries, response time, meetings, proposals, wins, and delivery commitments, then compare them with canonical actuals and named data gaps.
Add base, upside, and downside planning scenarios whose versioned assumptions operate on canonical open-pipeline facts while remaining visibly separate from recorded forecast and won revenue.
Turn one canonically won opportunity into one inspectable client engagement with onboarding milestones, commitments, source context, and a receipted handoff without creating a second identity or sales pipeline.
Extend the command center beyond the sale with one canonical workspace for onboarding progress, delivery commitments, client communication, risks, outcomes, renewal timing, expansion evidence, and referral follow-up.
Support carefully bounded multi-record task, ownership, stage, suppression, and campaign operations through exact previews, version-bound confirmation, per-record claims, receipts, partial failure, and safe retry.
Replace bespoke autonomous modules with one versioned registry for bounded triggers, envelopes, eligibility, stop rules, templates, models, eval fixtures, approvals, kill switches, decisions, and execution receipts.
Give each instance a bounded secret-free export and a scratch-instance restore proof covering canonical records, immutable provenance, approved configuration, templates, and schema version without copying Accelerate or another client's data.
Map Outlook mail, Outlook Calendar, and selected OneDrive or SharePoint content through Microsoft Graph into the same canonical communication, scheduling, identity, knowledge, run, and receipt services used by Google.
Link Stripe customers, invoices, subscriptions, payments, refunds, and disputes to canonical companies and opportunities so recorded payment truth can reconcile with pipeline and delivery without making Stripe the CRM.
Deliver selected briefs, operational alerts, and expiring approval links to founder-approved Slack destinations while keeping the Command Center as the durable notification, decision, and action ledger.
Index only founder-approved Notion pages and databases into the shared knowledge substrate with provider provenance, edit and permission propagation, citations, recency, and explicit deletion or inaccessible states.
Extend Setup Center into a guided first-run flow so a freshly deployed, unconfigured instance walks its new owner through connecting Supabase, applying migrations, and creating the first founder admin account from inside the running app. A one-click deploy that lands on an empty or crashing Setup Center is not actually one click; the remaining friction is exactly the CLI/psql migration step this card removes.
Package pre-configured tenant-config seams (branding placeholders, default pipeline stages, default AI system prompt framing, seeded demo data matching an industry) for 2-3 verticals already represented in this site's own case studies and demo scenarios, so a visitor can deploy something that already looks built for their business rather than a blank instance. Depends on the module contract so a template can declare which modules it enables.
Give a new self-hoster a real path off their existing CRM: a CSV importer (reusing the existing contact-import review/dedupe flow already shipped for manual list imports) and a HubSpot contacts+deals importer via HubSpot's API. Without this, 'self-host and own your data' still requires manually re-entering every contact.
Extract the pattern already used for Google/Gmail/Calendar/OpenRouter connections (src/lib/revenue-os/integrations.ts, integration-registry) into a documented adapter contract a third party can implement for a new provider (Stripe, QuickBooks, Slack, Twilio) without touching core connection/credential storage.
npx create-accelerate as a second on-ramp alongside the Deploy button, for developers who want a local clone pre-wired to a chosen template and modules rather than a hosted instance. Only makes sense once the module contract and templates exist; building this first would just hand-roll the same choices the contract should express declaratively.
A metadata layer letting a workspace define its own objects and fields, with dynamic record rendering, so a business whose shape does not match contacts/companies/opportunities can still run here. This is the single largest gap against a general-purpose CRM: there is currently no custom field anywhere in the schema, so any business needing one has to fork and migrate.
tenant_memberships.role currently permits exactly one value, admin, so every member of a workspace can do everything and the AI can reach everything that member can. A second person in the business, or a client given limited visibility, is not expressible today. This is also the one place a competitor's AI governance is genuinely ahead: theirs scopes agent access per object by role.
Saved views are localStorage only (src/lib/admin/pipelineViews.ts, leadsViews.ts), so they are per-device, unshareable, and lost when a browser is cleared, while being presented as a feature. Move them to tenant-scoped storage, shared or private per user, and extend the same mechanism to record page layout and sidebar arrangement.
Analytics is a fixed set of canonical formulas on one page (src/lib/revenue-os/analytics.ts). A workspace cannot define its own metric, cohort, or dashboard. Build on the existing attribution model, which already surfaces unknown attribution honestly rather than reporting it as zero, so a user-defined metric inherits that truthfulness instead of inventing a cleaner-looking number.
Automation exists but is hardcoded across campaigns.ts, inbound.ts, and auto-responder.ts, so changing when something fires means changing code. A visual designer over the same primitives lets an operator express a rule, while every action it can take stays inside the approval and receipt model rather than becoming a second, looser execution path.
The only external programmatic surfaces today are MCP and write-only tenant ingest keys. There is no way to read records out, or to integrate a tool that does not speak MCP. A documented REST surface over the canonical services, authenticated per tenant and scoped by role, is what makes the open and flexible claim hold for someone who is not using an AI client.
Plugin Platform phase 1 of 6, primitive 1 of 7: Records. There is no entity_links table, no entity_types registry, and no generic merge anywhere in src or migrations. Without a generic link table every pair of capabilities that needs to relate records requires a bespoke join table and its own migration, which is the cost that stops an ecosystem before it starts. A meeting capability needs to link a transcript to a contact to an opportunity to a follow-up task; today that is four schema changes. Entity types become rows rather than an enum so that links, merge and audit work on a newly registered type the day it appears, with no code change.
Plugin Platform phase 1 of 6, primitive 1 of 7: Records. Duplicates are inevitable once ingestion is AI-driven, and most integrations either never clean them up or delete and orphan the dependents. A merge driven by the entity registry's foreign key catalog walks every dependent in one transaction, preserves the loser's identity as an alias on the winner so future inbound matches still resolve, and supersedes live dependent rows rather than deleting them. That combination is what makes merge safe to run repeatedly.
Plugin Platform phase 1 of 6, primitive 3 of 7: Actions. This is a refactor of something real rather than a greenfield build. action_queue already carries the status lifecycle, a pending dedupe index and expiry, and the AI tool registry already asserts at runtime that a mutating tool staged a proposal. What is missing is the reversibility axis, which is orthogonal to the existing impact tiers: impact says how far an effect reaches, reversibility says whether core can restore the prior state. Add the class, add compensators, add an evidence column, and make one executor the only write path so that a user clicking Save and a plugin proposing a change traverse identical code. That single property is what makes the approval queue real rather than cosmetic and the audit log complete rather than best-effort.
Plugin Platform phase 1 of 6. resolveOrCreateIdentity exists in src/lib/revenue-os/identity.ts and resolves one record at a time. Every capability that extracts people from unstructured input has the same failure mode: silent duplicate creation from name variants and transcription drift. Resolve identity for a whole batch first, once, and classify each candidate as matched, ambiguous, near miss, or new. Ambiguous and near miss are queued for a human and never silently created. This becomes mandatory middleware on any write that could create a person or a company rather than a helper a caller may forget.
Plugin Platform phase 1 of 6, primitive 4 of 7: Events. Nothing in the tree provides typed business events, durable delivery, replay, or delivery deduplication. Without them, capabilities can only be wired by direct calls, which creates a dependency graph nobody can upgrade and is the failure mode this platform exists to avoid. Events are also the only sanctioned way capabilities communicate with each other.
Plugin Platform phase 1 of 6. Reads must go through a single capability-checked interface and writes must go through the executor, because that is what makes row-level security, cost accounting and audit complete rather than best-effort. The pattern is already proven in this repository: bindTenantDatabase is a proxy that forces tenant filtering because the service role bypasses row-level security. Generalize it into a data API with three shapes, a filtered entity query, a server-computed recipe, and a capability's own namespaced storage, and deliberately provide no direct write to core entities.
Plugin Platform phase 1 of 6. The repository is further ahead here than the specification assumes: grounded answer validation already rejects an answer that does not cite receipts from tools that actually executed in that run, and execution re-reads record state and expires a proposal if reality moved. What is missing is applying the same discipline to writes. A commitment extracted from a transcript, or a stage advanced on inferred intent, is exactly where a hallucination causes damage. Evidence requirements belong in the validator, because a prompt instruction is a suggestion to a model while a validator is a guarantee.
Plugin Platform phase 2 of 6. There is no sandbox of any kind in the tree today: no isolated-vm, no worker, no node:vm. The current seam avoids the problem by executing nothing from extensions, which is a correct invariant for a manifest but caps the platform at declarative capabilities forever. An isolate moves the boundary: plugin code runs with no database handle, no filesystem, no environment, and a default-deny egress allowlist, receiving only host bindings pre-scoped to what its manifest declared. Cold start under 50ms is a requirement rather than a goal, because event handlers fire constantly and a slow cold start makes the whole product feel dead.
Plugin Platform phase 2 of 6. A hand-maintained manifest goes stale the moment someone edits a schema, which is exactly what happened to setupChecks in the current module contract, where all four declared ids drifted away from the real checks. The proven answer is to generate the description from the live validators so it cannot drift, the same principle behind a generated schema description that can never disagree with reality. For Tier 2 and above the manifest is derived from source; for Tier 0 and 1 it stays hand-written because there is no source to derive from.
Plugin Platform phase 2 of 6, primitive 7 of 7: Connections. integration_connections already stores per-tenant credentials with AAD-bound envelope encryption, which is the hard half. What is missing is the broker shape: a plugin calls a fetch against a named connection and the broker attaches the token, so a compromised or malicious plugin cannot exfiltrate a refresh token because it never holds one. This is the single property that makes third-party plugins safe to connect to a customer's Google or payment account.
Plugin Platform phase 2 of 6. Today enabling a module flips one boolean and nothing else happens. A real lifecycle needs the plugin data model, a review screen generated from the manifest so an operator sees the blast radius before granting it, and an uninstall contract that leaves nothing behind. WordPress's debris problem is what makes long-lived installs unmaintainable, so the uninstall rules are non-negotiable rather than best-effort.
Plugin Platform phase 2 of 6. A plugin that calls a paid external service needs a per-install budget, and hitting the cap must disable that capability and notify rather than fail silently in the middle of a batch. Nothing meters plugin cost today because there are no plugins, but the shape should match the existing per-tenant AI budget work rather than inventing a second accounting system.
Plugin Platform phase 3 of 6. Trust is held per install and per action, never per plugin and never globally, because the unit a human can reason about is one narrow capability. Four levels: always propose; auto-execute with notification and a 24-hour undo; auto-execute within a declared budget, dropping to always-propose when the budget is exceeded; and autonomous with digest reporting only. The hard invariant is that an irreversible action never auto-executes at any level, for any publisher, with no configuration flag, and the validator rewrites any manifest that attempts otherwise.
Plugin Platform phase 3 of 6. This is the loop that makes the product feel like it is learning without ever making the operator feel it is escaping. Promotion is proposed by the system and approved by a human, never taken. Demotion is automatic, immediate and unilateral. The asymmetry is the point: earning trust requires a human decision, losing it does not.
Plugin Platform phase 3 of 6. An undo offer is only honest if the compensator has actually been executed against real state. A compensator that merely exists is a promise; one verified by executing and then undoing against seeded data is a guarantee. Undo is what makes the second trust level acceptable at all, so it is a precondition for graduation rather than a convenience.
Plugin Platform phase 3 of 6. An approval queue that requires navigating to a dedicated page is an approval queue people stop using. Approve from the digest, from chat, and from a dashboard card. Batch related proposals with per-item expansion. Treat edit-then-approve as first class, and record what the human changed as structured feedback rather than discarding it, because that edit is the highest-signal training data the system will ever get and it also feeds the graduation calculation.
Plugin Platform phase 4 of 6, primitive 5 of 7: Tools. PACK_TOOL_NAMES is a fixed three-entry map, not a bundle activation mechanism, and it currently fails closed in a way that silently hides any tool nobody remembered to add. Replace it with manifest-declared bundles, a small always-loaded core, and an intent lookup that activates the matching bundle for a conversation. The rule that keeps this honest: a tool needing five calls to answer a common question is a missing recipe, and that is enforced in review rather than left to the model to stitch together.
Plugin Platform phase 4 of 6, primitive 2 of 7: Views. Analytics today is a fixed set of canonical formulas on one page, and saved views are localStorage only, so they are lost on a device change while being presented as a feature. A recipe is one server-side computation with a typed output schema that answers a whole question in a single call. The alternative, letting a model assemble an answer from five separate queries at request time, is more expensive, inconsistent, uncacheable, and can silently omit a metric because the model forgot a call.
Plugin Platform phase 4 of 6. This is the single most important number in the platform: if adding a chart takes more than roughly twenty-five lines of JSON and zero build tooling, the ecosystem does not happen. A declarative card is validated against a schema and rendered by core, which means no build step, no bundle, no cross-site scripting surface, and automatic theming. Because core owns the pixels, the admin design token contract and the navigation runtime contract hold for plugin UI for free.
Plugin Platform phase 4 of 6. Declarative cards cover most needs; the remainder need real UI. A sandboxed frame with a message bridge to the same capability-checked data API, and host-provided design tokens so plugin UI matches the product without sharing a stylesheet. Named slots let a plugin place a card, a record tab, a sidebar section, a bulk action, a command palette entry, a settings section, a digest section, or a custom approval card. Slot contention is resolved by the operator's saved layout, never by install order.
Plugin Platform phase 4 of 6, primitive 6 of 7: Skills. A skill is markdown shipped with a plugin describing when a capability applies, what good output looks like, and what never to do. Skills load when their bundle activates. The invariant that makes them safe is that a skill may reference tools but can never grant one: a skill instructing the model to send an email, against a plugin that never declared a send capability, simply has no function to call. That is enforcement by absence applied to instructions.
Plugin Platform phase 5 of 6. A fixed project layout matters more here than in most projects because coding agents rely on it: one file per action exporting its validator, executor and compensator; one file per subscribed event; tools whose validator is the source of truth; recipes; skills as markdown; cards as JSON; forward-only migrations for owned schema; and a required health endpoint above Tier 1. The scaffold encodes the layout so an agent does not have to infer it.
Plugin Platform phase 5 of 6. This card is the reason a plugin written by an agent can be trusted. Every check here is structural: it executes something and asserts an outcome rather than reading a declaration. In particular, a compensator counts as working only when the kit has executed the action and undone it against seed data, and a replay counts as safe only when the kit has delivered the same event twice and asserted one effect.
Plugin Platform phase 5 of 6. The floor test. A complete, installable plugin that adds a pipeline-by-stage chart with no code, no build step, and no permission beyond a single entity read. If this file grows past roughly twenty-five lines, the platform has failed its floor test and that is a release blocker rather than a note.
Plugin Platform phase 5 of 6, and the launch demo. A daily briefing covering open pipeline, overdue invoices, unanswered inquiries bucketed by age, proposals awaiting follow-up, calendar deltas, and anomalies such as channel volume diverging from close rate. Built as one server-side recipe, because five ad-hoc queries stitched at request time drift the moment a data source is added and can silently omit a metric. The demo arc is connect, understand, find problems, propose work, approve, work happens, and the last step is honest only because it traverses the same executor as manual work.
Plugin Platform phase 5 of 6. This is deliberately built third, before any further connectors, because it is the only exemplar that exercises identity resolution, provenance gating, the full trust ladder and the event bus at the same time. If the primitives are wrong, this is where it surfaces, and finding that out here is far cheaper than finding it out after three more connectors assume the primitives are correct.
Plugin Platform phase 5 of 6. The exemplar for third-party data, and the one most likely to be copied badly, which is why it must demonstrate the discipline rather than only the capability. The write policy is the crux: enrichment never overwrites a non-empty field and never touches human-curated fields such as type, stage or owner. That single rule is the difference between enrichment as an asset and enrichment as data corruption.
Plugin Platform phase 5 of 6. Documentation for this platform is written last on purpose, against shipped behavior, because the plugin pages are the ones most likely to overstate. The current module documentation is the cautionary example: three separate files claimed route gating that did not exist. The target that matters is a timed one, not a word count.
Plugin Platform phase 6 of 6. A public directory with installation from the registry or from a git URL. The listing requirement that matters most is that the plain-language capability summary is generated from the manifest rather than written by the publisher, because publisher-authored summaries are exactly where honesty degrades. Trust tier gates behavior rather than only badges: a community plugin installs at always-propose across every action regardless of what its manifest requested.
Plugin Platform phase 6 of 6. This is where the scale actually comes from. Most businesses will install a vertical rather than assembling ten plugins, so a distribution is a signed bundle of plugins plus settings plus seed segments plus a dashboard layout, versioned and installable in one action. The existing five fictional demo workspaces are already the shape of this, which makes them useful evidence rather than only a demo.
Plugin Platform phase 6 of 6. This is the promise the ecosystem is built on, and the reason WordPress plugins from a decade earlier still run. A plugin declares a contract range; core guarantees no breaking change within a major version, announces deprecations one minor ahead with a build-time warning, and maintains a shim for one full major. Without this the ecosystem freezes on an old version, which is the observed failure mode rather than a hypothetical one.
Documentation track, step 1 of 4. Land the whole navigable spine with only three pages of prose, so the system is proven before any content volume is written. The MDX pipeline already exists and is production-proven for the learning hub: createMDX with the gfm, slug and autolink plugins, compileMDX from next-mdx-remote, a filesystem loader, and thirteen components. Three gaps: the loader is a flat directory read with no recursion, there is no persistent sidebar, and there is no docs search. Structure is an explicit manifest rather than a filesystem walk, because a walk can only ever be self-consistent: it can tell you what exists but never catch a page that was supposed to exist.
Documentation track, step 2 of 4, still with only three pages of prose so the wiring is proven before the content exists. Search costs almost nothing: one deploy-time index already serves the whole site and the client filters locally, so adding docs is a loop plus two typed entries, and because those are a keyed record and a typed array, forgetting either breaks the typecheck. Two corrections to earlier assumptions are load-bearing here. src/content/navigation.ts is dead and imported by nothing, so links go in the header and footer components directly. And a static file in public shadows any route handler at the same path, so the machine-readable index must be a build script with a check mode rather than a route.
Documentation track, step 3 of 4, and the reason this track is worth doing properly. RevenueOSModule already declares a docsUrl field at modules.ts:47 that only the generated extension module populates. That field is the seam. Every user guide section declares which modules it documents, every module points back at its section, and CI proves both directions resolve. This is what turns documentation from a marketing artifact into part of the product contract, and it is the single highest-leverage change in the track.
Documentation track, step 4 of 4. With the manifest complete every page is a fill-in-the-blank with a known slug, known neighbors and a known place in the sidebar. Write in link-dependency order so no page ever links forward to something unwritten. Getting started first because it establishes the vocabulary the rest assumes: workspace, module, record, action queue, approval gating, receipt, audit and idempotency, none of which the site explains to a user today.
Shipped · 51
Delivered and verified
Confirm the canonical Revenue OS and Feature Board schemas are present in production and record the verification baseline.
Maintain one durable roadmap with exact ordering, structured details, archival history, and agent-ready handoffs.
Make the deployed schema version and expected columns, constraints, functions, policies, and indexes reproducibly verifiable before shipping.
Prove row-count and field-level parity between legacy capture tables and canonical contacts, companies, opportunities, activities, and attribution.
Create one identity resolver for UI, forms, syncs, webhooks, campaigns, and AI that handles alternate emails and refuses ambiguous matches.
Route every opportunity stage change through one validated service with immutable history, reasons, and terminal-state rules.
Represent form submissions, messages, meetings, notes, proposal events, stage changes, tasks, and AI actions in one chronological activity contract.
Create tasks from humans, meetings, campaign exceptions, proposals, and AI without producing duplicate open commitments.
Create the stable integration contract that lets the Command Center add, replace, degrade, and retire providers without leaking provider-specific assumptions into admin, AI, or domain workflows. Ship a truthful founder-facing catalog for live and planned capabilities before adding another provider.
Rank overdue commitments, unread replies, imminent meetings, proposal follow-up, campaign exceptions, and system warnings with one explainable policy.
Make every admin metric derive from the same canonical contacts, opportunities, stage events, campaigns, meetings, proposals, and won revenue.
Ensure campaigns, approvals, sync jobs, sends, and webhook processing claim work atomically before side effects.
Record the actor, origin, target, before/after summary, and timestamp for every material founder, AI, automation, integration, and public action.
Replace route-local overlays and undefined visual tokens with one portal-based interaction system, intentional page entry motion, a responsive shell, and a persisted collapsible desktop sidebar.
Make Today the founder’s single queue for overdue work, replies, meetings, proposals, campaign exceptions, approvals, and system warnings.
Provide one industry-agnostic opportunity workspace with stage control, qualification, value, next actions, and consistent contact/company context.
Create responsive record details showing identity, qualification, value, timeline, conversations, meetings, proposals, tasks, research, attribution, and next action.
Support repeatable views for new inquiries, no next action, overdue follow-up, upcoming meetings, proposals, at-risk deals, wins, and nurture.
Present source-to-revenue funnel, campaign outcomes, forecast, response rates, meetings, proposals, wins, and data-quality warnings from one metric service.
Preserve the evidence and consequences of the former instance-per-client decision. This historical card was explicitly superseded on 2026-08-30 by shared-database-multi-tenancy-contract and no longer governs new schema or authorization work.
Create one typed configuration module that is the only place the brand, founder identity, offerings, industry playbooks, pipeline labels, AI persona, capability switches, and external project links appear, so a second installation is a config file rather than a search and replace across the codebase.
Supersede the former instance-per-client decision with one application and Supabase database where Accelerate's configured founder remains platform owner, client admins are tenant members, and every operational path carries an explicit tenant context.
Add tenant, membership, ingest-key, and platform-audit tables; give every operational row explicit tenant ownership; and backfill the existing database into the Accelerate tenant without deleting or duplicating records.
Replace founder-only service-role-everywhere access with explicit platform and tenant actors, tenant-bound authenticated database clients, RLS, and tenant-scoped system contexts for every domain read, write, claim, receipt, search, and export.
Give the founder a platform tenant directory and invitation lifecycle, give client admins the complete tenant-scoped operator workspace, and make tenant identity visible and stable across navigation, cache, branding, setup, and recovery.
Resolve public capture, OAuth, provider credentials, sends, syncs, webhooks, cron, health, tokens, and idempotency through the owning tenant so no external effect or provider fact crosses a workspace.
Run the complete database, API, browser, public, provider, and recovery matrix with controlled tenants, then activate client access only after every cross-tenant attempt fails closed and Accelerate behavior remains intact.
Phases C through F need something to run when nobody is asking. Vercel Hobby gives exactly two cron slots at daily granularity and both are used by revenue-campaigns and google-workspace-sync. This is an architectural ceiling rather than a backlog item, and it blocks continuous cognition entirely. Three options: Vercel Pro, Supabase pg_cron with edge functions, or an external worker.
Replace route-local model clients with one server-only OpenRouter gateway that owns authentication, model selection, structured outputs, timeouts, safe errors, attribution headers, and usage receipts for every Accelerate AI workflow.
Register bounded tools dynamically and classify reads, internal writes, external actions, and destructive actions with explicit schemas and permissions.
Turn the one-shot Revenue Copilot into one founder-only runtime with durable conversations, page context, streamed run events, cancellation, bounded history, and the existing registered-tool and action-queue boundaries.
Persist bounded run metadata, tools, inputs/results summaries, model usage, failures, and affected records for debugging and cost control.
Use the shared command runtime from a dedicated AI workspace, a global command panel, and contextual record launchers with one conversation state and one approval boundary.
Use the same versioned tool definitions for approved MCP clients and future external MCP sources so the Command Center can expand without creating parallel business logic.
Group Core, Email, Google, AI, Campaigns, Proposals, Analytics, optional Booking, and Operations into actionable live capability checks.
Keep provider secrets in environment configuration and encrypt refresh/access credentials server-side with rotation and redacted diagnostics.
Prove that only the configured founder can enter admin routes and APIs and that browser clients cannot use service-role capabilities.
Rewrite the public marketing site around Accelerate's actual offer: understand each business, identify where AI and automation can free time or increase revenue, then advise, build, integrate, execute, train, and improve the custom solution. Keep the Command Center as one integrated solution rather than the company definition, and make the positioning durable for future agents.
Provide a shareable full-screen Command Center sandbox that demonstrates realistic operator workflows with fictional data, coherent session state, and an explicit safety boundary before any account or provider is connected.
Create Accelerate's six-project public Selected Work system, with Northern Trust preserved as an unlisted archive, as a proof layer for the operating, product, software, automation, growth, and emerging-technology experience behind the firm.
Refine the public Work index and six public cases into a more alive, editorial proof layer with project-specific visual worlds, stronger media composition, and restrained motion that remains fast, accessible, and recognizably Accelerate.
Make every public route immediately visible from prerendered HTML, remove hydration-gated route blanks, and give the full public site a coherent, mobile-safe entrance-motion system with especially complete coverage across Selected Work.
Document operating contracts, data ownership, dependencies, setup, failure recovery, testing, and safe change boundaries so another agent can resume without rediscovery.
Render the real admin route tree through one safe live-or-demo runtime so shareable fictional workspaces reuse every production component without weakening founder authorization or reaching protected systems.
Populate the shared full-admin demo with three coherent fictional businesses whose emails, records, workflows, AI context, receipts, metrics, integrations, and guided stories reconcile across every enabled workspace.
Turn the full-admin demo into a five-business sales suite for home services, law firms, professional services, real estate, and nonprofits, with separately authored operating data, intentional default appearances, and a light/dark launcher that helps a visitor choose the right example.
Make public campaign, demo-selection, and marketing routes feel like one Accelerate site by applying the standard header, navigation, footer, chat, route progress, and responsive shell everywhere except authenticated or entered full-admin workspaces.
Make the managed Feature Board safe for lower-context workers by validating dependency direction, delivery-circuit ordering, roll-up ownership, milestone notes, and documentation references before a card can be claimed.
Add a real Deploy to Vercel button and template configuration so a visitor can go from the README to a running, empty, unconfigured instance without cloning the repo or touching a terminal. This is the single highest-leverage change for adoption: every extra manual step between 'I found this on GitHub' and 'I have a working workspace' loses non-technical operators and the agencies serving them.
Plugin Platform phase 0 of 6. Three shipped documents state that a disabled module's routes fail closed: src/lib/revenue-os/modules.ts:12, extensions/README.md:32, and docs/contributing/EXTENDING.md:17. Nothing enforces it. isModuleEnabled has zero callers in src/app and src/middleware.ts, so disabling a module hides its sidebar link while the page still renders on direct navigation and its API routes still answer. Close the gap at two points and describe each one accurately.
Plugin Platform phase 0 of 6. Four defects let broken module wiring pass CI today. setupChecks is read by nothing and all four declared ids at modules.ts:152 and :194 are drifted, resolving to no real Setup Center check. availabilityFor marks any tool outside PACK_TOOL_NAMES unavailable while ai-agent.ts always passes a pack, so a registered tool can pass every gate and be permanently unreachable. isNavLinkEnabled and isAiToolModuleEnabled both fail open on an unknown id, so deleting a manifest without deleting its code pins that code on forever. And verify-module-contract.mjs parses TypeScript with regular expressions, which is how a gate script eventually starts lying about what it checked.
Extend this manifest to propose new work; don't start a second roadmap in a fork. See Open Source for how to contribute.