Built in public · Changelog

How Supernova learned the job.

The product story, newest first: what actually became possible in each stretch, not a list of tweaks. Generated live from the engineering journal; the log is the changelog.

improvements shipped

days of building

shipped per day, avg

6 Jul

7 Jul

8 Jul

10 Jul

11 Jul

12 Jul

13 Jul

peak37

14 Jul

15 Jul

Improvements shipped per day; the glowing bar is today.

All · 99 Product · 46 Data · 15 Agents · 14 Design · 12 Fix · 9 Docs · 2 Performance · 1

Product panorama

One deal, one continuous operating loop.

Six agents live in the product today, propose-only, a named human at every gate. Everything below ships; nothing is a mock.

01every desk, daily

Brief

The Daily Brief opens each cockpit: meetings with exact times, deals needing a touch, the one move.

02critic-checked

Draft

The Email Drafter investigates the thread through scoped tools, then a fresh-context critic verifies every claim.

038 dimensions

Qualify

Deal Check scores MEDDPICC with the evidence that earned each score, never vibes.

04pre-call

Prep

Meeting Prep briefs every call: who is in the room, where it stands, what to ask.

05with provenance

Track

The Promise Tracker extracts what each side committed to, source attached, resolved in place.

06propose-only

Audit

Every run costed and receipted: model, tokens, verdict, the audit trail behind every artifact.

Jul 2026

Sunday

1 shipped

Performance

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.