@leadbay/mcp 0.27.0 → 0.28.0

package/CHANGELOG.md

@@ -1,5 +1,60 @@
 # Changelog — @leadbay/mcp
 
+## 0.28.0 — 2026-07-31
+
+Add **`leadbay_top_accounts_to_activate`** — a prompt that builds a ranked
+account-**conquest** plan from Leadbay data: the accounts worth activating,
+ranked by the strongest Leadbay signal (not by money — Leadbay holds no
+invoicing data), each carrying one of six strategic motifs (SAUVETAGE / PLAN DE
+COMPTE / MONTÉE EN GAMME / RÉVEIL / CONQUÊTE / SUIVI) that drives its phone
+pitch and three-step checklist (product#3863). Renders via `leadbay_artifact_kit` when the user
+accepts the offered deck; the chat table stands alone otherwise.
+
+**Leadbay-only by design.** Leadbay holds no invoicing data, so the plan ranks
+by the strongest Leadbay signal and renders revenue-realized, per-family revenue
+and cash-to-capture as **OMITTED — never estimated**, naming the extract columns
+a cash-ranked version would require. An ERP-ingest mode was explored and
+deliberately cut before release: it depended on inputs the platform cannot
+supply (headcount for off-lens imported leads) and permissions it cannot assume
+(`leadbay_import_leads` is admin-only). It is tracked separately.
+
+**New `gates/data-provenance` snippet.** The deliverable mixes Leadbay
+responses, public-registry counts and modelled assumptions in
+front of a paying client, so every emitted number carries a provenance class
+(`[ERP]` / `[LB]` / `[SIRENE]` / `[HYP]`), taint propagates through derived
+figures, and a PROVENANCE LEDGER prints **before** the plan with un-sourceable
+fields shown as OMITTED instead of quietly filled. The existing
+`iron-laws/no-fabrication` covers identifiers only, so a derived quantity such
+as a revenue figure could previously be invented without violating it.
+
+Also adds `heuristics/account-activation-motifs` and `rendering/activation-card`,
+plus WORKFLOWS entries 46–47 — the conquest plan and its fabrication guard.
+
+The six motifs are SAUVETAGE / PLAN DE COMPTE / MONTÉE EN GAMME / RÉVEIL /
+CONQUÊTE / **SUIVI**. The last is the honest label for an active known-pipeline
+account when no order history is available: the four Pilotage motifs are
+purchase-behaviour reads and CONQUÊTE means "not in the pipeline", so without
+invoicing data an active Monitor row matches none of them. ERP order data would
+split those rows into the Pilotage four.
+
+Fixes a stale `server.json` npx pin that tracked the `0.25` line while the
+package was on `0.26`, and bumps the `.claude-plugin` bundle off `@leadbay/mcp@0.13`,
+which predated `leadbay_get_qualification_questions`,
+`leadbay_scan_portfolio_signals` and `leadbay_artifact_kit`.
+
+## 0.27.0 — 2026-07-31
+
+Consent-gated friction reporting (#171) — see that PR for detail. Released from
+`main`; this entry is a placeholder so the version line is unbroken.
+
+## 0.26.0 — 2026-07-27 (tagged, never published)
+
+Makes **`leadbay_build_campaign`** autonomous: runs to a target `count` with no
+confirm gates, and accepts explicit `job_titles` for buyer enrichment (#169).
+The version was bumped and `mcp-v0.26.0` tagged, but the npm publish did not
+complete — npm's latest remained `0.25.0`. Documented here retroactively;
+`0.27.0` supersedes it and carries these changes forward.
+
 ## 0.25.0 — 2026-07-13
 
 Add `leadbay_set_telemetry` — an in-product control to enable, disable, or check

package/dist/bin.js

@@ -25241,6 +25241,457 @@ End with a NEXT STEPS chip via your host's choice widget (\`ask_user_input_v0\`
 
 Done. The lens is live, the validated cohort is persisted as named campaigns, and the manager knows where the cross-user-visibility gap is.
 `;
+var leadbay_top_accounts_to_activate = `
+## MEMORY
+
+Before responding, glance at any \`_meta.agent_memory.summary\` returned by tool calls earlier in this session and reflect its top signals in your reasoning ("Filtering by your stated preference for healthcare"). After any material new signal from the user this conversation (sector, region, deal size, communication style, qualification rule, explicit retraction, or recurrence / scheduling preference such as "I do this every day" or "remind me every morning"), call \`leadbay_agent_memory_capture\` to persist it: \`source:"user_stated"\` if literal, \`source:"inferred"\` with confidence <=6 if inferred.
+
+
+Build me a **top-{{arg:count_or_default}} account-conquest plan** \u2014 the accounts worth activating, ranked, each one carrying a strategic motif, a phone pitch and a three-step checklist. {{arg:territory_block}}
+
+This deliverable goes in front of a paying client, so **the honesty of the numbers matters more than their completeness**. Deliver the strongest plan the available data actually supports, and be explicit about what it doesn't.
+
+**DATA PROVENANCE \u2014 every number carries its source.** This deliverable mixes
+four data sources with very different trust levels, and it is shown to a
+paying client. A figure whose origin is unstated reads as measured fact. Tag
+every number you emit with exactly one class:
+
+| Tag | Meaning | Where it comes from |
+|---|---|---|
+| \`[ERP]\` | measured in the client's own invoicing / management extract | the file the user attached, or a \`leadbay_get_lead_custom_fields\` read of a value imported from it |
+| \`[LB]\` | returned by a \`leadbay_*\` tool THIS session | \`leadbay_pull_leads\`, \`leadbay_pull_followups\`, \`leadbay_bulk_qualify_leads\`, \`leadbay_enrich_titles\`, \`leadbay_scan_portfolio_signals\`, \`leadbay_account_history\`, \`leadbay_research_lead_by_id\` |
+| \`[SIRENE]\` | the French public company registry | \`recherche-entreprises.api.gouv.fr\` \u2014 **your own web tool, NOT Leadbay.** Leadbay does not proxy the registry |
+| \`[HYP]\` | a modelled assumption | the \u20AC/employee benchmark, the 35 % objective, the trade purchase mix, any Tier-1 threshold the client hasn't confirmed |
+
+**Taint propagates.** A derived figure inherits the weakest class of its
+inputs. \`cash = pot12 \u2212 ca12\` where \`pot12\` is \`[HYP]\` makes **\`cash\` itself
+\`[HYP]\`** \u2014 say so in the artefact's own caveat block, not only in chat. A
+client who mistakes a modelled \`cash\` figure for an audited one will build a
+sales plan on it.
+
+**Print the PROVENANCE LEDGER before you build anything**, BEFORE writing
+artifact code or the final table. The block below is a **shape, not a literal**:
+keep the header, the \`field / class / source\` columns and the closing rule, but
+**replace every \`<...>\` placeholder with the real field name, class and source**
+\u2014 one row per field you actually emit. A ledger still showing \`<field name>\` has
+passed the ordering check while telling the reader nothing, which defeats its
+entire purpose.
+
+\`\`\`
+PROVENANCE LEDGER
+=================
+field           class     source
+<field name>    ERP       <file>:col "<column header>"
+<field name>    LB        <tool that returned it>
+<field name>    SIRENE    recherche-entreprises.api.gouv.fr
+<field name>    HYP       <the formula + which input is assumed>
+<field name>    OMITTED   <why it cannot be computed>
+=================
+\`\`\`
+
+An \`OMITTED\` row is the point of the ledger: it makes a gap **visible** instead
+of silently filled with a plausible guess. Never drop a field from the ledger
+just because you couldn't source it \u2014 render it as \`OMITTED\` with the reason.
+
+**When a number is unavailable, do NOT model it \u2014 switch modes.** Specifically:
+if the client's revenue-realized figure is absent, do not estimate it, do not
+proxy it from headcount / sector / score, and **do not sort by any quantity
+derived from it.** Say plainly which fields are unavailable, name the exact
+columns you'd need, and deliver the plan the prompt describes \u2014 ordered by the
+strongest \`[LB]\` ranking you actually have.
+
+**Sorting is where fabrication hides.** Asked for a ranking "by cash to go
+get" with no revenue data, the tempting move is to invent a revenue figure per
+account purely so the sort produces a plausible-looking order. That is
+fabrication with a confident shape, and it is the single most likely failure of
+this workflow. Change the sort and say so; never invent the key.
+
+**Client-specific parameters are to be CONFIRMED, not assumed as product
+constants.** The Tier-1 threshold, the \u20AC/employee benchmark and the purchase
+mix all come from one client's economics. State each as \`[HYP]\` with its value
+visible and offer to re-run when the client supplies the real figure.
+
+
+GATE \u2014 DEFER TO TOOL RENDERING. When you call a Leadbay composite that ships its own RENDERING block (every composite in 0.9.0+ does), render the response using that block's recipe verbatim \u2014 score bars, glyph palette, column order, hide-list, link priorities, all of it. Do NOT substitute prose, a numbered list, or a different column structure even when an orchestrating prompt's body suggests alternate framing. Prompt-specific commentary (motivational nudges, summaries, next-action recommendations) belongs ABOVE or BELOW the canonical table, never in place of it.
+
+If the prompt's body and the tool's RENDERING appear to conflict, the tool's RENDERING wins for the structural layout; the prompt's voice wins for the commentary that surrounds it.
+
+
+# Resilience rules for Leadbay long-running tools
+
+These four rules apply to every Leadbay workflow that calls \`leadbay_pull_leads\`, \`leadbay_bulk_qualify_leads\`, \`leadbay_research_lead_by_id\`, \`leadbay_import_and_qualify\`, or \`leadbay_enrich_titles\`. **Treat timeouts and stream-closed errors as transient, not as signals to replan.**
+
+## Rule 1 \u2014 Pin the lens
+
+After your first \`leadbay_pull_leads\` call, capture \`response.lens.id\` into your working memory and **pass it explicitly as the \`lensId\` argument to every subsequent call** in this session \u2014 including any re-pulls, bulk qualifies, or research calls that accept it. (Field-name caveat: the response nests it as \`lens.id\`; the parameter on subsequent calls is \`lensId\`.) The active lens can shift between calls (5-minute client cache + backend \`last_requested_lens\` can change if the user touches the web UI). A lens shift mid-workflow throws away your top-10 work.
+
+## Rule 2 \u2014 Prefer async for bulk operations
+
+\`leadbay_bulk_qualify_leads\` and \`leadbay_import_and_qualify\` accept \`wait_for_completion:false\`, which returns \`{status:'running', qualify_id}\` immediately. Then poll \`leadbay_qualify_status\` (or \`leadbay_import_status\`) every ~10s until the job completes. **Use the async pattern by default** \u2014 the blocking default can exceed the MCP client's per-call timeout on large batches and produce a misleading \`"Request timed out"\` even though the server is still working.
+
+## Rule 3 \u2014 Serialize \`leadbay_research_lead_by_id\` fan-out
+
+\`leadbay_research_lead_by_id\` is composite and reads many sub-resources. Calling it on 10 leads in parallel can saturate the transport and produce \`"Tool permission stream closed"\` errors that look like permission failures but are really backpressure. **Call it sequentially**, or at most 3 in parallel. If one call fails with a stream/timeout error, retry that one call once before moving on; on a second failure, note the lead and continue \u2014 do not abandon the remaining leads.
+
+## Rule 4 \u2014 Retry, don't replan
+
+If a Leadbay tool returns \`"Request timed out"\`, \`"stream closed"\`, or any other transport-level error (distinct from a Leadbay-issued error payload), the work may still be running server-side. Do this in order:
+
+1. For bulk tools \u2014 retry with \`wait_for_completion:false\` and poll the status tool with the returned id. Don't re-pull leads; that can shift the lens.
+2. For single-lead tools \u2014 retry the same call once. If it still fails, record the lead id and continue with the rest of the workflow.
+3. **Do not** switch strategies (e.g. "the endpoint is broken, let me re-pull from scratch"). The earlier work is still valid; the timeout was the wire.
+
+If \`pull_leads\` itself fails and you have no prior batch, then yes \u2014 retry it, explicitly pass the lensId you captured (if any), and continue.
+
+
+# PHASE 0 \u2014 SCOPE + STATE
+
+Call \`leadbay_account_status\` for my quota and active lens.
+
+**What this plan is, and what it deliberately isn't.** Leadbay knows who a company is, how it scores, what signals it has and who to call there. It does **not** know what any account buys from me \u2014 invoicing lives in my ERP, and no Leadbay tool exposes it. So this is a **conquest plan**: real accounts, real qualification, real signals, real contacts, ranked by the strongest Leadbay signal available. Revenue-realized, per-family revenue, addressable spend and cash-to-capture are **OMITTED \u2014 never estimated, never proxied from headcount, sector or lead score.**
+
+Say that scope in one line up front, so nobody reads the ranking as a money sort. If I ask for a cash-ranked plan, tell me plainly that it needs my invoicing extract and that the MCP has no path to it today \u2014 then deliver this plan anyway rather than stopping.
+
+**DELIVER FIRST, ASK ALONGSIDE \u2014 never gate the plan on a missing input.** Only ONE thing can stop you before you have shipped a ranked list of real accounts: not knowing **whose** plan this is (a company-identity mismatch you genuinely cannot resolve). Everything else is a question you carry *next to* the delivered plan, not a reason to withhold it:
+
+- **No benchmark?** Costs nothing here \u2014 the money column is OMITTED regardless. Pull, qualify, rank by the Leadbay signal, deliver, and mention what a cash-ranked version would need.
+- **No Tier-1 threshold?** Not a blocker. Deliver, and ask alongside.
+- **No territory?** Not a blocker \u2014 but do NOT call the result "national". You'll be pulling my ACTIVE lens, which may already be scoped to a city, sector or rep patch. Say the plan covers **my active lens's existing scope** (name the lens), not the whole country, and offer to re-scope. Calling a city-scoped lens a national plan misdescribes the deliverable to a client.
+- **\`last_requested_lens: null\`?** Not a blocker \u2014 and **do NOT read it as "no lens exists".** \`leadbay_account_status\` deliberately WITHHOLDS the lens id unless the request mentioned the lens/audience, so a plain "top 50 accounts to activate" returns null even when I have a perfectly good active lens. Default to calling \`leadbay_pull_leads\` with **no** \`lensId\` and let it resolve my active lens; capture \`response.lens.id\` from that result and pin it thereafter. Only create or switch a lens when I explicitly asked to scope or change the audience (e.g. a \`territory\` argument) \u2014 inventing a new lens silently changes what I see in the product.
+- **Only 3 qualification questions instead of 5?** Not a blocker. Use the org's real questions, note the gap, recommend the additions \u2014 do not wait for permission before pulling.
+
+Bundling a non-blocking question in with a blocking one turns a justified pause into an over-wide gate, and the user gets a plan-of-a-plan instead of a plan. The test is **"have I shipped a ranked list of real accounts yet?"** \u2014 if you're about to end a turn without one, you are almost certainly over-gating: deliver first, then ask.
+
+If I gave a \`territory\`, scope discovery to it now, and **make sure the scoping actually took effect before you pull** \u2014 a territory request that silently returns out-of-territory accounts is worse than none.
+
+- **Preferred: \`leadbay_adjust_audience\`** on my active lens, passing the place as \`locations\`. It applies directly, so the lens I already use is now scoped and \`leadbay_pull_leads\` needs no new id.
+
+  \u26A0 **Location criteria MERGE \u2014 they do not replace.** \`adjust_audience\` unions the new \`location_ids\` into any existing include-location criterion (and \`pull_followups\` merges its \`city\` shortcut the same way). So asking for "R\xE9gion Ouest" on a lens already scoped to Paris yields **Paris OR R\xE9gion Ouest** while your header claims R\xE9gion Ouest. Before adding a territory, check the current filter: if it already carries locations you were not asked to keep, clear or replace them (or build a fresh territory-only lens for this one-off plan) rather than stacking a union.
+- **If a new lens is genuinely warranted: \`leadbay_new_lens\` is a two-step call.** It returns \`status:"preview"\` and creates NOTHING unless you re-call the same args with \`confirm:true\`. So: preview \u2192 confirm \u2192 take \`lens.id\` from the \`created\` response \u2192 pass that id as \`lensId\` on every subsequent pull. Never continue on the previous active lens after previewing a new one; that delivers the old audience under a new heading.
+
+A place name goes to \`locations\`, never to \`sectors\` or a refine prompt.
+
+# PHASE 1 \u2014 THE FIVE QUALIFICATION QUESTIONS
+
+Call \`leadbay_get_qualification_questions\` and use the org's **actual** questions \u2014 they become the qualification row on every card. Do NOT invent them.
+
+If the org has none set, or they don't discriminate for this exercise, recommend this shape and offer to set it via \`leadbay_set_qualification_questions\` (max 5, and ask before replacing anything): **Q1** exercises a core-target trade \xB7 **Q2** big enough to matter \xB7 **Q3** operates in the covered territory \xB7 **Q4** recent activity signals \xB7 **Q5** likely need in the next quarter. Q4 and Q5 are the load-bearing pair \u2014 they separate "fits the profile" from "worth calling this week". Recommend; don't overwrite without my say-so.
+
+# PHASE 2 \u2014 THE ACCOUNT UNIVERSE
+
+\u26A0 **Monitor membership is not client status.** Monitor tells you what Leadbay is watching \u2014 lens scoring decides who lands there, not whether the company ever bought anything. Label that pane "Leadbay view membership", never "customer".
+
+**Get the accounts.** \`leadbay_pull_followups\` for the known/identified side, \`leadbay_pull_leads\` for the not-yet-identified side.
+
+\u26A0 **Monitor's scope must match the scope you put in the header \u2014 never leave it accidental.** \`leadbay_pull_followups\` defaults to applying whatever Monitor filter is persisted server-side from a previous session, and that filter has nothing to do with the lens Discover is using. Two stale-state traps, one rule:
+
+- **A persisted filter you didn't ask for** silently shrinks the known side, so a rep who once filtered Monitor to a city gets a "whole base" plan missing most of it.
+- **Blindly passing \`filtered:false\`** does the opposite: Monitor goes org-wide while Discover stays on a scoped lens, so out-of-scope known accounts land in a plan headed with the lens's name.
+
+\u26A0 **You cannot mirror a geography you haven't read.** \`leadbay_pull_leads\` returns only \`lens: {id}\` \u2014 not the lens's filter \u2014 so capturing the id tells you nothing about which locations it covers. Before scoping Monitor to match a lens, read the **\`lens://<id>/definition\` resource** \u2014 that is where the filter and its \`location_ids\` actually live. \`leadbay_my_lenses\` returns only id / name / description / active flags, so it cannot tell you a lens's geography and must not be used for this. If you cannot determine the lens's geography, do NOT guess: pull Monitor org-wide with \`filtered:false\` and say in the header that the known side is org-wide while Discover follows lens \`<id>\`, whose scope you could not read. An unstated mismatch is the failure; a stated one is honest.
+
+So: **read the persisted filter first** (the response reports \`active_filters\`), then make it match the plan's declared scope. If the plan is scoped (a \`territory\`, or an active lens with its own geography), apply that same geography to Monitor. If the plan is genuinely org-wide, pass \`filtered:false\`. Either way, state the known side's scope in the header in the same breath as the Discover side \u2014 a plan whose two halves are scoped differently is misleading even when both halves are individually correct.
+
+\u26A0 **A territory must scope BOTH sides.** Adjusting or creating a lens only scopes Discover; Monitor is filtered through its own path, so pass the territory to \`leadbay_pull_followups\` as well (its \`city\` free-text shortcut resolves to a \`location_ids\` filter, same resolver as the lens). Otherwise a territory-scoped plan quietly mixes in out-of-territory known accounts \u2014 and a client reading "R\xE9gion Ouest" at the top will not check every row. Unless I named a \`territory\`, call \`leadbay_pull_leads\` with **no \`lensId\`** so it resolves my active lens \u2014 do not create a lens just because \`account_status\` showed a null. Capture \`response.lens.id\` from the first pull and pass it as an explicit \`lensId\` on every later call \u2014 a mid-session lens shift discards the cohort. Keep pulling until you have a pool comfortably deeper than {{arg:count_or_default}}, topping up with \`leadbay_bulk_qualify_leads\` \u2192 \`leadbay_qualify_status\` \u2192 re-pull as needed.
+
+# PHASE 3 \u2014 QUALIFY, SIGNAL, MOTIF
+
+**Qualify \u2014 the SELECTED cohort, in chunks of 25.** \`leadbay_bulk_qualify_leads\` caps \`count\` at **25**, so a single call cannot cover a 50-account plan. Loop until the whole cohort is qualified, polling \`leadbay_qualify_status\` between chunks.
+
+\u26A0 **Never qualify Monitor rows through a Discover \`lensId\`.** \`leadbay_qualify_status\` re-checks each lead against the lens it was launched on and returns them under **\`not_in_lens\`** \u2014 the backend does not qualify them, so those rows ship with permanently empty pills while the poll reads "still running". So split the cohort: qualify the Discover rows with the pinned \`lensId\`, and for known-side rows use the qualification data \`leadbay_pull_followups\` already returned rather than re-launching them off-lens. If a Monitor row has no qualification data, say so in its cell \u2014 do not leave a pill that will never fill. **Always read \`not_in_lens\` in the poll response** and report anything listed there rather than waiting on it.
+
+\u26A0 **Pass explicit \`leadIds\` whenever the cohort isn't simply "the next N on the lens"** \u2014 e.g. after you've selected a shortlist, or when the plan mixes Monitor and Discover rows. The \`count\`-based path selects the next *unqualified leads from the lens wishlist*, so on any other cohort it qualifies unrelated leads and hands you handles whose pills belong to different companies. Use \`leadbay_bulk_qualify_leads({leadIds:[\u2026\u226425 of the cohort], wait_for_completion:false})\` and chunk through the cohort's own ids. The \`{lensId, count}\` form is only right when the cohort genuinely *is* the lens's top N.
+
+**Qualify the plan cohort, not the whole base.** Select your ~{{arg:count_or_default}} candidates (plus a modest buffer for drop-outs) BEFORE qualifying \u2014 qualification is async and quota-bearing, so running it across an entire portfolio to produce a top-{{arg:count_or_default}} burns the user's quota for rows that will never appear. **Keep every returned \`qualify_id\`** \u2014 the deck's live qualification layer is wired from those handles, and a deck with none is a dead deck that still looks finished. Never ship a plan whose lower ranks have empty qualification pills because only the first 25 were ever qualified.
+
+**Signals \u2014 scoped to the cohort.** \u26A0 **Always pass the selected \`leadIds\`.** With \`leadIds\` omitted, \`leadbay_scan_portfolio_signals\` builds its own portfolio by paging \`/monitor\` \u2014 so on an imported cohort or a freshly-pulled Discover set it would scan a *different population* and you'd render dashes for accounts whose signals were never read.
+
+\`leadbay_scan_portfolio_signals\` is also a **filtered** read: it requires a concrete \`query\` and returns only the accounts whose cached signals match it. It is not a generic "read every signal" call. So run it **once per why-now theme, as SEPARATE calls** \u2014 expansion/new site \xB7 contract or tender won \xB7 funding \xB7 hiring \xB7 acquisition \xB7 new venue \u2014 and union the results.
+
+\u26A0 **One comma-joined omnibus query is NOT six themed scans.** Cramming every keyword into a single string is one match attempt whose recall you cannot inspect: a lead that would have matched "hiring" alone can be missed, and you have no way to tell which themes actually returned anything. Six calls, six result sets, one union. If a theme returns nothing, that is information \u2014 record it rather than hiding it inside a broad string. An account that matched no query has **not** been shown to be signal-free; render it with an explicit \`\u2014\`, never an invented event. For the identified side, take interaction recency from the fields \`leadbay_pull_followups\` already returned. \u26A0 **Do NOT reach for \`leadbay_account_history\` on Monitor rows outside the active lens** \u2014 it calls \`research_lead_by_id\` first, which fetches \`/lenses/{lensId}/leads/{leadId}\` and 404s off-lens, so the very rows that need a SUIVI / R\xC9VEIL-LB decision are the ones it fails on. Use it only for a lead you know is in the pinned lens.
+
+**SIGNAL HONESTY \u2014 never infer signals from freshness.** \`stale_at\`,
+\`web_fetch_in_progress\`, \`fetch_at\` are freshness markers, not signal
+indicators \u2014 signal presence is read ONLY from the actual \`signals[]\` /
+\`web_fetch.content\` entries. For "which of my leads have signal X" across a
+portfolio, call **\`leadbay_scan_portfolio_signals\`** (bulk-reads cached
+signals); don't loop \`leadbay_research_lead_by_id\` per lead or guess from
+freshness. A lead with no cached content is \`not_researched\`, not "no match";
+never report a signal verdict for a lead you never read.
+
+
+**Assign the motif.**
+
+**THE ACTIVATION MOTIFS.** Every account on the plan carries exactly one motif
+from this closed set of six. The motif is not decoration \u2014 it decides the phone
+pitch, the checklist, and whether the account belongs to the *Pilotage* engine
+(already identified) or the *Conqu\xEAte* engine (not yet identified). Assign it
+from observable data and state the deciding evidence in one line per account.
+
+| Motif | Assign when | Engine |
+|---|---|---|
+| **SAUVETAGE** | was buying steadily, has now stopped \u2014 a recent, sharp break (e.g. no order in ~60\u201390 days against a real history) | Pilotage |
+| **PLAN DE COMPTE** | large, still active, buying broadly \u2014 the risk is complacency, not loss; plan the coming half-year and lock volume terms | Pilotage |
+| **MONT\xC9E EN GAMME** | active but narrow \u2014 buys one product family while comparable accounts of the same size buy several; the gap is cross-sell | Pilotage |
+| **R\xC9VEIL** | account exists, essentially dormant \u2014 long-dead history (e.g. 12+ months at zero) but the company is demonstrably still trading | Pilotage |
+| **CONQU\xCATE** | not present in the Leadbay known pipeline \u2014 in the addressable market, absent from the base. \u26A0 Absence from Monitor is NOT proof they never bought (see below) | Conqu\xEAte |
+| **SUIVI** | in the known pipeline with recent activity, purchase behaviour unknown \u2014 the honest label for an active Monitor row when no order history is available | Pilotage |
+
+**Decision order matters.** Test in this order and stop at the first match, or
+a big lapsed account will be labelled R\xC9VEIL when it is really a SAUVETAGE:
+recent sharp break \u2192 SAUVETAGE; long-dormant \u2192 R\xC9VEIL; never bought \u2192
+CONQU\xCATE; buying broadly at scale \u2192 PLAN DE COMPTE; buying narrowly \u2192
+MONT\xC9E EN GAMME.
+
+**Without order history the first five tests cannot run at all.** In that case
+the split is simply: in the Leadbay known pipeline \u2192 **SUIVI**; not in the
+pipeline \u2192 **CONQU\xCATE**. Never reach for a Pilotage motif you cannot evidence,
+and never invent a seventh label \u2014 the set is closed at six.
+
+When a known-pipeline row has long-dormant *Leadbay* activity, it stays
+**SUIVI** and you say what the dormancy measures in its why-now cell: "no
+Leadbay-logged action in N months". That is a qualifier on the evidence, not a
+new motif. It is NOT R\xC9VEIL \u2014 R\xC9VEIL means dormant *purchasing*, which needs
+order history you do not have.
+
+**What each motif changes in the output.**
+
+- The **pitch angle** \u2014 SAUVETAGE opens on the silence itself and offers terms
+  to resume; PLAN DE COMPTE opens on the relationship and plans forward;
+  MONT\xC9E EN GAMME opens on what comparable firms buy that this one doesn't;
+  R\xC9VEIL asks what made them leave and offers a re-entry incentive; CONQU\xCATE
+  introduces the company and asks for a short first meeting \u2014 **without
+  asserting no prior relationship**. Never write "we've never worked together"
+  or "as a new customer" on a Leadbay-only plan: absence from the known
+  pipeline is not proof they never bought, and that line told to an existing
+  customer is the one mistake a rep cannot walk back. Write the pitch in the
+  client's own commercial voice, naming the specific families and figures the
+  account's data actually supports. **SUIVI** picks up the existing thread \u2014
+  a continuation, never an introduction and never a win-back.
+- The **checklist** \u2014 three concrete, checkable next actions matching the
+  motif's shape: diagnose \u2192 schedule \u2192 send-terms for SAUVETAGE; review \u2192
+  propose \u2192 open-a-family for PLAN DE COMPTE; visit-with-full-tariff \u2192 quote \u2192
+  first-order-in-the-new-family for MONT\xC9E EN GAMME; understand-the-departure \u2192
+  send-offer \u2192 first-order-back for R\xC9VEIL; reach-the-decision-maker \u2192
+  open-the-account \u2192 first-test-order for CONQU\xCATE; confirm-the-state \u2192
+  identify-the-current-need \u2192 agree-a-next-step for SUIVI. When a signal exists,
+  promote "exploit <the signal>" to the top of that account's checklist.
+
+**Motif assignment depends on order history, which is ERP data.** Without the
+client's extract, SAUVETAGE / PLAN DE COMPTE / MONT\xC9E EN GAMME / R\xC9VEIL cannot
+be assigned from purchase behaviour \u2014 do not guess them from a lead score, a
+sector, or a company's size. Two honest options, in order of preference:
+
+**The Monitor gap \u2014 read this before assigning anything.** Four of the six
+motifs (SAUVETAGE / PLAN DE COMPTE / MONT\xC9E EN GAMME / R\xC9VEIL) are purchase-
+behaviour reads, and CONQU\xCATE means "not in the known pipeline". A Monitor row
+that is *actively* worked therefore matches none of them: it IS in the pipeline,
+and without order history you cannot tell whether it buys broadly, narrowly, or
+at all. Do NOT resolve that by guessing a purchase motif, and do NOT silently
+drop the row.
+
+Those rows take **SUIVI** (row 6 of the table above). Say in the plan's legend
+that SUIVI exists precisely because purchase history is unavailable, and that
+ERP order data would split those rows into the four Pilotage motifs.
+
+1. **CONQU\xCATE is assignable from Leadbay alone \u2014 but say what it actually
+   means.** Discover membership proves a company is **not in the Leadbay known
+   pipeline**; it does NOT prove they never bought. Monitor membership is set by
+   lens scoring, not by purchase history, so an existing customer who was never
+   scored into the known view will appear in Discover. Without order history
+   there is no way to tell the two apart.
+
+   So label the motif for what the data supports \u2014 "fresh / not in the Leadbay
+   pipeline" \u2014 and **write the pitch so it survives being wrong**: an opener
+   that introduces the company works for a genuine prospect and merely sounds
+   uninformed to a customer, whereas "we've never worked together" told to a
+   current customer damages the relationship and the credibility of the whole
+   plan. Only ERP order history can upgrade this to a true never-a-client
+   claim. A Leadbay-only plan is still a legitimate *Conqu\xEAte* plan \u2014 say so in
+   the title rather than implying it covers the whole base.
+2. **Leadbay-activity recency is a qualifier, never a motif.** A long-dormant
+   known row stays **SUIVI** with "no Leadbay-logged action in N months" in its
+   why-now cell \u2014 never "no orders in N months", and never a seventh label.
+   Logged activity is not invoicing.
+
+
+# PHASE 4 \u2014 POTENTIAL AND RANKING
+
+Rank by \`ai_agent_lead_score\`, then qualification boost, then headcount. **Name that key in the plan's own header** \u2014 a reader who assumes a money-sort misreads the whole order \u2014 and title the deliverable for what it is (a conquest plan), not for what it isn't.
+
+Cash-to-capture is not available: it needs \`ca12\` from my invoicing system, which no Leadbay tool exposes. Show it as OMITTED in the ledger and say what a cash-ranked version would require (12-month revenue per account, per-family split, last order date, order count, plus a \u20AC/employee benchmark) \u2014 do not model it.
+
+# PHASE 5 \u2014 CONTACTS (consent-gated)
+
+Each card needs a reachable decision-maker. \`leadbay_enrich_titles({leadIds, lensId})\` in discovery mode first \u2014 that reveals what's enrichable and spends nothing. Render whatever contact detail is already on the record; many accounts already carry a named contact.
+
+**Do NOT stop and wait for enrichment consent before delivering.** Asking for a plan is not authorization to spend quota on {{arg:count_or_default}} accounts \u2014 but neither is it a reason to end the turn on a spending question with no plan attached. Ship the ranked plan (Phase 6), then **offer** the paid reveal alongside it. The discovery call returned no \`titles\`, so it only told you what's *available* \u2014 **the offer must therefore carry the titles you propose to enrich AND the channels**, not just a volume: "enrich N contacts at these titles (\`<the titles you picked from available_titles / title_suggestions>\`), email only / email + phone \u2014 reveals consume quota". A bare "yes" to a volume-only question is not a mandate to pick titles yourself, and re-running discovery instead of launching wastes a turn.
+
+\u26A0 **Do NOT quote a cost or a credits figure.** The per-reveal rate is backend-side and enrichment is gated by quota, not a credit balance; \`credits_remaining\` is advisory context only. A spend number invented to make the offer concrete is the same failure as an invented euro on a card.
+
+On an explicit yes, launch with the agreed \`titles\` + channels, then poll \`leadbay_bulk_enrich_status\` until done and **keep the \`bulk_id\` handles** for the deck.
+
+\u26A0 **Render only the channels that actually came back.** The default reveal is email-only unless phone was explicitly requested, so never emit a \`tel:\` link for a contact whose phone was never revealed \u2014 show the channels enrichment returned and mark the rest omitted. A fabricated phone link is the same failure as a fabricated euro.
+
+# PHASE 6 \u2014 DELIVER
+
+Render the PROVENANCE LEDGER and its legend FIRST, then the chat answer beneath it \u2014 never the other way round. A ranked money column read before its sourcing has already misled the reader:
+
+## RENDERING \u2014 account activation plan
+
+Two surfaces. The **chat table** is the default answer and must stand alone as
+useful. The **interactive deck** is offered, not forced (see the widget gate) \u2014
+build it only once the user accepts.
+
+### Order on the page \u2014 ledger FIRST, then the plan
+
+Print the PROVENANCE LEDGER (and the one-line provenance legend) **before** the
+chat table, the deck, or any other part of the deliverable. The reader must know
+which figures are measured and which are modelled *before* they read a ranking
+built on them \u2014 a cash column read first and sourced second has already done its
+damage. This ordering is the workflow contract, not a stylistic preference.
+
+### The chat table (render immediately after the ledger)
+
+**The chat answer must be the whole deliverable the user asked for** \u2014 the deck
+is optional, so a top-50 request whose chat half stops at 10 rows has delivered
+a fifth of the plan. Render the **requested count**, with its pitch + checklist
+block per row (see below).
+
+If that is genuinely too long for one message, do NOT silently truncate: state
+the delivered count plainly ("here are 20 of the 50 \u2014 say the word for the
+rest"), so the user knows what they have. Never present a partial list as
+though it were the plan. Four columns:
+
+Col 3's header is **the ranking key you actually used** \u2014 never a cash label,
+since cash-to-capture cannot be computed from Leadbay data:
+
+\`\`\`
+| # \xB7 Account | Motif | Fit score | Why now |
+\`\`\`
+
+- **Col 1** \u2014 rank number, then the company name linked to its website when one
+  is known. Follow with a compact \` \xB7 \`-separated pill line: city \xB7 headcount \xB7
+  any account reference you were given. **Every figure in that pill line carries
+  its class too** \u2014 headcount is \`[LB]\` (a Leadbay size band, so render the band
+  rather than a false-precision point value) or \`[SIRENE]\` if you read it from
+  the registry. An untagged employee count is still an untagged number in front
+  of a client; omit it rather than ship it bare.
+- **Col 2** \u2014 the motif, exactly one of SAUVETAGE / PLAN DE COMPTE / MONT\xC9E EN
+  GAMME / R\xC9VEIL / CONQU\xCATE / SUIVI. Never invent a seventh.
+- **Col 3** \u2014 the ranking signal with its provenance class, e.g. \`AI 30 [LB]\`.
+  Tagging is not optional; an untagged figure reads as measured fact. **There is
+  no money column** \u2014 cash-to-capture needs invoicing data Leadbay does not
+  hold, so it stays OMITTED in the ledger rather than being modelled. A column
+  of invented euros next to a client's name is the exact failure this
+  deliverable must not ship.
+- **Col 4** \u2014 the one-line reason to act now: the signal when there is one,
+  otherwise the motif's deciding evidence. Never fill this with a
+  plausible-sounding invented event; an account with nothing read shows \`\u2014\`.
+
+Sort strictly by the ranking key named in the ledger (which was printed above).
+
+### The pitch + checklist block (part of the chat answer, not the deck)
+
+The table alone is a shortlist, not a plan \u2014 the pitch and the three-step
+checklist are what make it actionable, and the deck is **optional**, so they
+cannot live only there. Under the table, render a block for **every account you
+put in the table** \u2014 if a row is good enough to rank, it is good enough to carry
+its pitch. Do NOT ship the top 5 or 10 and offer the rest "on request": that
+puts the actionable half of the deliverable behind another user turn, and the
+rows you defer are the ones a rep is least likely to chase. If the full plan is
+genuinely long, shrink the TABLE (fewer rows, stated plainly) rather than
+shipping ranked rows with no pitch:
+
+\`\`\`
+**<rank> \xB7 <Company>** \u2014 <MOTIF>
+\u260E <contact name>, <title> \xB7 <only the channels actually revealed>
+> "<the motif's pitch, in the client's commercial voice>"
+\u2610 <step 1>  \u2610 <step 2>  \u2610 <step 3>
+\`\`\`
+
+Keep each pitch to one or two sentences a rep can say out loud, and each
+checklist to three concrete, checkable actions matching that motif's shape.
+When an account has a signal, lead the pitch with it and promote
+"exploit &lt;the signal&gt;" to the top of its checklist.
+
+### The interactive deck (only after the user accepts)
+
+One card per account, ordered by the same key. Per card:
+
+- **Header** \u2014 rank badge, company name, city \xB7 trade \xB7 headcount, and the
+  ranking signal right-aligned with its class tag (e.g. \`AI 30 [LB]\`). No cash
+  figure: the deck and the chat answer must never disagree about which fields
+  exist, and a card carrying a euro the table omitted means one was modelled.
+- **Motif badge** \u2014 the motif, visually distinct per motif so the deck can be
+  scanned by strategy.
+- **Qualification row** \u2014 the org's **actual** questions as returned by
+  \`leadbay_get_qualification_questions\` (there may be fewer than five), each with
+  \u2713 / \u2717 / pending and labelled with its real text. Render exactly as many rows as
+  the org has: never pad to five with invented labels or bogus pending pills, and
+  never substitute invented wording.
+- **Signal line** \u2014 the event driving urgency, or omitted.
+- **Action block** \u2014 the named contact with **only the channels enrichment
+  actually returned** as one-tap \`tel:\` / \`mailto:\` links (the default reveal is
+  email-only unless phone was requested \u2014 never emit a \`tel:\` for a phone that
+  was never revealed; mark it omitted instead), the motif's pitch as a quoted
+  line, and the three-item checklist as checkboxes.
+- **Caveat block** \u2014 closing the deck: which classes fed it, an explicit line
+  that \`[HYP]\` figures are modelled rather than measured, and which fields are
+  OMITTED because Leadbay does not hold them. A missing input means an omitted
+  field, never a stand-in number.
+
+Header KPIs across the top, each carrying its provenance class: accounts on the
+plan, count qualified, count with a reachable contact. **No euro totals** \u2014 the
+same rule as the table, for the same reason.
+
+\u26A0 **No "activated" KPI at build time.** Nothing in this workflow measures
+activation \u2014 the deck is built before any outreach happens \u2014 so a count would be
+fabricated or imply outcome tracking that doesn't exist. If the deck's checklists
+persist locally, an "activated" tile may count *checked* accounts and must be
+labelled as local checklist state, not a measured outcome.
+
+
+Then **offer** the interactive deck \u2014 don't force it:
+
+## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
+
+Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can route into. These ALWAYS produce a better UX than markdown tables / inline prose for the data shapes they support \u2014 they're tappable on mobile, persistent across turns, and integrate with the host's quick-actions.
+
+**The Big Three** \u2014 when a tool result fits, route there:
+
+| Host widget | Use when | Field map (from Leadbay payload) |
+|---|---|---|
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
+| \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
+| \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
+
+ChatGPT exposes the same routing pattern via \`_meta.openai/outputTemplate\`. We don't ship any custom widgets ourselves \u2014 this gate is exclusively about routing into the host's first-party widgets when the data shape fits.
+
+**Rules:**
+- The widget IS the visual. Do NOT emit a markdown table or prose list of the same data alongside \u2014 that produces two competing UIs.
+- Pass identifiers (place_id, lead.id, contact_id) verbatim. Don't rewrite.
+- When the host doesn't expose the named widget, the agent falls back to the prose/table rendering the per-tool description already specifies. The directive is host-conditional; the fallback is automatic.
+- One short intro sentence in chat is enough \u2014 "Here are your 5 NYC follow-ups." Then route into the widget.
+
+
+\u26A0 **The deck's contact layer depends on what actually happened in Phase 5.** Bind a \`leadbay_bulk_enrich_status\` resource ONLY if a paid reveal was launched and you hold a \`bulk_id\`. If the user accepted the deck but not the reveal, render the contacts already on record and carry the paid-reveal offer inside the deck \u2014 never wire a status resource with no handle (it renders permanently empty) and never launch enrichment from the deck to manufacture one.
+
+On acceptance, call \`leadbay_artifact_kit\`, read its \`usage_guide\` before writing any code, and build a single-file deck. Wire the live layer from the handles you kept: a poll-until-done resource per \`qualify_id\` for the qualification pills, and one over \`leadbay_bulk_enrich_status\` for the contacts. \u26A0 **If enrichment already ran this session, bind the existing \`bulk_id\` \u2014 re-launching enrichment from the deck double-spends my quota.** Per-card notes and outcomes go through the pre-wired note/outreach view-models (they carry the required verification and \`_triggered_by\` fields; hand-rolling those is where it breaks). Keep the checklists in local storage, and always wire a Refresh \u2014 auto-poll is host-dependent. List every tool the deck calls in its \`mcp_tools\`, and render the bridge-unavailable branch, or the pills silently show empty.
+
+# Iron laws
+
+- **Never invent a number.** No revenue figure, registry count, signal or lead id that didn't come from a Leadbay response or a real registry query. A modelled figure is fine \u2014 tagged \`[HYP]\` and named as an assumption. An untagged one is not.
+- **The ledger ships before the deliverable**, with un-sourceable fields shown as OMITTED rather than dropped.
+- **A conquest plan is the deliverable, not a consolation prize.** Leadbay holds no invoicing data, so the money columns are OMITTED by design. Title it honestly, name what a cash-ranked version would need \u2014 never refuse, and never fill the gap with a guess.
+- **Deliver first, ask alongside.** Do not end a turn without a ranked list of real accounts. The benchmark, the Tier-1 threshold, the territory, a missing lens, a short question set and an unanswered enrichment offer are all NON-blocking \u2014 carry them next to the plan. Only an unresolvable identity mismatch (whose plan is this?) may stop delivery.
+- **One motif per account, from the closed set of six**, with its deciding evidence stated.
+- **The org's real qualification questions**, read from Leadbay \u2014 never invented.
+- **Consent before any paid enrichment**, and never re-launch a bulk that already exists.
+- **Offer the deck; don't force it.** The chat answer must stand alone as useful.
+- Carry the captured \`lensId\` on the calls whose schema **accepts** it (\`leadbay_pull_leads\`, \`leadbay_bulk_qualify_leads\`, \`leadbay_enrich_titles\`). Do NOT add it to \`leadbay_pull_followups\`, \`leadbay_scan_portfolio_signals\`, \`leadbay_qualify_status\` or \`leadbay_bulk_enrich_status\` \u2014 they declare no such argument and reject unknown properties.
+- Building a plan is not outreaching \u2014 do not send anything and do not call \`leadbay_report_outreach\`.
+`;
 var leadbay_work_campaign = `
 Work my **{{arg:campaign_or_default}}** campaign as an outreach session{{arg:mode_paren}}.
 
@@ -25364,6 +25815,7 @@ should I follow up on" to "I'll send via lemlist".
   leadbay_refine_audience: { "name": "leadbay_refine_audience", "short_description": "Refine the kind of leads Leadbay surfaces beyond firmographics, with a\nfree-text instruction. Handles the clarification round-trip if the new\nprompt is ambiguous.\n", "arguments": [{ "name": "instruction", "description": "The refinement (e.g. 'focus on hospitals running their own IT'). Set to plain English.", "required": true }], "expected_calls": ["leadbay_refine_prompt", "leadbay_account_status"], "failure_modes": ["Calls leadbay_answer_clarification on the user's behalf instead of surfacing the clarification verbatim", "Glosses over the clarification options instead of presenting them as offered", "Promises immediate effect when status='applied' actually triggers an async intelligence recompute"] },
   leadbay_research_a_domain: { "name": "leadbay_research_a_domain", "short_description": "Resolve a company by name or domain across the user's visible Discover,\nMonitor, and Activate corpus, then return everything Leadbay knows about it.\n", "arguments": [{ "name": "domain", "description": "Company name or domain (for example 'Acme Corporation' or 'acme.com'). The legacy argument key remains `domain` for client compatibility.", "required": true }], "expected_calls": ["leadbay_research_lead_by_name_fuzzy"], "failure_modes": ["Fabricates qualification answers not present in any tool response", "Calls leadbay_import_and_qualify before searching the existing visible corpus", "Treats the active lens as the entire search universe when the user did not request a lens scope", "Imports a missing company without the user's explicit permission", "Renders the research result as a freeform narrative instead of the canonical research-company-card layout (the card with header score bar, pill row, signal sections, contacts table is the structural contract; commentary belongs ABOVE or BELOW it)"] },
   leadbay_setup_team_prospecting: { "name": "leadbay_setup_team_prospecting", "short_description": "Manager-led prospecting setup: conversationally turn a natural-language\naudience ask into a Leadbay lens, validate the candidate leads, and\npersist them as one or more named campaigns the rep(s) can work\nthrough. Closes #3630 US3 end-to-end (within the current\ncreator-scoped campaign visibility model).\n", "arguments": [{ "name": "audience", "description": "Natural-language audience description (e.g. 'plumbing companies with 10-50 employees in Seine-Maritime'). The lens-creation step (`leadbay_refine_prompt` \u2192 `leadbay_create_lens`) interprets it.", "required": true }, { "name": "rep_split", "description": "Optional: how to split the validated leads into per-rep campaigns. Free text \u2014 e.g. 'split by city' or 'one campaign per rep: John gets Tulsa, Sarah gets OKC'.", "required": false }], "expected_calls": ["leadbay_refine_prompt", "leadbay_create_lens", "leadbay_promote_lens", "leadbay_pull_leads", "leadbay_research_lead_by_id", "leadbay_create_campaign", "leadbay_add_leads_to_campaign"], "failure_modes": ["Skips the validation step \u2014 creates a campaign of unvetted leads from a freshly-created lens without giving the manager a chance to drop weak fits", "Creates ONE campaign for all reps without asking about the split \u2014 the user explicitly mentioned per-rep distribution and the prompt should honor it", "Pretends the backend supports cross-user assignment \u2014 campaigns are owned by the caller (creator-scoped). Surface this honestly instead of fabricating an assignment model", "Asks ALL clarifying questions inline before tool calls \u2014 instead, run the lens refinement loop with `leadbay_refine_prompt` which handles the clarification protocol natively"] },
+  leadbay_top_accounts_to_activate: { "name": "leadbay_top_accounts_to_activate", "short_description": 'Build a ranked account-conquest plan from Leadbay data \u2014 the accounts worth\nactivating, each with a motif, a pitch and a checklist, ranked by the\nstrongest Leadbay signal. Every figure carries its source, and anything\nLeadbay can\'t measure is shown as OMITTED rather than estimated. Uses\n`leadbay_bulk_qualify_leads` and `leadbay_enrich_titles`. Trigger on\n"top 50 accounts to activate", "who should we go after".\n', "arguments": [{ "name": "count", "description": "Optional: how many accounts the plan should hold (default 50).", "required": false }, { "name": "territory", "description": "Optional: restrict the plan to a territory (e.g. 'Indre-et-Loire', 'R\xE9gion Ouest'). Sets geography on the Discover lens.", "required": false }], "expected_calls": ["leadbay_account_status", "leadbay_get_qualification_questions", "leadbay_pull_leads", "leadbay_pull_followups", "leadbay_bulk_qualify_leads", "leadbay_qualify_status", "leadbay_scan_portfolio_signals", "leadbay_enrich_titles", "leadbay_bulk_enrich_status", "leadbay_account_history", "leadbay_artifact_kit", "leadbay_new_lens", "leadbay_adjust_audience"], "failure_modes": ["Invents, estimates or proxies a revenue-realized figure \u2014 the single worst failure. Leadbay does not hold what an account buys, and headcount, sector and lead score are NOT proxies for it.", "Sorts by cash-to-capture, synthesizing a revenue figure per account purely to make that ranking work. Leadbay has no revenue data: rank by the Leadbay signal, say so in the header, and never invent the key.", "Emits \u20AC figures with no provenance class, so modelled numbers read as measured fact in front of a paying client.", "Skips the PROVENANCE LEDGER, or drops un-sourceable fields from it instead of rendering them as OMITTED \u2014 which hides the gap.", "Fabricates registry/TAM counts (France or regional company counts) instead of querying the registry or marking the figure NOT COMPUTED. Leadbay does not proxy SIRENE.", "Invents the five qualification questions from this prompt's own recommendations instead of reading the org's actual questions via leadbay_get_qualification_questions.", "Leaves the deck's live layer dead \u2014 qualification and enrichment handles never wired in, so the pills and contacts stay empty while the deck still looks finished.", "Invents lead ids to make the qualification pills appear populated.", "Fabricates a plausible-sounding signal ('just won a public tender') for an account whose signals were never read. No signal read means an explicit dash.", "Assigns a motif outside the closed set of six, or assigns SAUVETAGE / PLAN DE COMPTE / MONT\xC9E EN GAMME / R\xC9VEIL from a lead score or sector when order history was never available.", "Labels Monitor membership as 'is a client' \u2014 Monitor is a Leadbay view whose membership is decided by lens scoring, not by whether the company ever bought anything.", "Launches paid enrichment on the whole plan without consent. Asking for a plan is not authorization to spend on 50 accounts.", "Re-launches enrichment from inside the built deck when a bulk handle already exists this session \u2014 double-spends the user's quota.", "Forces the interactive deck without offering it first, or ships the deck INSTEAD of a chat answer that stands on its own.", "Refuses the task because revenue data is missing, instead of delivering the conquest plan and naming what a cash-ranked version would need.", "Ends the turn without a ranked list of real accounts \u2014 gating the whole plan on a NON-blocking question (the territory, a missing lens, or a 3-vs-5 qualification-question gap) so the user gets a plan-of-a-plan. Only an unresolvable company-identity mismatch may stop delivery; every other open question rides alongside the delivered plan.", "Stops after the discovery contact preview to wait for enrichment consent, delivering no plan that turn \u2014 the ranked plan ships first; the paid reveal is offered alongside it.", "Renders a contact channel enrichment never returned (e.g. a phone link when only email was approved and revealed) instead of showing the returned channels and marking the rest omitted."] },
   leadbay_work_campaign: { "name": "leadbay_work_campaign", "short_description": "Work a campaign as a real outreach session: pick the campaign,\nassess what the user has (phones / emails / coords), then PROPOSE\nthe right session mode (call sheet, email sheet, enrich titles\nfirst, map). After they pick, render \u2014 and as they dictate\noutcomes per lead, record both note + epilogue via\n`leadbay_report_outreach` in one round trip.\n", "arguments": [{ "name": "campaign", "description": "Campaign name (fuzzy match against your own campaigns) or campaign UUID. Omit to list and pick interactively.", "required": false }, { "name": "mode", "description": "Optional: skip the readiness-assessment proposal and jump directly into 'call_sheet' / 'email_sheet' / 'map' / 'enrich_first'. Omit (recommended) and let the prompt propose based on the data.", "required": false }], "expected_calls": ["leadbay_list_campaigns", "leadbay_campaign_call_sheet", "leadbay_enrich_titles", "leadbay_report_outreach"], "failure_modes": ["Renders the call sheet immediately without proposing the right mode \u2014 if 60% of leads have no contacts, calling is futile; enrich first. Always assess `readiness` first.", "Auto-renders the map widget without asking \u2014 maps are intrusive when the user just wants to scroll a list. Map mode is a proposed option, not a default.", "Proposes map mode after the user has previously said they don't like maps \u2014 check conversation memory before adding 'View on a map' to the options list.", "Calls `leadbay_campaign_progression` instead of `leadbay_campaign_call_sheet` \u2014 progression has counts but no phones / LinkedIn / call-ready data; the user can't actually dial from progression rows.", "Renders contacts WITHOUT making the phone number a `[bare](tel:URL)` link \u2014 on mobile that breaks one-tap calling, which is the whole point of the cheat sheet.", "Records outreach WITHOUT epilogue_status \u2014 leaves the lead's pipeline state unchanged; the rep then sees the same lead surfaced again next session.", "Records outreach WITHOUT verification \u2014 verification.source/ref is REQUIRED. For calls, pass `{source: 'user_confirmed', ref: <user's exact words>}`.", "Loops through ALL leads in a 50-lead campaign before recording any outreach \u2014 the call-then-record loop must be per-lead, not batched."] }
 };
 var PROMPT_CATALOG_HEADER = `This server exposes the following workflow prompts via \`prompts/list\` and \`prompts/get\`. Some MCP clients render them as slash commands; if your client does not, you (the agent) should invoke them directly via \`prompts/get\` when the user's request matches one of the triggers described below.`;
@@ -25380,6 +25832,7 @@ var PROMPT_CATALOG_BULLETS = {
   leadbay_refine_audience: `- \`leadbay_refine_audience\` (required args: instruction): Refine the kind of leads Leadbay surfaces beyond firmographics, with a free-text instruction. Handles the clarification round-trip if the new prompt is ambiguous.`,
   leadbay_research_a_domain: `- \`leadbay_research_a_domain\` (required args: domain): Resolve a company by name or domain across the user's visible Discover, Monitor, and Activate corpus, then return everything Leadbay knows about it.`,
   leadbay_setup_team_prospecting: `- \`leadbay_setup_team_prospecting\` (required args: audience; optional args: rep_split): Manager-led prospecting setup: conversationally turn a natural-language audience ask into a Leadbay lens, validate the candidate leads, and persist them as one or more named campaigns the rep(s) can work through. Closes #3630 US3 end-to-end (within the current creator-scoped campaign visibility model).`,
+  leadbay_top_accounts_to_activate: `- \`leadbay_top_accounts_to_activate\` (optional args: count, territory): Build a ranked account-conquest plan from Leadbay data \u2014 the accounts worth activating, each with a motif, a pitch and a checklist, ranked by the strongest Leadbay signal. Every figure carries its source, and anything Leadbay can't measure is shown as OMITTED rather than estimated. Uses \`leadbay_bulk_qualify_leads\` and \`leadbay_enrich_titles\`. Trigger on "top 50 accounts to activate", "who should we go after".`,
   leadbay_work_campaign: `- \`leadbay_work_campaign\` (optional args: campaign, mode): Work a campaign as a real outreach session: pick the campaign, assess what the user has (phones / emails / coords), then PROPOSE the right session mode (call sheet, email sheet, enrich titles first, map). After they pick, render \u2014 and as they dictate outcomes per lead, record both note + epilogue via \`leadbay_report_outreach\` in one round trip.`
 };
 
@@ -25624,6 +26077,33 @@ var CATALOG = [
         )
       ];
     }
+  },
+  {
+    name: "leadbay_top_accounts_to_activate",
+    description: PROMPT_META.leadbay_top_accounts_to_activate.short_description,
+    arguments: [
+      {
+        name: "count",
+        description: "Optional: how many accounts the plan should hold (default 50).",
+        required: false
+      },
+      {
+        name: "territory",
+        description: "Optional: restrict the plan to a territory (e.g. 'Indre-et-Loire'). Sets geography on the Discover lens via `locations`.",
+        required: false
+      }
+    ],
+    render: (args) => {
+      const n = args.count ?? "50";
+      return [
+        userMessage(
+          substitutePlaceholders(leadbay_top_accounts_to_activate, {
+            count_or_default: n,
+            territory_block: args.territory ? `Scope the plan to **${args.territory}** \u2014 pass it as \`locations\` on the lens, never as a sector.` : ""
+          })
+        )
+      ];
+    }
   }
 ];
 function listPrompts() {
@@ -28746,7 +29226,7 @@ var OAUTH_BASE_URLS = {
     fr: "https://staging.api.leadbay.app"
   }
 };
