@leadbay/mcp 0.18.2 → 0.19.1

package/dist/bin.js

@@ -5134,6 +5134,7 @@ var init_composite_file_names = __esm({
       "leadbay_research_lead_by_id",
       "leadbay_research_lead_by_name_fuzzy",
       "leadbay_resolve_import_rows",
+      "leadbay_scan_portfolio_signals",
       "leadbay_seed_candidates",
       "leadbay_tour_plan"
     ]);
@@ -5439,7 +5440,7 @@ var init_notifications = __esm({
 });
 
 // ../core/dist/tool-descriptions.generated.js
-var leadbay_account_history, leadbay_account_status, leadbay_acknowledge_notification, leadbay_add_leads_to_campaign, leadbay_add_note, leadbay_adjust_audience, leadbay_agent_memory_capture, leadbay_agent_memory_recall, leadbay_agent_memory_review, leadbay_answer_clarification, leadbay_bulk_enrich_status, leadbay_bulk_qualify_leads, leadbay_campaign_call_sheet, leadbay_campaign_progression, leadbay_clear_selection, leadbay_clear_user_prompt, leadbay_create_campaign, leadbay_create_custom_field, leadbay_create_lens, leadbay_create_lens_draft, leadbay_create_topup_link, leadbay_deselect_leads, leadbay_discover_leads, leadbay_dislike_lead, leadbay_dismiss_clarification, leadbay_enrich_contacts, leadbay_enrich_titles, leadbay_extend_lens, leadbay_followups_map, leadbay_get_clarification, leadbay_get_contacts, leadbay_get_enrichment_job_titles, leadbay_get_epilogue_responses, leadbay_get_lead_activities, leadbay_get_lead_notes, leadbay_get_lead_profile, leadbay_get_lens_filter, leadbay_get_lens_scoring, leadbay_get_prospecting_actions, leadbay_get_quota, leadbay_get_selection_ids, leadbay_get_taste_profile, leadbay_get_user_prompt, leadbay_get_web_fetch, leadbay_import_and_qualify, leadbay_import_leads, leadbay_import_status, leadbay_launch_bulk_enrichment, leadbay_like_lead, leadbay_list_campaigns, leadbay_list_lenses, leadbay_list_locations, leadbay_list_mappable_fields, leadbay_list_sectors, leadbay_login, leadbay_my_lenses, leadbay_new_lens, leadbay_open_billing_portal, leadbay_pick_clarification, leadbay_prepare_outreach, leadbay_preview_bulk_enrichment, leadbay_promote_lens, leadbay_pull_followups, leadbay_pull_leads, leadbay_qualify_lead, leadbay_qualify_status, leadbay_recall_ordered_titles, leadbay_refine_prompt, leadbay_remove_epilogue, leadbay_remove_leads_from_campaign, leadbay_remove_pushback, leadbay_report_friction, leadbay_report_outreach, leadbay_research_lead_by_id, leadbay_research_lead_by_name_fuzzy, leadbay_resolve_import_rows, leadbay_seed_candidates, leadbay_select_leads, leadbay_set_active_lens, leadbay_set_epilogue_status, leadbay_set_pushback, leadbay_set_user_prompt, leadbay_tour_plan, leadbay_update_lens, leadbay_update_lens_filter;
+var leadbay_account_history, leadbay_account_status, leadbay_acknowledge_notification, leadbay_add_contact, leadbay_add_leads_to_campaign, leadbay_add_note, leadbay_adjust_audience, leadbay_agent_memory_capture, leadbay_agent_memory_recall, leadbay_agent_memory_review, leadbay_answer_clarification, leadbay_bulk_enrich_status, leadbay_bulk_qualify_leads, leadbay_campaign_call_sheet, leadbay_campaign_progression, leadbay_clear_selection, leadbay_clear_user_prompt, leadbay_create_campaign, leadbay_create_custom_field, leadbay_create_lens, leadbay_create_lens_draft, leadbay_create_topup_link, leadbay_deselect_leads, leadbay_discover_leads, leadbay_dislike_lead, leadbay_dismiss_clarification, leadbay_enrich_contacts, leadbay_enrich_titles, leadbay_extend_lens, leadbay_followups_map, leadbay_get_clarification, leadbay_get_contacts, leadbay_get_enrichment_job_titles, leadbay_get_epilogue_responses, leadbay_get_lead_activities, leadbay_get_lead_notes, leadbay_get_lead_profile, leadbay_get_lens_filter, leadbay_get_lens_scoring, leadbay_get_prospecting_actions, leadbay_get_quota, leadbay_get_selection_ids, leadbay_get_taste_profile, leadbay_get_user_prompt, leadbay_get_web_fetch, leadbay_import_and_qualify, leadbay_import_leads, leadbay_import_status, leadbay_launch_bulk_enrichment, leadbay_like_lead, leadbay_list_campaigns, leadbay_list_lenses, leadbay_list_locations, leadbay_list_mappable_fields, leadbay_list_sectors, leadbay_login, leadbay_my_lenses, leadbay_new_lens, leadbay_open_billing_portal, leadbay_pick_clarification, leadbay_pin_contact, leadbay_prepare_outreach, leadbay_preview_bulk_enrichment, leadbay_promote_lens, leadbay_pull_followups, leadbay_pull_leads, leadbay_qualify_lead, leadbay_qualify_status, leadbay_recall_ordered_titles, leadbay_refine_prompt, leadbay_remove_contact, leadbay_remove_epilogue, leadbay_remove_leads_from_campaign, leadbay_remove_pushback, leadbay_report_friction, leadbay_report_outreach, leadbay_research_lead_by_id, leadbay_research_lead_by_name_fuzzy, leadbay_resolve_import_rows, leadbay_scan_portfolio_signals, leadbay_seed_candidates, leadbay_select_leads, leadbay_set_active_lens, leadbay_set_epilogue_status, leadbay_set_pushback, leadbay_set_user_prompt, leadbay_tour_plan, leadbay_unpin_contact, leadbay_update_contact, leadbay_update_lens, leadbay_update_lens_filter;
 var init_tool_descriptions_generated = __esm({
   "../core/dist/tool-descriptions.generated.js"() {
     "use strict";
@@ -5673,6 +5674,45 @@ WHEN TO USE: immediately after you finish reviewing / revising in response to a
 WHEN NOT TO USE: before doing the revision work; for general "mark all read" sweeps (call once per notification id you've actually consumed).
 
 This tool MUTATES state. The caller (agent or human-in-the-loop) is responsible for confirming intent before invocation; the MCP server does not soft-prompt for confirmation. See \`annotations.destructiveHint\`.
+`;
+    leadbay_add_contact = `## WHEN TO USE
+
+Trigger phrases: "add a contact to this company", "add this person to <company>", "create a contact from this LinkedIn URL", "this company has no contacts \u2014 add one", "I found someone on LinkedIn, add them to <lead>".
+
+**Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
+
+Do NOT use for: "import these companies / a CSV of leads and qualify them" \u2192 \`leadbay_import_and_qualify\`; "get email/phone for a contact already on the company" \u2192 \`leadbay_enrich_titles\`; "remove / delete this contact" \u2192 \`leadbay_remove_contact\`.
+
+Prefer when: user wants to attach ONE known person to an already-identified company \u2014 pass the company's \`lead_id\` plus the person's name (+ optional linkedin_page/title/email/phone)
+
+Examples that SHOULD invoke this tool:
+- "Acme has no suggested contacts \u2014 add Jane Doe, VP Eng, here's her LinkedIn."
+- "Add this person I found on LinkedIn to that company."
+- "Create a contact for John Smith, CFO, on this lead."
+
+Examples that should NOT invoke this tool (sound similar, route elsewhere):
+- "Import these 40 domains from my CRM and qualify them."
+- "Get me the email for the contact already on this company."
+- "Remove that contact, it's the wrong person."
+
+## RENDER (quick)
+
+One-line confirmation: the contact's name + title now sits on the company.
+No table. If the contact has no email/phone yet, note it can be enriched.
+
+---
+
+Add a single contact (a person) to a known company \u2014 the in-conversation "create a contact" path. Use it when a rep has found someone (often just a LinkedIn URL) and wants them on an already-identified Leadbay company without leaving the chat.
+
+Pass the parent company's \`lead_id\` plus the person's \`first_name\` + \`last_name\`. Everything else is optional: \`job_title\`, \`linkedin_page\`, \`email\`, \`phone_number\`.
+
+Backend: \`POST /leads/{lead_id}/contacts\` \u2192 returns the created contact with its new \`id\`. This is the same direct endpoint the Leadbay web UI uses \u2014 one call, no import/qualify quota. (Distinct from \`leadbay_import_and_qualify\`, which is for importing *lists of companies*, not attaching a single person.)
+
+The created contact starts unenriched \u2014 if it has no email/phone, enrich it via \`leadbay_enrich_titles\`. The undo is \`leadbay_remove_contact\` (pass the returned \`contact.id\`).
+
+Returns \`{ added: true, lead_id, contact: { id, first_name, last_name, job_title, linkedin_page, email, phone_number, \u2026 } }\`.
+
+Requires: LEADBAY_MCP_WRITE=1 (MCP) or exposeWrite=true (OpenClaw).
 `;
     leadbay_add_leads_to_campaign = `## WHEN TO USE
 
@@ -5847,29 +5887,23 @@ Do not enumerate the affected leads \u2014 that's the job of \`leadbay_pull_lead
 
 ---
 
+---
+
 ## NEXT STEPS \u2014 after kicking off bulk qualification
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -6001,7 +6035,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 |---|---|---|
 | \`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 |
 | \`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) | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | \`{questions: [{question: "What next?", type: "single_select", options: [<2-4 short button labels>]}]}\`; max 3 questions per call |
+| \`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.
 
@@ -6093,6 +6127,8 @@ WHEN TO USE: after \`leadbay_list_campaigns\` (or when the user named a specific
 WHEN NOT TO USE: for cross-campaign pulse (use \`leadbay_list_campaigns\`); to drill into a lead's full timeline (use \`leadbay_get_lead_activities\` or \`leadbay_research_lead_by_id\`); to log outreach (\`leadbay_report_outreach\`).
 
 **Response**: \`{items, pagination, summary, _meta}\`. Use the \`summary\` for the one-line headline; use \`items\` for the per-lead table.
+
+---
 `;
     leadbay_clear_selection = `Clear the user's transient selection.
 
@@ -6300,7 +6336,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 |---|---|---|
 | \`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 |
 | \`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) | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | \`{questions: [{question: "What next?", type: "single_select", options: [<2-4 short button labels>]}]}\`; max 3 questions per call |
+| \`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.
 
@@ -6337,7 +6373,7 @@ Examples that should NOT invoke this tool (sound similar, route elsewhere):
 
 \`queued\` \u2192 \u2705 "Queued <N> extra leads on lens <id>. Pull in ~30s." Do NOT
 list \`accepted_seeds\`; they're internal.
-\`quota_exceeded\` \u2192 render three options via \`ask_user_input_v0\` (smaller
+\`quota_exceeded\` \u2192 render three options via your host's choice widget (\`ask_user_input_v0\` or \`AskUserQuestion\`) (smaller
 count / wait until reset / upgrade).
 \`refresh_in_progress\` \u2192 "lens is filling, retry in a minute".
 \`no_valid_seeds\` \u2192 silently re-call \`leadbay_seed_candidates\`, retry once.
@@ -6355,7 +6391,7 @@ Queue an additive extra-refill on a lens \u2014 more leads on the same criteria,
 **Status envelope (translated from raw API errors so the agent routes on \`status\`).**
 
 - \`status: "queued"\` \u2014 fill is queued. \`accepted_seeds\` lists IDs that passed validation. NEXT STEP: call \`leadbay_pull_leads\` in ~30s.
-- \`status: "quota_exceeded"\` \u2014 daily LENS_EXTRA_REFILL hit. Response carries \`quota: {used_today, resets_at}\` + a \`message\` to surface. **Render three options via \`ask_user_input_v0\`**: (1) smaller \`extra_count\`, (2) wait until \`resets_at\`, (3) upgrade plan (TIER1=150, TIER2=1000). Do NOT silently retry.
+- \`status: "quota_exceeded"\` \u2014 daily LENS_EXTRA_REFILL hit. Response carries \`quota: {used_today, resets_at}\` + a \`message\` to surface. **Render three options via your host's choice widget (\`ask_user_input_v0\` or \`AskUserQuestion\`)**: (1) smaller \`extra_count\`, (2) wait until \`resets_at\`, (3) upgrade plan (TIER1=150, TIER2=1000). Do NOT silently retry.
 - \`status: "refresh_in_progress"\` \u2014 a refresh or extra-refill is already running. Tell the user to wait and call \`leadbay_pull_leads\` in ~30s.
 - \`status: "no_valid_seeds"\` \u2014 seeds went stale. Silently re-call \`leadbay_seed_candidates\` and retry once; only surface to the user if the second attempt also fails.
 
@@ -6370,27 +6406,19 @@ This tool MUTATES state. The caller (agent or human-in-the-loop) is responsible
 
 ## NEXT STEPS \u2014 after \`leadbay_extend_lens\`
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -6533,7 +6561,7 @@ Never link a person's name to the company's LinkedIn page (and vice versa) \u201
 
 Open with **one short intro sentence** in chat ("Five lead visits across NYC for your trip next week \u2014 three in Midtown, plus Long Island and one in NJ.") and then invoke the widget, then the chat-side list above. **No markdown table.**
 
-**After the widget renders, end the turn with the NEXT STEPS surface** \u2014 not with a prose question. See "GATE \u2014 PREFER BUILT-IN HOST WIDGETS" below: surface 2\u20134 mutually-exclusive moves via \`ask_user_input_v0\` if the host exposes it, else as a short bulleted list. "Want me to plot these on a map or jump to outreach for Atlas?" is exactly the prose pattern to AVOID \u2014 it's a \`single_select\` with two options.
+**After the widget renders, end the turn with the NEXT STEPS surface** \u2014 not with a prose question. See "GATE \u2014 PREFER BUILT-IN HOST WIDGETS" below: surface 2\u20134 mutually-exclusive moves via your host's choice widget (\`ask_user_input_v0\` or \`AskUserQuestion\`) if the host exposes it, else as a short bulleted list. "Want me to plot these on a map or jump to outreach for Atlas?" is exactly the prose pattern to AVOID \u2014 it's a \`single_select\` with two options.
 
 ## RENDER \u2014 fallback for hosts without \`places_map_display_v0\`
 
@@ -6564,7 +6592,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 |---|---|---|
 | \`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 |
 | \`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) | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | \`{questions: [{question: "What next?", type: "single_select", options: [<2-4 short button labels>]}]}\`; max 3 questions per call |
+| \`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.
 
@@ -6709,27 +6737,19 @@ Defer the full list of imported leads to \`leadbay_pull_leads\` or \`leadbay_res
 
 ## NEXT STEPS \u2014 after an import
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -6782,27 +6802,19 @@ Defer the full list of imported leads to \`leadbay_pull_leads\` or \`leadbay_res
 
 ## NEXT STEPS \u2014 after an import
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -6942,6 +6954,8 @@ WHEN TO USE: the user wants the cross-campaign pulse \u2014 what cohorts are in
 WHEN NOT TO USE: for per-lead progression inside ONE campaign (use \`leadbay_campaign_progression\`); to create a campaign (\`leadbay_create_campaign\`); to add leads to one (\`leadbay_add_leads_to_campaign\`).
 
 **Response**: \`{campaigns: CampaignWithStats[], _meta}\`. Sort by \`updated_at desc\` when rendering \u2014 recency is the manager's natural lens.
+
+---
 `;
     leadbay_list_lenses = `List all available Leadbay lenses (saved lead-search configurations). Each lens defines a different target market or buyer segment. The lens with \`is_last_active=true\` is used by default for lead discovery.
 
@@ -7068,7 +7082,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 |---|---|---|
 | \`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 |
 | \`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) | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | \`{questions: [{question: "What next?", type: "single_select", options: [<2-4 short button labels>]}]}\`; max 3 questions per call |
+| \`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.
 
@@ -7107,27 +7121,19 @@ render an empty table.
 
 ## NEXT STEPS \u2014 after \`leadbay_my_lenses\`
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -7205,7 +7211,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 |---|---|---|
 | \`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 |
 | \`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) | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | \`{questions: [{question: "What next?", type: "single_select", options: [<2-4 short button labels>]}]}\`; max 3 questions per call |
+| \`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.
 
@@ -7220,27 +7226,19 @@ ChatGPT exposes the same routing pattern via \`_meta.openai/outputTemplate\`. We
 
 ## NEXT STEPS \u2014 after \`leadbay_new_lens\`
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -7279,6 +7277,42 @@ WHEN TO USE: low-level.
 WHEN NOT TO USE: from agent flow \u2014 use leadbay_answer_clarification.
 
 This tool MUTATES state. The caller (agent or human-in-the-loop) is responsible for confirming intent before invocation; the MCP server does not soft-prompt for confirmation. See \`annotations.destructiveHint\`.
+`;
+    leadbay_pin_contact = `## WHEN TO USE
+
+Trigger phrases: "pin this contact", "mark this person as priority", "make this the main contact", "favourite this contact".
+
+**Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
+
+Do NOT use for: "unpin / remove the pin" \u2192 \`leadbay_unpin_contact\`; "add a contact to this company" \u2192 \`leadbay_add_contact\`; "remove / delete this contact" \u2192 \`leadbay_remove_contact\`.
+
+Prefer when: user wants ONE person flagged as the priority on a company \u2014 pass that contact's own \`contact_id\`
+
+Examples that SHOULD invoke this tool:
+- "Pin Jane Doe as the main contact on this company."
+- "Mark this person as the priority contact."
+- "Favourite that contact so it shows first."
+
+Examples that should NOT invoke this tool (sound similar, route elsewhere):
+- "Add a contact to this company."
+- "Remove that contact, wrong person."
+- "Stop showing me this lead."
+
+## RENDER (quick)
+
+One-line confirmation that the named contact (or id) is now pinned. No table.
+
+---
+
+Pin a single contact on a company so it surfaces first as a priority / favourite. Use when the user wants to flag a specific person as the one to focus on.
+
+Pass the contact's **own** \`contact_id\` (the \`id\` field on a contact object from \`leadbay_research_lead_by_id\` or a contacts list) \u2014 **not** the parent lead id.
+
+Backend: \`POST /contacts/{contact_id}/pin\` \u2192 204. Idempotent. The inverse is \`leadbay_unpin_contact\`.
+
+Returns \`{ pinned: true, contact_id, action: "pinned" }\`.
+
+Requires: LEADBAY_MCP_WRITE=1 (MCP) or exposeWrite=true (OpenClaw).
 `;
     leadbay_prepare_outreach = `## WHEN TO USE
 
@@ -7309,7 +7343,7 @@ 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\` (other contacts at this company), 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\` (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.
 
 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\`.
 
@@ -7326,46 +7360,9 @@ WHEN NOT TO USE: across many leads \u2014 use leadbay_enrich_titles for bulk; fo
 
 ## RENDER \u2014 host-native message composer is the PRIMARY surface
 
-\`message_compose_v1\` is the canonical surface for outreach drafts on this tool. The composer gives the user inline edit + send affordances and beats any prose code-fenced draft. **If the host exposes \`message_compose_v1\`, route every draft through it.** Don't paste email body or call-opener body into chat prose alongside \u2014 the composer IS the visual.
+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.
 
-Above the composer, emit ONE short markdown context paragraph: the lead's score callout + sector fit + recommended-contact name (LinkedIn-markdown-linked) + bare phone/email pills. That gives the user the "why this lead" context. The composer below carries the actionable draft.
-
-**Single draft:**
-
-\`\`\`
-message_compose_v1({
-  kind: "email",
-  summary_title: "Outreach to <Contact Name> at <Company>",
-  variants: [{
-    label: "Lead with the M&A signal",
-    subject: "<one-line subject \u2014 references the angle>",
-    body: "<5-8 sentence email; salesperson voice; references signal + a clear next step>"
-  }]
-})
-\`\`\`
-
-**Strategic options (preferred when split_ai_summary surfaces multiple angles):**
-
-\`\`\`
-message_compose_v1({
-  kind: "email",
-  summary_title: "Three angles for <Company> outreach",
-  variants: [
-    { label: "Push for alignment",  subject: "...", body: "..." },
-    { label: "Reference the M&A signal", subject: "...", body: "..." },
-    { label: "Soft intro \u2014 peer reference", subject: "...", body: "..." }
-  ]
-})
-\`\`\`
-
-Constraints:
-- **Labels describe STRATEGY, not tone.** "Push for alignment", "Reference M&A signal", "Lead with peer reference" \u2014 not "Friendly" / "Formal" / "Aggressive".
-- **2\u20133 variants when strategic options are clearly distinct.** One variant when you have a single best-angle draft.
-- Subject required for \`kind: "email"\`. Phone/call openers use \`kind: "other"\` with the opener in \`body\`.
-
-The composer becomes the single visual. **Don't also paste the email body into chat prose** \u2014 that's just noise next to the composer.
-
-For phone-only contacts (no email enriched), use \`kind: "other"\` with a 60-second call opener.
+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\`.
 
 ## GATE \u2014 PREFER BUILT-IN HOST WIDGETS
 
@@ -7377,7 +7374,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 |---|---|---|
 | \`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 |
 | \`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) | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | \`{questions: [{question: "What next?", type: "single_select", options: [<2-4 short button labels>]}]}\`; max 3 questions per call |
+| \`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.
 
@@ -7458,27 +7455,19 @@ When the response carries \`social_urls\` (the post-fix multi-platform URL block
 
 ## NEXT STEPS \u2014 after the outreach brief
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -7498,7 +7487,6 @@ Offer 2\u20133 follow-ups. Choose based on enrichment state + available channels
 | User reports they reached out                   | "Log this outreach \u2014 creates prospecting action + outcome"    | leadbay_report_outreach(leadId, contact_id, ...)       |
 | User adds context for next time                 | "Save a note on the contact or company"                       | leadbay_add_note                                       |
 | After a successful exchange                     | "Update qualification answers based on what you learned"      | leadbay_answer_clarification                           |
-
 The "log outreach" step is the most-important follow-up \u2014 it closes the loop and populates history for the next \`leadbay_prepare_outreach\` call. Detect intent from natural language: "I sent the email", "she didn't pick up", "left a voicemail", "they responded yes/no", etc.
 `;
     leadbay_preview_bulk_enrichment = `Preview a bulk-enrichment cost given a set of job titles applied to the current selection. Returns \`{selected_leads, enriched_contacts, enrichable_contacts, title_suggestions, auto_included_titles, previously_enriched_titles}\`. \`previously_enriched_titles\` is a newer field (in prod soon) \u2014 when present, the agent can recommend repeating those titles for new leads.
@@ -7549,9 +7537,9 @@ table. Detail + status priority below.
 
 Pull KNOWN leads from the user's Monitor view \u2014 the re-engagement entry point. Use when the user asks "what should I follow up on", "leads I haven't contacted", "leads in [city]", "before my trip", or any phrasing implying pre-existing pipeline context. For NEW leads from Discover, use \`leadbay_pull_leads\`.
 
-Backend: wraps \`GET /1.5/monitor?personal=&liked=&filtered=&count=&page=\` plus, when \`set_filter\` is supplied, a preceding \`POST /1.5/monitor/filter\` to persist the filter server-side. The Monitor filter is a single \`FilterItem\` per user \u2014 refreshing the page restores it.
+Backend: wraps \`GET /1.5/monitor?personal=&liked=&filtered=&count=&page=\` plus, when \`set_filter\` is supplied, a preceding \`POST /1.5/monitor/filter\`. The Monitor filter is a single \`FilterItem\` per user \u2014 refreshing restores it.
 
-**Filter mechanism \u2014 store-then-apply.** Pass \`set_filter: { criteria: FilterCriterion[] }\` to overwrite the server-stored filter, then the composite re-fetches with \`filtered:true\`. \`FilterCriterion\` is the backend's \`anyOf\` over 10 typed criteria: \`size\`, \`keywords\`, \`sector_ids\`, \`location_ids\`, \`custom_field\`, \`custom_field_comparison\`, \`yc\`, \`liked\`, \`last_action\` (filters by MonitorActionType enum), \`last_action_date\` (with \`last_days\` for "last N days").
+**Filter mechanism \u2014 store-then-apply.** Pass \`set_filter: { criteria: FilterCriterion[] }\` to overwrite the server-stored filter, then the composite re-fetches with \`filtered:true\`. \`FilterCriterion\` is the backend's \`anyOf\` over 10 typed criteria: \`size\`, \`keywords\`, \`sector_ids\`, \`location_ids\`, \`custom_field\`(\`_comparison\`), \`yc\`, \`liked\`, \`last_action\` (MonitorActionType enum), \`last_action_date\` (with \`last_days\`).
 
 Practical mapping from user phrasing to criterion:
 
@@ -7564,11 +7552,11 @@ Practical mapping from user phrasing to criterion:
 | "leads 50\u2013200 employees"             | \`{type: "size", sizes: [{min: 50, max: 200}]}\`                       |
 | "Y Combinator companies"             | \`{type: "yc"}\`                                                       |
 
-Geo filtering needs \`admin_area_id\` resolution \u2014 backend rejects free-text in \`location_ids\`. Pass \`city: "<free-text>"\` and the composite calls \`/geo/search\` internally, picks the best match, merges its id into \`set_filter\`. Ambiguous matches return \`status: "ambiguous_locations"\` + \`location_ambiguities[]\` \u2014 pick an id and re-call with \`city_id\`. For multi-city cases, call \`leadbay_list_locations\` then pass \`set_filter.criteria\` with \`{type: "location_ids", is_excluded: false, locations: [...]}\`.
+Geo filtering needs \`admin_area_id\` resolution \u2014 backend rejects free-text in \`location_ids\`. Pass \`city: "<free-text>"\` and the composite calls \`/geo/search\` internally, picks the best match, merges its id into \`set_filter\`. Ambiguous matches return \`status: "ambiguous_locations"\` + \`location_ambiguities[]\` \u2014 pick an id and re-call with \`city_id\`.
 
-**Place names go through \`city\`, NEVER \`keywords\`.** This includes any geographic token the user names \u2014 cities (\`"Berlin"\`, \`"NYC"\`), states / provinces / regions (\`"Texas"\`, \`"California"\`, \`"Bavaria"\`), countries (\`"France"\`, \`"United States"\`), neighborhoods (\`"Brooklyn"\`, \`"SoHo"\`). The \`/geo/search\` resolver handles all admin levels \u2014 level 4 (state) and level 2 (country) resolve just as well as level 5 (city). If you put \`"Texas"\` in \`keywords\` you get a TEXT-MATCH against company descriptions (\u22480 hits) instead of a real state filter. If a place name resolves ambiguously, surface the choices to the user \u2014 do NOT silently fall back to keyword search or to the unfiltered Monitor view. If \`keywords: ["Texas"]\` returned empty, the next call is \`city: "Texas"\`, not \`keywords: []\`.
+**Place names go through \`city\`, NEVER \`keywords\`.** Any geographic token the user names \u2014 cities (\`"Berlin"\`), states/regions (\`"Texas"\`, \`"Bavaria"\`), countries (\`"France"\`), neighborhoods (\`"Brooklyn"\`) \u2014 resolves via \`/geo/search\` (all admin levels). A place name in \`keywords\` becomes a TEXT-MATCH against company descriptions (\u22480 hits), not a real filter. If a place resolves ambiguously, surface the choices \u2014 never silently fall back to keyword search or the unfiltered view.
 
-**Pushback exclusion.** Leads with active pushback (\`pushback_status\` set and \`pushback_until > today\`) are excluded from the response. The composite enforces this client-side; \`total_excluded_by_pushback\` in the output reports how many rows were dropped.
+**Pushback exclusion.** Leads with active pushback (\`pushback_status\` set, \`pushback_until > today\`) are excluded client-side; \`total_excluded_by_pushback\` reports how many rows were dropped.
 
 WHEN TO USE: re-engaging pipeline ("what should I follow up on", "stale leads"), filtering monitored leads by city / sector / recency / action type / liked. The canonical orchestrator is the \`leadbay_followup_check_in\` prompt.
 
@@ -7576,6 +7564,16 @@ WHEN NOT TO USE: for NEW leads \u2014 that's \`leadbay_pull_leads\` (Discover).
 
 **Anti-confusion guardrail.** Iterating \`pull_leads\` pages looking for \`prospecting_actions_count > 0\` or \`notes_count > 0\` rows is the wrong entry point \u2014 the two read different tables. Leads with follow-up history live in \`pull_followups\`.
 
+**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.
+
+
 ---
 
 ## RENDERING \u2014 follow-ups table, status-badge driven
@@ -7662,27 +7660,19 @@ When the response carries \`social_urls\` (the post-fix multi-platform URL block
 
 ## NEXT STEPS \u2014 after the follow-ups table
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -7703,7 +7693,6 @@ Always include at least one filter-modification offer (users think in filters: b
 | User wants to defer a lead                    | "Snooze [Company] for 3 / 6 / 12 months"                 | leadbay_set_pushback({ lead_ids:[leadId], status:"3" })                                            |
 | User completed outreach mid-flow              | "Log the outreach + record the outcome"                  | leadbay_report_outreach                                                                            |
 | Discovery mode might fit better               | "Looking for NEW leads instead? Switch to discovery."    | leadbay_pull_leads                                                                                 |
-
 Always offer at least one of: prep outreach, refilter, pushback. Pushback is the canonical way to honor "not now" / "next quarter" \u2014 leads with active pushback are excluded from this view until expiry.
 `;
     leadbay_pull_leads = `## WHEN TO USE
@@ -7830,27 +7819,19 @@ When the response carries \`social_urls\` (the post-fix multi-platform URL block
 
 ## NEXT STEPS \u2014 after rendering the pull_leads table
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -7860,6 +7841,7 @@ Pick 2\u20133 items below based on what was actually observed in the response. T
 
 | Observation                                                | Suggest                                                      | Calls                                                  |
 |------------------------------------------------------------|--------------------------------------------------------------|--------------------------------------------------------|
+| \u2265 5 leads returned (any batch)                             | "Build an interactive lead triage board for this batch"      | emit antArtifact from data in hand (do NOT re-call leadbay_pull_leads) |
 | \`has_more == true\`                                         | "Pull the next page (page N+1 of M)"                         | leadbay_pull_leads(page = current + 1, lensId = pinned)|
 | \u2265 3 rows have \`qualification_summary.answered == 0\`        | "Deepen AI qualification on the rows without \u2756 caps"         | leadbay_bulk_qualify_leads(leadIds=[\u2026])                |
 | User points at a single row                                | "Research [Company] in depth"                                | leadbay_research_lead_by_id(leadId)                    |
@@ -7870,7 +7852,7 @@ Pick 2\u20133 items below based on what was actually observed in the response. T
 | Top row has contacts but no phone/email                    | "Order contact enrichment to surface email/phone first"      | leadbay_enrich_titles(...) or leadbay_prepare_outreach(leadId, enrich:true) |
 | \`computing_scores == true\` or \`computing_wishlist == true\` | "Scores are still being computed \u2014 re-pull in ~30s"          | leadbay_pull_leads (retry with same lensId)            |
 | User wants a narrower / wider audience                     | "Adjust the lens filters (sector / size)"                    | leadbay_adjust_audience(...)                           |
-
+| Phase 4 research was run (\`research_lead_by_id\` called) AND top contacts lack direct email/phone | "Enrich contacts on [Lead1], [Lead2] to get direct emails and phone numbers" | leadbay_enrich_contacts(leadId, contactId) \u2014 ONE call per contact (the tool takes a single leadId + contactId, never a list) |
 If nothing in the menu applies cleanly, suggest only "pull next page" and "research a specific lead in depth" \u2014 never invent a tool that doesn't exist.
 `;
     leadbay_qualify_lead = `Trigger AI qualification for a single lead (web fetch + AI rescore). The operation is asynchronous \u2014 results take ~60s. \`forceFetch:true\` re-runs even if recent data exists.
@@ -7926,6 +7908,43 @@ WHEN TO USE: when audience filters (leadbay_adjust_audience) aren't enough.
 WHEN NOT TO USE: to answer a pending clarification \u2014 that's leadbay_answer_clarification.
 
 This tool MUTATES state. The caller (agent or human-in-the-loop) is responsible for confirming intent before invocation; the MCP server does not soft-prompt for confirmation. See \`annotations.destructiveHint\`.
+`;
+    leadbay_remove_contact = `## WHEN TO USE
+
+Trigger phrases: "remove this contact", "delete this contact", "take this person off the company", "that contact is wrong \u2014 get rid of it", "undo the contact I just added".
+
+**Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
+
+Do NOT use for: "add a contact to this company" \u2192 \`leadbay_add_contact\`; "stop showing me this lead / not interested" \u2192 \`leadbay_dislike_lead\`.
+
+Prefer when: user wants a specific PERSON gone from a company \u2014 pass that contact's own \`contact_id\` (from a contacts list), not the lead id
+
+Examples that SHOULD invoke this tool:
+- "Remove Jane Doe from that company \u2014 I added her by mistake."
+- "Delete this contact, it's the wrong person."
+- "Undo the contact I just added to Acme."
+
+Examples that should NOT invoke this tool (sound similar, route elsewhere):
+- "Stop showing me this lead."
+- "Add a contact to this company."
+- "Show me today's leads."
+
+## RENDER (quick)
+
+One-line confirmation: name the contact (or id) and that it was removed
+from the company. No table.
+
+---
+
+Remove a single contact from a company by archiving it. This is the **undo** for the add-a-contact path (\`leadbay_add_contact\`) \u2014 when a rep adds the wrong person, or finds a stale contact, this takes them off the company.
+
+Pass the contact's **own** \`contact_id\` \u2014 the \`id\` field on a contact object returned by \`leadbay_research_lead_by_id\` or the contacts list. **Not** the parent lead id; the archive endpoint is keyed by the contact directly.
+
+Backend: \`POST /contacts/{contact_id}/archive\` \u2192 204. Archive is a **soft-delete** \u2014 the contact leaves the company's active contact list (the same action the Leadbay web UI's contact "delete" fires). Idempotent: archiving an already-archived contact is a no-op.
+
+Returns \`{ archived: true, contact_id, action: "archived" }\`.
+
+Requires: LEADBAY_MCP_WRITE=1 (MCP) or exposeWrite=true (OpenClaw).
 `;
     leadbay_remove_epilogue = `Bulk-clear the epilogue status from a set of leads.
 
@@ -8055,7 +8074,7 @@ Trigger phrases: "tell me about this lead", "deep dive on the lead I just picked
 
 **Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
 
-Do NOT use for: "company name without lead id" \u2192 \`leadbay_research_lead_by_name_fuzzy\`; "draft outreach for <Contact>" \u2192 \`leadbay_prepare_outreach\`.
+Do NOT use for: "company name without lead id" \u2192 \`leadbay_research_lead_by_name_fuzzy\`; "draft outreach for <Contact>" \u2192 \`leadbay_prepare_outreach\`; "add a contact to this company" \u2192 \`leadbay_add_contact\`.
 
 Prefer when: user picked a row and you have its UUID; pass \`leadId\`
 
@@ -8070,42 +8089,46 @@ Examples that should NOT invoke this tool (sound similar, route elsewhere):
 ---
 
 Tell me everything decision-relevant about a single lead, identified by its
-Leadbay UUID. Bundles the lens-scoped lead profile, the AI qualification
-answers (the agent's knowledge-base food), the structured web-research signals
-(with hot flags + sources), the two-tier contact set (\`enriched\` + \`org\`), the
-unified \`recent_activities\` timeline, the engagement counts, and a
-\`_meta.has_reachable_contact\` hint that drives NEXT STEPS. Order is
-deliberate: qualification first, then signals, then firmographics, then
-contacts, then recent activity.
-
-Scoring has two layers: the basic \`score\` (firmographic, always present,
-already decent) and the AI qualification layer (\`ai_agent_lead_score\` +
-per-question answers + web_fetch signals). The AI layer is pre-populated for
-roughly the top 10 of each daily batch, and on-demand (via
-leadbay_bulk_qualify_leads) for anything below that. Combine both layers when
-judging a lead.
-
-The companion tool **leadbay_research_lead_by_name_fuzzy** wraps this one for
-the case where the user names a company in prose without a UUID \u2014 it
-fuzzy-resolves the name against the active lens's wishlist, then delegates
-here. Both return the same shape; the fuzzy wrapper just adds
-\`_meta.resolved_from\` and \`_meta.match_candidates\` so you can offer
-disambiguation.
+Leadbay UUID. Bundles the lens-scoped profile, AI qualification answers,
+structured web-research signals (hot flags + sources), the two-tier contact set
+(\`enriched\` + \`org\`), the unified \`recent_activities\` timeline, engagement
+counts, and a \`_meta.has_reachable_contact\` hint that drives NEXT STEPS. Order
+is deliberate: qualification, signals, firmographics, contacts, recent activity.
+
+Scoring has two layers: the basic \`score\` (firmographic, always present) and
+the AI qualification layer (\`ai_agent_lead_score\` + per-question answers +
+web_fetch signals). The AI layer is pre-populated for roughly the top 10 of
+each daily batch, and on-demand (via leadbay_bulk_qualify_leads) below that.
+Combine both when judging a lead.
+
+The companion **leadbay_research_lead_by_name_fuzzy** wraps this one when the
+user names a company without a UUID: it fuzzy-resolves against the active
+lens's wishlist, then delegates here. Same shape, plus \`_meta.resolved_from\` /
+\`_meta.match_candidates\`.
 
 WHEN TO USE: when picking up a single lead from
 leadbay_pull_leads (or any list that exposed a leadId) to decide whether to
 act on it.
 
 WHEN NOT TO USE: across many leads at once \u2014 that's
-leadbay_pull_leads' job. (This composite supersedes the lower-level
-leadbay_get_lead_profile in agent flow; the granular tool stays available for
-fine-grained access.)
-
-**Concurrency note**: this is a composite that reads many sub-resources per
-call. Call it **sequentially** or in small batches (\u22643 parallel) when
-researching multiple leads. Firing 10+ in parallel can saturate the transport
-and produce misleading \`"Tool permission stream closed"\` errors that look like
-permission failures but are really backpressure. On a transient
+leadbay_pull_leads' job (portfolio-wide signal questions go to
+leadbay_scan_portfolio_signals; see below). This composite supersedes the
+lower-level leadbay_get_lead_profile.
+
+**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.
+
+
+**Concurrency note**: this composite reads many sub-resources per call. Call
+it **sequentially or in small batches (\u22643 parallel)**. Firing 10+ in parallel
+saturates the transport and produces misleading \`"Tool permission stream
+closed"\` errors \u2014 that's backpressure, not a permission failure. On a transient
 stream/timeout failure, retry the same lead once before moving on.
 
 ---
@@ -8184,27 +8207,19 @@ When the response carries \`social_urls\` (the post-fix multi-platform URL block
 
 ## NEXT STEPS \u2014 after the research card
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -8249,6 +8264,7 @@ out?"\`
 
 | Observation                                            | Suggest                                                  | Calls                                                          |
 |--------------------------------------------------------|----------------------------------------------------------|----------------------------------------------------------------|
+| Lead is clearly not a fit (wrong industry, too small)  | "Dislike this lead"                                      | leadbay_dislike_lead({ leadId })                               |
 | User is done with this lead                            | "Back to the inbox"                                      | leadbay_pull_leads                                             |
 `;
     leadbay_research_lead_by_name_fuzzy = `## WHEN TO USE
@@ -8372,27 +8388,19 @@ When the response carries \`social_urls\` (the post-fix multi-platform URL block
 
 ## NEXT STEPS \u2014 after the research card
 
-**RENDER NEXT STEPS via \`ask_user_input_v0\` when the host exposes it.**
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
 
-The (Observation, Suggest, Calls) table below is the source of truth for which moves are valid. Pick the 2\u20134 most relevant rows based on what the response actually contains, then surface them as a \`single_select\` quick-select widget:
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
 
-\`\`\`
-ask_user_input_v0({
-  questions: [{
-    question: "What next?",
-    type: "single_select",
-    options: [
-      "<Suggest column from row 1>",
-      "<Suggest column from row 2>",
-      "<Suggest column from row 3>"
-    ]
-  }]
-})
-\`\`\`
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
 
-When the user picks an option, you call the matching tool from the \`Calls\` column. Constraints carried over from the widget contract: 2\u20134 mutually-exclusive options per question, button-sized labels (\u22646 words), max 3 questions per call.
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
 
-**Fallback prose mode** \u2014 when the host doesn't expose \`ask_user_input_v0\` (or it returned an error): surface the same 2\u20133 picks as a short bulleted list of "Suggest" phrasings. The table itself stays internal; never recite the whole table to the user.
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
 
 ---
 
@@ -8437,6 +8445,7 @@ out?"\`
 
 | Observation                                            | Suggest                                                  | Calls                                                          |
 |--------------------------------------------------------|----------------------------------------------------------|----------------------------------------------------------------|
+| Lead is clearly not a fit (wrong industry, too small)  | "Dislike this lead"                                      | leadbay_dislike_lead({ leadId })                               |
 | User is done with this lead                            | "Back to the inbox"                                      | leadbay_pull_leads                                             |
 
 
@@ -8483,6 +8492,178 @@ Below the table, a one-liner: \`"Ready: K rows \xB7 Ambiguous: A rows \xB7 Unmat
 | Ambiguous rows present                 | "Inspect candidates for each ambiguous row"                 | (re-call with include_candidate_profiles=true)         |
 | Unmatched rows but websites present    | "Import anyway \u2014 Leadbay will crawl and match later"        | leadbay_import_leads (status check after)              |
 | User wants to skip rows they can't ID  | "Drop unmatched rows and import the rest"                   | leadbay_import_leads (with filtered records)           |
+`;
+    leadbay_scan_portfolio_signals = `## WHEN TO USE
+
+Trigger phrases: "which of my leads <did X>", "find leads that <raised / acquired / hired / moved / changed CEO>", "scan my portfolio for <signal>", "identify all the ones that <event> since <date>", "who in Monitor has a <funding / M&A / hiring> signal", "build a campaign from leads with <signal>".
+
+**Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
+
+Do NOT use for: "research one named company" \u2192 \`leadbay_research_lead_by_name_fuzzy\`; "everything about lead <UUID>" \u2192 \`leadbay_research_lead_by_id\`; "qualify my next N leads (they aren't researched yet)" \u2192 \`leadbay_bulk_qualify_leads\`; "just list my follow-ups" \u2192 \`leadbay_pull_followups\`.
+
+Prefer when: user wants to FILTER a known portfolio by a web-research signal in bulk \u2014 pass \`query\`, optionally \`since\`, \`city\`/\`set_filter\`, or \`leadIds\`
+
+Examples that SHOULD invoke this tool:
+- "Which of my leads acquired a company since 2025?"
+- "Scan my Lyon portfolio for funding signals."
+- "Find everyone in Monitor who changed CEO and build a campaign."
+
+Examples that should NOT invoke this tool (sound similar, route elsewhere):
+- "Look up Acme Corp for me."
+- "Show me my follow-ups."
+- "Qualify my next 10 leads."
+
+## RENDER (quick)
+
+Cohort grouped by lead: one block per matched lead (name \xB7 location +
+its matched signal entries, hot first, source-linked). Open with
+"N match <query> (M scanned)"; ALWAYS close with an honesty footer \u2014
+"scanned N \xB7 matched M \xB7 K not yet researched". Never present
+not_researched leads as "no signal". Full layout below.
+
+---
+
+Scan a known portfolio for a specific web-research signal in one call. This is
+the bulk, read-only answer to "which of my leads have signal X" \u2014 the question
+that otherwise forces a per-lead \`leadbay_research_lead_by_id\` loop (one full
+profile call per lead, slow and quota-heavy).
+
+**Reads CACHED signals only \u2014 does not trigger new research.** For each lead in
+scope it reads \`GET /leads/{id}/web_fetch\` (the already-computed web-research
+signals) and filters the entries against \`query\`. It issues NO web_fetch POST,
+so it does not consume AI qualification credits and does not re-crawl. Leads
+that have no cached content (never qualified, or still in progress) are
+reported in \`not_researched\` \u2014 they are **NOT** silently treated as "no
+match". Qualify them with \`leadbay_bulk_qualify_leads\`, then re-scan.
+
+**Scope.** Pass \`leadIds\` for an explicit cohort, or omit it to scan the
+Monitor portfolio. Narrow the Monitor scope with \`city\` / \`set_filter\` exactly
+as \`leadbay_pull_followups\` does (store-then-apply server-side filter). The
+scan is bounded by \`max_leads\` (default 200, hard cap 300); when the portfolio
+is larger, \`truncated_at\` is set and coverage is partial \u2014 say so.
+
+**Query.** \`query\` is matched case- and accent-insensitively against each
+signal entry's description, source, and section label. Comma- or
+space-separated terms are OR'd ("M&A, acquisition, rachet\xE9" matches any). Use
+\`since\` (ISO date) to keep only entries dated on/after it \u2014 entries with no
+date are kept (a missing date is not evidence the event is old).
+
+**Result is campaign-ready.** \`matched[]\` carries \`lead_id\`, \`name\`,
+\`location\`, and the matching \`matched_signals[]\` (section + hot + source +
+date + description). Feed the matched \`lead_id\`s straight into
+\`leadbay_add_leads_to_campaign\` / \`leadbay_create_campaign\`.
+
+On a 429 mid-scan, partial \`matched\` is returned with \`quota_exceeded: true\` \u2014
+offer the user wait-for-reset OR a top-up link (both unblock; a top-up clears
+the throttle immediately).
+
+**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.
+
+
+WHEN TO USE: when the user wants to filter a known
+portfolio by a web-research signal across many leads at once \u2014 discovering a
+cohort to act on, not inspecting a single lead.
+
+WHEN NOT TO USE: for a single named company
+(leadbay_research_lead_by_name_fuzzy) or one lead by UUID
+(leadbay_research_lead_by_id); to qualify leads that have no signals yet
+(leadbay_bulk_qualify_leads); or to just list follow-ups with no signal filter
+(leadbay_pull_followups).
+
+---
+
+## RENDERING \u2014 bulk signal-scan results
+
+The output is a cohort, grouped by lead. Lead with the matches, end with an
+honesty footer \u2014 never hide what wasn't scanned.
+
+### Matched leads
+
+Open with a one-line headline: \`**N leads match "<query>"** (M scanned).\`
+
+Then one block per \`matched[]\` lead, ordered with \`hot\` matches first. Emit
+each as a host-parseable per-lead block so the chat host's place-card
+auto-detector can render it (per the repo "feed the address auto-detector"
+convention):
+
+\`\`\`
+### <name> \xB7 <location>
+
+<for each matched_signal, one bullet>
+- **<section_emoji> <section_label>** \u2014 <description> <\u{1F525} if hot> ([source](<source>), <date>)
+\`\`\`
+
+- **Bold** the description of \`hot: true\` entries; leave cold entries plain.
+- Render \`source\` as a markdown link \`([source](url), date)\`; omit the date
+  when null, omit the link when \`source\` is empty.
+- Cap to the 3 strongest signals per lead (hot first, then by date desc); if a
+  lead has more, end its block with \`_+K more signals_\`.
+- When \`name\` is null (the scan was scoped by \`leadIds\` and the read failed to
+  carry firmographics), fall back to \`### Lead <lead_id>\` \u2014 but prefer to enrich
+  the name via the matched lead's own data when available.
+
+### Honesty footer (ALWAYS print)
+
+A single italic line summarising coverage:
+
+\`_Scanned N \xB7 matched M \xB7 K had no cached signals (not yet researched)._\`
+
+- When \`not_researched\` is non-empty, this is load-bearing: state plainly that
+  those K leads were NOT searched and were NOT counted as "no match". Offer to
+  qualify them and re-scan (see NEXT STEPS).
+- When \`truncated_at\` is set, add: \`_Coverage partial \u2014 only the first <truncated_at>
+  leads were scanned; narrow the scope or raise max_leads._\`
+- When \`quota_exceeded\` is true, add the wait-or-top-up offer.
+
+**Hide:** raw \`lead_id\` in prose (use it only for the campaign call), \`_meta\`,
+empty arrays, any freshness field. NEVER present \`not_researched\` leads as
+"no signal found".
+
+
+---
+
+## NEXT STEPS \u2014 after the signal scan
+
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
+
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
+
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
+
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
+
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
+
+---
+
+
+
+The scan exists to BUILD A COHORT, not just to list. The default next move is
+almost always "turn the matched leads into a campaign."
+
+| Observation                                       | Suggest                                                      | Calls                                                                                  |
+|---------------------------------------------------|--------------------------------------------------------------|----------------------------------------------------------------------------------------|
+| \`matched\` non-empty (top of menu)                 | "Build a campaign from the N matched leads"                  | leadbay_create_campaign / leadbay_add_leads_to_campaign(matched lead_ids)              |
+| \`not_researched\` non-empty                        | "K leads aren't researched yet \u2014 qualify them, then re-scan" | leadbay_bulk_qualify_leads(not_researched lead_ids) \u2192 re-run leadbay_scan_portfolio_signals |
+| Zero matches but leads were researched            | "Widen the query (synonyms) or relax \`since\`"                | leadbay_scan_portfolio_signals(query: "<broader terms>", since: omit-or-earlier)      |
+| \`truncated_at\` set                                | "Scan only covered N \u2014 narrow scope or raise the cap"        | leadbay_scan_portfolio_signals({city / set_filter}) or raise \`max_leads\`              |
+| One standout matched lead                          | "Open that lead's full brief"                                | leadbay_research_lead_by_id(leadId)                                                    |
+| \`quota_exceeded\`                                  | "Wait for reset OR top up to finish the scan"                | leadbay_create_topup_link                                                              |
+
+NEVER report leads in \`not_researched\` as if they had no matching signal \u2014 they
+were never read. Distinguish "no signal X found" (researched, no match) from
+"not yet researched" (no data to search) every time.
 `;
     leadbay_seed_candidates = `## WHEN TO USE
 
@@ -8656,7 +8837,7 @@ Modern chat hosts (Claude, ChatGPT) expose first-party widgets the agent can rou
 |---|---|---|
 | \`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 |
 | \`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) | The tool's NEXT STEPS block has 2\u20134 mutually-exclusive next moves and the user hasn't already chosen | \`{questions: [{question: "What next?", type: "single_select", options: [<2-4 short button labels>]}]}\`; max 3 questions per call |
+| \`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.
 
@@ -8674,6 +8855,83 @@ 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.
+
+---
+`;
+    leadbay_unpin_contact = `## WHEN TO USE
+
+Trigger phrases: "unpin this contact", "remove the pin from this contact", "this person isn't the priority anymore", "unfavourite this contact".
+
+**Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
+
+Do NOT use for: "pin / mark as priority" \u2192 \`leadbay_pin_contact\`; "remove / delete this contact" \u2192 \`leadbay_remove_contact\`.
+
+Prefer when: user wants to clear the pinned flag on a contact (but keep the contact) \u2014 pass that contact's own \`contact_id\`
+
+Examples that SHOULD invoke this tool:
+- "Unpin Jane Doe \u2014 she's not the priority anymore."
+- "Remove the pin from that contact."
+- "Unfavourite this person."
+
+Examples that should NOT invoke this tool (sound similar, route elsewhere):
+- "Pin this contact as priority."
+- "Remove that contact entirely."
+- "Add a new contact to this company."
+
+## RENDER (quick)
+
+One-line confirmation that the named contact (or id) is no longer pinned.
+No table.
+
+---
+
+Unpin a single contact on a company \u2014 clears its priority / favourite flag. The contact stays on the company; only the pin is removed (to remove the contact entirely, use \`leadbay_remove_contact\`).
+
+Pass the contact's **own** \`contact_id\` \u2014 not the parent lead id.
+
+Backend: \`POST /contacts/{contact_id}/unpin\` \u2192 204. Idempotent. The inverse is \`leadbay_pin_contact\`.
+
+Returns \`{ pinned: false, contact_id, action: "unpinned" }\`.
+
+Requires: LEADBAY_MCP_WRITE=1 (MCP) or exposeWrite=true (OpenClaw).
+`;
+    leadbay_update_contact = `## WHEN TO USE
+
+Trigger phrases: "update this contact", "fix this contact's title", "change their email / phone / LinkedIn", "edit this person's details", "correct the contact's name".
+
+**Memory:** recall + capture via \`leadbay_agent_memory_*\` tools.
+
+Do NOT use for: "add a new contact to this company" \u2192 \`leadbay_add_contact\`; "remove / delete this contact" \u2192 \`leadbay_remove_contact\`; "get email/phone for a contact (enrichment)" \u2192 \`leadbay_enrich_titles\`.
+
+Prefer when: user wants to change details on an EXISTING contact \u2014 pass that contact's own \`contact_id\` plus first_name + last_name (required) and the fields to change
+
+Examples that SHOULD invoke this tool:
+- "Update Jane's title to SVP Engineering."
+- "Fix this contact's LinkedIn URL."
+- "Change John's email to john@acme.com."
+
+Examples that should NOT invoke this tool (sound similar, route elsewhere):
+- "Add a new contact to this company."
+- "Remove that contact, wrong person."
+- "Get me the email for this contact."
+
+## RENDER (quick)
+
+One-line confirmation naming the contact and what changed. No table.
+
+---
+
+Edit an existing contact in place \u2014 change their \`job_title\`, \`linkedin_page\`, \`email\`, \`phone_number\`, or name.
+
+Pass the contact's **own** \`contact_id\` (the \`id\` field from \`leadbay_research_lead_by_id\` or a contacts list) \u2014 **not** the parent lead id.
+
+**\`first_name\` + \`last_name\` are required even on an edit.** The backend validates the full contact identity and rejects a partial body (\`invalid contact\`). So pass the contact's *current* first/last name even when you're only changing the title \u2014 read the current values via \`leadbay_research_lead_by_id\` first if you don't have them.
+
+Backend: \`POST /contacts/{contact_id}/update\` (snake_case body) \u2192 200 with the updated contact. Edits in place (same id). Camel-case bodies are rejected.
+
+Returns \`{ updated: true, contact_id, contact: { id, first_name, last_name, job_title, linkedin_page, email, phone_number } }\`.
+
+Requires: LEADBAY_MCP_WRITE=1 (MCP) or exposeWrite=true (OpenClaw).
 `;
     leadbay_update_lens = `Update lens metadata (name, description, mode flags). Does NOT change the audience filter \u2014 use leadbay_update_lens_filter for that.
 
@@ -13094,6 +13352,250 @@ var init_dislike_lead = __esm({
   }
 });
 
+// ../core/dist/tools/add-contact.js
+var addContact;
+var init_add_contact = __esm({
+  "../core/dist/tools/add-contact.js"() {
+    "use strict";
+    init_tool_descriptions_generated();
+    addContact = {
+      name: "leadbay_add_contact",
+      description: leadbay_add_contact,
+      write: true,
+      annotations: {
+        title: "Add a contact",
+        readOnlyHint: false,
+        destructiveHint: false,
+        idempotentHint: false,
+        openWorldHint: true
+      },
+      inputSchema: {
+        type: "object",
+        properties: {
+          lead_id: {
+            type: "string",
+            description: "UUID of the parent company (lead) to attach the contact to. The contact is created on this company."
+          },
+          first_name: { type: "string", description: "Contact first name." },
+          last_name: { type: "string", description: "Contact last name." },
+          job_title: { type: "string", description: "Contact job title (optional)." },
+          linkedin_page: {
+            type: "string",
+            description: "Contact LinkedIn profile URL (optional)."
+          },
+          email: { type: "string", description: "Contact email (optional)." },
+          phone_number: {
+            type: "string",
+            description: "Contact phone number (optional, free-form)."
+          }
+        },
+        required: ["lead_id", "first_name", "last_name"],
+        additionalProperties: false
+      },
+      execute: async (client, params, _ctx) => {
+        const body = {
+          first_name: params.first_name,
+          last_name: params.last_name
+        };
+        if (params.job_title != null)
+          body.job_title = params.job_title;
+        if (params.linkedin_page != null)
+          body.linkedin_page = params.linkedin_page;
+        if (params.email != null)
+          body.email = params.email;
+        if (params.phone_number != null)
+          body.phone_number = params.phone_number;
+        const contact = await client.request("POST", `/leads/${params.lead_id}/contacts`, body);
+        return { added: true, lead_id: params.lead_id, contact };
+      }
+    };
+  }
+});
+
+// ../core/dist/tools/remove-contact.js
+var removeContact;
+var init_remove_contact = __esm({
+  "../core/dist/tools/remove-contact.js"() {
+    "use strict";
+    init_tool_descriptions_generated();
+    removeContact = {
+      name: "leadbay_remove_contact",
+      description: leadbay_remove_contact,
+      write: true,
+      annotations: {
+        title: "Remove a contact",
+        readOnlyHint: false,
+        // Soft-delete (archive), but it does remove the contact from the active
+        // list, so flag it destructive so cautious clients can confirm.
+        destructiveHint: true,
+        idempotentHint: true,
+        openWorldHint: true
+      },
+      inputSchema: {
+        type: "object",
+        properties: {
+          contact_id: {
+            type: "string",
+            description: "UUID of the contact to remove (the contact's own `id`, e.g. from leadbay_research_lead_by_id's contacts list \u2014 NOT the parent lead id)."
+          }
+        },
+        required: ["contact_id"],
+        additionalProperties: false
+      },
+      execute: async (client, params, _ctx) => {
+        await client.requestVoid("POST", `/contacts/${params.contact_id}/archive`);
+        return { archived: true, contact_id: params.contact_id, action: "archived" };
+      }
+    };
+  }
+});
+
+// ../core/dist/tools/pin-contact.js
+var pinContact;
+var init_pin_contact = __esm({
+  "../core/dist/tools/pin-contact.js"() {
+    "use strict";
+    init_tool_descriptions_generated();
+    pinContact = {
+      name: "leadbay_pin_contact",
+      description: leadbay_pin_contact,
+      write: true,
+      annotations: {
+        title: "Pin a contact",
+        readOnlyHint: false,
+        destructiveHint: false,
+        idempotentHint: true,
+        openWorldHint: true
+      },
+      inputSchema: {
+        type: "object",
+        properties: {
+          contact_id: {
+            type: "string",
+            description: "UUID of the contact to pin (the contact's own `id` \u2014 NOT the parent lead id)."
+          }
+        },
+        required: ["contact_id"],
+        additionalProperties: false
+      },
+      execute: async (client, params, _ctx) => {
+        await client.requestVoid("POST", `/contacts/${params.contact_id}/pin`);
+        return { pinned: true, contact_id: params.contact_id, action: "pinned" };
+      }
+    };
+  }
+});
+
+// ../core/dist/tools/unpin-contact.js
+var unpinContact;
+var init_unpin_contact = __esm({
+  "../core/dist/tools/unpin-contact.js"() {
+    "use strict";
+    init_tool_descriptions_generated();
+    unpinContact = {
+      name: "leadbay_unpin_contact",
+      description: leadbay_unpin_contact,
+      write: true,
+      annotations: {
+        title: "Unpin a contact",
+        readOnlyHint: false,
+        destructiveHint: false,
+        idempotentHint: true,
+        openWorldHint: true
+      },
+      inputSchema: {
+        type: "object",
+        properties: {
+          contact_id: {
+            type: "string",
+            description: "UUID of the contact to unpin (the contact's own `id` \u2014 NOT the parent lead id)."
+          }
+        },
+        required: ["contact_id"],
+        additionalProperties: false
+      },
+      execute: async (client, params, _ctx) => {
+        await client.requestVoid("POST", `/contacts/${params.contact_id}/unpin`);
+        return { pinned: false, contact_id: params.contact_id, action: "unpinned" };
+      }
+    };
+  }
+});
+
+// ../core/dist/tools/update-contact.js
+var updateContact;
+var init_update_contact = __esm({
+  "../core/dist/tools/update-contact.js"() {
+    "use strict";
+    init_tool_descriptions_generated();
+    updateContact = {
+      name: "leadbay_update_contact",
+      description: leadbay_update_contact,
+      write: true,
+      annotations: {
+        title: "Update a contact",
+        readOnlyHint: false,
+        destructiveHint: false,
+        idempotentHint: true,
+        openWorldHint: true
+      },
+      inputSchema: {
+        type: "object",
+        properties: {
+          contact_id: {
+            type: "string",
+            description: "UUID of the contact to edit (the contact's own `id` \u2014 NOT the parent lead id)."
+          },
+          first_name: {
+            type: "string",
+            description: "Contact first name \u2014 REQUIRED even on an edit. Pass the current value if you're not changing it."
+          },
+          last_name: {
+            type: "string",
+            description: "Contact last name \u2014 REQUIRED even on an edit. Pass the current value if you're not changing it."
+          },
+          // Nullable so the agent can CLEAR a field (pass null) as well as set a
+          // new value. execute forwards null verbatim; the backend accepts it.
+          job_title: {
+            type: ["string", "null"],
+            description: "Contact job title. Pass null to clear it."
+          },
+          linkedin_page: {
+            type: ["string", "null"],
+            description: "Contact LinkedIn URL. Pass null to clear it."
+          },
+          email: {
+            type: ["string", "null"],
+            description: "Contact email. Pass null to clear it."
+          },
+          phone_number: {
+            type: ["string", "null"],
+            description: "Contact phone (free-form). Pass null to clear it."
+          }
+        },
+        required: ["contact_id", "first_name", "last_name"],
+        additionalProperties: false
+      },
+      execute: async (client, params, _ctx) => {
+        const body = {
+          first_name: params.first_name,
+          last_name: params.last_name
+        };
+        if (params.job_title !== void 0)
+          body.job_title = params.job_title;
+        if (params.linkedin_page !== void 0)
+          body.linkedin_page = params.linkedin_page;
+        if (params.email !== void 0)
+          body.email = params.email;
+        if (params.phone_number !== void 0)
+          body.phone_number = params.phone_number;
+        const contact = await client.request("POST", `/contacts/${params.contact_id}/update`, body);
+        return { updated: true, contact_id: params.contact_id, contact };
+      }
+    };
+  }
+});
+
 // ../core/dist/composite/prepare-outreach.js
 function normalizeLinkedinPage2(v) {
   if (v == null)
@@ -13316,6 +13818,35 @@ function summarise(responses) {
   }
   return { answered, total, avg_qualification_boost: avg, best_response_excerpt: excerpt };
 }
+function buildPullLeadsNextSteps(args) {
+  const { leadCount, hasMore, nextPage } = args;
+  if (leadCount <= 0)
+    return null;
+  const options = [];
+  options.push({
+    label: "Triage board",
+    description: "Build an interactive lead triage board to sort and filter this batch.",
+    kind: "build_artifact"
+  });
+  options.push({
+    label: "Deepen qualification",
+    description: "Run deeper AI qualification on these leads.",
+    kind: "qualify_deeper"
+  });
+  if (hasMore && nextPage != null) {
+    options.push({
+      label: "Next page",
+      description: `Pull page ${nextPage + 1} of this lens.`,
+      kind: "pull_next_page"
+    });
+  }
+  options.push({
+    label: "Refine audience",
+    description: "Adjust the lens audience / filters (sector, size, prompt).",
+    kind: "refine_audience"
+  });
+  return { question: "What do you want to do next?", options: options.slice(0, 4) };
+}
 var pullLeads;
 var init_pull_leads = __esm({
   "../core/dist/composite/pull-leads.js"() {
@@ -13386,6 +13917,24 @@ var init_pull_leads = __esm({
             type: "boolean",
             description: "True if scoring is still running."
           },
+          next_steps: {
+            type: ["object", "null"],
+            description: "Ready-made NEXT STEPS for the host's choice widget. Each option has a SHORT `label` (\u22645 words, fits AskUserQuestion's label cap on Claude cowork/Claude Code) and a full `description`. For AskUserQuestion (cowork/Claude Code) pass each option as {label, description}. For ask_user_input_v0 (Claude chat/ChatGPT, string-only options) use the `description` as the option string. Use these VERBATIM, in order \u2014 do NOT re-derive, reword, or render as prose when a widget tool exists. options[0] is the artifact offer (build the lead triage board) whenever the batch is non-empty. null only when the batch is empty.",
+            properties: {
+              question: { type: "string" },
+              options: {
+                type: "array",
+                items: {
+                  type: "object",
+                  properties: {
+                    label: { type: "string" },
+                    description: { type: "string" },
+                    kind: { type: "string" }
+                  }
+                }
+              }
+            }
+          },
           _meta: {
             type: "object",
             description: "Operator context: region + last-call latency.",
@@ -13460,6 +14009,8 @@ var init_pull_leads = __esm({
         const currentPage = res.pagination?.page ?? page;
         const hasMore = currentPage < totalPages - 1;
         const nextPage = hasMore ? currentPage + 1 : null;
+        const leadCount = res.items.length;
+        const nextSteps = buildPullLeadsNextSteps({ leadCount, hasMore, nextPage });
         return withAgentMemoryMeta(client, {
           lens: { id: lensId },
           leads: res.items.map((lead) => ({
@@ -13471,6 +14022,7 @@ var init_pull_leads = __esm({
           next_page: nextPage,
           computing_wishlist: res.computing_wishlist,
           computing_scores: res.computing_scores,
+          next_steps: nextSteps,
           _meta: {
             region: client.region,
             latency_ms: client.lastMeta?.latency_ms ?? null
@@ -14587,6 +15139,46 @@ var init_campaign_call_sheet = __esm({
   }
 });
 
+// ../core/dist/composite/_web-fetch-helpers.js
+function splitEmojiSection(key) {
+  const m = key.match(/^([^\p{L}\p{N}\s]+)\s+(.+)$/u);
+  if (m)
+    return { emoji: m[1], label: m[2] };
+  return { emoji: null, label: key };
+}
+function reshapeWebFetchContent(content) {
+  if (!content)
+    return [];
+  const sections = [];
+  for (const [key, val] of Object.entries(content)) {
+    if (!Array.isArray(val))
+      continue;
+    const { emoji, label } = splitEmojiSection(key);
+    sections.push({
+      section_label: label,
+      section_emoji: emoji,
+      entries: val
+    });
+  }
+  sections.sort((a, b) => {
+    const ai = SECTION_PRIORITY.findIndex((p) => a.section_label.toLowerCase().includes(p));
+    const bi = SECTION_PRIORITY.findIndex((p) => b.section_label.toLowerCase().includes(p));
+    const aN = ai < 0 ? SECTION_PRIORITY.length : ai;
+    const bN = bi < 0 ? SECTION_PRIORITY.length : bi;
+    if (aN !== bN)
+      return aN - bN;
+    return a.section_label.localeCompare(b.section_label);
+  });
+  return sections;
+}
+var SECTION_PRIORITY;
+var init_web_fetch_helpers = __esm({
+  "../core/dist/composite/_web-fetch-helpers.js"() {
+    "use strict";
+    SECTION_PRIORITY = ["profile", "signals", "clues"];
+  }
+});
+
 // ../core/dist/composite/research-lead-by-id.js
 function normalizeLinkedinPage5(v) {
   if (v == null)
@@ -14702,37 +15294,6 @@ _Truncated_: ${shape.truncation_hint ?? "response trimmed"}_`);
   }
   return out.join("\n");
 }
-function splitEmojiSection(key) {
-  const m = key.match(/^([^\p{L}\p{N}\s]+)\s+(.+)$/u);
-  if (m)
-    return { emoji: m[1], label: m[2] };
-  return { emoji: null, label: key };
-}
-function reshapeWebFetchContent(content) {
-  if (!content)
-    return [];
-  const sections = [];
-  for (const [key, val] of Object.entries(content)) {
-    if (!Array.isArray(val))
-      continue;
-    const { emoji, label } = splitEmojiSection(key);
-    sections.push({
-      section_label: label,
-      section_emoji: emoji,
-      entries: val
-    });
-  }
-  sections.sort((a, b) => {
-    const ai = SECTION_PRIORITY.findIndex((p) => a.section_label.toLowerCase().includes(p));
-    const bi = SECTION_PRIORITY.findIndex((p) => b.section_label.toLowerCase().includes(p));
-    const aN = ai < 0 ? SECTION_PRIORITY.length : ai;
-    const bN = bi < 0 ? SECTION_PRIORITY.length : bi;
-    if (aN !== bN)
-      return aN - bN;
-    return a.section_label.localeCompare(b.section_label);
-  });
-  return sections;
-}
 function isReachable(c) {
   if (!c)
     return false;
@@ -14740,13 +15301,13 @@ function isReachable(c) {
   const phone = typeof c.phone_number === "string" ? c.phone_number.trim() : "";
   return email.length > 0 || phone.length > 0;
 }
-var SECTION_PRIORITY, researchLeadById, _innerExecute;
+var researchLeadById, _innerExecute;
 var init_research_lead_by_id = __esm({
   "../core/dist/composite/research-lead-by-id.js"() {
     "use strict";
     init_agent_memory();
+    init_web_fetch_helpers();
     init_tool_descriptions_generated();
-    SECTION_PRIORITY = ["profile", "signals", "clues"];
     researchLeadById = {
       name: "leadbay_research_lead_by_id",
       annotations: {
@@ -15321,6 +15882,326 @@ var init_account_history = __esm({
   }
 });
 
+// ../core/dist/composite/scan-portfolio-signals.js
+function fold(s) {
+  return s.normalize("NFD").replace(/[̀-ͯ]/g, "").toLowerCase().trim();
+}
+function parseQueryTerms(query) {
+  return query.split(/[,\s]+/).map((t) => fold(t)).filter((t) => t.length > 0);
+}
+function shortLocation(loc) {
+  if (loc == null)
+    return null;
+  if (typeof loc === "string")
+    return loc.trim() || null;
+  if (typeof loc === "object") {
+    const o = loc;
+    const clean = (v) => {
+      const s = typeof v === "string" ? v.trim() : "";
+      return s && s.toUpperCase() !== "N/A" ? s : "";
+    };
+    const city = clean(o.city);
+    const state = clean(o.state);
+    if (city && state)
+      return `${city}, ${state}`;
+    if (city)
+      return city;
+    if (typeof o.full === "string" && o.full.trim())
+      return o.full.trim();
+  }
+  return null;
+}
+function mergeLocationIds2(filter, ids) {
+  const criteria = filter?.criteria ? [...filter.criteria] : [];
+  const idx = criteria.findIndex((c) => c?.type === "location_ids" && c?.is_excluded === false);
+  if (idx >= 0) {
+    const cur = criteria[idx];
+    const existing = Array.isArray(cur.locations) ? cur.locations : [];
+    const merged = Array.from(/* @__PURE__ */ new Set([...existing, ...ids]));
+    criteria[idx] = { ...cur, locations: merged };
+  } else {
+    criteria.push({ type: "location_ids", is_excluded: false, locations: ids });
+  }
+  return { criteria };
+}
+function entryMatches(entry, sectionLabel, terms) {
+  if (terms.length === 0)
+    return false;
+  const haystack = fold([entry.description ?? "", entry.source ?? "", sectionLabel].join(" 
 "));
+  return terms.some((t) => haystack.includes(t));
+}
+function passesSince(entry, sinceMs) {
+  if (sinceMs == null)
+    return true;
+  if (!entry.date)
+    return true;
+  const ts = Date.parse(entry.date);
+  if (Number.isNaN(ts))
+    return true;
+  return ts >= sinceMs;
+}
+var DEFAULT_MAX_LEADS, HARD_MAX_LEADS, MONITOR_PAGE_SIZE, scanPortfolioSignals;
+var init_scan_portfolio_signals = __esm({
+  "../core/dist/composite/scan-portfolio-signals.js"() {
+    "use strict";
+    init_agent_memory();
+    init_web_fetch_helpers();
+    init_geo_helpers();
+    init_tool_descriptions_generated();
+    DEFAULT_MAX_LEADS = 200;
+    HARD_MAX_LEADS = 300;
+    MONITOR_PAGE_SIZE = 200;
+    scanPortfolioSignals = {
+      name: "leadbay_scan_portfolio_signals",
+      annotations: {
+        title: "Scan a portfolio for a web-research signal in bulk",
+        readOnlyHint: true,
+        destructiveHint: false,
+        idempotentHint: true,
+        openWorldHint: true
+      },
+      description: leadbay_scan_portfolio_signals,
+      inputSchema: {
+        type: "object",
+        properties: {
+          query: {
+            type: "string",
+            description: "Signal terms to match (case- and accent-insensitive). Comma- or space-separated terms are OR'd, e.g. 'M&A, acquisition, rachet\xE9'. Matched against each signal entry's description, source, and section label."
+          },
+          leadIds: {
+            type: "array",
+            items: { type: "string" },
+            description: "Explicit lead UUIDs to scan (skips Monitor pagination). Use when you already hold a cohort of ids."
+          },
+          city: {
+            type: "string",
+            description: "Free-text city / region to scope the Monitor portfolio before scanning (resolved via /geo/search, same as leadbay_pull_followups). Ignored when `leadIds` is given."
+          },
+          city_id: {
+            type: "string",
+            description: "Pre-resolved admin_area id (numeric string). Bypasses the resolver. Ignored when `leadIds` is given."
+          },
+          set_filter: {
+            type: "object",
+            description: "Optional Monitor FilterItem ({criteria: FilterCriterion[]}) to scope the portfolio before scanning. Persisted server-side then applied, mirroring leadbay_pull_followups. Ignored when `leadIds` is given.",
+            properties: {
+              criteria: { type: "array", items: { type: "object" } }
+            }
+          },
+          since: {
+            type: "string",
+            description: "ISO date (e.g. '2025-01-01'). When set, only signal entries dated on/after it are returned. Entries with no date are kept (absence of a date is not evidence the event is old)."
+          },
+          max_leads: {
+            type: "number",
+            description: `Cap on leads scanned (default ${DEFAULT_MAX_LEADS}, hard max ${HARD_MAX_LEADS}). When the portfolio exceeds this, the scan is truncated and truncated_at is set.`
+          }
+        },
+        required: ["query"],
+        additionalProperties: false
+      },
+      outputSchema: {
+        type: "object",
+        properties: {
+          matched: {
+            type: "array",
+            description: "Leads with \u22651 signal entry matching the query. Each: {lead_id, name, location, matched_signals:[{section_label, section_emoji, hot, source, date, description}]}. Campaign-ready \u2014 feed lead_ids straight into leadbay_add_leads_to_campaign.",
+            items: { type: "object" }
+          },
+          not_researched: {
+            type: "array",
+            description: "Leads scanned that had NO cached signal content (web_fetch.content null or still in progress). These are NOT 'no match' \u2014 they were never researched. Qualify them (leadbay_bulk_qualify_leads) then re-scan. Each: {lead_id, name}.",
+            items: { type: "object" }
+          },
+          scanned_count: {
+            type: "number",
+            description: "Total leads read in this scan (matched + non-matching + not_researched)."
+          },
+          matched_count: { type: "number", description: "Length of `matched`." },
+          truncated_at: {
+            type: "number",
+            description: "Present only when the portfolio exceeded `max_leads`; equals the cap applied. Coverage is partial \u2014 narrow the scope (city / set_filter) or raise max_leads."
+          },
+          quota_exceeded: {
+            type: "boolean",
+            description: "True if a 429 was hit mid-scan. Partial `matched` is still returned. Offer wait-for-reset OR top-up."
+          },
+          status: {
+            type: "string",
+            description: "`ambiguous_locations` when a passed `city` matched multiple admin_areas; pick an id from `location_ambiguities` and re-call with `city_id`. Absent on the happy path."
+          },
+          location_ambiguities: {
+            type: "array",
+            description: "Only present when status === 'ambiguous_locations'.",
+            items: { type: "object" }
+          },
+          _meta: {
+            type: "object",
+            properties: {
+              region: { type: "string" },
+              agent_memory: { type: "object" }
+            }
+          }
+        },
+        required: ["matched", "not_researched", "scanned_count", "matched_count", "quota_exceeded"]
+      },
+      execute: async (client, params, ctx) => {
+        const terms = parseQueryTerms(params.query ?? "");
+        const maxLeads = Math.min(params.max_leads ?? DEFAULT_MAX_LEADS, HARD_MAX_LEADS);
+        const sinceParsed = params.since ? Date.parse(params.since) : NaN;
+        const sinceValid = Number.isNaN(sinceParsed) ? null : sinceParsed;
+        let portfolio;
+        let truncatedAt;
+        let quotaExceeded = false;
+        if (params.leadIds && params.leadIds.length > 0) {
+          const sliced = params.leadIds.slice(0, maxLeads);
+          if (params.leadIds.length > maxLeads)
+            truncatedAt = maxLeads;
+          portfolio = sliced.map((id) => ({ id, name: null, location: null }));
+        } else {
+          let effectiveSetFilter = params.set_filter;
+          const geoTexts = [];
+          if (params.city)
+            geoTexts.push(params.city);
+          if (params.city_id)
+            geoTexts.push(params.city_id);
+          if (geoTexts.length > 0) {
+            const { resolved, ambiguities } = await resolveLocations(client, geoTexts);
+            if (ambiguities.length > 0) {
+              return withAgentMemoryMeta(client, {
+                status: "ambiguous_locations",
+                location_ambiguities: ambiguities,
+                matched: [],
+                not_researched: [],
+                scanned_count: 0,
+                matched_count: 0,
+                quota_exceeded: false,
+                _meta: { region: client.region }
+              }, ctx);
+            }
+            if (resolved.length > 0) {
+              effectiveSetFilter = mergeLocationIds2(effectiveSetFilter, resolved);
+            }
+          }
+          let filterStored = false;
+          if (effectiveSetFilter) {
+            try {
+              await client.requestVoid("POST", "/monitor/filter", effectiveSetFilter);
+              filterStored = true;
+            } catch (err) {
+              if (err?.code === "QUOTA_EXCEEDED")
+                quotaExceeded = true;
+              ctx?.logger?.warn?.(`scan_portfolio_signals: POST /monitor/filter failed (${err?.code ?? err?.message ?? err}); scanning UNfiltered to avoid trusting a stale server-side filter`);
+            }
+          }
+          portfolio = [];
+          let page = 0;
+          while (portfolio.length < maxLeads) {
+            const qs = new URLSearchParams({
+              personal: "false",
+              liked: "false",
+              filtered: String(filterStored),
+              count: String(MONITOR_PAGE_SIZE),
+              page: String(page)
+            }).toString();
+            let monitor;
+            try {
+              monitor = await client.request("GET", `/monitor?${qs}`);
+            } catch (err) {
+              if (err?.code === "QUOTA_EXCEEDED") {
+                quotaExceeded = true;
+                break;
+              }
+              throw err;
+            }
+            const rawLeads = Array.isArray(monitor.items) ? monitor.items : Array.isArray(monitor.leads) ? monitor.leads : Array.isArray(monitor) ? monitor : [];
+            if (rawLeads.length === 0)
+              break;
+            for (const lead of rawLeads) {
+              if (portfolio.length >= maxLeads)
+                break;
+              portfolio.push({
+                id: lead.id,
+                name: lead.name ?? null,
+                location: shortLocation(lead.location)
+              });
+            }
+            const pages = monitor.pagination?.pages;
+            if (typeof pages === "number" && page >= pages - 1)
+              break;
+            if (rawLeads.length < MONITOR_PAGE_SIZE)
+              break;
+            page += 1;
+          }
+          if (portfolio.length >= maxLeads)
+            truncatedAt = maxLeads;
+        }
+        const matched = [];
+        const notResearched = [];
+        const reads = await Promise.all(portfolio.map(async (lead) => {
+          try {
+            const wf = await client.request("GET", `/leads/${lead.id}/web_fetch`);
+            return { lead, wf, error: null };
+          } catch (error) {
+            return { lead, wf: null, error };
+          }
+        }));
+        for (const r of reads) {
+          const { lead, wf, error } = r;
+          if (error) {
+            if (error?.code === "QUOTA_EXCEEDED")
+              quotaExceeded = true;
+            notResearched.push({ lead_id: lead.id, name: lead.name });
+            continue;
+          }
+          const hasContent = wf && wf.content != null && wf.in_progress !== true && Object.keys(wf.content).length > 0;
+          if (!hasContent) {
+            notResearched.push({ lead_id: lead.id, name: lead.name });
+            continue;
+          }
+          const sections = reshapeWebFetchContent(wf.content);
+          const matchedSignals = [];
+          for (const sec of sections) {
+            for (const entry of sec.entries) {
+              if (!entryMatches(entry, sec.section_label, terms))
+                continue;
+              if (!passesSince(entry, sinceValid))
+                continue;
+              matchedSignals.push({
+                section_label: sec.section_label,
+                section_emoji: sec.section_emoji,
+                hot: entry.hot === true,
+                source: entry.source ?? "",
+                date: entry.date ?? null,
+                description: entry.description ?? ""
+              });
+            }
+          }
+          if (matchedSignals.length > 0) {
+            matched.push({
+              lead_id: lead.id,
+              name: lead.name,
+              location: lead.location,
+              matched_signals: matchedSignals
+            });
+          }
+        }
+        const out = {
+          matched,
+          not_researched: notResearched,
+          scanned_count: portfolio.length,
+          matched_count: matched.length,
+          quota_exceeded: quotaExceeded,
+          _meta: { region: client.region }
+        };
+        if (truncatedAt !== void 0)
+          out.truncated_at = truncatedAt;
+        return withAgentMemoryMeta(client, out, ctx);
+      }
+    };
+  }
+});
+
 // ../core/dist/composite/recall-ordered-titles.js
 var recallOrderedTitles;
 var init_recall_ordered_titles = __esm({
@@ -20486,6 +21367,7 @@ __export(dist_exports, {
   resolveImportRows: () => resolveImportRows,
   resolveRegion: () => resolveRegion,
   reviseHintFor: () => reviseHintFor,
+  scanPortfolioSignals: () => scanPortfolioSignals,
   seedCandidates: () => seedCandidates,
   selectLeads: () => selectLeads,
   setActiveLens: () => setActiveLens,
@@ -20560,6 +21442,11 @@ var init_dist = __esm({
     init_create_custom_field();
     init_like_lead();
     init_dislike_lead();
+    init_add_contact();
+    init_remove_contact();
+    init_pin_contact();
+    init_unpin_contact();
+    init_update_contact();
     init_prepare_outreach();
     init_pull_leads();
     init_pull_followups();
@@ -20574,6 +21461,7 @@ var init_dist = __esm({
     init_research_lead_by_id();
     init_research_lead_by_name_fuzzy();
     init_account_history();
+    init_scan_portfolio_signals();
     init_recall_ordered_titles();
     init_account_status();
     init_bulk_qualify_leads();
@@ -20673,6 +21561,10 @@ var init_dist = __esm({
       // reprioritize-a-neglected-account workflow (#3630 GAP C) must work in a
       // default deployment without LEADBAY_MCP_ADVANCED=1.
       accountHistory,
+      // Bulk portfolio signal scan — read-only, no quota burn. The single-call
+      // answer to "which of my leads have signal X" that previously forced a
+      // per-lead research_lead_by_id loop (issue #3704).
+      scanPortfolioSignals,
       recallOrderedTitles,
       accountStatus,
       bulkEnrichStatus,
@@ -20722,6 +21614,18 @@ var init_dist = __esm({
       reportOutreach,
       importLeads,
       importAndQualify,
+      // Contact management (product#3703) — each is a single-call relay, so
+      // granular-shaped and living in tools/; registered HERE (not granular-gated)
+      // so reps can manage contacts in-conversation without LEADBAY_MCP_ADVANCED.
+      // Same pattern as likeLead/dislikeLead below. Endpoints (all direct, the
+      // ones the web UI uses — NOT the import pipeline, which 401s on some
+      // accounts): add → POST /leads/{id}/contacts; remove → archive;
+      // pin/unpin → /pin|/unpin; update → /update (snake_case, first/last required).
+      addContact,
+      removeContact,
+      pinContact,
+      unpinContact,
+      updateContact,
       // createCustomField is granular-shaped but file-import prompts depend on it
       // to preserve source-system links without requiring advanced-tool exposure.
       createCustomField,
@@ -20785,10 +21689,10 @@ import {
 var leadbay_daily_check_in = `
 ## 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 taste signal from the user this conversation (sector, region, deal size, communication style, qualification rule, explicit retraction), call \`leadbay_agent_memory_capture\` to persist it: \`source:"user_stated"\` if literal, \`source:"inferred"\` with confidence <=6 if inferred.
+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.
 
 
-Run the Leadbay daily check-in for me. Treat this prompt the same way for any equivalent ask focused on NEW leads from the Discover wishlist: "get me leadbay leads", "best NEW leads to prospect today", "what's new today", "show me my batch", "let's prospect". For follow-up phrasings ("what should I follow up on", "leads I've already worked", "before my trip"), this is the wrong prompt \u2014 route to \`leadbay_followup_check_in\` instead. If the user's intent is ambiguous ("what should I work on?"), ASK once before picking an entry point.
+Run the Leadbay daily check-in for me. Treat this prompt the same way for any equivalent ask focused on NEW leads from the Discover wishlist: "get me leadbay leads", "best NEW leads to prospect today", "what's new today", "show me my batch", "let's prospect", "run my morning check-in", "my daily routine", "I do this every day", "every morning". For follow-up phrasings ("what should I follow up on", "leads I've already worked", "before my trip"), this is the wrong prompt \u2014 route to \`leadbay_followup_check_in\` instead. **Recurrence language ("I do this every day", "every morning", "my routine") always means this prompt \u2014 it is a daily batch check-in, not a follow-up.** If the user's intent is ambiguous ("what should I work on?"), ASK once before picking an entry point.
 
 # Resilience rules for Leadbay long-running tools
 
@@ -20914,13 +21818,66 @@ If the batch returns fewer than 10 qualified leads, top it up: call \`leadbay_bu
 
 # PHASE 4 \u2014 DEEP DIVE (every promising lead)
 
+**Skip Phase 4 if the user's request is primarily to view the batch** (e.g., "show me today's leads", "run my morning check-in", "what's in my inbox") \u2014 proceed directly to NEXT STEPS. Run Phase 4 when the user explicitly asks to research leads, names a specific company, or says "and then research" / "deep dive" / "tell me more about".
+
 Call \`leadbay_research_lead_by_id\` on **every** lead from your top 10 that the user might realistically prospect today (filter out clearly weak fits if any). Don't pick just one. **Call it sequentially** \u2014 one at a time, or batches of at most 3 in parallel. Do not fire 10 in parallel \u2014 it triggers transport backpressure that surfaces as \`"Tool permission stream closed"\` errors (see Rule 3 above). If a call fails, retry that single lead once; if the retry also fails, note the lead id and continue. Report Phase 4 results even if 1\u20132 leads were unresearchable.
 
 For each researched lead surface:
 - what makes it promising (1\u20132 sentences citing signals from the research)
 - the **recommended contacts** the research returns \u2014 name, title, why they're the right starting point
 
-Then ASK the user (don't auto-run): "Want me to enrich the contacts on these leads to acquire their emails / phone numbers?" If the user says yes, call \`leadbay_enrich_contacts\` for the relevant lead IDs (this consumes enrichment quota \u2014 that's why we ask first).
+Contact enrichment is offered in the NEXT STEPS widget below \u2014 do NOT emit a separate prose question here. The widget handles the enrichment offer as one of the selectable options. If the user selects enrichment, call \`leadbay_enrich_contacts({leadId, contactId})\` ONCE PER CONTACT \u2014 the tool takes a single leadId + contactId, never a list. (For bulk title/seniority enrichment across many leads at once, use \`leadbay_enrich_titles({leadIds: [...]})\` instead.) This consumes enrichment quota.
+
+# NEXT STEPS
+
+**Sequential request gate:** If the user's original message contained the literal phrase "and then" (e.g., "show me X and then do Y"), and all stated actions have been completed this turn, skip the NEXT STEPS widget entirely and emit STOP directly. The user stated their full plan; they do not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, go directly to STOP without any widget.
+- Do NOT skip for: plain single-action requests ("show me today's leads"), recurring requests ("I do this every day"), or multi-step workflows the user didn't pre-specify.
+
+**REQUIRED OPTIONS \u2014 triggers and position rules:**
+- **Recurring language** ("every day", "every morning", "I do this every", "remind me", "automate this", "recurring"): add "Schedule 'Daily prospecting check-in' as a recurring task" and place it **first**.
+- **\u22655 leads returned**: add "Build an interactive lead triage board for this batch" and place it **first** (or second if the scheduling offer above also applies).
+
+## NEXT STEPS \u2014 after rendering the pull_leads table
+
+**ALWAYS render NEXT STEPS via your host's next-step widget.** Use whichever is in your tool set \u2014 the NAME and SCHEMA differ: **\`ask_user_input_v0\`** (Claude chat / ChatGPT) takes plain-string options with \`type:"single_select"\`; **\`AskUserQuestion\`** (Claude cowork / Claude Code) takes object options \`{label, description}\` plus a required short \`header\` (\u226412 chars) and \`multiSelect\`, NO \`type\` field, and never add an "Other" option (the host adds it). Match the schema to the tool you actually have \u2014 the wrong schema fails silently and you fall back to prose. Prose bullets are the fallback ONLY when NEITHER widget exists. Any turn that would end with a choice must be the widget \u2014 the widget IS the question.
+
+**If the tool result carries a \`next_steps\` object, that is the source of truth \u2014 use it directly.** Each option has a short \`.label\` (\u22645 words) and a full \`.description\`. Map \`next_steps.options[]\` into your host widget VERBATIM and in order: for \`AskUserQuestion\` (cowork / Claude Code) pass each as \`{label, description}\`; for \`ask_user_input_v0\` (Claude chat / ChatGPT, string options only) pass each option's \`.description\` as the string (it's the full sentence). Do NOT reword, reorder, drop, or prose-ify them \u2014 they're built deterministically by the server so the offer (incl. the artifact option at position 0) fires every time. Fall back to the table below only when there is NO \`next_steps\` field.
+
+**One exception \u2014 skip the widget** when the user's original message contained a complete sequential instruction chain ("show me X and then do Y") AND all stated steps have been completed. In that case, end with STOP directly \u2014 the user stated their full plan and does not need a "what next?" prompt.
+- Skip example: "Show me today's leads and then research the top one for me." \u2192 after research completes, emit STOP without the widget.
+- Do NOT skip for: plain requests ("show me today's leads", "run my check-in"), recurring-language requests ("I do this every day"), or requests where only one action was stated.
+
+Pick 2\u20134 rows from the (Observation, Suggest, Calls) table below most relevant to the response, then call your host's widget with ITS schema (per the schema rules above \u2014 wrong schema fails silently):
+- \`ask_user_input_v0\`: \`{questions:[{question,type:"single_select",options:["<Suggest 1>","<Suggest 2>"]}]}\`
+- \`AskUserQuestion\`: \`{questions:[{question,header:"Next step",multiSelect:false,options:[{label:"<\u22645 words>",description:"<Suggest 1>"}]}]}\`
+
+User picks \u2192 call the matching \`Calls\` tool. Constraints: 2\u20134 mutually-exclusive options, AskUserQuestion labels \u22645 words (full text in \`description\`), max 3 questions. Table stays internal; never recite it.
+
+---
+
+
+
+Pick 2\u20133 items below based on what was actually observed in the response. The table is the source of truth for which moves are valid.
+
+| Observation                                                | Suggest                                                      | Calls                                                  |
+|------------------------------------------------------------|--------------------------------------------------------------|--------------------------------------------------------|
+| \u2265 5 leads returned (any batch)                             | "Build an interactive lead triage board for this batch"      | emit antArtifact from data in hand (do NOT re-call leadbay_pull_leads) |
+| \`has_more == true\`                                         | "Pull the next page (page N+1 of M)"                         | leadbay_pull_leads(page = current + 1, lensId = pinned)|
+| \u2265 3 rows have \`qualification_summary.answered == 0\`        | "Deepen AI qualification on the rows without \u2756 caps"         | leadbay_bulk_qualify_leads(leadIds=[\u2026])                |
+| User points at a single row                                | "Research [Company] in depth"                                | leadbay_research_lead_by_id(leadId)                    |
+| User only has a name (no leadId in context)                | "Look up [Company] by name"                                  | leadbay_research_lead_by_name_fuzzy(companyName)       |
+| Top row has phone AND email                                | "Prepare an outreach for [Contact] \u2014 call + email"           | leadbay_prepare_outreach(leadId)                       |
+| Top row has email but no phone                             | "Draft an outreach email for [Contact]"                      | leadbay_prepare_outreach(leadId)                       |
+| Top row has phone but no email                             | "Show [Contact]'s call details + a 60-second opener"         | leadbay_prepare_outreach(leadId)                       |
+| Top row has contacts but no phone/email                    | "Order contact enrichment to surface email/phone first"      | leadbay_enrich_titles(...) or leadbay_prepare_outreach(leadId, enrich:true) |
+| \`computing_scores == true\` or \`computing_wishlist == true\` | "Scores are still being computed \u2014 re-pull in ~30s"          | leadbay_pull_leads (retry with same lensId)            |
+| User wants a narrower / wider audience                     | "Adjust the lens filters (sector / size)"                    | leadbay_adjust_audience(...)                           |
+| Phase 4 research was run (\`research_lead_by_id\` called) AND top contacts lack direct email/phone | "Enrich contacts on [Lead1], [Lead2] to get direct emails and phone numbers" | leadbay_enrich_contacts(leadId, contactId) \u2014 ONE call per contact (the tool takes a single leadId + contactId, never a list) |
+If nothing in the menu applies cleanly, suggest only "pull next page" and "research a specific lead in depth" \u2014 never invent a tool that doesn't exist.
+
+
+**Final ordering check (do this before rendering):** Recurring offer \u2192 option 1; triage board \u2192 option 1 (or 2 if scheduling is also required). Swap if needed.
 
 # GATE \u2014 STOP
 
@@ -21167,7 +22124,7 @@ Done. The map is the surface; the drafts are the action; the campaign is the per
 var leadbay_prospecting_overview = `
 ## 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 taste signal from the user this conversation (sector, region, deal size, communication style, qualification rule, explicit retraction), call \`leadbay_agent_memory_capture\` to persist it: \`source:"user_stated"\` if literal, \`source:"inferred"\` with confidence <=6 if inferred.
+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.
 
 
 # Leadbay Prospecting \u2014 Orientation
@@ -21441,7 +22398,7 @@ If the response status is \`applied\`, tell me Leadbay is regenerating intellige
 var leadbay_research_a_domain = `
 ## 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 taste signal from the user this conversation (sector, region, deal size, communication style, qualification rule, explicit retraction), call \`leadbay_agent_memory_capture\` to persist it: \`source:"user_stated"\` if literal, \`source:"inferred"\` with confidence <=6 if inferred.
+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.
 
 
 IRON LAW \u2014 NO FABRICATION. Every lead id, contact email, custom field id, mapping decision, and tool argument must trace to a value you read from the file the user attached or to an output from a leadbay_* tool call in this session. Do not invent values. Do not "fill in" a missing leadId with a name match. Do not synthesize a CRM id from a guess. If a value is missing, leave the field blank and say so.
@@ -21582,7 +22539,7 @@ Then ask me ONCE: "Which of these should we drop?" If I name leads to drop, excl
 
 # PHASE 3 \u2014 DECIDE THE CAMPAIGN SHAPE
 
-If I provided a \`rep_split\` ("one campaign per rep: John gets Tulsa, Sarah gets OKC"), partition the validated leads accordingly. If I didn't, ask ONCE: "Create one campaign for the whole batch, or split per rep / region / sector?" \u2014 surface 2-4 options via \`ask_user_input_v0\` when available, else as a bulleted list.
+If I provided a \`rep_split\` ("one campaign per rep: John gets Tulsa, Sarah gets OKC"), partition the validated leads accordingly. If I didn't, ask ONCE: "Create one campaign for the whole batch, or split per rep / region / sector?" \u2014 surface 2-4 options via your host's choice widget (\`ask_user_input_v0\` or \`AskUserQuestion\`) when available, else as a bulleted list.
 
 For each campaign-shape decision, derive a name. Templates:
 - Whole batch: \`"<lens-name> \u2013 <YYYY-MM-DD>"\`
@@ -21599,7 +22556,7 @@ Once the campaigns are created, surface this caveat in plain prose:
 
 > Campaign visibility is currently scoped to the user who CREATED the campaign \u2014 the reps won't see these in their own MCP \`leadbay_list_campaigns\` calls. They CAN see them in the web UI at app.leadbay.ai \u2192 Campaigns. Cross-user MCP visibility would need backend work; flag this as a #3630 US3 product gap if your reps work primarily through MCP.
 
-End with a NEXT STEPS chip via \`ask_user_input_v0\`: "View progression on one of these now?" \u2192 routes to \`leadbay_campaign_progression\`.
+End with a NEXT STEPS chip via your host's choice widget (\`ask_user_input_v0\` or \`AskUserQuestion\`): "View progression on one of these now?" \u2192 routes to \`leadbay_campaign_progression\`.
 
 # PHASE 6 \u2014 STOP
 
@@ -21615,7 +22572,7 @@ If the prompt's body and the tool's RENDERING appear to conflict, the tool's REN
 
 # PHASE 0 \u2014 PICK THE CAMPAIGN
 
-If I gave you a name or id, resolve it. Otherwise call \`leadbay_list_campaigns()\` and surface the active campaigns as a \`single_select\` via \`ask_user_input_v0\` (cap at 4 \u2014 sort by \`updated_at\` desc, archived hidden):
+If I gave you a name or id, resolve it. Otherwise call \`leadbay_list_campaigns()\` and surface the active campaigns as a \`single_select\` via your host's choice widget (\`ask_user_input_v0\` or \`AskUserQuestion\`) (cap at 4 \u2014 sort by \`updated_at\` desc, archived hidden):
 
 > Which campaign do you want to work?
 > - <Name 1> \xB7 <N leads> \xB7 last touched <date>
@@ -21648,7 +22605,7 @@ Call \`leadbay_campaign_call_sheet({campaign_id})\`. The response carries \`summ
 \u{1F4CB} <total_leads> leads \xB7 \u{1F4DE} <leads_with_phone> with a phone \xB7 \u2709 <leads_with_email> with an email \xB7 \u{1F5FA} <leads_with_coords> with coords \xB7 \u{1F534} <leads_without_contacts> need enrichment \xB7 \u2705 <leads_already_contacted> already touched
 \`\`\`
 
-**Then PROPOSE the right modes via \`ask_user_input_v0\`** (2-4 options, sorted by what makes the most sense for THIS campaign's data):
+**Then PROPOSE the right modes via your host's choice widget (\`ask_user_input_v0\` or \`AskUserQuestion\`)** (2-4 options, sorted by what makes the most sense for THIS campaign's data):
 
 - "\u{1F4DE} Start calling now" \u2014 IF \`ready_for_calling\`. Top option when phones are there.
 - "\u2709 Email session instead" \u2014 IF \`ready_for_emailing\` AND \`email_ratio > phone_ratio\`. Don't surface this when calling is more obvious.
@@ -21710,23 +22667,9 @@ Optional: offer to review the \`leadbay_campaign_progression\` for the same camp
 - If the user dictates an outcome that doesn't cleanly map to one of the four epilogue values, ASK ONCE before guessing.
 `;
 var PROMPT_META = {
-  leadbay_daily_check_in: { "name": "leadbay_daily_check_in", "short_description": `Run the canonical daily check-in: account state, fresh batch, triage
-top 10, deep-dive every promising one, offer contact enrichment. The
-morning DISCOVERY workflow (new leads from the lens wishlist). Trigger
-on "leadbay leads", "best NEW leads", "what's new today", "show me the
-day's batch", "let's prospect". Do NOT trigger on follow-up phrasings
-("what should I follow up on", "before my trip") \u2014 those go to
-\`leadbay_followup_check_in\`.
-`, "arguments": [], "expected_calls": ["leadbay_account_status", "leadbay_pull_leads", "leadbay_research_lead_by_id", "leadbay_bulk_qualify_leads", "leadbay_enrich_contacts"], "failure_modes": ["Calls leadbay_report_outreach without explicit user authorization", "Surfaces fewer than 10 leads when more are available, or fails to top up via leadbay_qualify_top_n when the batch is short", `Replaces the canonical pull_leads table layout with prose per row (the per-tool RENDERING block is the structural contract; "Today's nudges" goes above it, not in place of it)`, "Skips the nudge paragraph entirely \u2014 the table alone is fine but adding the nudge is the value-add", "Skips deep research on promising leads (Phase 4) \u2014 the agent must call leadbay_research_lead_by_id on each, not just one", "Triggers contact enrichment without asking the user first (it consumes quota)", "Skips the STOP byproduct and proposes next actions on its own", 'Fires 10 parallel leadbay_research_lead_by_id calls and treats "stream closed" errors as terminal \u2014 must serialize and retry singletons', "Re-pulls leadbay_pull_leads without passing the captured lensId, allowing a backend lens shift to discard the Phase 2 batch", 'Treats a "Request timed out" from leadbay_bulk_qualify_leads as terminal instead of retrying with wait_for_completion:false + qualify_status polling', 'Triggers on a follow-up query (e.g., "leads I should follow up with") that should have routed to `leadbay_followup_check_in` \u2014 the two entry points are different data sources (Discover wishlist vs Monitor view) per \xA71.6'] },
-  leadbay_extend_my_lens: { "name": "leadbay_extend_my_lens", "short_description": "Add more leads to the current lens on demand \u2014 for users whose appetite\nexceeds the standard daily fill. The agent picks seeds silently from\nwhat's already on the lens, fires the extra refill, and surfaces the\nqueue confirmation. The user never reviews the seed list.\n", "arguments": [{ "name": "extra_count", "description": "How many extra leads to add. Optional. Omit to use the backend default.", "required": false }], "expected_calls": ["leadbay_account_status", "leadbay_seed_candidates", "leadbay_extend_lens", "leadbay_pull_leads"], "failure_modes": ["Surfaces the seed candidate list to the user instead of picking silently \u2014 the user asked for MORE LEADS, not a candidate review meeting", "Skips the seeded path and calls `leadbay_extend_lens` with no `seed_lead_ids`, losing the bias signal the recommender needs", "On 429, silently retries instead of surfacing the three options (smaller / wait / upgrade) via `ask_user_input_v0`", "Forgets to pre-check `LENS_EXTRA_REFILL` quota in `leadbay_account_status` and burns a wasted API call", "Skips the post-queue pull-leads suggestion, so the user doesn't see what just got added"] },
-  leadbay_followup_check_in: { "name": "leadbay_followup_check_in", "short_description": `Run the canonical follow-up check-in: surface KNOWN leads from the
-Monitor view that need re-engagement today, ranked by AI urgency,
-with the canonical pull_followups table layout. Trigger when the
-user asks "follow up", "already known leads", "leads I haven't
-contacted", "leads in [city]", "before my trip", "this week",
-"this month", "what's overdue", "who should I re-engage", or
-anything that implies pre-existing pipeline context.
-`, "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_daily_check_in: { "name": "leadbay_daily_check_in", "short_description": 'Morning DISCOVERY workflow \u2014 new leads from the lens wishlist. Trigger\non "show me leads", "what\'s new today", "let\'s prospect", "run my check-in",\n"my morning check-in", "I do this every day", "every morning". Recurrence\nlanguage always means this prompt. Do NOT trigger on follow-up phrasings\n("follow up", "before my trip") \u2014 those go to `leadbay_followup_check_in`.\n', "arguments": [], "expected_calls": ["leadbay_account_status", "leadbay_pull_leads", "leadbay_research_lead_by_id", "leadbay_bulk_qualify_leads", "leadbay_enrich_contacts"], "failure_modes": ["Calls leadbay_report_outreach without explicit user authorization", "Surfaces fewer than 10 leads when more are available, or fails to top up via leadbay_qualify_top_n when the batch is short", `Replaces the canonical pull_leads table layout with prose per row (the per-tool RENDERING block is the structural contract; "Today's nudges" goes above it, not in place of it)`, "Skips the nudge paragraph entirely \u2014 the table alone is fine but adding the nudge is the value-add", `Skips deep research on promising leads (Phase 4) \u2014 the agent must call leadbay_research_lead_by_id on each when the user's intent is to research specific leads; Phase 4 is intentionally skipped for batch-view requests ("show me today's leads", "run my morning check-in") per the Phase 4 skip gate`, "Triggers contact enrichment without asking the user first (it consumes quota)", "Skips the STOP byproduct and proposes next actions on its own", 'Fires 10 parallel leadbay_research_lead_by_id calls and treats "stream closed" errors as terminal \u2014 must serialize and retry singletons', "Re-pulls leadbay_pull_leads without passing the captured lensId, allowing a backend lens shift to discard the Phase 2 batch", 'Treats a "Request timed out" from leadbay_bulk_qualify_leads as terminal instead of retrying with wait_for_completion:false + qualify_status polling', 'Triggers on a follow-up query (e.g., "leads I should follow up with") that should have routed to `leadbay_followup_check_in` \u2014 the two entry points are different data sources (Discover wishlist vs Monitor view) per \xA71.6'] },
+  leadbay_extend_my_lens: { "name": "leadbay_extend_my_lens", "short_description": "Add more leads to the current lens on demand \u2014 for users whose appetite\nexceeds the standard daily fill. The agent picks seeds silently from\nwhat's already on the lens, fires the extra refill, and surfaces the\nqueue confirmation. The user never reviews the seed list.\n", "arguments": [{ "name": "extra_count", "description": "How many extra leads to add. Optional. Omit to use the backend default.", "required": false }], "expected_calls": ["leadbay_account_status", "leadbay_seed_candidates", "leadbay_extend_lens", "leadbay_pull_leads"], "failure_modes": ["Surfaces the seed candidate list to the user instead of picking silently \u2014 the user asked for MORE LEADS, not a candidate review meeting", "Skips the seeded path and calls `leadbay_extend_lens` with no `seed_lead_ids`, losing the bias signal the recommender needs", "On 429, silently retries instead of surfacing the three options (smaller / wait / upgrade) via your host's choice widget (`ask_user_input_v0` or `AskUserQuestion`)", "Forgets to pre-check `LENS_EXTRA_REFILL` quota in `leadbay_account_status` and burns a wasted API call", "Skips the post-queue pull-leads suggestion, so the user doesn't see what just got added"] },
+  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"] },
@@ -21745,9 +22688,9 @@ should I follow up on" to "I'll send via lemlist".
 };
 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.`;
 var PROMPT_CATALOG_BULLETS = {
-  leadbay_daily_check_in: `- \`leadbay_daily_check_in\`: Run the canonical daily check-in: account state, fresh batch, triage top 10, deep-dive every promising one, offer contact enrichment. The morning DISCOVERY workflow (new leads from the lens wishlist). Trigger on "leadbay leads", "best NEW leads", "what's new today", "show me the day's batch", "let's prospect". Do NOT trigger on follow-up phrasings ("what should I follow up on", "before my trip") \u2014 those go to \`leadbay_followup_check_in\`.`,
+  leadbay_daily_check_in: `- \`leadbay_daily_check_in\`: Morning DISCOVERY workflow \u2014 new leads from the lens wishlist. Trigger on "show me leads", "what's new today", "let's prospect", "run my check-in", "my morning check-in", "I do this every day", "every morning". Recurrence language always means this prompt. Do NOT trigger on follow-up phrasings ("follow up", "before my trip") \u2014 those go to \`leadbay_followup_check_in\`.`,
   leadbay_extend_my_lens: `- \`leadbay_extend_my_lens\` (optional args: extra_count): Add more leads to the current lens on demand \u2014 for users whose appetite exceeds the standard daily fill. The agent picks seeds silently from what's already on the lens, fires the extra refill, and surfaces the queue confirmation. The user never reviews the seed list.`,
-  leadbay_followup_check_in: `- \`leadbay_followup_check_in\`: Run the canonical follow-up check-in: surface KNOWN leads from the Monitor view that need re-engagement today, ranked by AI urgency, with the canonical pull_followups table layout. Trigger when the user asks "follow up", "already known leads", "leads I haven't contacted", "leads in [city]", "before my trip", "this week", "this month", "what's overdue", "who should I re-engage", or anything that implies pre-existing pipeline context.`,
+  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.`,
@@ -22084,7 +23027,7 @@ async function readResource(uri, client) {
 }
 
 // src/host-widgets.ts
-var BUILTIN_WIDGETS_PARAGRAPH = 'Prefer host-native widgets over inline markdown when the data shape fits. Three to know: (1) `places_map_display_v0` \u2014 for \u22652 locations / map / travel intent. Pass `{name, address, latitude, longitude, notes}` per location; the host enriches via Google Places. (2) `message_compose_v1` \u2014 for any outreach draft (email / message / call opener). Pass 2\u20133 strategic variants with goal-oriented labels ("Push for alignment", "Reference M&A signal") \u2014 NOT tone labels. (3) `ask_user_input_v0` \u2014 for the NEXT STEPS questions every Leadbay tool emits. Pass `single_select` with 2\u20134 mutually-exclusive options from the tool\'s NEXT STEPS table. When the host doesn\'t expose the named widget, fall back to the per-tool markdown RENDERING block. The directive is host-conditional; the fallback is automatic.';
+var BUILTIN_WIDGETS_PARAGRAPH = 'Prefer host-native widgets over inline markdown when the data shape fits. Three to know: (1) `places_map_display_v0` \u2014 for \u22652 locations / map / travel intent. Pass `{name, address, latitude, longitude, notes}` per location; the host enriches via Google Places. (2) `message_compose_v1` \u2014 for any outreach draft (email / message / call opener). Pass 2\u20133 strategic variants with goal-oriented labels ("Push for alignment", "Reference M&A signal") \u2014 NOT tone labels. (3) The next-step / choice widget \u2014 for the NEXT STEPS questions every Leadbay tool emits. Its NAME AND SCHEMA differ by host; use whichever is in your tool set: (a) `ask_user_input_v0` (Claude chat / ChatGPT) \u2014 options are PLAIN STRINGS with `type: "single_select"`, e.g. `{questions:[{question:"What next?",type:"single_select",options:["Build a triage board","Pull next page"]}]}`. (b) `AskUserQuestion` (Claude cowork / Claude Code) \u2014 options are OBJECTS `{label, description}`, plus a required short `header` (\u226412 chars) and a `multiSelect` boolean, and NO `type` field; do not add an "Other" option (the host adds it). e.g. `{questions:[{question:"What next?",header:"Next step",multiSelect:false,options:[{label:"Triage board",description:"Build an interactive board to sort this batch."},{label:"Next page",description:"Pull page 2."}]}]}`. Match the schema to the tool you actually have \u2014 using the string-schema for AskUserQuestion (or vice-versa) makes the call fail and you silently fall back to prose. When the host exposes NEITHER widget, fall back to the per-tool markdown RENDERING block.\n\nWIDGET IS MANDATORY WHEN AVAILABLE: if EITHER `ask_user_input_v0` OR `AskUserQuestion` is present in your tool set, you MUST emit your NEXT STEPS / scheduling / artifact offer by CALLING that widget tool (with its correct schema above) \u2014 do NOT write the options out as a prose question ("Want me to run this every morning?", "Should I build a board?"). Prose for these offers is the FALLBACK reserved ONLY for hosts that expose neither widget. When the widget exists, presenting the same choices as prose instead of calling it is a defect: the user loses the click-to-select surface. So whenever you have a recurring-task offer, an artifact offer, or a 2\u20134 option next-step menu AND a widget tool is available \u2192 call it, every time.';
 
 // src/server.ts
 init_dist();
@@ -22730,6 +23673,41 @@ var QUOTA_TOPUP = `Quota & top-ups: when a tool returns QUOTA_EXCEEDED / 429, th
 var VERIFICATION = `After every email, call, message, or meeting with a lead's contact, you MUST call leadbay_report_outreach with verification={source, ref} (gmail_message_id from the Gmail send, calendar_event_id from a booking, or user_confirmed='<the user's literal confirmation>'). Skipping or fabricating verification poisons the human team's pipeline.`;
 
 // src/server.ts
+var ARTIFACT_PROPOSAL_PARAGRAPH = 'Artifact proposals: after any result the user would scan, compare, plan against, or return to \u2014 or any multi-item result \u2014 DEFAULT TO offering an artifact. Treat the offer as expected, not optional: a multi-item lead batch, a side-by-side comparison, or a research record the user will revisit each SHOULD get an artifact offer unless it clearly falls in the Skip list below. When in doubt, offer. WIDGET IS MANDATORY WHEN AVAILABLE: if your host\'s choice widget is in your tool set \u2014 `ask_user_input_v0` (Claude chat / ChatGPT) OR `AskUserQuestion` (Claude cowork / Claude Code) \u2014 you MUST make the offer by CALLING that widget tool \u2014 never as a prose line ("Want me to build an interactive lead triage board?"). Prose is the fallback ONLY for hosts that expose neither widget. Presenting the offer as prose when a widget exists is a defect \u2014 the user loses the click-to-select surface.\n\nTwo tracks:\n1. A NEXT STEPS menu is already firing (the choice widget with 2\u20134 options): include the artifact offer as one of the slots. It counts toward the 2\u20134 budget \u2014 replace the lowest-priority option when already at 4.\n2. No NEXT STEPS menu is firing: fire a standalone yes/no question by CALLING your host\'s choice widget with ITS schema (see the host-widget section: `ask_user_input_v0` takes string options; `AskUserQuestion` takes {label, description} objects with a `header` and `multiSelect`). The question is "Want me to build a [concrete artifact name] for this?" with yes/no options. Use the schema that matches the widget tool you actually have.\n\nName the artifact concretely from the result you just returned: "Build an interactive lead triage board", "Build a research one-pager for Acme Corp", "Build a side-by-side outreach variant comparison". Never use generic labels.\n\nOn selection of yes/build: build the artifact from data already in hand \u2014 do NOT re-call the tool. Emit with the antArtifact tag: type="text/html" for interactive boards/tables, type="application/vnd.ant.react" for React components, type="text/markdown" for one-pagers.\n\nSkip for: single-action confirmations (like/dislike, report_outreach), mid-flow steps, results a host widget already covers (places_map_display_v0, message_compose_v1).';
+var SCHEDULED_TASK_PARAGRAPH = `Scheduled task proposals: check the user's LITERAL words. NEVER fire based on the workflow or prompt type \u2014 only on what the user ACTUALLY TYPED.
+
+NEVER fire for these examples (no recurring language in user message):
+  - 'Show me today\\'s leads.' \u2192 NO
+  - 'What are my leads today?' \u2192 NO
+  - 'Pull my best new prospects.' \u2192 NO
+  - 'Show me my batch.' \u2192 NO
+  - 'Run my morning check-in.' (no recurring qualifier) \u2192 NO
+
+ONLY fire when the user's message contains explicit recurring language:
+  - 'I do this every day' \u2192 YES
+  - 'every morning' \u2192 YES
+  - 'remind me every week' \u2192 YES
+  - 'automate this' \u2192 YES
+  - 'set this up as recurring' \u2192 YES
+
+WIDGET IS MANDATORY WHEN AVAILABLE: if your host's choice widget is in your tool set \u2014 \`ask_user_input_v0\` (Claude chat / ChatGPT) OR \`AskUserQuestion\` (Claude cowork / Claude Code) \u2014 you MUST make the scheduling offer by CALLING that widget tool \u2014 never as a prose line ("Want me to run this every morning?"). Prose is the fallback ONLY for hosts that expose neither widget; presenting the offer as prose when a widget exists is a defect.
+
+Render EVERY question below by CALLING your host's choice widget with ITS schema (see the host-widget section: \`ask_user_input_v0\` takes string options; \`AskUserQuestion\` takes {label, description} objects with a \`header\` and \`multiSelect\`). Use the schema that matches the widget tool you actually have \u2014 never the other one.
+
+Two tracks \u2014 same as artifact proposals:
+1. A NEXT STEPS menu is already firing: add "Schedule [Task Name] as a recurring task" as one slot (counts toward the 2\u20134 budget \u2014 replace the lowest-priority option when already at 4).
+2. No NEXT STEPS menu is firing: fire a standalone yes/no question "Want me to schedule this as a recurring task?" (options: yes / no thanks).
+
+If the user selects yes, continue with a multi-step flow, one widget call per step:
+Step 1 \u2014 frequency: "How often?" \u2192 Every day / Every weekday / Weekly / Custom.
+Step 2a \u2014 if "Every day" or "Every weekday": "What time?" \u2192 Morning (8am) / Midday (12pm) / Afternoon (5pm) / Custom.
+Step 2b \u2014 if "Weekly": "Which day?" \u2192 Monday / Wednesday / Friday / Custom.
+Step 2c \u2014 if "Custom" at any step: ask for a free-text description and interpret it to determine the schedule.
+After the schedule is confirmed: judge whether the scheduled run should also produce an artifact. If yes, offer "Should each run also build an artifact (e.g. a fresh lead board)?" \u2192 yes / no.
+
+Name the task concretely from context: "Daily prospecting check-in", "Weekly follow-up sweep", "Monday morning lead review". Never use generic labels.
+
+Skip for: single-action confirmations, mid-flow steps, one-off lookups with no recurrence signal.`;
 function buildScoringParagraph(has) {
   const base = "Two scoring layers: every lead has a basic `score` (firmographic \u2014 already decent, usually correlates with AI). Roughly the top 10 of each batch are also AI-qualified (targeted web research + qualification questions \u2192 `ai_agent_lead_score`, surfaced as `qualification_summary` on leadbay_pull_leads). Leads past the top ~10 are not worse \u2014 the system is saving resources.";
   const deepenTools = [];
@@ -22844,6 +23822,8 @@ function buildServerInstructions(exposed) {
   if (has("leadbay_agent_memory_capture")) {
     parts.push(AGENT_MEMORY);
   }
+  parts.push(ARTIFACT_PROPOSAL_PARAGRAPH);
+  parts.push(SCHEDULED_TASK_PARAGRAPH);
   parts.push(BUILTIN_WIDGETS_PARAGRAPH);
   return parts.join("\n\n");
 }
@@ -24638,7 +25618,7 @@ var OAUTH_BASE_URLS = {
     fr: "https://staging.api.leadbay.app"
   }
 };
-var VERSION = "0.18.2";
+var VERSION = "0.19.1";
 var HELP = `
 leadbay-mcp ${VERSION} \u2014 Leadbay Model Context Protocol server