@leadbay/mcp 0.23.5 → 0.23.7

package/dist/http-server.js

@@ -625,44 +625,80 @@ GATE \u2014 DEFER TO TOOL RENDERING. When you call a Leadbay composite that ship
 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.
 
 
-# PHASE 1 \u2014 BUILD THE ITINERARY
+# PHASE 1 \u2014 CLARIFY SCOPE FIRST (ask before building)
 
-Call \`leadbay_tour_plan({city: "{{arg:city}}"})\` with the default counts (6 follow-ups + 6 discover). If the response is \`status: "ambiguous_locations"\`, surface the candidates and ask me to pick one, then re-call with \`city_id\`.
+Before calling \`leadbay_tour_plan\`, ask me what the tour should cover \u2014 a field tour is high-intent and the scope changes what lands on the map. Use your host's interactive question widget (\`ask_user_input_v0\` in Claude chat \u2014 \`{questions:[{question, type:"single_select", options:[\u2026]}]}\`; or \`AskUserQuestion\` in cowork / Claude Code \u2014 \`{questions:[{question, header, multiSelect, options:[{label, description}]}]}\`). Ask at most 2 short tap-to-answer questions:
 
-Split the returned \`monitor_leads\` into two buckets client-side using \`last_monitor_action\`:
+1. **Who to include?** \u2014 options: "Mix \u2014 known accounts + fresh prospects" (default), "Only my known accounts (follow-ups)", "Only fresh new prospects".
+2. **Enrich contacts that have no phone/email?** \u2014 options: "Yes, enrich the top stops", "No, just plan the tour".
 
-- **Customers** \u2014 leads with any \`last_monitor_action\` history (CONTACTED, MEETING_BOOKED, etc.). Treat as known accounts with prior engagement.
-- **Qualified prospects** \u2014 leads with high \`ai_agent_lead_score\` (or \`score\`) but no recent action.
+Skip a question only if I already answered it in my request (e.g. "plan a tour of just my new leads in NYC" \u2192 who-to-include is already "only new"; don't re-ask). If I gave the full scope up front, skip PHASE 1 entirely and go to PHASE 2.
+
+Map my answers to the \`leadbay_tour_plan\` call:
+- **Mix** \u2192 defaults (\`followups_count: 6, discover_count: 6\`).
+- **Only known accounts** \u2192 \`discover_count: 0\`.
+- **Only new prospects** \u2192 \`followups_count: 0\`.
+- **Enrich = yes** \u2192 after the tour is planned (PHASE 2), call \`leadbay_enrich_titles\` / \`leadbay_prepare_outreach(enrich:true)\` on the top stops that have no \`recommended_contact\` channel, before drafting outreach.
+
+# PHASE 2 \u2014 BUILD THE ITINERARY
+
+Call \`leadbay_tour_plan({city: "{{arg:city}}", \u2026scope from PHASE 1})\`. If the response is \`status: "ambiguous_locations"\`, surface the candidates and ask me to pick one, then re-call with \`city_id\`.
+
+Split the returned \`monitor_leads\` into two buckets client-side using their engagement-history fields:
+
+- **Customers** \u2014 leads with prior engagement history: any of \`epilogue_status\`, \`last_prospecting_action_at\`, or \`last_monitor_action_at\` is set. Treat as known accounts with prior interaction.
+- **Qualified prospects** \u2014 leads with a high \`ai_agent_lead_score\` (or \`score\`) but none of those history fields set (scored, not yet worked).
 
 \`discover_leads\` are the **New** bucket.
 
 Aim for a 3+3+3 split if possible. If the customers bucket has fewer than 3, fill from qualified. If discover_filter_note indicates a low match ratio for the city, mention it: "Only N/30 fresh leads matched your city" \u2014 better honest than padded.
 
-# PHASE 2 \u2014 RENDER THE MAP
+# PHASE 3 \u2014 PRESENT THE ITINERARY + OFFER THE MAP
+
+Show the planned tour as a concise per-lead list grouped by mode (Customers \u2192 Qualified \u2192 New), each line carrying its \`\u2605\`/\`\u2726\` badge, the company, city, and best contact. Keep it tight \u2014 this is the summary, not the map.
+
+Then **ALWAYS offer the map as the immediate next step** \u2014 a tour is inherently geographic, so the map is the natural payoff. End the turn with a single clear proposal:
+
+> **Want me to put these <N> stops on a map?** I'll plot them so you can see the route for your <city> day.
 
-Route the union of \`monitor_leads + discover_leads\` into \`places_map_display_v0\` (when the host exposes it). Per-lead \`notes\` string:
+Make it a genuine yes/no offer (route it through \`ask_user_input_v0\` / \`AskUserQuestion\` when that's in your tool set, so it's a tappable choice; otherwise the one-line question above). Do NOT render the map yet, and do NOT bury the offer \u2014 proposing the map is mandatory on every tour, for BOTH "plan a prospecting tour in <city>" and "who's worth meeting in <city>" phrasings. If the user already said "show me on a map" / "give me the map" in their request, skip the offer and go straight to PHASE 4 (render).
 
-- \`\u2605 Customer \u2014 <one-sentence sector + why-now>. Reach <name>, <role>: <bare phone>, <bare email>.\`
-- \`\u2605 Qualified \u2014 <one-sentence>. Reach <name>...\`
-- \`\u2726 New \u2014 <one-sentence>. Reach <name>...\`
+# PHASE 4 \u2014 RENDER THE MAP (when the user accepts, or asked for it up front)
 
-Skip leads with \`location.pos === null\` (no coordinates \u2192 no pin) \u2014 list them as "+ N leads without coordinates" below the widget.
+When the user says yes (or asked for the map in their original message), render it now. Two ways \u2014 you MUST do one, never a flat prose paragraph:
 
-Below the widget, emit a chat-prose summary grouped by mode (Customers / Qualified / New), with LinkedIn-linked contact name + bare phone/email pills per lead. Use the canonical \`linking/contact-linkedin\` rules.
+**Path A \u2014 \`places_search\` + \`places_map_display_v0\` are in your tool set.** Use the **two-step** host flow (this is what draws a real street map, not a schematic scatter):
+
+1. **\`places_search\` first, once per lead** \u2014 query = each \`map_locations\` entry's \`name\` + full street \`address\` (e.g. "Brooklyn Brewery, 79 N 11th St, Brooklyn, NY"). Resolve all stops up front to get real \`place_id\`s + verified coords/ratings.
+2. **\`places_map_display_v0\` second**, fed those resolved places, in **Itinerary mode** (a tour is a multi-stop route \u2014 show order, optionally arrival times / stop durations). Carry each lead's \u2605/\u2726 badge + one-line pitch from its \`notes\` into the place note.
+
+Do NOT push raw \`latitude\`/\`longitude\` straight into the display widget without \`places_search\` \u2014 that degrades to the neighborhood-dot scatter. \`map_locations\` already carries \`name\`, full \`address\`, coords, and badge-tagged \`notes\`; don't shorten the address to the city.
+
+**Path B \u2014 the widget is NOT in your tool set (e.g. Claude Desktop).** Emit one **place-card block per lead** in EXACTLY this shape so the chat host auto-detects the address and renders its own Google-Place-card map carousel \u2014 the \`### Company \xB7 City, State\` heading + address is what triggers it:
+
+\`\`\`
+### <Company Name> \xB7 <City>, <State>
+
+<\u2605 Customer | \u2605 Qualified | \u2726 New> \u2014 <one-sentence why-it-fits>. Reach **[<Contact name>](<LinkedIn URL>)**, <role>. \u260E <bare phone>.
+\`\`\`
 
-# PHASE 3 \u2014 DRAFT IN-AREA OUTREACH (optional, ask first)
+One block per lead in \`map_locations\`, grouped by mode. Pull company, city/state, badge, and contact straight from the tool response. A flat paragraph like "Brooklyn Brewery \u2014 Broadway, 10018 (Midtown). Best contact: \u2026" does NOT auto-detect and is WRONG \u2014 the per-lead heading with the city is mandatory.
+
+Coordinate-less leads are already omitted from \`map_locations\`; footnote them with \`map_summary.leads_without_coords\` ("+ N leads without coordinates").
+
+# PHASE 5 \u2014 DRAFT IN-AREA OUTREACH (optional, ask first)
 
 After the map, ask me ONCE: "Want me to draft 'I'll be in {{arg:city}}{{arg:date_paren}}' outreach for the top accounts?" If I say yes, for each of the top 3 leads (1 Customer / 1 Qualified / 1 New), call \`leadbay_prepare_outreach(leadId)\` and route the draft through \`message_compose_v1\` with a single variant labeled "In-area visit" \u2014 body opens with the visit context, references the AI-summary angle, ends with a clear ask (15-min coffee / on-site stopover).
 
 Serialize the prepare_outreach calls (max 3 in parallel \u2014 see the long-running-tools rule).
 
-# PHASE 4 \u2014 PERSIST AS A CAMPAIGN (optional, ask first)
+# PHASE 6 \u2014 PERSIST AS A CAMPAIGN (optional, ask first)
 
 After drafts, ask me ONCE: "Save these 9 accounts as a campaign called '**{{arg:city}} Tour{{arg:date_dash}}**'?" If I say yes, call \`leadbay_create_campaign({lead_ids: [...all_nine_lead_ids], name: "{{arg:city}} Tour{{arg:date_dash}}"})\`. Surface the returned \`id\` + \`name\` as a confirmation line, and offer the NEXT STEPS chip "View progression" (which routes to \`leadbay_campaign_progression\`).
 
 If I declined the campaign step, end the turn \u2014 the map + drafts are enough for an ad-hoc trip.
 
-# PHASE 5 \u2014 STOP
+# PHASE 7 \u2014 STOP
 
 Done. The map is the surface; the drafts are the action; the campaign is the persistence layer for managerial follow-up after the trip.
 `;