-var VERSION = "0.27.0";
+var VERSION = "0.28.0";
 var HELP = `
 leadbay-mcp ${VERSION} \u2014 Leadbay Model Context Protocol server
 

package/dist/http-server.js

@@ -1185,6 +1185,457 @@ End with a NEXT STEPS chip via your host's choice widget (\`ask_user_input_v0\`
 
 Done. The lens is live, the validated cohort is persisted as named campaigns, and the manager knows where the cross-user-visibility gap is.
 `;
+var leadbay_top_accounts_to_activate = `
+## MEMORY
+
+Before responding, glance at any \`_meta.agent_memory.summary\` returned by tool calls earlier in this session and reflect its top signals in your reasoning ("Filtering by your stated preference for healthcare"). After any material new signal from the user this conversation (sector, region, deal size, communication style, qualification rule, explicit retraction, or recurrence / scheduling preference such as "I do this every day" or "remind me every morning"), call \`leadbay_agent_memory_capture\` to persist it: \`source:"user_stated"\` if literal, \`source:"inferred"\` with confidence <=6 if inferred.
+
+
+Build me a **top-{{arg:count_or_default}} account-conquest plan** \u2014 the accounts worth activating, ranked, each one carrying a strategic motif, a phone pitch and a three-step checklist. {{arg:territory_block}}
+
+This deliverable goes in front of a paying client, so **the honesty of the numbers matters more than their completeness**. Deliver the strongest plan the available data actually supports, and be explicit about what it doesn't.
+
+**DATA PROVENANCE \u2014 every number carries its source.** This deliverable mixes
+four data sources with very different trust levels, and it is shown to a
+paying client. A figure whose origin is unstated reads as measured fact. Tag
+every number you emit with exactly one class:
+
+| Tag | Meaning | Where it comes from |
+|---|---|---|
+| \`[ERP]\` | measured in the client's own invoicing / management extract | the file the user attached, or a \`leadbay_get_lead_custom_fields\` read of a value imported from it |
+| \`[LB]\` | returned by a \`leadbay_*\` tool THIS session | \`leadbay_pull_leads\`, \`leadbay_pull_followups\`, \`leadbay_bulk_qualify_leads\`, \`leadbay_enrich_titles\`, \`leadbay_scan_portfolio_signals\`, \`leadbay_account_history\`, \`leadbay_research_lead_by_id\` |
+| \`[SIRENE]\` | the French public company registry | \`recherche-entreprises.api.gouv.fr\` \u2014 **your own web tool, NOT Leadbay.** Leadbay does not proxy the registry |
+| \`[HYP]\` | a modelled assumption | the \u20AC/employee benchmark, the 35 % objective, the trade purchase mix, any Tier-1 threshold the client hasn't confirmed |
+
+**Taint propagates.** A derived figure inherits the weakest class of its
+inputs. \`cash = pot12 \u2212 ca12\` where \`pot12\` is \`[HYP]\` makes **\`cash\` itself
+\`[HYP]\`** \u2014 say so in the artefact's own caveat block, not only in chat. A
+client who mistakes a modelled \`cash\` figure for an audited one will build a
+sales plan on it.
+
+**Print the PROVENANCE LEDGER before you build anything**, BEFORE writing
+artifact code or the final table. The block below is a **shape, not a literal**:
+keep the header, the \`field / class / source\` columns and the closing rule, but
+**replace every \`<...>\` placeholder with the real field name, class and source**
+\u2014 one row per field you actually emit. A ledger still showing \`<field name>\` has
+passed the ordering check while telling the reader nothing, which defeats its
+entire purpose.
+
+\`\`\`
+PROVENANCE LEDGER
+=================
+field           class     source
+<field name>    ERP       <file>:col "<column header>"
+<field name>    LB        <tool that returned it>
+<field name>    SIRENE    recherche-entreprises.api.gouv.fr
+<field name>    HYP       <the formula + which input is assumed>
+<field name>    OMITTED   <why it cannot be computed>
+=================
+\`\`\`
+
+An \`OMITTED\` row is the point of the ledger: it makes a gap **visible** instead
+of silently filled with a plausible guess. Never drop a field from the ledger
+just because you couldn't source it \u2014 render it as \`OMITTED\` with the reason.
+
+**When a number is unavailable, do NOT model it \u2014 switch modes.** Specifically:
+if the client's revenue-realized figure is absent, do not estimate it, do not
+proxy it from headcount / sector / score, and **do not sort by any quantity
+derived from it.** Say plainly which fields are unavailable, name the exact
+columns you'd need, and deliver the plan the prompt describes \u2014 ordered by the
+strongest \`[LB]\` ranking you actually have.
+
+**Sorting is where fabrication hides.** Asked for a ranking "by cash to go
+get" with no revenue data, the tempting move is to invent a revenue figure per
+account purely so the sort produces a plausible-looking order. That is
+fabrication with a confident shape, and it is the single most likely failure of
+this workflow. Change the sort and say so; never invent the key.
+
+**Client-specific parameters are to be CONFIRMED, not assumed as product
+constants.** The Tier-1 threshold, the \u20AC/employee benchmark and the purchase
+mix all come from one client's economics. State each as \`[HYP]\` with its value
+visible and offer to re-run when the client supplies the real figure.
+
+
+GATE \u2014 DEFER TO TOOL RENDERING. When you call a Leadbay composite that ships its own RENDERING block (every composite in 0.9.0+ does), render the response using that block's recipe verbatim \u2014 score bars, glyph palette, column order, hide-list, link priorities, all of it. Do NOT substitute prose, a numbered list, or a different column structure even when an orchestrating prompt's body suggests alternate framing. Prompt-specific commentary (motivational nudges, summaries, next-action recommendations) belongs ABOVE or BELOW the canonical table, never in place of it.
+
+If the prompt's body and the tool's RENDERING appear to conflict, the tool's RENDERING wins for the structural layout; the prompt's voice wins for the commentary that surrounds it.
+
+
+# Resilience rules for Leadbay long-running tools
+
+These four rules apply to every Leadbay workflow that calls \`leadbay_pull_leads\`, \`leadbay_bulk_qualify_leads\`, \`leadbay_research_lead_by_id\`, \`leadbay_import_and_qualify\`, or \`leadbay_enrich_titles\`. **Treat timeouts and stream-closed errors as transient, not as signals to replan.**
+
+## Rule 1 \u2014 Pin the lens
+
+After your first \`leadbay_pull_leads\` call, capture \`response.lens.id\` into your working memory and **pass it explicitly as the \`lensId\` argument to every subsequent call** in this session \u2014 including any re-pulls, bulk qualifies, or research calls that accept it. (Field-name caveat: the response nests it as \`lens.id\`; the parameter on subsequent calls is \`lensId\`.) The active lens can shift between calls (5-minute client cache + backend \`last_requested_lens\` can change if the user touches the web UI). A lens shift mid-workflow throws away your top-10 work.
+
+## Rule 2 \u2014 Prefer async for bulk operations
+
+\`leadbay_bulk_qualify_leads\` and \`leadbay_import_and_qualify\` accept \`wait_for_completion:false\`, which returns \`{status:'running', qualify_id}\` immediately. Then poll \`leadbay_qualify_status\` (or \`leadbay_import_status\`) every ~10s until the job completes. **Use the async pattern by default** \u2014 the blocking default can exceed the MCP client's per-call timeout on large batches and produce a misleading \`"Request timed out"\` even though the server is still working.
+
+## Rule 3 \u2014 Serialize \`leadbay_research_lead_by_id\` fan-out
+
+\`leadbay_research_lead_by_id\` is composite and reads many sub-resources. Calling it on 10 leads in parallel can saturate the transport and produce \`"Tool permission stream closed"\` errors that look like permission failures but are really backpressure. **Call it sequentially**, or at most 3 in parallel. If one call fails with a stream/timeout error, retry that one call once before moving on; on a second failure, note the lead and continue \u2014 do not abandon the remaining leads.
+
+## Rule 4 \u2014 Retry, don't replan
+
+If a Leadbay tool returns \`"Request timed out"\`, \`"stream closed"\`, or any other transport-level error (distinct from a Leadbay-issued error payload), the work may still be running server-side. Do this in order:
+
+1. For bulk tools \u2014 retry with \`wait_for_completion:false\` and poll the status tool with the returned id. Don't re-pull leads; that can shift the lens.
+2. For single-lead tools \u2014 retry the same call once. If it still fails, record the lead id and continue with the rest of the workflow.
+3. **Do not** switch strategies (e.g. "the endpoint is broken, let me re-pull from scratch"). The earlier work is still valid; the timeout was the wire.
+
+If \`pull_leads\` itself fails and you have no prior batch, then yes \u2014 retry it, explicitly pass the lensId you captured (if any), and continue.
+
+
+# PHASE 0 \u2014 SCOPE + STATE
+
+Call \`leadbay_account_status\` for my quota and active lens.
+
+**What this plan is, and what it deliberately isn't.** Leadbay knows who a company is, how it scores, what signals it has and who to call there. It does **not** know what any account buys from me \u2014 invoicing lives in my ERP, and no Leadbay tool exposes it. So this is a **conquest plan**: real accounts, real qualification, real signals, real contacts, ranked by the strongest Leadbay signal available. Revenue-realized, per-family revenue, addressable spend and cash-to-capture are **OMITTED \u2014 never estimated, never proxied from headcount, sector or lead score.**
+
+Say that scope in one line up front, so nobody reads the ranking as a money sort. If I ask for a cash-ranked plan, tell me plainly that it needs my invoicing extract and that the MCP has no path to it today \u2014 then deliver this plan anyway rather than stopping.
+
+**DELIVER FIRST, ASK ALONGSIDE \u2014 never gate the plan on a missing input.** Only ONE thing can stop you before you have shipped a ranked list of real accounts: not knowing **whose** plan this is (a company-identity mismatch you genuinely cannot resolve). Everything else is a question you carry *next to* the delivered plan, not a reason to withhold it:
+
+- **No benchmark?** Costs nothing here \u2014 the money column is OMITTED regardless. Pull, qualify, rank by the Leadbay signal, deliver, and mention what a cash-ranked version would need.
+- **No Tier-1 threshold?** Not a blocker. Deliver, and ask alongside.
+- **No territory?** Not a blocker \u2014 but do NOT call the result "national". You'll be pulling my ACTIVE lens, which may already be scoped to a city, sector or rep patch. Say the plan covers **my active lens's existing scope** (name the lens), not the whole country, and offer to re-scope. Calling a city-scoped lens a national plan misdescribes the deliverable to a client.
+- **\`last_requested_lens: null\`?** Not a blocker \u2014 and **do NOT read it as "no lens exists".** \`leadbay_account_status\` deliberately WITHHOLDS the lens id unless the request mentioned the lens/audience, so a plain "top 50 accounts to activate" returns null even when I have a perfectly good active lens. Default to calling \`leadbay_pull_leads\` with **no** \`lensId\` and let it resolve my active lens; capture \`response.lens.id\` from that result and pin it thereafter. Only create or switch a lens when I explicitly asked to scope or change the audience (e.g. a \`territory\` argument) \u2014 inventing a new lens silently changes what I see in the product.
+- **Only 3 qualification questions instead of 5?** Not a blocker. Use the org's real questions, note the gap, recommend the additions \u2014 do not wait for permission before pulling.
+
+Bundling a non-blocking question in with a blocking one turns a justified pause into an over-wide gate, and the user gets a plan-of-a-plan instead of a plan. The test is **"have I shipped a ranked list of real accounts yet?"** \u2014 if you're about to end a turn without one, you are almost certainly over-gating: deliver first, then ask.
+
+If I gave a \`territory\`, scope discovery to it now, and **make sure the scoping actually took effect before you pull** \u2014 a territory request that silently returns out-of-territory accounts is worse than none.
+
+- **Preferred: \`leadbay_adjust_audience\`** on my active lens, passing the place as \`locations\`. It applies directly, so the lens I already use is now scoped and \`leadbay_pull_leads\` needs no new id.
+
+  \u26A0 **Location criteria MERGE \u2014 they do not replace.** \`adjust_audience\` unions the new \`location_ids\` into any existing include-location criterion (and \`pull_followups\` merges its \`city\` shortcut the same way). So asking for "R\xE9gion Ouest" on a lens already scoped to Paris yields **Paris OR R\xE9gion Ouest** while your header claims R\xE9gion Ouest. Before adding a territory, check the current filter: if it already carries locations you were not asked to keep, clear or replace them (or build a fresh territory-only lens for this one-off plan) rather than stacking a union.
+- **If a new lens is genuinely warranted: \`leadbay_new_lens\` is a two-step call.** It returns \`status:"preview"\` and creates NOTHING unless you re-call the same args with \`confirm:true\`. So: preview \u2192 confirm \u2192 take \`lens.id\` from the \`created\` response \u2192 pass that id as \`lensId\` on every subsequent pull. Never continue on the previous active lens after previewing a new one; that delivers the old audience under a new heading.
+
+A place name goes to \`locations\`, never to \`sectors\` or a refine prompt.
+
+# PHASE 1 \u2014 THE FIVE QUALIFICATION QUESTIONS
+
+Call \`leadbay_get_qualification_questions\` and use the org's **actual** questions \u2014 they become the qualification row on every card. Do NOT invent them.
+
+If the org has none set, or they don't discriminate for this exercise, recommend this shape and offer to set it via \`leadbay_set_qualification_questions\` (max 5, and ask before replacing anything): **Q1** exercises a core-target trade \xB7 **Q2** big enough to matter \xB7 **Q3** operates in the covered territory \xB7 **Q4** recent activity signals \xB7 **Q5** likely need in the next quarter. Q4 and Q5 are the load-bearing pair \u2014 they separate "fits the profile" from "worth calling this week". Recommend; don't overwrite without my say-so.
+
+# PHASE 2 \u2014 THE ACCOUNT UNIVERSE
+
+\u26A0 **Monitor membership is not client status.** Monitor tells you what Leadbay is watching \u2014 lens scoring decides who lands there, not whether the company ever bought anything. Label that pane "Leadbay view membership", never "customer".
+
+**Get the accounts.** \`leadbay_pull_followups\` for the known/identified side, \`leadbay_pull_leads\` for the not-yet-identified side.
+
+\u26A0 **Monitor's scope must match the scope you put in the header \u2014 never leave it accidental.** \`leadbay_pull_followups\` defaults to applying whatever Monitor filter is persisted server-side from a previous session, and that filter has nothing to do with the lens Discover is using. Two stale-state traps, one rule:
+
+- **A persisted filter you didn't ask for** silently shrinks the known side, so a rep who once filtered Monitor to a city gets a "whole base" plan missing most of it.
+- **Blindly passing \`filtered:false\`** does the opposite: Monitor goes org-wide while Discover stays on a scoped lens, so out-of-scope known accounts land in a plan headed with the lens's name.
+
+\u26A0 **You cannot mirror a geography you haven't read.** \`leadbay_pull_leads\` returns only \`lens: {id}\` \u2014 not the lens's filter \u2014 so capturing the id tells you nothing about which locations it covers. Before scoping Monitor to match a lens, read the **\`lens://<id>/definition\` resource** \u2014 that is where the filter and its \`location_ids\` actually live. \`leadbay_my_lenses\` returns only id / name / description / active flags, so it cannot tell you a lens's geography and must not be used for this. If you cannot determine the lens's geography, do NOT guess: pull Monitor org-wide with \`filtered:false\` and say in the header that the known side is org-wide while Discover follows lens \`<id>\`, whose scope you could not read. An unstated mismatch is the failure; a stated one is honest.
+
+So: **read the persisted filter first** (the response reports \`active_filters\`), then make it match the plan's declared scope. If the plan is scoped (a \`territory\`, or an active lens with its own geography), apply that same geography to Monitor. If the plan is genuinely org-wide, pass \`filtered:false\`. Either way, state the known side's scope in the header in the same breath as the Discover side \u2014 a plan whose two halves are scoped differently is misleading even when both halves are individually correct.
+
+\u26A0 **A territory must scope BOTH sides.** Adjusting or creating a lens only scopes Discover; Monitor is filtered through its own path, so pass the territory to \`leadbay_pull_followups\` as well (its \`city\` free-text shortcut resolves to a \`location_ids\` filter, same resolver as the lens). Otherwise a territory-scoped plan quietly mixes in out-of-territory known accounts \u2014 and a client reading "R\xE9gion Ouest" at the top will not check every row. Unless I named a \`territory\`, call \`leadbay_pull_leads\` with **no \`lensId\`** so it resolves my active lens \u2014 do not create a lens just because \`account_status\` showed a null. Capture \`response.lens.id\` from the first pull and pass it as an explicit \`lensId\` on every later call \u2014 a mid-session lens shift discards the cohort. Keep pulling until you have a pool comfortably deeper than {{arg:count_or_default}}, topping up with \`leadbay_bulk_qualify_leads\` \u2192 \`leadbay_qualify_status\` \u2192 re-pull as needed.
+
+# PHASE 3 \u2014 QUALIFY, SIGNAL, MOTIF
+
+**Qualify \u2014 the SELECTED cohort, in chunks of 25.** \`leadbay_bulk_qualify_leads\` caps \`count\` at **25**, so a single call cannot cover a 50-account plan. Loop until the whole cohort is qualified, polling \`leadbay_qualify_status\` between chunks.
+
+\u26A0 **Never qualify Monitor rows through a Discover \`lensId\`.** \`leadbay_qualify_status\` re-checks each lead against the lens it was launched on and returns them under **\`not_in_lens\`** \u2014 the backend does not qualify them, so those rows ship with permanently empty pills while the poll reads "still running". So split the cohort: qualify the Discover rows with the pinned \`lensId\`, and for known-side rows use the qualification data \`leadbay_pull_followups\` already returned rather than re-launching them off-lens. If a Monitor row has no qualification data, say so in its cell \u2014 do not leave a pill that will never fill. **Always read \`not_in_lens\` in the poll response** and report anything listed there rather than waiting on it.
+
+\u26A0 **Pass explicit \`leadIds\` whenever the cohort isn't simply "the next N on the lens"** \u2014 e.g. after you've selected a shortlist, or when the plan mixes Monitor and Discover rows. The \`count\`-based path selects the next *unqualified leads from the lens wishlist*, so on any other cohort it qualifies unrelated leads and hands you handles whose pills belong to different companies. Use \`leadbay_bulk_qualify_leads({leadIds:[\u2026\u226425 of the cohort], wait_for_completion:false})\` and chunk through the cohort's own ids. The \`{lensId, count}\` form is only right when the cohort genuinely *is* the lens's top N.
+
+**Qualify the plan cohort, not the whole base.** Select your ~{{arg:count_or_default}} candidates (plus a modest buffer for drop-outs) BEFORE qualifying \u2014 qualification is async and quota-bearing, so running it across an entire portfolio to produce a top-{{arg:count_or_default}} burns the user's quota for rows that will never appear. **Keep every returned \`qualify_id\`** \u2014 the deck's live qualification layer is wired from those handles, and a deck with none is a dead deck that still looks finished. Never ship a plan whose lower ranks have empty qualification pills because only the first 25 were ever qualified.
+
+**Signals \u2014 scoped to the cohort.** \u26A0 **Always pass the selected \`leadIds\`.** With \`leadIds\` omitted, \`leadbay_scan_portfolio_signals\` builds its own portfolio by paging \`/monitor\` \u2014 so on an imported cohort or a freshly-pulled Discover set it would scan a *different population* and you'd render dashes for accounts whose signals were never read.
+
+\`leadbay_scan_portfolio_signals\` is also a **filtered** read: it requires a concrete \`query\` and returns only the accounts whose cached signals match it. It is not a generic "read every signal" call. So run it **once per why-now theme, as SEPARATE calls** \u2014 expansion/new site \xB7 contract or tender won \xB7 funding \xB7 hiring \xB7 acquisition \xB7 new venue \u2014 and union the results.
+
+\u26A0 **One comma-joined omnibus query is NOT six themed scans.** Cramming every keyword into a single string is one match attempt whose recall you cannot inspect: a lead that would have matched "hiring" alone can be missed, and you have no way to tell which themes actually returned anything. Six calls, six result sets, one union. If a theme returns nothing, that is information \u2014 record it rather than hiding it inside a broad string. An account that matched no query has **not** been shown to be signal-free; render it with an explicit \`\u2014\`, never an invented event. For the identified side, take interaction recency from the fields \`leadbay_pull_followups\` already returned. \u26A0 **Do NOT reach for \`leadbay_account_history\` on Monitor rows outside the active lens** \u2014 it calls \`research_lead_by_id\` first, which fetches \`/lenses/{lensId}/leads/{leadId}\` and 404s off-lens, so the very rows that need a SUIVI / R\xC9VEIL-LB decision are the ones it fails on. Use it only for a lead you know is in the pinned lens.
+
+**SIGNAL HONESTY \u2014 never infer signals from freshness.** \`stale_at\`,
+\`web_fetch_in_progress\`, \`fetch_at\` are freshness markers, not signal
+indicators \u2014 signal presence is read ONLY from the actual \`signals[]\` /
+\`web_fetch.content\` entries. For "which of my leads have signal X" across a
+portfolio, call **\`leadbay_scan_portfolio_signals\`** (bulk-reads cached
+signals); don't loop \`leadbay_research_lead_by_id\` per lead or guess from
+freshness. A lead with no cached content is \`not_researched\`, not "no match";
+never report a signal verdict for a lead you never read.
+
+
+**Assign the motif.**
+
+**THE ACTIVATION MOTIFS.** Every account on the plan carries exactly one motif
+from this closed set of six. The motif is not decoration \u2014 it decides the phone
+pitch, the checklist, and whether the account belongs to the *Pilotage* engine
+(already identified) or the *Conqu\xEAte* engine (not yet identified). Assign it
+from observable data and state the deciding evidence in one line per account.
+
+| Motif | Assign when | Engine |
+|---|---|---|
+| **SAUVETAGE** | was buying steadily, has now stopped \u2014 a recent, sharp break (e.g. no order in ~60\u201390 days against a real history) | Pilotage |
+| **PLAN DE COMPTE** | large, still active, buying broadly \u2014 the risk is complacency, not loss; plan the coming half-year and lock volume terms | Pilotage |
+| **MONT\xC9E EN GAMME** | active but narrow \u2014 buys one product family while comparable accounts of the same size buy several; the gap is cross-sell | Pilotage |
+| **R\xC9VEIL** | account exists, essentially dormant \u2014 long-dead history (e.g. 12+ months at zero) but the company is demonstrably still trading | Pilotage |
+| **CONQU\xCATE** | not present in the Leadbay known pipeline \u2014 in the addressable market, absent from the base. \u26A0 Absence from Monitor is NOT proof they never bought (see below) | Conqu\xEAte |
+| **SUIVI** | in the known pipeline with recent activity, purchase behaviour unknown \u2014 the honest label for an active Monitor row when no order history is available | Pilotage |
+
+**Decision order matters.** Test in this order and stop at the first match, or
+a big lapsed account will be labelled R\xC9VEIL when it is really a SAUVETAGE:
+recent sharp break \u2192 SAUVETAGE; long-dormant \u2192 R\xC9VEIL; never bought \u2192
+CONQU\xCATE; buying broadly at scale \u2192 PLAN DE COMPTE; buying narrowly \u2192
+MONT\xC9E EN GAMME.
+
+**Without order history the first five tests cannot run at all.** In that case
+the split is simply: in the Leadbay known pipeline \u2192 **SUIVI**; not in the
+pipeline \u2192 **CONQU\xCATE**. Never reach for a Pilotage motif you cannot evidence,
+and never invent a seventh label \u2014 the set is closed at six.
+
+When a known-pipeline row has long-dormant *Leadbay* activity, it stays
+**SUIVI** and you say what the dormancy measures in its why-now cell: "no
+Leadbay-logged action in N months". That is a qualifier on the evidence, not a
+new motif. It is NOT R\xC9VEIL \u2014 R\xC9VEIL means dormant *purchasing*, which needs
+order history you do not have.
+
+**What each motif changes in the output.**
+
+- The **pitch angle** \u2014 SAUVETAGE opens on the silence itself and offers terms
+  to resume; PLAN DE COMPTE opens on the relationship and plans forward;
+  MONT\xC9E EN GAMME opens on what comparable firms buy that this one doesn't;
+  R\xC9VEIL asks what made them leave and offers a re-entry incentive; CONQU\xCATE
+  introduces the company and asks for a short first meeting \u2014 **without
+  asserting no prior relationship**. Never write "we've never worked together"
+  or "as a new customer" on a Leadbay-only plan: absence from the known
+  pipeline is not proof they never bought, and that line told to an existing
+  customer is the one mistake a rep cannot walk back. Write the pitch in the
+  client's own commercial voice, naming the specific families and figures the
+  account's data actually supports. **SUIVI** picks up the existing thread \u2014
+  a continuation, never an introduction and never a win-back.
+- The **checklist** \u2014 three concrete, checkable next actions matching the
+  motif's shape: diagnose \u2192 schedule \u2192 send-terms for SAUVETAGE; review \u2192
+  propose \u2192 open-a-family for PLAN DE COMPTE; visit-with-full-tariff \u2192 quote \u2192
+  first-order-in-the-new-family for MONT\xC9E EN GAMME; understand-the-departure \u2192
+  send-offer \u2192 first-order-back for R\xC9VEIL; reach-the-decision-maker \u2192
+  open-the-account \u2192 first-test-order for CONQU\xCATE; confirm-the-state \u2192
+  identify-the-current-need \u2192 agree-a-next-step for SUIVI. When a signal exists,
+  promote "exploit <the signal>" to the top of that account's checklist.
+
+**Motif assignment depends on order history, which is ERP data.** Without the
+client's extract, SAUVETAGE / PLAN DE COMPTE / MONT\xC9E EN GAMME / R\xC9VEIL cannot
+be assigned from purchase behaviour \u2014 do not guess them from a lead score, a
+sector, or a company's size. Two honest options, in order of preference:
+
+**The Monitor gap \u2014 read this before assigning anything.** Four of the six
+motifs (SAUVETAGE / PLAN DE COMPTE / MONT\xC9E EN GAMME / R\xC9VEIL) are purchase-
+behaviour reads, and CONQU\xCATE means "not in the known pipeline". A Monitor row
+that is *actively* worked therefore matches none of them: it IS in the pipeline,
+and without order history you cannot tell whether it buys broadly, narrowly, or
+at all. Do NOT resolve that by guessing a purchase motif, and do NOT silently
+drop the row.
+
+Those rows take **SUIVI** (row 6 of the table above). Say in the plan's legend
+that SUIVI exists precisely because purchase history is unavailable, and that
+ERP order data would split those rows into the four Pilotage motifs.
+
+1. **CONQU\xCATE is assignable from Leadbay alone \u2014 but say what it actually
+   means.** Discover membership proves a company is **not in the Leadbay known
+   pipeline**; it does NOT prove they never bought. Monitor membership is set by
+   lens scoring, not by purchase history, so an existing customer who was never
+   scored into the known view will appear in Discover. Without order history
+   there is no way to tell the two apart.
+
+   So label the motif for what the data supports \u2014 "fresh / not in the Leadbay
+   pipeline" \u2014 and **write the pitch so it survives being wrong**: an opener
+   that introduces the company works for a genuine prospect and merely sounds
+   uninformed to a customer, whereas "we've never worked together" told to a
+   current customer damages the relationship and the credibility of the whole
+   plan. Only ERP order history can upgrade this to a true never-a-client
+   claim. A Leadbay-only plan is still a legitimate *Conqu\xEAte* plan \u2014 say so in
+   the title rather than implying it covers the whole base.
+2. **Leadbay-activity recency is a qualifier, never a motif.** A long-dormant
+   known row stays **SUIVI** with "no Leadbay-logged action in N months" in its
+   why-now cell \u2014 never "no orders in N months", and never a seventh label.
+   Logged activity is not invoicing.
+
+
+# PHASE 4 \u2014 POTENTIAL AND RANKING
+
+Rank by \`ai_agent_lead_score\`, then qualification boost, then headcount. **Name that key in the plan's own header** \u2014 a reader who assumes a money-sort misreads the whole order \u2014 and title the deliverable for what it is (a conquest plan), not for what it isn't.
+
+Cash-to-capture is not available: it needs \`ca12\` from my invoicing system, which no Leadbay tool exposes. Show it as OMITTED in the ledger and say what a cash-ranked version would require (12-month revenue per account, per-family split, last order date, order count, plus a \u20AC/employee benchmark) \u2014 do not model it.
+
+# PHASE 5 \u2014 CONTACTS (consent-gated)
+
+Each card needs a reachable decision-maker. \`leadbay_enrich_titles({leadIds, lensId})\` in discovery mode first \u2014 that reveals what's enrichable and spends nothing. Render whatever contact detail is already on the record; many accounts already carry a named contact.
+
+**Do NOT stop and wait for enrichment consent before delivering.** Asking for a plan is not authorization to spend quota on {{arg:count_or_default}} accounts \u2014 but neither is it a reason to end the turn on a spending question with no plan attached. Ship the ranked plan (Phase 6), then **offer** the paid reveal alongside it. The discovery call returned no \`titles\`, so it only told you what's *available* \u2014 **the offer must therefore carry the titles you propose to enrich AND the channels**, not just a volume: "enrich N contacts at these titles (\`<the titles you picked from available_titles / title_suggestions>\`), email only / email + phone \u2014 reveals consume quota". A bare "yes" to a volume-only question is not a mandate to pick titles yourself, and re-running discovery instead of launching wastes a turn.
+
+\u26A0 **Do NOT quote a cost or a credits figure.** The per-reveal rate is backend-side and enrichment is gated by quota, not a credit balance; \`credits_remaining\` is advisory context only. A spend number invented to make the offer concrete is the same failure as an invented euro on a card.
+
+On an explicit yes, launch with the agreed \`titles\` + channels, then poll \`leadbay_bulk_enrich_status\` until done and **keep the \`bulk_id\` handles** for the deck.
+
+\u26A0 **Render only the channels that actually came back.** The default reveal is email-only unless phone was explicitly requested, so never emit a \`tel:\` link for a contact whose phone was never revealed \u2014 show the channels enrichment returned and mark the rest omitted. A fabricated phone link is the same failure as a fabricated euro.
+
+# PHASE 6 \u2014 DELIVER
+
+Render the PROVENANCE LEDGER and its legend FIRST, then the chat answer beneath it \u2014 never the other way round. A ranked money column read before its sourcing has already misled the reader:
+
+## RENDERING \u2014 account activation plan
+
+Two surfaces. The **chat table** is the default answer and must stand alone as
+useful. The **interactive deck** is offered, not forced (see the widget gate) \u2014
+build it only once the user accepts.
+
+### Order on the page \u2014 ledger FIRST, then the plan
+
+Print the PROVENANCE LEDGER (and the one-line provenance legend) **before** the
+chat table, the deck, or any other part of the deliverable. The reader must know
+which figures are measured and which are modelled *before* they read a ranking
+built on them \u2014 a cash column read first and sourced second has already done its
+damage. This ordering is the workflow contract, not a stylistic preference.
+
+### The chat table (render immediately after the ledger)
+
+**The chat answer must be the whole deliverable the user asked for** \u2014 the deck
+is optional, so a top-50 request whose chat half stops at 10 rows has delivered
+a fifth of the plan. Render the **requested count**, with its pitch + checklist
+block per row (see below).
+
+If that is genuinely too long for one message, do NOT silently truncate: state
+the delivered count plainly ("here are 20 of the 50 \u2014 say the word for the
+rest"), so the user knows what they have. Never present a partial list as
+though it were the plan. Four columns:
+
+Col 3's header is **the ranking key you actually used** \u2014 never a cash label,
+since cash-to-capture cannot be computed from Leadbay data:
+
+\`\`\`
+| # \xB7 Account | Motif | Fit score | Why now |
+\`\`\`
+
+- **Col 1** \u2014 rank number, then the company name linked to its website when one
+  is known. Follow with a compact \` \xB7 \`-separated pill line: city \xB7 headcount \xB7
+  any account reference you were given. **Every figure in that pill line carries
+  its class too** \u2014 headcount is \`[LB]\` (a Leadbay size band, so render the band
+  rather than a false-precision point value) or \`[SIRENE]\` if you read it from
+  the registry. An untagged employee count is still an untagged number in front
+  of a client; omit it rather than ship it bare.
+- **Col 2** \u2014 the motif, exactly one of SAUVETAGE / PLAN DE COMPTE / MONT\xC9E EN
+  GAMME / R\xC9VEIL / CONQU\xCATE / SUIVI. Never invent a seventh.
+- **Col 3** \u2014 the ranking signal with its provenance class, e.g. \`AI 30 [LB]\`.
+  Tagging is not optional; an untagged figure reads as measured fact. **There is
+  no money column** \u2014 cash-to-capture needs invoicing data Leadbay does not
+  hold, so it stays OMITTED in the ledger rather than being modelled. A column
+  of invented euros next to a client's name is the exact failure this
+  deliverable must not ship.
+- **Col 4** \u2014 the one-line reason to act now: the signal when there is one,
+  otherwise the motif's deciding evidence. Never fill this with a
+  plausible-sounding invented event; an account with nothing read shows \`\u2014\`.
+
+Sort strictly by the ranking key named in the ledger (which was printed above).
+
+### The pitch + checklist block (part of the chat answer, not the deck)
+
+The table alone is a shortlist, not a plan \u2014 the pitch and the three-step
+checklist are what make it actionable, and the deck is **optional**, so they
+cannot live only there. Under the table, render a block for **every account you
+put in the table** \u2014 if a row is good enough to rank, it is good enough to carry
+its pitch. Do NOT ship the top 5 or 10 and offer the rest "on request": that
+puts the actionable half of the deliverable behind another user turn, and the
+rows you defer are the ones a rep is least likely to chase. If the full plan is
+genuinely long, shrink the TABLE (fewer rows, stated plainly) rather than
+shipping ranked rows with no pitch:
+
+\`\`\`
+**<rank> \xB7 <Company>** \u2014 <MOTIF>
+\u260E <contact name>, <title> \xB7 <only the channels actually revealed>
+> "<the motif's pitch, in the client's commercial voice>"
+\u2610 <step 1>  \u2610 <step 2>  \u2610 <step 3>
+\`\`\`
+
+Keep each pitch to one or two sentences a rep can say out loud, and each
+checklist to three concrete, checkable actions matching that motif's shape.
+When an account has a signal, lead the pitch with it and promote
+"exploit &lt;the signal&gt;" to the top of its checklist.
+
+### The interactive deck (only after the user accepts)
+
+One card per account, ordered by the same key. Per card:
+
+- **Header** \u2014 rank badge, company name, city \xB7 trade \xB7 headcount, and the
+  ranking signal right-aligned with its class tag (e.g. \`AI 30 [LB]\`). No cash
+  figure: the deck and the chat answer must never disagree about which fields
+  exist, and a card carrying a euro the table omitted means one was modelled.
+- **Motif badge** \u2014 the motif, visually distinct per motif so the deck can be
+  scanned by strategy.
+- **Qualification row** \u2014 the org's **actual** questions as returned by
+  \`leadbay_get_qualification_questions\` (there may be fewer than five), each with
+  \u2713 / \u2717 / pending and labelled with its real text. Render exactly as many rows as
+  the org has: never pad to five with invented labels or bogus pending pills, and
+  never substitute invented wording.
+- **Signal line** \u2014 the event driving urgency, or omitted.
+- **Action block** \u2014 the named contact with **only the channels enrichment
+  actually returned** as one-tap \`tel:\` / \`mailto:\` links (the default reveal is
+  email-only unless phone was requested \u2014 never emit a \`tel:\` for a phone that
+  was never revealed; mark it omitted instead), the motif's pitch as a quoted
+  line, and the three-item checklist as checkboxes.
+- **Caveat block** \u2014 closing the deck: which classes fed it, an explicit line
+  that \`[HYP]\` figures are modelled rather than measured, and which fields are
+  OMITTED because Leadbay does not hold them. A missing input means an omitted
+  field, never a stand-in number.
+
+Header KPIs across the top, each carrying its provenance class: accounts on the
+plan, count qualified, count with a reachable contact. **No euro totals** \u2014 the
+same rule as the table, for the same reason.
+
+\u26A0 **No "activated" KPI at build time.** Nothing in this workflow measures
+activation \u2014 the deck is built before any outreach happens \u2014 so a count would be
+fabricated or imply outcome tracking that doesn't exist. If the deck's checklists
+persist locally, an "activated" tile may count *checked* accounts and must be
+labelled as local checklist state, not a measured outcome.
+
+
+Then **offer** the interactive deck \u2014 don't force it:
+
+## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
+
+Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can route into. These ALWAYS produce a better UX than markdown tables / inline prose for the data shapes they support \u2014 they're tappable on mobile, persistent across turns, and integrate with the host's quick-actions.
+
+**The Big Three** \u2014 when a tool result fits, route there:
+
+| Host widget | Use when | Field map (from Leadbay payload) |
+|---|---|---|
+| \`places_map_display_v0\` + \`places_search\` (Claude) | \u22652 leads with coords / \`location.city\`, geographic / "in person" / travel intent | **Two-step**: \`places_search\` each lead (query = company + full street address) \u2192 real \`place_id\`/coords, THEN render with \`places_map_display_v0\` (Itinerary mode for a tour). Skipping \`places_search\` \u2192 schematic scatter, not a street map. |
+| \`message_compose_v1\` (Claude) | You're about to draft outreach (email / message / call opener) | \`{kind: "email", summary_title, variants: [{label, body, subject}]}\` \u2014 2\u20133 variants, labels describe STRATEGY ("Push for alignment", "Reference the M&A signal"), not tone ("Friendly", "Formal") |
+| \`ask_user_input_v0\` (Claude chat / ChatGPT) **or** \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 whichever is in your tool set; their schemas differ, match the one you have | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | Per-tool schema in the server instructions + NEXT STEPS routing block. Max 3 questions. |
+
+ChatGPT exposes the same routing pattern via \`_meta.openai/outputTemplate\`. We don't ship any custom widgets ourselves \u2014 this gate is exclusively about routing into the host's first-party widgets when the data shape fits.
+
+**Rules:**
+- The widget IS the visual. Do NOT emit a markdown table or prose list of the same data alongside \u2014 that produces two competing UIs.
+- Pass identifiers (place_id, lead.id, contact_id) verbatim. Don't rewrite.
+- When the host doesn't expose the named widget, the agent falls back to the prose/table rendering the per-tool description already specifies. The directive is host-conditional; the fallback is automatic.
+- One short intro sentence in chat is enough \u2014 "Here are your 5 NYC follow-ups." Then route into the widget.
+
+
+\u26A0 **The deck's contact layer depends on what actually happened in Phase 5.** Bind a \`leadbay_bulk_enrich_status\` resource ONLY if a paid reveal was launched and you hold a \`bulk_id\`. If the user accepted the deck but not the reveal, render the contacts already on record and carry the paid-reveal offer inside the deck \u2014 never wire a status resource with no handle (it renders permanently empty) and never launch enrichment from the deck to manufacture one.
+
+On acceptance, call \`leadbay_artifact_kit\`, read its \`usage_guide\` before writing any code, and build a single-file deck. Wire the live layer from the handles you kept: a poll-until-done resource per \`qualify_id\` for the qualification pills, and one over \`leadbay_bulk_enrich_status\` for the contacts. \u26A0 **If enrichment already ran this session, bind the existing \`bulk_id\` \u2014 re-launching enrichment from the deck double-spends my quota.** Per-card notes and outcomes go through the pre-wired note/outreach view-models (they carry the required verification and \`_triggered_by\` fields; hand-rolling those is where it breaks). Keep the checklists in local storage, and always wire a Refresh \u2014 auto-poll is host-dependent. List every tool the deck calls in its \`mcp_tools\`, and render the bridge-unavailable branch, or the pills silently show empty.
+
+# Iron laws
+
+- **Never invent a number.** No revenue figure, registry count, signal or lead id that didn't come from a Leadbay response or a real registry query. A modelled figure is fine \u2014 tagged \`[HYP]\` and named as an assumption. An untagged one is not.
+- **The ledger ships before the deliverable**, with un-sourceable fields shown as OMITTED rather than dropped.
+- **A conquest plan is the deliverable, not a consolation prize.** Leadbay holds no invoicing data, so the money columns are OMITTED by design. Title it honestly, name what a cash-ranked version would need \u2014 never refuse, and never fill the gap with a guess.
+- **Deliver first, ask alongside.** Do not end a turn without a ranked list of real accounts. The benchmark, the Tier-1 threshold, the territory, a missing lens, a short question set and an unanswered enrichment offer are all NON-blocking \u2014 carry them next to the plan. Only an unresolvable identity mismatch (whose plan is this?) may stop delivery.
+- **One motif per account, from the closed set of six**, with its deciding evidence stated.
+- **The org's real qualification questions**, read from Leadbay \u2014 never invented.
+- **Consent before any paid enrichment**, and never re-launch a bulk that already exists.
+- **Offer the deck; don't force it.** The chat answer must stand alone as useful.
+- Carry the captured \`lensId\` on the calls whose schema **accepts** it (\`leadbay_pull_leads\`, \`leadbay_bulk_qualify_leads\`, \`leadbay_enrich_titles\`). Do NOT add it to \`leadbay_pull_followups\`, \`leadbay_scan_portfolio_signals\`, \`leadbay_qualify_status\` or \`leadbay_bulk_enrich_status\` \u2014 they declare no such argument and reject unknown properties.
+- Building a plan is not outreaching \u2014 do not send anything and do not call \`leadbay_report_outreach\`.
+`;
 var leadbay_work_campaign = `
 Work my **{{arg:campaign_or_default}}** campaign as an outreach session{{arg:mode_paren}}.
 
@@ -1308,6 +1759,7 @@ should I follow up on" to "I'll send via lemlist".
   leadbay_refine_audience: { "name": "leadbay_refine_audience", "short_description": "Refine the kind of leads Leadbay surfaces beyond firmographics, with a\nfree-text instruction. Handles the clarification round-trip if the new\nprompt is ambiguous.\n", "arguments": [{ "name": "instruction", "description": "The refinement (e.g. 'focus on hospitals running their own IT'). Set to plain English.", "required": true }], "expected_calls": ["leadbay_refine_prompt", "leadbay_account_status"], "failure_modes": ["Calls leadbay_answer_clarification on the user's behalf instead of surfacing the clarification verbatim", "Glosses over the clarification options instead of presenting them as offered", "Promises immediate effect when status='applied' actually triggers an async intelligence recompute"] },
   leadbay_research_a_domain: { "name": "leadbay_research_a_domain", "short_description": "Resolve a company by name or domain across the user's visible Discover,\nMonitor, and Activate corpus, then return everything Leadbay knows about it.\n", "arguments": [{ "name": "domain", "description": "Company name or domain (for example 'Acme Corporation' or 'acme.com'). The legacy argument key remains `domain` for client compatibility.", "required": true }], "expected_calls": ["leadbay_research_lead_by_name_fuzzy"], "failure_modes": ["Fabricates qualification answers not present in any tool response", "Calls leadbay_import_and_qualify before searching the existing visible corpus", "Treats the active lens as the entire search universe when the user did not request a lens scope", "Imports a missing company without the user's explicit permission", "Renders the research result as a freeform narrative instead of the canonical research-company-card layout (the card with header score bar, pill row, signal sections, contacts table is the structural contract; commentary belongs ABOVE or BELOW it)"] },
   leadbay_setup_team_prospecting: { "name": "leadbay_setup_team_prospecting", "short_description": "Manager-led prospecting setup: conversationally turn a natural-language\naudience ask into a Leadbay lens, validate the candidate leads, and\npersist them as one or more named campaigns the rep(s) can work\nthrough. Closes #3630 US3 end-to-end (within the current\ncreator-scoped campaign visibility model).\n", "arguments": [{ "name": "audience", "description": "Natural-language audience description (e.g. 'plumbing companies with 10-50 employees in Seine-Maritime'). The lens-creation step (`leadbay_refine_prompt` \u2192 `leadbay_create_lens`) interprets it.", "required": true }, { "name": "rep_split", "description": "Optional: how to split the validated leads into per-rep campaigns. Free text \u2014 e.g. 'split by city' or 'one campaign per rep: John gets Tulsa, Sarah gets OKC'.", "required": false }], "expected_calls": ["leadbay_refine_prompt", "leadbay_create_lens", "leadbay_promote_lens", "leadbay_pull_leads", "leadbay_research_lead_by_id", "leadbay_create_campaign", "leadbay_add_leads_to_campaign"], "failure_modes": ["Skips the validation step \u2014 creates a campaign of unvetted leads from a freshly-created lens without giving the manager a chance to drop weak fits", "Creates ONE campaign for all reps without asking about the split \u2014 the user explicitly mentioned per-rep distribution and the prompt should honor it", "Pretends the backend supports cross-user assignment \u2014 campaigns are owned by the caller (creator-scoped). Surface this honestly instead of fabricating an assignment model", "Asks ALL clarifying questions inline before tool calls \u2014 instead, run the lens refinement loop with `leadbay_refine_prompt` which handles the clarification protocol natively"] },
+  leadbay_top_accounts_to_activate: { "name": "leadbay_top_accounts_to_activate", "short_description": 'Build a ranked account-conquest plan from Leadbay data \u2014 the accounts worth\nactivating, each with a motif, a pitch and a checklist, ranked by the\nstrongest Leadbay signal. Every figure carries its source, and anything\nLeadbay can\'t measure is shown as OMITTED rather than estimated. Uses\n`leadbay_bulk_qualify_leads` and `leadbay_enrich_titles`. Trigger on\n"top 50 accounts to activate", "who should we go after".\n', "arguments": [{ "name": "count", "description": "Optional: how many accounts the plan should hold (default 50).", "required": false }, { "name": "territory", "description": "Optional: restrict the plan to a territory (e.g. 'Indre-et-Loire', 'R\xE9gion Ouest'). Sets geography on the Discover lens.", "required": false }], "expected_calls": ["leadbay_account_status", "leadbay_get_qualification_questions", "leadbay_pull_leads", "leadbay_pull_followups", "leadbay_bulk_qualify_leads", "leadbay_qualify_status", "leadbay_scan_portfolio_signals", "leadbay_enrich_titles", "leadbay_bulk_enrich_status", "leadbay_account_history", "leadbay_artifact_kit", "leadbay_new_lens", "leadbay_adjust_audience"], "failure_modes": ["Invents, estimates or proxies a revenue-realized figure \u2014 the single worst failure. Leadbay does not hold what an account buys, and headcount, sector and lead score are NOT proxies for it.", "Sorts by cash-to-capture, synthesizing a revenue figure per account purely to make that ranking work. Leadbay has no revenue data: rank by the Leadbay signal, say so in the header, and never invent the key.", "Emits \u20AC figures with no provenance class, so modelled numbers read as measured fact in front of a paying client.", "Skips the PROVENANCE LEDGER, or drops un-sourceable fields from it instead of rendering them as OMITTED \u2014 which hides the gap.", "Fabricates registry/TAM counts (France or regional company counts) instead of querying the registry or marking the figure NOT COMPUTED. Leadbay does not proxy SIRENE.", "Invents the five qualification questions from this prompt's own recommendations instead of reading the org's actual questions via leadbay_get_qualification_questions.", "Leaves the deck's live layer dead \u2014 qualification and enrichment handles never wired in, so the pills and contacts stay empty while the deck still looks finished.", "Invents lead ids to make the qualification pills appear populated.", "Fabricates a plausible-sounding signal ('just won a public tender') for an account whose signals were never read. No signal read means an explicit dash.", "Assigns a motif outside the closed set of six, or assigns SAUVETAGE / PLAN DE COMPTE / MONT\xC9E EN GAMME / R\xC9VEIL from a lead score or sector when order history was never available.", "Labels Monitor membership as 'is a client' \u2014 Monitor is a Leadbay view whose membership is decided by lens scoring, not by whether the company ever bought anything.", "Launches paid enrichment on the whole plan without consent. Asking for a plan is not authorization to spend on 50 accounts.", "Re-launches enrichment from inside the built deck when a bulk handle already exists this session \u2014 double-spends the user's quota.", "Forces the interactive deck without offering it first, or ships the deck INSTEAD of a chat answer that stands on its own.", "Refuses the task because revenue data is missing, instead of delivering the conquest plan and naming what a cash-ranked version would need.", "Ends the turn without a ranked list of real accounts \u2014 gating the whole plan on a NON-blocking question (the territory, a missing lens, or a 3-vs-5 qualification-question gap) so the user gets a plan-of-a-plan. Only an unresolvable company-identity mismatch may stop delivery; every other open question rides alongside the delivered plan.", "Stops after the discovery contact preview to wait for enrichment consent, delivering no plan that turn \u2014 the ranked plan ships first; the paid reveal is offered alongside it.", "Renders a contact channel enrichment never returned (e.g. a phone link when only email was approved and revealed) instead of showing the returned channels and marking the rest omitted."] },
   leadbay_work_campaign: { "name": "leadbay_work_campaign", "short_description": "Work a campaign as a real outreach session: pick the campaign,\nassess what the user has (phones / emails / coords), then PROPOSE\nthe right session mode (call sheet, email sheet, enrich titles\nfirst, map). After they pick, render \u2014 and as they dictate\noutcomes per lead, record both note + epilogue via\n`leadbay_report_outreach` in one round trip.\n", "arguments": [{ "name": "campaign", "description": "Campaign name (fuzzy match against your own campaigns) or campaign UUID. Omit to list and pick interactively.", "required": false }, { "name": "mode", "description": "Optional: skip the readiness-assessment proposal and jump directly into 'call_sheet' / 'email_sheet' / 'map' / 'enrich_first'. Omit (recommended) and let the prompt propose based on the data.", "required": false }], "expected_calls": ["leadbay_list_campaigns", "leadbay_campaign_call_sheet", "leadbay_enrich_titles", "leadbay_report_outreach"], "failure_modes": ["Renders the call sheet immediately without proposing the right mode \u2014 if 60% of leads have no contacts, calling is futile; enrich first. Always assess `readiness` first.", "Auto-renders the map widget without asking \u2014 maps are intrusive when the user just wants to scroll a list. Map mode is a proposed option, not a default.", "Proposes map mode after the user has previously said they don't like maps \u2014 check conversation memory before adding 'View on a map' to the options list.", "Calls `leadbay_campaign_progression` instead of `leadbay_campaign_call_sheet` \u2014 progression has counts but no phones / LinkedIn / call-ready data; the user can't actually dial from progression rows.", "Renders contacts WITHOUT making the phone number a `[bare](tel:URL)` link \u2014 on mobile that breaks one-tap calling, which is the whole point of the cheat sheet.", "Records outreach WITHOUT epilogue_status \u2014 leaves the lead's pipeline state unchanged; the rep then sees the same lead surfaced again next session.", "Records outreach WITHOUT verification \u2014 verification.source/ref is REQUIRED. For calls, pass `{source: 'user_confirmed', ref: <user's exact words>}`.", "Loops through ALL leads in a 50-lead campaign before recording any outreach \u2014 the call-then-record loop must be per-lead, not batched."] }
 };
 var PROMPT_CATALOG_HEADER = `This server exposes the following workflow prompts via \`prompts/list\` and \`prompts/get\`. Some MCP clients render them as slash commands; if your client does not, you (the agent) should invoke them directly via \`prompts/get\` when the user's request matches one of the triggers described below.`;
