Client CRM Factory.

Added 0.3, 2026-09-10. Phase 9 assumed a client arriving with nothing. Rising Origin arrives with a live Supabase, fourteen migrations of their own, and a team already signed in. That is the harder case and it is the one worth rehearsing, because a client with no existing system is trivially easy.

The decision that shapes everything: reuse the client's Supabase project, or create a new one.

auth.users lives in the auth schema; the core's 279 migrations only ever touch public. So reusing the client's project keeps every existing login working for free, and identity migration stops existing. Alex made this point directly: he is already in Nick's system. A fresh project would mean exporting and importing auth.users including password hashes, which nobody here has rehearsed.

What reuse costs: in-place rollback. The core wants names that are already taken in public, so applying it is a hard cutover with no parallel run. A verified snapshot is the only way back.

Recommendation: reuse, with a rehearsal on a restored snapshot first. For a single client with one team, a snapshot is adequate rollback, and identity is the messier of the two problems.

The procedure

Run npm run inventory:client-collisions -- --url "<client db>" first. It is read-only, parses the core's objects from the migrations, introspects the client's public schema, and prints exactly what clashes plus the rename statements. Point it at a restored snapshot before the live database.

1. Snapshot. A gate, not a step. It is the only rollback.
2. Rename the colliding objects to a <client>_legacy_ prefix. Postgres resolves foreign keys, indexes, policies and column types by OID rather than by name, so every relationship inside the client's schema survives a rename.
3. Apply the core's 279 migrations to public, now that the names are free.
4. Transform from the _legacy objects and the client's untouched tables into the core's shape, using the mapping stage 1.5 already proved.
5. Verify counts against stage 1.5, then remove the seeded Ventari rows: 21 organisations and 16 price book entries as measured on 2026-09-10.
6. Repoint the client's deployment at the shared codebase with their host binding.
7. Walk the instance with the client before dropping anything.
8. Drop the legacy objects, last, and only after step 7.

The client's application is down from step 3 to step 6. Minutes at Rising Origin's volume, and it is a genuine outage rather than a DNS wait, so it is announced and scheduled.

The client's old schema does not need to keep working. The transform reads as service role, which bypasses RLS, so their policies, functions and views can be renamed or broken without consequence. What is needed is their data legible for one pass, not their application functional.

Worked example, Rising Origin, measured 2026-09-10

32 objects in their public schema. Six collide: tables organizations, people, notes; types organization_status, person_status; function current_person_id. The other 26 can sit untouched while the core installs.

The inventory script reproduces that set exactly, which is how it was verified: it was first worked out by hand, then the script had to agree.

The undocumented step this exposed

Creating the first admin user has no script and is not written down anywhere. It takes five steps against a fresh database, two of which are not guessable:

1. POST /auth/v1/admin/users with the service-role key
2. INSERT INTO people
3. INSERT INTO profiles with id = the auth user id, linked to that person
4. INSERT INTO role_assignments with role admin
5. PUT app_metadata with ventariRole, ventariRoles, ventariOnboarded

Miss step 5 and the user sits on /pending forever with no error shown. This was found by hitting it during the 2026-09-10 preview. It belongs in the runbook and then in the skill, and it does not apply when reusing a client's project, which is another argument for reuse.

What round two found on real data, 2026-09-11

The procedure above ran twice: once on the synthetic fixture (a Grok worker), once on Rising Origin's real export (Alex, with Claude driving). Both are in docs/crm-factory/runbooks/cutover.md. Every step held on real data, and the real run added five rules the synthetic one could not:

1. The export is the truth. A client's own migrations seed reference rows (Rising Origin: a role matrix and one initial identity). The export carries those rows as production has them. The loader truncates first. The real cutover has this same collision.
2. Free-text in a closed-dictionary column. Rising Origin's team typed job titles into the membership role field. The mapping refused ten of thirteen links, correctly. Decision: unrecognised roles map to other and the title is kept on the person as metadata. Expect every client to have one of these. The refusal count is the signal; a mapping that silently coerces would have hidden it.
3. The bootstrap admin checks for an existing person first. Alex was already in Nick's data as a collaborator; the bootstrap created him again.
4. The sidebar CRM surface must point at the org list, /crm/clients, not the client-360 vault at /clients, which is empty on a fresh instance.
5. lib/team.ts puts Ventari's six people on every client's Team page. A code constant, not a pack surface, not seed data. Third instance of that pattern; it needs the same fix as the executive name and the icons.

The export path removes the password dependency for the rehearsal. A collaborator holds the service-role key and can read every table through the REST API. scripts/export-client-data.mjs does that, read-only. The password is still needed for the live cutover, because that applies migrations.

Screenshots of his real pipeline exist under snapshots/, gitignored, for the message to Nick. His deals, his stages, his company names, the pack's chrome, and the workspace strip showing only what his pack declares.

Added 0.5, 2026-09-11, from Alex's screenshot of Rising Origin's current build next to the new CRM. Runs alongside Phases 10 to 13; it neither blocks provisioning nor waits for it. It does block the skill's design step in Phase 14.

Measured 2026-09-11: components/ and app/ contain 9,788 hardcoded Tailwind colour classes across 380 files (bg-zinc-800, border-white/10, text-zinc-400 and kin). The pack's six colour tokens are read by a handful of them. That is why setting primary to his orange changed a button and a number and nothing else.

Four steps, in order. The order is not negotiable.

1. The token contract. Decided by Alex 2026-09-11: the table below, as proposed. Names follow the code that already exists (primary, not accent; the six signal* keys stay as the status group), because renaming a live key is churn with no client on the other side of it.

The typographic roles are the part the current contract cannot express and the part that makes his build look like his build. A family alone does not give you condensed capital headings and monospace labels.

Layout is out of scope. His two-panel CRM is structure, and a pack does not swap components. The pass makes the same structure wear his clothes completely. A client whose layout must differ is a bespoke build and is priced as one.

Exit: the funnel, CRM and sign-in pages of Rising Origin's instance, on tokens extracted from his CSS and adjusted once through the gate, pass a side-by-side review by Alex against his current build. And the agency's rendered output is byte-identical to before the pass began, proved per lane.

Two lanes (historical on the operating desk; not required for pickup): A for growth and social, B for inbox and clients. Both also answer Alex's first-sign-in notes: where attribution went (his old CRM had it on every lead; the mapping imported the touches), whether Clients is redundant on an instance with no client-health pipeline, and why Funnel lands on the control room.

Exit: the four surfaces on Rising Origin's instance show his identifiers or an honest not-connected state in his name, never Ventari's; his real Search Console, social and mailbox connected by hand from the hand-steps in the reports; the agency unchanged.

