Build checklist

Every feature, big and small, with its verified/unverified build status. Checkboxes drift — verify claims against code.

Exposes build status

This is the internal feature-by-feature build tracker. It reveals what's shipped, what's only code-complete, and where the known gaps are. Items are checked only when the code is written, verified (lint + build + manual run), and pushed — but checkboxes drift, so verify against code before relying on them.

Derived from BRD. Every feature, big and small. Items get checked ([x]) only when the code is written, verified (lint + build + manual run), and pushed. Partial work stays unchecked with a note.

Legend: (M#) = BRD MVP feature · (v1.x) = BRD roadmap phase

0. Foundation

1. Shared core — `packages/core`

2. Web app shell (v1.1 surface, built first)

3. Data layer (BRD §7.4 — boring storage)

4. Capture — web quick-add (v1.1, M1-equivalent for web)

5. Events / auto-grouping (M2)

6. Notes & entity extraction (M3, M4)

Voice STT + phonetic teaching (2026-07-24) — built, pending real verification

STT is a pluggable engine gateway — the AsrEngine contract lives in @dhaga/core/src/voice/asr/types; an engineer adds a future model by implementing it and wiring a useDictation branch. Only Dhaga Voice (Moonshine) ships now — the browser SpeechRecognition engine, on-device Whisper, real-time Whisper, and the Settings engine-picker (VoiceInputSetting / the SttEngine preference) were all removed. The gateway remains the single extension point for a future engine.
"Dhaga Voice" (Moonshine tiny) engine, web — the only web STT engine; on-device WebGPU streaming. WebGPU is required and there is no fallback (no browser / CPU / WASM degrade), so voice notes do not work on iOS Safari or most mobile browsers — a real limitation of the product, not just of a deployment. No longer the whole story (2026-08-26): a second, server-side engine now takes precedence where the deployment has speech-to-text configured, and it runs in any browser — everything from here to the end of this entry describes what happens only when it does not. The on-device engine is gated behind a confirmed WebGPU adapter (resolveDictationState, components/app/contact/dictation-gate.ts): while the probe is still running the Voice button is not-ready and its start is inert, and once the probe comes back false the mic renders greyed out up front with a "Coming soon" reason (DICTATION_NO_WEBGPU_COMING_SOON through ComingSoonNotice, on the note composer, quick-add paste capture and the search palette alike) — it used to look live and explain itself in a warning toast only after a tap, which the beta product rule forbids. So a mistimed tap can never race the model loader into onnxruntime's "no available backend", and no "Downloading model…" progress ever shows on an unsupported device (loadTiny also throws fast when WebGPU is absent). @huggingface/transformers dynamic-import-only. COOP/COEP were scoped to /app/** for threaded WASM and removed 2026-08-25: they made Razorpay's checkout iframe unframable on every soft navigation into Settings, and WebGPU — which the engine hard-requires — needs no cross-origin isolation, so only the rare same-device WASM fallback loses threading. (typecheck + prod build pass; pending real-browser mic/WebGPU verification)
Dhaga Voice Phase-2 UX — the transcript streams live into the capture textarea as you speak (was: appeared only on Stop); the tap-to-fix word-chip review sits directly under the textarea, bounded to the last dictated segment (was: at the bottom of the modal); a silence gate stops the model transcribing dead air (fixes a garbled-transcription / hallucination bug); bounded memory supports long (~15-min) recordings; the microphone lifecycle was hardened — always tears down, rebuilds, resumes, and verifies (fixes a stale-mic-feeding-silence bug). (pending real-browser mic/WebGPU verification)
Phonetic teaching (double-metaphone) — shared pure-TS core (@dhaga/core/src/voice/teaching), deep-import-only, Hermes-safe (never the core barrel); web dictation applies taught spellings on finalize; teaching/vocabulary manager in Settings (Settings restructured into tabs — Account/Capture/Calendar/Suggestions/Import). (pending real testing)
Mobile phonetic teaching (parity) — shared core wired into expo-speech-recognition dictation (correct() on the transcript, interim + final) + a vocab screen; JSON-file VocabStore. (pending device build)
voice_vocab table (synthetic id PK, mirrors settings; EE TENANT_TABLES adds RLS) + /api/voice/vocab (GET/POST/DELETE) + "use server" actions + export coverage; core path unaffected (no apps/web→@dhaga/ee import). LLM self-correction stays PARKED (§20 backlog — needs a GPU).
Search dictation append-vs-replace bug fixed (multi-segment finals accumulate).
Real-browser + device verification (mic capture, WebGPU streaming accuracy, teaching round-trip) and commit (currently uncommitted on main).

7. Knowledge graph v0 (M5)

Relationship edges written from extraction (works_at, knows, used_to_work_at, …)
Jobs & education written from extraction — an affiliation to a company (works_at, studied_at, interned_at, …) becomes a positions row carrying the note as its receipt, not a literal edge (the graph re-derives the affiliation edge from the row), and the contact's title/company denorm is recomputed. Strictly additive: an existing position for that employer — the user's or an earlier note's — is never rewritten or displaced, and a note's own rows are cleared on reprocess/delete by source_note_id alone. Built 2026-07-29 (web); mobile parity pending
Contact page: same-company + same-event + edge connections render
Graph browser page (React Flow: people/companies, typed edges, ring layout)
Directional graph edges + full affiliation history — past employers now render as their own solid "worked at" edges (every positions role ships from the graph payload, not just the denormalised current company) and education as "studied at"; edges are drawn directed, and hovering a node emphasises its outgoing edges (full amber, thickest, arrowhead — the subject side) over incoming ones (softer, thinner) so relationship direction reads at a glance. Built 2026-07-28 (web graph)
Edit an existing relationship — every relationship row on a person/entity page carries a pencil that reopens the same target picker + predicate picker + live direction preview, so a wrong endpoint, a mislabelled type or a backwards edge is corrected in one dialog instead of delete-and-re-add. The edit rewrites the existing edges row in place, so the edge keeps its id and its source_note_id receipt; the action revalidates the endpoints the edge LEFT as well as the ones it joins, and an edge deleted elsewhere reports "no longer exists" rather than a phantom save. Only the node whose page you're on is fixed. Same pass made the target typeahead's state legible (Searching… / Couldn't search + Retry / No matches, plus one automatic retry) after a silently-failed search read as "search is broken". Built 2026-08-06 (web); mobile parity pending
Tag ontology v0 (tags from extraction, filter chips on People)
Tags are first-class entities, with their own surface (2026-08-12) — a tag used to be a bare string in the contacts.tags jsonb array, so it could carry nothing but its own spelling, and there was no read path for contact_tag_sources at all. Now tags (id, name), contact_tags (composite PK, cascade both ways) and tag_aliases are the source of truth, contact_tag_sources gained a tag_id FK, and contacts.tags survives only as a derived cache with exactly ONE writer — refreshContactTagsCache (lib/repo/contacts/tags/cache.ts), the same denormalisation contract contacts.title/company_id already have over positions. Every previous jsonb writer (extraction, addTagToContacts, tagCluster, contact merge, dropTagFromContacts, pruneUnvouchedTags, moveTagSourcesToContact) now writes normalized and recomputes; a grep for a second writer of the column returns only cache.ts. The migration is EXPAND-ONLY — nothing dropped, contacts.tags and contact_tag_sources.tag both still exist, and the text column is written in lockstep with tag_id. Surface: /app/tags (server-paginated, one grouped aggregate for tag + people count, cross-page selection, bulk delete, merge) mirroring /app/companies; tag chips on a person link to /app/people?tags=… with an active-filter affordance and a clear; per-tag Also known as editor plus a global /app/tags/aliases. Merge folds the losing names in as aliases of the survivor, and findOrCreateTagIds resolves name → alias → create — that is the anti-treadmill point: without it the next extraction re-mints the tag the user just merged away and they merge the same pair forever (regression-tested through the real applyExtraction path, not a direct resolver call, so a writer that bypasses the resolver fails the test). Receipts survive a merge re-pointed rather than deleted, source_note_id intact, hand-pinned (NULL) rows included. The RLS wipe hazard and its guard: every new table is under RLS and the boot DDL connection sets no app.current_user_id, so the DDL-time backfill legitimately sees zero rows on a hosted install — leaving contacts.tags full and the normalized tables empty, where the first cache refresh would write [] and unrecoverably destroy that tenant's tags. ensureTenantTagsBackfilled(tx) re-runs the same shipped SQL constant inside the tenant's own scope, and the cache writer fails closed structurally: it demands a TagsBackfilled receipt whose class value is never exported, so a refresh that skips the backfill does not compile, with a runtime instanceof + same-transaction check behind it. The probe matches only "jsonb non-empty AND zero membership rows", so a user who genuinely removed their last tag is never mistaken for an un-backfilled tenant. EE adds tags/contact_tags/tag_aliases to TENANT_TABLES with RLS specs; all three are in the JSON export. Tests: lib/__tests__/tags-normalization/{backfill,merge,aliases,lifecycle}.test.ts — including the wipe regression proved to go red with the guard defeated, tenant-scoped backfill idempotency, and a cache-drift assertion run after every mutation. User guide: content/docs/guide/tags.mdx. (web only — mobile parity pending; typechecked, lint-clean and unit-tested, but not yet browser-verified)
Confirmations centre — unified "AI proposes, code disposes" inbox (/app/confirmations + navigation badge; the former Home tile was retired in the lifecycle rebuild). The nav row is hidden entirely when the inbox is empty (2026-08-14) — an empty inbox is not a destination, and the row was unconditional, so every user carried a permanent link to a page with nothing on it. countPendingConfirmations() was already resolved once per /app render and threaded to the nav for the badge, so the visibility rule (AppNav/link-state.ts, isNavLinkVisible) costs no extra query — deliberately not folded into getCachedAppConfig, whose per-user cache has no TTL and is busted only by settings mutations, which would leave a stale row and badge behind after the last confirmation was resolved generalizing edge-suggestions into typed confirmations (entity_link / subject_resolution "who is he?" / enrichment_match / supplement); ambiguous extraction defers to a confirmation, deterministic resolver applies on confirm; opt-in email digest on the daily cron A note that turns out to be about nobody (2026-08-10): a note_subject card whose note already carries reminders offers two more answers beside the person ones — Not about a person (the general tasks stay exactly as they are) and It’s about a company (they are re-pointed onto follow_ups.company_id). Neither writes a note, and the card says so in one line rather than letting the user assume otherwise: facts.contact_id/embeddings.contact_id are NOT NULL and a note hangs off a contact — never a company — so the honest outcome is that the reminders survive and get labelled while the note body is not persisted. Answering with a person re-points those pre-written tasks onto the contact with the note's receipt (attachTasksToContact), and dedupeNoteTasks then collapses each action back to ONE open row, oldest-first, because the extraction that runs on the newly attached note re-derives the very follow-ups the user already has — that is where the duplicate came from. Re-pointing rather than deleting-and-re-extracting is deliberate (the same reasoning as moveNoteToContact): it keeps an edit the user already made, the row id and its calendar entry, and it cannot lose the reminder on a self-host with no LLM, where re-extraction writes nothing at all. Dismiss soft-dismisses those tasks too (deleteTask, never a hard delete) and the button says so — dismissing used to leave an open task about nobody, from a note the user had just thrown away. And the connected calendar follows the answer (2026-08-20): those reminders reach Google/Outlook the moment the message lands, so the card is answered against an event that already exists. Dismissing schedules write-out for the dismissed ids — a non-open follow-up maps to NO event, which is how write-out deletes what it wrote, and nothing scheduled it, so the card left a phantom event the user could not delete from inside Dhaga. It's about a company schedules it too: attachTasksToCompany writes no note and no source_note_id, so the note-based re-sync can never fire for it and the event kept its pre-answer title. The ids come from the pending payload, read inside the same mutation scope BEFORE the row stops being pending (lib/actions/confirmations/general-tasks.ts); the person answer needs nothing new, because attachTasksToContact gives the SAME rows the note's receipt and openFollowUpIdsForNote then hands those same ids to a write-out keyed on calendar_event_links.follow_up_id — an edit of the existing event, never a second one. Covered by lib/__tests__/confirmations-note-subject-calendar.test.ts. Both extra answers are hidden when the note carries no reminders: with nothing to keep, the only honest answers are a person or Dismiss. Covered by lib/__tests__/confirmations-note-subject-tasks.test.ts. The Links card can no longer dead-end (2026-08-12): its create affordance was gated on the user owning at least one node type — entities.type_id is NOT NULL and nothing seeds a type — so a user who had never opened the type manager saw a search box over an empty set and Dismiss, with no way to create the thing the question was asking about. With an empty ontology the type picker becomes a name field, prefilled from the extractor's own entityTypeHint, and one answer mints the node type and the entity together (components/app/confirmations/EntityLinkCard/NewObjectTargets.tsx). The same card also lets the user correct the object's KIND: a non-person mention is searched across entities and companies, and + New company resolves it through findOrCreateCompany — alias-aware, so a merged-away name links the surviving company instead of forking the duplicate createCompany would mint. The target union (EdgeSuggestionTarget) gained companyId/newCompany, ConfirmationResult's edge dstType is now the endpoint union rather than string, and both resolveTarget and the action's revalidation switch are exhaustive on it, so a future endpoint kind is a compile error rather than a silently stale page. Covered by lib/__tests__/entity-edge-suggestions/{company-target,no-node-types}.test.ts.

8. Natural-language search (M6)

9. AI follow-up drafts (M7)

One-tap draft using notes + event context + facts (Sonnet, cache-friendly prompt)
Draft references ≥1 note-derived fact (acceptance — verify with a live API key)
Edit + copy-to-clipboard flow

10. Metering, cost control (BRD §8.2–8.3)

Every AI call logged to ai_actions (feature, model, tokens in/out) — metered per user-visible ACTION, not per call (2026-07-30): a card scan is one row whose tokens are the sum of its field-extraction and transcription calls, and enrichment folds its web search + extraction pass into one. withAiAction (lib/ai/metering/action-scope.ts) is an AsyncLocalStorage scope that nested AI calls join instead of double-billing; no schema change, and pre-existing rows still count as one action each
Free-tier cap enforced (10 credits/month since 2026-07-31, was 0 — PLAN_AI_CREDITS_PER_MONTH.free, which FREE_TIER_AI_CREDITS_PER_MONTH now derives from so the free tier has one number; an admin re-sizes it at /app/admin/ai-credits like any other plan, and DHAGA_AI_MONTHLY_CAP seeds it for an instance that has set nothing in the DB) with clear UI message. Free is a real taster rather than zero: 10 credits = 10 card scans, or 5 scans + 5 notes, or 5 Ask-Dhaga questions — deep research (20) never fits in a free month, and enrichment + pre-meeting briefs stay feature-gated to paid plans regardless of credits (PLAN_FEATURES). The cap is now denominated in AI credits, priced per action from real measured cost (BRD §8.3, packages/core/src/metering/credits.ts): 1 credit = a card scan, note, quick add or draft; 2 = Ask Dhaga or a brief; 20 = deep research; 0 = a nightly watchlist scan (throttled by the watch limit instead)
User-facing credits page (/app/settings → Credits, 2026-07-31) — the answer to "where did my credits go?", built as a Settings tab rather than its own route because it sits next to Billing in the IA and because the onboarding tour already has a settings leg to hang it on. Three cards: allowance (remaining of total, used-bar, reset date, and — only when something was added — a base / grant / promotion split, so a bigger-than-expected number is explainable rather than mysterious); breakdown by action kind for the current month, whose rows sum to the total by construction (the total is derived from the same per-feature aggregate, and ai-credits-overview.test.ts pins it against aiCreditsUsedThisMonth() — the figure the cap is enforced against); and recent activity, now keyset-paginated (2026-08-01) rather than capped: the first AI_ACTIVITY_LIMIT (20) rows render server-side, and a Load more button pages through the rest of the account's full history via getAiCreditActivityPageAction → listAiCreditActivityPage (lib/repo/ai-usage/activity.ts), a (created_at, id) keyset cursor rather than OFFSET so it stays fast as ai_actions grows without bound (it's append-only and never pruned). Zero-credit watchlist scans are listed and marked Free, never hidden — a month of nightly scanning that vanished from the ledger reads as a bug. Nothing user-facing renders a feature id or a token count (AI_ACTION_LABELS, utils/constants/ai-credits.ts); unlimited plans read "Unlimited" instead of dividing by a zero cap. One aggregate read on the request-scoped connection (lib/repo/ai-usage/overview.ts), no getDb() fan-out. Added to the driver.js walkthrough, and since the tour was rebuilt to start on Settings (§ onboarding walkthrough) it is its second step — a new user meets the price here rather than as a cap message later. Guide: AI credits
AI controls grey out before the click when credits are gone (2026-07-31) — a UX layer over assertAiBudget, never a replacement: aiGateReason (lib/ai/gate.ts, React-cache()-memoized so one request resolves it once instead of every server component fanning out its own getDb()) returns a reason or null, and AiGateNotice renders it beside the disabled control in the calm amber pill — never red, because running out of credits is a plan state, not an error. Greyed: Extract contact, card scan, Ask Dhaga (palette Ask tab + search-tab bridge), Brief me, Draft follow-up, Enrich from public web. Deliberately not greyed: manual capture and CRUD, hand-added facts/follow-ups, typed + photo notes (the note still saves; extraction degrades to the existing "…so facts weren't extracted" notice), note re-process, confirmation cards, extraction-job retry, keyword search, graph, import, export, on-device voice — greying those would break the free/no-AI product commitment. The predicate is zero credits left, not "can I afford this action": assertAiBudget refuses on used >= cap and never prices the action, so a price-aware gate would disable a button the server would happily run. !hasLLM() ⇒ null, leaving the existing "Configure an LLM provider…" degraded messages to own the no-key case. The two controls the client-only app shell mounts (nav quick-add, Ask palette) have no server parent to take a prop, so they read /api/ai/gate lazily (useAiGate). Since 2026-08-14 that route serves a second field alongside the reason — llmConfigured (hasLLM() evaluated server-side, a configuration boolean that never carries key material) — used only to pick the search palette's default tab (Ask when AI is usable, Search otherwise, so ⌘K never opens onto a disabled box) and never to grey a control; aiGateReason itself is unchanged and stays credit-only. 8 tests in lib/__tests__/ai-gate/; manual walkthrough in TESTING.md §7r-ii. Guide: AI credits
Monthly inference-DOLLAR ceiling — the master cost gate (2026-08-03) — a second ceiling, independent of credits, because credits stopped bounding spend the moment three metered features were priced at 0 credits on purpose (signal_detection, person_classification, goal_matching; folding them in at 1 credit each was rejected as ~26× mispriced, so an uncredited nightly sweep costs real money and moves no counter). Dollars are computed, not estimated: utils/constants/model-pricing.ts holds the only copy of provider rates (MODEL_RATES_PER_MTOK, BATCH_PRICE_MULTIPLIER = 0.5) and lib/ai/cost/ turns a recorded ai_actions row into USD — an unknown model is priced at the dearest known rate and a dated snapshot matches by longest known prefix, since under-reporting cost is the dangerous direction. Prompt caching is deliberately not modelled (see the next item — there is no discount to apply). Batch-ness is recorded, not inferred: ai_actions gained batch boolean NOT NULL DEFAULT false (lib/db/ddl/core/meta.ts, self-healing ADD COLUMN IF NOT EXISTS) because goal_matching runs both a nightly Batch pass and a synchronous goal-resolve path, so inferring from the feature would halve a real bill; pre-existing rows read false, over-stating an old batch action by 2× (the safe direction) and ageing out within a month. Precedence (lib/ai/metering/dollar-cap.ts), mirroring the credit ladder rung for rung: per-user ai_monthly_dollar_cap_override (0 is a valid override) → the subscription's monthly revenue × multiplier (default 3.0 since 2026-08-19, raised from 2.0 — the arithmetic is below; revenue, not a list price, and every plan is recurring, so each has a real monthly figure) → the floor ($0.50) for any plan with no recurring revenue, which is the case that breaks a percentage model on day one since 0 × any multiplier = $0 would refuse a free user the ten credits they are owed → no ceiling when no plan is in play (a self-host with no billing) or enforcement is off. No promotion rung, deliberately: a promotion raises what a user may do, not the bill we absorb. The revenue basis changed on 2026-08-19 (§18 carries the prices): the rung reads the SUBSCRIPTION, not the plan. monthlyPlanRevenueUsd({ plan, cadence, currency }) (utils/constants/ai-budget/plan-revenue.ts) resolves tier × cadence × the currency the PROCESSOR charges — never the one a visitor toggled on /pricing — introductory offer prices included, because the rule is now that the ceiling follows what a customer is paying at the moment. cadence: null (an admin comp, a referral grant, a plan whose processor we could not reach) falls back to the standing price via STANDING_MONTHLY_REVENUE_USD (pricing/prices.ts), which is now only that fallback and no longer the general basis: there is no charged price to read, and refusing them a ceiling would be a $0 refusal. PLAN_MONTHLY_REVENUE_USD survives but is narrowed to the representative standing-USD figure the admin per-plan table renders (that screen lists plans, not subscribers, so it has no cadence or currency to resolve against) — it is not what any subscriber's gate computes. An INR subscription is expressed in the dollars the ceiling is denominated in through the pinned INR_PER_USD = 87 + inrToUsd() (pricing/currency.ts): a constant and deliberately not an FX feed, because it sizes a loose backstop where a few percent of drift moves a ceiling by cents and can never change whether a real user is refused, while a live rate would put a network call — and an outage mode — behind every metered AI action. It must never be used to charge anyone. The multiplier moved 2.0 → 3.0 the same day, and the reason matters more than the number (DEFAULT_AI_DOLLAR_CAP_MULTIPLIER, ai-budget/dollar-ceiling.ts): tying the ceiling to the price paid pulls the thinnest CHARGED row down to Pro introductory yearly, ₹167/mo ≈ $1.92. The measured heavy-user month (BRD §8.3) is $2.84 of inference plus ~$0.40 of uncredited watchlist ≈ $3.24 — at 2.0 that is a $3.84 ceiling with that user at ~84% of it, so real paying customers would have started being refused mid-month by a gate they had never met, with nothing on screen explaining why (the pre-click grey-out is credit-only — see the known gap below). At 3.0 the ceiling is $5.76 and the same user sits at 56%: a backstop again. Resulting ceilings on Razorpay, the only live processor — Pro standing monthly ₹499 → $17.21, Pro standing yearly ₹400/mo → $13.79, Pro introductory monthly ₹199 → $6.86, Pro introductory yearly ₹167/mo → $5.76; Power standing monthly ₹899 → $31.00, Power standing yearly ₹750/mo → $25.86 (Power's four rows became two on 2026-08-24, when its standing price was cut to ₹899 / ₹8,999 — exactly what its introductory rows already held — so the standing and introductory pairs collapsed; the superseded standing rows were ₹1,499 → $51.69 and ₹1,200/mo → $41.38); legacy founding_yearly (₹6,999/yr = ₹583/mo) → $20.11; free → the $0.50 floor; no plan in play at all → no ceiling. Two caveats, to be repeated every time this arithmetic is quoted. (1) The ~$0.40/month watchlist figure is BRD §8.3-flagged ESTIMATED, never measured, and it UNDER-reports by ~$0.01 per contact per cycle: search writes a 0-credit signal_detection row carrying the search turn's tokens, but the $10/1k per-search charge has no column on ai_actions. (2) The thinnest row in the whole table is not the ₹167 one — it is USD introductory yearly at $1.67/mo, a $5.01 ceiling, 65% utilised by that same heavy month, and that is only safe because no USD processor is live; re-run this arithmetic before the first USD charge. The danger did not disappear when the invariant flipped, it changed shape: it used to be "an offer price must never reach the ceiling", and it is now "the multiplier must clear the measured heavy month on the CHEAPEST thing we sell" — which has to be re-checked every time a cheaper offer is added or an uncredited feature grows. Instance state reuses ai_budget_settings (dollar_cap_enforcement on by default, dollar_cap_multiplier, dollar_cap_floor — utils/constants/ai-budget/, a DIRECTORY since 2026-08-19: index.ts, allowances.ts, dollar-ceiling.ts, plan-revenue.ts. The import path @/utils/constants/ai-budget is unchanged because index.ts re-exports everything, so any doc still naming utils/constants/ai-budget.ts points at nothing); no new table and no new env var (there is no DHAGA_AI_MONTHLY_DOLLAR_CAP). Enforced inside the existing metering path (assertAiBudget + the hasMonthlyAiBudget pre-flight, lib/ai/metering/index.ts) so it covers every action including the three uncredited ones: credits are checked first, dollars second — the credit message is the one a user can act on (upgrade), the dollar gate is the operator's backstop — and the dollar check sits outside the hasUnlimitedAiCredits early return on purpose, since an unlimited-credit plan (one an admin has uncapped) is exactly the account nothing else bounds. Failure matches the credit cap: AiBudgetError with kind: "dollar_cap" (kinds are now "cap" | "dollar_cap" | "burst"), non-retryable at both sites that branch on kind. Known gap, stated rather than hidden: the pre-click grey-out (aiGateReason, lib/ai/gate.ts) is still credit-only, so an account stopped by the dollar ceiling learns at click time from the error rather than from a greyed control — acceptable because the dollar gate is an operator backstop sized to never touch a normal account, but it is not the same UX the credit cap gets. Tests: lib/__tests__/ai-cost.test.ts, ai-action-metering/dollar-cap.test.ts, ai-action-metering/dollar-gate.test.ts. Admin visibility in §19; rationale and the per-plan table in BRD §8.3
Prompt caching markers on stable system prompts — markers are in place (cachedSystem) but do not engage: measured 2026-07-30, zero cached tokens across 33 calls, because every Dhaga system prompt is far below the model minimum (Haiku 4.5 4,096 / Sonnet 5 1,024 tokens). No cost model should assume the discount (BRD §8.2)
Batch API for nightly jobs — lib/jobs/detect-signals/ (§14) is now a two-phase job through Anthropic's Message Batches API (BatchLLMClient, packages/core/src/llm): each run applies the previous run's finished batch (dedup + signal insert + metering, unchanged) then submits one fresh batch for whatever's newly due, persisting the pending batch id via settings (getPendingSignalBatchId/setPendingSignalBatchId). Vercel Hobby's once-daily cron means a contact's signal now lands with a ~1-day lag instead of immediately — accepted tradeoff for a job that was already nightly and latency-insensitive. Typecheck/lint/tests pass (signal-detection-batch.test.ts); no live-API manual run

11. Privacy & export (M8, BRD §7.5)

12. Mobile app — `apps/mobile` (BRD MVP platform; separate milestone)

13. Browser extension (v1.1)

Built but NOT published (restated 2026-08-09): apps/extension is a working MV3 extension at manifest version 0.0.1 with a packaged .zip, but there is no Chrome Web Store listing and no install link anywhere on the site — the only way to run it is to load it unpacked from the repo. The landing hero lists it as a capture channel marked Coming soon with no install link, matching the mobile app's treatment. Everything ticked below is the extension's behaviour; distribution is the unticked item at the end.

14. Proactive intelligence (v1.2)

15. Graph power (v1.3)

Warm-path finding (BFS over edges/companies/events — no AI cost)
Second-degree suggestions ("Nearby in your network" — ideas.md #1, local-only traversal)
Relationship timeline view (captures, events, notes, touches on the contact page)
Watch app / widgets

16. Ecosystem (v1.4)

Salesforce/HubSpot/Notion export-sync
Outbound webhooks (contact.created, followup.created → DHAGA_WEBHOOK_URL)
Telegram bot: capture + ?questions from chat (ideas.md #6; owner-only, secret-verified)
WhatsApp + Telegram inbound capture (fulfils the WhatsApp-capture item; core — lives in apps/web + packages/core, needs no packages/ee): forward a contact card, raw text, or a photo — one message or many — to the bot; items accumulate in a per-sender session until you reply DONE (or it goes idle), then the whole batch is planned in ONE LLM call that reads every message together and returns who the batch is about and which messages to store on each of them; deterministic code applies that plan, stamps a per-message verdict, and replies a per-person summary ("Created Priya Raman and added 1 note to them"). This replaced a positional walk that read each message alone with a carried "current contact" cursor: no call ever saw two messages at once, so a batch of "Priya Raman is the founder of…" + "Create a new contact" filed the first as an ambiguity (setting no cursor) and turned the second into a contact named "Unnamed contact", while the real note sat unreachable in a confirmation the inbox was coded never to render. Planning the batch as a whole removes that class of failure entirely. Every inbound case is answered, never silently dropped: contact cards go through the structured vCard importer (no AI re-parse); photos take the vision path (card scan → contact, non-card photo → transcribePhotoNote read as a note, caption kept as a note; magic-byte sniffing so Telegram's mime-less photos scan; the photo itself is kept as the visual receipt via saveCardImages, hung off the note so deleting the note hard-deletes the image, behind the same per-user shouldStoreCardPhotos switch as a web card scan — a forwarded photo used to leave only its transcription behind, with no way to check the reading against the original); voice notes are refused with a "coming soon" reply gated on hasTranscription(); unknown chats, empty messages, videos/documents/stickers get an immediate reply; unreadable cards/photos, orphan pins and failed media downloads are listed in the batch summary, and one bad item no longer aborts the batch. A genuinely ambiguous note is never argued about in chat — chat can hold only one open question per sender, so a batch naming three ambiguous people could only ever resolve the first and silently duplicated the rest. It becomes a note_subject confirmation carrying the note body, raised with origin: "messaging" and resolved in the app's Inbox; nothing is written to anybody until the user picks, and every ambiguity gets its own row so a batch can raise several. A parked note no longer parks its deadlines with it (2026-08-10): the same batch-plan call now also returns each unclear note's followUps, and applyUnclear (lib/messaging/process-session/apply/unclear.ts) writes them immediately as general tasks — contact_id/company_id NULL, user_id set explicitly through the tasks repo because a contact-less task has no other tenant anchor (an extraction-born follow-up inherits its tenant from the contact it hangs off; this one would belong to nobody and could never be surfaced), and due_hint resolved by the same deterministic resolveDatePhrase the extraction path uses — null when it resolves to nothing, never a guess. No classifier and no second model call: it rides the plan that already runs. Otherwise “need to check with the plumber today” sat inert in a confirmation card while the day it named went past, and a user who never opened the Inbox simply missed it. The ids ride on the payload (generalTaskIds) so answering the question can re-point them instead of stranding a duplicate beside a re-extracted one; an ambiguous phrase (“this weekend”) deliberately does NOT raise the second follow_up_date confirmation the extraction path raises — the note already carries one unanswered question, so the task takes the primary date and stays editable. Ordering is load-bearing: tasks are written BEFORE the confirmation (their ids have no later write) and never fatally — a task failure is logged PII-free and the ambiguity is still parked, because losing the note is the worse half. The batch reply says the reminders exist (generalTasksLine) rather than reporting only the open question. Covered by lib/__tests__/messaging-cases/general-tasks.test.ts. A note is now the sender's own words, never the model's account of them (2026-08-10): the plan used to carry a body the model composed, and on a long message it composed a short one — asked for prose about a person it kept the clauses that were ABOUT that person and dropped the rest, the sender's own thinking, which the plan shape offered nowhere else to put. A reported capture came back at about a fifth of its length under a plain "✅ Added 1 note" reply: the seq was still accounted for, so nothing anywhere said four fifths of it had gone, and the only way to find out was to read the note back. It looked like a summarisation bug and was not one — the model was filtering to fit the schema. So plannedNoteSchema (packages/core/src/schemas/batch-plan/, split from the single file per the 150-line rule) has no body field at all: a note states only WHICH message seqs it is made of, and assembleNoteBody (lib/messaging/process-session/apply/note-body.ts) joins those messages' own text in send order (sorted in code — the model returns seqs in whatever order it reasoned about them). Copying a message into a note is a deterministic transform and belongs in code (Rule 5); the model keeps only the judgement — whose it is, which messages group into one note, what in them was an instruction. Photos and voice notes ride the same one path, since DerivedItem.text already holds what the vision/transcription pass read off them. Three consequences, each pinned by a test: (1) the one thing that can be REMOVED is what the plan quotes into directives, cut by exact first-occurrence match — a miss keeps the whole message and says so in the reply (keptInstructionLine), because matching loosely would eventually cut a sentence the sender actually wrote, and a stray line they can delete beats a paragraph they never learn about; a message that assembles to nothing was only ever an instruction and writes no note, falling through to the person's own verdict (getting that wrong left such a message with no verdict at all — not stamped, not unaccounted, since the plan had mentioned it — so bare is now computed from the notes actually WRITTEN, not the ones planned). (1b — follow-up fix, same day) a message belongs to at most one note full stop, including two notes on the SAME person, which the cross-person guard below did not see. A single forwarded message that both recorded something and asked for something came back as TWO notes on one contact: the whole message, and the whole message minus its closing line, which the planner had quoted into the second note's directives. Both were written from the same source text, so the contact got the same paragraph twice with one copy a sentence shorter, under a reply saying "Added 2 notes" for one message. mergeOverlappingNotes (apply/merge-notes.ts) folds notes sharing a seq into one — transitively, so a chain that only overlaps pairwise still collapses — with seqs unioned and directives intersected, so a line is cut only where every note that claimed the message agreed it was an instruction. Intersected rather than first-wins deliberately: dropping the later note keeps whatever the FIRST one happened to cut, so had the planner emitted the two the other way round that sentence would have been lost for good, and the order the model emits notes in is not a decision about the user's text. (2) one message belongs to at most one person's notes: while the model wrote each body it could give two people different text off one message, but now the note IS the message, so a seq under two people copies the whole thing onto both. A contested seq is pulled from every person before anything is written (apply/contested.ts — from sourceItemSeqs too, or its photo and its verdict would attribute it by another route) and parked as a note_subject confirmation offering the claimants, stamped unclear with reason: "contested" so the capture log tells a planner conflict from a genuine ambiguity. No winner is picked: plan order is not evidence about who the user meant, and a whole message on the wrong contact is the failure they are least likely to catch. (3) the same rule governs unclear notes, which lost noteBody for the same reason — a parked note is the one the user is least able to check, sitting unread until they open the Inbox. Covered by messaging-cases/verbatim-notes.test.ts, note-directives.test.ts, contested-notes.test.ts, lib/__tests__/note-body.test.ts and lib/__tests__/merge-notes.test.ts. (The messaging_pending_questions table is vestigial — the old in-chat question mechanism was removed and nothing reads or writes it; this checklist entry described it long after it went dead.) The origin flag is load-bearing: an inline quick-add note_subject is answered on the spot and stays out of the inbox, and hiding the background-raised ones the same way is exactly what stranded a real user's note where no UI could reach it. A capture that names no person is never saved nameless — namedContact (lib/messaging/ingest-text/) falls back to the classifier's subject, then to the organisation itself (clearing company, or the profile shows it employing itself), then to UNNAMED_CONTACT_NAME; a blank-named contact renders as an empty row that no search can surface again, which is how a forwarded society noticeboard used to land. Text that INSTRUCTS the bot ('create a new contact', 'save this under Acme') is caught by an isInstruction flag folded into the existing captureExtractionSchema output — no extra round-trip, since the capture parse already runs on every text item — and is neither stored as a note nor mined for facts when a contact is already open; it used to sit in the timeline and have its imperative read straight back as a phantom follow-up. With nothing open it still establishes the contact it names, so nothing is dropped. Extraction also carries labelled emails/phones end to end (extractedMethodSchema = { value, label }), so 'Society office – 9999900102' and 'MNGL – 9999900103 (Ravi)' keep whose number is whose instead of arriving as an anonymous list. Built: provider-agnostic gateway (packages/core/src/messaging/ — WhatsApp + Telegram MessagingClients behind a registerMessagingProvider registry), webhooks /api/messaging/{whatsapp,telegram}/webhook (Meta GET verify via WHATSAPP_VERIFY_TOKEN; both POST verify via signature/secret and fail closed when unset), per-user token account-linking (Settings → Messaging; self-host single-owner falls back to DHAGA_OWNER_EMAIL), session batching + DONE delimiter, batch planner + deterministic apply, a capture log (Settings → Messaging) that keyset-paginates every batch ever forwarded and shows what each message became — created / attached / unclear / directive / unreadable / unaccounted, persisted on the row at write time because once the resulting contacts are edited there is no way back to what happened; a plan that omits a message stamps it unaccounted and says so in chat rather than dropping it, and a failed batch stays retryable with a PII-free reason and never silently falls back to the old per-message walk, idle auto-flush (the daily-cron floor everywhere via runMessagingFlush, plus an optional ~15-min POST /api/jobs/messaging/flush worker route — kept off vercel.json so Vercel Hobby's one-cron-a-day limit isn't broken), and the Settings → Messaging UI. Pending/stubbed: server-side voice-note transcription (pluggable TRANSCRIPTION_PROVIDER gateway shipped but no provider yet — voice notes are refused with "Voice notes aren't supported yet — coming soon!", and the refusal lifts by itself once a provider registers); true contact de-dup/merge across a batch (nothing de-dupes a forwarded card against the graph by its own fields — it promotes a "mentioned" stub, or merges into whoever the planner matched it to, and creates otherwise). A matched person is no longer a dead end (2026-08-09): augmentContact (lib/repo/contacts/write/augment/) writes the plan's contact — and a forwarded card's parsed profile — onto them ADD-ONLY: a phone/email/link/address/important-date/custom-field they lack is appended in SQL (c.phones || …, so a concurrent append can't be lost), one they have is left untouched (deduped on the merge core's entryKey, so "+91 98765 43210" and "098765 43210" are one number; custom fields have no merge-core key and fall back to a case-folded label+value pair), and title/company/location are filled only where empty — a stale card can never overwrite what the user curated. A filled job is a real positions row (2026-08-09), not just the denormalised title/company_id the shortcut used to write: the detail page showed a job the edit form's job list — which reads positions — could not show, so the user could neither confirm nor correct a stale card's employment. Written through insertPositionRows and only for a contact holding NO position, which keeps it add-only and keeps the denorm recompute agreeing with the fill; its source_note_id receipt is null by design (augment runs before the batch's notes exist, and the title usually comes off a card that produced no note — a receipt pointing at an unrelated note would be false provenance and would let deleting that note hard-delete the user's job). The apply step used to return the moment it had the contact id and discard every field the planner had extracted, so "+91 90000 00002 / Phone number of Grace Hopper" was read, badged Instruction, answered "✅ Updated Grace Hopper." and never written. The reply now names what actually landed ("Added a phone number to Grace Hopper"), says so plainly when nothing changed, and the log badges those messages attached. Covered by lib/__tests__/contact-augment/ + messaging-cases/augment.test.ts; .vcf-as-document ingestion; multi-contact association from free text beyond the positional pairing; the batch planning prompt is unmeasured — the batch_plan credit price in packages/core/src/metering/credits.ts is an estimate, not one of the 39 measured calls, and must be re-derived against the live API. Payment-gated since 2026-08-07 (hosted only): linking a new chat is an enforcement point for multi_device_sync (generateMessagingLinkTokenAction, lib/actions/messaging.ts) — a link token is the only way a chat becomes a capture channel, so minting one is the honest definition of "connect another channel". Unlinking and inbound processing of an already-linked chat are deliberately NOT gated: taking away someone's ability to disconnect a channel that reads their messages is a privacy problem rather than a monetisation one, and silently dropping messages a user is still forwarding to a number we told them to use loses their data. Self-hosts resolve to self_hosted and are unaffected. Pinned by lib/__tests__/messaging-link-entitlement.test.ts.
LinkedIn QR format support — pure matcher packages/core/src/capture/linkedin-qr.ts (unit-tested, apps/web/src/lib/__tests__/linkedin-qr.test.ts); web: QuickAddForm/PhotoCaptureInput.tsx detects via BarcodeDetector and routes to /app/people/new?linkedin= (prefills the existing manual-add form, no auto-create); mobile: camera-capture-view.tsx scans live via expo-camera, LinkedInQrPrompt hands off to the web form via Linking.openURL (mobile has no manual-add screen of its own to route to — see docs/notes, this is the closest honest equivalent). Typecheck/lint/test all pass; manual browser + device click-through still pending
Email/calendar interaction sync (Gmail/Outlook OAuth, explicit opt-in) — the one ToS-clean ambient-capture channel (BRD §6.7)

17. Teams (v2.0 — revenue engine)

Org workspace, contact-level sharing controls
"Who knows whom" across team
SSO; per-seat billing

18. Monetization & launch

19. SaaS platform — accounts, multi-tenancy, billing, admin (Dhaga Cloud)

Everything in this section is typecheck/lint/build/vitest-clean (including a build with packages/ee and its exclusive route folders physically removed, confirming the core doesn't need it — as of 2026-07-07 this is enforced on every push by the verify-without-ee CI job, not just a one-off manual check) but not yet manually click-tested in a browser or pushed — the checklist bar for [x] needs both, so these stay unchecked until that happens. A 2026-07-07 code audit confirmed every item below is backed by real, substantive implementation (RLS policies, Stripe integration matching the "4 event types" claim exactly, real notFound() admin gating) — none of this is a stub, the only gap is the manual click-through + push.

20. Considered features backlog (2026-07 review)

New gaps from a July 2026 competitive review. All unbuilt — considered, not committed. Full rationale, dedup against existing scope, and the considered-and-declined items live in BRD §5.4. Gaps already tracked are not re-added here (relationship-strength score → §14; LinkedIn import + job-change detection + keep-in-touch nudges → §4/§14; WhatsApp capture → §16); an external fundraising-discovery suite and iMessage/SMS capture were declined (BRD §5.4).

21. Viral growth loops (2026-07-24)

Three growth features built together on feat/network-wrapped-viral. All are typecheck/lint/build-clean across every workspace and the EE reward logic is unit-tested; not yet manually click-tested in a browser or pushed — same [x] bar as §19, so they stay unchecked until that happens. The public graph sandbox is web-only by design (a marketing surface); Wrapped + referral ship on web and mobile per the parity rule.

Network Wrapped — a contact-free, proud-to-post share card computed deterministically from the user's own graph (no LLM, zero metered cost, Rule 5). Scope-selectable: per event, or per week/month/quarter/year/all-time ("47 people this month", "12 at an event"). Server-rendered next/og card in three formats (1200×630 unfurl / 1080×1080 square / 1080×1920 story), with HMAC-signed params so cards can't be forged; public /wrapped/[token] unfurl page; authed /app/wrapped scope-picker + share modal (download / copy / native-share). Stats repo lib/repo/wrapped runs ONE aggregate query (no getDb() fan-out). Privacy: the card carries counts + cluster CATEGORY only; third-party names (top company, most-connected person) are reveal-gated in-app and never enter the token/URL/image. /api/wrapped (x-api-key) + mobile wrapped screen (RN Share).
Public interactive graph sandbox (landing, web-only) — a STATIC, anonymized network the visitor drags/zooms/hovers, reusing the /app sigma renderer verbatim (useRenderer/reducers/theme/camera) with positions baked offline. Loads ONLY on demand: the landing ships a light teaser + CTA; the sigma chunk + graph-core.json (~3.9k nodes, ~134 KB gz) fetch on click, and graph-full.json (21k nodes, ~820 KB gz) only on "Explode to full network". Baked by scripts/export-public-graph.mjs from the deterministic seed generator (synthetic names, no PII, no DB, no network).
Two-sided referral (hosted/EE) — a free month of Pro for both sides. /r/<code> sets an httpOnly cookie; a valid code admits the referee past the invite allowlist; the reward fires on email-verify. Stripe-safe: a live-Stripe advocate gets a 100%-off-1-month coupon (STRIPE_REFERRAL_COUPON_ID), free users get an additive comp Pro month (null-preserving). Anti-abuse: self-ref + duplicate + per-referrer cap. packages/ee/src/referrals (control-plane tables, no RLS); web /app/referral + /api/referral; mobile advocate screen. Redemption is web-signup only.
Dhaga Classic preserves the original warm paper/charcoal light and dark palettes as an eighth Appearance preset; the refreshed blue-white/midnight Dhaga palette remains the zero-overhead default.

Two features built together because they share one foundation: Dhaga had nowhere to record who you are, and a template needs a signature while a shared page needs a sender. Both are core — nothing here imports packages/ee — and neither makes a single AI call, so there is no new credit price and no new row in BRD §8.3. Web only; no mobile parity (the Expo app has no /app/me equivalent and cannot mint a link).

Test state, as measured rather than assumed (run 2026-08-23, ten files, 64 cases): 63 pass and ONE FAILS. me-profile.test.ts › "updates in place instead of accumulating rows" calls upsertMeProfile({ headline: … }) with the old single-argument signature, while the repo now takes (userId, input) — the signature changed when the singleton fix landed (below) and this caller was not brought with it. The consequence is not cosmetic: the singleton write is the one path in this feature with no passing coverage right now. Everything else — templates, rendering, expiry, revocation, both projections, the share actions, the resolver's tenant scoping, the DDL replay and the analytics-token redaction — is green.

Nothing else has been verified either: no browser click-through, no push, and the live-database RLS isolation run is still owed (see the last item). So every box here stays unchecked — same bar as §19 and §21.

The Me page (/app/me, 2026-08-22) — Profile / Company / Templates, with the tab as URL state (?tab=, the /app/saved shape) so a pane is linkable and the back button works; an unrecognised value narrows to Profile rather than 500ing. Profile and Company are two halves of ONE me_profile row (lib/db/ddl/me.ts, db/schema/me.ts, repo lib/repo/me/, actions lib/actions/me/, UI app/app/me/ + components/app/me/): the account holder has one employer at a time for the purpose of a letterhead, so a second table would buy a join and nothing else. Singleton-ness IS the primary key, because id is the owning user's id — the same trick referral_codes uses in packages/ee. A UNIQUE (user_id) cannot be declared in core (the column does not exist there; EE's RLS loop adds it later), so the key the table already has does the work and the write is one INSERT … ON CONFLICT (id) DO UPDATE. This was corrected on 2026-08-22 after a concurrency audit, and the reason is worth keeping: the first implementation was lookup-then-upsert inside one mutation() transaction, and both the code comment and the design doc claimed the transaction prevented a double insert. It does not — at READ COMMITTED neither transaction sees the other's uncommitted row, so with nothing to conflict on both saves observe "no profile", both insert, and every later read limit 1s onto an arbitrary one of them. A transaction cannot serialise two inserts that have no row to collide over; only a key can. getMeProfile() still orders by updated_at DESC, id ASC as belt-and-braces, so a row written by the earlier build (keyed on a random UUID, and therefore able to sit beside the user-keyed row) resolves to the newest write rather than to whichever one the planner reached first. Stale comment flagged, not fixed — lib/db/ddl/me.ts's header still says singleton-ness is "enforced in the REPO (lookup-then-upsert)"; that describes the implementation this audit replaced. Templates are document templates and email drafts in one me_templates table with a kind discriminator, because they differ only by whether a subject line applies; a body is stored verbatim with its {{tokens}} unexpanded, so editing the profile updates every template that references it instead of leaving stale copies behind. Substitution is a pure function and that is the cost story (lib/templates/render.ts): no DB, no LLM, no clock — if code can answer, code answers — so this path adds no AI action, no credit price and no metering, and the same function runs in the editor's live preview (client) and on the server. The vocabulary is closed and enumerated (utils/constants/me.ts, 14 tokens), deliberately not an open object-path syntax, which would be a read primitive aimed at whatever object the renderer was holding; {{ me.name }} with spaces is the same token as {{me.name}}, an unknown token is left VERBATIM so a typo stays visible instead of silently deleting a line from a letter, and a known-but-unfilled one renders empty. The live preview merges the user's REAL profile with invented samples for the recipient — no contact is picked yet and borrowing one from the graph would put a third party's PII on a screen nobody asked for. Field caps (ME_TEXT_MAX 200 / ME_LONG_TEXT_MAX 4000 / TEMPLATE_BODY_MAX 20000) are product limits in the form and the server action, not column constraints, so raising one needs no migration and an over-long legacy row stays readable. Nav: Me sits in the overflow/You sheet (APP_MORE_LINKS, APP_MORE_MENU_LINKS), not the rail — you fill a profile in once. Tests: lib/templates/render.test.ts (every token class, whitespace tolerance, unknown-token verbatim, an unclosed {{ not throwing, "no listed variable is dead", and that the preview never carries a real contact's details), lib/__tests__/me-profile.test.ts (singleton upsert, partial submits, present-and-blank means delete, over-long rejected not truncated), lib/__tests__/me-templates.test.ts (a subject exists only on an email, unknown kind refused, empty title/body refused, CRUD round-trip). NOT pushed, and no browser click-through has happened — this stays unchecked until both. Deliberately not built yet, so nobody reads this as more than it is: nothing renders a template against a CHOSEN contact. {{contact.*}} is implemented and tested and buildTemplateValues accepts a recipient, but the only surface that expands a template today is the editor preview, which always substitutes samples — picking a recipient and producing the finished text is the next step.
Share links (/s/[token], 2026-08-22) — one contact or one company published at an unauthenticated URL that always expires. Schema lib/db/ddl/share-links.ts + db/schema/share-links.ts; repo lib/repo/share-links/; pure helpers lib/share/{expiry,token,url}.ts; projection lib/share/projection/; resolver lib/share/resolve/; actions lib/actions/share-links.ts; public route app/s/[token]/; owner UI components/app/share/ mounted from ContactActionsCard and CompanyDetailActions. Expiry is mandatory and has no escape hatch: presets are 24h / 7d / 30d / 90d (SHARE_EXPIRY_PRESETS, default 7d), there is no sentinel meaning forever anywhere in utils/constants/share.ts, the server clamps to SHARE_MAX_EXPIRY_HOURS (365 days) for requests that did not come from the presets, and an expiry the server does not recognise is REJECTED, never quietly defaulted — a request whose intent we cannot read must not mint a working link. Liveness is one read-time check (isLive: revoked_at IS NULL AND expires_at > now), so revocation is instant with no cache to invalidate and no sweeper that must have run; expired rows are kept as the owner's record of what was shared. Unknown, expired, revoked and dangling links all render the SAME neutral page (not-available.tsx) — telling them apart would confirm to a stranger holding a guessed string that the token was once real. Disclosure is opt-in, five toggles, all DEFAULT FALSE (include_contact_details / include_notes / include_people / include_facts / include_follow_ups, the last two added 2026-08-24), and a toggle that cannot apply to the subject is stored false rather than carried inert, since the row is the audit record of what was disclosed — include_contact_details is contact-only and include_people company-only, while facts and follow-ups are clamped by neither, because facts and follow_ups each carry a contact_id or a company_id and listCompanyFacts / listOpenCompanyFollowUps exist for exactly that. Defaults are name/nickname/title/company/positions for a contact and name/domain/sector/aliases for a company; behind a toggle: contact details, owner-written notes (SHARE_MAX_NOTES 50), facts (SHARE_MAX_FACTS 50) and OPEN follow-ups (SHARE_MAX_FOLLOW_UPS 25, lower because a long list of what the owner still owes someone is a portrait of how they manage the relationship); never disclosed at all: tags, starred, keep-in-touch cadence, personKind, source, signals, card photos, relationship edges, a fact's confidence, a follow-up's recurrence schedule and closed follow-ups, and the source_note_id receipts that ride on facts, edges, follow-ups AND positions. Enforced by an allow-list projection built field by field, never a ...spread, so a column added to contacts later cannot silently widen an existing link; card photos are also structurally out of reach (/api/card-image/[id] is session-gated and 401s a visitor). The one correctness constraint is tenancy. A visitor has no session, so getDb() would fall through to the global UNSCOPED connection and getContact(id) carries no owner predicate — calling a repo read straight from the public page would hand any tenant's contact to anyone who guessed an id. So share_links is a cross-tenant routing table with an explicit user_id (in CORE_DECLARED_USER_ID_TABLES, deliberately ABSENT from EE's TENANT_TABLES alongside messaging_identities/messaging_link_tokens — an RLS policy would compare user_id against a session variable that is unset at exactly that moment and match nothing), the owner is read off that row first, and every content read happens inside withUserDb(link.userId, …). No FK to contacts/companies, twice deliberate: an FK check bypasses RLS and would be a cross-tenant existence oracle, and a plain REFERENCES is RESTRICT in this repo, so an outstanding link would veto "forget this person" — a privacy promise cannot have a delete a stale link can block. A dangling subject_id is therefore an expected state that fails closed, and deleting the person is itself a revocation. A visit records a count and nothing else — view_count / last_viewed_at, no visitor identity, IP or user agent; a share link must not become a tracker aimed at a third party — and it is recorded only once the link actually resolves, so probing a guessed token never lands in the owner's receipt. Not indexable: ${SHARE_PATH}/ joins the robots.ts disallow list (trailing slash load-bearing — a bare /s prefix-matches /signup and /sitemap.xml), the page sets robots: { index: false, follow: false }, its title/description are fixed strings so no crawler or chat-app unfurl republishes a private person's name, and it is force-dynamic because a prerendered copy would keep serving seconds after a revoke. Account deletion covers it: share_links, me_templates and me_profile are all in ACCOUNT_OWNED_TABLES — nothing cascades them, so an outstanding link would otherwise outlive the account. A recipient can save the person, not just read them (2026-08-24). The contact body carries a quick-action row — Save contact always, plus Call / Email / WhatsApp only when include_contact_details is on — built as plain <a href>s rather than scripted downloads, because a text/vcard response opens the OS add-contact sheet only when the browser makes the navigation itself; nothing there is instrumented and the wa.me link is digits only with rel="noreferrer", so the person's name leaves the page in nothing. GET /s/[token]/vcard (app/s/[token]/vcard/route.ts) builds the file from lib/share/vcard.ts, a sibling of the export writer rather than a caller of it: contactsToVCards takes an ExportContact extends ContactRow — the raw row this whole page exists to keep away from a visitor — so the shared builder takes SharedContactCard instead, and details being ABSENT unless toggled makes an over-disclosing file impossible by type rather than by review. Escaping is the export writer's own helpers, whose parameter was widened to Pick<ContactMethod, "value" | "label"> rather than duplicated — a second escaper would mean a name that renders correctly on the page and corrupts the file. The route re-resolves the token, so expiry and revocation are re-checked at DOWNLOAD time, and passes countView: false because a sub-resource of an already-counted view must not report the link as opened twice; it is force-dynamic + no-store, and returns the same bare 404 for an unknown/expired/revoked token AND for a company link, which has no vCard — a different status would let a stranger probe whether a token exists. The Content-Disposition filename goes through an allow-list ([A-Za-z0-9 _-], NFKD first) because the person's name is owner-typed data landing in an HTTP header, where a quote ends the parameter early and a CR/LF starts a new one. Tests: lib/__tests__/share-resolve.test.ts (the resolution opens the scope named ON THE ROW and never reads a subject outside one; nothing resolves one second past expires_at with no sweeper having run; revocation is immediate; a revoke from anyone but the owner is refused; unknown token and dangling subject both fail closed), share-expiry.test.ts (each shipped preset resolves and nothing else, no preset means forever or reaches the ceiling, the clamp cannot be routed around, the expiry instant itself counts as over, URL building), share-projection.test.ts + share-company-projection.test.ts (the exact disclosed key set, receipts and the owner's private per-position note stripped, each toggle honoured, a fact stripped of confidence/sourceNoteId and a follow-up of its recurrence/status — the key-set assertions are what a future ...spread would fail on), share-actions.test.ts (an unrecognised expiry rejected rather than defaulted, an unknown subject type rejected, refusal to mint against a subject the caller cannot see, only applicable toggles stored — including facts/follow-ups surviving on BOTH subject types — every toggle opening only on a literal true, revoke reflected in the refreshed list), me-share-ddl-replay.test.ts (the two later columns reach a database that already holds links, closed), share-vcard.test.ts (a card with NO details produces a vCard with no EMAIL/TEL/URL line at all — a downloaded file outlives the link's expiry and nobody re-reads it, so over-disclosure there is worse than on the page — plus CRLF endings, vCard escaping of a name's own separators, and the filename sanitiser against the header injection it exists to stop). NOT pushed, and no browser click-through has happened. Manual QA — including opening a link in a private window with no session — is written up in the testing guide §7ad and has not been walked yet.
The share token stopped leaking into analytics (2026-08-22, found by the same audit pass) — app/layout.tsx mounts Vercel Web Analytics and Speed Insights on every route, /s/[token] included, and both store the CONCRETE url of every data point. The only defence, redactAnalyticsUrl (lib/analytics/redact-url.ts), replaced a path segment only when it matched a UUID — and a share token is randomBytes(32).toString("base64url"), which matches that pattern in no character. So the redactor was a complete no-op on the one route where the path segment is not an id but the whole credential: it was reported intact on every view, to a third-party store that retains it past the link's own expiry, where anyone with dashboard access could have used it to read a named person's record. The fix is a second redaction that works by POSITION rather than shape — ANALYTICS_OPAQUE_PATH_ROOTS (utils/constants/analytics.ts) declares that whatever sits directly under /s is secret, anchored to the START of the path so a segment merely named s deeper in another route (/blog/s/…) is untouched, and REFERRAL_PATH was extracted alongside it rather than left as a bare "/r". Position is the property that survives someone re-encoding tokens later; shape is not. /wrapped is deliberately NOT in the list (its token is contact-free by construction and /wrapped/og is worth telling apart in the analytics) and /r/<code> is not either (a route handler that 302s before any analytics script runs). Covered by four cases in lib/__tests__/analytics-url-redaction.test.ts, written against a real generated token rather than a literal, precisely because the defect was that the token's shape is unrecognisable. The two throwaway audit artefacts that documented both findings were deleted once the fixes landed, which is why neither is cited above.
New tables + RLS specs — me_profile and me_templates are added to EE's TENANT_TABLES (they hold one identifiable living person's own name/email/phone and their own drafts in their own voice — nothing derived, so no FK could scope them even in principle) with matching entries in the RLS isolation test's SPECS, without which nothing proves their rows are hidden from another tenant. share_links is deliberately in neither list, for the routing-table reason above. lib/__tests__/me-share-ddl-replay.test.ts proves the three tables apply cleanly to a database that predates them, leave existing rows alone, replay idempotently, and that Postgres itself refuses a share link with no expiry. The live-database RLS isolation test was NOT run: it needs a real Postgres with a non-superuser role and skips itself without DATABASE_URL — in CI too — so what is proven today is the database-free tenant-table coverage guard plus the DDL replay, not that the policies behave against a live server.

Build checklist

On this page