Built in public · Changelog
How Supernova learned the job.
Product panorama
One deal, one continuous operating loop.
Seventeen agents live in the product today, two squads (7 sales-side, 10 delivery-side), propose-only, a named human at every gate. Everything below ships; nothing is a mock.
Sell
Daily Brief, Email Drafter, Call Notes, Deal Check, Meeting Prep, Promise Tracker and Enrich run the deal desk, evidence attached.
Spec
A won deal births the project; Persona Researcher and Spec Writer read the real corpus and draft the use-case tree, every requirement quoting its source.
Model
Data Modeler, Role Definer and Page Architect ratchet ontology, roles and the page atlas forward, one approved artifact feeding the next.
Design
Designer codifies the design language; Mock Builder renders one mock per page wearing the approved tokens.
Run
E2E Writer specs the tests; Tech Stack Advisor and Impact Analyst guard the plan; delivery runs five-state stories, bugs, QA gates and release exit criteria.
Audit
Every run is a session you can open: model calls, tool calls, cost, the audit trail behind every artifact.
12
Jul 2026
Sunday
1 shipped
Performance21:57 ISTPerformance: /ae/meetings was 24.8s → sub-second (query + indexes)
/ae/meetings took 24.8s in application code. Timed the DAL: getMeetingSignals's "unlinked" query was 8.6s — its not exists correlated-joined all 19k zoho_leads per attendee per meeting with…
Performance: /ae/meetings was 24.8s → sub-second (query + indexes)
/ae/meetings took 24.8s in application code. Timed the DAL: getMeetingSignals's "unlinked" query was 8.6s — its not exists correlated-joined all 19k zoho_leads per attendee per meeting with…
/ae/meetings took 24.8s in application code. Timed the DAL: getMeetingSignals's "unlinked" query was 8.6s — its not exists correlated-joined all 19k `zoho_leads` per attendee per meeting with an OR domain-match (split_part(email,'@',2)), non-sargable, re-scanning the whole leads table repeatedly. Rewrote it to materialize the lead-email + lead-domain sets once as hashable CTEs, then check membership: 8,588ms → 240ms (~35×), identical 44 rows. Then the root cause app-wide: no functional indexes existed on the email/mailbox JOIN keys, but "email is the universal join key" and every join uses lower(...), so the PK/FK indexes were unusable — seq scans across recipients (753k), messages (148k), contacts (140k), attendees (44k). Added 7 functional indexes (lower(email) / lower(mailbox_email) / lower(from_email) on graph_events/attendees/messages/recipients + zoho_leads/contacts) via CREATE INDEX CONCURRENTLY + ANALYZE. getMeetings events query: 408ms → 172ms. Net: the meetings page drops from ~9s of DB time to <1s. Indexes are version-controlled in scripts/perf/add-indexes.mjs (idempotent; not via db:push).
Then the app-wide audit (task #19, a subagent that timed every DAL query against the live DB): one genuine outlier remained — `getTasks` (SDR follow-ups) at 2.6s, a per-task left join lateral scanning all 3,298 of the owner's leads filtering on unindexed lower(company). Added a composite functional index zoho_leads (owner, lower(company)) → 2,655ms → 196ms warm (also speeds getLeadTasks + the lead-timeline task block). Added the cheap graph_messages (lower(split_part(from_email,'@',2))) for the rare lead-timeline domain fallback. The audit confirmed everything else (AE, metrics, peek, SLA, attachment DALs) is already FK/PK-indexed and sits at the ~150ms remote-DB network floor — no more indexes needed. 9 perf indexes total, all in scripts/perf/add-indexes.mjs.