Corrected 2026-09-14: a client pack never uses the platform Resend key (#694). Sending on Connections takes the client's own key.

Exit: met on the agency side; Alex's second look on Rising Origin's live funnel and CRM after the release that carries it.

Two things the first walk-through found, 2026-09-19 (Rising Origin, Alex driving, signed in as Nico):

1. /me/accounts can be empty for a Page the user fully controls

   Nico has Full access (Everything) on the Rising Origin Page through the business portfolio, every one of the ten scopes granted, and GET me/accounts returned [] on v21.0 and v26.0. The Access Token Debugger listed the Page (1284116174786165) under pages_show_list granular scopes and the Instagram account (17841477864741917) under every instagram_* scope, and a direct read of the Page returned instagram_business_account and a Page access_token. So the card lists Pages from /me/accounts first and, when that is empty, from debug_token granular scopes (app token, never the user token) read directly. me/businesses needs business_management, which the configuration deliberately does not take.
2. Meta is retiring the "Other" app-creation path. The dashboard now builds an app from use cases; "Other — this option is going away soon" still exists but a SOP that starts there is dead on arrival. The recipe below is the use-case path, as walked. Meta's docs say config_id "has replaced scope" for Login for Business; the card sends config_id when the configuration id is saved and scope otherwise.

Exit: Rising Origin posts to his Page and Instagram from the CRM with tokens he minted on his own app, and no Meta credential exists in his Vercel project or in Ventari's hands.

SOP: client Meta app (model B) — every CRM install

This is the install recipe, not a one-off for Nick. Walked end to end on 2026-09-19 for Rising Origin; every step below was clicked, and the screens are named as Meta showed them that day. Same steps for Ventari's agency instance (model A app, same permission set, never reused on a client).

Before you start: three facts to have in hand

• The Facebook profile that will click Connect. It must (a) have full control of the client's Page and (b) be able to create or administer an app in the client's business portfolio. For Rising Origin that is Nico's personal profile; Nick (info@risingorigin.com) has full portfolio access too. Business-portfolio access and app roles are two different systems; only the second makes an app show up in Graph API Explorer.
• The Instagram professional account is linked to the Page, not only present in the portfolio. Business Manager → Accounts → Instagram accounts → the account → Connected assets must list the Page. Rising Origin: @risingorigin → Rising Origin Page, confirmed.
• The contact email is the client's (info@risingorigin.com), never a Ventari mailbox. Meta sends data-use checkups, restriction warnings and policy notices to that address; a Ventari address makes Ventari the responsible party, which is the entanglement model B exists to avoid. It grants no role. Tell the client to forward anything with a deadline.

Create the app from the client's business portfolio (as the profile above; the app is then business-owned and that profile is admin from the first second — no role invite, no developer registration wait)

1. Business Manager (business.facebook.com/settings) → Accounts → Apps. Empty means the business owns no app yet; an app created under someone's personal developer account does not appear here and should not be reused — it is a Ventari-held (or one-person-held) credential for the client's assets. (Rising Origin had none: the handoff's "Nick's app" meant his CRM deployment, not a Meta app. Corrected 2026-09-20.)
2. Add → Create a new app ID. Meta hands off to the developer site with the business pre-selected.
3. App details: name {client product} CRM (Rising Origin: Rising Origin CRM), contact email the client's.
4. Use cases. Do not tick "Authenticate and request data from users with Facebook Login" (consumer login: public_profile, email; no pages_* or instagram_*), nothing under Ads, not Threads, not WhatsApp, not "Create an app without a use case", not "Other". Tick exactly:
   • Manage everything on your Page (Content management)
   • Manage messaging & content on Instagram (Content management)
   • Engage with customers on Messenger from Meta (Business messaging)
5. Business: the client's portfolio (should be pre-selected). Publishing requirements: "No requirements identified" — that is the model-B claim in one line: a business's own app in Development mode needs no App Review for that business's own assets. Overview → Create app.
6. Back in Business Manager, Accounts → Apps now lists it. That listing is the proof of ownership.

Dashboard, in this order (the app dashboard at developers.facebook.com, left nav: Dashboard, Required actions, Use cases, Facebook Login for Business, Testing, Publish, App settings, App roles)

7. Facebook Login for Business → Settings. Client OAuth login yes, Web OAuth login yes, Enforce HTTPS yes, Strict Mode yes. Valid OAuth Redirect URIs — type the URI, press Enter so it becomes a chip, scroll to the bottom, Save changes, then use "Redirect URI to check" below it; it validates the saved list only. Exact, https, no trailing slash: https://rising-crm.vercel.app/api/connections/meta/callback (copy from the Connections card once 9f is on the instance). Preview *.vercel.app hosts are not listed unless someone is testing on one.
8. Use cases → Manage messaging & content on Instagram → Customize

   Two tabs matter and one is a trap:

   • API setup with Instagram login — not this one. It carries its own Instagram app ID/secret and the instagram_business_* scopes on graph.instagram.com. Do not click "Add all required permissions" there and do not note that ID/secret.
   • API setup with Facebook login — this one. Click Add required content permissions (instagram_basic, instagram_content_publish, pages_read_engagement, pages_show_list, business_management) and Add required messaging permissions (adds instagram_manage_messages).
   • Permissions and features (top of the sub-nav): search manage_comments and add instagram_manage_comments (the row without business in the name); search manage_insights and add instagram_manage_insights. Adding a Page permission here pops "Adding X will affect other use cases on this app" — Add; it is app-wide and the other two use cases legitimately want it.
9. Use cases → Manage everything on your Page → Customize → Permissions and features. Confirm pages_read_user_content and pages_manage_posts say "Ready for testing"; add them if not. pages_messaging lives on the Messenger use case and is already on. pages_manage_metadata arrives with Messenger (webhooks); leave it as Meta set it. Never add pages_manage_ads, pages_manage_engagement, instagram_manage_engagement, instagram_manage_contents, branded content, shopping, creator marketplace, or anything instagram_business_*.
10. Facebook Login for Business → Configurations → Create configuration

    Name {client product} CRM. Login variation: standard. Access token: User access token (the Assets step greys out on purpose — the user picks the Page and Instagram account inside the login dialog; that is what the card's select step relies on). Permissions: the ten in the table, and only the ten. This picker only offers permissions the use cases have already added, which is why steps 8–9 come first. Leave business_management and pages_manage_metadata unticked: the card asks for the ten by name and checks for the ten. Create. Note the configuration ID (public; Rising Origin: 1082330371075711) — it goes on the Connections card.
11. App settings → Basic. App domains: the CRM host only. Privacy Policy URL: on the client's own site, never Ventari's. Category: Business and pages. App ID and App Secret go on Connections. Never into Vercel on a client project. Never into chat.
12. Leave the app in Development. Live / App Review is not required for a business's own assets.

This list is META_SCOPES in lib/socials/meta.ts. Keep the configuration, Connect, and this table the same. Meta's summary screen spells one of them instagram_content_publishing; the permission itself is instagram_content_publish — read the Permissions and features row, not the summary.

Prove it in Graph API Explorer before touching the instance (developers.facebook.com/tools/explorer, as the Page admin)

13. Meta App: the client's app. User Token. Configuration: the one from step 10. Generate Access Token. In the dialog choose Opt in to current Pages only and tick only the client's Page; same for Instagram. Never "all current and future Pages" — the admin's profile may administer other businesses' Pages and this token must not see them.
14. me/permissions — all ten granted, nothing else but public_profile.
15. Tools → Access Token Debugger → Granular Scopes: every pages_* row names the client's Page id, every instagram_* row the Instagram account id. That is the token shape Connect wants.
16. {page-id}?fields=id,name,instagram_business_account{id,username} — returns the Page with the linked Instagram account. This, not me/accounts, is the proof; me/accounts may be [] (finding 1 above) and the card handles that.
17. Never paste an Explorer token anywhere: not Vercel, not chat, not a note. Ids and usernames only.

Then, on the instance (after the 9f release is on the client's host)

18. Connections → Meta card → App ID, App Secret, configuration ID → Save.
19. Connect through Facebook as the Page admin; current Pages only; pick the Page; the card stores the Page and Instagram tokens encrypted.
20. Posting to the Page and Instagram from Socials is the exit.

Not this configuration, not this card

Exit: Nick adds a deal, opens it, decides its attribution, and works his organisations across his four declared tabs (a fifth, Audits & Proposals, is Nick's call), on the live instance; the agency's funnel and CRM unchanged.

Scoped 2026-09-20 from the decision in §5.9 (2026-09-19: Cody and Alex; Nico to ratify). Written against lib/executive/tenant-model-gate.ts, lib/executive/provider.ts, lib/agent-connections/host-protocol.ts and the Connections store. No code yet.

The card. Connections gains kind ai, the sixth card, pack-declared like GHL (pack.integrations.ai.enabled; Rising Origin's pack does not declare it until Nick asks). Two modes, one connection row; the client picks on the card.

• Key-paste. The client pastes an API key from their own provider account (Anthropic or OpenAI; the card names the provider). Stored as the row's secret, encrypted with the instance key like a mailbox password; identity is the provider plus the key's last four; config holds provider, model, and the verify timestamp. Save verifies the key with one cheap call (models list or a one-token completion) and stores nothing on failure, same as GHL. Server-side, always on, metered on the client's bill.
• Host-connect. The client's own machine runs the provider CLI signed into the client's own subscription and enrols as a host through the existing host protocol - the same intent → claim → complete → canary sequence the agency's hosts use, with the instance as the broker. The card shows the enrolment code and the host's status (last canary, provider, version). An installer packages the CLI, dependencies and the host agent for macOS and Windows. Works while that machine is awake; that is the trade the client makes for using a subscription instead of a metered key, and the card says so.

Sequence. Key-paste first - it is the card, the store, the resolver and the gate clause, and it is enough for a client to have an assistant on their own bill the day it ships. Host-connect second, on the existing host protocol; the installer third. Rising Origin's pack declares the card when Nick says he wants it.

Exit. A client instance whose pack declares the card, with no Ventari model credential in its environment, answers an Ask Executive turn using the credential the client entered on Connections, and the same instance with the row disconnected answers 403. Ventari's own instance is unchanged, proved by the harness.

Not this card. Ventari-metered usage rebilled at the $1-2K/month passthrough is the Helix tier's model, selected in the customer agreement, and is not a Connections card on a CRM-only instance.

Built 2026-09-21 (9h.1, key-paste); not yet released or live-proved. What landed, against the scope above:

• Providers: Anthropic, or the Vercel AI Gateway - not OpenAI direct. The gateway key fronts OpenAI, Google, xAI, Anthropic and Mistral on one key and the client names the model, and the gateway transport already exists; an OpenAI-direct transport does not, and is a later add only if a client refuses the gateway. AiKeyProvider = 'anthropic' | 'gateway'.
• The row (lib/connections/ai.ts, migration 20260924210000): kind ai; identity = provider; secret = the key, encrypted with the instance key, never returned; config = provider, gateway model, last four of the key. Verified before stored: a 200 on the provider's models list (api.anthropic.com/v1/models with x-api-key; ai-gateway.vercel.sh/v1/models with a bearer); 401/403 refuse; a malformed key never reaches the network; a refused key stores nothing.
• The card (Assistant): provider select, key (password field), model for the gateway; Connect verifies and stores; Disconnect clears. Copy names the product, never the agency.
• Resolution (lib/executive/client-model-access.ts, modelAccessForTenant): the agency is exactly the gate that existed. A client instance: pack declares the card + row connected + key readable → the turn's env is the seat-lane-stripped env with one lane laid over it (VENTARI_EXECUTIVE_PROVIDER pinned to anthropic with the key in CLIENT_HEALTH_INTERPRETER_API_KEY, or gateway with AI_GATEWAY_API_KEY and VENTARI_EXECUTIVE_MODEL); anything else → refused with a stripped env. No env fallback; tenant-model-gate and the boot backstop are untouched (the sync gate module did not change).
• Wired: the two Ask Executive routes (voice/respond, conversations/[id]/replies) and the dashboard layout resolve access through it; on a client the picker's hint (Claude / ChatGPT / Grok - the agency's seats) is ignored and the picker is not rendered; the launcher mounts on a pack that declares the card, so on a client it appears exactly when the card is connected. Every other model-spending route stays agency-only.
• Pack contract: integrations.ai.enabled required on every pack; Rising Origin declares it (his to connect); the agency, Helix, beeem and Cymatica do not. Rising Origin checksum moved (reason in the pin).
• Verifier: verify:ai-card (core-stability) - contract, the key check per provider, connect/refuse/disconnect with the key never in config or status, model access in every state with the runtime accepting both overlays, the routes and shell, the card render and copy. verify-tenant-model-gate and verify-command-center-ui pins updated to recognise the resolver.
• Standard: the three modes for a client's AI - own key (this), own machine (9h.2 - parked 2026-09-21: bespoke, on request, quoted; never a standard offer), Ventari-managed metered (a priced tier, not a card) - are laid out for proposals in the Brain draft client-hosting-and-ai-standard-v1.md, pending Alex and Cody's sign-off.

• Read tools on the client gateway lane (lib/executive/client-crm-tools.ts): pipeline_overview, find_contacts, list_tasks, upcoming_appointments
  • the instance's own tables through the service client, row-capped and trimmed. The agency's tools (Brain pages, its task board, repositories) never reach a client turn; the provider picks the client set only when the turn says toolSet: client_crm. Anthropic-direct has no tool loop here, so the card recommends a gateway key and says the Anthropic key is conversation only.
• The client's envelope (buildClientAssistantPrompt): the product's name, the person's role at the product, what the tools can and cannot do (read yes, change nothing yet). Replaces the Command Center envelope wholesale on a client-key turn.
• Nothing of the agency's in a client's prompt: no canon (the canon's fallback text is Ventari's identity - the co-founder line - so a client-key turn passes canonSections: []), no chief @mentions, no Command Center snapshot, no memory-offer rule; the identity line in the context pack is pack-aware with the agency default intact.
• verify:ai-card grew to 11 checks covering all of it; the voice-routes and context-pack contracts pass unchanged. Next (9h.1c): write tools
  • create a task, move a deal - through the lifecycle engine, same gating.

The maps are pickup evidence, not a second spec:

• Cody Message Triage file map. messaging-triage at 71fff2c1c6391d57c3c6b0e5e3b0adc2ecdfbd3f is Cody's source application. Codysmessages at 32d1a0941fb6ab3a7de28ef3be2945629d4c30b3 is a personal Markdown archive, not app code.
• Holistic University and client messaging file map. Donor SHAs are pinned in that file.

Corrections to earlier Phase 9i text (verified in code). (1) The native-flow runtime on main is no longer "one meta_reply plus optional end": it has wait (timer, or until reply with timeout), branch, capture_email, send_email, handoff_crm, stop, per-instance opt-out words, pause, send grants and a runs panel showing provider message ids. The 2026-10-01 and 2026-10-04 "no run receipt, no waits or branches" sentences are historical. (2) What is still missing for flows: no cron entry in vercel.json, no unsubscribe handler (marketing email refuses), staff-reply takeover is set on Facebook only (not Instagram or X), and no pack enables native_flows. (3) SOCIAL_SENDING_ENABLED gates automated sends only; the human reply path is gated by pack module and staff auth. (4) The "no direct port from Message Triage" donor row is superseded by the file-by-file classification below. Licensing and owner authorization are separate questions and are recorded separately under "Cody source reuse". (5) Several donor risks stay in force: Holistic send.ts skips its scope check when scopes are omitted, automation-gate.ts and the Apex lease fail open, Rising CRM suppression ignores query errors, and Holistic keyword precedence is by creation time with an empty list matching every DM. Ventari must fail closed and use explicit priority.

Shared foundations (one build, used by every capability). Tenant pack gating and per-account isolation, webhook_inbox, the outbox and effect guard, consent and suppression, the Meta 24-hour message and 7-day private-reply windows, per-channel throttling, audit receipts, and the Social Inbox thread model. No capability gets its own store, sender or scheduler.

Separate gates (shared foundation, different control).

Draft persistence (open product and architecture choice; recommendation, not a decision). Recommendation: keep persistence out of T1 and make it T1b. Evidence: the only tenant-safe store in this area, social_dm_triage_states (migration 20261005160000_social_dm_triage, extended for X by 20261007030000), is metadata only by its own header: "no message bodies, previews, tokens, or provider payloads". It is keyed by connection, provider account, provider and conversation, has staff-only row level security, and has no tenant column because the deployment database is the instance boundary. It has no draft, text or retention column, and nothing in triage-store.ts deletes or purges rows. A persisted draft is staff-authored text about a customer conversation, so it is a new class of stored content. The in-memory controller already solves the stated T1 problem (an edit surviving a same-analysis refresh) and was verified to have no other caller. If T1b is approved, the work is: (a) a new table beside the triage table, same key plus the analysis token, one row per staff profile and thread, with the same connection foreign key and ON DELETE CASCADE, staff-only RLS and no anon or authenticated direct grants; (b) a text length cap and a stale-analysis rule matching the controller; (c) the retention rule, decided by Alex 2026-10-07: a draft is deleted after 30 days of inactivity, on archive of the thread, on removal of the connection, and after a confirmed send only; a draft is preserved while a send outcome is ambiguous (unconfirmed, timed out or failed without a provider answer), and a failed send never deletes it; (d) deletion on account disconnect, which the cascade covers; (e) a security review confirming draft text is excluded from logs, analytics and any AI prompt until the T5 consent decision; (f) a source migration only, not applied to any hosted database from this change. Alex accepted this on 2026-10-07: T1 keeps drafts in memory and persistence is T1b. T1b implementation is not authorized by this document.

Cody source reuse: licensing versus owner authorization. These are different questions and the roadmap treats them separately.

• Verified facts. joyblisscoder/messaging-triage is a private repository owned by the GitHub user account joyblisscoder, the same account that owns VentariFullApp; this host holds admin and push access to it. It has no license file, no notice file and no contributing or use-restriction text in its README or HANDOFF notes. It has one commit (2026-09-16), authored under that account and the Ventari marketing mailbox. joyblisscoder/Codysmessages is private under the same owner, with no license file.
• What that establishes. A missing license file means no license has been offered to outsiders. It does not show that Ventari lacks permission, because the repository is held in the Ventari-controlled account. Internal reuse needs no license grant from a third party. No restriction on reuse was found.
• Owner authorization. Alex reported on 2026-10-07 that Cody directly told him to use his existing Message Triage code. That is a direct instruction relayed by Alex, with no separate document, and it is recorded here as the authorization for this reuse work. No separate written confirmation from Cody is required, and nothing in this roadmap is gated on one. The repository itself does not record whether the code is Cody's personal work or Ventari's; the authorization above is the basis for reuse.
• Separate from licensing, never ported. Personal paths, account identifiers, config.json values, the response profile file, and every message in Codysmessages. These are privacy and tenant-isolation limits, not copyright limits.
• Third-party code. The donor's dependencies carry their own terms (its README notes a WhatsApp library limited to personal-volume use). Dependencies are not copied, and no part of the WhatsApp path is used.
• Close reuse is the default where code fits. Every port keeps the donor function name, source SHA and test intent in its header or PR description, and adds tenant keys, fail-closed checks and account scoping.

File-by-file classification (donor messaging-triage at 71fff2c1; from the 2026-10-07 audit map). Classes: direct port is a near line-for-line translation with only identifiers changed; adapt keeps the logic closely and changes storage, tenancy or safety; rewrite keeps only the behavior; do not use leaves it behind. Line-level fit is confirmed in each slice's PR, not here.

Other reuse notes unchanged: Holistic additions worth taking are DST-correct send-time scheduling (email/send-time.ts), the self-authored-message skip that prevents reply loops, and the HMAC unsubscribe token pattern. Not found in any source, so new builds: social STOP handling, quiet hours, lead scoring, a template library. Source capabilities the earlier map did not cover (analytics, voice transcription, media-aware drafting, folders and pinning, calendar-link suggestions, contact memory sync) stay deferred.

Slices and dependencies. Track T is human triage and drafting, track F is automated flows, and the two share foundations but not a release.

• T1. Wire the draft controller into the Social Inbox with per-account and per-thread isolation, human send unchanged, no AI. Drafts stay in memory (the controller's current design: keyed by account context, provider, conversation and analysis token). A refresh keeps an edited draft; a page reload or sign-out discards it. No migration, no new table, no new stored message content. Safe to start now. It is the first slice of track T, not the whole roadmap.
• T1b. Persisted drafts across reloads and staff devices. Not part of T1. Needs the decision in "Draft persistence" below, a new migration, and a retention rule. Independent of T2 and T3; T5 and T6 do not require it.
• T2. Internal needs-reply and waiting-too-long views from Cody's rules. Parallel with T1. No outbound.
• T3. Delivery receipts and duplicate-send safeguards on the human reply path. Gate for T5 and T6. Parallel with T1 and T2.
• T4. Confirmed-send-only style learning. Needs T3 and the consent and retention decision.
• T5. Assisted AI drafting with staff review. Needs T1 and the provider and consent decision. Works without T4.
• T6. Batch approval and send. Needs T1, T3, T5, throttle and window checks.
• F1. Flow release readiness: schedule and heartbeat the cron, unsubscribe handler through the email port, takeover on Instagram and X, resolve the Rising Origin tenant literal. Fully parallel with track T, and the longest lead time.
• F2. Rising Origin comment, private reply, email capture, course link as a saved definition. Needs F1 and Rising Origin setup.
• F3. Outbound cadences. Needs F1 consent work and T2 rules.
• Later: analytics; media and voice context.

MVP. A client-ready first release is T1 plus T2 plus T3 on Rising Origin: the existing live inbox, persisted drafts, a needs-reply queue and receipts. F2 is the second milestone, because it depends on setup that cannot be proved from source. Fuller build: T4 through T6, F3, analytics.

Shared CRM work versus Rising Origin work. Shared: T1 to T6, F1, F3. Rising Origin only: tenant literal decision and any rename, Meta grants and webhook subscription proof, sending account, activation, one controlled provider test, release and validation. Do not enable native_flows on Rising Origin while its tenant literal is ventari.

Open decisions for Alex. (1) Tenant literal for Rising Origin: rename, or confirm no collision with agency rows. (2) Whether AI drafting may use client message content, with which provider, and the retention rule. (3) Whether style learning is in scope for Rising Origin at all. (4) Whether risingorigin/rising-crm is the intended repository for the earlier code read. (5) Vercel plan for five-minute cron. (6) Whether outbound cadences are in the first client release or later. (7) Draft persistence: decided 2026-10-07, T1 in memory, T1b later with the retention rule recorded under "Draft persistence". (8) Decided 2026-10-07: Cody told Alex directly to use his Message Triage code, so no written confirmation is required and none gates any port. The privacy limits and the file-by-file port, adapt and rewrite decisions stay in force.

Checkpoint, 2026-10-07 (late; historical, superseded by the 2026-10-08 checkpoint below). At that time nothing here was merged or deployed. No migration, client activation or live provider test has happened in these steps.

• T1 (claim #1225), Social Inbox draft wiring. The claim now lists the supporting verifier. Draft PR #1236 is open and cold review is CLEAR. Core Stability, Vercel and Vercel Preview Comments pass; the Booking production gate is skipped. Nothing is merged.
• T2 (claim #1231), needs-reply and Waiting rules. The claim now links PR #1235, which is ready for human review. Core Stability, Vercel and Vercel Preview Comments pass; Cursor and Netlify remain queued; the Booking production gate is skipped. The PR contains only the rule and inbox-route half, so the visible Waiting view stays on legacy behavior until the Social Inbox panel is wired.
• F1b (claim #1233) is separately blocked: the claim's file list did not match the required public unsubscribe route, and the worker stopped at a Git ownership guard before editing. It does not block T1 or T2. (Historical as of this 2026-10-07 checkpoint and superseded. Issue #1233 now contains the corrected files and approved decisions. See "Current status, 2026-10-09" for current state.)

Recommended order from this checkpoint (historical, 2026-10-07; superseded by "Current status, 2026-10-09"; do not follow it. T1, T2 and T2c are complete). (1) Human-review and merge T1 (#1236) after its checks remain green. (2) Finish T2's panel wiring in #1235 after T1 lands, so the inbox uses the five-day Waiting rule and snooze-reopen behavior, then review and merge the complete T2 behavior. (3) Keep migrations, client activation and provider tests on the separate Rising Origin release checklist.

Checkpoint, 2026-10-08 (historical; verified against GitHub on that date; superseded by "Current status, 2026-10-09" below; it supersedes the late 2026-10-07 checkpoint). No migration, client activation, deployment or live provider test has happened in these steps.

• T1 (claim #1225), Social Inbox draft wiring: PR #1236 merged, merge commit 5de94fb12c42234812264b577e02865a67bc4826, head 43f50b7786fd1cdebd69529065750df46e470bfc. Drafts stay in memory, keyed by account, provider, conversation and analysis token. Human send path unchanged. Core Stability, Vercel and Vercel Preview Comments passed; the Booking production gate was skipped. No browser session or live provider test was run.
• T2 (claim #1231), needs-reply and Waiting views: PR #1235 merged as squash commit aaf7702e743fbd4a59fabf71aab03c6a7596c4cf from reviewed head 835ee0e0bb9592c4c3636103d0fc6aebd5cca383. Cold review CLEAR. Core Stability, Vercel and Vercel Preview Comments passed; the Booking gate was skipped. Waiting uses the newest message's own timestamp and a five-day default. GitHub confirms #1231 is closed as completed (2026-10-08); its stale body, which said the pull request was unmerged, was corrected to the merge record. Its three limits are recorded next.
• T2 limit 1, verifier not registered: scripts/comms/verify-social-triage-views.ts runs only with node --import tsx; it is not an npm script or Core Stability check. The reviewer treated this as a follow-up, not a merge blocker. Needs its own small claim (T2c) that also registers the T1 verifiers.
• T2 limit 2, no browser or live provider test. This stays on the release checklist, not on shared product work.
• T2 limit 3, snooze reopen is applied by the inbox route and visible filter only. The single-thread triage GET and POST return the stored status without the thread's messages, so right after a newer inbound they can still say snoozed until the next inbox load. Accepted as a cosmetic limit: the list views are correct and the panel does not drive them from that response. It needs a separate claim only if another consumer starts to rely on that response.
• F1b (claim #1233, email unsubscribe): still open, unassigned, no branch or PR. No implementation exists: the earlier worker stopped before editing any file because of a Git ownership guard and a mismatch with its prompt. The claim now lists app/unsubscribe/route.ts, lib/automations/flow-crm/consent.ts, lib/automations/flow-crm/email.ts and a verifier, and requires a verified clean worktree before editing. It is independent of track T and does not block it. The assigned worktree has not been verified clean and accessible from the roadmap owner's host, so that check is still required before redispatch. It is kept separate from the #1183 and T3 work.
• T3 (claim #1232, delivery receipts and duplicate-send guard): queued. Its stated hold is "after T1 and overlap with #1183 resolved". T1 has landed. #1183's own text says the takeover binding shipped in merged #1185 and the issue stays open only for release coordination, so the overlap is now a paperwork item: #1183 has now been narrowed to release coordination and its ownership of lib/socials/dm.ts, app/api/comms/social/reply/route.ts and lib/automations/flow-crm/takeover.ts is explicitly released on GitHub. T3 may claim the reply route and lib/socials/dm.ts under its own claim; #1232's queued hold text should be updated when it is dispatched.

Where the lane stands, 2026-10-08 (historical; superseded by "Current status, 2026-10-09" below). Merged into main (available in source): human triage on three providers, the draft helper and controller wired into the panel (T1), the needs-reply and Waiting views (T2), and the flow runtime behind the default-off native_flows module. Present but unwired or off: native flows (no pack enables them, no cron entry, no unsubscribe handler), Instagram and X takeover. Still to build: T2c, T3, T1b, T4, T5, T6, F1a to F1d, F2, F3. Needed only for a client rollout: tenant literal, Meta grants, webhook proof, sending account, activation, one controlled provider test. Merged foundations do not mean flows or automated sending are enabled.

Merge receipt, 2026-10-08 (historical record of the state on that date; items such as #1225 "still open" and #1220 as a draft no longer hold). PR #1239 (this roadmap's lane reassessment) is merged as squash commit 2a44808fe24687b513ed88ab1acab50ed2a177f9 from head b1a49c73fc8f6a38c4c165a714a4bca585b294c7. It changed only docs/crm-factory/SPEC.md and regenerated SPEC.html. Core Stability, spec-guard, Vercel and Vercel Preview Comments passed; the Booking gate was skipped. GitHub state: #1231 closed as completed; #1183 open for release coordination only, with app/api/comms/social/reply/route.ts, lib/socials/dm.ts and lib/automations/flow-crm/takeover.ts released (Facebook-only takeover boundaries kept); #1232 (T3) and #1233 (F1b) open, unassigned, no branch or PR; #1225 (T1 claim) still open although #1236 merged, so its body and state need reconciling. No active native-triage worker; the older social-triage worktree is clean but stale and diverged, so preserve it and start new work from a verified clean checkout of current main.

Current status, 2026-10-09 (verified against GitHub; this governs wherever it conflicts with the 2026-10-08 notes above, which stay as the dated record). Merged: #1220 (squash e7611e1c), #1230 (7db8f45c), #1235 (T2), #1236 (T1), #1242 (T3a, 85958759), #1244 (T2c verifier registration, 34f52ae6) and #1250 (revised T3 design record, c2128922). Closed: #1225 (T1 claim). T1, T2 and T2c are complete. T3a is merged with social_dm_reply_guard default-off in every pack and no production outbox adapter, so the guarded reply route refuses with 503 and sends nothing through it. T3b (migration, production adapter) has not started. The T3 design record revised 2026-10-08 is direction only; it does not authorize T3b implementation or a migration, and the older outbox-table plan (a separate reply outbox migration) is superseded by it. #1233 (F1b, email unsubscribe) is open and unassigned, with no branch or PR; its decisions and file list are tracked in the claim and in the F1b notes. Nothing in this status authorizes a migration, deployment, provider test, gate change or client activation, and none has happened.

Next sequence, 2026-10-09 (recommendation, not a dispatch). (1) Settle the documentation PRs (#1240, then #1257); neither is merged without a human decision. (2) F1b (#1233) may be dispatched only after the docs sequence is settled and a fresh clean worktree on current main passes the Git ownership check. (3) T3b waits for an explicit decision on the revised design record; no migration is applied. (4) Deferred, unchanged: T1b persisted drafts; T4 to T6 and F1a to F1d after their gating decisions; T6 after T3 and T5.

Recommended next sequence, 2026-10-08 (historical and superseded by "Current status, 2026-10-09" below; do not follow it. Its T3 step assumes an outbox migration plan that the revised T3 design record replaces, and it describes #1220 as a draft). Claim-overlap scan on open pull requests and issues, run 2026-10-08: nothing open edits the T3 reply files or the Social Inbox panel. Two things to know. #1220 (draft) edits .github/workflows/core-stability.yml, package.json, the migration runner guards and the baseline list, so it overlaps #1230 on the workflow file and will touch the same migration ledger T3's outbox migration must pass; several other open pull requests also edit package.json.

1. T3 (#1232), now. First refresh #1232: remove the 'wait for T1 and #1183' hold and the 'owned by #1183' file note, and list the reply route, lib/socials/dm.ts, the receipt display in the Social Inbox panel, a source-only outbox migration and a verifier. Then prepare it from a clean worktree of current main. The migration is written but not applied; applying it is a separate decision. Before the migration is named, check #1220's ledger rules so the file passes the guard.
2. T2c, needs its own small claim, safe in parallel with T3. It touches package.json and scripts/core-stability-manifest.json, which T3 and F1b do not. It shares no file with #1230. Expect a textual merge conflict in the package.json scripts block with whichever of #1220, #1224, #1203 or #1200 lands first, so it should rebase and register the T1 and T2 verifiers last.
3. F1b (#1233), separate; hold until the Herdr ownership check passes. Its files (app/unsubscribe/route.ts, consent.ts, email.ts, a verifier) do not overlap T3 or T2c, so it can run in parallel once the worktree is verified clean and accessible on the Herdr side. It has not been verified from this host.
4. Deferred, unchanged: T1b persisted drafts; T4 to T6 and F1a to F1d after their gating decisions; T6 after T3 and T5.

What can proceed now / needs an exact decision / release prerequisite (historical, 2026-10-08; superseded). Proceed now (on authorization): refresh #1232 and dispatch T3; open and dispatch a T2c claim; reconcile #1225. Needs a decision from Alex: AI use of client messages (consent, provider, retention; gates T4 and T5); the cron choice (gates F1a); the Rising Origin tenant literal, audit first (gates F2); whether outbound cadences are in the first client release. Release prerequisite only, not shared product work: applying any migration, Meta grants and webhook proof, sending account, activation, one controlled provider test, browser check of the Waiting views. Merged to main is not deployed or enabled for a client; native flows and automated sending stay off unless separately authorized.

Earlier order from the 2026-10-08 checkpoint (superseded by the next-sequence note above). (1) First, clear the #1183 ownership overlap (done on GitHub; confirm before T3 is dispatched) so T3 can proceed. In parallel, no shared files: T2c verifier registration (touches package.json and scripts/core-stability-manifest.json; draft #1230 changes only .github/workflows/core-stability.yml and adds a separate test step, so the two share no file and there is no dependency or sequencing requirement); F1b unsubscribe (#1233), kept separate and only after its worktree check. (2) After #1183 is narrowed: T3, the gate for T4, T5 and T6. (3) T1b persisted drafts deferred; independent of T3. (4) T5 assisted drafting after the AI-consent decision, T6 batch send after T3 and T5. (5) F1a cron and F1d tenant literal after their decisions. (6) Keep migrations, client activation and provider tests on the separate Rising Origin release checklist.

Recommended defaults, 2026-10-08 (historical; these were proposals at the time). (a) #1183 narrowing: done on GitHub. (b) Defer T1b persisted drafts. (c) Keep AI use of client messages gated until consent, provider and retention are specified (gates T4 and T5). (d) Defer the cron choice (Vercel versus GitHub Actions) until launch needs it (gates F1a). (e) Audit the Rising Origin tenant literal collision before deciding whether to rename it (gates F2). Nothing here has been migrated, deployed, provider-tested or activated for any client.

Migration reconciliation, 2026-10-08 (read-only audit of main at merge commit e7611e1c, after #1220; supersedes none of the checkpoints above). No file, baseline, hold marker, database, pull request, deployment, provider connection, gate or client activation was changed by this audit, and no migration was applied.

• Source inventory. supabase/migrations/ holds 454 files with no duplicate versions and no malformed names. supabase/migrations-baseline.txt lists 453 entries and every entry has a file. The single file not in the baseline is 20261007030000_social_x_dm_triage.sql. That is intentional: the baseline records ordering for files that existed when it was cut, and this file was added after it. It is held, not forgotten.
• Hold markers. Exactly two files carry -- hosted: hold in their first ten lines: 20261005160000_social_dm_triage.sql and 20261007030000_social_x_dm_triage.sql. Both also carry a "Source migration only. Do not apply it to a hosted database" header, so header and marker agree. Seven other migrations match a looser "not applied / do not apply" text search (work-ledger evidence attribution, approval cards, client repo provisioning, model work admission, model failover tiers, droplet lane slots, client project bindings); none has a hold marker, and this audit did not read or classify them. Whether each is a genuine mismatch is for the human migration review; no marker was normalized.
• Baseline membership of the social DM file is not an apply record. The baseline records order only.
• Database status, agency app database only (the database the app's configured URL points to), read through the migration history table with the host's existing read-only access: 453 versions recorded, newest 20261007020000. Source versions with no history row (14): 20260928142800, 20261001120000, 20261001130000, 20261001140000, 20261002090000, 20261002100000, 20261002110000, 20261002120000, 20261002130000, 20261002140000, 20261002150000, 20261004090000, 20261005160000, 20261007030000. History rows with no same-version source file (13): 20260906050829, 20260907011015, 20260907024830, 20260907033212, 20260907212504, 20260915010000, 20260915011000, 20260915185736, 20260919185127, 20260919185133, 20260922163704, 20260928142980, 20261001213426. The two lists are not a clean diff of each other, so history rows alone cannot say which SQL is applied. The object-by-object comparison of the 14 unrecorded source versions has since been completed (see "Object-by-object audit result" below); the 13 sourceless history rows remain unresolved candidates.
• One ordering anomaly to review: 20261007020000_native_intake_binding.sql (replaces the intake commit function) is recorded while the earlier native-flow chain is not. Its dependency on that chain was not examined.
• Object-by-object audit result, agency app database only (read-only; catalog metadata and migration history only; no customer or CRM rows were read; compared against main at e7611e1c). Of the 14 source versions with no history row, 2 have matching objects (20260928142800, 20261001140000), 1 is partial (20261004090000: the requested grants are satisfied, but the revoke of INSERT and UPDATE from the authenticated role has not happened), and 11 are absent. Function checks covered name, arguments, rights and one body marker, not full bodies. The 13 history rows without a same-version source file are unresolved candidates, not proven replacements: some have text identical to a source file that has its own history row and look like re-applications under another timestamp, but none of these mappings is proven. The object-by-object audit is therefore no longer the next step. This result does not make the baseline proof of application, does not classify any migration as pending or safe to apply, and does not change either Social DM hold marker.
• Other databases (client instance databases, Rising Origin, local or disposable): unverified. No authorized read-only access to them was used, and nothing is inferred from the baseline or from the agency database.
• Social DM triage (20261005160000, and its X extension 20261007030000): intended status is source-only and hosted-held. Verified read-only: social_dm_triage_states does not exist on the agency database, and neither version is in its history, so it is not applied there. Release blockers, all open: (1) the file's own header says there is no tenant column and the deployment database is the instance boundary, so it cannot be applied to a shared database; (2) a tenant-safety review must establish a safe release path (for example per-instance only, or a tenant-scoped key); (3) the X extension depends on the first file and on social_x_connections, and its provider-specific unique keys do not add a tenant; (4) the hold marker may be removed only by a reviewed change. The hold stays.
• T3 status, revised 2026-10-08: the adapter-only design is insufficient. This supersedes the earlier "adapter over existing tables" reading. The current runtime effect guard does not bind reserve and apply to the worker lease, cannot represent an ambiguous send safely, and has no per-send receipt fields. The reply route, lib/socials/dm.ts, provider send semantics and provider-history confirmation paths have not yet been inspected, so what T3 needs beyond that is not yet established. Existing tenant scoping is unchanged: outbox_events has UNIQUE (tenant_id, topic, idempotency_key) and UNIQUE (tenant_id, id), runtime_effect_guards has UNIQUE (tenant_id, effect_key), and webhook_inbox is keyed (tenant_id, provider, idempotency_key). Any duplicate-send key must include tenant, connection and provider account, and conversation, never conversation alone; no message content is stored in receipts. Any new migration must be source-only and -- hosted: hold, use a <YYYYMMDDHHMM00> version sorting after the newest file, pass verify:migration-order, and be reviewed separately before any apply. Implementation has not started and is not authorized by this note.
• Smallest safe next step, revised. (1) Review each of the 11 absent, 1 partial and 2 present versions individually, and the 7 other migrations with "not applied / do not apply" wording, which stay unclassified until each is reviewed individually. (2) Read-only inspection of the reply route, lib/socials/dm.ts, provider send semantics and provider-history confirmation paths, to inform a T3 redesign; no T3 implementation until that review is accepted. Do not touch the social DM hold. Everything past that, including any apply, repair, marker change, baseline edit, or client database, needs its own written approval naming exact versions.

Corrected findings. (a) The job functions (heartbeat, complete, fail) check token, generation, worker, lease_expires_at > now and a running control. The effect functions do not: reserve_effect takes a job id and checks only that the job exists and its control is running; apply_effect reads the job's topic for the control check but never its lease; refuse_effect and compensate_effect check neither. (b) foundation_runtime_enqueue_job inserts a runtime_controls row with the column default running when none exists, and raises when the control is not running. (c) foundation_runtime_claim_job re-claims any processing row whose lease has expired. (d) fail_job schedules a retry (failed, later claimable) and replay_job clones a held row into a new pending job. (e) lib/socials/dm.ts has no request timeout on any provider fetch. (f) lib/socials/reply-outbox.ts stores reply text and treats a similarity of 0.88 or more as proof of delivery; both are rejected below. (g) productionReplyOutbox() still returns null, so the guarded route refuses with 503 and nothing sends through it.

1. Tenant boundary. Tenant identity for every job, guard and receipt comes from the server-resolved pack's integrations.tenantLiteral, never from the connection row (instance_connections has no tenant column and is unique per kind) and never from request input. The reply route already reads it this way for the Facebook takeover. All five packs on main (agency, Beeem, Cymatica, Helix, Rising Origin) set tenantLiteral: 'ventari', so the literal does not distinguish instances: the database is the instance boundary (one database and one deployment per client, D20). Consequences: (i) every key and uniqueness rule must also bind connection id, provider account, provider and conversation, never conversation alone; (ii) tenant_id equality is a consistency check, not isolation, so no cross-instance read or write is ever acceptable; (iii) before any guarded send the route runs a capability preflight against its own database (required tables, lease columns, effect and transition functions, service-role-only execute rights) and fails closed with 503 if anything is missing, never falling back to an unguarded send; (iv) the guard stays default-off per pack and a pack must not enable it until its own database passes the preflight. Per-instance migration state: unverified. 0065 and 0066 are core, numbered migrations (not agency-only files), but whether they, and any later runtime migration, are recorded and applied in each client instance database is not known; the agency database was audited earlier for the 14 unrecorded versions only, which did not list 0065 or 0066, and it was not re-read for this record. Nothing is inferred from the agency database. Required before any enablement, per instance and read-only, each needing written approval naming that instance: migration-history rows for 0065 and 0066; presence of outbox_events lease columns, runtime_controls, runtime_effect_guards; presence and execute rights of the runtime functions; and the social triage table, which is held.

2. Human reply job, lease and fenced transitions. The staff request is the only worker. There is no cron route, schedule, allowlist entry or heartbeat for the topic (provisional name social.reply.send), and none may be added. Sequence, each step one transaction that locks the job row, then the guard row, and re-checks token, generation, worker, unexpired lease and control state (except safety transitions, below):

1. Route, outside any transaction: requireCrmStaff, server-resolved pack, guard flag, capability preflight, live thread verification (existing pre-send reads), and a bounded history read used as diagnostic evidence only. Reject empty text here, before any intent exists.
2. begin: one function that, in one transaction, requires the topic control to already exist and be running (it must not auto-create a control the way enqueue_job does), then inserts the outbox_events job already processing with a lease, attempts = 1, max_attempts = 1, idempotency key derived from the reply intent id, and inserts the guard reserved bound to that job and its lease generation, with the conversation-scope key (connection, account, provider, conversation). A repeat of the same intent returns the stored state and never claims or reclaims; a live lease returns 409; an expired lease goes to the lease-loss path below.
3. mark_sending: fenced, reserved to sending, committed before any network I/O. Between steps 2 and 3 the route re-checks takeover and connection validity; a failure there calls refuse (nothing has left).
4. Provider call with a bounded timeout and abort, sized below the lease so one send needs no heartbeat. The lease length and timeout values are open decisions; no number is proposed here.
5. Outcome, one fenced transition: provider acceptance with a message id goes to applied (storing provider message id and time) and completes the job in the same transaction; a definitive pre-send refusal goes to refused and the job to cancelled; any other outcome goes to ambiguous and the job to held with a hold_reason. Lease loss and timeout: a fence rejection, crash, timeout or abort never retries and never reclaims. A guard in reserved or sending whose lease has expired is converted to ambiguous and the job held by an expiry transition run on the next touch of that intent or conversation and by an admin sweep; no claim path may select it first. A 2xx with a message id that arrives after the lease expired is recorded as ambiguous with the provider message id kept as evidence (conservative; the operator can confirm sent), not as applied. Principle: transitions toward progress (mark_sending, applied, complete) require a valid lease and a running control; transitions toward safety (ambiguous, hold) require only a matching token and generation, so a control flipped to held mid-send cannot strand a guard in sending. A DB-enforced partial unique index on the conversation-scope key for guards in reserved, sending or ambiguous blocks any new intent on that conversation until the earlier one is resolved; without it, staff could retype and send again past an ambiguous row.

3. Job-control lifecycle. The control row for the topic is created held by a separate release-controls step before the first possible enqueue, because an enqueue against a missing control would create it running. held is the default and the kill state: while held, begin raises and nothing enqueues. It moves to running only by an explicit, per-instance, written release decision, and back to held or killed at any time. begin runs only while running; progress transitions require running; safety transitions do not. A verifier must assert that no cron, schedule or catalog entry references the topic.

4. Drain isolation (all callers inspected, not only cron). The generic drainOutbox (lib/integrations/outbox.ts) has two importers on main: the re-export in lib/integrations/index.ts, which nothing imports, and scripts/verify-integration-inbox-outbox.ts, which uses the in-memory store. The only OutboxStore implementation is createMemoryOutboxStore; no database-backed store exists, so the generic drain cannot reach a database row today. The database claim, foundation_runtime_claim_job, takes an explicit job id and is called only by topic-specific workers (automation flows, projection state transition, reviewed-outcome projection) and by crons that filter on one topic. This is a source-level fact, not a guarantee, so the design makes it structural: (i) social-reply jobs are born processing and are never pending or failed; a table CHECK for the topic forbids pending, failed and dead_letter, which also makes fail_job retry and replay_job cloning raise for this topic; (ii) claim_job must exclude the topic family, because the CHECK does not stop a processing row with an expired lease from being re-claimed; this is a reviewed change to a shared function and needs its own disposable-database test; (iii) a repository verifier forbids importing drainOutbox outside tests and requires any future database-backed OutboxStore to exclude reserved topics. Not proven: no SQL was executed, so (i) and (ii) are design requirements, not demonstrated behavior.

5. Ambiguous sends and the operator flow. Held, never retried: a timeout, abort, crash, thrown network error, empty or unparseable response, a 2xx without a message id, and any received non-2xx. A negative history search never authorizes a resend; a fuzzy text match is not proof of delivery and must not auto-resolve (a reply cannot carry the intent id, so history can only match on text and time). Receipts hold identifiers, state, times and the provider message id, never reply text; the checksum form (plain or keyed) is an open decision. Confirmation flow, exactly one of two actions by an authorized resolver, each a compare-and-swap on the guard still being ambiguous, idempotent, and audited with actor, decision, prior state and evidence counts but no content: (a) confirm sent, which moves the guard to applied and the job to sent, optionally with a provider message id read from fresh verified history; (b) confirm not sent, which moves the guard to a distinct operator-attested refusal and the job to cancelled, and unlocks the conversation. Confirm-not-sent requires a typed acknowledgement that this determination may cause a duplicate message to the customer, a recorded reason, and the screen must show that "no matching message found" is not proof. Neither action sends anything: any new reply is a new intent with a new send. Limitation: because text is not stored, the operator compares provider history with staff recollection or a separate draft, which makes T1b relevant.

6. Authorization. Provisional resolver role is admin; team may not confirm either outcome, and agency-admin delegation is excluded until its authorization model is verified and approved (not inspected in this pass). Implementation note: requireCrmStaff returns the first of admin or team found in the user's role list, so a user holding both roles can resolve as team depending on list order; the resolver must check that admin is among all of the user's roles, not read the context's single role. The database functions are service-role only and cannot see the user's role, so the role check lives in the route and the audit row records the actor; this is a limit, not a guarantee. Separation of duties (resolver differs from sender) is an open decision.

7. Provider semantics. Only failures that occur before any request leaves are definitive: SocialDmBoundaryError (including its 502 "could not verify the live thread", which is thrown by the pre-send verification reads and must not be confused with a provider send 5xx) and input validation. Current code mis-types two local failures as plain errors that the guard would hold (empty text, "X is not connected"); they should be rejected before an intent exists or typed as pre-send. Every received non-2xx from Meta or X stays ambiguous until primary provider documentation, read and cited, supports a specific definitive pre-acceptance case; that documentation review has not been done.

8. Retention. Receipt retention is an open founder decision. No duration is proposed or implied.

Remaining decisions (none made here). Lease length and request timeout; checksum form; whether a late provider acknowledgement after lease loss may ever auto-confirm; separation of duties; whether confirm-not-sent needs a second approver; receipt retention; per-instance preflight and read-only verification approvals; provider documentation review; and the final topic and state names. Unchanged: both Social DM hold markers, the default-off guard and sending flags, and every release control. Any migration for this design must be source-only and -- hosted: hold, pass verify:migration-order, and be reviewed separately before any apply.

Merge receipt, 2026-10-08. Docs PR #1248 merged into main as squash commit 86859190e29b75b2ad2238c5883fa0a72a1ce720, pinned to reviewed head c93bf1a276b46d6f7f9f0d904db548caa9771d7a. Core Stability, the spec guard, Vercel and Preview Comments passed; Booking was not listed in the current check rollup, so it is not recorded as passed. The audit's source anchor stays e7611e1c, the commit it examined; the merge commit is the record of when the findings landed, not a new audit anchor. #1248 changed documentation only: no migration was applied, no database or migration history was changed, and no deployment, gate change, provider test or client activation occurred.

Holistic also has a durable, versioned workflow runtime with delays, bounded conditions, tags, email/Meta steps, leases, retries, run receipts, and reconciliation holds. Reuse its lifecycle and recovery patterns selectively. Its generic producer currently requires a resolved CRM contact before enrollment. Its generic workflow capability exposes no active Meta account in production.ts (metaAccounts is an empty set); hu-admin uses separate activation-readiness logic. These limits mean it cannot be copied unchanged for a comment trigger that must reply before CRM identity resolution. Keep one Ventari runtime and adapt the donor behind Ventari's tenant, account, permission, outbox and identity services.

Message Triage is Cody's personal local inbox: useful patterns include response-style learning from confirmed-sent messages, human-reviewed drafts, thread context, throttling, and local outbox/double-send protection. It does not provide client-scoped webhooks, unattended campaign execution, CRM identity handoff, or a deployable flow builder. The separate Codysmessages archive is not a flow runtime. Do not copy personal message stores, credentials, identifiers, or memory into the CRM.

The recent ApexRx CRM has a durable When/Then/If CRM automation engine and email sequence jobs. A prior audit reports lead/stage email sequences and send suppression in risingorigin/rising-crm, but the named joyblisscoder/rising-crm URL returned 404 and the repository owner/path did not match. The Herdr operator confirms that worker 01 read code-only files from the alternate repository; no customer or production data was accessed. Treat those findings as provisional until the Brain confirms that this is the intended repository and accepts the out-of-scope code read. Neither repository is known to supply social comment/DM triggers or a customer-facing DM campaign. Community chat in other client apps is user-to-user messaging, not autonomous marketing automation. No inspected client repo closes the end-to-end gap by itself.

Within Ventari, extend the existing tenant pack and encrypted Meta connection model from Phase 9f; use webhook_inbox for verified, deduplicated provider events, a dedicated automation_flow_runs row as authoritative runtime state, the existing automation_runs ledger as the human-visible projection, and the existing outbox/retry patterns for provider calls. Do not add an event ledger unless implementation review proves the two existing records cannot support required history. Do not create a second CRM, inbox, credential store, or generic scheduler. A comment-triggered flow must start before its sender is a CRM person or opportunity; the existing CRM rules runner is for effects after identity-safe handoff, not a prerequisite for the first reply. Persist a versioned flow snapshot and execution cursor so an instance-owned definition resumes safely. The Automations tab is the authoring surface and must publish a saved, inspectable version the runtime can execute, rather than treating AI prose or catalog steps as executable instructions.

Donor-to-Ventari port map (audit 2026-10-01). Port behavior and safety invariants, not Holistic's tenant tables or account-selection assumptions. The donor's component boundaries map to Ventari as follows:

First build boundary. Implement deterministic authored steps first:

1. Trigger on an eligible Instagram or Facebook comment, or a new inbound DM; support an explicit keyword/phrase match and account/media scope.
2. Send an approved Instagram comment private reply or eligible inbound DM through the existing connected Meta account; record the provider receipt and make retries idempotent. The first executable flow shape is one saved meta_reply step followed by optional end. Facebook inbound-DM replies and comment private replies require pages_messaging and their respective provider windows; comment event intake and read permissions must also be proved. The worker route exists but is not on a client cron allowlist or schedule, so do not promise automatic or delayed execution yet.
3. Wait for a configured interval and continue from durable state. A client instance may ship with no cron routes, so the build must define and monitor one pack-allowlisted delayed-step worker before promising waits. Never add a cron per flow.
4. Branch only on explicit, bounded reply conditions in the first release. Stop automation on opt-out, a human reply/takeover, provider-window or permission failure, or a kill switch; surface the reason in Runs.
5. Resolve the social sender to a CRM person without silently merging people. Create or update an opportunity only through existing identity-safe CRM services. Record a named owner and handoff task when the configured goal is reached.

1. Read-only review wave (parallel)

   (a) cold-check the existing donor coverage and port map, focusing only on unresolved Holistic runtime behavior and source claims rather than repeating the completed repo sweep; (b) trace the current Ventari branch from Meta event to trigger, flow run, sender and outbox, including what the code cannot prove about live provider setup; (c) map the Rising Origin journey to existing consent/email/identity/CRM services and list decisions still owned by Cody/client; (d) audit client capability installation, scheduling/hosting, Automations UI and run operations. Each worker reports exact source paths, verified behavior, unknowns and recommended reuse; no product edits.
2. Owner review and preservation gate: On 2026-10-02 Alex accepted Codex's internal review in place of waiting for Brain credits. Brain review remains welcome and may revise these defaults, but is not a dispatch blocker. Keep the risingorigin/rising-crm findings excluded from implementation decisions unless their owner/path is confirmed. Do not dispatch implementation workers until the uncommitted foundation has a verified preservation checkpoint and Alex has authorized the worker wave.
3. Interface freeze (operator): use the adopted defaults below as the baseline, then translate them into the typed, versioned flow contract, run/event/outbox receipt relationship, consent/identity/handoff interfaces, per-instance activation gates, and exclusive file ownership. Reopen a default only when source evidence or implementation constraints require a change, and record the reason for Brain review. Do not begin parallel implementation before this contract is stable.
4. Implementation wave (parallel only on disjoint ownership): (a) bounded durable flow runtime; (b) Meta event and delivery adapters; (c) Automations authoring, validation, preview and run operations; (d) adapters to existing CRM identity, consent/suppression and email delivery; (e) dormant per-client installation, schedule and health/runbook. Existing inbox, connection, outbox/effect guards, identity, email, and scheduler infrastructure take precedence over adding parallel systems. Shared schema, migration, or contract changes remain operator-owned or serialized.
5. Integration and independent review: operator integrates without losing pre-existing changes, updates Markdown and its generated HTML together, and records implemented/partial/unverified/deferred status. Parallel reviewers separately inspect safety/tenant isolation, runtime/recovery behavior, and product/setup/rollback completeness. Fixes have one named owner at a time.
6. Review and launch gates: provide source-reuse map, architecture and node contract, Rising Origin example, supported per-instance capability matrix, test evidence, known limits, and explicit client decisions. Run the complete journey on an approved test account. Production sending stays disabled until exact content, timing, consent, channel authorization, owner/SLA, and immutable flow version are approved. Review readiness is not deployment or activation approval.

The operator prompt, numbered worker prompts, report paths, allowed file ownership, and verification commands must agree with this plan before agents are dispatched. Read-only discovery may fan out immediately; implementation workers wait for the interface-freeze gate. Do not use hidden in-session subagents in place of visible Herdr worker panes.

Per-instance setup SOP (once the feature ships).

1. Confirm the client owns/administers the Meta app, Page and linked professional Instagram account, following Phase 9f's model-B procedure. Never connect a client's account to Ventari's agency app.
2. Connect the Page and Instagram account on the instance's Meta card. Set the instance's META_WEBHOOK_VERIFY_TOKEN, callback URL and app secret; configure the webhook fields and permissions required for message and comment events. Confirm the deployed release exposes the callback and Meta verifies it. Check the required permission/field list against Meta's current official docs before each setup; Phase 9f's existing publishing and inbox scope list alone is not proof of webhook subscription.
3. Send a signed provider test event and confirm it is accepted once, stored under the instance tenant, deduplicated on replay, and rejected for a different account or invalid signature. Confirm the event reaches a flow preview without sending a customer message.
4. Configure and save the flow: exact trigger and keyword, account/media scope, approved messages/media, waits, reply branches, stop/opt-out rules, CRM goal, human owner and handoff SLA. All values are specific to that client and live in its instance data.
5. Run preview and delivery-path checks, resolve permission, identity, schedule and provider-window holds, then obtain the client's explicit approval of the published flow and send authorization. Activate only that version. Confirm kill switch, event receipts, failed-send visibility and human handoff before declaring the campaign live.

• Flow contract: immutable, validated flow.v1 definitions with explicit comment/DM triggers and typed meta_reply, wait, bounded branch, capture_email, send_email, handoff_crm, stop and end steps. Limit a flow to 12 steps and a total wait horizon of 7 days. Reject cycles and open-ended AI responders. A published version hash pins each run.
• Matching: exact, whole-phrase and contains modes use Unicode and case normalization. Whole phrase is the default. Preserve each client's trigger values, apply explicit priority, and run only the highest-priority matching flow for each event.
• Receipts: automation_flow_runs is authoritative for runtime state and cursor; existing automation_runs is the operator-visible run history and evidence projection. Provider events remain in webhook_inbox, and sends link to existing outbox/effect guards. Add no separate event ledger unless technical review demonstrates a specific missing requirement.
• Roles and send approval: Ventari staff author and publish v1 flows. The client reviews and approves the exact content and grants or revokes a per-flow send authorization. Client controls include view, pause and stop; client editing can follow once the role model supports it. A flow cannot grant itself permission to send.
• Capability gate: one default-off native_flows capability, enforced server-side on API, webhook and worker paths. Hiding navigation is not authorization. Keep agency outbound disabled and retain SOCIAL_SENDING_ENABLED as an outer kill switch.
• Scheduling: one pack-allowlisted worker per client instance with a monitored heartbeat; no worker per flow. Recommend a five-minute Vercel Pro schedule for Rising Origin only after confirming plan and cost. Hobby allows daily schedules only, so it cannot support promised sub-daily waits. See Vercel Cron usage and pricing and Supabase Cron. Supabase Cron remains a fallback for Brain review if it better fits operations.
• Safety and recovery: fail closed on tenant/account/scope/window, authorization, consent and suppression checks. Hold ambiguous sends for an explicit, audited staff resolution; never blindly replay them. Persist opt-outs and human takeovers and stop the affected run.
• Identity and email

  retain a provider-scoped provisional identity until email is supplied; treat captured email as unverified and never auto-merge on it. Route collisions to review. Use a durable consent reader/writer against the existing consent schema if it supports the required policy; otherwise extend that consent service rather than adding a parallel ledger. Fail closed, keep requested course delivery consent distinct from ongoing marketing consent, and honor durable STOP/unsubscribe suppression. Do not verify an email solely to deliver a specifically requested course link after consent and suppression checks; require verified ownership or client-approved review before associating it with an existing CRM identity.
• First campaign: Rising Origin's first flow is the ad-comment-triggered mini-course campaign, on one client-owned social account with one approved comment trigger and authored private reply. Add email capture and course-link delivery after Rising Origin supplies approved copy, destination URL, consent language and a named owner. The success goal is course requested and delivered plus a CRM handoff task; do not assume booked call as the goal.
• Evidence boundary: the risingorigin/rising-crm findings remain provisional because the named URL returned 404 and the alternate owner/path needs Brain confirmation. The operator records a code-only read and no customer/production-data access. This does not authorize reads of other unlisted client repositories. Preserve the dirty foundation branch untouched; checkpoint it on its own branch before creating separate implementation worktrees.

Source corrections from the 2026-10-01 review. The Facebook donor scope list contains pages_manage_engagement, which Phase 9f prohibits; do not port it. The migration-scope verifier already exists at scripts/migrations/verify-agency-scope.ts and is run as npm run verify:migrations-agency-scope.

• crm-factory-native-chatbot-2026-09-30/reports/03-repository-coverage.md
• crm-factory-native-chatbot-2026-09-30/reports/02-crm-native-implementation-map.md
• crm-factory-native-chatbot-2026-09-30/reports/01-source-access-and-capability-audit.md
• crm-native-automation-build-2026-10-01/reports/01-donor-evidence.md
• crm-native-automation-build-2026-10-01/reports/02-ventari-runtime.md
• crm-native-automation-build-2026-10-01/reports/03-rising-origin-journey.md
• crm-native-automation-build-2026-10-01/reports/04-instance-operations.md
• crm-native-automation-build-2026-10-01/reports/05-interface-freeze-proposal.md

The one that changes what onboarding is. While REGISTERED_PACKS is a compiled array, every client is a release of the shared codebase, nobody can be onboarded during a code freeze, and client five is a merge conflict in the same file as client four.

• A pack registry the application reads at runtime rather than compiles.
• A binding that points at an unknown pack must fail loudly, never silently drop. That is today's behaviour and it is how a misconfiguration becomes invisible.
• The unbound-host finding is decided here or explicitly deferred again. A host with no binding currently resolves to the agency pack and renders Ventari's chrome. verify:client-surface-leak:unbound already asserts it and exits 1.

Exit: a new client can be registered and bound without a merge, and verify:client-surface-leak still passes against the new registry.

Watch for: the leak check asserts that every pack registered in tenant-context appears in its own table. A runtime registry must keep that assertion meaningful, or the check quietly stops covering new clients.

How a schema change reaches every client. Code propagates on deploy. Schema does not.

• A way to apply a migration across every client database.
• It reports per database: applied, skipped, failed, and current version. A fan-out that cannot tell you which clients are behind is not a fan-out.
• Drift is visible without being asked for. A client behind the application's expected version should be discoverable before a user finds it.

Exit: a schema change can be applied to every client database in one operation, and the current version of every client is knowable at any time.

This is the phase that makes the one-product model real. Without it, "we maintain one product" is true of the code and false of the data.

Third correction, same night (#703 CI red on client-deploy-smoke): verify-client-deploy-action.ts pinned the new probe; verify-client-deploy-smoke.ts still demanded the old body string in the workflow. Both verifiers pin the same contract: 404, no Ventari surface, not the app's not-configured page.

• -- scope: agency in a migration's first ten lines marks agency data. scripts/apply-migrations.mjs skips it on a client target (--expect-pack other than the agency pack), reports it as skipped, never pending, never applied, and refuses --only on it. A scoped migration carries no DDL, because a skipped migration must not leave a client schema behind; a migration that needs both is split, or its data half gains a no-op path (RETURN when the organisation is absent) and stays core.
• verify:migrations-agency-scope (core-stability) fails a migration from version 20260922000000 on that writes a specific organisation at top level without the header or a WHERE EXISTS, or whose DO block asserts one with no RETURN, or that is scoped and carries DDL. Mutation-tested on all three. Older migrations are reported as residue: client_roster_truth and client_roster_correction (09-14) are the same pattern and reached Rising Origin only because his organisation set happened to satisfy them.
• The deal-stage move is not a migration's to make. The lifecycle function wants an actor, a reason and the expected revision - evidence a migration cannot honestly supply. Roster and deal changes for the agency's clients are made in the app, under a name. beeem_paid_client was rewritten on this rule before its first hosted run.

Only now is there something worth automating, because Phases 9 to 12 have made each step real and measured.

• Rows 3 to 6 become repeatable: database project, deployment, env and host bindings, domain.
• Whatever cannot be automated is written down as a named manual step with an owner, rather than left implicit.

13a - Client release transport. CLI standard adopted 2026-09-27.

Parked action history (2026-09-20, after v25-v28 on Rising Origin). The GitHub workflow below previously dry-ran a tag, published a Release, waited on the environment gate, shipped and smoked. Its rules remain recorded for later versioning-system review; they are not current operator instructions.

Rules the action carries:

• Triggers on a stable release tag per pack, never on a push to main. Legacy production tags retain client/<packId>/v<n>; new stable tags use client/<packId>/v<major>.<minor>.<patch>. A client instance moves when Ventari publishes a stable GitHub Release and clears the existing client environment approval, not on every merge.
• One pack, one project. The workflow maps packId to the three identifiers (VERCEL_ORG_ID, VERCEL_PROJECT_ID, token secret name) from a checked-in allowlist; a tag for a pack not in the list fails before it builds.
• The host binding is asserted, not assumed. Before deploy, the action reads the target project's TENANT_PACK_HOST_BINDINGS and refuses if it does not bind to the tagged pack. Deploying Ventari's pack into a client's project is the failure this exists to prevent.
• The client's existing project, not a new one. Revised the same day: Alex did not want to ask Nick for a new project. A Vercel project holds many deployments and one production alias, so the demo is a preview deployment into his existing project (its own URL, his domain untouched), the migration is the same deploy promoted to production (his domain follows), and the rollback is Vercel's promote-previous-deployment. The one hand step at cutover: disconnect the old repository's Git integration from that project, or a push to the old CRM would redeploy over the new.
• Secrets never enter a worker lane. The workflow and its checks are built and proved with a dry run that builds and prints what would be uploaded; the first real deploy is Alex and the operator with the token in GitHub secrets.
• 2026-09-15. The smoke's probe is the check; the judge's verdict is recorded, not enforced.

13a.1 - Client release versions for people and bots. Future design; implementation parked 2026-09-28.

New client release labels use:

client/<packId>/v<major>.<minor>.<patch>              production
client/<packId>/v<major>.<minor>.<patch>-preview.<n>  preview candidate

The word is preview, not rc, because the label must be understandable to a client, operator, and bot without translating release jargon. Every normal ship increments the minor number and resets patch to zero. Production v1.37.0 makes the next line v1.38.0; a production bugfix is also the next minor, not v1.37.1. There is no patch/hotfix lane yet, and the coordinator refuses one until a later approved policy defines it. The first code-bearing candidate is v1.38.0-preview.1. A changed candidate becomes preview.2. Rerunning the identical commit reuses its existing preview tag; GitHub's run ID and run-attempt number distinguish the attempts. A retry therefore never invents another product version.

Tags are immutable. A bot never moves, deletes, or force-pushes a release tag. Preview allocation is serialized per pack and still uses an atomic push. If two allocators collide, the loser refetches and recalculates once, then fails for review rather than overwriting history.

GitHub does not emit another workflow run for most events created with a workflow's own GITHUB_TOKEN. After the coordinator publishes the stable Release, it therefore calls the same reusable production deploy executor directly and proves the Release exists first. A stable Release published by a person still uses the ordinary Release event. Both paths wait on the same client-environment reviewer; neither deploys from a tag alone.

Legacy tags remain exact evidence and receive a display normalization only: client/<packId>/v<n> is shown as v1.<n>.0. Rising Origin's last stable published Release remains exact tag client/rising-origin/v37, displayed as v1.37.0; the latest manually CLI-promoted Vercel production deployment uses source 788cd1bd and has no matching stable GitHub Release. Do not treat the tag as proof of that deployment's source or as a current deployment receipt. Unpublished tags including v35, v36, and v38 through v43 are examples of the general rule: a tag without a published stable Release is not production. They do not advance the baseline or occupy an ordinal on the new preview line. They stay in Git history and are never moved or deleted. The first new candidate line is client/rising-origin/v1.38.0-preview.1.

Build bots use one release coordinator rather than implementing these rules independently. The coordinator reads published Releases, existing tags and the requested immutable source commit; emits an exact and normalized version receipt; creates or reuses the preview tag; and calls the existing deployment executor. Production promotion remains behind the existing client-specific human approval boundary. The complete allocator, concurrency, failure and verification contract is docs/superpowers/specs/2026-09-27-crm-factory-client-release-versioning-design.md.

The promote operation accepts only packId, the exact previewTag and its previewRunId. It downloads that run's receipt, validates it through scripts/client-release/cli.mjs, proves the candidate is reachable from current origin/main, and repeats the baseline/tag validation after the human approval wait. It then creates the stable tag at that exact SHA, publishes and re-reads the stable GitHub Release, and calls the same production executor, which independently repeats Release/tag/SHA validation and retains the client environment gate. A failed production job is rerun at the same stable Release after an environmental correction; a code change starts a new preview and the next minor line.

Client release versions are separate from the CRM Factory/platform version, database migration versions and pack schema versions. Release receipts record the factory source commit, but this lane does not change package.json or claim a new platform release.

The current bot-facing CRM Factory instructions must use the cross-platform CLI procedure and must not invent a GitHub version string. If the integrated coordinator is later approved, the Phase 14 factory skill must inherit its minor-only version rule verbatim. This release policy does not start Phase 14.

13b - The demo path for Nick, in order

1. B and F merge; six surfaces converted.
2. The gate: his real export on a local stack, host bound to his pack, Alex and the operator side by side with his current build, pack adjusted.
3. Revised 2026-09-12: no demo database. The demo is his export on a local stack on Alex's desktop (docs/crm-factory/runbooks/cutover.md, sitting 4: nine minutes from a clean stack), recorded as a Loom. Costs nothing, needs nothing from him, and the first deployed instance he touches is the real one. Rollback is the pre-cutover snapshot plus Vercel's promote-previous.
4. The GHL mirror and the public intake route (Phase 13d, scoped the same day) so leads reach the new instance from day one without hands.
5. The migration: tag client/rising-origin/v1, production deploy into the same project (his link unchanged), env pointed at his real database after the live cutover. The cutover runs through the Supabase Management API with a collaborator token if that path proves out read-only first; otherwise his database password. At initial cutover his CRM shipped zero crons (no vercel.json in rising-crm). Current pack deployments ship three daily routes: the standard GSC snapshot at 06:20 UTC, the standard measurement snapshot at 07:20 UTC, and Rising Origin's automation-rules tick at 08:40 UTC. The route allowlist and override are in deploy/clients.json.

13d - A client's GHL as a connection (landed)

A client whose front door is still GoHighLevel connects it themselves on /settings/connections. The pack declares integrations.ghl.locationId as a guardrail only (Rising Origin: his sub-account id; agency and Helix: null). The client path stores a Private Integration token encrypted on instance_connections kind ghl; the platform path uses GHL_AGENCY_API_KEY when the pack already names a location. Connect verifies the location endpoint. The Calendars page lists that location's calendars read-only. An inbound mirror upserts people, organisations, opportunities and appointments from contacts and events, keyed on the GHL id, and feeds the attribution ledger. Nothing outbound. The agency pack has no card and no route; Ventari's retired-GHL rule is unchanged. No GHL credential enters a worker lane.

13e - GHL exit, three replacements (scoped 2026-09-15)

Not a big-bang. Nick works in one CRM; GHL is cancelled when the third replacement is live. Detail and file paths: docs/crm-factory/ghl-exit.md.

• forms remains the single inventory with explicit agency_catalog and instance ownership. Catalog refresh can update only catalog-owned rows. Instance drafts are database-owned; each publish creates an immutable form_publications snapshot and moves the current-publication pointer.
• The neutral project-request-v1 template creates an inactive instance draft. A Project Request can match the same person as a Journey Access Checklist, but it cannot create, verify, waive, complete or advance a checklist item.
• form_adapter_connections is a service-only multi-row store, so several forms and several provider credentials coexist without changing the one-row-per-kind semantics of instance_connections. Secrets use the instance encryption key and appear only once on create or rotate; status payloads expose safe state, counts and timestamps, never ciphertext.
• Native form, legacy website and ChatbotBuilder ingress all normalize to one bounded envelope and call the same atomic service. A successful commit writes the person/organisation/opportunity mutation, durable idempotency receipt and immutable intake evidence together before a retryable post-commit automation dispatch. Evidence explicitly records executionAuthority: false; conflicts are preserved as evidence and do not overwrite canonical facts. Staff read the bounded evidence through /api/clients/[organizationId]/brain/evidence/intake, with exact instance identity binding and no-store responses.
• ChatbotBuilder uses one connection per form/provider row. Bearer Authorization is the shipped mode. The provider-editor probe could not be completed, so no JSON-body secret fallback ships. The approved architecture permits that fallback only after a recorded failed header probe, only in preview, with the secret removed before validation, digesting, evidence or logging; production would still need a separate explicit exception.
• Provider ownership stays outside the CRM. The client owns the ChatbotBuilder and Resend accounts. Direct ChatbotBuilder SMTP uses smtp.resend.com, port 465 SSL, username resend, and a client-owned sending-only domain-restricted key entered in ChatbotBuilder. Opens and clicks for provider-sent mail are outside current CRM receipts; CRM-sent mail retains its existing Resend receipt path.

At merge, the capability's build proof was local and synthetic: schema, real disposable-Postgres runtime, renderer, public routes, adapter lifecycle, canonical ingress, Forms, Connections and factory-presence checks were green. That evidence did not itself authorize hosted migration, a live form, website embed, production traffic switch or deployment. Rising Origin's later migration and deployment are recorded in §4b. They still do not prove a real website submission or provider request. Packet A remains parked, and each public cutover retains a separate approval gate. Phase 14 stays blocked.

1. Form intake (first, pure client lane). Built 2026-09-20; not yet released or live-proved

   His website POSTs a Project Request to GHL form yOljZNFvrgWLPtSfHlwD today. The replacement: POST /api/intake/[packId]/[formKey] on the instance host, pack-driven (pack.integrations.intake: enabled, formSource, allowedOrigins; Rising Origin declares it with his two site origins, the agency declares it with ventari.media for the proof; beeem and Helix do not). A Website form card on Connections: one Connect button that mints the form key and shows the address; Disconnect turns it off; connecting again mints a new address. The card shows nothing else - no secret, no rotate. (The API also mints an HMAC signing secret, returned once to the admin call, for a client whose site posts server-side; the card does not surface it.) One submission becomes a person (matched by email), an organisation when a business name was given, and a deal at the first stage of the pack's pipeline with attribution evidence (formSource, landing URL, referrer host, UTM) - the GHL mirror's write pattern with source intake; the same person inside ten minutes is one deal. Fields are the canonical keys (fullName, email, phone, businessName, website, businessType, need, problem, timeline, budget, consent) with his GHL form's labels accepted as aliases; extras kept, bounded. Deviation from the 09-15 wording, recorded: "signed with a per-connection secret" assumed a sender that can keep a secret. His site is static (Vite, no server), so a secret in the page would be public - and so is the form key, which sits in his site's code: it is an address, not a secret. What stands between the endpoint and junk, stated honestly: the pack's origin allowlist (CORS - a browser cannot fake it, curl can), persisted rate limits that fail closed (12 per minute per IP, 60 per hour per endpoint so a spread of IPs cannot flood the pipeline), a honeypot field, and the duplicate window. The same posture as Formspree or Netlify Forms. The consequence of abuse is junk deals the client can delete. Named upgrade, not built: if junk ever becomes a nuisance, a Cloudflare Turnstile token check - intake.turnstileSiteKey on the pack, the Turnstile secret pasted on the card, one verify call in the route, one script tag on the site; half a day, no change to anything above; the route behaves as today when the pack has no key. Decided 2026-09-20 (Alex): not now - nothing is built until one real junk submission lands. When it does, Turnstile over reCAPTCHA: invisible for nearly every visitor where reCAPTCHA v2 shows a puzzle that costs leads; a pass/fail answer where v3 returns a score to tune; no badge required; no Google tracking on the client's site; free. It needs a Cloudflare account (widget = site key + secret), not a Cloudflare-hosted site; the CRM's only contact is one server-side verify call per submission, failing open if Cloudflare is down so a lead is never lost to a spam filter. Whose account: the client's (the Meta and Resend rule). Rising Origin already runs risingorigin.com DNS on Cloudflare, so his widget goes in his account; Ventari's Cloudflare account only for a client who has none. His DNS being on Cloudflare protects his site, not the CRM endpoint on Vercel - Turnstile is still the form's guard. No-account fallback if a client refuses Cloudflare: a proof-of-work token computed in the page, same shape, stops scripted spam, not a determined sender. Vercel BotID does not fit (it guards routes in the page's own Vercel project; the site and the CRM are separate projects). The HMAC signature (x-intake-timestamp, x-intake-signature, five-minute window) exists and is enforced whenever a request carries it, and required when the connection says so - the one guard curl cannot pass, for a client whose site posts server-side. verify:intake (core-stability) covers the contract, connect/disconnect with the secret encrypted and returned once, the absolute address, field normalisation, the write path on an in-memory CRM, the duplicate window, the signature, and the card (Disconnect only when connected; no secret rendered). Proof order (Alex, 2026-09-20): the agency instance first - fan out 20260923120000 to Ventari's database, Connect the card on the agency instance, one post with an allowed Origin becomes a deal at the first stage of ventari_sales, the same post again is a duplicate, a post from a foreign origin is 403; then v30 for Rising Origin. Exit: his /contact form posts to the endpoint and a submission is a deal on rising-crm within seconds; then the GHL form is retired. The site-side change is in his site repository and needs the explicit ask §13e names.
2. Automations (product then client). Built 2026-09-21 (13e.2); not yet released or live-proved

   The two GHL form workflows ("email the owner; email the requester") are two rule templates on the client's own pipeline (lib/automation-rules/client-intake-rules.ts): trigger stage_entered at the pipeline's first stage, condition source in [intake], action send_email - new in the rule schema, to: team | contact, subject and body with {{name}} / {{deal}} / {{stage}}. On a client instance the action sends through createResendSender(), which resolves the client's own Resend key from Connections and refuses without one; the team address is only what the client connected (mailbox, else the sending from-address, else the pack's declared inbox) - never an environment fallback. On the agency pack send_email never sends: it degrades to the review draft, so founder decision #1 (no automated outbound from the agency) and the runner verifier's literal assertion on actions.ts stand unchanged. The intake route fires stage_entered inline after a created deal (runRulesForEvent, fail-open), so the stage-entered rules need no cron. Follow-ups that fire a number of days after a deal is created (days_after_created) do need the daily rule tick, /api/cron/automation-rules. The client pack's entry in deploy/clients.json carries it once a day (40 8 * * *); see Standard client crons. The ventari tenant literal was never the problem: every instance's database uses it (packs carry tenantLiteral: 'ventari'). Seeded per instance by scripts/intake/seed-client-intake-rules.ts --pack <id> [--apply] [--activate]: refuses the agency pack, a pack without intake, and a mismatched instance_identity; gates land is_active=false; --activate refuses until the client's sending key is on Connections. Rising Origin's pack now exposes three Automations pages (General, Rules, Runs; the rest answer 404 for it, pack-driven in lib/automations/surface-access.ts), so once that build is deployed its rules are switched on from General with the client; until then, and for any pack that does not declare the surface, that flag is how a client's rule is switched on. verify:client- automations (core-stability) covers schema, templates, evaluation on a client subject, the four send outcomes, the agency degrade, the event wiring, the boundary and the seed's refusals. Exit: on his instance, one real website submission emails info@risingorigin.com and the requester, from his own address, and both land as ran in Runs.
3. Booking as a pack surface. Built 2026-09-21 (13e.3); not yet released or live-proved

   Decided 2026-09-19 (§5 item 12). What changed: one route loader for the instance (lib/booking/routes-for-instance.ts) replaces fourteen private copies

   • the agency keeps rows-else-its-defaults plus the Helix route; a client instance gets its booking_routes rows and nothing else (an empty table is "no routes", never Ventari's Calendly links, never Helix); an unbound host gets none. The public page, the slot picker and the unavailable page render in the pack's tokens and the unavailable page emails the pack's declared inbox. Booking copy on a client instance names the product (clientBookingBrand), never the agency or Helix. The shared busy calendar is the agency's only: a client instance never reads ventarimarketing@gmail.com; its hosts' own calendars are the only busy source. The instance is resolved from the deployment's own production host through the host bindings (lib/tenancy/instance-pack.ts, one home for the lookup the sender and the rule runner carried inline). Host = the person whose Google is connected on the client's Connections card; the seed (scripts/booking/seed-client-booking-route.ts --pack <id> --host-email <email> --origin https://<host> [--apply]) refuses a host with no calendar, the agency pack, a mismatched instance_identity, an existing key, and never writes a Calendly target. Known gap, on purpose: booking-reconcile runs every ten minutes on the agency; Vercel Hobby allows daily crons only and the client allowlist copies the source schedule, so his crons stay empty - the public status endpoint is the fast path and reconcile is crash recovery; a per-client schedule override is the fix when it matters. verify:client-booking (core-stability) covers the loader per instance, fail-closed hosts, the env-bound pack, brand copy, shared busy, the surfaces, and the seed's refusals. Exit: his site's Book-a-Call points at rising-crm.vercel.app/book/intro-call; one real booking lands on his Google calendar and as an appointment in his CRM; the GHL widget is retired; he cancels GHL.

His site www.risingorigin.com (pack productionHost is null): Book a Call widget https://api.leadconnectorhq.com/widget/booking/9r0PXwwRF6yzBe9MJSwj on / and /fractional-cto; Project Request form https://api.leadconnectorhq.com/widget/form/yOljZNFvrgWLPtSfHlwD on /contact. Chat widget off (Alex, 09-15). Site cutover still needs an explicit ask.

Forms tab pack-aware visibility, fixed locally 2026-09-28; not yet released.

The route decides agency versus client by resolving the pack from the request's own host, never from a stored preference: GET/PATCH in app/api/automations/forms/route.ts call isAgencyFormsHost (new, lib/forms/visibility.ts), which calls the same resolveTenantContext the publications route already used and reads agency only when the resolved pack is the Ventari agency pack. Any other result — including an unbound or unrecognised host — resolves to client, so a host nobody has registered shows nothing from the catalog rather than everything.

Test coverage. scripts/verify-automations-forms.ts proves the chain in five layers; the fourth layer also has a matching console-level render check:

• Store behaviour, given an isAgency boolean (commit b99ddfdc): the agency case seeds and lists exactly the four FORM_CATALOG rows plus instance rows; a client case (generic in the fixtures, not the named client, to satisfy verify:no-client-material) never seeds, hides a pre-existing leaked catalog row, and returns only its own instance row; an unbound/unknown host seeds and lists none of the catalog; a client PATCH on a catalog row is refused with the same not-found response a missing form gets, and the row is proved untouched.
• The host decision alone, section 9 (commit 804d5673): isAgencyFormsHost, called against the real resolveTenantContext (no stub), resolves the named Ventari agency host and the local-dev fallback to agency, and a synthetic client host, an unbound host and a null host to client. Sections 9 and 10 together are the durable coverage of host → resolved pack → visible forms; nothing else in this lane proves that chain.
• Host through to what the tab actually shows, section 10 (commit 5bd8c735): the same real host resolution is chained into seeding and listing for a client host, an unbound host and the agency host, proving no catalog row is seeded or listed for the first two and the instance row is what a client sees either way. A structural check reads the route file itself and confirms it calls isAgencyFormsHost exactly once in GET and once in PATCH, passes { isAgency } into every store call, and imports nothing else pack- or tenant-shaped.
• Instance card status and field count, proved from the real publication, section 11 (commit 367c44ea): the real listForms/toDto are called (no hand-built DTO) against PROJECT_REQUEST_TEMPLATE.definition's actual 12 fields. A published instance (draft 12 fields, publication 5 fields) renders status: 'live' and fields.length === 5, keyed to the publication, not the draft; the same row, after its draft is rewritten to 8 fields through the real updateInstanceFormDraft, still shows the publication's 5 — the published snapshot does not move when the draft changes later. An unpublished instance shows its draft's own field count. A Forms card render of that same real DTO (scripts/intake/verify-native-forms-console.tsx) confirms the card itself prints "Published" and "5 fields" from that real data, not from an invented fixture.
• Fail-closed completeness boundary, section 12 (commit edf603c1): GET /api/automations/forms/<slug>/completeness now resolves the same host decision first, before requireCrmStaff() and before any database query, and returns the identical not-found response for a client host, an unbound host, and an unknown slug on the agency host — proved with a database stand-in that throws on any query, so a passing assertion means no query was attempted. A chained real-agency-host case shows the moved completeness calculation still matches the unchanged original function on the same fixture data (agency behaviour unchanged), and a structural check confirms no db.from( remains in the route and both rejection paths call the same responder.

The full verification set — verify:automations-forms (37 checks), verify:native-forms-console, verify:form-publications, verify:native-intake-golden-path, verify:client-surface-leak, verify:no-client-material, and typecheck — passed after each commit, per reports/01-implement-pack-aware-forms.md sections 01, 01b, 01c, 01d and 01e.

The first real install, 2026-09-13

Rising Origin is on the new CRM at his existing URL, on his existing database, with his logins. Cutover through the Supabase Management API with a collaborator token (no password), twenty minutes. Release client/rising-origin/v5 through the deploy action, after four releases each caught one first-run gap (environment, heap, upload quota, env-file tracing) and a fifth found the first Phase 13c prune (a Ventari cron above the Hobby timeout cap). Full account in docs/crm-factory/runbooks/cutover.md, sitting 5. The rule it produces: the deploy action is dry-run against the client's project the day before the window, never during it. Alex's first words on the funnel: the deals are there, the UI needs passes. That is the gate evening, now on the live instance.

Exit: a second client is installed end to end using the runbook, by someone who did not write it, without asking a question.

That second install is the acceptance test. One successful install proves nothing except that the person who built it can use it.

The skill is the runbook, once the runbook has been executed twice by people and has stopped changing.

• Lives as a skill in the agents tab, discoverable by any agent doing client work, bound through the pack's skills contract (SkillBinding { id, enabled, requiresCapabilities }).
• It encodes the sequence, the check at each step, and the stop conditions.
• It refuses rather than guesses. A missing brand asset, an unregistered pack, a database that fails its post-install check: each is a stop with a message, never a default.

Exit: an agent runs the skill and produces a client CRM that passes the same checks a hand-built one does, including verify:client-surface-leak.

Preconditions, all mandatory. Do not start this phase without them:

1. Phase 13's second install succeeded, run by someone who did not write it.
2. The sequence did not change during that install.
3. Every step has a check that can fail. A step nobody can verify cannot be in a skill, because an agent cannot tell whether it worked.
4. A human has opened the resulting instance and walked it. Section 5b is the argument: the first walkthrough of a client instance found four problems in minutes that 72 automated checks could not see, because the checks asserted on resolved values and the leaks were in what the page emitted. A skill that installs a CRM nobody has looked at will install the same invisible defects every time, faster.
5. Phase 9c's token contract is written and at least the shell, funnel and CRM lanes have converted. The skill's design step is: run the extraction script against the client's current CSS, render, put it beside their current build, and stop for a person. A skill that skips the gate ships Ventari with the client's logo on it, which is what the instance looked like on 2026-09-11 before anyone said so.

• Pack contract

  integrations.analytics: { provider: 'vercel' | null, projectId, teamId }, required-and-explicit on every pack. vercel is the only website-analytics adapter: a site hosted on Vercel with Web Analytics on. A pack that declares null has no Website analytics card, and POST /api/connections/analytics answers 404. Rising Origin declares vercel; the project id is entered on the card until it is copied into the pack. This describes the v32 provider already shipped; the complete factory standard also requires the separately labelled GA4 adapter in Phase 13g.1.

• Connections card "Website analytics"

  (kind analytics, migration 20260925190000, already the connection row): admin only (requireAdmin). One card on /settings/connections. The client's own Vercel token is verified by reading the project once, which also records whether Web Analytics is on, then stored encrypted. It is never shown again and never read from env on a client. The project id comes from the pack when declared, otherwise from the card. Six labels are derived when the card is read (websiteAnalyticsPhase). They are not written to the row. Stored status stays connected, error, or disconnected.

  A saved token is setup. A count is observed data. The card shows one next step and does not repeat the SEO & GEO report. Disconnect is DELETE /api/connections/analytics and clears the secret.

• Windows

  Day-or-wider Vercel queries already send a Pacific calendar date (apiDate, America/Los_Angeles) to both the count and the series. This branch does not replace that helper. The new Connections presence count (probeWebsiteAnalyticsPresence, precise: false, 30 days) uses it. At 2026-09-23T06:30:00.000Z that request is date-only since=2026-08-23 and until=2026-09-22. A UTC date of that instant is 2026-09-23. Growth "Last 24 hours" stays an exact rolling window: granularity hour, precise ISO since and until, hour labels in Pacific time. A custom range of two Pacific days or less is also granularity hour with precise ISO bounds. At that instant, 1 September 2026 is since=2026-09-01T07:00:00.000Z and until=2026-09-02T06:59:59.999Z; 1–2 September 2026 is since=2026-09-01T07:00:00.000Z and until=2026-09-03T06:59:59.999Z. The freshness line names that range. It says the exact last 24 hours only for the Last 24 hours preset. Day, week, and month chart labels use the timestamps the reader returned. Hourly unique visitors are not summed into the period unique total. A failed or unreadable read stays unavailable. A ready snapshot whose whole-site visitor or page-view total is null stays unavailable on the report as well, and is not labelled Website reading. Zero visits and zero page views is an observed empty window. The presence read does not rewrite the connection row. No live Vercel call was made for this correction.

• Reader

  lib/growth/analytics-for-instance.ts: the agency reads env (VERCEL_ANALYTICS_READ_TOKEN and VERCEL_ANALYTICS_PROJECT_ID; a pack projectId wins when declared). A client reads its connection row and never the agency env. A client with no row is told to connect on Settings → Connections. A missing read stays empty rather than a filled zero from another instance. The SEO & GEO cached read is keyed by pack id, never by the token. Cache window 900 seconds. The freshness line names the window the reader used and the Pacific check time. It says the exact last 24 hours only for that preset. Any other hour window is named as its own Pacific start and end.

• Search Console

  Totals are the pack property (searchConsole.propertyUrl), finalized Pacific days. The overview end day is three Pacific days before the Pacific day of the read; more recent days are still finalizing. The default overview is 28 days. Domain and URL-prefix properties are not substituted. Query/page history is the latest stored snapshot for that property (gscDemandPropertiesForPack), not a live inventory of every search.

• CRM outcomes. Bookings are dated CRM appointment records. Commercial signed, paid, and revenue totals stay hidden until agreement and payment records cover the cohort. A website visitor, a search click, and a booking are separate measures.

• Standard client crons

  STANDARD_CLIENT_CRONS in scripts/deploy-client.mjs is daily, because a Hobby project allows daily crons only. The reporting job is /api/cron/gsc-demand-snapshot at 20 6 * * *. A client deployment receives that list plus the pack's own crons when a person publishes an approved client release. Until that release, the running client keeps the crons from its last release. CRON_SECRET stays on the client env checklist. This correction adds no cron and no migration.

• Per-client schedule override

  An entry in a pack's crons list in deploy/clients.json is a path string or { "path", "schedule" }. A string takes the schedule in the root vercel.json. An object uses its own five-field schedule for that path. The path must start with /api/cron/. A bad entry is a clear error and the deploy refuses. The override exists because the root file runs the rule tick every 15 minutes and a Hobby project allows daily crons only. The client pack's entry sets the rule tick to once a day. No other entry has an override, so no other client's output changes. The root schedule is not changed. The script cannot see the client's Vercel plan, its cron count limit or how exactly Vercel times a daily run.

• Release

  Clients do not follow main. Production for a client is a published stable Release under §13a.1 (.github/workflows/client-deploy.yml, no push trigger). workflow_dispatch can only preview and the deploy retains the existing client-environment reviewer. This lane has not published a tag, has not applied a migration to a hosted database, and has not changed a live website.

• Verifier. verify:analytics-card covers the six card states, the Pacific-day presence count, unavailable versus zero, the per-instance reader, and the standard cron list. Card verifiers stay structurally exempt from no-client-material.

Not built, logged: Threads has a tile and no card (Meta pattern, when a client asks); the Executive in Team Chat on a client key. Do not start Phase 14.

Phase 13g.1 - Core analytics bridge and selectable reporting modules

The layers are:

1. Analytics foundation (core, always installed). Tenant and program identity, site timezone, exact window semantics, unavailable-versus-zero, source vocabulary, evidence freshness, idempotency, module health and the shared report contracts. It stores no browser event merely because the CRM was deployed.
2. Attribution bridge (core, always installed and dormant). One stable contract can link an anonymous first-party visitor to a CRM person after a trusted successful intake, native booking or authenticated identity event. It preserves first touch and separately labels session/latest touch. It reads existing CRM client and successful-payment truth; it never creates a second person, booking, pipeline, client or revenue ledger. A failed link is best-effort and cannot roll back or delay an operational write.
3. Capture modules (pack selected). website_measurement supplies the root tracker, same-origin forwarder, server-minted first-party visitor and sliding session, page path, normalized referrer, five UTM fields, engagement and bot rejection. No site is registered, no cookie is set and no panel is exposed while the module is off.
4. Provider adapters (independently selected). Vercel Web Analytics, Google Search Console and GA4 remain separately labelled evidence. Each has its own Connections state, credential scope, freshness and report panel. Their visitors, users, sessions, clicks and impressions are never summed or silently substituted for first-party identities.
5. Outcome adapters (core contracts, source-specific readers). Intake, booking, held-call, proposal, client, successful payment and collected revenue map into the shared funnel only from their canonical operational sources. Attribution coverage always names linked, source-known and unattributed records. A missing join is not zero revenue.
6. Vertical reporting modules (pack selected). Business-model dashboards consume the foundation and operational truth without forking the core. community_learning may add DAU/WAU, watch sessions, cohorts, retention, drop-off and at-risk membership. recurring_revenue may add active MRR, churn and renewals. They do not activate on a marketing CRM merely because their code exists, and member names or emails do not enter the generic analytics spine.
7. Data quality and health (core, always installed). First-party and provider observations keep their source, window, freshness and completeness. Reconciliation may name reconciled, pending, review or unavailable; it never overwrites one source with another. Connection health requires a real scoped read, and a silent or failed interval never becomes a measured zero.
8. Privacy and lifecycle (core guardrail, no consent product). Browser measurement contains no direct contact fields. Visitor rows have one fixed 400-day maximum lifetime matching the first-party visitor cookie, idle sessions expire after 30 minutes, and a service-owned erase operation can remove one visitor or every visitor linked to a person. Its append-only receipt names site, organization, program, erased time, and event count, and excludes visitor/session hash, person id, path, referrer, UTM, and cookie. This adds no consent banner, consent mode setting or client-facing privacy workflow.
9. Installation and operations (shared control plane). Every module declares dependencies, owned routes/components, migrations, Connections requirements, dashboard panels, pack flag, health states, verifiers, release order and rollback. Connections explains setup and health; Growth reports evidence. Build-time pruning may later remove undeclared module code under Phase 13c, but activation never depends on hiding UI alone.

The dependency direction is one-way:

analytics foundation -> website measurement -> attribution bridge -> vertical reports

Provider adapters attach to the foundation and can operate without first-party measurement. Outcome adapters attach to the bridge and canonical CRM records. A vertical may depend on the foundation, bridge or its own domain records, but core never imports a vertical. This keeps learning portable for future factory agents and prevents a community dashboard from becoming a hidden dependency of a normal client CRM.

Money leads with a recent-charges chart (pull request 971, merge 3b27c770). Days follow the device clock. A day below zero means refunds were larger than charges, and that part of the line is yellow. The picker filters the loaded Stripe page. It does not fetch older history. Rising Origin tag client/rising-origin/v34 is that commit and was published. GitHub deploy 35943318530 reported success, including smoke. A logged-in look at Money and SEO & GEO was not completed. The public URL showed only the sign-in screen.

The green Website and CRM chips, and the timeframe picker on the traffic trend, are pull request 972 (merge 2d76cf15, tag v35) and are carried by current v37. The change moved the controls clear of the plot. The separate mobile usability finding remains: the graph itself is too small. Its exit is a 390px logged-in screenshot with a materially readable plot, useful height and width, compact ticks and the existing timeframe control.

Meta reconcile, delivery, and retention are in vercel.json. A client release still ships only the cron paths in deploy/clients.json. Rising Origin, Cymatica, and Myth & Ethos add none of these. The jobs do nothing useful until CAPI is enabled, and retention needs the outbox table.

Wave B · design contract

• Pipeline opens on Funnel. The sequence is Funnel, CRM, Leads, Proposals, Audits, Kickoff, Stewardship unless a pack removes an undeclared surface.
• Growth/SEO puts the traffic graph before large warnings. A warning belongs in the section whose evidence failed or below the primary graphic. Timeframe controls use the compact labels 24h, 7d, 30d, 90d, All, Custom and reuse one existing picker.
• Social puts account identity first, then Reach for the last 7 days, then a compact single-row metrics strip where width permits. Instagram receives the same title hierarchy as Facebook. Counts may abbreviate (13.4k) while an accessible title or detail exposes the exact value.
• Social and Money share the restrained chart language: continuous line/area, subtle bright-blue point markers, useful hover/focus detail and no decorative animation. Markers are opt-in shared behavior, not a global chart rewrite.
• Delivery, Automations and Shop each receive one first screen: one lead, one chart or strip from existing evidence, then supporting material. Autopilot stays where it is. This pass does not restyle unrelated surfaces.
• Connections gives every declared capability one operator-ready card. Remove redundant How-to sections when a connected card has no remaining setup or repair value; retain instructions where renewal, verification or recovery still benefits the operator.
• A first screen tells the operator where they are. Today uses one short, pack-aware orientation sentence below its title: “Your follow-ups, scheduled work, and recent changes across Rising Origin.” It does not repeat the nav label or become a welcome essay.

Wave C · responsive contract

Wave D · speed contract

Growth currently waits for Search Console, Website analytics, the acquisition pipeline and optional GA4 before paint. Money waits for the Stripe ledger. The speed pass first measures provider and route timings, then streams or defers independent panels so useful local/fast evidence can render first. Connection health, provider totals and CRM outcomes keep separate loading and freshness states. A slow or missing provider never manufactures a zero and never blocks intake, booking, navigation or the rest of the page.

Standard modules and client delivery

• There is one canonical CRM spine. Client Success is an optional post-sale module for lifecycle, plan, delivery, health, reviews and outcomes—not a duplicate clients database. A pack activates it only when the operating model and data owner are defined; do not enable an empty workspace for parity. At sufficient scale it is a legitimate expansion/upsell.
• Pre-sale intake stays accountless. After an approved accepted engagement, invite the client into one branded authenticated portal for decisions, files, structured intake and delivery status. The portal is an interface; canonical CRM, delivery, file and Brain systems remain the authority.
• Community-only analytics belongs in selectable vertical modules such as community_learning, never in the core marketing CRM. Threads is likewise a separate future provider module: it currently has no client, OAuth, storage, card, pack flag or adapter and must not borrow Facebook/Instagram credentials by implication.
• GA4 is part of the factory analytics standard but optional per pack. Its operator flow still requires trusted instance callback handling, read-only authorization, explicit property/stream selection, callback-result feedback, disconnect/repair and a dedicated provider panel. It does not replace Vercel, Search Console or first-party attribution.
• Cymatica is outside this CRM Factory rollout. Sharing the agency pack does not make it a factory target. Historical pull-request titles are evidence of a past change, not current product truth; the client Executive's live GitHub status was intentionally reverted and must not be represented as shipped.

Alex walked the first client release with the 13e lane and the Assistant card live and opened every tab. Eighteen findings, all in docs/estate/FINDINGS.md under "The v30 walk on Rising Origin"; the ones that were code shipped in v31 (one PR, no migration). The two decisions worth keeping here:

• A client keeps every tab, and every tab speaks in the product's words about what is and is not set up for them

  No teaser page, no hidden console. The Agents workspace resolves clientProduct once (CapabilitiesWorkspace) and each tab takes it: what an agent network, a team, a skill, a block, a run, a model choice is, and that none exists for them until Ventari sets up a Brain. The agency's rendering is untouched. What a client never sees: our repository, commit and file paths (Blocks), build-routing rows (Models), engagement gates (Client AI Teams), staff playbooks (skillsForClientInstance), the agency's SEO & GEO agent (Experiments).
• Every read of a credential goes through the connection row, never the environment alone. Inbox (#914) and now Sent (resolveSendingApiKey) had read env; a client whose key was stored on Connections saw "not configured". The rule is already the sender's rule; the walk found the two readers that had not adopted it.

Also from the walk: a contact can now be removed (softDeletePerson, soft, refuses staff and a deal's primary contact); an empty experiments ledger is the empty state, not an outage; Open in Chat is agency-only until the group-chat reply takes the client key (FINDINGS item 11).

The three options, side by side

• It is a monoculture. A bug that passes all 77 checks and gets approved for a client ships to that client, and to every client who approves it. Diverse businesses mean diverse ways to hit a bug the checks did not imagine. Done about it: releases are per client, so a bug surfaces on the first client to take a release, not all of them; the walkthrough in Phase 14's preconditions stays human; and the pixel harness now proves that design changes do not move the agency by a pixel, which is the class of change most likely to slip past a functional check.
• Core changes serve Ventari's needs first. A change Ventari wants for itself lands in the code every client runs from. Done about it: the rule from Phase 7 that every change is conditional on the pack or it is wrong, enforced by verify:tenant-aware-shell and the leak check; and a client never has to take a release they did not ask for.
• A shared dependency vulnerability hits everyone. True in every layout. Done about it: dependency scanning on main, and the one-codebase model is the only one where the fix ships to everyone the same day.
• If the account that owns everything is compromised, layout does not save anyone. True. Done about it: required reviewers per client environment; environment-scoped secrets; and, for clients who want it, the instance repository in their own organisation so a different account holds their release decision. That is the middle ground and it is real.
• Many kinds of businesses will want different things. True, and the design's answer is modules and packs, not forks. When a client's need cannot be expressed as a module, they are a bespoke build. The factory should say no to that client rather than fork for them.

Alex, 2026-09-12: "when we build med spa CRMs that means we will have to build them first in the Ventari app." True, and it exposes the one place this section was soft.

A pack gates surfaces: navigation, routes a user can reach, what the shell renders. When the med-spa modules are built, their code lands in the one codebase, and today it would ship in every client's deployment bundle, Nick's included. He would never see a med-spa page. But the API routes would exist on his instance, unlinked, and a vulnerability in one of them would be reachable there and on Ventari's own instance. "The gate is tested" answers the leak. It does not answer this.

• Phase 13c, scoped: each module in the pack contract names the directories it owns (app/(dashboard)/<x>, app/api/<x>, components/<x>). The deploy script prunes every directory owned by an undeclared module before the build. A verifier builds the pruned tree for Rising Origin and asserts that no route for an undeclared module exists in the output, and that the committed tree is untouched afterward, the same way the cron step is proved.
• The precondition is the module-to-directory map, which does not exist yet. Writing it is also the audit of which code is actually shared (auth, tenancy, the shell, components/ui) and which is a module, and that audit is worth having regardless.

The preferred workflow is Vercel connected to GitHub: previews per pull request, deployments traceable to commits. That stays exactly as it is for Ventari's own project, which is Ventari's team looking at Ventari's code.

It cannot be used for a client's project, for one reason: connecting a repository to a Vercel project gives everyone on that project the deployment Source tab, which browses the deployed source files. In a client's account, that is the client reading Ventari's codebase. It would also require Ventari to authorise the Vercel GitHub App on the private repository for the client's account. So rule one of the deploy action is no Git integration on a client project, and the verifier proves the workflow has no push trigger.

What that workflow is wanted for, and where each part lives instead: