toga-ai 1.0.285 → 1.0.287

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

@@ -5,4 +5,5 @@
 | [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 |
 | [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 |
 | [New-Campaign Onboarding (6-phase runbook)](workflows/new-campaign-onboarding.md) | The end-to-end procedure for launching a new outbound BDR campaign (industry, offer, target persona, geography). | ai-bdr/docs/client-onboarding-sop.md, ai-bdr/docs/calcom-new-campaign-event-guide.md, ai-bdr/prompts/templates/campaign-template.md, ai-bdr/scripts/update_assistant.py, ai-bdr/scripts/update_system_prompt.py |

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

@@ -6,8 +6,8 @@ project: AI-BDR
 client: shared
 type: architecture
 status: active
-updated: 2026-06-16
-owners: [akhokhani]
+updated: 2026-07-08
+owners: [akhokhani, tcox]
 files:
   - ai-bdr/README.md
   - ai-bdr/requirements.txt
@@ -30,6 +30,7 @@ files:
 related:
   - features/vapi-integration.md
   - features/call-orchestration.md
+  - features/web-funnel-content-model.md
   - workflows/new-campaign-onboarding.md
 ---
 
@@ -175,6 +176,19 @@ authored here, then pushed to Vapi by `scripts/update_system_prompt.py`.
 - **No Langfuse / OTEL** — there is no TOGA-side LLM call to trace; the
   LLM call happens inside Vapi.
 
+## Public web funnel (UI / lead-capture front door)
+
+The AI-BDR product now has a **public-facing web funnel** — a **Next.js (App Router)**
+app in its own code repo, **`bdr`** — as its UI and lead-capture front door. It **reuses
+this system's existing calls** (HubSpot contact fetch, Toga upsert + campaign link,
+`requestCall` callback — see *End-to-end call flow* and `features/call-orchestration.md`),
+ported from the external `info` repo behind `LeadSink` / `CallbackService` adapters so all
+secret-bearing calls stay server-side. On top of that reuse it adds a **HubSpot-owned,
+config-driven campaign content layer**: marketing authors campaign content in HubSpot,
+fetched by slug at runtime and mapped to a serializable `CampaignBundle` (config-driven
+components, `DEFAULT` fallback — no `if(campaign===x)`; a copy change ships with no
+redeploy). Full detail: **`features/web-funnel-content-model.md`**.
+
 ## Key decisions
 
 - **Single shared structured-output schema** across all assistants — keeps
@@ -195,3 +209,7 @@ authored here, then pushed to Vapi by `scripts/update_system_prompt.py`.
 
 ## Change history
 - 2026-06-16 — Initial architecture doc for AI-BDR. (akhokhani)
+- 2026-07-08 — Additive: recorded the public Next.js web funnel (code repo `bdr`) as the
+  product's UI / lead-capture front door — reuses this system's existing HubSpot/Toga/callback
+  calls and adds a HubSpot-owned, config-driven campaign content layer. See
+  `features/web-funnel-content-model.md`. (tcox)

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

@@ -0,0 +1,148 @@
+---
+title: Web Funnel — Next.js UI + Config-Driven Campaign Content
+framework: "2.0"
+repo: ai-bdr
+project: AI-BDR
+client: shared
+type: feature
+status: draft
+updated: 2026-07-08
+owners: [tcox]
+files:
+  - 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
+related:
+  - ../architecture.md
+  - call-orchestration.md
+---
+
+## What this is
+
+The **public-facing web funnel** is the new UI / lead-capture front door of the **same
+AI-BDR product** documented in `../architecture.md`. It is a **Next.js (App Router) +
+TypeScript** app living in its own code repo, `bdr` (registered separately because it is a
+distinct codebase). Only the UI/content layer is new — the funnel **reuses this AI-BDR
+system's existing backend calls** (see "Backend reuse" below); the API/backend contracts
+are already documented and are **not** restated here.
+
+The UI is built pixel-perfect from the mockup at `BDR/mockup`: a **7-screen "Agent Studio"
+flow** — Welcome → AutoBuild → Capabilities → Call Now / Schedule → Success. The
+agent-identity model is **form × slot × accent × voice × name** (form Human/Owl/Robot ×
+slot 0–8 × one of 5 TOGA accents → `--accent` × voice × name). Two shipped-copy rules from
+the mockup are load-bearing: a **single `--accent` source** (every accent-tinted element
+routes through `var(--accent)` + derived `--accent-fill`; never hardcode an accent) and
+**no em dashes** in any shipped copy.
+
+Full implementation plan: `BDR/PLAN.md`.
+
+## Config-driven campaign content (HubSpot-owned, fetched by slug at runtime)
+
+Every campaign is a **serializable data bundle** (`CampaignBundle`) keyed by a stable
+`slug`. **Campaign content is authored by the marketing team in HubSpot** and fetched **by
+slug at runtime, server-side**, then mapped to a `CampaignBundle`. Content is **not** stored
+in the repo — a new campaign or a copy edit ships with **no developer and no redeploy**,
+only a HubSpot edit.
+
+Config-driven, per TOGA precedent (`toga25-supply`'s `useClientFields`,
+`toga2-commerce`'s Cart C1–C7): components are **pure renderers of a bundle**; there is
+**no `if (campaign === 'x')` branching** anywhere in the screens. The repo holds only the
+**schema** (`CampaignBundle` types), the **HubSpot→bundle mapping** (provider), and a
+minimal safety-net **`DEFAULT`** bundle (an engineering fallback, not authored copy).
+
+- **Provider seam.** `CampaignContentProvider.resolve(slug)` returns a `CampaignBundle` (or
+  `DEFAULT` on an unknown/unreachable slug). `HubSpotContentProvider` runs **server-side**
+  (page server component / route handler), maps HubSpot content to a `CampaignBundle`,
+  caches it (Next revalidation), and applies the no-em-dash normalization pass. Client
+  components receive the resolved bundle as props / via `useCampaign()` and never see
+  HubSpot.
+- **Serializable-only bundles.** Non-serializable behavior (a CTA action, an icon) is
+  referenced by an **enum key** and hydrated at the view-model layer through a
+  `Record<key, fn|Component>` registry — HubSpot only ever stores plain strings/values.
+- **Campaign selection is URL-driven, per-request.** `resolveCampaignId()`, first match
+  wins: `?campaign=<slug>` → mapped `?hsCampaignId=<id>` (id→slug lookup so existing
+  outreach/CRM links keep working) → `DEFAULT`. Query-param entry ships first (matches how
+  leads arrive and how the ported backend already reads `?hsCampaignId=`); optional
+  `/c/[slug]` path later. No global "current campaign" state — selection is derived from
+  each visitor's URL, so any number of campaigns run **simultaneously**.
+- **Attribution travels in the bundle.** The resolved bundle carries `hsCampaignId` and
+  `togaCampaignUuid`, used when the lead is upserted/linked and for per-campaign GA4.
+
+### CampaignBundle shape (contract)
+
+Keyed by `slug` (`id`). Carries `agent: AgentIdentity` (form × slot × accent → `--accent` ×
+voice × name; the default flow does not let the user pick, so agent identity is effectively
+campaign config), plus `welcome`, optional `landing`, `capabilities` (skill cards +
+`anchor`/`pool`/`sets` Q&A bank + CTAs), `call`, `schedule`, `success` (`callSummaries`),
+optional `build` (AutoBuild beats), `analytics`, and `features[]` capability flags.
+`RichLine` supports the accent-inked span the mockup uses (e.g. `"<agent> is ready to
+work."`). The mapping layer is the seam between HubSpot storage and this contract.
+
+## Backend reuse (from the `info` repo; existing AI-BDR calls)
+
+The funnel's Call Now / Schedule screens submit to a real backend **ported from the
+external `info` repo** (github.com/agilantsolutions/info — a Next.js app whose `/bdr` route
+already runs these calls in production). `info` is an **external reference repo, not a TOGA
+registry repo** — port its logic, do not register or rebuild it. The ported logic drives
+**this AI-BDR system's existing backend calls** (HubSpot contact fetch, Toga upsert +
+campaign link, `requestCall` callback) — those contracts are already documented in
+`call-orchestration.md` and `../architecture.md`; do **not** restate them.
+
+Because BDR is Next.js there is no separate backend to host — all secret-bearing calls run
+server-side (route handlers / server actions in `app/api/*`), wrapped behind two adapters
+so only the impl changes later:
+
+- `LeadSink.upsertLead(input)` → Toga upsert-by-email + campaign link + HubSpot.
+- `CallbackService.requestCall(ref, whenOrNow, phone)` → Toga `requestCall`, immediate vs.
+  scheduled mapped to `CONTACT_CALL_TYPE_UUID`.
+
+Note on "campaign": `info` uses HubSpot **only to fetch the contact**; the URL's
+`hsCampaignId` is passed to Toga as the attribution campaign UUID
+(`addContactToCampaign`) — attribution-only in `info`. **Fetching marketing content by
+slug from HubSpot is net-new** to this funnel (above). The content slug and the attribution
+UUID are related but distinct; the `CampaignBundle` carries the UUID so a slug maps to the
+right campaign for logging.
+
+### Environment (values live in env / Amplify config, never in the repo)
+
+- `HUBSPOT_ACCESS_TOKEN`
+- `TOGA_API_BASE_URL`, `TOGA_CLIENT_ID`, `TOGA_CLIENT_API_UUID`, `TOGA_CLIENT_API_SECRET`
+- `NEXT_PUBLIC_GA_MEASUREMENT_ID`
+
+## Gotchas
+
+- **HubSpot content mechanism is an OPEN question that gates the content-layer phase.**
+  `info` gives no precedent (it only *reads contacts*). Candidate homes: **HubDB** (CMS-Hub
+  table — one row per campaign, `slug` column + content columns, API-fetchable; likely fit)
+  vs. a **custom object** vs. properties on the Campaigns object. The hard part is the
+  **nested content** — Q&A pool + rotation sets, call summaries, accent `RichLine`s — which
+  flat columns can't hold cleanly, so it needs child rows or a structured (JSON) field.
+  Settle with the HubSpot owner before building the content layer.
+- **Keep secrets server-side.** `TOGA_CLIENT_API_SECRET` / `HUBSPOT_ACCESS_TOKEN` 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 Agent
+  Studio screens are client components, so this boundary is load-bearing.
+- **Do NOT port `info`'s debug `console.log`s** — several log PII (email/phone). Log
+  identifiers only.
+- **Do not port `info`'s hero/curiosity marketing UI** — it is a different, older funnel.
+- **`DEFAULT` must always render.** An unknown/absent slug or a brief HubSpot outage falls
+  back to the built-in safety net — never a 404 funnel.
+- **Runtime fetch adds latency + an availability dependency.** Cache server-side with short
+  revalidation; mind HubSpot API rate limits.
+- **No em dashes in any shipped copy** (mockup rule) — can't be linted on HubSpot-authored
+  copy, so enforce via marketing author guidance + the normalization pass; in-repo strings
+  get an ESLint no-em-dash check.
+- **Single accent source** (mockup rule): every accent-tinted element routes through
+  `var(--accent)` (+ derived `--accent-fill`); never hardcode an accent value.
+
+## Change history
+- 2026-07-08 — Initial doc: Next.js App Router web funnel as the AI-BDR product's UI /
+  lead-capture front door; config-driven campaign bundle authored in HubSpot and fetched by
+  slug server-side at runtime (`DEFAULT` fallback, URL-driven per-request selection); backend
+  ported from the external `info` repo behind LeadSink/CallbackService adapters, reusing this
+  AI-BDR system's existing calls. HubSpot content mechanism still open. (tcox)

package/knowledge/2.0/apps/worker2/features/clickup-work-type-automation.md

@@ -6,7 +6,7 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-06-23
+updated: 2026-07-08
 owners: ["jcardinal"]
 files:
   - worker2/Worker/Clickup.php
@@ -69,8 +69,26 @@ None — internal team/sprint tooling, uniform across clients.
 - **No PHPUnit harness** in worker2. The regression test
   `Tests/Worker/ClickupWorkTypeTest.php` is a plain-PHP script (reflection on
   `isStatusComplete`) run with `php Tests/Worker/ClickupWorkTypeTest.php`.
+- **ClickUp dropdown custom-field `value` is the option ORDERINDEX, not its name.** The
+  webhook payload for a dropdown/labels custom field delivers the selected option's integer
+  `orderindex`, *not* the option's display name. Any name-keyed lookup (e.g.
+  `$lookupPreviousSprintWorkTypeByName`) will silently never match if fed the raw `value`.
+  Resolve the name first via the field's own `type_config->options` — build a map keyed by
+  `orderindex` (`$workTypesByIndex[$opt->orderindex] = $opt`) and read `->name` from it. This
+  is the proven pattern in `_Worker_Team_Sprint::SprintLock` (`Worker/Team/Sprint.php`, the
+  Work Type resolve ~L3894 and the POST ~L3971). Guard the lookup with
+  `isset($workTypesByIndex[$value])` so a stale/deleted option orderindex doesn't warn.
 
 ## Change history
