toga-ai 1.0.287 → 1.0.289

package/knowledge/2.0/apps/_underscore/INDEX.md

@@ -8,6 +8,7 @@
 | [Assortment Name Translation (AssortmentTranslations sidecar)](features/assortment-name-translation.md) | Serves Assortment (product-grouping) **names** in multiple languages by adding a per-language **sidecar** table `AssortmentTranslations`, reusing the platform's | _underscore/Model/Client/AssortmentTranslation.php, dbchanges2/Client/2026-06-26a - AssortmentTranslations.sql, dbchanges2/Core/2026-06-26a - AssortmentTranslationsRecord.sql, dbchanges2/Client/2026-06-26b - AssortmentTranslationsAcl.sql |
 | [Asynchronous Query Execution (writes-only, via Worker)](features/async-query-execution.md) | `_Query` can run a **write** query asynchronously so a long/slow write does not hold a request-scoped DB connection open long enough to hit **"MySQL server has | _underscore/Query.php, worker2/Worker/Infrastructure/Database.php, worker2/Worker/Team/Transcripts.php |
 | [Carrier Shipping Labels (UPS/FedEx) & NetSuite Item Fulfillment](features/carrier-shipping-labels.md) | Backend mechanics behind TOGa Supply's Fulfill & Ship: buying a carrier label (UPS/FedEx), persisting it, and creating the NetSuite Item Fulfillment with tracki | _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Client/TrackingNumber.php, _underscore/Model/Client/ItemFulfillments/TrackingNumber.php, _underscore/Component/Library/LabelPdf/LabelPdf.php, _underscore/Component/Library/Carriers/ShipmentRequest/ShipmentRequest.php, _underscore/Component/Library/Carriers/Ups/Ups.php, _underscore/Component/Library/Carriers/Fedex/Fedex.php, _underscore/Trait/Netsuite/ItemFulfillment.php, _underscore/Trait/Netsuite/SalesOrder.php, _underscore/Component/Library/NetSuite/NetSuite.php, _underscore/Model/Client/TrackingNumber.php, _underscore/Model/Client/ShippingMethod.php, _underscore/Model.php, _underscore/Cloud.php |
+| [_Component_*/_Model_* project-namespace registration (autoloader) & backslash-qualify traps](features/component-model-namespace-registration.md) | Every **project-local** `_Component_*` and `_Model_*` class in a 2.0 app **must declare the project namespace** at the top of the file: ```php namespace <NAMESP | _underscore/Loader.php, worker2/_.php, api2/_.php, worker2/Component/Forecast/Db/Db.php, worker2/Component/Forecast/SaleImport/SaleImport.php, api2/Component/Api/Netsuite/Netsuite.php |
 | [Client Email Template Sending](features/email-template-sending.md) | `_Model_Client_EmailTemplate` sends a stored, client-defined email template by UUID. | _underscore/Model/Client/EmailTemplate.php, _underscore/Model/Client/EmailTemplateOutgoingEmailAddress.php, _underscore/Email.php |
 | [Error Reporting — Issue/Event Aggregation (exceptionHandler)](features/error-reporting-issue-event.md) | `_underscore`'s global exception handler persists every uncaught exception into a two-table **Issue / Event** model in the **shared Core Logs DB** (`_underscore | _underscore/Error.php, _underscore/Model/Core/Logs/Issue.php, _underscore/Model/Core/Logs/Event.php, dbchanges2/Logs/2026-07-06 - Issue and Event tables.sql |
 | [Record-Changed Event Publishing (_Event::publish to SQS)](features/event-publish-sqs.md) | `_Event::publish()` (in `_underscore/Event.php`) is the PHP side of the real-time event pipeline. | _underscore/Event.php |

package/knowledge/2.0/apps/_underscore/features/component-model-namespace-registration.md