@@ -1324,6 +1776,7 @@ var PROMPT_CATALOG_BULLETS = {
   leadbay_refine_audience: `- \`leadbay_refine_audience\` (required args: instruction): Refine the kind of leads Leadbay surfaces beyond firmographics, with a free-text instruction. Handles the clarification round-trip if the new prompt is ambiguous.`,
   leadbay_research_a_domain: `- \`leadbay_research_a_domain\` (required args: domain): Resolve a company by name or domain across the user's visible Discover, Monitor, and Activate corpus, then return everything Leadbay knows about it.`,
   leadbay_setup_team_prospecting: `- \`leadbay_setup_team_prospecting\` (required args: audience; optional args: rep_split): Manager-led prospecting setup: conversationally turn a natural-language audience ask into a Leadbay lens, validate the candidate leads, and persist them as one or more named campaigns the rep(s) can work through. Closes #3630 US3 end-to-end (within the current creator-scoped campaign visibility model).`,
+  leadbay_top_accounts_to_activate: `- \`leadbay_top_accounts_to_activate\` (optional args: count, territory): Build a ranked account-conquest plan from Leadbay data \u2014 the accounts worth activating, each with a motif, a pitch and a checklist, ranked by the strongest Leadbay signal. Every figure carries its source, and anything Leadbay can't measure is shown as OMITTED rather than estimated. Uses \`leadbay_bulk_qualify_leads\` and \`leadbay_enrich_titles\`. Trigger on "top 50 accounts to activate", "who should we go after".`,
   leadbay_work_campaign: `- \`leadbay_work_campaign\` (optional args: campaign, mode): Work a campaign as a real outreach session: pick the campaign, assess what the user has (phones / emails / coords), then PROPOSE the right session mode (call sheet, email sheet, enrich titles first, map). After they pick, render \u2014 and as they dictate outcomes per lead, record both note + epilogue via \`leadbay_report_outreach\` in one round trip.`
 };
 
