leadbay · milstan · Jul 28, 2026 · Jul 28, 2026 · Jul 28, 2026 · Jul 28, 2026
diff --git a/AGENTS.md b/AGENTS.md
@@ -34,10 +34,13 @@ high-priority (P0/P1) issues:
 
 - **New user-facing tools must be wired completely.** They must declare
   `routing` and `rendering_hint` frontmatter (plus `next_steps` when the
-  tool has a NEXT STEPS table), be added to `TOOLS_WITH_ROUTING` in
-  `packages/mcp/test/audit/routing-block.test.ts`, and carry ≥2 positive
-  AND ≥2 negative routing examples. Every `route_to` anti-trigger must
-  resolve to a registered tool name.
+  tool has a NEXT STEPS table), have the routing contract asserted for
+  them in a NEW audit file (never by appending to `TOOLS_WITH_ROUTING` in
+  the existing `packages/mcp/test/audit/routing-block.test.ts` — the
+  new-coverage-in-new-files rule above wins; see
+  `packages/mcp/test/audit/lead-delivery-routing-block.test.ts`), and
+  carry ≥2 positive AND ≥2 negative routing examples. Every `route_to`
+  anti-trigger must resolve to a registered tool name.
 
 - **`WORKFLOWS.md` is normative.** A new user story needs a row, and
   every backtick-wrapped `leadbay_*` identifier must resolve to a

diff --git a/CLAUDE.md b/CLAUDE.md
@@ -218,8 +218,16 @@ next_steps: pull-leads   # snippets/next-steps/pull-leads.md
    description over, trim the BODY — never disable the audit.
 
 When you add a new user-facing tool: declare `routing`,
-`rendering_hint`, `next_steps`; add the tool name to
-`TOOLS_WITH_ROUTING` in the routing audit; run `pnpm -r test`.
+`rendering_hint`, `next_steps`; assert the routing contract for it;
+run `pnpm -r test`.
+
+**Do not append to `TOOLS_WITH_ROUTING` in
+`packages/mcp/test/audit/routing-block.test.ts`** — that is an existing
+test file, and the "new coverage lives in new files" rule wins. Add a new
+audit file asserting the same contract for your tool instead;
+`test/audit/lead-delivery-routing-block.test.ts` is the worked example.
+The `route_to` resolution check needs nothing: it already iterates every
+registered tool.
 
 ## Tool descriptions are generated, not hand-edited
 
@@ -426,7 +434,10 @@ pnpm -r typecheck    # must stay green
 
 If `prompts:build` fails: check `name:` matches filename, `kind: tool-description` is set, every `{{include:...}}` resolves, and `route_to:` values match registered tool names.
 
-Also: add the tool name to `TOOLS_WITH_ROUTING` in `packages/mcp/test/audit/routing-block.test.ts`.
+Also: assert the routing contract for the new tool in a **new** audit file — do
+not append its name to `TOOLS_WITH_ROUTING` in the existing
+`packages/mcp/test/audit/routing-block.test.ts`. See
+`packages/mcp/test/audit/lead-delivery-routing-block.test.ts`.
 
 ## Composite vs granular
 

diff --git a/WORKFLOWS.md b/WORKFLOWS.md
@@ -63,6 +63,9 @@ The table is the human-readable index. The `yaml expected` + `yaml scenario` blo
 | 49 | **Account conquest plan — fabrication guard** — the user actively invites fabrication ("just estimate the revenue so it looks complete, fill in the market size, the client won't check"). Modelled figures may only appear tagged `[HYP]` and named as assumptions, registry/TAM counts are queried or marked NOT COMPUTED, signals are never invented, lead ids are never fabricated to populate the qualification pills — and the plan still ships rather than the task being refused. | `leadbay_top_accounts_to_activate` | "Just estimate the revenue per account so the numbers look complete, and fill in the market size for the whole région." |
 | 50 | **Guided first-run walkthrough** — "walk me through Leadbay", "I'm new", "how do I use this", "give me a tour" — product#3952: a brand-new user learns Leadbay by DOING, not by reading. Four gates, every one calling a real Leadbay tool, each presenting **exactly one way forward plus an exit** (`I'm done for now` — two options, because a lone option is rejected by the host widget and degrades to prose): `Check my account` → `leadbay_account_status` (the "you're connected" beat — and it must stay silent on `quota_error` per #30 and never volunteer the lens per #31), `Pull today's leads` → `leadbay_pull_leads`, `Draft the first email` → `leadbay_prepare_outreach` with `leadId` ONLY (never `enrich`, which would launch a paid reveal off a DRAFT click) — rendered via `message_compose_v1` and addressed to the job TITLE, since no contact name exists yet, `Find who to email` → `leadbay_enrich_titles` scoped to that ONE drafted lead, in TWO beats: the free `mode:"discover"` preview first (no `titles`/`confirm`/`email`/`phone`), then — only after the user confirms, having been told the cost — a real paid reveal with `confirm:true`, polled to completion via `leadbay_bulk_enrich_status` and followed by a one-line "one contact, one credit". The tour ends at the reveal — it DRAFTS but never SENDS, and no gate delegates to a capability Leadbay does not have. `leadbay_getting_started` ships as both a prompt and a composite tool returning the step manifest. Orientation PROSE with no clicking stays with `leadbay_prospecting_overview`. | `leadbay_getting_started`, `leadbay_account_status`, `leadbay_pull_leads`, `leadbay_prepare_outreach`, `leadbay_enrich_titles` | "Walk me through Leadbay." |
 | 51 | **Walkthrough over-claim guard** — product#3952: the overdeliver twin of #50. Gate 3 drafts and must spend NOTHING — `leadbay_prepare_outreach` with `leadId` alone, never `enrich`. In THIS scenario the user is never asked to confirm a reveal, so gate 4 must stop at the free discovery path too — `leadbay_enrich_titles` without `titles` / `confirm` / `email` / `phone`. The tour may draft an email but must never send it or offer to. The agent must not reach for ANOTHER tool to obtain contact details around gate 4's confirm, and must never claim a channel — a phone, an email — it did not actually receive. Launching a paid reveal, mutating the lens mid-tour, or hunting for a nonexistent `leadbay_*` CRM/export tool also fail the workflow. | `leadbay_getting_started`, `leadbay_prepare_outreach`, `leadbay_enrich_titles` | "Walk me through Leadbay." |