@@ -0,0 +1,102 @@
+---
+title: "_Component_*/_Model_* project-namespace registration (autoloader) & backslash-qualify traps"
+framework: "2.0"
+repo: _underscore
+project: _Underscore
+client: shared
+type: feature
+status: active
+updated: 2026-07-08
+owners: [dfranks]
+files:
+  - _underscore/Loader.php
+  - worker2/_.php
+  - api2/_.php
+  - worker2/Component/Forecast/Db/Db.php
+  - worker2/Component/Forecast/SaleImport/SaleImport.php
+  - api2/Component/Api/Netsuite/Netsuite.php
+related:
+  - ../architecture.md
+  - ./forecast-sale-import.md
+---
+
+## Summary
+Every **project-local** `_Component_*` and `_Model_*` class in a 2.0 app **must declare the
+project namespace** at the top of the file:
+
+```php
+namespace <NAMESPACE>;   // worker2 → 'worker', api2 → 'api'
+```
+
+where `<NAMESPACE>` is the value of that project's `_.php` `const NAMESPACE` (worker2 =
+`'worker'`, api2 = `'api'`). The `namespace` declaration **IS the "registration"** — there
+is no config toggle. If the class is declared in the **global** namespace instead, the
+`_underscore` autoloader throws at **class-load (runtime)**:
+
+> The namespace for '`<Class>`' located in '`<path>`' has not been defined which is
+> prohibited for all _Model and _Component classes. Define the namespace for this class and
+> try again.
+
+**This is NOT caught by `php -l`** (parse-only) — it only surfaces at autoload/runtime, so
+lint-clean code can still fatally throw on the first request that touches the class.
+
+## How it works — `_underscore/Loader.php` (lines ~71-83)
+For a project-local `_Component_*` / `_Model_*` class the autoloader:
+1. `require`s the local file.
+2. Checks whether the class **also** exists under the project namespace
+   (`<NAMESPACE>\<Class>`).
+3. **If yes** → `eval`s a bridge class in the global namespace
+   (`class <Class> extends <NAMESPACE>\<Class> {}`, Loader.php:79-80) so callers can use the
+   bare `_Component_Foo` name.
+4. **If no** (class was declared globally, so `<NAMESPACE>\<Class>` doesn't exist) → **throws**
+   the "namespace … has not been defined" error above.
+
+**Correct precedent to copy:** `api2/Component/Api/Netsuite/Netsuite.php` —
+`namespace api;` + `class _Component_Api_Netsuite extends \_Component` + `\_Config::netsuite(...)`,
+`new \_ApiRequest(...)`.
+
+### Framework references inside a namespaced file — what resolves vs. what must be backslash-qualified
+Once the file is in `namespace <NAMESPACE>;`, **static calls and constants** to framework
+classes resolve transparently via the autoloader's namespace fallback (Loader.php ~94-120),
+bridged as `<NAMESPACE>\_X` → the framework class — e.g. `_Time::convert(...)`,
+`_underscore::DB_FORECAST`, `_Component_Api_Netsuite::send(...)`, `new _Query(...)` all work
+unqualified.
+
+**Three constructs do NOT get that treatment and MUST be backslash-qualified:**
+- `catch (\Exception $e)` / `catch (\RuntimeException $e)` — unqualified `catch (Exception $e)`
+  resolves to the non-existent `<NAMESPACE>\Exception` and silently no-matches (or fatals).
+  **This silent-swallow `catch` is the most dangerous / easiest-to-miss line** — the block
+  never catches, so error handling quietly does nothing.
+- `new \Exception(...)` / `throw new \RuntimeException(...)` — same reason.
+- `extends \_Component` (and `extends \_Model` etc.) — the base class in the class declaration
+  must be backslash-qualified.
+
+## Why this matters — the Forecast SALES drift root cause
+This mechanism was the root cause of the Forecast **SALES** drift observed after a worker2
+push: `_Component_Forecast_SaleImport` and `_Component_Forecast_Db` had been declared in the
+**global** namespace, so every NetSuite sales/invoice/opportunity webhook **fatally threw at
+autoload before writing to `Forecast.Sales`**. Because NetSuite replays edits across old
+transactions, the symptom **presented as ~7 months of historical drift** rather than as a
+"new code broken" failure — a misleading symptom that this mechanism explains.
+
+(The engine ultimately lives under `_underscore` — see the
+[Forecast.Sales import engine doc](./forecast-sale-import.md) — precisely because a
+`_Component_*` class loaded from a project path is rejected; but even a legitimately
+project-local `_Component_*`/`_Model_*` must still declare the project namespace.)
+
+## Gotchas / known issues
+- `php -l` will **not** catch a missing/global namespace or an unqualified `catch`/`throw`/
+  `extends` — boot the class (autoload it) to verify. A wrong autoload path is likewise a
+  runtime-only failure.
+- A global-namespace `_Component_*`/`_Model_*` fails **loudly** (the throw above). An
+  unqualified `catch (Exception $e)` fails **silently** — the more insidious of the two.
+
+## Change history
+- 2026-07-08 — Documented the `_Component_*`/`_Model_*` project-namespace registration
+  requirement (Loader.php eval-bridge mechanism, ~71-83), the runtime-only failure mode (not
+  caught by `php -l`), and the three constructs that must be backslash-qualified inside a
+  namespaced file (`catch`/`throw`/`new \Exception`, `extends \_Component`). Root-caused the
+  Forecast SALES drift to `_Component_Forecast_SaleImport`/`_Component_Forecast_Db` declared
+  in the global namespace (webhooks threw at autoload before writing; presented as 7-month
+  historical drift because NetSuite replays edits). Correct precedent:
+  `api2/Component/Api/Netsuite/Netsuite.php`. (dfranks)

package/knowledge/2.0/apps/_underscore/features/forecast-sale-import.md

@@ -38,6 +38,7 @@ related:
   - ../../worker2/features/netsuite-salesorder-open-orders-sync.md
   - ../../worker2/features/netsuite-supporting-record-webhook-importer.md
   - ./netsuite-rest-client.md
+  - ./component-model-namespace-registration.md
 ---
 
 ## Summary
@@ -135,7 +136,14 @@ This is the **opposite of the legacy cron**, which reads the pre-signed listSale
 (already `-foreignamount`) and so applies the factor **only** to the synthetic shipping
 line. **Do not copy the cron's sign handling into the webhook** — it reintroduces the
 ~$470K credit-memo sign bug (credits stored positive). The cron is not authoritative for
-the raw-REST path. Confirmed end-to-end against the local Forecast mirror (creditMemo
+the raw-REST path.
+
+> **Do not confuse this line-amount/revenue sign with the `amountDue` "store raw positive"
+> decision (TRUE-78923).** The "store raw positive / don't sign-flip credit memos & refunds"
+> guidance applies **only to `amountDue`** (which this importer does not write) — it does
+> **NOT** apply to the line `amount`/revenue sign. For revenue, credit memos + cash refunds
+> **must** land NEGATIVE and invoices + cash sales POSITIVE in `Forecast.Sales`; that is the
+> stored contract. Mis-carrying the amountDue rule onto revenue would store credits positive. Confirmed end-to-end against the local Forecast mirror (creditMemo
 revenue stored -350..-600; cashRefund revenue -885 / profit -78; invoice positive).
 
 > A reviewer may flag "profit double-signs the factor" — false positive:
@@ -481,10 +489,25 @@ record is deleted in NetSuite.)
   (e.g. `./` under worker2) with "namespace … has not been defined" — at **class-load
   (runtime), not `php -l`**. So this engine lives in `_underscore` next to
   `_Component_Forecast_Db` even though only worker2 uses it; it references the worker2 class
-  `_Worker_Netsuite_Item`, resolved lazily at runtime in the worker2 context.
+  `_Worker_Netsuite_Item`, resolved lazily at runtime in the worker2 context. **A
+  legitimately project-local `_Component_*`/`_Model_*` (e.g. the worker2 copies of these
+  classes) must still declare `namespace worker;` or it throws the same error at autoload —
+  and this exact global-namespace mistake caused the SALES drift (webhooks fatally threw
+  before writing, presenting as 7-month historical drift). See the
+  [namespace-registration doc](./component-model-namespace-registration.md) for the
+  eval-bridge mechanism and the `catch`/`throw`/`extends` backslash-qualify traps.**
 - The cron's sign handling is not portable here — see Sign convention.
 
 ## Change history
+- 2026-07-08 — **Clarified the revenue sign convention is NOT the `amountDue` "store raw
+  positive" rule.** The TRUE-78923 "don't sign-flip credit memos/refunds" guidance applies
+  only to `amountDue` (which this importer does not write); the line `amount`/revenue sign
+  contract is unchanged — credit memos + cash refunds NEGATIVE, invoices + cash sales
+  POSITIVE. Also cross-linked the new
+  [`_Component_*`/`_Model_*` namespace-registration doc](./component-model-namespace-registration.md):
+  a global-namespace declaration of `_Component_Forecast_SaleImport`/`_Component_Forecast_Db`
+  was the root cause of the SALES drift (webhooks threw at autoload before writing; presented
+  as 7-month historical drift because NetSuite replays edits). (dfranks)
 - 2026-07-07 — **Documented the AMQ enqueuer's line-field inline-edit blind spot** (Forecast2 SALES
   profit-drift forensics; invoice 6715127 / 2026-02-20 / $3,392.70). Editing a **sublist LINE
   field** (e.g. cost `TRANLINE.MCOSTESTIMATE`) inline in the NetSuite UI raises **no** record UE

package/knowledge/2.0/apps/ai-bdr/INDEX.md

@@ -3,6 +3,7 @@
 | Doc | Summary | Files |
 |-----|---------|-------|
 | [AI-BDR Architecture](architecture.md) | **AI-BDR** is TOGA's outbound AI sales-development representative. | ai-bdr/README.md, ai-bdr/requirements.txt, ai-bdr/.env.example, ai-bdr/docs/client-onboarding-sop.md, ai-bdr/docs/vapi-firstmessage-timing-fix.md, ai-bdr/docs/vapi-inbound-callback-assistant-request.md, ai-bdr/docs/vapi-voicemail-iphone-screening.md, ai-bdr/vapi/templates/system-prompt.template.md, ai-bdr/vapi/templates/assistant.template.json, ai-bdr/prompts/archive/prompt-may-15.txt, ai-bdr/prompts/campaigns/healthcare-2026-03-18.md, ai-bdr/prompts/campaigns/healthcare-v2-2026-03-25.md, ai-bdr/scripts/update_assistant.py, ai-bdr/scripts/update_system_prompt.py, ai-bdr/scripts/update_structured_output.py, ai-bdr/scripts/update_call_summary_context.py, ai-bdr/scripts/fix_booking_guardrails.py, ai-bdr/scripts/get_assistant.py |