+- 2026-07-08 — Fixed **Previous Sprint Work Type** never being set on tasks created after a
+  sprint launched (`taskCreated` case, `Worker/Clickup.php` ~L715-751). Root cause: the handler
+  assigned `$workType = $customField->value` (the ClickUp option orderindex, an int) then looked
+  it up in a name-keyed map, so the `isset()` guard never matched and the POST silently never
+  fired. Now resolves orderindex→name via the WORKTYPE field's `type_config->options`
+  (`$workTypesByIndex`), matching the `SprintLock` convention, with an added
+  `isset($workTypesByIndex[$value])` guard. Also added: empty Work Type now defaults to
+  `Unplanned` before the Previous Sprint Work Type lookup so newly-created tasks still get a
+  value. `php -l` clean; php-reviewer approved. (jcardinal)
 - 2026-06-23 — Fixed dependents staying Conditional after a blocker completed: completion check
   now treats `closed` as terminal alongside `done`, and `taskStatusUpdated` re-evaluates
   dependents (gated to terminal statuses). Added `COMPLETE_STATUS_TYPES`, `isStatusComplete()`,

package/knowledge/INDEX.md

@@ -27,10 +27,11 @@ _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) — 4 doc(s) → [2.0/apps/ai-bdr/INDEX.md](2.0/apps/ai-bdr/INDEX.md)
+- **ai-bdr** (AI-BDR) — 5 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)
+- **bdr** (BDR) — 0 doc(s) → [2.0/apps/bdr/INDEX.md](2.0/apps/bdr/INDEX.md)
 
 ## standalone framework
 

package/knowledge/registry.json

@@ -210,5 +210,14 @@
     "dependsOn": [
       "library"
     ]
+  },
+  {
+    "repo": "bdr",
+    "project": "BDR",
+    "framework": "2.0",
+    "role": "app",
+    "dependsOn": [
+      "api2"
+    ]
   }
 ]

package/package.json

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