@@ -1261,7 +1297,7 @@ var PROMPT_META = {
   leadbay_followup_check_in: { "name": "leadbay_followup_check_in", "short_description": 'Follow-up check-in: surface KNOWN leads from the Monitor view needing\nre-engagement. Trigger on "follow up", "already known leads", "what\'s\noverdue", "before my trip", "who should I re-engage". Do NOT trigger on\n"show me today\'s leads", "my morning check-in", "run my check-in",\n"I do this every day", "every morning" \u2014 those go to\n`leadbay_daily_check_in`.\n', "arguments": [], "expected_calls": ["leadbay_pull_followups", "leadbay_research_lead_by_id", "leadbay_prepare_outreach"], "failure_modes": ["Calls leadbay_pull_leads (the Discover entry point) instead of leadbay_pull_followups \u2014 these are different data sources; the Discover queue does NOT contain Monitor's known-but-cold pipeline", 'Iterates pages of leadbay_pull_leads filtering by engagement_count to "fake" a follow-up view (a real bug observed in 0.9.0 \u2014 the right move is to call pull_followups directly)', "Replaces the canonical pull_followups table layout with prose per row (the per-tool RENDERING block is the structural contract; commentary belongs above or below)", 'Skips the cross-mode pivot offer at the end ("Want to see NEW leads from your wishlist instead?" routes to leadbay_pull_leads)'] },
   leadbay_import_file: { "name": "leadbay_import_file", "short_description": "Import a user-supplied CSV/file into Leadbay through five phases with\nevidence gates \u2014 scan, derive, resolve identities, preserve & commit,\nthen optionally qualify and report. The job is to maximize how many\nrows the Leadbay system actually ingests and matches.\n", "arguments": [{ "name": "file", "description": "Path or user-visible name of the CSV/file to import. If omitted, use the file the user attached or referenced.", "required": false }, { "name": "instruction", "description": 'Additional user goal, e.g. "then qualify the leads", "preserve owner phone as a custom field", or "only import restaurants in Manhattan".', "required": false }], "expected_calls": ["leadbay_resolve_import_rows", "leadbay_list_mappable_fields", "leadbay_create_custom_field", "leadbay_import_leads", "leadbay_import_and_qualify", "leadbay_add_note", "leadbay_import_status"], "failure_modes": ["Picks LEADBAY_ID from score alone, name-only, fuzzy-name-only, root-domain-only, brand-only, postcode-only, or city-only evidence", "Drops meaningful business notes or CRM record links instead of preserving them as custom fields or lead notes", "Treats a consumer mailbox domain (gmail.com, hotmail.com, ...) as the company domain", "Skips deriving company_domain from a business email when no website column exists (this kills match rate)", "Skips the COLUMN PRESERVATION PLAN byproduct before importing", "Skips the DECISION LOG byproduct before writing LEADBAY_ID", "Returns the imported records WITHOUT writing LEADBAY_ID values back into the user's file (leaves the user no audit trail of what matched)", "Fabricates leadIds, contact emails, or mapping IDs not present in the file or a tool response"] },
   leadbay_log_outreach: { "name": "leadbay_log_outreach", "short_description": "Log outreach (an email I sent, a call I made, a meeting I had) on a\nspecific lead. Captures verification so the SDR pipeline trusts the entry.\n", "arguments": [{ "name": "lead_id", "description": "The lead UUID. Get it from leadbay_pull_leads or leadbay_research_lead_by_id.", "required": true }, { "name": "summary", "description": "1-2 sentences describing what I did (e.g. 'Sent intro email to CTO citing recent Hornsea contract').", "required": true }], "expected_calls": ["leadbay_report_outreach"], "failure_modes": ["Calls leadbay_report_outreach without first collecting a verification source", "Fabricates a gmail_message_id or calendar_event_id (the human team treats verification as canonical)", "Records outreach to a different lead_id than the one the user supplied", "Skips the dry_run step when the user is unsure what would be sent"] },
-  leadbay_plan_tour_in_city: { "name": "leadbay_plan_tour_in_city", "short_description": "Plan a field sales tour: in one flow, surface follow-ups + fresh\nDiscover leads in the target city via `leadbay_tour_plan`, render\nto a map, draft in-area outreach via `leadbay_prepare_outreach`,\nand optionally persist the selected accounts as a named campaign\nvia `leadbay_create_campaign`. Closes #3630 US1 end-to-end.\n", "arguments": [{ "name": "city", "description": "City or region the user is visiting (e.g. 'Limoges', 'Bay Area'). Used as the geo filter for both Monitor and Discover lookups.", "required": true }, { "name": "date", "description": "When the visit is (e.g. 'May 24', 'next Thursday'). Surfaced in the outreach drafts as 'I'll be in <city> on <date>'.", "required": false }], "expected_calls": ["leadbay_tour_plan", "leadbay_research_lead_by_id", "leadbay_prepare_outreach", "leadbay_create_campaign"], "failure_modes": ["Calls leadbay_followups_map (Monitor-only) instead of leadbay_tour_plan \u2014 loses the Discover (fresh-lead) half that the user explicitly asked for", "Calls leadbay_pull_leads then drops the geo filter \u2014 returns the lens-wide wishlist instead of city-relevant fresh leads", 'Skips the campaign-persist step ("would you like to save these as a tour?") \u2014 leaves the rep with a one-shot map but no follow-up artifact', "Creates a campaign WITHOUT asking the user first \u2014 the persist step is high-intent; offer it, don't assume", "Fabricates lead_ids when seeding the campaign instead of using the ids returned by tour_plan"] },
+  leadbay_plan_tour_in_city: { "name": "leadbay_plan_tour_in_city", "short_description": 'Use whenever the user names a city they\'ll be in and asks who to see\n\u2014 "I\'m in SF next Tuesday, who\'s worth meeting?", "I\'m going to Berlin\n\u2014 who should I visit?", "plan my <city> tour". Any in-person/visit\nintent tied to a place routes here, NOT to `leadbay_pull_leads`. It\nsurfaces follow-ups + fresh Discover leads in the city via\n`leadbay_tour_plan`, ALWAYS offers to plot them on a map (rendering it\non yes), then offers outreach drafts + campaign persistence.\n', "arguments": [{ "name": "city", "description": "City or region the user is visiting (e.g. 'Limoges', 'Bay Area'). Used as the geo filter for both Monitor and Discover lookups.", "required": true }, { "name": "date", "description": "When the visit is (e.g. 'May 24', 'next Thursday'). Surfaced in the outreach drafts as 'I'll be in <city> on <date>'.", "required": false }], "expected_calls": ["leadbay_tour_plan", "leadbay_research_lead_by_id", "leadbay_prepare_outreach", "leadbay_create_campaign"], "failure_modes": ["Calls leadbay_followups_map (Monitor-only) instead of leadbay_tour_plan \u2014 loses the Discover (fresh-lead) half that the user explicitly asked for", "Calls leadbay_pull_leads then drops the geo filter \u2014 returns the lens-wide wishlist instead of city-relevant fresh leads", 'Skips the campaign-persist step ("would you like to save these as a tour?") \u2014 leaves the rep with a one-shot map but no follow-up artifact', "Creates a campaign WITHOUT asking the user first \u2014 the persist step is high-intent; offer it, don't assume", "Fabricates lead_ids when seeding the campaign instead of using the ids returned by tour_plan"] },
   leadbay_prospecting_overview: { "name": "leadbay_prospecting_overview", "short_description": `Orientation for working with Leadbay from any host \u2014 discovery vs.
 follow-up, the outreach loop, outcome recording, imports, pushback /
 snooze, and the connected-outreach-tool registry. Trigger when the
@@ -1283,7 +1319,7 @@ var PROMPT_CATALOG_BULLETS = {
   leadbay_followup_check_in: `- \`leadbay_followup_check_in\`: Follow-up check-in: surface KNOWN leads from the Monitor view needing re-engagement. Trigger on "follow up", "already known leads", "what's overdue", "before my trip", "who should I re-engage". Do NOT trigger on "show me today's leads", "my morning check-in", "run my check-in", "I do this every day", "every morning" \u2014 those go to \`leadbay_daily_check_in\`.`,
   leadbay_import_file: `- \`leadbay_import_file\` (optional args: file, instruction): Import a user-supplied CSV/file into Leadbay through five phases with evidence gates \u2014 scan, derive, resolve identities, preserve & commit, then optionally qualify and report. The job is to maximize how many rows the Leadbay system actually ingests and matches.`,
   leadbay_log_outreach: `- \`leadbay_log_outreach\` (required args: lead_id, summary): Log outreach (an email I sent, a call I made, a meeting I had) on a specific lead. Captures verification so the SDR pipeline trusts the entry.`,
-  leadbay_plan_tour_in_city: `- \`leadbay_plan_tour_in_city\` (required args: city; optional args: date): Plan a field sales tour: in one flow, surface follow-ups + fresh Discover leads in the target city via \`leadbay_tour_plan\`, render to a map, draft in-area outreach via \`leadbay_prepare_outreach\`, and optionally persist the selected accounts as a named campaign via \`leadbay_create_campaign\`. Closes #3630 US1 end-to-end.`,
+  leadbay_plan_tour_in_city: `- \`leadbay_plan_tour_in_city\` (required args: city; optional args: date): Use whenever the user names a city they'll be in and asks who to see \u2014 "I'm in SF next Tuesday, who's worth meeting?", "I'm going to Berlin \u2014 who should I visit?", "plan my <city> tour". Any in-person/visit intent tied to a place routes here, NOT to \`leadbay_pull_leads\`. It surfaces follow-ups + fresh Discover leads in the city via \`leadbay_tour_plan\`, ALWAYS offers to plot them on a map (rendering it on yes), then offers outreach drafts + campaign persistence.`,
   leadbay_prospecting_overview: `- \`leadbay_prospecting_overview\`: Orientation for working with Leadbay from any host \u2014 discovery vs. follow-up, the outreach loop, outcome recording, imports, pushback / snooze, and the connected-outreach-tool registry. Trigger when the conversation involves Leadbay leads, prospecting, pipeline, follow-up, outreach, or lens / ICP \u2014 anything from "show me my leads" to "what should I follow up on" to "I'll send via lemlist".`,
   leadbay_qualify_top_n: `- \`leadbay_qualify_top_n\` (optional args: count): Bulk-qualify the top N un-qualified leads in the active lens. Uses leadbay_bulk_qualify_leads with a sensible default budget.`,
   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.`,
@@ -6897,7 +6933,7 @@ This tool MUTATES state. The caller (agent or human-in-the-loop) is responsible
 `;
 var leadbay_adjust_audience = `## WHEN TO USE
 
-Trigger phrases: "narrow the audience to <sector>", "add <sector> to my <name> lens", "remove <sector> from this lens", "only show me companies of <size>", "stop including <sector>", "broaden this lens to also include <sector>".
+Trigger phrases: "narrow the audience to <sector>", "add <sector> to my <name> lens", "remove <sector> from this lens", "only show me companies of <size>", "stop including <sector>", "broaden this lens to also include <sector>", "restrict this lens to <city/d\xE9partement/r\xE9gion/state>", "only companies in <place>", "exclude <region> from this lens".
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
@@ -6908,7 +6944,7 @@ Prefer when: user wants to change an EXISTING lens's sectors/sizes. If the user
 Examples that SHOULD invoke this tool:
 - "Add fintech to my Joinery lens."
 - "Narrow my audience to manufacturing companies, 50\u2013500 people."
-- "Stop including retail in this lens."
+- "Restrict my rep's lens to Indre-et-Loire."
 
 Examples that should NOT invoke this tool (sound similar, route elsewhere):
 - "Create a lens called Joinery for fintech."
@@ -6917,9 +6953,10 @@ Examples that should NOT invoke this tool (sound similar, route elsewhere):
 
 ## RENDER (quick)
 
-On \`applied\`: confirm the lens edited (name) + the sectors/sizes added as
-chips. On \`ambiguous_sectors\` / \`ambiguous_lens\` / \`lens_not_found\`: surface
-the candidates and ask the user to pick, then re-call with the id/exact name.
+On \`applied\`: confirm the lens edited (name) + the sectors/sizes/locations
+added as chips. On \`ambiguous_sectors\` / \`ambiguous_locations\` /
+\`ambiguous_lens\` / \`lens_not_found\`: surface the candidates and ask the user
+to pick, then re-call with the id/exact name.
 
 ---
 
@@ -6927,7 +6964,9 @@ Restrict (or expand) the lens audience by sector / size. Free-text sectors are a
 
 **Targeting a lens \u2014 READ THIS.** By default this edits the user's ACTIVE lens. **If the user names a lens** ("add fintech to my **Joinery** lens", "in my Nordics lens, exclude retail"), you MUST pass \`lensName\` with that name (\`lensName:"Joinery"\`). Do NOT silently edit the active lens when a different one was named \u2014 that corrupts the wrong audience and is a top friction source. The name resolves against the user's lenses (case-insensitive, exact then unique-substring); it is edit-only and does NOT change which lens is active. An unmatched name returns \`status:"lens_not_found"\` with the lens list, and a name matching several returns \`status:"ambiguous_lens"\` with the candidates \u2014 surface them and re-call with the exact \`lensName\` or a \`lensId\`. Use \`leadbay_my_lenses\` if the user first wants to SEE or SWITCH lenses. To CREATE a brand-new lens, use \`leadbay_new_lens\` \u2014 not this tool.
 
-WHEN TO USE: when the user wants to see different kinds of leads (sector / size / etc.).
+**Geography \u2014 scope a sales territory.** Pass \`locations\` (free text like \`["Indre-et-Loire"]\`, \`["Bavaria"]\`, \`["Austin"]\`, or admin-area ids) to restrict the lens to a region, and \`exclude_locations\` to carve one out. Free text auto-resolves via \`/geo/search\` across every admin level \u2014 city, county, *d\xE9partement*, *r\xE9gion*, state, country. Place names go in \`locations\`, **never** in \`sectors\` or \`refine_prompt\`. Unresolved/ambiguous text returns \`status:"ambiguous_locations"\` with candidates \u2014 surface them and re-call the chosen id via the SAME axis it came from: an INCLUDE pick \u2192 \`location_ids\`; an EXCLUDE pick \u2192 \`exclude_locations\` (**NOT** \`location_ids\`, which would include the area the user asked to exclude). The returned \`message\` names the right param per text. This is how a director scopes a rep's territory and then asks for net-new accounts there.
+
+WHEN TO USE: when the user wants to see different kinds of leads (sector / size / geography / etc.).
 
 WHEN NOT TO USE: to refine BEYOND firmographics \u2014 that's leadbay_refine_prompt.
 
@@ -7207,7 +7246,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`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. |
 
@@ -7525,7 +7564,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`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. |
 
@@ -7781,7 +7820,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`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. |
 
@@ -8397,7 +8436,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`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. |
 
@@ -8475,7 +8514,7 @@ invent a tool that doesn't exist.
 `;
 var leadbay_new_lens = `## WHEN TO USE
 
-Trigger phrases: "create a lens", "create a new lens called <name>", "create a lens specialized in/into <X>", "make me a new audience for <X>", "set up a lens for <sector>", "new lens named <name>", "I want a lens just for <X>".
+Trigger phrases: "create a lens", "create a new lens called <name>", "create a lens specialized in/into <X>", "make me a new audience for <X>", "set up a lens for <sector>", "new lens named <name>", "I want a lens just for <X>", "create a lens for net-new accounts in <place>", "a lens scoped to <territory>".
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
@@ -8486,7 +8525,7 @@ Prefer when: user wants a brand-new lens (create/make/set up, often 'specialized
 Examples that SHOULD invoke this tool:
 - "Create a lens called Joinery for the fintech sector."
 - "Make me a new audience for healthcare companies, 30\u2013300 people."
-- "Set up a new lens named Nordics SaaS."
+- "Create a lens for net-new accounts in Indre-et-Loire."
 
 Examples that should NOT invoke this tool (sound similar, route elsewhere):
 - "Add fintech to my Joinery lens."
@@ -8499,7 +8538,8 @@ On \`preview\` (default \u2014 NOTHING created yet): show the lens that WILL be
 created (name + resolved sectors/sizes as chips) and ASK the user to confirm
 via ask_user_input_v0 ("Create this lens?" / "Change something"). Only on
 "yes" re-call with confirm:true. On \`created\`: confirm "Created **<name>**."
-On \`ambiguous_sectors\`: surface the candidate sectors to pick from.
+On \`ambiguous_sectors\` / \`ambiguous_locations\`: surface the candidates to
+pick from.
 
 ---
 
@@ -8509,6 +8549,8 @@ Create a brand-new lens (saved audience) and apply its sector/size criteria. Clo
 
 **Sectors resolve first.** Free-text \`sectors\`/\`exclude_sectors\` are auto-resolved against the taxonomy. If any don't resolve, the tool returns \`status:"ambiguous_sectors"\` with the candidates and **does NOT create the lens** \u2014 so re-calling after picking the right sector won't leave orphan half-built lenses. To discover valid sector labels up front, use \`leadbay_list_sectors\`.
 
+**Geography \u2014 scope a territory.** Pass \`locations\` (free text like \`["Indre-et-Loire"]\`, \`["Bavaria"]\`, or admin-area ids) to scope the lens to a sales territory, and \`exclude_locations\` to carve one out. Free text auto-resolves via \`/geo/search\` across every admin level (city / county / *d\xE9partement* / *r\xE9gion* / state / country). Like sectors, locations resolve BEFORE the lens is created \u2014 unresolved/ambiguous text returns \`status:"ambiguous_locations"\` with candidates and **does NOT create the lens**. Re-call the chosen id via the SAME axis it came from: an INCLUDE pick \u2192 \`locations\`; an EXCLUDE pick \u2192 \`exclude_locations\` (**NOT** \`locations\`, which would include the area the user asked to exclude). This is how a director spins up a lens for a rep's zone to surface net-new accounts there.
+
 **Does not switch the active lens.** The new lens is created but the user stays on their current one. Offer \`leadbay_my_lenses(switchToLensId=<new id>)\` as a next step if they want to start pulling from it.
 
 WHEN TO USE: when the user wants a NEW lens. Canonical phrasings: "create a lens called X", "make a new audience for Y", "set up a lens for <sector>".
@@ -8526,7 +8568,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`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. |
 
@@ -8660,11 +8702,11 @@ email. Do NOT paste the email body into chat prose alongside.
 
 ---
 
-Prepare a single-lead outreach brief: the full \`lead\` block (score, \`split_ai_summary\`, \`location\`, \`size\`, \`phone_numbers\`, \`website\`, \`description\`, \`social_urls\`, \`social_presence\`), the \`recommended_contact\` (always in the post-enrichment shape \u2014 \`contact_id\`, \`first_name\`, \`last_name\`, \`job_title\`, \`email\`, \`phone_number\`, \`linkedin_page\`, \`is_org_contact\` \u2014 with nulls where data isn't yet enriched), \`additional_contacts_count\`, and an \`enrichment\` block describing async state.
+Prepare a single-lead outreach brief: the full \`lead\` block (score, \`split_ai_summary\`, \`location\`, \`size\`, \`phone_numbers\`, \`website\`, \`description\`, \`social_urls\`, \`social_presence\`), the \`recommended_contact\` in post-enrichment shape (\`contact_id\`, names, \`job_title\`, \`email\`, \`phone_number\`, \`linkedin_page\`, \`is_org_contact\` \u2014 nulls where not yet enriched), \`additional_contacts_count\`, and an \`enrichment\` block describing async state.
 
 Optionally trigger contact enrichment in-flight with \`enrich:true\`. Enrichment is async (~60s). **Self-polling pattern (no separate tool needed):** re-call \`leadbay_prepare_outreach(leadId)\` without \`enrich\`; check \`enrichment.complete\`. When \`complete: true\`, the recommended contact now carries \`email\` and/or \`phone_number\`.
 
-The first call to this tool on a lead records a \`LEAD_VIEWED\`-style prospecting action server-side (one per lead per session \u2014 deduped) so the lead ages out of the Discover "new" view.
+The first call on a lead records a \`LEAD_VIEWED\`-style prospecting action server-side (deduped, one per lead per session) so it ages out of the Discover "new" view.
 
 IRON LAW \u2014 OUTCOME AFTER OUTREACH. The moment the user reports outreach happened ("I sent it", "she didn't pick up", "left a voicemail", "they replied", a forwarded email thread, a calendar invite), you MUST (1) call leadbay_report_outreach with verification (gmail_message_id, calendar_event_id, or the user's literal one-sentence confirmation as user_confirmed.ref) AND (2) ask the user about the outcome and set epilogue_status to one of the 4 canonical values: EPILOGUE_INTEREST_VALIDATED_OR_MEETING_PLANED ("Meeting booked"), EPILOGUE_COULD_NOT_REACH_STILL_TRYING ("Trying to reach"), EPILOGUE_NOT_INTERESTED_LOST ("Not interested"), EPILOGUE_STILL_CHASING ("In progress"). Use the user-facing labels in dialogue ("What's the outcome \u2014 meeting booked, trying to reach, not interested, or in progress?"); never say "epilogue" out loud. Skipping this step silently de-ranks every future follow-up suggestion because pull_followups depends on honest, current outcomes.
 
@@ -8679,7 +8721,7 @@ WHEN NOT TO USE: across many leads \u2014 use leadbay_enrich_titles for bulk; fo
 
 Route every draft through \`message_compose_v1\` (Claude's email composer). Above it, emit ONE short markdown context paragraph: score callout + sector fit + linked contact name + bare phone/email pills. Do NOT paste the email body into chat prose alongside \u2014 the composer IS the visual.
 
-Variant shape: 1\u20133 entries. Labels describe **strategy** ("Push for alignment", "Reference the M&A signal", "Soft intro \u2014 peer reference"), not tone. \`kind: "email"\` requires \`subject\`; phone/call openers use \`kind: "other"\` with the opener in \`body\`.
+Variant shape: 1\u20133 entries. Labels describe **strategy** ("Push for alignment", "Reference the M&A signal"), not tone. \`kind: "email"\` requires \`subject\`; phone/call openers use \`kind: "other"\` with the opener in \`body\`.
 
 ## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
 
@@ -8689,7 +8731,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`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. |
 
@@ -9018,7 +9060,7 @@ Trigger phrases: "show me leads", "show me new leads", "show me today's leads",
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
-Do NOT use for: "leads I should follow up with" \u2192 \`leadbay_pull_followups\`; "I'm going to <city>" \u2192 \`leadbay_followups_map\`; "leads I should reach out to" \u2192 \`leadbay_pull_followups\`; "leads to get back to" \u2192 \`leadbay_pull_followups\`; "leads to contact today" \u2192 \`leadbay_pull_followups\`; "should I contact" \u2192 \`leadbay_pull_followups\`; "reconnect with" \u2192 \`leadbay_pull_followups\`; "re-engage" \u2192 \`leadbay_pull_followups\`.
+Do NOT use for: "leads I should follow up with" \u2192 \`leadbay_pull_followups\`; "I'm going to <city>" \u2192 \`leadbay_tour_plan\`; "I'm in <city> next week \u2014 who's worth meeting" \u2192 \`leadbay_tour_plan\`; "who should I meet in <city>" \u2192 \`leadbay_tour_plan\`; "visiting <city> \u2014 who's worth meeting / seeing" \u2192 \`leadbay_tour_plan\`; "leads I should reach out to" \u2192 \`leadbay_pull_followups\`; "leads to get back to" \u2192 \`leadbay_pull_followups\`; "leads to contact today" \u2192 \`leadbay_pull_followups\`; "should I contact" \u2192 \`leadbay_pull_followups\`; "reconnect with" \u2192 \`leadbay_pull_followups\`; "re-engage" \u2192 \`leadbay_pull_followups\`.
 
 Prefer when: fresh Discover leads; if a lens is named, pass \`lensId\` and pin it
 
@@ -9029,6 +9071,7 @@ Examples that SHOULD invoke this tool:
 Examples that should NOT invoke this tool (sound similar, route elsewhere):
 - "Which leads should I follow up with this week?"
 - "I'm flying to Berlin Thursday \u2014 who should I meet?"
+- "I'm in San Francisco next Tuesday \u2014 who's worth meeting?"
 - "Show me leads I should reach out to today."
 - "Who should I get back to today?"
 - "Leads I should contact today."
@@ -10226,7 +10269,7 @@ WHEN NOT TO USE: the user wants a lead list (leadbay_pull_leads / leadbay_pull_f
 `;
 var leadbay_tour_plan = `## WHEN TO USE
 
-Trigger phrases: "visiting <city> in <N> days", "field tour in <city>", "plan a tour in <city>", "who should I meet in <city>", "customers plus prospects in <city>", "tour itinerary".
+Trigger phrases: "visiting <city> in <N> days", "I'm in <city> next week / Tuesday \u2014 who's worth meeting", "I'm going to <city> \u2014 who should I see", "who's worth meeting in <city>", "field tour in <city>", "plan a tour in <city>", "who should I meet in <city>", "customers plus prospects in <city>", "tour itinerary".
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
@@ -10236,6 +10279,7 @@ Prefer when: user wants known accounts plus new discoveries in one geographic it
 
 Examples that SHOULD invoke this tool:
 - "I'm flying to Limoges in 4 days \u2014 give me 3 customers, 3 qualified prospects, and 3 new high-potential."
+- "I'm in San Francisco next Tuesday. Who's worth meeting?"
 - "Plan my tour next Tuesday in Lyon: known accounts plus discoveries."
 - "Build a mixed itinerary for Berlin \u2014 I want both follow-ups and fresh leads."
 
@@ -10246,16 +10290,18 @@ Examples that should NOT invoke this tool (sound similar, route elsewhere):
 
 ## RENDER (quick)
 
-Route the union of monitor_leads + discover_leads into
-\`places_map_display_v0\` \u2014 same recipe as followups_map (lat/lng
-split, full address, short notes). Tag each entry's notes with a
-mode badge: "\u2605 Customer" / "\u2605 Qualified" / "\u2726 New" (split Monitor
-by last_monitor_action; Discover = New). Below the widget: one
-intro sentence + per-group chat-prose list with LinkedIn-linked
-contact names.
+Present the leads grouped by mode (\u2605 Customer / \u2605 Qualified / \u2726 New),
+then ALWAYS offer to plot them on a map ("Want me to put these on a
+map?"). On yes (or if the user asked for a map up front), render it:
+pass \`map_locations\` verbatim into \`places_map_display_v0\`, or on a
+host without the widget emit one \`### Company \xB7 City, State\` place-card
+block per lead so the host's address carousel renders. Never a flat
+prose paragraph. Full recipe below.
 
 ---
 
+**BEFORE YOU CALL \u2014 clarify scope with a tap-to-answer question.** A field tour is high-intent, so unless the user already said it, ASK first (via \`ask_user_input_v0\` / \`AskUserQuestion\` \u2014 whichever is in your tool set) and wait for the answer before calling this tool: (1) **Who to include?** \u2014 "Mix \u2014 known accounts + fresh prospects" (default) / "Only my known accounts" / "Only fresh new prospects"; (2) **Enrich contacts with no phone/email?** \u2014 "Yes, enrich the top stops" / "No, just plan". Map answers to args: only-known \u2192 \`discover_count: 0\`; only-new \u2192 \`followups_count: 0\`; mix \u2192 defaults; enrich=yes \u2192 after planning, run \`leadbay_enrich_titles\` / \`leadbay_prepare_outreach(enrich:true)\` on top stops missing a channel. Skip the question only if the request already states scope ("plan a tour of just my new leads" \u2192 only-new, don't ask). Do NOT skip straight to building + mapping without this.
+
 Build a single-call mixed-mode itinerary for a field sales tour. Combines \`leadbay_pull_followups\` (Monitor leads in the city \u2014 known accounts) with \`leadbay_pull_leads\` (Discover wishlist \u2014 new prospects, then client-side filtered by city) so the agent can answer the canonical #3630 US1 ask: *"I'm visiting Limoges in 4 days \u2014 propose 3 customers + 3 qualified prospects + 3 new high-potential discoveries."*
 
 **Geo resolution** is identical to \`leadbay_followups_map\`: pass \`city\` (any admin level \u2014 city, state, country, region \u2014 the \`/geo/search\` resolver picks the best match), or a pre-resolved \`city_id\`. Ambiguous matches surface as \`status: "ambiguous_locations"\` + \`location_ambiguities[]\`; pick an id and re-call with \`city_id\`.
@@ -10266,21 +10312,30 @@ Build a single-call mixed-mode itinerary for a field sales tour. Combines \`lead
 
 ---
 
-## RENDER \u2014 host-native map widget (REQUIRED, preferred)
+## RENDER \u2014 present the leads, then OFFER the map (render on yes)
+
+First present the leads grouped by mode as a tight per-lead list (badge + company + city + best contact). Then **ALWAYS offer the map** as the next step \u2014 "Want me to put these on a map?" \u2014 and render it only when the user accepts (or asked for a map in their original message). The map is mandatory to *offer* on every tour; it is *rendered* on acceptance.
 
-Identical to \`leadbay_followups_map\`. Pass the union \`monitor_leads + discover_leads\` into \`places_map_display_v0\`. The mode information goes in the per-lead \`notes\` string as a **leading badge**:
+When rendering, use the **two-step host flow** \u2014 this is what produces a real interactive street map instead of a schematic neighborhood scatter:
 
-- \`\u2605 Customer\` \u2014 Monitor lead with an existing \`last_monitor_action\` history (engaged / past interaction).
-- \`\u2605 Qualified\` \u2014 Monitor lead with a high \`ai_agent_lead_score\` or \`score\` but no recent action.
+1. **\`places_search\` first, once per lead.** For each entry in \`map_locations\`, call \`places_search\` with a natural query built from the lead's \`name\` + \`address\` (the full street address, e.g. "Brooklyn Brewery, 79 N 11th St, Brooklyn, NY"). This resolves a real \`place_id\` + verified coordinates/ratings from the host's place index. Run them up front (resolve all stops first), as the host's own guidance prescribes.
+2. **\`places_map_display_v0\` second**, fed the resolved places. Use **Itinerary mode** for a tour (multi-stop, route order, optional arrival times / stop durations) \u2014 a field-sales day IS an itinerary; Markers mode is only for a plain "show me X on a map". Carry each lead's mode badge (\u2605/\u2726) + one-line pitch from \`map_locations[i].notes\` into the place's note.
+
+Do NOT skip \`places_search\` and push raw \`latitude\`/\`longitude\` straight into the display widget \u2014 that's exactly what falls back to the schematic relative scatter (dots by neighborhood, no streets). The \`map_locations\` array already gives you everything \`places_search\` needs (\`name\`, full \`address\`, \`latitude\`, \`longitude\`, badge-tagged \`notes\`); do NOT shorten the address to just the city.
+
+For reference, the badge the server already applied to each \`notes\`:
+
+- \`\u2605 Customer\` \u2014 Monitor lead with prior engagement history (\`epilogue_status\`, \`last_prospecting_action_at\`, or \`last_monitor_action_at\` set).
+- \`\u2605 Qualified\` \u2014 Monitor lead with a high score but no recent action.
 - \`\u2726 New\` \u2014 Discover lead from \`discover_leads\`.
 
-Then the rest of the notes string follows the standard recipe: ONE sentence, sector/fit + contact ask, bare phone + email auto-linkified. Example:
+Example of a server-built \`notes\` string you pass through unchanged:
 
 \`\`\`
 \u2726 New \u2014 Strong mid-size hardware distributor fit. Reach Marie Dupont, Sales Director: +33 5 55 12 34 56, m.dupont@example.fr.
 \`\`\`
 
-Skip any lead whose \`location.pos\` is null (no lat/lng \u2192 no pin) \u2014 list them as a "+ N leads without coordinates" footer below the widget.
+Leads without coordinates are already omitted from \`map_locations\`. Use \`map_summary.leads_without_coords\` to footnote "+ N leads without coordinates" below the widget \u2014 no need to re-count.
 
 ## Chat prose AFTER the widget (where markdown DOES render)
 
@@ -10288,9 +10343,17 @@ Group the leads into THREE sections (Customers / Qualified Prospects / New Disco
 
 If the user said something like "3+3+3", honor that split. If \`followups_count\` returned fewer Customers than asked, fill from Qualified.
 
-## RENDER \u2014 fallback for hosts without \`places_map_display_v0\`
+## RENDER \u2014 fallback for hosts without \`places_map_display_v0\` (still a map, never a prose list)
 
-Emit per-lead markdown blocks grouped by mode, in the standard place-card-friendly format (\`### **Company** \xB7 City, State\`, mode badge + score, contact line, channel lines). Hosts that auto-detect addresses (Claude.ai web, cowork) build their own carousel from these blocks.
+When the widget isn't in your tool set (e.g. Claude Desktop), you MUST still produce a map by emitting one place-card block per \`map_locations\` entry in EXACTLY this shape \u2014 the \`### Company \xB7 City, State\` heading with the address is what makes the host auto-detect it and render its own Google-Place-card carousel:
+
+\`\`\`
+### <Company Name> \xB7 <City>, <State>
+
+<\u2605 Customer | \u2605 Qualified | \u2726 New> \u2014 <one-sentence fit>. Reach **[<Contact>](<LinkedIn URL>)**, <role>. \u260E <bare phone>.
+\`\`\`
+
+Group the blocks by mode (Customers \u2192 Qualified \u2192 New). A flat narrative paragraph ("Brooklyn Brewery \u2014 Broadway, 10018 (Midtown). Contact: \u2026") does NOT auto-detect into cards and is WRONG \u2014 the per-lead heading with the city is mandatory.
 
 ## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
 
@@ -10300,7 +10363,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 
 | Host widget | Use when | Field map (from Leadbay payload) |
 |---|---|---|
-| \`places_map_display_v0\` (Claude) | Result has \u22652 leads with \`location.city\` set, and the user's intent is geographic / "in person" / travel | \`{name: lead.company_name, address: "<city>, <country>", place_id: lead.location.place_id ?? omit, notes: <one-sentence pitch>}\` per location |
+| \`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. |
 
@@ -10319,7 +10382,7 @@ WHEN TO USE: the user signals a *mixed* tour-planning intent \u2014 they want bo
 
 WHEN NOT TO USE: if the user only wants follow-ups (use \`leadbay_followups_map\`), only wants new leads (use \`leadbay_pull_leads\`), wants research on one specific account (\`leadbay_research_lead_by_id\`), or wants to persist the tour as a campaign artifact (chain into \`leadbay_create_campaign\` after this).
 
-**Response envelope**: \`{city, city_id, monitor_leads, discover_leads, discover_filter_note, _meta}\` on happy path; \`{status: "ambiguous_locations", location_ambiguities, ...}\` when the passed \`city\` matched multiple admin areas.
+**Response envelope**: \`{city, city_id, monitor_leads, discover_leads, discover_filter_note, map_locations, map_summary, _meta}\` on happy path; \`{status: "ambiguous_locations", location_ambiguities, ...}\` when the passed \`city\` matched multiple admin areas.
 
 ---
 `;
@@ -15664,6 +15727,54 @@ function cityMatches(lead, cityHint) {
   const haystacks = [loc.city, loc.state, loc.country, loc.full].filter((v) => typeof v === "string").map((v) => v.toLowerCase());
   return haystacks.some((h) => h.includes(hint) || hint.includes(h));
 }
+function toMapLocation(lead, mode) {
+  const pos = lead?.location?.pos;
+  const valid = Array.isArray(pos) && pos.length === 2 && pos.every((n) => typeof n === "number");
+  if (!valid)
+    return null;
+  const loc = lead.location;
+  const c = lead.recommended_contact;
+  const cleanName = (v) => typeof v === "string" && v.trim() && v.trim().toLowerCase() !== "null" ? v.trim() : "";
+  const fullName = c ? [cleanName(c.first_name), cleanName(c.last_name)].filter(Boolean).join(" ") : "";
+  const role = cleanName(c?.job_title) ? `, ${cleanName(c?.job_title)}` : "";
+  const angle = lead.split_ai_summary?.next_step ?? lead.split_ai_summary?.approach_angle ?? lead.short_description ?? "Worth a visit";
+  let reach;
+  if (c && fullName && c.phone_number) {
+    reach = `Reach ${fullName}${role}: ${c.phone_number}${c.email ? `, ${c.email}` : ""}.`;
+  } else if (c && fullName && c.email) {
+    reach = `Reach ${fullName}${role}: ${c.email}.`;
+  } else if (c && fullName) {
+    reach = `Reach ${fullName} (enrich a channel).`;
+  } else {
+    reach = "Enrich a contact to reach this account.";
+  }
+  const notes = `${mode} \u2014 ${angle}. ${reach}`.slice(0, 280);
+  return {
+    name: lead.name,
+    address: loc.full ?? [loc.city, loc.state, loc.country].filter(Boolean).join(", "),
+    latitude: pos[0],
+    longitude: pos[1],
+    notes
+  };
+}
+function hasMonitorHistory(lead) {
+  return Boolean(lead?.epilogue_status || lead?.last_prospecting_action_at || lead?.last_monitor_action_at);
+}
+function buildMap(monitorLeads, discoverLeads2) {
+  const mapLocations = [
+    ...monitorLeads.map((l) => toMapLocation(l, hasMonitorHistory(l) ? "\u2605 Customer" : "\u2605 Qualified")),
+    ...discoverLeads2.map((l) => toMapLocation(l, "\u2726 New"))
+  ].filter((m) => m !== null);
+  const totalLeads = monitorLeads.length + discoverLeads2.length;
+  return {
+    map_locations: mapLocations,
+    map_summary: {
+      total_leads: totalLeads,
+      leads_with_coords: mapLocations.length,
+      leads_without_coords: totalLeads - mapLocations.length
+    }
+  };
+}
 var tourPlan = {
   name: "leadbay_tour_plan",
   annotations: {
@@ -15715,6 +15826,20 @@ var tourPlan = {
         type: "string",
         description: "Human-readable summary of the client-side geo filter applied to Discover leads (e.g. 'matched 3/30 by city/state')."
       },
+      map_locations: {
+        type: "array",
+        description: "Pre-shaped entries for `places_map_display_v0` \u2014 pass each one verbatim ({name, address, latitude, longitude, notes}); the mode badge (\u2605 Customer / \u2605 Qualified / \u2726 New) is already in `notes`. Do NOT reshape or re-derive from `location.pos`. One entry per lead with valid coordinates; coordinate-less leads are omitted and counted in `map_summary`.",
+        items: { type: "object" }
+      },
+      map_summary: {
+        type: "object",
+        description: "Deterministic coverage counts so the agent can footnote '+ N leads without coordinates' without re-counting.",
+        properties: {
+          total_leads: { type: "number" },
+          leads_with_coords: { type: "number" },
+          leads_without_coords: { type: "number" }
+        }
+      },
       status: {
         type: "string",
         description: "'ambiguous_locations' when the passed `city` matched multiple admin areas \u2014 pick an id from location_ambiguities and re-call with city_id."
@@ -15731,7 +15856,7 @@ var tourPlan = {
         }
       }
     },
-    required: ["monitor_leads", "discover_leads"]
+    required: ["monitor_leads", "discover_leads", "map_locations"]
   },
   execute: async (client, params, ctx) => {
     const followupsCount = params.followups_count ?? DEFAULT_FOLLOWUPS_COUNT;
@@ -15753,6 +15878,12 @@ var tourPlan = {
           monitor_leads: [],
           discover_leads: [],
           discover_filter_note: "City was ambiguous; pick an id and re-call to proceed.",
+          map_locations: [],
+          map_summary: {
+            total_leads: 0,
+            leads_with_coords: 0,
+            leads_without_coords: 0
+          },
           city: params.city ?? null,
           city_id: params.city_id ?? null,
           _meta: {
@@ -15779,6 +15910,7 @@ var tourPlan = {
       monitor_leads: monitorLeads,
       discover_leads: discoverLeads2,
       discover_filter_note: filterNote,
+      ...buildMap(monitorLeads, discoverLeads2),
       _meta: {
         region: client.region,
         latency_ms: client.lastMeta?.latency_ms ?? null
@@ -20415,7 +20547,7 @@ async function resolveLensByName(client, name) {
     return { ok: false, reason: "ambiguous", matches: partial };
   return { ok: false, reason: "not_found", lenses: all };
 }
-function mergeFilter(current, toAddSectors, toExcludeSectors, sizes) {
+function mergeFilter(current, toAddSectors, toExcludeSectors, sizes, toAddLocations = [], toExcludeLocations = []) {
   const items = current?.lens_filter?.items ?? [];
   const item = items[0] ?? { criteria: [] };
   const criteria = item.criteria ? [...item.criteria] : [];
@@ -20447,6 +20579,34 @@ function mergeFilter(current, toAddSectors, toExcludeSectors, sizes) {
       });
     }
   }
+  if (toAddLocations.length > 0) {
+    const idx = criteria.findIndex((c) => c.type === "location_ids" && !c.is_excluded);
+    if (idx >= 0) {
+      const cur = criteria[idx];
+      const merged = Array.from(/* @__PURE__ */ new Set([...cur.locations ?? [], ...toAddLocations]));
+      criteria[idx] = { ...cur, locations: merged };
+    } else {
+      criteria.push({
+        type: "location_ids",
+        is_excluded: false,
+        locations: toAddLocations
+      });
+    }
+  }
+  if (toExcludeLocations.length > 0) {
+    const idx = criteria.findIndex((c) => c.type === "location_ids" && c.is_excluded);
+    if (idx >= 0) {
+      const cur = criteria[idx];
+      const merged = Array.from(/* @__PURE__ */ new Set([...cur.locations ?? [], ...toExcludeLocations]));
+      criteria[idx] = { ...cur, locations: merged };
+    } else {
+      criteria.push({
+        type: "location_ids",
+        is_excluded: true,
+        locations: toExcludeLocations
+      });
+    }
+  }
   if (sizes && sizes.length > 0) {
     const normalizedSizes = sizes.map((s) => ({
       min: s.min ?? 0,
@@ -20507,6 +20667,21 @@ var adjustAudience = {
         },
         description: "Company size buckets, e.g. [{min:30,max:300}]"
       },
+      locations: {
+        type: "array",
+        items: { type: "string" },
+        description: "Geographic scope \u2014 free text (e.g. ['Indre-et-Loire', 'Bavaria', 'Austin']) or admin-area ids. Auto-resolved via /geo/search across all admin levels (city / county / d\xE9partement / r\xE9gion / state / country). Place names go HERE, never in sectors/keywords."
+      },
+      location_ids: {
+        type: "array",
+        items: { type: "string" },
+        description: "Explicit admin-area ids (skips /geo/search resolution)"
+      },
+      exclude_locations: {
+        type: "array",
+        items: { type: "string" },
+        description: "Locations to exclude (free text or ids)"
+      },
       lensId: { type: "number", description: "Lens id (escape hatch)" },
       lensName: {
         type: "string",
@@ -20525,17 +20700,22 @@ var adjustAudience = {
   },
   outputSchema: {
     type: "object",
-    description: "Return shapes: 'applied' on success; 'ambiguous_sectors' when free-text sectors matched multiple candidates (re-call with sector_ids); 'lens_not_found' / 'ambiguous_lens' when a lensName didn't resolve to exactly one lens (re-call with lensId or an exact lensName).",
+    description: "Return shapes: 'applied' on success; 'ambiguous_sectors' when free-text sectors matched multiple candidates (re-call with sector_ids); 'ambiguous_locations' when free-text locations didn't resolve to one area \u2014 re-call with the chosen id via the SAME axis it came from (an include pick \u2192 location_ids; an EXCLUDE pick \u2192 exclude_locations, NOT location_ids, which would include it); 'lens_not_found' / 'ambiguous_lens' when a lensName didn't resolve to exactly one lens (re-call with lensId or an exact lensName).",
     properties: {
       status: {
         type: "string",
-        description: "'applied', 'ambiguous_sectors', 'lens_not_found', or 'ambiguous_lens'."
+        description: "'applied', 'ambiguous_sectors', 'ambiguous_locations', 'lens_not_found', or 'ambiguous_lens'."
       },
       sector_ambiguities: {
         type: "array",
         description: "Per ambiguous text: {sector_text, matches:[{id, name, score}]}. Agent picks an id and re-calls.",
         items: { type: "object" }
       },
+      location_ambiguities: {
+        type: "array",
+        description: "On 'ambiguous_locations': per text {location_text, matches:[{id, name, country, level, score}]}. Agent picks an id and re-calls via the SAME axis the text came from \u2014 an include text \u2192 location_ids; a text from exclude_locations \u2192 exclude_locations (NOT location_ids, which would include the area the user asked to exclude). The `message` field names the correct param per text.",
+        items: { type: "object" }
+      },
       lenses: {
         type: "array",
         description: "On 'lens_not_found': the user's lenses [{id, name}] to pick from.",
@@ -20619,9 +20799,45 @@ var adjustAudience = {
         message: parts.join(" ")
       };
     }
+    const includeLocTexts = [
+      ...params.locations ?? [],
+      ...params.location_ids ?? []
+    ];
+    const excludeLocTexts = params.exclude_locations ?? [];
+    const includeLocRes = await resolveLocations(client, includeLocTexts);
+    const excludeLocRes = await resolveLocations(client, excludeLocTexts);
+    const locAmbiguities = [
+      ...includeLocRes.ambiguities,
+      ...excludeLocRes.ambiguities
+    ];
+    if (locAmbiguities.length > 0) {
+      const incMatch = includeLocRes.ambiguities.filter((a) => a.matches.length > 0);
+      const incNone = includeLocRes.ambiguities.filter((a) => a.matches.length === 0);
+      const excMatch = excludeLocRes.ambiguities.filter((a) => a.matches.length > 0);
+      const excNone = excludeLocRes.ambiguities.filter((a) => a.matches.length === 0);
+      const quote = (as) => as.map((a) => `"${a.location_text}"`).join(", ");
+      const parts = [];
+      if (incNone.length > 0) {
+        parts.push(`Couldn't find a location matching ${quote(incNone)}. Ask the user to rephrase, then re-call with location_ids=...`);
+      }
+      if (incMatch.length > 0) {
+        parts.push(`${quote(incMatch)} matched multiple areas. Pick from the matches and re-call with location_ids=...`);
+      }
+      if (excNone.length > 0) {
+        parts.push(`Couldn't find a location to exclude matching ${quote(excNone)}. Ask the user to rephrase, then re-call with exclude_locations=... (the chosen id).`);
+      }
+      if (excMatch.length > 0) {
+        parts.push(`${quote(excMatch)} (to exclude) matched multiple areas. Pick from the matches and re-call with exclude_locations=... (the chosen id) \u2014 NOT location_ids, which would include it.`);
+      }
+      return {
+        status: "ambiguous_locations",
+        location_ambiguities: locAmbiguities,
+        message: parts.join(" ")
+      };
+    }
     const lens = await client.request("GET", `/lenses/${startingLensId}`);
     const currentFilter = await client.request("GET", `/lenses/${startingLensId}/filter`);
-    const merged = mergeFilter(currentFilter, includeRes.resolved, excludeRes.resolved, params.sizes);
+    const merged = mergeFilter(currentFilter, includeRes.resolved, excludeRes.resolved, params.sizes, includeLocRes.resolved, excludeLocRes.resolved);
     const mergedBody = filterWriteBody(merged);
     const isDefault = lens.is_default || lens.default;
     const isUserLevel = lens.user_id != null;
@@ -21344,6 +21560,16 @@ var newLens = {
         },
         description: "Company size buckets, e.g. [{min:30,max:300}]."
       },
+      locations: {
+        type: "array",
+        items: { type: "string" },
+        description: "Geographic scope \u2014 free text (e.g. ['Indre-et-Loire', 'Bavaria']) or admin-area ids. Auto-resolved via /geo/search across all admin levels (city / county / d\xE9partement / r\xE9gion / state / country). Scopes the lens to a sales territory."
+      },
+      exclude_locations: {
+        type: "array",
+        items: { type: "string" },
+        description: "Locations to exclude \u2014 free text or ids."
+      },
       base: {
         type: "number",
         description: "Lens id to clone from. Defaults to the active/default lens."
@@ -21359,12 +21585,12 @@ var newLens = {
   },
   outputSchema: {
     type: "object",
-    description: "'preview' (default, NOTHING created \u2014 confirm with the user then re-call with confirm:true); 'created' on success; 'ambiguous_sectors' when free-text sectors didn't resolve (re-call with sector ids \u2014 the lens was NOT created).",
+    description: "'preview' (default, NOTHING created \u2014 confirm with the user then re-call with confirm:true); 'created' on success; 'ambiguous_sectors' / 'ambiguous_locations' when free-text sectors / locations didn't resolve (re-call with ids \u2014 the lens was NOT created).",
     properties: {
-      status: { type: "string", description: "'preview', 'created', 'ambiguous_sectors', or 'orphan_created' (filter write failed + cleanup failed)." },
+      status: { type: "string", description: "'preview', 'created', 'ambiguous_sectors', 'ambiguous_locations', or 'orphan_created' (filter write failed + cleanup failed)." },
       will_create: {
         type: "object",
-        description: "On 'preview': what WILL be created \u2014 {name, description, sectors, exclude_sectors, sizes}. Nothing has been written yet."
+        description: "On 'preview': what WILL be created \u2014 {name, description, sectors, exclude_sectors, sizes, locations, exclude_locations}. Nothing has been written yet."
       },
       filter_preview: { type: "object", description: "On 'preview': the FilterPayload that would be applied." },
       lens: {
@@ -21376,6 +21602,11 @@ var newLens = {
         description: "On 'ambiguous_sectors': per text {sector_text, matches:[{id,name,score}]}.",
         items: { type: "object" }
       },
+      location_ambiguities: {
+        type: "array",
+        description: "On 'ambiguous_locations': per text {location_text, matches:[{id,name,country,level,score}]}. Re-call the chosen id via the SAME axis the text came from \u2014 an include text \u2192 locations; a text from exclude_locations \u2192 exclude_locations (NOT locations, which would include the area the user asked to exclude). The `message` field names the correct param per text.",
+        items: { type: "object" }
+      },
       filter_applied: { type: "object", description: "On 'created': the FilterPayload POSTed to the new lens." },
       message: { type: "string" },
       _meta: { type: "object" }
@@ -21402,7 +21633,38 @@ var newLens = {
         message: parts.join(" ")
       };
     }
-    const merged = mergeFilter(EMPTY_FILTER, includeRes.resolved, excludeRes.resolved, params.sizes);
+    const includeLocRes = await resolveLocations(client, params.locations ?? []);
+    const excludeLocRes = await resolveLocations(client, params.exclude_locations ?? []);
+    const locAmbiguities = [
+      ...includeLocRes.ambiguities,
+      ...excludeLocRes.ambiguities
+    ];
+    if (locAmbiguities.length > 0) {
+      const incMatch = includeLocRes.ambiguities.filter((a) => a.matches.length > 0);
+      const incNone = includeLocRes.ambiguities.filter((a) => a.matches.length === 0);
+      const excMatch = excludeLocRes.ambiguities.filter((a) => a.matches.length > 0);
+      const excNone = excludeLocRes.ambiguities.filter((a) => a.matches.length === 0);
+      const quote = (as) => as.map((a) => `"${a.location_text}"`).join(", ");
+      const parts = [];
+      if (incNone.length > 0) {
+        parts.push(`Couldn't find a location matching ${quote(incNone)}. Pick a known area and re-call via locations (lens not yet created).`);
+      }
+      if (incMatch.length > 0) {
+        parts.push(`${quote(incMatch)} matched multiple areas. Pick from the matches and re-call with the chosen id in locations.`);
+      }
+      if (excNone.length > 0) {
+        parts.push(`Couldn't find a location to exclude matching ${quote(excNone)}. Pick a known area and re-call via exclude_locations (lens not yet created).`);
+      }
+      if (excMatch.length > 0) {
+        parts.push(`${quote(excMatch)} (to exclude) matched multiple areas. Pick from the matches and re-call with the chosen id in exclude_locations \u2014 NOT locations, which would include it.`);
+      }
+      return {
+        status: "ambiguous_locations",
+        location_ambiguities: locAmbiguities,
+        message: parts.join(" ")
+      };
+    }
+    const merged = mergeFilter(EMPTY_FILTER, includeRes.resolved, excludeRes.resolved, params.sizes, includeLocRes.resolved, excludeLocRes.resolved);
     if (params.confirm !== true) {
       return {
         status: "preview",
@@ -21411,7 +21673,9 @@ var newLens = {
           description: params.description ?? null,
           sectors: includeRes.resolved,
           exclude_sectors: excludeRes.resolved,
-          sizes: merged.lens_filter.items[0].criteria.find((c) => c.type === "size") ?? null
+          sizes: merged.lens_filter.items[0].criteria.find((c) => c.type === "size") ?? null,
+          locations: includeLocRes.resolved,
+          exclude_locations: excludeLocRes.resolved
         },
         filter_preview: merged,
         message: `About to create "${params.name}". Confirm with the user, then re-call with confirm:true.`,
@@ -23750,7 +24014,7 @@ function parseWriteEnv(env = process.env) {
 }
 
 // src/http-server.ts
-var VERSION = true ? "0.23.5" : "0.0.0-dev";
+var VERSION = true ? "0.23.7" : "0.0.0-dev";
 var PORT = Number(process.env.PORT ?? 8080);
 var HOST = process.env.HOST ?? "0.0.0.0";
 var sseSessions = /* @__PURE__ */ new Map();