@@ -1568,6 +2021,33 @@ var CATALOG = [
         )
       ];
     }
+  },
+  {
+    name: "leadbay_top_accounts_to_activate",
+    description: PROMPT_META.leadbay_top_accounts_to_activate.short_description,
+    arguments: [
+      {
+        name: "count",
+        description: "Optional: how many accounts the plan should hold (default 50).",
+        required: false
+      },
+      {
+        name: "territory",
+        description: "Optional: restrict the plan to a territory (e.g. 'Indre-et-Loire'). Sets geography on the Discover lens via `locations`.",
+        required: false
+      }
+    ],
+    render: (args) => {
+      const n = args.count ?? "50";
+      return [
+        userMessage(
+          substitutePlaceholders(leadbay_top_accounts_to_activate, {
+            count_or_default: n,
+            territory_block: args.territory ? `Scope the plan to **${args.territory}** \u2014 pass it as \`locations\` on the lens, never as a sector.` : ""
+          })
+        )
+      ];
+    }
   }
 ];
 function listPrompts() {
@@ -25289,7 +25769,7 @@ function parseWriteEnv(env = process.env) {
 }
 
 // src/http-server.ts
-var VERSION = true ? "0.27.0" : "0.0.0-dev";
+var VERSION = true ? "0.28.0" : "0.0.0-dev";
 var PORT = Number(process.env.PORT ?? 8080);
 var HOST = process.env.HOST ?? "0.0.0.0";
 var logger = {

package/dist/installer-electron.js

@@ -1804,7 +1804,7 @@ var init_installer_gui = __esm({
     init_install_dxt();
     init_install_shared();
     init_oauth();
-    VERSION = true ? "0.27.0" : "0.0.0-dev";
+    VERSION = true ? "0.28.0" : "0.0.0-dev";
     MESSAGES = {
       en: {
         installer: {

package/dist/installer-gui.js

@@ -1067,7 +1067,7 @@ async function oauthLogin(opts) {
 }
 
 // installer/installer-gui.ts
-var VERSION = true ? "0.27.0" : "0.0.0-dev";
+var VERSION = true ? "0.28.0" : "0.0.0-dev";
 var MESSAGES = {
   en: {
     installer: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leadbay/mcp",
-  "version": "0.27.0",
+  "version": "0.28.0",
   "mcpName": "io.github.leadbay/leadbay-mcp",
   "description": "Model Context Protocol (MCP) server for Leadbay — AI lead discovery, qualification, and enrichment for Claude Desktop, Cursor, and Claude Code.",
   "type": "module",