Changelog

User-visible and structural changes. Newest first. Format: YYYY-MM-DD.

The picker. The ad-set builder asked for a Meta pixel id as fifteen typed digits. There is no structure to that number and no check character, so the wrong one is not an error anywhere — Meta accepts it, the ad runs, and the campaign optimises toward events it will never see. The only symptom is a conversion count that sits at zero, and by the time that reads as a configuration problem rather than a bad audience, a week of budget is gone. GET /ad-accounts/:id/pixels now reads the account's pixels off Meta's adspixels edge and the field is a dropdown of names, each showing when it last fired — which is what distinguishes the live pixel from the three left over from previous sites. The text box stays as the fallback for the three cases that all want the same answer (the fetch failed, the account has no pixels, the stored id isn't in the list), because a dropdown is a convenience and must never become the reason a campaign cannot be configured.

The forwarding. POST /track/conversion now also sends the conversion server-to-server to Meta's Conversions API. The browser pixel is the least reliable part of the measurement stack — Safari's ITP caps its cookies, ad blockers remove the script, iOS ATT removes the identifier underneath it — and what Meta cannot see, Meta cannot optimise toward, so a campaign buying "purchases" spends its budget learning from whatever fraction survived the trip. This path has no browser to block and no cookie to expire. The destination pixel comes from AdGroup.targeting.pixel_id — the field the ad-set builder writes (D-031) — so the pixel a campaign optimises against is by construction the one its conversions reach, deduplicated across ad sets because several routinely share one and repeating the send is triple-counting rather than redundancy.

Three details that are the whole difference between working and looking like it works. Value is converted to major units (4999 → 49.99), because sending minor units overstates revenue a hundredfold and the ROAS optimiser believes it. event_time is epoch seconds; milliseconds are accepted by Graph and land the event fifty thousand years past the attribution window. event_id carries the conversion's own id, so the browser pixel and this path cannot count the same purchase twice. The brief specified act_{account}/events, which is not a real endpoint — CAPI is scoped to a pixel, and posting to an act_ node returns "path /events does not exist", so building it as written would have failed on every call and, because this path swallows its errors so it cannot slow a checkout page, failed in silence (D-032). The only identifier sent is a hashed external_id; no raw IP leaves the process, because the touchpoint table stores ipHash and never an address and shipping the raw one to a third party would make that posture a fiction (D-033). Forwarding is fire-and-forget: a Graph outage, a rejected event and an unreachable host all leave the tracker returning 201 with the conversion recorded. | F-114 · F-115 · apps/api/src/modules/ads/pixels.ts · apps/api/src/modules/attribution/capi-forwarder.ts | Claude | | 2026-08-31 | feat | A rich email composer (F-113). The broadcast composer was four fields and a <textarea>; it is now the screen the feature deserved. A formatting toolbar (font, size, bold / italic / underline / strikethrough, text colour, highlight, alignment, bulleted and numbered lists, indent / outdent, blockquote, undo, redo, clear formatting), hyperlinks with their own display text, inline images by upload or drag-and-drop, file attachments, a merge-tag picker that works in the subject line as well as the body, a Desktop / Mobile preview, a test send, drafts that autosave, saved templates, a project signature, and a full-screen mode. The layout is deliberately Gmail's — this is the screen where getting it wrong mails the wrong thing to a few thousand people, and a familiar shape is a smaller source of mistakes than a clever one.

Four things are worth knowing about how it is built. The sanitiser is shared and it runs on write (D-030): the same allow-list function in @verjson/contracts cleans the body in the browser preview, in the API on save, and again on a signature at render — so what the preview shows, what the database holds and what the recipient receives cannot diverge, and no read path can forget to clean anything. It is an allow-list at four levels (tags, attributes, URL schemes, CSS properties), so a payload nobody has thought of fails closed. The editor is contenteditable + execCommand (D-029) rather than an editor library, because every button here is one command every browser implements, and a document-model editor would have to be taught to emit exactly the subset of HTML the sanitiser permits or watch the server strip its output. The signature is inserted into the body, not appended at send (D-028), because a sign-off the sender never saw in the editor or the preview is a paragraph added to their email by something they never saw. A test send shares none of the dispatch path: no recipient rows, no status change, no counters, no audience resolution — "I only meant to test it" is not a recoverable state.

Every broadcast now goes out multipart, with the text part derived from the HTML rather than typed twice, because a message with no text/plain part renders as nothing in a client with HTML disabled. Merge tags are escaped into the HTML part and not into the subject or text part — the contact table is filled by CSV and Google Sheets, so a name is input from outside, and getting that split wrong is either an XSS in every other recipient's webmail or a literal & in the inbox. Attachment bytes are read from our own storage by key, once per dispatch rather than once per recipient, and a key outside the caller's organization prefix is a 404 before anything is read. Drafts autosave into a real row from the first save, so a closed tab recovers through the broadcast list, which has always shown drafts — and the indicator says "Draft saved 14:22" only after the server said so. Nothing drafted before this change behaves differently: body_text stays NOT NULL, a text-only broadcast is still sent text-only with no HTML part invented for it, and the 76 existing broadcast tests pass unchanged. | F-113 · packages/contracts/src/email-html.ts · apps/api/src/modules/email-broadcasts/{render,attachments}.ts · apps/web/src/components/email/ | Claude | | 2026-08-27 | feat | Import contacts from a Google Sheets link (F-111.2). The import modal grows a second source tab: paste a sheet URL instead of uploading a file. Everything around the source is unchanged — the fallback-segment picker, the auto-create-categories switch and the result summary are shared — and so is everything underneath it: the sheet is fetched server-side through Google's gviz/tq CSV export and handed to the same parseContactsCsv a file goes through, so header aliases, address normalisation, custom-category matching, in-file de-duplication and the 20k row cap cannot drift between the two paths. The link is validated in the browser by the same parser the API runs, from the contracts package, so a typo costs no round trip and the field can never accept something the server will reject. SSRF is closed structurally, not by allow-list. The obvious build — check the pasted URL's host, then fetch that URL — is the one that keeps failing in the wild, defeated by redirects, by userinfo (https://docs.google.com@evil.test/), and by DNS rebinding. So the server never fetches the pasted URL at all: it extracts an id matching an anchored [A-Za-z0-9_-]{20,200} and builds a fresh URL against a hardcoded https://docs.google.com, with redirect: "manual" so an off-Google Location is a refusal rather than a second request. The user controls no scheme, host, port or path segment of the request actually made; the host list is a usability gate for error messages, nothing more. Scope and role are checked before the fetch, so the endpoint cannot be used as a probe for whether an arbitrary spreadsheet exists, and it is rate limited at 10/min as the only endpoint that makes an outbound request on user input. Failures are written for the person who pasted the link: a private sheet names "Anyone with the link" rather than reporting a 302, and Google's HTML sign-in page is caught before it reaches the CSV parser and gets misreported as "missing an email column". Oversized bodies are aborted mid-read rather than buffered and then measured. Contacts record source: "google-sheet:<id>", so "where did this address come from" stays answerable. | F-111.2 · packages/contracts/src/email-broadcasts.ts · apps/api/src/modules/email-broadcasts/google-sheets.ts · apps/web/src/app/(app)/projects/[id]/email-broadcasts | Claude | | 2026-08-27 | feat | Custom audience categories for email broadcasts (F-111.1). The Audience header is no longer three fixed cards: a project can create its own segments — name, description, colour — from a Create category card sitting at the end of the same grid, and they appear beside the built-in three with live counts, filter on click, and can be renamed or deleted in place. Contact rows re-file into any of them from the inline segment dropdown, the composer targets one and shows its sendable count before Send, and CSV import matches them by name, case- and whitespace-insensitively (Enterprise Renewals = enterprise renewals = ENTERPRISE-RENEWALS), with an opt-in switch to create the ones a file names but the project lacks. The downloadable template now lists the project's own categories as example rows — built in the browser, because the template route is deliberately unauthenticated and an <a download> cannot carry a localStorage bearer. Three decisions carry the feature. One audience column, not two: email_contacts.category became nullable next to a new custom_category_id, with a CHECK constraint enforcing exactly one — the tempting alternative (keep the enum NOT NULL as a "fallback") leaves a contact in the custom segment "VIP" still matching WHERE category = 'active_clients', and one audience query forgetting AND custom_category_id IS NULL mails the wrong list. Deleting a category is never a silent audience loss: one holding contacts answers 409 with the head count until a destination is named, and the contacts move rather than vanish (the FK is RESTRICT as a backstop). History outlives its category: a broadcast snapshots the segment name into audience_label at draft time and its FK is SET NULL, so "who was this sent to" survives a rename or a delete — and a draft whose audience was deleted refuses to send by name instead of guessing one. Uniqueness is per project, not per org, so two clients of one agency can both have a "VIP"; a name the CSV importer already reads as a built-in segment is refused at creation, because built-ins win a collision by design and a shadowed category would be silently unreachable from a spreadsheet. | F-111.1 · packages/contracts/src/email-broadcasts.ts · apps/api/src/modules/email-broadcasts/* · apps/web/src/app/(app)/projects/[id]/email-broadcasts · migration 20260827100000_email_custom_audience_categories | Claude | | 2026-08-27 | fix | A Slack integration could die and go on looking healthy forever. Deleting an Incoming Webhook inside Slack changes nothing on our side: the row stays verified: true — that flag only ever recorded that one send worked once, on the day it was set up — and every subsequent notification POSTed at a URL Slack answers 404 no_service. The transport logged it and swallowed it, per MUST-NOT-throw. So the settings page kept showing a green Verified badge, the notifications kept not arriving, and the only record was a server log nobody reads. This is the exact failure UserOutboundWebhook was already built to catch, and Slack simply never got the same treatment. Four columns bring it to parity — disabled_at / consecutive_failures / last_failure_at / last_failure_message — and the fan-out now filters on disabledAt: null, so a dead hook stops being re-dialled on every notification for the rest of time. Two ways to give up, because Slack distinguishes them for us. A revoked hook answers 404, an uninstalled app answers 410, a workspace-disabled hook answers 403: none of those un-break by waiting, so we disable on the FIRST one and say so. Everything else — 5xx, rate limits, timeouts — is transient by nature and goes through the 10-consecutive-failure counter, so one bad afternoon at Slack does not cost a user their integration. An undecryptable webhook URL disables immediately too: that means ENCRYPTION_KEY rotated out from under the row and no send will ever succeed again. At the moment of disabling the owner gets an in-app slack_integration_disabled notification — which is deliberately never sent through Slack, and needs no explicit exclusion to be safe: by the time it is emitted the row is already disabledAt, so the fan-out skips it for free. Recovery has two doors because the causes are two. A revoked hook needs a NEW URL, so re-registering clears the whole failure history rather than inheriting it. A receiver that was merely down needs the switch flipped, so POST /user/slack/enable clears the disable with no send at all — and a successful POST /user/slack/test does the same implicitly, because making someone hunt for a separate Enable button after the app has just proved the hook works is ceremony. A failed manual test records its reason but pointedly does NOT count toward auto-disable: a user pressing a button is diagnostics, not traffic, and ten frustrated clicks must not disable an integration they are actively repairing. The test endpoint now returns Slack's own reason (no_service, channel_not_found) instead of the app guessing on the user's behalf. Panel leads with Turned off over the green badge, because "your notifications stopped a week ago" is the thing worth knowing. +16 tests (12 API, 4 web). | apps/api/prisma/schema.prisma + migrations/2026082712{0000_slack_integration_health,0100_slack_integration_disabled_kind}/, apps/api/src/modules/notifications/{slack,slack-routes,emit}.ts, packages/contracts/src/{user-slack,notifications}.ts, apps/web/src/lib/{user-slack,connection-health,integrations-hub,notifications}.ts, apps/web/src/app/(app)/settings/integrations/slack-panel.tsx, apps/api/src/test/slack.test.ts | Claude | | 2026-08-26 | feat | Per-project email broadcasts (F-111). A new Email Broadcasts section in the project sidebar, directly under Campaigns, with two tabs. Audience is the mailing list the project owns: drag-and-drop CSV import, filed into three fixed segments — Active Clients & Buyers (active_clients), Inbound Web Leads & Visitors (inbound_leads), Compute Supply Partners & Hosts (supply_partners). The segment is a Postgres enum rather than free-text tags on purpose: "who did we mail" has to still be answerable in six months, and free text drifts into Leads / leads / Lead inside a week. Broadcasts composes one plain-text email against one segment and dispatches it over the project's configured SMTP transport (the same config.email block that already carries invitations and notification mail), then shows a per-address delivery table. The importer is forgiving on the way in and strict on the way out — BOM, E-mail/Segment header aliases, mailto: prefixes, "Name" <a@b.com>, and human category labels all parse; anything that still isn't an address is rejected with its row number rather than dropped, because an import that silently loses 12% of a spreadsheet isn't found out until the campaign under-delivers. Three things are load-bearing and tested as such: an unsubscribe is a suppression flag, never a deleted row, so a re-import cannot resurrect somebody who opted out; a second click on Send loses a conditional draft → sending claim (updateMany on status) and gets a 409 instead of mailing the list twice; and every address carries its own outcome, so a partial send reports which addresses failed rather than a green tick. Sending is owner/admin only — drafting and curating the list is member work, pushing mail to a few thousand external addresses under the client's name is not. A deployment with EMAIL_ENABLED=0 refuses the send with a 422 up front instead of writing N identical failed rows. 100% additive: three new tables, one new router mounted at /, one new sidebar entry — no existing model, route, contract or page changed shape. Still to come: HTML bodies (needs sanitisation + an unsubscribe-footer injector), scheduled sends, and open/bounce tracking — the recipient status vocabulary is deliberately dispatch only, so the UI never claims knowledge it doesn't have. | apps/api/prisma/schema.prisma · apps/api/src/modules/email-broadcasts/* · apps/api/src/app.ts · packages/contracts/src/email-broadcasts.ts · apps/web/src/lib/{email-broadcasts,project-ia,section-tabs}.ts · apps/web/src/app/(app)/projects/[id]/email-broadcasts/[[...tab]]/page.tsx | Claude | | 2026-08-26 | feat | The Baileys WhatsApp bridge exists (F-048, step 1). services/whatsapp is a standalone ESM Node 22 service on :4100 — deliberately outside the npm workspace, so it can hold a stale Baileys pin without dragging the API's dependency tree with it. It manages one long-lived WhatsApp Web socket and exposes it over HTTP: GET /health (open — it is the container probe and reveals only liveness) and, behind x-bridge-token, GET /status, GET /qr, POST /send and POST /disconnect. The QR comes back as a PNG data URL and expires after 60 s rather than being served stale, because a stale code costs a wasted scan and looks like a broken pairing. /send refuses with 409 when the socket is not open instead of dropping the message silently. /disconnect logs the device out, wipes the auth volume and comes back up un-paired, which is the whole re-pair path. Inbound messages.upsert, delivery receipts and connection changes are POSTed to WEBHOOK_URL with the same token, fire-and-forget: a webhook failure logs and is dropped, never taking the socket down or failing a caller's send. Reconnects use exponential backoff to 30 s; a loggedOut close clears the auth state instead of looping on dead credentials. Baileys is pinned to 6.7.24 on purpose — npm's latest tag is a 7.0.0-rc, and legacy is the last stable line. Still to come: the API half (POST /api/v1/whatsapp/events, the ChannelProvider adapter, opt-in, templates, the verjson.whatsapp consumer). ⚠️ Unofficial client — D-015 stands. | services/whatsapp/src/{index,baileys,routes,config,webhook,logger}.ts · services/whatsapp/Dockerfile · docs/INFRASTRUCTURE.md | Claude | | 2026-08-31 | feat | The project shell stopped saying everything twice. Three separate duplications, one shape. (1) The sidebar restated tab bars that sit directly below it. Content listed New post / All posts / Drafts / Scheduled / Published, Calendar listed Monthly / Weekly / Content Calendar / Ad Calendar, Approvals listed Pending / Approved / Rejected / Feedback — and every one of those resolved to a route the page already reaches through its own controls, several of them to the same URL with a query string. Only the two children pointing somewhere a tab strip cannot reach survive: Media Library (still /measure/media) and Bulk import (a static route with its own upload + preview state). Approvals became a leaf like Inbox and Publish log. The tab bars are not generated from these children — the ids live in lib/section-tabs.ts, which was not touched — so this is a sidebar change and nothing else; had they been generated, deleting the children would have emptied the calendar's view switcher. Two tests pin that independence in both directions, because the monthly/weekly slug mappings are now unreferenced by the IA and read as dead code to anyone tidying up. (2) The breadcrumb band spent a full horizontal strip on Projects › <project> › <section> above a sidebar that already marks the active section. Deleted; project identity moved into a new switcher at the top of the sidebar — name, status badge, and a dropdown listing every project, which the breadcrumb could not do: getting from one project to another meant going out to the list and back in. The breadcrumb's one irreplaceable affordance, the link back to /projects, survives as a pinned All projects row at the foot of the panel. It is a disclosure, not a role="menu" — the items are links, so tab order and Enter already work, and advertising arrow-key roving that isn't implemented reads worse than no role. (3) The calendar toolbar gave a passive view selector the same solid bg-primary fill as the page's only call to action, and put + New post at the end of a control row directly above the grid, detached from the page it acts on. The CTA moved up onto the heading row; the switcher became a raised chip on a bg-muted trough (the pattern already on the marketing hero board), with hover: pinned on both branches because the shared ghost variant's hover:bg-muted would otherwise make an unselected chip identical to a selected one. The date range label moved between the arrows where a date shifter is read — keeping its "go to today" reset, which the visible text no longer states, so it carries an explicit aria-label and title rather than silently losing a working affordance. Arrow buttons were size="icon" (40px) in a row of 32px controls, stretching that group 8px taller than the switcher beside it. +5 tests, −1 rewritten. Frontend only — no API, contracts, schema or compose changes. | apps/web/src/lib/project-ia.ts + test, apps/web/src/app/(app)/projects/[id]/{layout.tsx,project-switcher.tsx}, apps/web/src/app/(app)/projects/[id]/calendar/[[...tab]]/page.tsx, docs/{IA,DECISIONLOG,VERIFICATION}.md | Claude | | 2026-08-26 | feat | Teams, individual roles and work assignment — and the one thing they deliberately do NOT do. The ask was teams with roles that can be handed work. The spec that came back merged two different ideas into one column: it replaced project_members.role (a permission — lead/contributor/viewer) with a job title (Designer, Writer). Those answer different questions, and "Designer" does not say whether someone may edit the project — so building it that way would have quietly dismantled access control. Four things are called a "role" here and only two grant permission: workspace role and project role decide what you may do; team and individual role describe who you work with and what you make. This ships the two descriptive ones and leaves the two permissions untouched. project_members has not been altered, and a team grants access to nothing — pinned by a test where a team member with no project_members row still gets 404 on the project. Two routes to the same access is how "why can this person see this?" stops having a short answer, and we invite agencies into this system. Sub-teams were asked for (video / infographic / carousel) and deliberately not built: granular individual roles inside one team answer "whoever does video in Design" as (Design, Video Editor) — the same question, two levels of hierarchy instead of three, and no third level for every screen and permission check to carry. Assignment can name a team rather than a person, which a single assignee column cannot express: the work shows in My Work for everyone on that team as Waiting on your team until somebody picks it up, then disappears from the others' lists. Several assignments per post, because a post needs a designer AND a writer. Status and due date live on the assignment, and the assignee may close their own work without project write access — otherwise every status change would need someone with edit rights, which defeats handing work to a contributor. New /my-work in the main nav; assignment panel on the post in Calendar; Settings → Teams. Chat was requested and refused (F-113): Slack is already integrated and a usable chat needs threads, unread state, search and mobile — a product, not a feature. +27 tests (17 API, 10 web). | apps/api/prisma/schema.prisma + migrations/20260826120000_teams_and_assignments/, apps/api/src/modules/teams/, packages/contracts/src/teams.ts, apps/web/src/lib/teams.ts, apps/web/src/app/(app)/{my-work,settings/teams}/page.tsx, apps/web/src/components/assign-panel.tsx, apps/api/src/test/teams.test.ts | Claude | | 2026-08-25 | feat | Fine-grained ad-set location targeting in the UI. New LocationPicker component with a Target-location-type selector — Country / State-region / City + radius / Zip-postal — backing the regions / cities / zips fields the mapper already understood but nothing could set. Items render as removable chips. One kind is active at a time, and that is a correctness rule, not a simplification: Meta unions everything inside geo_locations, so a city radius sitting beside a country is not a narrower target — it is the whole country at the whole country's cost, and the platform's response says nothing. selectionToTargeting emits only the active kind, which matches the precedence the server already applies in toMetaGeoLocations, so what is stored equals what will run. Region/city/zip take Meta's platform KEY (a typed place name is a 400), with an optional label carried for display. Radius is capped per unit (50 mi / 80 km) in the input as well as the schema. The publish-readiness check and the ad-set card now count and describe every location kind rather than countries alone, mirroring assertRunnableTargeting. Country-only ad sets keep exactly the shape and default they had. | apps/web/src/components/performance/location-picker.tsx · apps/web/src/lib/ad-builder.ts · apps/web/src/app/(app)/projects/[id]/performance/campaigns/[campaignId]/page.tsx | Claude | | 2026-08-25 | fix | Every PATCH to an ad campaign was silently wiping its extra bag. adCampaignUpdateSchema was derived from adCampaignCreateSchema.partial(), and .partial() does NOT stop zod filling a .default() when the key is absent — the exact trap adTargetingPatchSchema was written to avoid, ten lines further down the same file. So a rename, an objective change, or a pause arrived at the domain carrying extra: {}, passed the input.extra !== undefined guard, and replaced whatever platform config the campaign held. Invisible until something read the column back. Fixed by deriving both shapes from an undefaulted adCampaignBase, the same way the targeting schemas already do. Found while wiring special ad categories, which store into extra — the bug would have turned a declared Housing campaign into an undeclared one on the next edit. | packages/contracts/src/ads.ts · regression test in apps/api/src/test/ads.test.ts | Claude | | 2026-08-25 | feat | Meta special ad categories. A campaign can now declare itself as Employment, Housing, Credit, or Social issues/elections/politics — the declaration Meta requires for regulated ads and rejects (or later takes down) a campaign for omitting. AdSpecialCategory is our vocabulary; adapters/meta-ads.ts::toMetaSpecialAdCategories owns the mapping to EMPLOYMENT/HOUSING/CREDIT/ISSUES_ELECTIONS_POLITICS, and none maps to the empty list Meta reads as "ordinary commercial ad". Stored inside AdCampaign.extra (no migration) but validated as a first-class contract field — "none" is exclusive, duplicates are refused. Defaults to ["none"], so every existing caller is unchanged. The declaration is pulled OUT of the adapter's generic extra passthrough before the body is built, so the raw internal value can never overwrite the mapped one; it is dropped entirely from updateCampaign, because Meta fixes the field at creation. The domain refuses to change it once a campaign has an external_campaign_id and points the user at Duplicate instead. Picker added to both campaign-creation paths (the hub modal and the 5-step wizard), locked with an explanation on a published campaign. | packages/contracts/src/ads.ts · apps/api/src/modules/ads/domain.ts · apps/api/src/modules/ads/adapters/meta-ads.ts · apps/web/src/components/performance/ad-campaign-form.tsx · apps/web/src/app/(app)/projects/[id]/performance/campaigns/new/page.tsx | Claude | | 2026-08-25 | feat | Duplicate an ad campaign. POST /ad-campaigns/:id/duplicate deep-copies a campaign — its ad groups, their ads, and the budgets still in force — in one transaction, and a Copy button on each row of the Google/Meta Ads campaign table calls it. The copy is deliberately inert: draft status on the campaign and every ad, blank external_campaign_id / external_ad_group_id / external_ad_id, no adapter call anywhere on the path. Duplicating a live campaign therefore cannot produce a second live campaign — the copy exists only in our database until someone runs the existing publish flow on it. Expired budgets are left behind (they describe spend the copy will never make); ad_creative_id is shared rather than duplicated, because creatives are project-owned and built for reuse. The audit row records duplicated_from, which is the question anyone reading that trail is actually asking. | apps/api/src/modules/ads/domain.ts::duplicateAdCampaign · apps/api/src/modules/ads/db.ts::findAdCampaignTree/createAdCampaignDeepCopy · apps/api/src/modules/ads/routes.ts · apps/web/src/lib/ads.ts::useDuplicateAdCampaign · apps/web/src/components/performance/ad-platform-hub.tsx | Claude | | 2026-08-25 | fix | The tracker key had no reader — the whole ingest side was unreachable. GET /projects/:id/tracker-key has minted a key on demand since E6, and nothing in the dashboard ever called it. The only tracker_key anywhere in the product was the literal trk_YOUR_KEY placeholder on the public /tracker docs page. Visits, visitor paths, attribution and conversions all depend on the snippet being live on the customer's site, and the snippet cannot be written without that value: the pipeline worked and nobody could switch it on. New Website tracker panel on the project Integrations page — the real key, the snippet with project_id, tracker_key and api_base already filled in, and a copy button. Rendered complete rather than as a template because every substitution error fails the same silent way: the tracker posts, the API rejects the key, and the dashboard goes on saying "no visits recorded", which reads identically to "nobody came". Three things are pinned by test for the same reason — api_base is the API origin, not the /api/v1 path axios uses (passing it through unchanged posts to /api/v1/api/v1/track/visit, a 404 on every pageview); the queue stub is defined before init runs, because the script tag is async and the first visits after an install are the ones that matter; and verjson('page') is present, without which an installed tracker records nothing at all. Owner/admin only — the key authorises writes into the project's traffic data — and the panel names the reason rather than looking broken. +7 tests. | apps/web/src/lib/tracker-key.ts + test, apps/web/src/app/(app)/projects/[id]/integrations/{tracker-panel.tsx,page.tsx} | Claude | | 2026-08-25 | fix | Approvals: a missing DEFAULT workflow was reported as a missing workflow, and could not be fixed from the UI. Two halves of one dead end, hit on production. submitForReview falls back to the project's default whenever a post is sent without naming one — which is what every button in the app does — so a project whose only workflow was not flagged default refused every submission. The 409 said "This project has no approval workflow yet", which was false: the workflow existed. That sent the reader to a settings page where everything looked correct and nothing explained the refusal, burning the one place they were going to look. The message now asks which case it is before choosing its words. The second half: the default flag was settable only at creation, and the table offered nothing but delete — so a single missed checkbox meant rebuilding the workflow and its stages by hand. PATCH /approval-workflows/:id already accepted is_default; it had no caller. Added useUpdateApprovalWorkflow and a Make default action in the Default column. Making one default un-flags the previous one server-side, so it is one click rather than a two-step swap. | apps/api/src/modules/approvals/domain.ts, apps/web/src/lib/approvals.ts, apps/web/src/app/(app)/settings/approvals/page.tsx | Claude | | 2026-08-25 | fix | A draft could not be deleted from the page that lists drafts. Delete lived only on the per-channel hubs — the one place you are not when clearing out drafts, since the sidebar's Drafts link lands on /content. Worse, a draft with no channel attached (which most are) had no hub to be found on at all, so it could not be deleted from anywhere in the app. Reuses DeletePostModal, so the published-vs-local distinction survives being reached from a second screen. The button is always visible rather than hover-revealed: hiding it is how it went missing in the first place, and on a touch screen there is no hover, so it would simply never appear. Only rendered when the reader can actually delete the post — caught in the browser, where a client user saw a Delete button on every row and got a 403 on click. canDeletePost mirrors posts/domain.ts::remove with tests that fail if the two drift. +7 tests. | apps/web/src/app/(app)/projects/[id]/content/page.tsx, apps/web/src/lib/post-permissions.ts + test | Claude | | 2026-08-25 | feat | Visitor paths — the report that was already in the database. The ask was heatmaps of where people go after clicking an ad. Half that question turned out to be answerable with no new capture at all: tracker.js fires verjson('page') on load AND on every SPA navigation, so the ordered page sequence of every visit has been landing in marketing_touchpoints this whole time, already joined to the ad campaign resolved from the UTMs at ingest. The only reader was /attribution/journeys, which demands a visitor_id and returns one person's timeline — a support tool, not a marketing one. New GET /projects/:id/attribution/paths and a /analytics/paths screen close that. Sessionising is where this kind of report goes quietly wrong, so it is a pure function (attribution/paths.ts) with every rule pinned by a test: consecutive duplicates collapse, because an SPA router that replaces state without changing the URL re-fires page and would otherwise make /pricing → /pricing the most common journey on the site; query strings and fragments are stripped so one page is one row rather than one row per ad variant; case is NOT folded, because plenty of servers treat /Pricing and /pricing as different documents; rows with no session_id fall back to the same 30-minute inactivity window the browser SDK uses, so the report cannot disagree with the tracker about what one visit is. The visit is credited to its FIRST touchpoint — the campaign that started it is the one whose money bought it — and the filters apply there too, so a visit that merely wandered through a campaign's landing page on its third page is not counted as something that ad bought. Leaving is an explicit edge (to_path: null) rather than an absence: on a real funnel the largest number is usually the people who left, and a chart that only draws where people WENT reads as though everybody went somewhere. A visit deeper than max_depth deliberately gets no exit edge — a phantom one would report people as having left while they were still reading. Read ceiling of 50k touchpoints, surfaced as truncated: true and as a banner, because a silently truncated report looks exactly like a complete one. UI is a drill-down rather than a Sankey: a Sankey looks impressive and you cannot read a number off it, and the number is the point. +33 tests (26 API incl. the pure sessioniser, 7 web). Verified against 116 seeded visits end to end — every reported figure matches the seeded journey weights. | apps/api/src/modules/attribution/{paths,routes}.ts, packages/contracts/src/attribution.ts, apps/web/src/lib/attribution.ts, apps/web/src/app/(app)/projects/[id]/analytics/paths/page.tsx, apps/api/src/test/attribution-paths.test.ts, docs/{API,FEATURES,VERIFICATION}.md | Claude | | 2026-08-24 | feat | A client can now pitch in from the calendar — propose a post and a date, without ever reaching the publisher. The ask was "can the client schedule something from their end"; the answer was no anywhere in the app, and the block was one org-role list (WRITE_ROLES = owner|admin|member) checked before project membership, so a client who was a project lead still got 403 on compose. Worse, the calendar UI had no role gating at all — a client reaching that URL saw the full compose and schedule controls and only found out on submit. Opening this up naively would break non-negotiable #3, because create flips variants to scheduled whenever a scheduled_at is present and the publisher acts on that with no reference to any approval. So the distinction the new gate draws is proposing vs scheduling: a client/agency post always lands draft, their chosen time is clamped out of scheduled_at and into the post's proposed_publish_at, and the publisher — which selects on a variant whose status is scheduled — structurally cannot see it. The suggestion becomes real when an approval lands and the existing scheduleApprovedPost promotes scheduledAt ?? proposedPublishAt; that plumbing was already there for calendar-import and agent drafts, so the round trip needed no new machinery. Scope beyond the org role: a proposer may only touch a post they authored, only while every variant is still in a proposal status (once the team schedules it, the content is under a decision already taken), and may withdraw their own — without that last one every mistake would need a team member. The project role stays the second lock, so a client invited as viewer proposes nothing; contributor is the deliberate act that lets them contribute. One new hole closed while opening this: an external contributor cannot decide on their own submission even when a client_review stage names them as an approver — propose-and-approve in two clicks makes the gate a formality for exactly the person it checks. Binds external roles only; an internal author who is also an approver is unchanged. Calendar-side: proposals now render on the grid (dashed, "Proposed — awaiting approval") because a suggestion that lives only in an approvals inbox is invisible on the screen the plan is actually read from — and a proposed date is suppressed once any variant carries a real scheduled_at, or the same post would sit on the grid twice at two different times with no way to tell which one the publisher will act on. The header button reads "+ Suggest a post" and the date modal "Propose date" for external roles. +14 API tests. | apps/api/src/modules/posts/{domain,db}.ts, apps/api/src/modules/approvals/domain.ts, apps/web/src/app/(app)/projects/[id]/calendar/[[...tab]]/page.tsx, apps/api/src/test/posts-proposals.test.ts, docs/{PERMISSIONS,FEATURES,VERIFICATION}.md | Claude | | 2026-08-22 | feat | Agents page + readable proposals — Batch A of the agents plan closes. Two UI halves of a gate that was already enforced server-side but unusable. (1) Proposals rendered as raw JSON. /approvals printed JSON.stringify(run.proposal) in a <pre>. For Scout and Ideator that was merely ugly; for the Drafter it defeats the gate — a five-draft proposal is ~80 lines of quoted JSON, and a human asked to approve that approves it without reading it, which is exactly the rubber-stamp the state machine exists to prevent. New lib/agent-proposals.ts turns each kind into prose: Scout → what it found + the angles it suggests; Ideator → each idea with hook/angle/why + target channels; Drafter → per-draft blocks with the script and caption side by side, under a one-line summary of what approving does ("Approving creates 2 draft posts on linkedin, instagram. They land as drafts — the usual client approval still runs before anything publishes"). Every parser degrades to null on an unrecognised shape and the page falls back to the JSON view: an unparsed proposal must look unparsed, because a confidently empty summary would understate what is being approved. (2) The launcher became a team. /agent was three numbered steps describing a pipeline; it is now one card per agent — what it does, when it last ran, and Run now — driven by lib/agent-roster.ts. Agents that aren't built (Optimiser, Planner, Site auditor) are listed visibly greyed with the reason, rather than hidden: hiding them makes the page look finished when it isn't. A gated agent explains its gate instead of offering a button that would produce a guaranteed failed run, and a gated agent with several approved parents gets one button per parent — which approved scout to build on is a real choice, not a default we should quietly make. +18 tests (agent-proposals.test.ts 10, agent-roster.test.ts 8) covering the fallbacks, the gates, newest-first candidate ordering and the last-run labels. Web 741/741. | apps/web/src/lib/{agent-proposals,agent-roster}.ts + tests, apps/web/src/app/(app)/agent/page.tsx, apps/web/src/app/(app)/approvals/page.tsx, docs/plans/2026-08-20-studio-agents.md | Claude | | 2026-08-21 | fix | Facebook post metrics returned nothing at all — one retired metric name was taking the whole row down. Reproduced against a live Page token, not inferred: GET /{post-id}/insights?metric=post_impressions,post_impressions_unique,post_clicks,post_reactions_by_type_total,post_engaged_users answers (#100) The value must be a valid insights metric on every API version from v19.0 to v23.0. Probing name-by-name showed Meta has retired post_impressions, post_impressions_unique and post_engaged_users at post level (also post_views, post_reach, post_activity, post_negative_feedback); post_clicks, post_reactions_by_type_total and post_video_views still answer. Graph rejects the entire request when any one name is invalid, so asking for two live metrics alongside three dead ones failed the whole call — and because an insights failure threw, the comment/share/reaction counts on the post object (which were answering fine the whole time) were never read either. Net effect: every Facebook analytics row blank. Three changes. (1) The metric list is now the verified-live set. (2) Impressions and reach are reported as undefined, not 0 — a zero is a claim ("nobody saw it"), undefined is the truth ("the platform stopped telling us"). (3) The two calls degrade independently: a 400 from insights (the shape a retired metric arrives in — no retry fixes it) leaves clicks blank, records extra.insights_unavailable = 1 for triage, and still returns comments/shares/likes; 401/403/429/5xx still throw, because those are account or transient problems where writing a half-empty snapshot and reporting success would stop the worker ever fetching the real numbers. Likes now prefer reactions.summary(true).total_count from the post object, which answers on Pages where the insights reaction metric returns an empty set. Verified end-to-end through the real adapter against a live post: {likes: 0, comments: 0, shares: 1} where the old code threw. +1 test, 2 rewritten. | apps/api/src/modules/channels/adapters/facebook.ts, apps/api/src/test/adapter-facebook.test.ts | Claude | | 2026-08-21 | fix | Facebook silently published one image out of however many you attached. Attach five images, approve the post, and the Page showed one — no error, no warning, nothing in the audit trail to say the other four were dropped. The adapter took mediaUrls[0] and discarded the rest, under a comment that said so out loud ("we disallow multi-image here; the first image wins"). A publish that loses content while reporting success is the worst shape this can take, because the post looks fine until someone opens the Page. Now 2-10 images build a real multi-photo post the way Graph requires: each image uploads to POST /{page-id}/photos with published=false (sequential, so a partial failure orphans as few unpublished photos as possible and doesn't burst Meta's per-Page upload limit), then one POST /{page-id}/feed carries them as attached_media[n]={"media_fbid": …}. A failed upload names its position (photo upload 2/5), releases the idempotency marker, and never publishes the partial post. Over ten images is refused with the count rather than trimmed. extra gained post_type: "multi_photo" + media_count; photo_id now only appears on the genuine single-photo path. Single-image and text/link paths are byte-identical to before. Verified the rest of the fleet while here: Instagram (real CAROUSEL, N children + parent) and LinkedIn (multi-image share) were already correct; Threads and Pinterest refuse multi-image with a clear message; X refuses all media (OAuth 1.0a signer still missing). Facebook was the only adapter losing data quietly. +3 tests (multi-photo call sequence + body shape, mid-sequence upload failure publishes nothing, >10 refused). | apps/api/src/modules/channels/adapters/facebook.ts, apps/api/src/test/adapter-facebook.test.ts | Claude | | 2026-08-21 | feat | The Drafter agent — and approval finally does something (agents plan, Batch A). Two halves of one gap. (1) approve() never applied anything. It moved a run to applied and returned, under a comment saying the apply was "the runner's job, dispatched after this commits" — and nothing dispatched it. Invisible for a year because both live agents (Scout, Ideator) produce text a human reads. New agents/apply.ts executes the approved proposal after the transition commits, and domain.approve records the outcome as an apply step. It never throws into the approver's request: the decision has committed and is not in doubt, so a downstream failure belongs in the run's step log (visible, retryable), not as a 500 on a POST whose primary effect succeeded — pinned by a test that forces the apply to blow up and asserts the run still reads applied with a failed apply step. apply.ts deliberately does not import domain.ts (step-writing stays in the caller) so the two can't form an import cycle. (2) The Drafter (content_draft). Third link in Scout → Ideator → Drafter; the chain previously dead-ended at ideas nobody turned into posts. Same parent gate as ideation and for the same reason — refuses unless the marketing_ideate parent is applied and same-org (a drafter with no approved ideas is the empty proposal the gate exists to prevent). Writes one draft per (idea, channel) pair, capped at 20 so a large idea list can't become a proposal nobody reads before approving; drafts for channels outside the approved ideas are dropped rather than quietly widening the blast radius. Fills the new Post.script alongside the caption, so the client approves the brief before anyone designs the graphic. Approving the writing is not approving the sending: applied drafts land as draft posts with no schedule and no proposed_publish_at, tagged agent-drafted with the run id in internal notes, and still go through the ordinary client-approval flow. Channel → account resolution is conservative — exactly one connected account attaches; zero or several creates the post with no variant and says so in the step log, because guessing between two connected brand accounts is worse than doing nothing. +10 tests (executor refusals incl. cross-tenant, "proposal written, zero posts created", apply-creates-drafts, ambiguous-channel, no-op apply for text-only kinds, apply-failure-keeps-approval). | apps/api/src/modules/agents/{apply.ts,kinds/content-draft.ts,domain.ts,execute.ts}, apps/api/src/test/content-draft.test.ts, docs/plans/2026-08-20-studio-agents.md | Claude | | 2026-08-21 | feat | Content-calendar bulk import — a month of planned posts from one CSV/Excel upload. POST /projects/:id/calendar-import (multipart) parses a planning sheet into draft posts. Two passes, one code path: dry_run=true (the default — a missing or garbled flag can never write) validates and returns a per-row preview; dry_run=false runs the identical validation and commits. All-or-nothing — one bad row refuses the whole file with every issue listed at once, because a half-imported calendar can't be told from a full one by looking, and re-uploading the corrected sheet duplicates whatever did land. Imported posts are DRAFTS carrying proposed_publish_at, never scheduled_at — nothing in the publish path consults the approval, so importing straight to scheduled would publish a month of unreviewed content on its dates. Fuzzy header matching (Publish Date / publish_at / publishat) with per-column aliases; platform aliases (twitter → x); bare dates read in the project's timezone via fromZonedTime, not UTC (09:30 IST is 04:00Z — getting this wrong shifts an entire calendar), and ExcelJS date cells normalised through the same path so .csv and .xlsx land on one timezone rule. Ambiguity is an error, never a guess: two connected accounts on one platform demands an account_handle column rather than picking a brand. Row cap 500, upload cap 5 MB, legacy .xls refused with a fix-it message, unknown columns reported rather than silently dropped. GET /calendar-import/template.csv generates the starter sheet from CALENDAR_IMPORT_COLUMNS so the template can't drift from the parser. New Post.script + PostRevision.script — the creative brief the client signs off on before graphics are produced; client-visible (it renders in the approval portal) unlike team-only internal_notes, and on CONTENT_FIELDS so editing it invalidates a live approval exactly like editing the caption does. UI at /projects/[id]/calendar/import — template download, file picker, preview table with per-row errors, and a commit button that only lights up when every row is clean. +29 tests (22 API across CSV/Excel/validation/commit/tenancy, 7 web helper). | apps/api/src/modules/calendar-import/{parse,domain,routes}.ts, apps/api/prisma/schema.prisma + migrations/20260821120000_post_script/, packages/contracts/src/{calendar-import,posts,post-revisions}.ts, apps/api/src/modules/posts/{domain,db,serialize}.ts, apps/web/src/lib/calendar-import.ts, apps/web/src/app/(app)/projects/[id]/calendar/import/page.tsx, apps/api/src/test/calendar-import.test.ts | Claude | | 2026-08-12 | fix | Uploaded media pointed at a host that no longer existed — breaking every thumbnail AND every publish. POST /uploads baked PUBLIC_API_URL into the returned url, and the composer persisted that whole object into Post.media_assets (JSONB). The moment the API's public host changed — a new dev tunnel, a prod cutover — every url ever stored pointed at a dead host, and nothing self-repaired because the value sat inside a blob nobody rewrites. Found live: assets carrying nitrogen-paperback-bouquet-arbor.trycloudflare.com and parameters-acoustic-donation-baptist.trycloudflare.com, both HTTP 000. The visible symptom was broken <img> tiles, but the expensive one was silent: posts/domain.ts hands mediaUrls straight to the adapters, and Meta and LinkedIn fetch those URLs server-side to ingest media — so a publish with a stale host fails at the platform, not in our logs. The url is now derived, never trusted: new core/media.ts owns mediaUrlForKey + withFreshMediaUrls, and the posts serializer rebuilds every media_assets / platform_media entry from its durable S3 key on read. Existing rows heal with no migration. The same helper now backs the upload response and the publish path, which had each grown their own copy of the URL shape. Verified on a real asset: frozen url → HTTP 000, key-derived url → HTTP 200, 2.6 MB image/jpeg. | apps/api/src/core/media.ts, apps/api/src/modules/posts/{serialize,domain}.ts, apps/api/src/modules/uploads/routes.ts | Claude | | 2026-08-12 | fix | The composer described every platform as if it were LinkedIn. Three bugs from one cause — LinkedIn was the first adapter, and its assumptions were left hardcoded. (1) A Visibility select reading "Public — anyone on LinkedIn" / "Connections only" rendered on every composer, including Instagram's, where it offered a choice that does nothing and named the wrong network doing it; visibility maps to LinkedIn's MemberNetworkVisibility and is read by exactly one adapter. It now renders only when a LinkedIn account is targeted, and default_platform_extra stops stamping the field onto non-LinkedIn variants. (2) The media cap was a hardcoded 20 attributed to LinkedIn — wrong for every platform including LinkedIn (9). The composer accepted 20 assets, warned about nothing, and the server normaliser then clipped to the real per-platform max at publish time, so the post that went out was not the post that was composed. Both guards and the (n/20) header now read PLATFORM_MEDIA_SUPPORT — the same table the normaliser clips against — and the error names the actual platform. (3) Link-preview copy generalised. | apps/web/src/app/(app)/projects/[id]/organic/[platform]/composer-modal.tsx | Claude | | 2026-08-12 | fix | Videos rendered as an identical grey glyph everywhere. The media library, the composer's Recent strip, its attached-media grid and the preview panel each drew a bare camera icon for any non-image asset — so a project with six clips showed six identical tiles, and a visual picker you cannot pick from is not a picker. All four now render the asset itself with preload="metadata", which fetches the container header and first frame only (no full download) and lets the browser paint a real poster. muted + playsInline stop mobile Safari hijacking a tile into fullscreen playback; the icon survives as an overlay so an undecodable codec still reads as a video. | apps/web/src/app/(app)/projects/[id]/measure/media/page.tsx, apps/web/src/app/(app)/projects/[id]/organic/[platform]/composer-modal.tsx | Claude | | 2026-08-12 | fix | Next 16 stopped suppressing smooth scrolling during route transitions, so every sidebar click glided to the top instead of landing there. The app sets scroll-smooth on <html> for the landing page's anchor navigation. Next ≤15 silently forced scroll-behavior: auto for the duration of a navigation; Next 16 dropped that override (it cost a style write per navigation) and made it opt-in. Restored with data-scroll-behavior="smooth" on <html> — the documented replacement, per node_modules/next/dist/docs/01-app/02-guides/upgrading/version-16.md. The dev server had been logging the warning on every navigation. | apps/web/src/app/layout.tsx | Claude | | 2026-08-12 | fix | Disconnecting a social account no longer deletes its analytics. DELETE /social-accounts/:id called prisma.socialAccount.delete(), and PlatformPost.socialAccount is onDelete: Cascade — so every published post through that account, plus every PostMetricSnapshot, PostMetricDaily and AccountMetricSnapshot under it, was destroyed. The confirm dialog said "Draft and scheduled posts to it will be removed too", which described a fraction of what actually went. Disconnect is now a state change: credentials are wiped, connection_status flips to disconnected with a new disconnected_at stamp, and nothing historical is touched. That status is already what a worker sets when a token dies, so metrics/inbox/publish consumers skip it with no new concept. Scheduled variants pause rather than fail — findDueScheduled / findDueRetries now exclude disconnected accounts, because dispatching without credentials could only burn the 5-attempt retry budget and land the post in terminal failed; they resume on reconnect. Reconnect revives the same row: the manual path used to 409 on the composite unique, so the OAuth upsert (which already revived) and the manual path disagreed; both now clear disconnected_at and the published history reattaches by id. New posts to a dormant account are refused 422 at the domain rather than queued as work that can never run, and the composer's channel list filters through a new isPublishableAccount. Permanent deletion survives as an explicit ?purge=true (204, still cascades) behind a confirm that names what it erases; the default control is an unplug icon, and a dormant account carries a "Disconnected · analytics kept" badge. Browser verification caught a real bug in this change: the first cut filtered the analytics panels through publishableAccounts too, so a disconnected account rendered "No Instagram account to analyse yet" — exactly the failure the work set out to fix. +5 API tests. | apps/api/prisma/schema.prisma, apps/api/src/modules/social-accounts/{domain,db,routes}.ts, apps/api/src/modules/publisher/db.ts, apps/api/src/modules/posts/{domain,db}.ts, apps/api/src/modules/channels/routes.ts, apps/api/src/modules/{metrics/worker,inbox/polling,inbox/reply}.ts, apps/api/src/test/social-accounts.test.ts, packages/contracts/src/posts.ts, apps/web/src/lib/social-accounts.ts, apps/web/src/app/(app)/projects/[id]/organic/{[platform]/[[...tab]],instagram/[[...tab]]}/page.tsx, apps/web/src/components/organic-hub-tiles.tsx | Claude | | 2026-08-11 | feat | AEO Competitors tab — the last stub on the hub (E7 tail). Ships on the AIAnswerSource rows recorded earlier the same day, so it needed no new backend: every check already stores the full ranked source list an engine used, and the competitor set is just that grouped by domain. The peer set is observed, not typed. A hand-maintained competitor list names the rivals you already know about; this one names whoever keeps turning up in the answers to your prompts, which is a different and more useful set. Deliberately distinct from the SEO hub's share-of-voice — a domain can own the AI answer while ranking nowhere on Google. Two tables. Your domains always renders one row per tracked domain including when it was never cited (bestPosition: null → "not cited"): the previous empty-state rollup could only list domains that were actually cited, so a project nobody cites vanished from its own report and the reader hunted for a row that was never going to exist. Who you are up against ranks by engine breadth before raw volume, with share drawn against 100% of all observed sources rather than leader-relative, so a flat field reads as flat instead of making its top row look commanding. New pure ourStanding (+5 tests) and a sharePct on the existing rollup. A test caught the domain normaliser matching only www. and not a scheme — https://www.example.com would have been reported as "not cited" while its citations sat in the table; it now strips scheme, path, query, port and trailing dot. Verified live: 138 observed sources, 51 domains, verjson.com and verjson.ai both listed at 0.0% / not cited, arxiv.org and huggingface.co tied at 15.9% across 4 and 3 engines. IA flipped competitors to implemented: true; tab hint "Soon" → "Live". | apps/web/src/app/(app)/projects/[id]/performance/aeo/{competitors-tab.tsx,[[...tab]]/page.tsx}, apps/web/src/lib/{growth-helpers,growth-helpers.test,project-ia}.ts | Claude | | 2026-08-11 | fix | The AEO citation tracker never actually ran on its own (E7 tail). The worker scheduled its first sweep one full interval out — setTimeout(runTickSafe, 24h) — so the timer restarted from zero on every deploy and every dev-server reload. A day of work produced 30 worker starts and 0 sweeps, and the only symptom was a UI that said "not checked yet" forever; every result seen so far had been triggered by hand. Any restart cadence faster than the interval means the sweep never fires at all, which for a daily deploy is "never", silently. Same shape sits in the backlinks worker (7-day interval) — flagged, not touched here. Fixed by moving the schedule off process uptime and onto the data: first sweep 30s after boot, interval 24h → 1h. The interval was conflated with "how often to ask an engine"; it only controls how often we go LOOKING for due work, and each prompt's own checkFrequency + lastCheckedAt still decides whether anything is actually asked, so a short interval costs nothing when nothing is due. Adding a prompt now checks it immediately — a prompt is an explicit "tell me about this", and waiting a scheduled sweep for the first answer was never right. New runCheckForPrompt / requestImmediateCheck (fire-and-forget: four engines take ~30s, far too long to hold a request open) behind POST /growth/projects/:projectId/prompts/:id/check → 202, owner/admin only, 409 on a disabled prompt, 404 cross-project. requestImmediateCheck is a no-op under NODE_ENV=test — a detached write would otherwise land after the case that triggered it, racing the next case's TRUNCATE; tests drive runCheckForPrompt directly. UI: per-prompt "Check now" button and a "checking all engines…" state on the row, with the prompts list and both feeds polling at 5s only while a check is in flight. The first cut of that state compared Date.now() in the browser against the server's last_checked_at and hung forever — the server stamps from its own clock, so the value never "overtakes" a locally-taken timestamp. Now it records the last_checked_at visible at request time and waits for it to change, comparing a server value against the same server value. A matching attempt to stamp the row on completion instead was reverted: it broke the tick's injectable clock and two deterministic tests with it, and the change-detection made it unnecessary. +6 API tests. | apps/api/src/modules/growth/{ai-citations,routes}.ts, apps/api/src/main.ts, apps/api/src/test/growth-ai-citations.test.ts, apps/web/src/lib/growth.ts, apps/web/src/app/(app)/projects/[id]/performance/aeo/citations-tab.tsx | Claude | | 2026-08-11 | feat | AEO: record who did get cited, and stop showing an empty box (E7 tail). Found by using the feature: a real tick ran 16 live checks against four answer engines, found no citation of the tracked domain, and the UI showed the same "No citations yet" it shows before anything has ever run. Two defects behind one symptom. (1) The paid-for answer was being thrown away. The tick only wrote a row if (result.cited), so a check that found nobody stored nothing — despite the provider having just told us the full ranked source list. The project learned nothing and the next check would pay to rediscover the same thing. New AIAnswerSource model records every URL an engine leaned on: model · checked_at · url · domain (bare host, www. stripped — the grouping key) · title · position (the engine's own ranking; source 1 is not source 9) · is_expected, denormalised on purpose so a past observation keeps reporting what was true when it was made even after the expected-domain list is edited. Written by the same tick via one createMany, mock path included, and exposed as GET /growth/projects/:projectId/answer-sources?prompt_id=&model=&from=&to=. (2) "Never checked" and "checked and lost" rendered identically. The empty state now branches: with no observations it says Not checked yet and names the cadence; with observations it says "Checked 4m ago — you weren't cited" and renders Who owns this answer — a per-domain rollup of engines / citations / best position, with the project's own domains marked (you). Ranked by engine breadth before raw volume, because three engines citing you once is a stronger position than one engine citing you three times, and sorting on count alone hides that. New pure helpers summariseAnswerSources + lastCheckedAtFrom (6 web tests) and toAnswerSources (4 API tests). Verified live: a check on "Best AI platform for agriculture and crop management" stored 23 sources across 4 engines and put cropin.com — the domain already tracked as a competitor on the SEO side — at the top with 2 engines and 3 citations. Also fixed a lost space around the em dash: JSX trims line-end whitespace between text and expressions, so the banner rendered "Checked 4m ago— you"; built as one template string instead. Not in scope: the Competitors tab still stubs — this ships the data it needs, not the tab. | apps/api/prisma/schema.prisma, apps/api/src/modules/growth/{ai-citations,routes}.ts, apps/api/src/test/{growth-answer-engines.test.ts,setup.ts}, packages/contracts/src/ai-citations.ts, apps/web/src/lib/{growth,growth-helpers,growth-helpers.test}.ts, apps/web/src/app/(app)/projects/[id]/performance/aeo/citations-tab.tsx | Claude | | 2026-08-11 | fix | Lint back to zero errors (4 pre-existing failures). npm run lint had been failing, which meant npm run verify could not pass at all. (1) youtube.ts hid a zero-width space (U+200B) inside `bytes *​/{total}` so the literal would not close its own block comment — invisible, and no-irregular-whitespace rightly objected. Replaced with a plain-ASCII *\/ escape and a note saying why the backslash is there. (2) Unused beforeEach import in ai.test.ts. (3+4) Two setState-synchronously-in-an-effect errors from the campaign-wizard work (wizard-modal.tsx, calendar/[[...tab]]/page.tsx) — both the "reset form state when the modal opens" pattern. Converted to React's documented adjusting-state-during-render form, comparing against the previous open value: React re-runs the component immediately and never commits the stale values, so the field is filled on the first painted frame instead of flashing empty. Behaviour is otherwise identical, and the wizard is no longer reset by a defaultStartDate change while it is already open — the old effect listed it as a dependency, so a parent updating that prop mid-edit would have wiped whatever the user had typed. Browser-verified: opening the wizard from a day cell prefills that date (2026-08-20), cancelling and opening a different day resets the step, clears typed input, and shows the new date (2026-08-03); the schedule modal opens pre-filled with the next round hour. | apps/api/src/modules/channels/adapters/youtube.ts, apps/api/src/test/ai.test.ts, apps/web/src/components/campaigns/wizard-modal.tsx, apps/web/src/app/(app)/projects/[id]/calendar/[[...tab]]/page.tsx | Claude | | 2026-08-11 | feat | AEO citation tracker now measures reality (E7 tail). fetchAICitationFromProvider had been a throw since the tracker shipped, so every citation in the UI came from checkAICitationMock — a SHA-256 dice roll (30% hit / 15% competitor / 55% miss). Plausible fiction, correctly labelled as such internally, but nothing anyone could report on. It now asks real answer engines real questions. One provider, four engines — everything goes through OpenRouter (OPENROUTER_API_KEY), whose OpenAI-compatible endpoint fronts every model, so measuring four engines costs one integration and one account instead of four. Search is the whole point: a plain chat completion answers from the model's weights and cites nothing, which would read as "nobody cites you" on every prompt. Requests append the :online suffix to buy web search (native for OpenAI/Anthropic/Google, Exa fallback otherwise); Perplexity's Sonar searches natively and is deliberately not given the plugin, which would pay for search twice. Citations arrive as structured url_citation annotations — URL, title, excerpt, order — so cited_url / cited_text / position are read off the provider's own data rather than regexed out of prose. New answer-engines.ts owns the HTTP call and the engine→slug map; the reader (interpretAnswerForCitation) is pure and lives beside the mock it replaces. Domain matching treats subdomains as the tracked domain (blog.example.com cites example.com) with a dot-boundary check so notexample.com does not match, and ignores www./case. An engine that names the domain in prose with no annotation attached still counts — cited_url stays null because there is no URL to record. Stored ids are now the ENGINE, not the model version (chatgpt · claude · gemini · perplexity, was gpt-4o · claude-3-5-sonnet · gemini-1.5-pro · perplexity-online): the customer's question is "does ChatGPT cite us", and engine identity is the only thing stable enough to chart once the underlying model is replaced. Rows written before the switch keep deserialising (model is a free z.string()) and render through a neutral-badge fallback. Two guards. config.growth.aiCitationsMockMode is forced on under NODE_ENV=test — the repo-root .env is injected into the test run, so without it npm test would make live billable calls the moment anyone configured a key (this was caught by a suite that started taking 30s and hitting the network). And AI_CITATIONS_MAX_CALLS_PER_TICK (default 200) caps a tick on a whole-prompt boundary, logging what it deferred rather than silently truncating. Slug selection is evidence-based, not vibes: a live smoke found google/gemini-3.6-flash:online returns HTTP 200, a good answer, and zero annotations — which this tracker would have faithfully recorded as "Gemini never cites anyone". 3.5-flash and 3-flash-preview do the same. Gemini therefore sits on 2.5-flash (5 annotations, verified); the finding and the full measurement table are written into answer-engines.ts so nobody "upgrades" into a silent false negative. New npm run smoke:engines --workspace @verjson/api re-runs that check and exits non-zero if any engine returns no sources. +17 API tests over the reader, the annotation parser, the domain matcher and the test-mode guard. | apps/api/src/modules/growth/answer-engines.ts, apps/api/src/modules/growth/ai-citations.ts, apps/api/src/core/config.ts, apps/api/scripts/smoke-answer-engines.ts, apps/api/src/test/growth-answer-engines.test.ts, packages/contracts/src/ai-citations.ts, apps/web/src/lib/growth-helpers.ts, apps/web/src/app/(app)/projects/[id]/performance/aeo/citations-tab.tsx, .env | Claude | | 2026-08-10 | feat | Campaign creation wizard + calendar click-to-schedule (F-023 · F-021 · F-024). New 4-step wizard replaces the single-page create modal: Step 1 (Type) picks one of organic · paid · mixed · influencer · event · launch · other — a shape hint that steers the wizard but never restricts what a campaign can do; Step 2 (Basics) captures project, name, one-line objective, brief, start & end dates; Step 3 (Channels) shows the project's marketing mix pre-filtered by the type hint (an organic campaign hides paid-only channels behind a "Show all" toggle, paid hides organic ones, mixed/other show everything) — the "channels must subset the project's mix" server rule remains the only hard constraint; Step 4 (Review) is a one-glance summary before create. New CampaignType Prisma enum (campaign_type) + type column on campaigns with default(other) so old rows read back cleanly; contract adds CAMPAIGN_TYPES, campaignTypeSchema, CAMPAIGN_TYPE_META, and threads type through create + update + read schemas + serializer. Calendar hook-up — each day cell in the project month grid is now a clickable button that opens the wizard with defaultStartDate pre-filled to that day (an absolute-positioned button sits behind the scheduled-post cards, z-0, so post-card clicks still land on the card — anywhere else in the cell opens the wizard). A "+ New campaign" button lives in the calendar header for the no-date case. Same wizard powers the org-wide /campaigns page — the older create-modal.tsx stays in the tree unused for a beat before deletion so a rollback is one import swap. 5 new API vitest cases: create defaults type to other, explicit type persists, unknown type is 422 at the contract layer (not silently coerced), update accepts a type change. Zero web unit-test churn — the wizard is a composition on top of the already-tested useCreateCampaign hook + ChannelPicker. | packages/contracts/src/campaigns.ts, apps/api/prisma/schema.prisma, apps/api/src/modules/campaigns/{domain,serialize}.ts, apps/api/src/test/campaigns.test.ts, apps/web/src/components/campaigns/wizard-modal.tsx, apps/web/src/app/(app)/campaigns/page.tsx, apps/web/src/app/(app)/projects/[id]/calendar/[[...tab]]/page.tsx | Claude | | 2026-08-10 | feat | Real Google Ads, Meta Ads, X and YouTube adapters (PR #116). Four adapters moved from "shell + mock" to platform-real. Google Ads — updateCampaignBudget resolves each campaign's shared campaign_budget resource via googleAds:searchStream, then mutates amount_micros (daily) or total_amount_micros (lifetime) with the right update_mask; updateAdBid reads each ad group's cpc_bid_micros, scales by multiplier, floors at 1, and refuses if no ad group under the target carries a manual bid (ad groups on automated bidding are skipped — silently doing nothing would let an approved proposal report success having moved no spend). New minorToMicros bridges our minor-units convention to Google's micros. Meta Ads — updateCampaignBudget writes daily_budget/lifetime_budget on the campaign (CBO-only; without Advantage campaign budget Meta keeps money on the ad set and 400s, mapped to invalid_request); updateAdBid scales each ad set's bid_amount, again skipping automatic-bid ad sets and throwing when nothing manual remains. X (Twitter) — OAuth AUTHORIZE_URL moved to x.com/i/oauth2/authorize; the legacy twitter.com host 302s to x.com and the browser drops the OAuth session across the redirect, yielding X's generic "You weren't able to give access to the App" page (server-to-server calls remain on api.twitter.com). YouTube — real-mode video publish via Google's resumable-upload protocol: session-init POST with X-Upload-Content-Length returns an opaque Location URL; 8 MiB PUT chunks with Content-Range; resync off Google's Range: bytes=0-{n} header rather than trusting our own cursor; 5xx-per-chunk retry via a bytes */{total} status probe, capped at MAX_CHUNK_ATTEMPTS=3. Reused for later videos: checkAndRemember/rememberSuccess/forget idempotency. Title floored at 100 chars, description at 5000, default category 22 ("People & Blogs"). Optimisation-proposal apply now uses real tokens — ads/proposals/domain.ts::apply reads the ad account's encrypted oauthAccessToken via decryptToken(...) and passes it to the adapter, falling back to the literal "mock-token" (which mock adapters ignore) only when the account has none; a real adapter handed that literal correctly fails at the platform with a 401, so a never-authorised account no longer reports a phantom success. Connect-guide for YouTube rewritten to flag the two real ceilings: unaudited apps have every upload forced to private regardless of request, and the daily 10 000-unit quota means ~6 real publishes/day (uploads cost 1 600 units each). +512 lines of new tests across adapter-google-ads.test.ts (new, 151 lines), adapter-meta-ads.test.ts (new, 125 lines), and adapter-youtube.test.ts (+236 lines exercising the resumable-upload happy path, non-256 KiB-aligned chunking, 5xx-then-resume, and quota-exceeded surface). 1 189 insertions / 61 deletions across 12 files. F-043 · F-050 · F-051 · F-056 flipped 🔲 → 🟡. | apps/api/src/modules/ads/adapters/{google-ads,meta-ads}.ts, apps/api/src/modules/ads/proposals/domain.ts, apps/api/src/modules/channels/adapters/{x,youtube}.ts, apps/api/src/modules/channels/bootstrap.ts, apps/api/src/core/config.ts, apps/api/src/test/adapter-{google-ads,meta-ads,x,youtube}.test.ts, apps/web/src/lib/connect-guides.ts | Claude | | 2026-08-05 | feat | Campaign → post → calendar loop closed (PR #93). Data model already had Post.campaign_id (Prisma FK, contracts, GET /posts?campaign_id= filter, calendar badge) but the UI never let a user tag a post to a campaign, and /campaigns/[id] was four PlaceholderCard "COMING UP" tiles. Now: composer has a Campaign <select> above Visibility+Schedule (filters out archived+completed; new defaultCampaignId prop for pre-tagged callers); /campaigns/[id] shows a real rollup — scheduled posts with status pills + relative datetimes + link into the filtered calendar, plus an ad-launches pointer card; calendar reads ?campaign=<id>, threads it to usePosts, renders a visible primary-tone filter chip with a Clear link, preserves the query param across Month/Week/Content/Ads view flips. Zero backend change — endpoint already accepted the filter. 247 / 30 lines across 3 files. | apps/web/src/app/(app)/campaigns/[id]/page.tsx, apps/web/src/app/(app)/projects/[id]/calendar/[[...tab]]/page.tsx, apps/web/src/app/(app)/projects/[id]/organic/[platform]/composer-modal.tsx | Claude | | 2026-08-05 | fix | First-run path repaired — signup, lint, and the documented setup command (B-011…B-014). Found by running the app rather than the suite: every one of these sits on signup → login → first project, and none was caught by ~2,100 green tests. B-011 (blocker) — POST /auth/signup-with-org set user.role = "owner" but never wrote the UserRoleAssignment the policy engine actually reads, so every real signup produced an owner with zero permissions and no in-app way out. The legacy POST /auth/signup had the write; the Better-Auth cutover added a second path and the E12 RBAC slice only back-filled the first. Test helpers sign up through the legacy route, which is why the suite stayed green. Fixed inside a transaction with compensating deletes, and covered by a new suite that asserts the resulting permission set (3 of 4 cases fail against the old code). B-012 — /login hydration error from a render-time window feature-detect. B-013 — db:push/seed failed from a clean clone because nothing bridged the root .env to apps/api; new prisma.config.ts (which also retires the deprecated package.json#prisma block) plus --env-file-if-exists on the tsx scripts. B-014 — lint was failing with 14 errors against a documented "0 errors": 7 were the Hono boundary rule's allowlist matching only the bare filename routes.ts while modules had split into *-routes.ts siblings; the code was right and the rule was stale. New npm run rbac:backfill supplies the script the API's own boot warning had been telling people to run since 2026-08-04. | apps/api/src/modules/auth-v2/routes.ts, apps/api/src/test/signup-with-org.test.ts, apps/api/prisma/{backfill-rbac.ts}, apps/api/prisma.config.ts, apps/api/eslint.config.mjs, apps/api/package.json, apps/web/src/app/(auth)/login/login-form.tsx, apps/web/src/lib/auth-passkey.ts, docs/{BUGS,VERIFICATION,STATUS}.md | Claude | | 2026-08-05 | feat | Per-project Integrations hub + Activity feed + KPIs redirect (batch 20 T1, PR #91). New /projects/:id/integrations unifies the 5 shipped connection hooks (social / ad / analytics / slack / webhook) into a single hub with status pills + Manage/Reconnect/Connect CTAs — client-side union, no new backend. New /projects/:id/activity per-project audit feed backed by a project_id query filter added to /audit-logs (matches entity_id = projectId OR meta.project_id = projectId — pragmatic over an FK-column migration). /projects/:id/kpis → server-side redirect to /analytics; KPIs section relabelled "KPIs & Analytics" for clarity. +14 web + 1 API tests → 514 web green. | apps/web/src/app/(app)/projects/[id]/{integrations,activity,kpis}/page.tsx, apps/web/src/lib/{integrations-hub,project-activity}.ts, apps/api/src/modules/audit/routes.ts | Claude | | 2026-08-05 | feat | URL-routed section tabs (batch 20 T2, PR #90). 8 sections converted to Next 16 optional-catch-all [[...tab]]/page.tsx (Organic hub, SEO, AEO, Google Ads, Meta Ads, Campaigns, Calendar, Approvals). Sidebar now renders children as nested links driving the active tab from params.tab[0] — ~50 previously-placeholder child slugs stop hitting the "Building this next" catch-all and open the correct tab instead. AdPlatformHub converted to controlled tab state so Google + Meta Ads share the same component with URL-driven active-tab. Approvals gained a live-count filter bar. New pure apps/web/src/lib/section-tabs.ts — tabForChildSlug / defaultTabFor / isValidTabForSection. +19 helper tests → 442 web green. | apps/web/src/app/(app)/projects/[id]/{organic,performance/{seo,aeo,google-ads,meta-ads},performance/campaigns,calendar,approvals}/[[...tab]]/page.tsx, apps/web/src/lib/section-tabs.ts, apps/web/src/components/app-shell/sidebar.tsx | Claude | | 2026-08-05 | feat | Connection health helpers + audit-feed polish (batch 20 T3, PR #89). Pure apps/web/src/lib/connection-health.ts — computeConnectionHealth(input, now) classifies every shipped connection kind (social / ad / analytics / slack / webhook) into a discriminated union healthy / degraded(reason) / failed(reason) / not_connected from the wire-shape rows the existing hooks already return; reads SocialAccountRateLimit (batch 13) when passed alongside a SocialAccount; terminal token failures short-circuit rate-limit branch; analytics stale threshold 24h; webhook degrades above 3 consecutive failures. Presentation helpers healthTone, healthLabel, healthActionCta, formatRetryAt. New <ConnectionHealthPill> component. Settings audit page rewritten with chip multi-select filters, preview drawer (click row to open, Escape closes), and CSV export (current page or walked cursor to 32-page cap). New apps/web/src/lib/audit-helpers.ts — diff extraction, RFC-4180-ish CSV quoting, multi-select serialisation, useDebouncedValue. +77 web helper tests → 500 web green. | apps/web/src/lib/{connection-health,audit-helpers}.{ts,test.ts}, apps/web/src/components/{integrations/connection-health-pill,audit/*}.tsx, apps/web/src/app/(app)/settings/audit/page.tsx | Claude | | 2026-08-05 | feat | E5 — GA4 + Google Search Console ingestion + cross-source reconciliation (batch 19 T1). Closes the three 🔲 rows on E5 (GA4, GSC, reconciliation). New Prisma models AnalyticsProviderConnection (project × provider × externalPropertyId — provider enum ga4/gsc; AES-256-GCM tokens via core/crypto purpose analytics-oauth; status enum connected/token_revoked/disabled) + AnalyticsMetricSnapshot (per-day per-dimension; nullable GA4 columns + nullable GSC columns; unique [connectionId, day, dimension, dimensionValue]). Two new NotificationKinds (analytics_provider_connected, analytics_token_revoked) wired in all four spots (Prisma enum + packages/contracts/src/notifications.ts + tray + KIND_META/CATEGORIES under new "Analytics" bucket). New module apps/api/src/modules/analytics/ — mock-first AnalyticsAdapter interface + registry (kept distinct from channel-adapters); adapters/ga4.ts (Data API v1beta runReport per-dimension × 3 + Admin API v1beta accountSummaries) + adapters/gsc.ts (Search Console v3 sites + searchAnalytics/query) both behind mock-vs-real factories (identical pattern to modules/ads/adapters/google-ads.ts) that fall back to SHA-256-seeded deterministic mocks when ANALYTICS_MOCK_MODE=1 OR when GOOGLE_ANALYTICS_CLIENT_{ID,SECRET} are unset; oauth.ts with analytics-oauth audience distinct from channel-oauth (no cross-flow replay). New endpoints (per-route requireAuth, mounted at /): GET /projects/:id/analytics-connections, POST /oauth/analytics/:provider/start, GET /oauth/analytics/:provider/callback (public — signed state carries userId; upserts on (project, provider, NULL) since Postgres treats NULL distinct in unique indexes → manual find+update+create), GET /projects/:id/analytics-connections/:cid/properties, POST /projects/:id/analytics-connections/:cid/properties/select, DELETE /projects/:id/analytics-connections/:cid, GET /projects/:id/analytics-metrics?provider=&from=&to=&dimension=, GET /projects/:id/analytics-reconciliation?from=&to=. Ingestion worker startAnalyticsWorker — 6h tick with 1h per-connection min-interval; pulls yesterday's day; token_revoked/token_expired → sole-writer updateMany on status=connected to token_revoked + one-shot analytics_token_revoked notification to connectedByUserId; rate_limited/invalid_request stash lastError but keep status connected; skip-in-test. Pure computeReconciliation walks four sources — GA4 (per-day sessions/conversions/revenue rolled from source dimension), GSC (per-day impressions/clicks), platform-native (PostMetricDaily engagements + impressions + clicks across every social account on the project), attribution (batch 17 T1 AttributionCredit model=last_touch → conversions + revenue = valueMinorUnits/100) — emits per-(day, metric) rows with drift_pct = (max-min)/max and drifted flag on drift_pct > 0.15 (config default). UI shipped at apps/web/src/app/(app)/projects/[id]/performance/analytics-providers/page.tsx — connection cards per provider (empty state + status pill + "Connect GA4" / "Connect Search Console" CTAs), property-picker modal (post-connect + change), metrics table with dimension/provider filters, reconciliation table with drift ribbon + per-row severity badge. New apps/web/src/lib/analytics-providers.ts with hooks + pure classifiers (driftSeverity, providerDisplayName, dimensionLabel, formatMetricValue, reconciliationSourceLabel). Sidebar entry flipped implemented: true in project-ia.ts. +89 API vitest cases (analytics-oauth, analytics-ga4, analytics-gsc, analytics-worker, analytics-routes, analytics-reconciliation) + 19 web helper tests. Non-scope: no GA4 real-time endpoint, no custom-dimension support (three GA4 defaults hard-coded), no cross-provider visitor dedup, no Looker export, no GA4-window attribution model overrides. | apps/api/prisma/schema.prisma, apps/api/src/core/config.ts, apps/api/src/modules/analytics/**, apps/api/src/test/analytics-*.test.ts, apps/api/src/test/setup.ts, apps/api/src/{app,main}.ts, packages/contracts/src/{analytics,notifications,index}.ts, apps/web/src/app/(app)/projects/[id]/performance/analytics-providers/page.tsx, apps/web/src/lib/{analytics-providers,analytics-providers.test,notifications,project-ia}.ts, apps/web/src/components/notification-tray.tsx, docs/CHECKLIST.md | Claude | | 2026-08-04 | feat | E12 — WebAuthn / passkeys + full MFA settings UI (batch 14 T2). Closes the two ⬜ rows on E12: passkeys as a second-factor option and the Settings → Security UI panel for both TOTP and passkeys. @simplewebauthn/server@^10 on the API, @simplewebauthn/browser@^10 + qrcode.react@^4 on the web. New Prisma model UserWebAuthnCredential (base64url credentialId + Bytes COSE public key + monotonic signCount for anti-clone + transports[] + deviceType + backupState + user nickname + lastUsedAt). New RP config in core/config.ts (WEBAUTHN_RP_ID, WEBAUTHN_RP_NAME, WEBAUTHN_ORIGINS). New backend module apps/api/src/modules/mfa/webauthn/* — challenge-cache.ts (in-memory 5-min TTL, consume-once, hourly unrefed sweep; single-replica caveat documented for a Redis follow-up), db.ts (sole-writer signCount update via signCount < newCount filter — race-safe against browser retries), domain.ts (start/finish registration + authentication + list/rename/delete). New endpoints (per-route requireAuth, mounted at /): POST /mfa/webauthn/register/{start,finish}, POST /mfa/webauthn/authenticate/{start,finish} (mints a satisfied-token with method="webauthn" reusing batch 12 T1's mfa-satisfied audience), GET /mfa/webauthn/credentials, PATCH /mfa/webauthn/credentials/:id (rename), DELETE /mfa/webauthn/credentials/:id?force=true (409 on the last MFA factor unless force; a forced last-factor removal also fires mfa_disabled audit + notification, mirroring the TOTP disable path). Extended POST /mfa/challenge/verify — Zod-refined mutex between code and webauthn_response; a passkey now satisfies the step-up gate without a separate flow. New POST /mfa/recovery-codes/regenerate — gated by requireMfa so a compromised session can't invalidate the owner's real recovery codes. GET /mfa/status now includes webauthn_credentials_count. Full audit trail: webauthn_credential_registered/_removed, webauthn_registration_failed, webauthn_authentication_{succeeded,failed}, mfa_recovery_codes_regenerated. Two new NotificationKinds + tray records (Shield): webauthn_credential_added / webauthn_credential_removed. UI shipped at apps/web/src/app/(app)/settings/security/{page,totp-panel,passkeys-panel}.tsx — Passkeys panel with add via SimpleWebAuthn browser flow + inline rename + delete-with-confirm; TOTP panel with modal QR enrollment (qrcode.react), one-time recovery-code reveal panel, disable flow, and a regenerate flow that runs the challenge/verify dance in-line before hitting the requireMfa-gated endpoint. New hook file apps/web/src/lib/mfa.ts (mirrors lib/api-keys.ts style; includes pure helpers formatOtpauthLabel / describeCredentialTransports / sortCredentialsForDisplay). +33 API vitest cases (webauthn-registration.test.ts, webauthn-authentication.test.ts, mfa-status-webauthn.test.ts — @simplewebauthn/server mocked at the module boundary) + 11 web helper tests → 1037/1037 API + 222/222 web. Non-scope: no sign-in-with-passkey (first-factor is a future slice), no FIDO2 admin policy, no SMS-based MFA, no hardware-key attestation verification. Also fixed a pre-existing web test failure by adding approval_reminder + approval_portal_link_created to the Approvals notification category (they were falling through to Other). | apps/api/prisma/schema.prisma, apps/api/src/core/config.ts, apps/api/src/modules/mfa/**, apps/api/src/test/{webauthn-registration,webauthn-authentication,mfa-status-webauthn}.test.ts, apps/api/src/test/setup.ts, packages/contracts/src/{mfa-webauthn,notifications,index}.ts, apps/web/src/app/(app)/settings/security/{page,totp-panel,passkeys-panel}.tsx, apps/web/src/lib/{mfa,mfa.test,notifications}.ts, apps/web/src/components/notification-tray.tsx | Claude | | 2026-08-04 | feat | E9 — X (Twitter) adapter. Sixth channel adapter shipped: connect + text publish + post-metrics. apps/api/src/modules/channels/adapters/x.ts. OAuth 2.0 with PKCE (X requires it — the E9.1 harness already emits the verifier/challenge pair) at twitter.com/i/oauth2/authorize; token exchange at POST api.twitter.com/2/oauth2/token uses Basic auth with code_verifier in the form body — LinkedIn's confidential-client shape with the PKCE twist. Scopes: tweet.read tweet.write users.read offline.access (the last is what enables real refresh). publishPost: text-only via POST /2/tweets (280-char cap enforced); threaded reply via content.extra.replyToTweetId; video refused. Media publishing is stubbed on purpose — v1.1 media/upload.json requires OAuth 1.0a HMAC signing (materially different from the OAuth 2 stack), so real-mode publish with images refuses invalid_request with a message naming the missing OAuth 1.0a signer. Mock mode (X_MOCK_MODE=1) returns deterministic SHA-256-seeded media_id_strings so the composer/publisher wiring is smoke-testable end-to-end without paying for the API tier that even grants analytics access. getPostMetrics: GET /2/tweets/:id?tweet.fields=public_metrics — the standard PostMetrics fields map cleanly except that X splits reshare into retweet vs quote-tweet, which we sum into shares and keep raw in extra. Error mapping: 401/403→token_revoked, 429→rate_limited (honours x-rate-limit-reset Unix-seconds header when computing retryAfterSec), 5xx→platform_error, 400→invalid_request. Bootstrap registers x when both X_CLIENT_ID + X_CLIENT_SECRET are set; UI Connect guide flipped to oauth_ready with prereqs that call out the media-stub caveat plainly. +25 tests → 806/806 (adapter suite grew 67 → 92 across pinterest/channels/x). | apps/api/src/modules/channels/adapters/x.ts, apps/api/src/modules/channels/bootstrap.ts, apps/api/src/core/config.ts, apps/api/src/test/adapter-x.test.ts, apps/web/src/lib/connect-guides.ts, docs/CHECKLIST.md, .env.example | Claude | | 2026-08-04 | feat | E10 — project KPI rollup engine + read API. Closes the "individual metric tables exist but nothing rolls them into a project view" gap. New ProjectKpiSnapshot model ([project, day, channel, platform] unique; "" empty-string sentinel for cross-platform aggregates because Postgres treats NULLs as distinct in unique indexes) — one row per (channel, platform) per UTC day plus a grand total row ALWAYS emitted (even for a zero-signal day, so a gap in the chart is a real "not yet computed" rather than "the day was silent"). Pure computeKpiSnapshotsForProjectDay reads PostMetricDaily (organic engagement + count of publishedAt-in-day PlatformPosts), AccountMetricSnapshot (per-account follower delta: last-of-today minus last-of-yesterday, per platform), and AdMetricSnapshot (spend + impressions + clicks + conversions per campaign per day + distinct active campaign count). Idempotent by shape — the caller upserts on the composite key. New 6-hourly startKpiRollupWorker (KPI_ROLLUP_TICK_MS, config in core/config.ts) walks every project, rolls yesterday, and triggers a catch-up (capped at 30 days) when the latest snapshot is more than 3 days behind. Read API: GET /projects/:id/kpis (items + server-summary; channel/platform filters), GET /projects/:id/kpis/trends?metric=…&granularity=day\|week (Monday-start ISO weeks; zero-filled buckets), POST /projects/:id/kpis/recompute?day=YYYY-MM-DD (owner/admin only, 422 on bad day). All per-route requireAuth behind the router mounted at / (E5.1 lesson). Contracts in packages/contracts/src/kpis.ts. Wire uses null for cross-platform aggregate platform; storage uses "" — bridged in the serialiser. +42 new tests → 715/715 pass. | apps/api/prisma/schema.prisma, apps/api/src/modules/kpis/**, apps/api/src/core/config.ts, apps/api/src/main.ts, apps/api/src/app.ts, apps/api/src/test/kpis-*.test.ts, apps/api/src/test/setup.ts, packages/contracts/src/{kpis,index}.ts | Claude | | 2026-08-03 | feat | E5.1 — LinkedIn post-metrics ingestion (PR #14). Every published LinkedIn post now shows a live metric strip (❤ · 💬 · fetched Nm ago) that refreshes as the worker polls. New PostMetricSnapshot model (time-series per PlatformPost: impressions/reach/likes/comments/shares/saves/clicks + raw). LinkedIn getPostMetrics implemented against /v2/socialActions/{urn} (likes + first-level comments; impressions are Page-scope only — deferred to linkedin-company). New apps/api/src/modules/metrics/ worker (15-min tick via METRICS_TICK_MS, 1-hour per-post min-interval, 30-day retention). Failure discipline mirrors publisher: token_revoked/token_expired marks account disconnected, rate_limited skips-until-next-tick. GET /posts/:id/metrics + usePostMetrics hook (60s refetch, published-only) + MetricsStrip on PostRow. Bug caught by tests: middleware leak on / mount broke better-auth's own auth flow — fixed by per-route requireAuth. +10 tests → 255/255. | apps/api/prisma/schema.prisma, apps/api/src/modules/metrics/**, apps/api/src/modules/channels/adapters/linkedin.ts, apps/api/src/test/metrics.test.ts, apps/web/src/lib/posts.ts, apps/web/src/app/(app)/projects/[id]/organic/[platform]/page.tsx | Claude | | 2026-08-03 | feat | E3.1 — publisher orchestrator (PR #13). "Schedule for tomorrow 9am" now actually fires at 9am instead of parking the row forever. New apps/api/src/modules/publisher/ — tick loop (default 30s via PUBLISHER_TICK_MS) finds due scheduled PlatformPosts and dispatches each. Atomic claim via the existing sole-writer scheduled → publishing transition (safe under N API replicas — zero double-publish risk). Uses the SAME code path as the "Publish now" button (extracted dispatchClaimedPublish + PublishFailure in posts/domain.ts so both surfaces share behaviour). Basic failure classification: token_revoked/token_expired → also flip the SocialAccount to disconnected; other errors → row lands at failed with publish_error stashed (user can Publish now to retry). SIGTERM: flips a drain flag, cancels next tick, waits (up to 30s) for in-flight publish(es) before exit — no half-posts on rolling deploys. Every attempt audit-logged (action: "publish" \| "publish_failed", via: "scheduler"). Deferred to E3.2+: retry queue with exponential backoff, per-account rate-limit tracking, full 90-day request/response audit. +8 tests → 245/245. | apps/api/src/modules/publisher/**, apps/api/src/modules/posts/domain.ts (refactored to expose dispatchClaimedPublish + PublishFailure), apps/api/src/main.ts, apps/api/src/test/publisher.test.ts | Claude | | 2026-08-03 | feat | E9.3 — publish path + media pipeline + composer rewrite (PR #11). Closes the "connected but can't publish" gap. New POST /uploads (multipart → MinIO with per-kind size caps: image 8 MB, video 200 MB; whitelisted content types) + GET /uploads/:key gateway so LinkedIn/etc. can download bytes without exposing S3. New POST /posts/:postId/platform-posts/:id/publish — draft/failed → publishing → published (or failed) through the sole-writer state machine; rollback to failed on adapter throw so no row stays stuck. LinkedIn adapter — full media parity: single & multi-image, single video, link preview, visibility (PUBLIC / CONNECTIONS). Register-upload → PUT bytes → include URN dance per asset with the right feedshare recipe per kind. Caps: 20 images OR 1 video, no mixing. Schema: Post.media_assets (JSONB) + Post.link_url. Contract: MediaAsset + default_platform_extra on create (seeds every child variant's platform_extra so composer-level visibility choices land where publish reads them). Composer rewrite: drop-zone file picker with drag-drop, thumbnail grid + per-item remove, link URL input, visibility select styled to the design system. Modal primitive refactored to header + scrollable body + footer with max-h-[calc(100vh-4rem)] and a footer?: ReactNode prop. "Publish now" button on draft/failed PostRow. 237/237. | apps/api/src/modules/uploads/**, apps/api/src/modules/posts/{routes,domain}.ts, apps/api/src/modules/channels/adapters/linkedin.ts, apps/api/prisma/schema.prisma, packages/contracts/src/posts.ts, apps/web/src/lib/posts.ts, apps/web/src/app/(app)/projects/[id]/organic/[platform]/composer-modal.tsx, apps/web/src/components/ui/modal.tsx | Claude | | 2026-08-03 | feat | E9.2 — Instagram + LinkedIn OAuth adapters + connect flow end-to-end (PR #10). Real OAuth adapters plug into the E9.1 framework. Meta: short→long token exchange, walks /me/accounts to pick the FB Page with a linked IG Business account, stashes PAGE access token + IG_USER id in providerMeta so publish/metrics never repeat the walk. LinkedIn: OAuth2 + OIDC /v2/userinfo for profile; refresh supported when the app has the Refresh Tokens product enabled. Registry auto-registers whichever platforms have META_* / LINKEDIN_* env at boot. New GET /channels public list endpoint powers a "Sign in with X" primary CTA on every organic hub (falls back to the manual modal when the platform's adapter isn't configured); success/failure banner on return from the OAuth callback (?connected= / ?oauth_error=), URL params scrubbed after read. Option A (same PR): connected_by_user_id nullable FK on SocialAccount — accounts stay project-shared for posting but token-death alerts / reconnect prompts go to the user whose grant powers it, not a random teammate. Publish/metrics/inbox for both platforms stubbed not_implemented — pending C2 / F-041. Proven live: real LinkedIn OAuth → account row in DB with AES-256-GCM-encrypted tokens. +14 tests → 237/237. | apps/api/src/modules/channels/adapters/{instagram,linkedin}.ts, apps/api/src/modules/channels/bootstrap.ts, apps/api/src/modules/channels/routes.ts (adds GET /channels), apps/api/prisma/schema.prisma (adds connected_by_user_id), apps/web/src/lib/social-accounts.ts, apps/web/src/app/(app)/projects/[id]/organic/[platform]/page.tsx, .env.example | Claude | | 2026-08-03 | feat | E9.1 — channel-adapter framework (PR #9). The abstraction one publisher/poller needs to talk to many platforms. Ships the seams only — per-platform adapters land in E9.2. ChannelAdapter interface + full type vocabulary (PublishContent, OAuthTokens, AccountProfile, PublishResult, PostMetrics, AccountMetrics, InboxMessage, typed AdapterError codes). Registry with duplicate refusal + test-only reset. Credential vault (AES-256-GCM via core/crypto.ts, purpose-namespaced HKDF-derived key, preserves NULL for no-refresh-token). OAuth harness (oauth.ts + routes.ts): JWT-signed state with channel-oauth audience + 5-min TTL, optional PKCE, generic POST /oauth/:adapterKey/start + GET /oauth/:adapterKey/callback that dispatch by URL segment. Upserts on (project, platform, accountPlatformId) so re-connect rotates tokens rather than duping; refresh only overwritten when the platform returned one (avoid clobbering with null). Schema: oauth_access_token / oauth_refresh_token / token_expires_at / oauth_scope / provider_meta on social_accounts_connected. Design clean-room from brightbean's providers/base.py + types.py. +15 tests → 223/223. | apps/api/src/modules/channels/{types,registry,vault,oauth,routes}.ts, apps/api/prisma/schema.prisma (OAuth token columns), apps/api/src/test/channels.test.ts | Claude | | 2026-08-03 | feat | IA restructure — the whole target sitemap is walkable end-to-end. Top nav trimmed from seven flat items (Projects · Calendar · Campaigns · Approvals · KPIs · Integrations · Billing) to the four IA top-level sections (Projects · Billing · Team · Settings); everything marketing-workflow lives inside a project now. New /projects/[id]/layout.tsx with grouped sidebar (Overview / Organic × 6 / Performance Marketing × 4 / Plan & Approve / Measure / Connect) and a project header with breadcrumb. Full-width layout — dropped max-w-7xl caps so the sidebar + content grid uses the whole viewport; individual copy blocks keep their own reading-column caps. One catch-all placeholder page ([...ia]/page.tsx) renders every un-implemented section — resolves at the section level (not per-child) so we ship ~20 sections instead of ~90 sprawling leaves, and shows the children as a preview tab-bar ("What this will have: Posts / Reels / Stories …"). Real pages take precedence automatically — creating projects/[id]/<section>/page.tsx displaces the catch-all. Campaigns list moved under project. Calendar UI (B1) shipped — monthly grid on top of E2 scheduling, timezone-local rendering, cards colored by PLATFORM_POST_STATUS_META tone. E2 scheduling engine (PostingSlot + Queue + QueueEntry + nextSlotDatetimes + SELECT FOR UPDATE on SocialAccount) came with this shipment via cherry-pick. Suite 168 → 201/201. | apps/web/src/app/(app)/**, apps/web/src/lib/project-ia.ts, apps/web/src/components/redirect-to-first-project.tsx, apps/api/src/modules/scheduling/**, apps/api/prisma/schema.prisma, apps/api/src/test/scheduling.test.ts | Claude | | 2026-08-03 | feat | Campaigns — the unit content, calendar entries and ad launches will hang off (F-023). Nav pointed at /campaigns since day one and 404'd — this ships the whole slice end-to-end: Prisma Campaign model + CampaignStatus enum (draft / scheduled / live / paused / completed / archived) on the existing Project FK, shared contract in @verjson/contracts/campaigns.ts (schemas + CAMPAIGN_STATUS_META), API module modules/campaigns/ (mirrors modules/projects/: db, domain, serialize, routes) with tenant + project-membership scope on every query, and a full /campaigns list + /campaigns/[id] detail page. Two rules the schema can't express are enforced in the domain: channels must be a subset of the parent project's mix (a channel the project doesn't invest in cannot be a campaign's channel — the roll-up would otherwise inflate silently); and status transitions follow a table — completed → live is refused, archived has no outbound edge, so a report a campaign appears in can't be invalidated by a stray write. The create modal mirrors the same subset-constraint client-side by disabling forbidden channels rather than validating after the fact. 10 new behavioural tests cover CRUD, cross-tenant isolation (out-of-org 404 not 403 — no oracle for "does this campaign exist"), project-scope for agencies, channels-subset enforcement, date-order refusal, and the illegal-transition wall. Full suite 158 → 168/168. Verified live: sign-in → create project with mix → create campaign scoped to project → list returns campaign with project projection → all four nav routes render 200. | apps/api/prisma/schema.prisma, packages/contracts/src/{campaigns,index}.ts, apps/api/src/modules/campaigns/*, apps/api/src/app.ts, apps/api/src/test/{campaigns.test,setup}.ts, apps/web/src/lib/campaigns.ts, apps/web/src/app/(app)/campaigns/** | Claude | | 2026-08-03 | feat | Password reset + email verification (closes two 🔴 GAPS.md rows). Three new pages — /forgot-password (request the reset), /reset-password?token=… (set a new password from the emailed link), /verify-email?token=… (confirmation surface for the verify link) — all in the landing theme with Reveal, the _kicker, and the acid-lime .mark. The login page's "reset coming soon" placeholder is now a real Forgot? link next to the password field. Backend flips emailVerification.sendOnSignUp: true so a fresh signup fires a verification email automatically without blocking login (unverified users can still use the app; the email flips users.email_verified on click, and per-endpoint gates can be layered later — e.g. billing requires verified). Reset & verify emails carry human-readable copy; the reset link expires in 1h, verify in 24h, both single-use. Config bug fixed in the same commit: config.betterAuth.baseUrl was using ??, which treated the empty-string default in .env.example as truthy — so sendOnSignUp's internal call (no HTTP request in scope for URL derivation) produced a relative /verify-email?… link that was unclickable. || coalesces empty strings too, so the fallback to PUBLIC_API_URL works. Two new behavioural tests cover the reset round-trip: token-in-identifier extraction, single-use, old-password rejection after reset, and no-user-enumeration on unknown emails. Full suite 158/158. Verified end-to-end against a running API + Mailpit: signup → verify email delivered → click → email_verified flipped false → true → 302 to /dashboard. | apps/api/src/core/better-auth.ts, apps/api/src/core/config.ts, apps/api/src/test/better-auth.test.ts, apps/web/src/app/(auth)/forgot-password/page.tsx, apps/web/src/app/(auth)/reset-password/{page,reset-form}.tsx, apps/web/src/app/(auth)/verify-email/{page,verify-form}.tsx, apps/web/src/app/(auth)/login/login-form.tsx | Claude | | 2026-08-01 | feat | Frontend cutover to Better-Auth (slice 3). The browser app now talks to /api/v1/auth/v2/* for sign-in, session bootstrap and sign-out, and to the new /api/v1/auth/signup-with-org wrapper for signup — the wrapper preserves the "no user without an organization" invariant that Better-Auth's own signup doesn't know about, by creating the Org then delegating password hashing + user creation to auth.api.signUpEmail then linking the user to the org (with a compensating delete if the user creation fails, so an orphaned org never persists). Better-Auth's bearer() plugin enabled server-side so a Bearer header (unchanged from the legacy pattern) authenticates every /v2/* endpoint — no cross-origin cookie work needed in dev. http/middleware.ts requireAuth now accepts EITHER a Better-Auth session token OR a legacy JWT, resolving both to the same Prisma User row on the context — so every existing route handler works unchanged regardless of which auth flow issued the token. Frontend lib/api.ts drops the refresh-token dance (Better-Auth's DB-backed sessions have sliding expiry, no refresh primitive), a 401 clears state and bounces to /login. lib/auth.tsx adapts Better-Auth's camelCase user shape to the legacy snake_case User type at the boundary, so no downstream page/component changes. Legacy /api/v1/auth/* routes still mounted for the belt-and-braces window; retired in the cutover-cleanup slice. Social sign-in temporarily hidden — the legacy OAuth callback mints legacy JWTs that Better-Auth's session middleware doesn't recognise, and wiring OAuth providers to Better-Auth is a later slice. Full workspace gate green (156/156, both builds clean). | apps/api/src/core/better-auth.ts, apps/api/src/modules/auth-v2/routes.ts, apps/api/src/http/middleware.ts, apps/api/src/app.ts, apps/web/src/lib/api.ts, apps/web/src/lib/auth.tsx, apps/web/src/app/(auth)/social-buttons.tsx, apps/web/src/app/(auth)/callback/page.tsx | Claude | | 2026-08-01 | feat | Better-Auth is real (slice 2 — schema + bcrypt bridge). Prisma schema gains Session, Account, Verification; User gains emailVerified + image and back-relations to the new tables. Better-Auth's advanced.database.generateId overridden to crypto.randomUUID() so its inserts land in our @db.Uuid id columns without a coercion error. Its default scrypt password hash swapped for bcrypt at cost 10 in both hash and verify — that's the bridge that lets an existing user's bcrypt hash (mirrored from users.hashed_password into accounts.password) authenticate through /v2/* without a reset. additionalFields on the User adapter (organizationId, role, isActive, isPlatformAdmin, tokenVersion) surface our tenancy/RBAC columns in the session payload. Backfill script at prisma/backfill-better-auth-accounts.ts (idempotent) mirrors every legacy hash into an accounts row. The seed creates both legacy + Better-Auth rows for the three seeded users so both paths log them in. 6 new behavioural tests over /v2/sign-up/email, /v2/sign-in/email (fresh user + seeded bcrypt bridge), /v2/get-session, and legacy coexistence — the full suite is now 156/156. Existing users unaffected; frontend still calls the legacy routes. Cutover is a later slice. | apps/api/prisma/schema.prisma, apps/api/src/core/better-auth.ts, apps/api/prisma/seed.ts, apps/api/prisma/backfill-better-auth-accounts.ts, apps/api/src/test/better-auth.test.ts, apps/api/src/test/setup.ts | Claude | | 2026-07-31 | feat | Better-Auth wired in parallel (auth migration slice 1). New apps/api/src/core/better-auth.ts builds a Better-Auth instance on the Prisma adapter, exposes it as a lazy getBetterAuth() factory, and mounts it under /api/v1/auth/v2/* alongside the existing /api/v1/auth/*. The parallel prefix is the whole point — legacy routes keep serving users, Better-Auth exists but has no schema yet (its session/account/verification tables land in slice 2). docker-compose.yml gains a Mailpit service on :1025 (SMTP) and :8025 (browsable inbox) so every reset/verify email is inspectable in dev without a real provider account. .env.example gains BETTER_AUTH_SECRET (NO default — signing keys shouldn't have source-tree fallbacks), BETTER_AUTH_URL, MAIL_TRANSPORT_URL, MAIL_FROM. The mailer falls back to logging to stdout when no transport is configured so a dev environment without Mailpit still shows what would have been sent. Zero user-visible change; every existing endpoint behaves identically. Sequencing plan in docs/AUTH_VERJSON.md §6 (slice 1 of 6). | apps/api/src/core/better-auth.ts, apps/api/src/app.ts, apps/api/src/core/config.ts, docker-compose.yml, .env.example | Claude | | 2026-07-30 | chore | Ported sources moved to archive/ and now tracked. Their nested .git directories were removed — a nested .git becomes a gitlink, a commit pointer with no submodule config, which clones as an empty directory nobody can check out. Each was verified clean first (no uncommitted changes, no unpushed commits, upstream remote present). Their node_modules stay untracked; one was 879MB. archive/ is excluded from the workspaces, both tsconfigs and lint, so nothing in it is built or shipped. | archive/**, .gitignore | Claude || 2026-07-29 | docs | Hootsuite gap analysis (COMPETITIVE.md) — most of the overlap was already in scope, because brightbean-studio was itself a Hootsuite-shaped platform. Nine features added (F-101 – F-109), and six deliberately refused with the reason recorded: chatbots, skill-based routing, 30+ network breadth, white-label, Canva embeds, advocacy gamification. Saying no is most of the value of the exercise. Also records what we have that Hootsuite does not — paid and organic in one budget model, an approval gate that covers AI, agency contractors as a first-class scope, and SEO/AEO alongside social. | docs/COMPETITIVE.md, data/dashboard/features.json | Claude || 2026-07-29 | feat | The UI wears the Verjson brand (D-024). Tokens, type and devices taken from verjson.com / verjson.ai: cream on ink, indigo for action, acid lime as a fill-only signature, Inter + JetBrains Mono, and the _section underscore kicker. Applied at the token layer, so /dashboard, /docs, /login and the app shell followed without touching them. | globals.css, layout.tsx, docs/DESIGN.md | Claude | | 2026-07-29 | feat | The landing page has pictures, because the product does (D-025). Two new sections show features that are entirely about images: the media library (F-033) as a browsable bento grid with an asset inspector, and the ad asset pipeline (F-055) as one source file rendered at all five Google Ads ratios with a movable focal point — real CSS crops of one image, not a diagram of rectangles. Plus two full-bleed photographic bands to break the rhythm, and the channel registry rebuilt as a table instead of fifteen identical cards. 14 images, downloaded to public/img/ with provenance in CREDITS.json. | apps/web/src/app/(marketing)/**, apps/web/public/img/** | Claude | | 2026-07-29 | fix | The board listed finished work as upcoming — labs.json keeps a milestone's ETA after the feature ships, so /dashboard and the landing roadmap both announced F-015 OAuth (done) as due 26 Aug. Fixed in the shared comingUp() helper, so both surfaces agree. | apps/web/src/lib/dashboard/status.ts | Claude | | 2026-07-29 | fix | The approval simulator forced the page to scroll sideways at 390px: long monospaced actor identities (key:ak_live_8f2a · optimise·google-ads) set the grid item's min-content width, so truncate never engaged. min-w-0 on both panels. | apps/web/src/app/(marketing)/gate.tsx | Claude | | 2026-07-29 | feat | SEO and AEO audits shipped (F-093 · F-094 · F-099) — crawl, pages and audit endpoints, plus 45 tests over the rules engine, extraction and crawl politeness. The audit runs over already-crawled pages rather than crawling on demand, so re-running it is instant and does not re-hammer someone's site — and that separation is what lets every rule be a pure function. | apps/api/src/modules/growth/** | Claude | | 2026-07-29 | fix | The tests found a real gap: a canonical of arbitrary text ("not a url at all") resolves as a relative path rather than throwing, so new URL() never failed and the invalid-canonical rule never fired. It now shape-checks the raw value before resolving. | apps/api/src/modules/growth/rules.ts | Claude || 2026-07-29 | feat | The landing page is now operable, not just readable (F-089). Seven sections, each driven by data/dashboard/*.json: an interactive approval-gate simulator (pick a proposer, send it to the queue, approve or reject, watch the audit log fill in with both actors), a ⌘K palette over every feature, experiment, doc and route, a tabbed jobs explorer with a mock per job, filterable channels wired to each adapter's real feature status, the open-questions accordion from labs.json, a month-by-month roadmap, and a searchable explorer over all 86 features — including the 58 still planned, because a front door showing only finished work is a brochure. The one invented thing on the page, the KPI mock, is labelled a preview. | apps/web/src/app/(marketing)/** | Claude | | 2026-07-29 | fix | Most of the landing page was invisible (B-009). Reveal interpolated its delay as seconds while every caller passed milliseconds, so delay={320} meant a 320-second fade-in. Nothing caught it because the elements were in the DOM — Playwright's toBeVisible() ignores opacity. The new guard asserts computed opacity. Also fixed sideways scroll at three widths (B-010). | apps/web/src/components/reveal.tsx, (marketing)/chrome.tsx | Claude | | 2026-07-29 | fix | The roadmap advertised finished work as upcoming: labs.json keeps a milestone's original ETA after the feature ships, so F-015 OAuth (done) still read "26 Aug". Lab rows are now dropped when the feature they name is already done. | apps/web/src/app/(marketing)/data.ts | Claude | | 2026-07-29 | test | 12 e2e cases for the landing page's interactive surfaces, including that the gate cannot be bypassed and that the page never scrolls sideways at five widths. E2E suite 5 → 17. | apps/web/e2e/landing.spec.ts | Claude | | 2026-07-29 | feat | Developer docs at /docs (F-100) — 25 pages across 6 groups, navigation driven by data/docs/manifest.json. Each entry points at a markdown file, a generated view, or nothing yet; an unwritten page is listed on purpose and says what it will contain, because a nav showing only finished pages hides the shape of the thing being built. Nine new documents: getting started, data model, hierarchies, permissions matrix, glossary, environment, frontend routes, design guide, integrations, bug reports. | data/docs/manifest.json, apps/web/src/app/(docs)/**, docs/** | Claude | | 2026-07-29 | feat | Growth intelligence foundation (F-093 · F-099) — a polite fetcher (robots.txt with longest-match precedence, per-host delay, honest UA with a contact URL, capped read), HTML extraction, and 18 audit rules as pure functions (11 SEO, 7 AEO) so the whole engine is testable with no network, no database and no fixtures. Scraping is a queue consumer, so it inherits retries and rate limiting rather than growing its own scheduler. | apps/api/src/modules/growth/** | Claude | | 2026-07-29 | docs | OpenSEO adopted (D-023) — replaces the planned SEMrush integration for keywords, ranks, backlinks and competitors, and its ai-search feature answers LAB-008's open question about what the AEO metric actually is. Our on-page audit stays: it costs nothing per run and emits stable rule ids that map to fix PRs. | docs/INTEGRATIONS.md | Claude | | 2026-07-29 | fix | Responsive pass. The app nav used overflow-x-auto, which "fit" at every width by slicing the last item in half (B-003). Replaced with three real layouts: drawer below md, icon-only md–lg, icon + label above. Scrollbars are now thin and token-coloured everywhere, and hidden inside .no-scrollbar containers — hidden, never disabled; every one still scrolls by wheel, drag, touch and keyboard. | apps/web/src/app/(app)/app-shell.tsx, globals.css | Claude | | 2026-07-29 | fix | The API now connects to the broker at startup, so a healthy stack no longer reports queue: down until the first publish (B-004). And the E2E suite runs while the dev server is up, instead of colliding with it (B-001). | apps/api/src/main.ts, apps/web/playwright.config.ts | Claude || 2026-07-29 | feat | Agent runs and the approval gate (F-073 · F-074 · F-075 · F-097) — the surface humans and agents converge on. The gate is a state machine with the legal transitions in one dependency-free module: there is no edge from running to applied, and the test asserts that negative property exhaustively rather than by example, so an auto-apply mode added later fails the suite. transition() is the sole writer of status and uses a filtered updateMany, so two simultaneous approvals cannot both apply the same spend. Rejections require a reason. An agency contributor can see a run on their project but cannot sign off its spend. See D-022. | apps/api/src/modules/agents/**, apps/web/src/app/(app)/approvals/ | Claude | | 2026-07-29 | feat | Durable execution with a fallback (F-097). Runs go to trigger.dev when configured and to our own RabbitMQ worker otherwise — deliberately, because a run that cannot start is a visible queued row, whereas a run that cannot be approved would be an outage of the control that stops money being spent. | apps/api/src/modules/agents/runner.ts | Claude | | 2026-07-29 | fix | The agent-run scope filter used an { id: "__never__" } sentinel for "match nothing", which Postgres rejects against a @db.Uuid column — so the fail-closed branch 500'd instead of returning nothing. Branches are now composed rather than negated. | apps/api/src/modules/agents/domain.ts | Claude | | 2026-07-29 | test | 18 new cases. API suite 87 → 105. | apps/api/src/test/agents.test.ts | Claude || 2026-07-29 | docs | Security findings register (SECURITY_FINDINGS.md) — all 19 findings from the review, what each one actually allowed, and what closed it. Rows are never deleted after closure: knowing what was once possible is what tells the next person which assumptions to re-check when they touch that code. | docs/SECURITY_FINDINGS.md | Claude | | 2026-07-29 | feat | Refresh tokens are revocable (S-015). POST /auth/logout bumps a tokenVersion carried in the token, so a leaked token stops working instead of lasting its full 14 days — clearing localStorage only removed one browser's copy. Access tokens are deliberately not revoked: that would mean a DB read per request, which is the cost the stateless design exists to avoid; residual access is bounded by the 30-minute TTL. Tokens predating the field are treated as version 0, so no session broke. | apps/api/src/core/auth.ts, modules/auth/routes.ts, apps/web/src/lib/auth.tsx | Claude | | 2026-07-29 | feat | ProjectMember.role is enforced (S-016). It was validated, stored and serialised while granting nothing — a viewer and a lead had identical power. Project update and budget writes now check it. Writing to a project you are not a member of returns 404, matching the read path so the write endpoint cannot be used to prove a project exists. | apps/api/src/modules/projects/domain.ts | Claude | | 2026-07-29 | fix | Plan caps are atomic (S-017). The count moved inside the create transaction at Serializable isolation; a serialization conflict is retried up to three times so the loser re-reads the committed count and gets a 402 about the cap rather than a 500 about a transaction. | apps/api/src/modules/projects/db.ts | Claude | | 2026-07-29 | fix | Retry queues split per delay tier (S-018). RabbitMQ only dead-letters from the head of a queue, so one queue with mixed per-message TTLs let a message parked for 80s block every 5s retry behind it. The TTL now lives on the queue and the tier is chosen by routing key. | apps/api/src/core/queue.ts | Claude | | 2026-07-29 | refactor | Removed unused authorization helpers (S-019). requireRoles, assertPlatformAdmin, requirePlatformAdmin, assertPaidChannelsAllowed, decryptNullable were exported and never called — an exported authorization helper that nothing invokes reads as an enforced control. Each removal leaves a comment saying where the check actually lives. core/storage.ts and the unused serialisers are kept for queued features but now say plainly that nothing calls them yet. | apps/api/src/core/**, src/http/middleware.ts | Claude | | 2026-07-29 | test | 7 new cases: token revocation (and that signing in again still works), viewer/contributor project roles, non-member 404, and three concurrent creates against a one-project cap. API suite 80 → 87. | apps/api/src/test/** | Claude || 2026-07-29 | breaking | OAuth state is now bound to the browser (D-018, supersedes D-012). Signing alone did not prevent session fixation, and the old rationale said it did — /start is unauthenticated, so an attacker could mint a genuinely-signed state, complete consent with their own account, and hand a victim a callback URL that logged the victim into the attacker's organization. Via /link-url it was worse: a victim's consent could attach their GitHub identity and repo-scoped token to the attacker's account. /start now sets an HttpOnly, SameSite=Lax, __Host- cookie; the state carries only the nonce hash; the callback requires both, compares in constant time, and clears the cookie before doing any work. An explicit link against an already-bound provider account is a 409. | apps/api/src/modules/oauth/** | Claude | | 2026-07-29 | breaking | The project scope filter is now an allow-list (D-019). It read "if agency or client, restrict to memberships", which fails open — any unrecognised role got org-wide read of every project, its budgets and its team. User.role is now a Prisma enum as well, so the column cannot hold a value no check anticipates. | apps/api/src/modules/projects/db.ts, prisma/schema.prisma | Claude | | 2026-07-29 | fix | Plan is derived from the Stripe price, not metadata (D-020). Metadata is written once at checkout and never updated by a portal plan change, so an org downgrading scale → starter kept scale limits indefinitely; and ?? "starter" silently granted a paid plan to any subscription without metadata. Unknown price now degrades to free and logs loudly. | apps/api/src/modules/billing/domain.ts | Claude | | 2026-07-29 | fix | Webhook idempotency claimed by INSERT before the work (D-021), so concurrent deliveries cannot both apply and the loser cannot 500 into a Stripe retry storm. Also found writing the tests: an over-broad catch was reporting "billing not configured" as "Invalid signature" — verification now uses a client built for that one job. | apps/api/src/modules/billing/domain.ts | Claude | | 2026-07-29 | fix | Rate limiting was bypassable — the first X-Forwarded-For hop is caller-controlled, so any client could send a random value per request and never trip the login limiter. Now uses the Nth hop from the right per TRUSTED_PROXY_COUNT, and ignores the header entirely when no proxies are configured. Added limits to /auth/refresh, /billing/checkout, /billing/portal and the OAuth link endpoints. | apps/api/src/http/middleware.ts | Claude | | 2026-07-29 | fix | Validation gaps that surfaced as 500s or a crashed page: 2026-13-45 passed the date regex and became an Invalid Date at Prisma; 1$# passed length(3) and threw RangeError inside Intl.NumberFormat, taking down the projects page for the whole org; channels was unbounded and un-deduplicated; website_url accepted javascript:. | packages/contracts/src/projects.ts | Claude | | 2026-07-29 | fix | The unauthenticated health probe dialled AMQP per request with no in-flight dedupe, leaking a connection per concurrent probe. It now reads cached state and never dials; connect() memoises the in-flight promise. | apps/api/src/core/queue.ts, modules/health/routes.ts | Claude | | 2026-07-29 | fix | Audit trail gained ipAddress (the column existed and was always null) plus entries for login success, login failure, and OAuth unlink — a burst against one account is invisible if only successes are recorded. Provider error bodies are no longer logged: they routinely echo the client secret. | apps/api/src/core/audit.ts, modules/auth/routes.ts, modules/oauth/** | Claude | | 2026-07-29 | test | 17 new cases covering every fix above, including the three the review named as missing. API suite 63 → 80, all green — and the queue's two integration cases now run against a real broker rather than skipping. | apps/api/src/test/** | Claude || 2026-07-29 | feat | Work queue and worker process (F-096) — direct exchange, a durable queue per job kind, a broker-side delayed retry queue and a dead-letter queue. Retries live in the broker rather than an in-process sleep, so a redeploy mid-backoff does not lose the job; failures re-publish with an incremented attempt instead of nack(requeue: true), which would hot-loop. prefetch is set per kind because nearly every consumer talks to a rate-limited API. Worker is the same image as the API with a different command; WORKER_KINDS lets a slow kind get its own Deployment. ⚠️ The broker round-trip is not yet verified — see VERIFICATION.md. | apps/api/src/core/queue.ts, src/worker.ts, src/jobs/index.ts | Claude | | 2026-07-29 | feat | Health probe now reports broker reachability. A down broker is reported but does not fail readiness — taking the service out of rotation because a queue is unavailable turns a degraded feature into a full outage. | apps/api/src/modules/health/routes.ts | Claude || 2026-07-29 | breaking | RabbitMQ replaces Postgres as the work queue (D-014). Almost every consumer talks to a rate-limited third-party API, and per-queue prefetch, fair dispatch and native dead-lettering are exactly those needs — a polling table reimplements all three. The rate limiter stays on Postgres; a fixed-window counter is not a queue. Compose gains rabbitmq and a worker service running the same image as the API. Supersedes the queue half of D-005. | docker-compose.yml, docs/INFRASTRUCTURE.md | Claude | | 2026-07-29 | feat | Baileys WhatsApp bridge as its own container (F-048, D-015) — persistent WhatsApp Web session on its own volume, behind the shared ChannelProvider interface. Flagged plainly in the docs: it is an unofficial client, bulk marketing over it breaches WhatsApp's terms, and the downside is a banned number. Kept behind the interface so the official Cloud API is a transport swap rather than a rewrite. | docker-compose.yml, docs/INFRASTRUCTURE.md | Claude | | 2026-07-29 | docs | Infrastructure recorded (D-014 · D-015 · D-016 · D-017) — new INFRASTRUCTURE.md covering why RabbitMQ and trigger.dev both exist (short jobs vs long durable runs, and what breaks if either does the other's job), the queue topology, the Baileys trade-off, and scraping rules. Added F-096 queue, F-097 trigger.dev workflows, F-098 Agent-Reach research layer, F-099 scraper framework. | docs/INFRASTRUCTURE.md, docs/DECISIONLOG.md, data/dashboard/** | Claude || 2026-07-29 | feat | OAuth sign-in with Google and GitHub (F-015) — one provider registry entry per provider, so adding a third changes nothing else. State is a signed short-lived JWT (the callback is a cross-site GET, so unsigned state is a session-fixation hole); accounts link only on a provider-verified email; the redirect target is allow-listed to our own origin; tokens land in the URL fragment so they never reach a server log or a Referer header. See D-012. | apps/api/src/modules/oauth/**, apps/web/src/app/(auth)/** | Claude | | 2026-07-29 | feat | Encryption at rest (F-008, partial) — AES-256-GCM with per-purpose keys derived by HKDF, so the OAuth-token key and the credential-vault key are different keys from one configured secret. Plus one-way token hashing and constant-time comparison. ENCRYPTION_KEY has no default on purpose: a fallback would mean production secrets encrypted with a key from the source tree. | apps/api/src/core/crypto.ts | Claude | | 2026-07-29 | fix | The API build produced an unrunnable bundle. tsc does not rewrite @/* path aliases on emit, so dist contained specifiers Node cannot resolve. Switched to tsup. See D-013. | apps/api/tsup.config.ts | Claude | | 2026-07-29 | fix | next build failed at prerender because /login reads ?error= via useSearchParams. Split into a Suspense boundary + form. | apps/web/src/app/(auth)/login/** | Claude | | 2026-07-29 | test | 20 new cases — OAuth state forgery/expiry/wrong-purpose, the redirect allow-list, unconfigured vs unknown providers, and encryption properties (tamper detection, key separation). E2E suite rewritten for the current routes: 5/5. API suite 30 → 50. | apps/api/src/test/{oauth,crypto}.test.ts, apps/web/e2e/smoke.spec.ts | Claude || 2026-07-29 | feat | Projects, marketing mix and budgets (F-020 · F-025 · F-026) — the first vertical slice. A company creates a project, declares which of twelve marketing channels it invests in, and sets a budget per channel per period. Money is integer minor units end to end; the roll-up is computed server-side and excludes foreign-currency budgets rather than adding them together. Re-setting a channel and period replaces the amount rather than stacking rows. | apps/api/src/modules/projects/**, packages/contracts/src/projects.ts, apps/web/src/app/(app)/projects/** | Claude | | 2026-07-29 | feat | Agency project-scoping (F-005 · F-006) — agency and client roles added, and project membership made the scope: without a ProjectMember row an outside contractor sees nothing, even inside their own organization. Enforced as a where clause in the data-access layer, so out-of-scope reads 404 rather than 403 and ids cannot be probed. See D-009. | apps/api/src/modules/projects/db.ts, domain.ts | Claude | | 2026-07-29 | feat | Login, signup and the app shell — (auth) route group and a session-guarded (app) group. The build board moved to (board) so it stays outside the guard. | apps/web/src/app/(auth)/**, apps/web/src/app/(app)/app-shell.tsx | Claude | | 2026-07-29 | test | Projects suite: 22 cases covering tenant isolation (404 not 403), agency scoping, role permissions, cross-org invite rejection, budget upsert semantics, channel validation and currency isolation. API suite now 30/30. | apps/api/src/test/projects.test.ts | Claude | | 2026-07-29 | docs | Scope expanded per the second brief: OAuth (F-015), Stripe (F-016), live campaign control (F-059), WhatsApp (F-048), and a new Growth intelligence group — SEMrush (F-091), Apollo (F-092), SEO audit (F-093), AEO readiness (F-094), GitHub PRs (F-095). Board now 81 features. Added D-009, D-010, D-011 and LAB-007/008/009. | docs/**, data/dashboard/** | Claude | | 2026-07-29 | chore | Branching model: prod ← dev ← feat/F-###-*, one branch per feature id, npm run verify before every merge. | docs/BRANCHING.md | Claude || 2026-07-29 | feat | Project dashboard — /dashboard, a JSON-backed command centre with seven tabs: Overview (with a computed "what's coming up"), Features checklist, User flows, Architecture, Tests, Labs, and Docs (renders docs/*.md in-app). Data lives in data/dashboard/*.json. | apps/web/src/app/(board)/dashboard/**, data/dashboard/** | Claude | | 2026-07-29 | feat | Landing page — the internal front door: what the studio is, the four pillars, the channel surface, the agentic layer, and live build status read from the dashboard data. | apps/web/src/app/(marketing)/page.tsx | Claude | | 2026-07-29 | docs | Full docs set rewritten for this product — brief, architecture, features (69 rows across 8 groups), API contract, decision log (8 ADRs), testing strategy, verification, deployment, and a porting map recording what comes from brightbean-studio vs adwords-adsense and what was deliberately dropped. | docs/** | Claude | | 2026-07-29 | breaking | Split into two deployables. The single Next.js app became an npm-workspaces monorepo: @verjson/api (Hono, owns Prisma and every database credential), @verjson/web (Next.js, no DB driver), @verjson/contracts (zod schemas both import). The seam is enforced by no-restricted-imports in both apps, not by convention. Supersedes the template's D-001. | apps/**, packages/**, docker-compose.yml | Claude | | 2026-07-29 | refactor | API rewritten from Next route handlers to Hono. src/server/* → apps/api/src/core/* (framework-agnostic) plus src/http/* (transport). Auth, health, audit, rate limiting, storage and serializers ported with behaviour preserved; the test harness now drives the real app in-process via app.request() instead of calling route functions directly. | apps/api/src/** | Claude | | 2026-07-29 | test | Auth suite extended from 5 to 8 cases — added duplicate-email 409, refresh-token exchange, and a 422 contract-violation case. | apps/api/src/test/auth.test.ts | Claude | | 2026-07-29 | chore | Dockerfiles for both apps (multi-stage, unprivileged, health-checked) and a Compose apps profile that runs the production topology locally. | apps/*/Dockerfile, docker-compose.yml | Claude | | 2026-07-29 | chore | Renamed from app-starter to verjson-marketing-studio; token storage keys, S3 bucket, container and volume names all rescoped. | package.json, .env.example | Claude |

Types: feat · fix · refactor · docs · chore · perf · test · breaking.