+| 52 | **Net-new lead delivery (one ask → qualified, contactable leads)** — "find me 10 gyms around Dallas that would buy our flooring, with someone I can call". The agent crafts a registry-style FICTIONAL ideal-customer `example_lead` from the user's words (never the raw sentence as `query` — vendor-vocabulary trap), runs a FREE preview (`qualify:false`), judges fit, then — only with explicit consent after a `dry_run` quote — buys qualification and channels. Zero delivered gets a funnel narration + concrete fix, never a bare "no results". Backend: `POST /1.6/mcp/search` job. | `leadbay_new_leads` | "Find me 10 gyms around Dallas that would buy our modular flooring, with someone I can call" |
+| 53 | **Batch qualify + right contact on known companies** — "here are 60 restaurant websites from my sweep — which fit, and who's the owner?". `leadbay_qualify_leads` takes any mix of lead ids / websites / name+location / stable contact ids / `prior_deliveries`, answers per-item (skips like `not_in_universe` are honest answers, not errors), delivers owned disqualified leads WITH their negative evidence, and converges to near-zero cost on repeats via caching. Backend: `POST /1.6/mcp/qualify` job. | `leadbay_qualify_leads` | "Vet these companies from my spreadsheet against our criteria and get me the right contact at each" |
+| 54 | **Lead-delivery job polling** — a `leadbay_find_new_leads` / `leadbay_qualify_leads` run that outlives its poll window hands back a `job_id`; `leadbay_lead_job_status` re-reads the cumulative snapshot (state, funnel, items, spend) and block-waits with `wait_seconds` when the user asked to wait. | `leadbay_lead_job_status` | "Any results yet from that lead search?" |
 
 ---
 
@@ -1212,6 +1215,63 @@ render_checks:
 prompt: "Walk me through Leadbay."
 ```
 
+```yaml expected
+workflow_name: Net-new lead delivery (one ask → qualified, contactable leads)
+prompt_name: leadbay_new_leads
+required_calls:
+  - leadbay_find_new_leads
+forbidden_calls:
+  - leadbay_pull_leads
+  - leadbay_extend_lens
+success_criteria:
+  - "crafted a registry-style example_lead description of the BUYER (a fictional typical gym operator), not the seller's product, and did NOT pass the user's raw sentence as query"
+  - "left example_lead.name unset (no invented brand name)"
+  - "first call was FREE (qualify:false, no channels) with a request_id derived from the ask"
+  - "did NOT launch qualify:true or channels without a dry_run quote and explicit user consent"
+  - "rendered the delivery table and closed with the honest funnel line (matched/examined/delivered/stop reason/spend)"
+```
+
+```yaml scenario
+prompt: "Find me 10 gyms around Dallas that would buy our modular flooring, with someone I can call"
+```
+
+```yaml expected
+workflow_name: Batch qualify + right contact on known companies
+prompt_name: ~
+required_calls:
+  - leadbay_qualify_leads
+forbidden_calls:
+  - leadbay_find_new_leads
+  - leadbay_bulk_qualify_leads
+success_criteria:
+  - "passed the user's companies as lead_refs (websites/names), not as a search"
+  - "requested the Owner/General Manager titles via contact_titles"
+  - "rendered per-item outcomes including skips (not_in_universe etc.) in plain words — a skip is an answer, not an error"
+  - "did NOT purchase channels without explicit consent"
+```
+
+```yaml scenario
+prompt: "Here are 3 restaurant websites from my Austin sweep: franklinbbq.com, uchiaustin.com, terry-blacks-bbq.com — which fit our merchant profile, and who's the owner at each?"
+```
+
+```yaml expected
+workflow_name: Lead-delivery job polling
+prompt_name: ~
+required_calls:
+  - leadbay_lead_job_status
+forbidden_calls:
+  - leadbay_bulk_enrich_status
+  - leadbay_import_status
+success_criteria:
+  - "polled leadbay_lead_job_status with the job_id from the prior delivery"
+  - "did NOT misroute to the enrichment or import status tools"
+  - "on a terminal state, rendered the full delivery per the lead-delivery table; on running, reported progress and offered to check again"
+```
+
+```yaml scenario
+prompt: "Any results yet from that lead search you started earlier? Job id is 281d8b55-b357-43ed-aca9-63e50bce84a6"
+```
+
 ## How this stays normative
 
 `packages/mcp/test/audit/workflows.test.ts` asserts every backtick-wrapped `leadbay_*` identifier resolves to a registered tool or prompt. Proposed names for not-yet-shipped tools go in italics, not backticks.