+| [BDR Web Funnel — Full Implementation Plan](features/bdr-web-funnel-plan.md) | > **Status:** First iteration (for Alex's review). | bdr/PLAN.md, bdr/mockup/app.jsx, bdr/mockup/screens.jsx, bdr/mockup/components.jsx |
 | [Call Orchestration — PHP Worker ↔ Vapi (the integration seam)](features/call-orchestration.md) | The **PHP worker** is the orchestrator; **Vapi** is the actor. | ai-bdr/docs/client-onboarding-sop.md, ai-bdr/docs/vapi-firstmessage-timing-fix.md, ai-bdr/docs/vapi-inbound-callback-assistant-request.md, ai-bdr/docs/vapi-voicemail-iphone-screening.md, ai-bdr/scripts/update_structured_output.py |
 | [Vapi Integration — Assistants, Tools, Structured Output](features/vapi-integration.md) | Everything inside Vapi: the three assistants, the three shared tools, the shared structured-output schema, the Liquid-templated system prompt, and the Python sc | ai-bdr/vapi/templates/assistant.template.json, ai-bdr/vapi/templates/system-prompt.template.md, ai-bdr/prompts/archive/prompt-may-15.txt, ai-bdr/prompts/campaigns/healthcare-2026-03-18.md, ai-bdr/prompts/campaigns/healthcare-v2-2026-03-25.md, ai-bdr/prompts/templates/campaign-template.md, ai-bdr/scripts/update_assistant.py, ai-bdr/scripts/update_system_prompt.py, ai-bdr/scripts/update_structured_output.py, ai-bdr/scripts/update_call_summary_context.py, ai-bdr/scripts/fix_booking_guardrails.py, ai-bdr/scripts/get_assistant.py, ai-bdr/docs/vapi-firstmessage-timing-fix.md, ai-bdr/docs/vapi-voicemail-iphone-screening.md |
 | [Web Funnel — Next.js UI + Config-Driven Campaign Content](features/web-funnel-content-model.md) | The **public-facing web funnel** is the new UI / lead-capture front door of the **same AI-BDR product** documented in `../architecture.md`. | bdr/src/content/schema.ts, bdr/src/content/hubspotProvider.ts, bdr/src/content/useCampaign.ts, bdr/src/content/default.ts, bdr/src/server/leadSink.ts, bdr/src/server/callbackService.ts, bdr/src/app/api/call-now/route.ts, bdr/src/app/api/call-later/route.ts |

package/knowledge/2.0/apps/ai-bdr/features/bdr-web-funnel-plan.md

@@ -0,0 +1,533 @@
+---
+title: "BDR Web Funnel — Full Implementation Plan"
+framework: "2.0"
+repo: ai-bdr
+project: "AI-BDR"
+client: shared
+type: feature
+status: draft
+updated: 2026-07-08
+owners: [tcox]
+files:
+  - bdr/PLAN.md
+  - bdr/mockup/app.jsx
+  - bdr/mockup/screens.jsx
+  - bdr/mockup/components.jsx
+related:
+  - architecture.md
+  - web-funnel-content-model.md
+---
+
+# BDR: Multi-Campaign "AI BDR / Agent Studio" Web App — Implementation Plan
+
+> **Status:** First iteration (for Alex's review). Draft, pending sign-off on the open questions
+> in §9 and final campaign direction / verbiage from leadership.
+> **Author:** tcox · **Stack:** TOGA 2.0 front-end · Next.js (App Router) · **Client scope:** shared / internal (TOGA)
+> **Repo (new):** `bdr` · **Two source inputs:** the **mockup** (real UI) + **`info`** (backend to reuse).
+>
+> Product-copy rules the built site must follow (from the mockup's `CLAUDE.md`): **no em dashes** in any
+> shipped string; **one accent source** drives every accent. (This internal planning doc itself uses em
+> dashes for readability; the rule governs what the site ships, not this file.)
+
+---
+
+## 0. Provenance & required inputs
+
+This plan comes from the **AI BDR Development Handoff** meeting plus a full read of two codebases.
+`bdr` is the new public **UI / lead-capture front door of TOGA's existing AI-BDR product** (that
+product's backend is documented at `2.0/apps/ai-bdr/`) — only the UI is new. It is an **entirely new
+code repo**, built by combining:
+
+1. **The mockup (the real target UI)** in the `bdr` repo's `mockup/` folder — a finished, high-fidelity
+   prototype of an "AI BDR / Agent Studio" single-page flow. This is the pixel-perfect blueprint.
+   - Source of truth: `app.jsx` (shell/routing/state), `screens.jsx` (the screens), `components.jsx`
+     (shared component + data library), `styles.css` (~97 KB of styling), `CLAUDE.md` (copy rules).
+   - Prototype tech: React 18 via UMD + in-browser Babel (no build step). Assets under
+     `media/ uploads/ agents/ voices/ screens/`. There is also a 14.5 MB single-file
+     `AI BDR (standalone).html` export (do not hand-edit; it is a build artifact).
+2. **`info`** — the external `info` repo (github.com/agilantsolutions/info) — a Next.js app whose `/bdr`
+   route already implements the **production backend calls we will reuse**: HubSpot contact fetch, Toga
+   contact upsert + campaign linking, and callback (call-now / call-later) requests. (BDR is **also
+   Next.js**, so we reuse `info`'s framework patterns and its server-side call logic directly; see §5.6.)
+   This is where the real integrations live; its marketing UI is a *different, older* funnel we are
+   **not** copying.
+
+**Attach when handing this plan to Claude for execution:** this file, the meeting transcript, the
+mockup folder, and the `info` repo.
+
+**Still pending (does not block the build):** final campaign direction and copy from leadership.
+
+---
+
+## 1. Goal & done-condition
+
+**Goal:** Rebuild the mockup's Agent Studio flow as a production **Next.js app** (App Router +
+TypeScript, matching `info`). Next.js is the chosen framework because the site is **highly public**,
+so server-side rendering + SEO matter, and its server (server components + route handlers) is where
+the secret-bearing HubSpot/Toga/content calls run natively (§5.6). Every campaign is defined by
+content authored in HubSpot, so a new campaign launches with **no code changes**, multiple campaigns
+run side by side, and the real HubSpot / Toga / callback backend from `info` is reused directly.
+
+**Done when:**
+1. The full flow (Welcome, Build, Capabilities, Call Now, Schedule, Success) renders in Next.js
+   with visual parity to the mockup (pixel-perfect pass against the mockup screens).
+2. Two distinct campaigns (for example a generic **BDR-as-a-service** and a **healthcare** variant),
+   **each authored in HubSpot**, render differing only in data (copy, Q&A proof points, agent identity,
+   accent), with zero component-code differences. Adding a campaign requires **only HubSpot edits** (no
+   code, no redeploy).
+3. No user-facing string is hardcoded in a component (grep-verified); all copy comes from the HubSpot
+   campaign content, fetched by slug at runtime and resolved through one hook.
+4. The simulated call/schedule actions are wired to the **real backend** (Toga `requestCall`,
+   HubSpot/Toga contact upsert) behind a `CallbackService` / `LeadSink` adapter ported from `info`.
+5. Campaign content is fetched from **HubSpot at runtime** via the backend, behind the
+   `CampaignContentProvider` seam (§5.2), so marketing edits copy without a developer or a deploy.
+6. Copy honors the mockup rules: no em dashes; a single `--accent` source drives all accents.
+7. No PII in logs; the `info` debug logging is not carried over.
+8. Deploys (AWS Amplify) with documented env vars.
+
+---
+
+## 2. What the mockup actually is (the real UI to rebuild)
+
+### 2.1 Screen / state map
+The shell (`app.jsx`) is a screen router with a 3-step rail (Create · Abilities · Connect) plus
+modals. Default flow in **bold**; parked screens are reachable only via hidden dev triggers today.
+
+| Screen (`screen` key) | Step | Role | Notes |
+|---|---|---|---|
+| `landing` | (rail hidden) | Service selection ("AI BDR" featured + "Talos" coming soon) | Parked; reached via a hidden corner door. |
+| `creator` | 0 Create | Manual agent builder (form tabs, 9-slot grid, live preview, name, color, voice) | **Parked / dev-only** ("Build it myself" is "coming soon"). |
+| **`building`** | 0 Create | **AutoBuild**: theatrical assembly, always lands on Alex / Human / Cobalt | ~5.5 s, then advances to capabilities. |
+| **`capabilities`** | 1 Abilities | **"Meet your agent"**: avatar, 3 skill cards, Q&A pill bank, CTAs | The content-heavy screen. |
+| **`call`** | 2 Connect | **Call Now**: agent recap + phone entry | Submits phone. |
+| **`schedule`** | 2 Connect | **Schedule**: calendar + 30-min slots + phone | 24/7, 12-month window. |
+| **`calling`** | 2 Connect | **Success (calling)**: connecting → connected → ended + call summary + share | Currently a timed simulation. |
+| **`scheduled`** | 2 Connect | **Success (scheduled)**: confirmation | Calendar-invite copy. |
+
+**Modals (`app.jsx`):** `Welcome` (first load: "Meet the rep who never sleeps.", primary
+"Build my agent for me"), `WelcomeStep2` (how-it-works, 3 tiles, shown once on first reaching
+capabilities), `EarlyAccess` ("Build it myself" / customization, coming-soon, with walkthrough video).
+
+**Default happy path:** `Welcome → (Build my agent) → building → capabilities → call | schedule → calling | scheduled`.
+
+### 2.2 Agent identity model (core state)
+`state = { form, sel, color, voice, voiceGender, name }`:
+- **form**: `Human | Owl | Robot`; **sel**: chosen slot index per form (0..8, 9 slots each).
+- **color**: one of 5 TOGA accents (`#FF6AB0` Fuchsia, `#CF9AFF` Lilac, `#4571DD` Cobalt,
+  `#FFA071` Peach, `#A2AAE1` Indigo); drives the global `--accent` (+ derived `--accent-fill`).
+- **voice**: `voiceGender` (Female/Male) + index into `VOICE_GROUPS`.
+- **name**: free text, falls back to a per-form sample name (`AGENT_NAMES`, for example Human ->
+  Maya/Alex/Zoe...). Default auto-build result is **Alex** (Human slot 1, Cobalt, Female voice 0).
+- Persisted to `localStorage` (`aibdr.v2`); only voice survives a refresh, flow restarts at Welcome.
+
+> Design implication: in the default flow the user does **not** pick the agent (the builder is
+> parked); AutoBuild fixes it to Alex/Cobalt. So **agent identity is effectively campaign config**
+> today (which art, accent, voice, name a campaign presents). See §6.
+
+### 2.3 Shared component + data library (`components.jsx`)
+Reusable pieces to port (heavy reuse is exactly why "build one screen cleanly, the rest are fast"):
+- **Structural/UI:** `Wordmark`, `StepRail`, `BackBtn`, `SynapseButton`, `CtlHead`, `IqMark`, `Ico`
+  (full inline SVG icon set), `Silhouette`.
+- **Agent visuals:** `AgentArt` / `SmoothImg` / `agentArt` + `AGENT_ART`, `TalkingPreview` +
+  `AGENT_TALK` (per-form talking video), `AgentSlot`, `ColorSelector` + `AGENT_COLORS`,
+  `VoiceDial` + `VOICE_GROUPS` + `VoiceAudio` + `voiceName`, `AGENT_NAMES` + `sampleName`.
+- **Motion/system:** `SwapFade` (the one page/tab transition), `Particles` (ambient motes),
+  plus app-level cursor-hover tracking and scroll-state tinting (in `app.jsx`).
+- **Asset resolution:** `ASSET(path)` maps a logical path to `window.__resources` (embedded assets
+  in the standalone export) or to a real URL. `preloadAgentAssets(form, sel)` warms art + video.
+- **Dev tuning:** `TweaksPanel` / `TweakSection` / `TweakColor` / `TweakSlider` (synapse glow,
+  radius). Likely dev-only; decide whether to keep in production (§9).
+
+### 2.4 Content inventory (everything that must become campaign config)
+This is the "verbiage" the meeting wants swappable. Current hardcoded copy lives in these surfaces:
+- **Welcome / WelcomeStep2 / EarlyAccess** (headlines, value bullets, how-it-works tiles, CTA labels).
+- **Landing** (headline, lede, the two service tiles).
+- **Capabilities**: `CAPS` (3 skill cards), `Q_ANCHOR` + `Q_POOL` (anchor + a 10-entry Q&A pool, 11
+  total) and `Q_SETS` (rotation A/B/C), lede, CTA labels, "avg connect time" line.
+- **Call Now / Schedule**: prompts, phone-field labels, privacy footnotes, durations.
+- **Success**: `CALL_SUMMARIES` (short/medium/large recaps), status strings, calendar-invite copy,
+  `AmbientQuestions` (reuses the Q pool).
+- **AutoBuild**: build-step labels ("Selecting your rep / Tuning the voice / Setting the style").
+
+> Note: the `Q_POOL` answers already contain **healthcare/pharma proof points** ("cut inventory
+> costs 32%", "recovered $167K in 90 days", "response times dropped 44%") alongside generic BDR
+> answers. This is direct evidence that campaign copy (BDR-as-a-service vs. healthcare) must be
+> bundle-swappable, and gives us real content for the two example bundles in the done-condition.
+
+---
+
+## 3. What `info` provides (backend to reuse, not its UI)
+**Many of the API calls the new BDR needs already exist and work in `info` — reuse them, do not
+rebuild.** The `info/bdr` route is a live implementation of the lead + callback backend; port these
+modules into `bdr` (behind the §5.6 adapters, minus the debug logging) rather than writing them from
+scratch. From the external `info` repo's `src` folder:
+- **HubSpot** (`lib/hubspot.ts`): `getContact(hsContactId)`, env `HUBSPOT_ACCESS_TOKEN`.
+- **Toga / api2** (`lib/toga.ts`, envelope `{isSuccess,status,error,messages,data}`):
+  cached-token auth; `upsertContactByEmail` (find/create/update) + `addContactToCampaign`;
+  `requestCall(uuid, dtNextContactRequested, phone, IMMEDIATE|SCHEDULED)` which drives the actual
+  voice callback; `CONTACT_CALL_TYPE_UUID` immediate/scheduled; CST datetime formatting.
+  Env: `TOGA_API_BASE_URL`, `TOGA_CLIENT_ID`, `TOGA_CLIENT_API_UUID`, `TOGA_CLIENT_API_SECRET`.
+- **Entry params**: `?hsContactId=…&hsCampaignId=…` (a server component prefetches the contact +
+  upserts on request; BDR keeps this same Next.js server-component pattern).
+- **API routes**: `call-now`, `call-later`, `contact` (and a `visit` 501 stub).
+- **GA4** (`lib/analytics.ts`): typed `EventMap`, env `NEXT_PUBLIC_GA_MEASUREMENT_ID`.
+- **Do not port**: the extensive debug `console.log`s (several log PII: email/phone), and `info`'s
+  hero/curiosity marketing UI.
+
+**Reconciliation:** the mockup's Call Now / Schedule screens are the front-end; `info`'s
+`requestCall` / upsert are the backend those screens should call (replacing the mockup's timed
+simulation in `Success`). The mockup already models immediate vs. scheduled, matching
+`CONTACT_CALL_TYPE_UUID`.
+
+**How `info` uses "campaign" (verified by reading the source):** it is **attribution-only**. HubSpot is
+used solely to fetch the *contact* (`getContact(hsContactId)`); the `hsCampaignId` from the URL is
+passed to **Toga** as a campaign UUID (`addContactToCampaign` → `POST /campaigns-contacts`), linking
+the contact to a campaign on the Toga/api2 side. **`info` does not fetch any marketing content from
+HubSpot** — its copy is hardcoded. So we reuse `info`'s contact fetch + Toga campaign-link + callback,
+but **fetching campaign *content* by slug from HubSpot is net-new** (no `info` pattern to copy; see
+§9.10). Note the slug (content key) and the campaign UUID (attribution key) are related but distinct;
+the bundle carries the UUID so a slug maps to the right campaign for logging.
+
+---
+
+## 4. Decisions locked at kickoff
+| Decision | Choice | Consequence |
+|---|---|---|
+| Repo name | **`bdr`** | New greenfield repo. Not yet in the TOGA registry. |
+| Framework | **Next.js (App Router) + TypeScript** | Chosen because the site is highly public: SSR + SEO, and a built-in server for the secret-bearing HubSpot/Toga/content calls. Matches `info`, so its patterns port directly. |
+| UI source | **The mockup** | Rebuild its Agent Studio flow faithfully (pixel-perfect). The mockup is React, so components port cleanly into Next.js client components. |
+| Backend source | **`info`** | Reuse HubSpot/Toga/callback logic directly (same framework). |
+| Content model | **Runtime, HubSpot-owned** | Campaign content is authored by the **marketing team in HubSpot** and fetched **by slug at runtime** via the backend. **No campaign content in the repo; no developer or redeploy to change copy.** (Supersedes the earlier "static bundles now" idea.) See §5.2 / §5.5. |
+| Backend relationship | **Same product; reuses the AI-BDR backend** | This funnel is the new UI / front door of TOGA's existing **AI-BDR** product; it reuses that system's HubSpot/Toga/callback calls (documented at `2.0/apps/ai-bdr/`). Lead/callback handoff still goes behind `LeadSink`/`CallbackService` adapters for a clean seam. |
+| Campaign entry | **Plan recommends** | See §5.5. |
+| Copy rules | **No em dashes; one accent source** | Accent enforced in code. No-em-dash cannot be linted on HubSpot-authored copy: enforce via author guidance + a normalization pass in the backend mapping. |
+| Client | Shared / internal | No per-client theming/entitlement logic. |
+
+---
+
+## 5. Target architecture
+
+### 5.1 Prototype → production porting strategy
+The mockup is already **React** (React 18 via UMD + in-browser Babel, no build step). Production is a
+**Next.js (App Router) + TypeScript** app, matching `info` (note `info/AGENTS.md`: Next has breaking
+changes vs. older versions; read the bundled docs in `node_modules/next/dist/docs/` before coding).
+Port approach:
+- Move `styles.css` in as the base stylesheet (Tailwind optional; the mockup is hand-authored CSS
+  with CSS variables, so keep it and layer Tailwind only if desired). Preserve the CSS-variable
+  accent system verbatim.
+- Convert each `components.jsx` / `screens.jsx` unit into a real module. The interactive Agent Studio
+  screens are **client components** (`"use client"`, they use state/effects/animation); the top-level
+  page is a **server component** that resolves the campaign + primes the lead server-side, then hands
+  data to the client flow. Replace UMD globals / `window.*` with imports. Keep `SwapFade` / `Particles`.
+- Replace `ASSET`/`window.__resources` with the Next asset pipeline (files in `public/`, imported URLs).
+  Migrate agent art / talking videos / walkthrough video / particles.
+- Replace `localStorage` boot logic with the same behavior in a client provider/hook.
+
+> **Server = built in (this is why Next.js helps here).** `info`'s HubSpot/Toga calls use **secrets**
+> (`HUBSPOT_ACCESS_TOKEN`, `TOGA_CLIENT_API_SECRET`, ...) that must never ship to the browser. In
+> Next.js those calls live in **server components + route handlers**, so there is no separate backend
+> or service to stand up. Keep secret-bearing code out of client components and never expose it via
+> `NEXT_PUBLIC_` env.
+
+### 5.2 Content provider — HubSpot is the source of truth
+**Campaign content lives in HubSpot, authored by marketing, and is fetched by slug at runtime.**
+It is **not** stored in the repo, and changing copy requires **no developer and no redeploy**. The
+provider is the seam that makes this true:
+```ts
+interface CampaignContentProvider {
+  resolve(slug: string | undefined): Promise<CampaignBundle>; // returns the safety-net fallback if unknown/unreachable
+  list?(): Promise<CampaignSummary[]>;
+}
+// Primary:  HubSpotContentProvider — runs server-side (in the page's server component / a route
+//           handler). Reads the campaign content from HubSpot (see §9.10 for the exact HubSpot
+//           mechanism), maps it to a CampaignBundle, and caches it. Secrets stay server-side.
+// Fallback: a minimal built-in DEFAULT bundle (engineering safety net only, NOT authored marketing
+//           copy) so the funnel still renders if a slug is unknown or HubSpot is briefly unreachable.
+```
+`resolve(slug)` runs on the server during render (SSR), so the HubSpot fetch + field mapping to the
+`CampaignBundle` shape (§6) happens before the page is sent, with Next caching / revalidation so
+marketing edits appear quickly without a deploy (and the public site stays SEO-friendly). The client
+components receive the resolved bundle as props / via `useCampaign()`; they never see HubSpot.
+
+> **Key sub-decision (open, §9.10):** *how* campaign content is represented in HubSpot. HubSpot's
+> "Campaigns" tool is built for attribution, not rich structured copy, so this depth of content
+> (headlines, a ~10-entry Q&A pool, agent identity, call summaries) needs a deliberate home. Likely
+> **HubDB** (a CMS-Hub table: one row per campaign, a `slug` column + content columns, API-fetchable)
+> or a **custom object**. This choice drives the fetch + the field mapping and needs confirmation with
+> whoever owns the HubSpot instance.
+
+### 5.3 Campaign as data, components as renderers
+Follow the TOGA config-driven precedents (`toga25-supply` `useClientFields`; `toga2-commerce` Cart
+C1..C7): resolve a bundle keyed by campaign, always with a `DEFAULT` fallback; render through the
+components; never branch `if (campaign === 'x')` in JSX. Non-serializable behavior (a CTA action,
+an icon) is referenced by an **enum key** hydrated via a `Record<key, fn|Component>` registry at the
+view-model layer, so bundles stay pure data (so HubSpot only ever stores plain strings/values).
+
+### 5.4 Flow state machine
+A `useAgentFlow(campaign)` hook owns `screen` + transitions (the `go()` / `back` map from `app.jsx`),
+the modal gates (`welcome`, `welcome2`, `earlyAccess`), and step derivation (`stepFor`). Screens are
+presentational and receive copy from the bundle + handlers from the hook. This mirrors the existing
+shell but makes the copy and agent identity injected rather than inlined.
+
+### 5.5 How the front end knows which campaign to display (URL-driven, slug-keyed)
+**Short answer: yes, it is URL-driven. Every campaign has a stable `slug`; the server reads the slug
+from the request URL and loads that campaign's data through the provider (at render time).** End to end:
+
+**1. Each campaign has a slug.** A short, stable identifier, for example `bdr-service`, `healthcare`.
+The slug is the key marketing's HubSpot campaign is looked up by. It lives **in HubSpot, not the
+repo** (§5.2); the repo only holds the type/schema, the HubSpot->bundle mapping, and a minimal
+safety-net `DEFAULT`.
+
+**2. The URL carries the slug.** Two supported shapes (both resolved by one `resolveCampaignId()`):
+- **Query param (recommended to ship first):** `bdr.togatech.com/?campaign=bdr-service`. Matches how
+  leads actually arrive: HubSpot outreach links are query-based, and `info` already reads a
+  `?hsCampaignId=` param, so this slots into existing outreach with no new infrastructure.
+- **Path (add later, optional):** `bdr.togatech.com/c/bdr-service`. Cleaner shareable URLs; added via
+  the client router without touching components once the query path exists.
+
+**3. Resolution order** (first match wins): explicit `?campaign=<slug>` -> mapped `?hsCampaignId=<id>`
+(id -> slug lookup, so CRM links keep working) -> `DEFAULT`. An unknown or missing slug always falls
+back to the `DEFAULT` bundle, so the funnel never fails to render.
+
+**4. The slug drives a runtime fetch of the content from HubSpot** (this is the confirmed requirement):
+the page's server component calls `provider.resolve(slug)`, which reads that campaign's content from
+**HubSpot** (§9.10), maps it to a `CampaignBundle`, and caches it (Next revalidation). Because this is
+server-side, the fully-populated page is rendered and sent (good for the public site's SEO). Marketing
+edits in HubSpot show up on the next revalidation. **No repo content, no redeploy, no developer** to
+change copy. If the slug is unknown or HubSpot is briefly unreachable, the minimal `DEFAULT` safety net
+renders so the funnel never breaks.
+
+**5. Multiple campaigns run simultaneously by construction.** Selection is per-visitor, derived from
+their URL each load; there is no global "current campaign" state. Any number of campaigns are live at
+once, each just a different slug.
+
+**6. CRM/analytics linkage travels in the bundle.** The resolved bundle carries `hsCampaignId` /
+`togaCampaignUuid`, used when the lead is upserted/linked (§5.6) and for per-campaign GA4, so every
+lead and event is attributed to the right campaign.
+
+**Recommendation:** ship **query-param entry + the HubSpot content provider** from the start (that is
+the confirmed requirement); add **path-based routing** as a nicety later. Keep all of this behind
+`resolveCampaignId()` + `useCampaign()` so none of it is visible to the screens. The one thing that
+must be pinned down before Phase 1 is **how the content is modeled in HubSpot** (§9.10).
+
+### 5.6 Backend adapters (run in the Next.js server)
+The client screens call two interfaces; both run **server-side** (in route handlers / server actions),
+so secrets never reach the browser:
+```ts
+interface LeadSink        { upsertLead(input): Promise<LeadRef>; }              // today: Toga upsert + HubSpot
+interface CallbackService { requestCall(ref, whenOrNow, phone): Promise<void>; } // today: Toga requestCall
+```
+Because BDR is Next.js, these live in the app's own server layer (route handlers such as
+`app/api/call-now/route.ts`, mirroring `info`), so **there is no separate backend to host**.
+Implementation is `info`'s existing logic (`lib/toga.ts`,
+`lib/hubspot.ts`, and its `call-now` / `call-later` route handlers): it **already exists and works**,
+we port it directly, minus the PII logging. The mockup's `Success` simulation is replaced by a real
+`CallbackService` call (immediate vs. scheduled maps to `CONTACT_CALL_TYPE_UUID`).
+
+This funnel is the front door of the existing **AI-BDR** product, so `CallbackService` is implemented
+with that system's callback path (the `info`-ported Toga `requestCall`). The adapter seam keeps the
+client and interfaces stable if that backend path changes.
+
+### 5.7 `togatech` website integration (eventual)
+The site will ultimately be surfaced through the TOGA Technology website (`togatech` repo). Design for
+it now: keep the funnel self-contained and embeddable, prefer a linkable per-campaign URL so
+`togatech` CTAs deep-link into a campaign, and express shared branding as tokens. Integration
+mechanism (subdomain / linked Amplify app vs. iframe vs. absorption into `togatech`) is an open
+question (§9), needed before deploy, not before building.
+
+### 5.8 Asset pipeline
+Migrate agent art (Human/Owl/Robot × up-to-9 slots), talking videos, the customization walkthrough
+video, and particle/Lottie assets into `public/`. Keep `preloadAgentAssets` behavior so screen swaps
+never blank. Prune unused slots per the campaigns actually shipped (the default flow uses one agent).
+
+---
+
+## 6. Campaign bundle schema (concrete sketch)
+This is the shape the app consumes. It is **produced server-side by mapping the HubSpot campaign
+content (§5.2) into this structure** — it is the contract between "how marketing's content is stored
+in HubSpot" and "what the components render," and the mapping layer is where HubSpot fields become
+these fields (and where the no-em-dash normalization runs). Serializable data only; behavior/icons by
+key. Covers the real content surfaces from §2.4.
+
+> The richer fields here (the nested `pool: QA[]` + `sets`, `callSummaries`, `RichLine` accent spans)
+> are the parts hardest to represent in a marketing-friendly way in HubSpot — a direct input to the
+> §9.10 modeling decision. Flat columns handle the simple strings; nested arrays likely need child
+> rows or a structured (JSON) field.
+```ts
+interface AgentIdentity {
+  form: "Human" | "Owl" | "Robot";
+  slot: number;                 // 0..8
+  accent: string;               // one of the 5 TOGA accents -> --accent
+  voiceGender: "Female" | "Male";
+  voiceIndex: number;
+  name: string;                 // e.g. "Alex"
+}
+
+interface QA { id: string; q: [string, string, string]; a: string; } // a: first-person, no em dashes
+
+interface CampaignBundle {
+  id: string;                   // slug
+  hsCampaignId?: string;        // HubSpot linkage
+  togaCampaignUuid?: string;    // Toga addContactToCampaign linkage
+  agent: AgentIdentity;         // who the campaign presents (default flow does not let user pick)
+  welcome:   { eyebrow: string; heading: string; body: string; values: string[]; primaryCta: string; };
+  landing?:  { heading: RichLine; lede: string; tiles: ServiceTile[]; };   // if the service picker is used
+  capabilities: {
+    step2Intro: { heading: string; body: string; values: string[]; tiles: HowTile[]; };
+    heading: RichLine; lede: string;
+    skills: { icon: string; title: string; desc: string }[];               // CAPS
+    anchor: QA; pool: QA[]; sets: string[][];                              // Q&A bank + rotation
+    ctas: { callNow: string; schedule: string; connectNote: string; };
+  };
+  call:     { heading: string; body: string; footnote: string; };
+  schedule: { heading: string; footnote: string; durationLabel: string; };
+  success:  { callSummaries: { key: string[]; next: string[] }[]; scheduledNote: string; };
+  build?:   { steps: { label: string; value?: string }[]; };              // AutoBuild beats
+  analytics?: { measurementId?: string; eventPrefix?: string };
+  features?: string[];          // capability flags (e.g. "showServicePicker", "allowManualBuilder")
+}
+```
+`RichLine` supports the mockup's accent-inked span (for example `"<agent> is ready to work."`).
+The provider must always return a valid bundle: on an unknown slug or a HubSpot hiccup it falls back
+to a minimal built-in `DEFAULT` (a safety net, not authored marketing copy) so the funnel still renders.
+
+---
+
+## 7. Proposed repo structure (Next.js App Router + TypeScript)
+```
+bdr/
+  src/
+    app/
+      layout.tsx  globals.css              # shell + ported styles.css / CSS variables
+      page.tsx                             # SERVER component: resolve slug -> campaign, prime lead, render flow
+      c/[slug]/page.tsx                    # optional path-based campaign entry (later)
+      api/{lead,call-now,call-later}/route.ts   # SERVER: secret-bearing Toga/HubSpot calls (ported from info)
+    content/
+      schema.ts                            # CampaignBundle types (the contract)
+      hubspotProvider.ts                   # SERVER: reads campaign content from HubSpot + maps to bundle (§5.2/§6)
+      useCampaign.ts                       # client hook to read the resolved bundle
+      default.ts                           # minimal safety-net fallback ONLY (not authored copy)
+      # NOTE: no per-campaign content files here — campaign copy lives in HubSpot, not the repo
+    flow/
+      useAgentFlow.ts                      # screen state machine + modal gates + step rail (client)
+      screens/{Landing,AutoBuild,Capabilities,CallNow,Schedule,Success}.tsx   # "use client"
+      modals/{Welcome,WelcomeStep2,EarlyAccess}.tsx
+    components/                            # ported shared lib (SwapFade, Particles, AgentArt, VoiceDial, ColorSelector, SynapseButton, StepRail, Wordmark, Ico, ...)
+    server/                                # secret-bearing modules, ported from info (PII logging removed)
+      toga.ts  hubspot.ts  leadSink.ts  callbackService.ts
+    lib/ analytics.ts assetPath.ts formatPhone.ts agentData.ts  # AGENT_ART/NAMES/COLORS/VOICES
+  public/                                  # migrated agent art, talking videos, walkthrough, particles
+  amplify.yml  next.config.ts  tsconfig.json  eslint (no-em-dash copy rule on in-repo strings)
+```
+
+---
+
+## 8. Phased execution plan
+Sizing note (from the meeting): once one screen is built cleanly the rest go fast (heavy component
+reuse); the long pole is pixel-perfect UI parity, not logic. We hand Claude the actual mockup source,
+so fidelity should be near-exact.
+
+- **Phase 0 — Bootstrap `bdr`.** New Next.js (App Router) + TypeScript app (mirror `info`'s config;
+  Amplify SSR hosting). Port `styles.css` and the CSS-variable accent system. Set up campaign routing
+  (query param now, `/c/[slug]` later) and ESLint incl. a no-em-dash check on in-repo strings. Read
+  `node_modules/next/dist/docs/` first (Next breaking changes per `info/AGENTS.md`).
+- **Phase 1 — Content layer.** Depends on the §9.10 HubSpot-modeling decision. Define `schema.ts`
+  (the `CampaignBundle` contract), the server-side `hubspotProvider` (`resolve(slug)` reads HubSpot +
+  maps to a bundle, with caching/revalidation + no-em-dash normalization), the `useCampaign` client
+  hook, and a minimal safety-net `DEFAULT`. Seed HubSpot with one real campaign (extract the mockup's
+  current copy into HubSpot, not the repo) to develop against. Unit-test mapping + fallback.
+- **Phase 2 — Port the component library.** Bring `components.jsx` across as real modules (SwapFade,
+  Particles, AgentArt + data, VoiceDial, ColorSelector, SynapseButton, StepRail, Wordmark, Ico,
+  asset/preload). Migrate assets to `public/`. This unblocks every screen.
+- **Phase 3 — Build one screen end to end (Capabilities), config-driven.** It is the richest
+  (skills + Q&A bank + CTAs), so building it first calibrates the real estimate and proves the bundle
+  schema before the remaining screens.
+- **Phase 4 — Remaining screens + modals from config.** AutoBuild, Landing (behind a feature flag),
+  Call Now, Schedule, Success, Welcome/WelcomeStep2/EarlyAccess, StepRail. Remove all hardcoded copy.
+- **Phase 5 — Wire the real backend.** Port `info`'s `lib/toga.ts` / `lib/hubspot.ts` + its call
+  route handlers into BDR's `app/api/*` (server-side); wire the `LeadSink` / `CallbackService`
+  adapters; replace the `Success` simulation with real immediate/scheduled `requestCall`; remove PII
+  logging; resolve the `visit` route (implement or drop).
+- **Phase 6 — Second campaign + multi-campaign.** Author a second campaign **in HubSpot** (for example
+  a `healthcare` variant using the healthcare proof points) alongside `bdr-service`; prove that adding a
+  campaign needs only HubSpot edits (no code, no deploy) and zero component diffs; validate slug
+  resolution and simultaneous campaigns.
+- **Phase 7 — Analytics + polish.** Per-campaign GA4, pixel-perfect pass vs. the mockup, motion/timing
+  parity, accessibility check.
+- **Phase 8 — Deploy.** Amplify env vars, README, "how to add a campaign" doc; confirm `togatech`
+  integration mechanism.
+
+---
+
+## 9. Open questions (leadership + HubSpot owner). Most do not block early work; **§9.10 gates Phase 1**.
+1. **Backend relationship:** RESOLVED — `bdr` is the new UI / front door of TOGA's existing **AI-BDR**
+   product (not standalone); it reuses that system's backend calls, and its knowledge is filed under
+   `2.0/apps/ai-bdr/`. `CallbackService` uses that system's callback path.
+2. **Runtime editability:** RESOLVED — content is authored by marketing **in HubSpot** and fetched by
+   slug at runtime; no repo content, no redeploy. The remaining question is the HubSpot mechanism (§9.10).
+3. **Agent choice:** Stay with a campaign-fixed agent (auto-build to a preset), or ship the manual
+   Creator (currently parked / "coming soon")? Determines whether `Creator` + full slot art ship now.
+4. **Service picker:** Is the `Landing` service-selection screen (AI BDR + "Talos coming soon") in
+   scope for launch, or parked like in the mockup?
+5. **Campaign catalog:** How many campaigns at launch and who authors copy? Confirms entry UX (§5.5).
+6. **`togatech` integration mechanism:** subdomain / linked Amplify app vs. iframe/embed vs. absorption
+   into `togatech`. Needed before Phase 8.
+7. **Tweaks panel:** keep the dev tuning panel (synapse/radius/accent) in production or strip it?
+8. **First campaign direction + verbiage** (BDR-as-a-service vs. healthcare): needed only to fill the
+   first bundle, not to build the engine.
+9. **Backend hosting:** RESOLVED by the Next.js choice — the secret-bearing HubSpot/Toga calls run in
+   BDR's own server components / route handlers; no separate backend to host. Only remaining item is
+   confirming the Amplify **SSR** hosting target (not static) at deploy.
+10. **HubSpot content mechanism (blocks Phase 1) — the big one.** *How* is campaign content stored in
+    HubSpot so it is marketing-editable and fetchable by slug? `info` gives no precedent (it only reads
+    contacts). Options: **HubDB** (CMS-Hub table, one row per campaign, `slug` column + content columns,
+    API-fetchable — the likely fit) vs. a **custom object** vs. properties on the Campaigns object. This
+    determines the fetch + the HubSpot->`CampaignBundle` mapping. Sub-parts to settle with the HubSpot
+    owner: which mechanism; how the **nested content** (Q&A pool + rotation sets, call summaries, accent
+    `RichLine`s) is represented (flat columns can't hold arrays cleanly — child rows or a JSON field);
+    who authors/owns the schema; and how the slug relates to the existing `hsCampaignId`/Toga campaign
+    UUID used for attribution.
+
+---
+
+## 10. Risks & gotchas
+- **Next breaking changes** (per `info/AGENTS.md`): read the bundled `node_modules/next/dist/docs/`
+  before coding; do not assume older-Next APIs.
+- **Keep secrets in server code.** `HUBSPOT_ACCESS_TOKEN` / `TOGA_CLIENT_API_SECRET` and the
+  token-exchange must live in server components / route handlers, never in a `"use client"` component
+  or a `NEXT_PUBLIC_` env var (those ship to the browser). The interactive screens are client
+  components, so the boundary matters: secret-bearing calls stay in `app/api/*` + server modules.
+- **No `2.0/standards/frontend.md`** exists; `toga2-view` conventions are the de-facto standard
+  (single axios/api client, `use*ViewModel` hooks, presentational views). Keep the viewmodel-vs-view
+  split in spirit.
+- **PII in logs** (existing `info` debt): log ids only, never email/phone/tokens.
+- **HubSpot as content store is net-new** (no `info` precedent). Biggest unknown is fitting the mockup's
+  rich, nested content (Q&A pool + sets, call summaries, accent `RichLine`s) into something marketing can
+  edit (§9.10). Flat strings are easy; nested arrays are the hard part.
+- **Runtime fetch = latency + availability**: the content now depends on a HubSpot call on load. Cache
+  in the backend with short revalidation, and keep the `DEFAULT` safety net so a HubSpot hiccup or an
+  unknown slug never breaks the funnel. Mind HubSpot API rate limits.
+- **Serializable content only**: the bundle stays pure data (no JSX/functions); behavior/icons are enum
+  keys hydrated in code, so HubSpot only ever needs to store strings/values.
+- **No-em-dash cannot be linted on HubSpot copy**: enforce via marketing author guidance + a
+  normalization pass in the backend mapping.
+- **DEFAULT must always render**: an unknown/absent slug (or HubSpot down) falls back cleanly, never a
+  404 funnel.
+- **Single accent source**: every accent-tinted element routes through `var(--accent)` /
+  `color-mix`; never hardcode an accent (mockup `CLAUDE.md` rule).
+- **Motion fidelity**: the mockup hardens transitions against stalled animation clocks (settle guards,
+  effect-owned timers). Preserve these when porting; do not "simplify" them away.
+- **Asset weight**: full slot art/video for 3 forms × 9 slots is large; ship only what the launched
+  campaigns use.
+
+## 11. Cleanup / fidelity checklist
+- [ ] No hardcoded marketing copy in any component (grep-verified).
+- [ ] No `if (campaign === …)` branches in components.
+- [ ] No em dashes in any shipped string; single `--accent` source respected.
+- [ ] `info` debug logging dropped; no PII in logs.
+- [ ] `visit` route resolved (implemented or removed).
+- [ ] Env vars documented; no secrets committed.
+- [ ] Pixel-perfect parity pass against the mockup screens + screenshots.
+
+## Change history
+- 2026-07-08 — Captured the full BDR web-funnel implementation plan verbatim into the knowledge repo as a companion to the distilled `web-funnel-content-model.md` feature doc (redundancy intentional). (tcox)

package/knowledge/INDEX.md

@@ -17,7 +17,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 
 ## 2.0 framework
 
-- **_underscore** (_Underscore) _(framework core)_ — 25 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
+- **_underscore** (_Underscore) _(framework core)_ — 26 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
 - **worker2** (Worker) — 27 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 10 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
 - **dbchanges2** (Database Changes) _(framework core)_ — 3 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
@@ -27,7 +27,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **toga2-hub** (TOGa Hub) — 2 doc(s) → [2.0/apps/toga2-hub/INDEX.md](2.0/apps/toga2-hub/INDEX.md)
 - **talos** (TOGa IQ) — 7 doc(s) → [2.0/apps/talos/INDEX.md](2.0/apps/talos/INDEX.md)
 - **voice-to-voice** (TOGa Voice) — 4 doc(s) → [2.0/apps/voice-to-voice/INDEX.md](2.0/apps/voice-to-voice/INDEX.md)
-- **ai-bdr** (AI-BDR) — 5 doc(s) → [2.0/apps/ai-bdr/INDEX.md](2.0/apps/ai-bdr/INDEX.md)
+- **ai-bdr** (AI-BDR) — 6 doc(s) → [2.0/apps/ai-bdr/INDEX.md](2.0/apps/ai-bdr/INDEX.md)
 - **toga2-commerce** (TOGa Commerce) — 7 doc(s) → [2.0/apps/toga2-commerce/INDEX.md](2.0/apps/toga2-commerce/INDEX.md)
 - **toga25-supply** (TOGa 2.5 Supply) — 8 doc(s) → [2.0/apps/toga25-supply/INDEX.md](2.0/apps/toga25-supply/INDEX.md)
 - **toga-blox** (TOGa Blox) — 7 doc(s) → [2.0/apps/toga-blox/INDEX.md](2.0/apps/toga-blox/INDEX.md)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.287",
+  "version": "1.0.289",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",