[bug] lead_finder cannot sweep a capital city: raw addressComponents push the flatten step's journal entry over the 1MiB Workflow limit

[serge-ivo]

lead_finder cannot sweep a capital city: the raw addressComponents arrays make the flatten step's journal entry exceed 1MiB

Three pipeline-run errors, all on instance 933ebec5…, read back today via list_errors:

2026-08-03 08:08 pipeline "lead_finder" crashed: WorkflowInternalError: Step s3-flatten-1 output is too large. Maximum allowed size is 1MiB.
2026-08-03 06:49 pipeline "lead_finder" crashed: WorkflowInternalError: Step s4-map-1 output is too large. Maximum allowed size is 1MiB.
2026-08-03 06:32 pipeline "lead-finder" crashed: WorkflowInternalError: Step s3-map-1 output is too large. Maximum allowed size is 1MiB.

list_pipeline_runs names the cities: the two failures with a city param are Sydney, NSW and
Brisbane, QLD. Every completed sweep is Hobart (116 places) or Launceston (83), both at
radius: 900. This is the one catalog card promising a general capability — "Search by city and
business type" — that fails on the first city a visitor would try.

Root cause, confirmed against the code

Not "the payload grows with the city" in general. It is one field, and one property of the runner.

A StepResult carries its payload twice. Every step handler returns pretty-printed JSON
(steps.ts:510 — ok(JSON.stringify({ items: out, count: out.length }, null, 2))), and
executePipelineStep ALSO stores the parsed value (pipeline.ts:436, output: parseOutput(r.content)).
capStepOutput measures JSON.stringify(result) (pipeline.ts:88), so a step's journal entry is
roughly 3× the records it holds. A forEach step is the exception: its content is "25 item(s)"
(pipeline.ts:431), so the fan-out carries ~1×. That is exactly why flatten — which holds the same
data as the fan-out that fed it — is the first step to fail, and why the production error names
s3-flatten-1 rather than the http_request above it.

The size is structural, not unlucky. extentKm: 2 / stepKm: 1 → gridCells yields 25 cells
(steps.ts:295), each requesting maxResultCount: 20, so a dense city returns 500 places and
cannot return more. Hobart's 116 fit; 500 do not.

addressComponents is 73% of the bytes. The responseMap projected Google's raw typed-component
array onto every record so the map step could extract city/state/suburb/country from it. Measured
on a 500-place fixture with the component arrays Google actually returns: the flatten step's
StepResult is 1681KB with them and 459KB without. capStepOutput's bound is 900KB.

Where the audit's prescription was wrong

#64 diagnosed the mechanism correctly (unbounded payload, slice unused) but prescribed "add slice
after flatten". That would not have fixed the reported failure: flatten is the step that
fails, and a later step cannot shrink an earlier step's journal entry. A slice there would have
bounded map, enrich, filter and the sink while the run still died at s3-flatten-1 on Sydney.

The fix has to move the bulk before the first non-forEach step — i.e. into the connector's own
responseMap, which runs inside the fan-out where the payload is only counted once.

What it does not claim

• I did not read the live instance's pipeline definition. No read-only MCP tool returns one. Two
  facts say the live copy differs from workers/api/src/lib/pipelines/lead-finder.json: the completed
  runs report "8 step(s)" where the reference has 9, and the 06:49 run failed at s4-map-1 after
  s3-flatten succeeded, which is only possible if its map output is larger than its flatten
  output — i.e. that map does not narrow with keep. The mechanism above is asserted for the
  reference definition, which I ran; the live one is inferred from step indices and counts.
• I have not measured a real Sydney response. The 500-place fixture uses the component array shape
  Google documents and returns, not a captured body.

Also true, and separate: since #381 the live pipeline cannot start at all

lead-finder.json names http_request, which is connector-provided (connectors/registry.ts:99,
HTTP_TOOLS), so it is gated by the declared-tools rule. declaredToolsFor maps an agent that
resolves but declares nothing to an empty array — a real assertion, not an absent one
(pipeline-tool-policy.ts) — and undeclaredToolRefusal then refuses (tool-refusal.ts:55).
startPipelineRun applies it before the run opens.

list_instance_tools(933ebec5…, allowed_only: true) returns seven tools today —
start_work, check_work, get_behaviour, set_behaviour, get_stats, set_stats_card,
run_pipeline — and no http_request. So lead_finder is refused at kick regardless of city.

This is live data and I have not touched it. The owner must add http_request to the
small-business-website-lead-finder agent's capabilities.tools:

PUT /v1/agents/<id> { "config": { … , "capabilities": { … , "tools": ["http_request"] } } }

Everything else the pipeline dispatches — geocode, fan_out, flatten, slice, map, enrich,
filter, dedupe_upsert, http_reachable — is step-library and connector-less, so it is exempt.
Note that a declared tools list is authoritative and replaces the surface default, so it must also
name any other connector tool the agent uses.

Fix

In workers/api/src/lib/pipelines/lead-finder.json:

1. Project the four geo strings in the responseMap (country:addressComponents[types~=country].longText,
   and the three siblings) instead of passing the raw arrays down the chain; drop the now-redundant
   extract from the map step. The getPath type-predicate from map/responseMap: type-predicate selection for Google addressComponents (child of #94) #116 already works inside a
   responseMap projection, so this is a config change, not a new primitive.
2. Add slice after flatten and before enrich — bounding the payload is only half of it; the
   enrich step is one HTTP probe per place, so a cap after it would leave the spend unbounded.
3. Give the cap a home and a default. A slice whose limit is an unsupplied $param resolves
   to undefined, and an absent limit means keep everything — so the one step that bounds the run
   silently stops bounding it whenever the wiring omits the param.
4. Say what the cap left. A run that quietly keeps the first N closes completed with tidy
   counts over a city it only partly looked at, and seen counts what was examined — so a capped
   Sydney and a complete Hobart are indistinguishable without a line that says so.

Source: the #64 catalog audit, finding 2. Verified against main at 7332a5e.
Seeding the definition onto the agent row (#64 finding 1) is deliberately not part of this — it is a
change to live catalog data, and the crash is fixable in the reference definition on its own.

[serge-ivo]

Account-wide audit: which live agents the #381 gate refuses, and the exact declaration each needs

Read-only. Nothing in the account was modified. Enumeration was done through the MCP server per
AGENTS.md; the rule was derived from lib/tool-refusal.ts + lib/pipeline-tool-policy.ts rather
than from the issue text.

Answer: one agent is refused, one is clean, one is clean-and-unreachable. The lead_finder
refusal reported in the issue body is confirmed independently below, and it is the only one in the
account — but the reason it is the only one is that the account contains almost no pipelines, not
that the gate is narrow.

The rule, as the code states it

undeclaredToolRefusal(name, declaredTools, connector) refuses iff all three hold:

1. the caller resolved an allowlist (declaredTools is an array, not undefined),
2. the tool carries a connector field, and
3. the allowlist does not name it.

declaredToolsFor maps a capability lookup that succeeded to capabilities.tools ?? []. So
"the agent declares nothing" is an empty array — a real assertion, not an absent one. Only a
lookup that returns null yields undefined, and capabilitiesForInstance returns null only when
the instance row is missing. In practice: every live instance asserts an allowlist, and for an
agent that declared no tools that allowlist is empty.

Condition 2 is the exemption. connectorTools() stamps connector on every connector tool;
FIRST_PARTY_TOOLS (which includes create_ticket and all of STEP_TOOLS) carry none. So
map / filter / flatten / slice / dedupe_upsert / fan_out / enrich / geocode /
http_reachable / extract_contacts / parse_json / ai_generate / create_ticket can never be
refused — and can never be declared either.

What is actually wired in this account

	count	detail
Agents owned (my_agents)	40	only one has config.pipelines: site-builder
Instances (my_instances)	27
Instances with any pipeline run history	2	933ebec5… (lead finder), 3c09069a… (outreach)
Triggers, all instances	1	facebook-friend-confirmer, cron @daily, action run_browse — not a pipeline
Connections, all instances	1	933ebec5… --lead.created--> 3c09069a… → run_pipeline: draft_outreach

list_instance_triggers and list_connections were called for all 27 instances;
list_pipeline_runs for all 27. Everything not listed above returned empty.

Verdicts

Step tools were read from the live runs via agent_trace (each pipeline.step event carries
context.tool), not from the reference JSON — the live definitions are not readable through any
read-only MCP tool, and for lead_finder they demonstrably differ from lib/pipelines/lead-finder.json.

Agent / instance	Pipeline	Tools its steps dispatch	Connector-provided (gated)	capabilities.tools today	Verdict	Must declare
small-business-website-lead-finder 4d9945ab… / inst 933ebec5…	lead_finder (8 steps)	geocode, fan_out, http_request, flatten, map, enrich, filter, dedupe_upsert	http_request (connector http)	agent config is {} → resolves to tools: undefined → asserted []	REFUSED at kick	http_request
same instance	pump_test (1 step)	dedupe_upsert	none	[]	CLEAN	—
lead-outreach-tj6qrr bf1de46a… / inst 3c09069a…	draft_outreach (3 steps)	map, ai_generate, dedupe_upsert	none	agent config is {} → []	CLEAN	— (see the narrowing warning)
site-builder agent_site_builder	site-builder (21 steps), site-deploy (4)	incl. http_request, web_search, mcp_call_tool	those three	["http_request","web_search","mcp_call_tool"] (migration 0096)	CLEAN	—

The control case checks out: I read the live agents.config.pipelines for site-builder and
extracted every step's tool. The gated set is exactly {http_request, web_search, mcp_call_tool}
and 0096 declares exactly those three. But that agent has zero subscribed instances — nothing
can run its pipelines today either way.

Two independent confirmations of the lead_finder refusal:

• list_instance_tools(933ebec5…, allowed_only:true) returns seven tools —
  start_work, check_work, get_behaviour, set_behaviour, get_stats, set_stats_card,
  run_pipeline — and no http_request. list_instance_tools(3c09069a…) returns the same seven.
• agent_trace on run 119a3933… shows {"step":2,"tool":"http_request","bind":"pages"}, so the
  live definition really does name it.

No refusal has fired in production yet

list_errors (50 rows, back to 2026-07-10) contains no not_declared refusal. The last
pipeline run in the account was 2026-08-06 04:39; the API Worker carrying b11a740 deployed at
2026-08-07 23:46 UTC (run on a5e2e8a, "Deploy API Worker" success). The refusal is
prospective — the next lead_finder kick is the first one that will hit it. The three
pipeline-run errors in the log are the 1MiB journal crashes this issue is about, not the gate.

The declarations, copy-pasteable

Only small-business-website-lead-finder needs one. Its config is {} today, so a tools-only
patch leaves surfaces/runtime/workflow resolving exactly as they do now (the fallback
derivation branch, {surfaces:[], runtime:null, workflow:null}).

Minimum that un-refuses the pipeline — but read the warning below before applying it:

update_agent agent_id: 4d9945ab-26b2-4476-b9c1-89b7f4426f35
 capabilities: { "tools": ["http_request"] }

What I actually recommend applying instead — same fix, no chat regression:

update_agent agent_id: 4d9945ab-26b2-4476-b9c1-89b7f4426f35
 capabilities: { "tools": [
 "http_request",
 "search_knowledge","list_knowledge","read_knowledge",
 "add_knowledge","update_knowledge","delete_knowledge",
 "upload_file","list_files","read_file","delete_file",
 "create_collection","list_collections","insert_record","query_records","update_record"
 ] }

(equivalently PUT /v1/agents/4d9945ab-.../ {"capabilities":{"tools":[…]}} — the route
patch-merges and re-validates through sanitizeDeclaredCapabilities.)

Narrowing risk — this is the part to read before applying anything

Declaring a tools array is authoritative. toolNamesFor branches on declared?.length: a
non-empty list means the agent gets BASE plus exactly those catalog names, replacing the
per-surface default. For an agent with surfaces: [] that default is FULL — BASE + KB read +
KB write + files + collections (+ the legacy apply/coding names).

So the one-line ["http_request"] fix would silently strip the lead finder's chat down to BASE +
http_request, and its chat is observably using the tools it would lose. From agent_trace
(source: chat) on that instance:

• ✅ query_records { "total": 116, … } — the "how many leads have website_status none" answer
• ✅ list_collections, ✅ list_knowledge, ✅ read_knowledge

(read_memory, also in that transcript, is BASE and survives either way.)

Applying the minimum declaration turns "116 total, 95 with no website, 9 in Richmond" back into the
answer it gave before it had those tools, in the same transcript: "I got that number from the
knowledge base documents … the summary lines at the top of each city document." That is the
regression, and it is a quiet one — the agent keeps answering, it just goes back to estimating.

The recommended list above is FULL minus two groups that are junk on a cloud-only lead agent:
submit_job_application (legacy, and not in TOOL_CATALOG so it cannot be declared at all) and the
coding runtime trio (list_coding_repos, read_terminal, send_to_cli). If you want those too,
add them; if you want a genuinely tighter agent, drop the KB-write and files names — but do that as
a deliberate decision, not as a side effect of fixing the pipeline.

Do NOT declare anything on lead-outreach-tj6qrr. Its pipeline touches no connector tool, so it
is clean as-is. Declaring a list there would be a pure narrowing with no benefit.

Second-order finding: three exempt steps nest http_request, and the kick check cannot see it

The gate lives in runRegistryTool, so it applies to nested dispatches. Three step-library tools
dispatch a connector tool from inside their handler:

• geocode → runRegistryTool("http_request", ctx, …) (steps.ts:786) — unconditional
• fan_out in pages mode → runRegistryTool("http_request", ctx, …) (steps.ts:663)
• enrich → runRegistryTool(<tool from input>, ctx, …) (steps.ts:706)

pipelineDeclarationError reads only each step's own tool field, by design and with the reason
stated in its docstring. The consequence is that a pipeline built entirely from exempt steps can
pass the kick check and then be refused mid-run — the half-completed run the commit message says
it wants to avoid, reached by a different door. lead_finder is not that case (it names
http_request at step 2, so it is refused up front), but note its step 0 is geocode: the same
declaration is needed twice over, and dropping the explicit http_request step would not remove the
requirement.

Worth considering: have the kick check also treat geocode and fan_out as implying
http_request, or move the early warning to report what the run would dispatch rather than what
its steps are named.

What I could not determine

• Live pipeline definitions. No read-only MCP tool returns one, and per AGENTS.md I did not go
  around MCP to a private route or D1. Step tools above are reconstructed from pipeline.step trace
  events on real runs, which gives each step's own tool but not the inner tool an enrich step
  dispatches — that is a value inside an input template and is never logged. For lead_finder
  step 5, the reachable values carried into the outreach runs ({"ok":false,"code":526},
  "Only https URLs allowed", "url is required.") match http_reachable's output contract
  exactly, so I read it as http_reachable (exempt). If it is in fact http_request, the
  declaration above already covers it; if it is some third connector tool, it would be an
  additional refusal I cannot see.
• Pipelines attached but never run. A definition that has never been kicked leaves no run row,
  no trigger and no connection, so it is invisible to every read-only surface. The two instances
  above are every instance with run history; I cannot rule out a dormant attached definition
  elsewhere.
• Other users' agents. Scope was this account (list_errors scope me).

Method note for anyone repeating this: my_agents returns the raw config column, so an agent's
declared pipelines and capabilities.tools are both readable in one call — that is how the
site-builder control was verified without touching anything.

[serge-ivo]

Picked this up for implementation and found it already delivered — shipped in 6b37070, which is on main and deployed.

All four numbered items of the Fix section are in lib/pipelines/lead-finder.json on main, and the diagnosis the issue argued for is the one that shipped:

1. The four geo strings are projected in the connector's responseMap — country:addressComponents[types~=country].longText and its three siblings — so the raw component arrays never cross a step boundary, and the now-redundant extract is gone from the map step. This is the part that actually fixes the reported crash, and the commit takes the issue's correction of [Catalog] Audit every published agent — keep / fix / unpublish #64 head-on: a slice after flatten could not have worked, because flatten is the step that fails and no later step shrinks an earlier step's journal entry.
2. slice sits between flatten and enrich (bind: "bounded") — kept for the other half of its job, since enrich is one HTTP probe per place and a cap after it would bound the payload while leaving the spend unbounded.
3. The cap has a home and a default — max_places is a declared param with default: 300, and startPipelineRun now resolves params as caller > subscriber setting > declared default, which closes the "an unsupplied $param resolves to undefined and an absent limit means keep everything" hole exactly as the issue described. Side effect worth noting: this is the first time a settingsSchema knob reaches a pipeline at all — settings previously reached only the chat prompt.
4. The run says what the cap left — twice. A warn-level pipeline.capped trace event, and a clause appended to the run's detail line: "slice examined 300 of 500 record(s) — 200 were left unexamined by the cap." Without it a capped Sydney and a complete Hobart close completed with indistinguishable counts, since seen counts what was examined.

The regression test is the fixture the issue said was missing: 25 cells × 20 places with the component arrays Google actually returns, projected through the definition's own responseMap rather than a hand-written restatement of it. Reverted, it fails with the production sentence naming step 3 (flatten) at 1681KB against the 900KB bound — which also confirms the 1681KB / 459KB measurement in the issue body. lead-finder.test.ts (14 tests) is green on current main, as is pipeline-run-start.test.ts (17) and the rest of the group (79 total).

What is still outstanding, and it is not code. The issue's "Also true, and separate" section stands: the live small-business-website-lead-finder agent declares no capabilities.tools, so since #381 lead_finder is refused at kick regardless of city. The commit deliberately did not touch it — that is live catalog data, and the crash was fixable in the reference definition on its own. The declaration to apply, and the narrowing warning that goes with it (a non-empty tools array is authoritative and would strip that agent's chat down from the permissive default, which is observably using query_records / list_collections / read_knowledge), is in the audit comment above. That is an owner action on production data, not a repo change.

Two further things the commit names as reported-here-but-not-changed, so they do not get lost: it does not seed the definition onto the agent row (#64 finding 1), and it does not fix site-builder's settings, whose ids are snake_case while its params are camelCase, so the new settings→params bridge does not reach them.

Closing as delivered — the code fix is complete; the live declaration above is the remaining step and belongs to the account owner.

[serge-ivo]

Reopening: the definition half of this fix landed in a file production never loads, and Sydney is still unfixed

6b37070 is good work and its own commit message is honest about the gap — "It does not touch the
live instance's own copy of the pipeline, which no read-only tool returns and which demonstrably
differs from the reference". I re-checked that today and it is worse than a caveat: the change
that fixes the crash cannot reach any user, present or future, and the storefront still sells the
capability.

Verified today, against production and main @ 0b4afd0

1. The reference JSON has no production loader. Two importers of
workers/api/src/lib/pipelines/lead-finder.json exist in the whole tree, both tests:
step-dispatch.test.ts:19 and pipelines/lead-finder.test.ts:15. No migration seeds it — grep -l
over workers/api/migrations/ returns nothing, and the sibling that is seeded (site-builder,
migration 0057) has pipelines/seed-drift.test.ts precisely to stop the reference and the SQL
drifting. lead-finder has no such pairing because it has no SQL.

2. The live pipeline is a different pipeline. GET /v1/instances/933ebec5…/pipelines:

{"pipelines":[{"name":"lead_finder","steps":8,"sink":"leads","valid":true},
 {"name":"pump_test","steps":1,"sink":"leads","valid":true}]}

8 steps. The reference is now 10 (geocode · fan_out · http_request · flatten · slice · map · enrich · map · filter · dedupe_upsert). It is also named lead_finder, not lead-finder. The two
steps the fix added — slice, and the second map that follows the responseMap reshape — are the
two the live copy is missing.

3. Every completed run since the fix still reports 8 steps. GET …/pipeline-runs:

2026-08-06T04:38Z lead_finder completed Launceston, TAS seen 83 "8 step(s), 45 → leads, 38 updated"
2026-08-04T14:09Z lead_finder completed Hobart, TAS seen 116 "8 step(s), 64 → leads"
2026-08-03T08:03Z lead_finder failed Brisbane, QLD seen 0 WorkflowInternalError: Step s3-flatten-1 output is too large. Maximum allowed size is 1MiB.
2026-08-03T06:44Z lead_finder failed Sydney, NSW seen 0 WorkflowInternalError: Step s4-map-1 output is too large. Maximum allowed size is 1MiB.
2026-08-03T06:26Z lead_finder failed (lat/lng Sydney) seen 0 WorkflowInternalError: Step s3-map-1 output is too large. Maximum allowed size is 1MiB.

The two runs after the fix were Hobart and Launceston. No capital city has been swept since, and
the last three that were tried all died at the 1MiB bound. (Two Sydney/Adelaide runs at 07:22–07:25
on 08-03 report completed with seen 1 — one place, not a sweep; they do not contradict this.)

4. A new subscriber gets no pipeline at all. The agent row's config is
{"capabilities":{"tools":[…]}} — no pipelines key, no settingsSchema. Subscribe copies
agents.config.pipelines (routes/instances.ts:137-142); there is nothing to copy. So the only
copy of lead_finder anywhere is agent_instances.config.pipelines on the single existing
instance, put there by hand. The max_places default the fix depends on — and the agent setting
that overrides it, which 6b37070 wired end to end for the first time — have no home on this agent.

5. The card still promises it. GET /v1/agents →
"…compiles them as ready-to-pitch leads for website building. Search by city and business type;
exports name, address, phone, and Maps link." Live, published, on the storefront today.

What is genuinely fixed, and should not be re-litigated

The runner-side half of 6b37070 is in production and is right: capStepOutput's accounting,
coverageShortfall + the pipeline.capped trace event (pipeline.ts, workflows/pipeline-run.ts),
the caller > setting > declared default param resolution (pipeline-run-start.ts,
instance-settings.ts), and the responseMap projection support (connectors/http.ts) that makes
the geo fix expressible at all. Reopening is not a criticism of any of that. The residual is exactly
the definition, and its distribution.

Also now resolved since the issue was written: the #381 blocker. GET /v1/instances/933ebec5…/tools reports http_request allowed:true, reason:"ok", and the agent row
declares it. That paragraph of the original issue is spent.

What closing this actually requires

• Seed the definition onto the agent row — agents.config.pipelines["lead_finder"] plus the
  max_places settingsSchema field — as a migration, in 0057's shape. This is [Catalog] Audit every published agent — keep / fix / unpublish #64 finding 1,
  deliberately deferred by 6b37070; it is the step that makes the reference JSON reach anyone.
• Pair it with a seed-drift assertion, the way site-builder is. Without that the
  reference and the seed drift the moment either is edited, which is the failure this reopening
  documents, one layer up.
• Decide the live instance. A seed on the agent row does not rewrite an existing instance's
  config.pipelines. Either PUT /v1/instances/:id/pipelines/lead_finder with the reference
  definition (owner action, live data), or a migration that replaces an instance copy whose
  definition is byte-identical to the old one. Pick one and say which — otherwise the one
  instance that exists stays on the 8-step copy after the ticket closes.
• Run Sydney, and put the run id and the detail line on this ticket. That is the acceptance
  criterion the original issue could not have: it now exists, because coverageShortfall makes a
  capped sweep say so.

One thing that made this hard to check, worth its own consideration

There is no read-back route for a live pipeline definition. GET /v1/instances/:id/pipelines
returns {name, steps, sink, valid} — a count, not the definition — and GET …/pipelines/lead_finder is a 404 (routes/tools.ts:168-241 has GET for the list, PUT and
POST …/run for one, and no GET for one). So a definition can only be written, never read, and
"is the live pipeline the one we fixed?" is answerable only by inference from step counts and error
step-indices — which is exactly what both this issue and 6b37070 had to do. A read-only GET …/pipelines/:name would have turned this whole investigation into one request. Filing that
separately if it is wanted; noting it here because it is why the original diagnosis had to hedge.

Verified: production reads via the REST API with a CLI session token (agents, instance pipelines,
pipeline runs, instance tools) and grep/git over main @ 0b4afd0. Not verified: I did not run
a sweep, edit any pipeline, or write anything.

[serge-ivo]

The seed shipped — c1612b9, deployed, and verified against the production agent row

Two of the four boxes in the reopening comment are closed. The two that mutate live data or spend
money are deliberately not, and are stated below rather than quietly dropped.

Verified in production, after the deploy landed

GET /v1/agents/my/agents for 4d9945ab-26b2-4476-b9c1-89b7f4426f35, read just now:

pipelines keys: [ 'lead_finder' ]
lead_finder name: lead_finder steps: 10
step order: geocode · fan_out · http_request · flatten · slice · map · enrich · map · filter · dedupe_upsert
settingsSchema: [{"id":"max_places","label":"Places per sweep","type":"number","default":300, …}]
capabilities.tools: 16 (unchanged)

That is the reference definition, on the agent row, in production. Before this commit the row's
config was {"capabilities":{"tools":[…16…]}} — no pipelines, no settingsSchema — so a new
subscriber got an agent that could do nothing, which was finding 4 of the reopening.

What shipped

• 0111_seed_lead_finder_pipeline.sql — UPDATE … WHERE slug = 'small-business-website-lead-finder',
  never by uuid, never INSERT. Unlike site-builder (0057) this is a real creator's row, not
  first-party seed data, so on a fresh database both statements are a clean no-op and nothing here
  fabricates an agent. Two targeted json_set writes, so it composes with [arch] A registry tool that no agent declares is silently unreachable — three times in four days, and six more are live right now #444's 0108 regardless
  of order (verified in sqlite both ways); the capabilities.tools statement is guarded
  WHERE json_type(…,'$.capabilities.tools') IS NULL and was, as expected, a no-op in production —
  the count above is still 16.
  • A json_set subtlety worth recording: it creates a leaf, never an intermediate object, so
    '$.pipelines.lead_finder' alone would have been a silent no-op on a config with no
    pipelines key. The statement builds $.pipelines first.
• seed-drift.test.ts gains a #394 block — the definition is parsed back out of the migration
  and asserted equal to lead-finder.json, plus validatePipeline and the settingsSchema id list.
  This is the pairing the reopening asked for, and it is the thing that stops the reference and the
  SQL drifting again.
• lead-finder.json: "name": "lead-finder" → "lead_finder", one line.

The key decision, since the reopening asked for it explicitly

lead_finder. loadPipeline resolves config.pipelines[key] and nothing reads def.name;
production, pipeline_runs.pipeline, the console and the one lead.created connection all say
lead_finder. Seeding under lead-finder would have stood a second pipeline up beside the live
one. The reference JSON's name was changed to match because defaultPipelinesFor (the subscribe
path, routes/instances.ts:73-88) copies what it is given without passing it through
pipelineDefForKey — so key lead_finder + name lead-finder would have re-created #173's split
(run rows under one spelling, workflow log lines under the other) for every future subscriber.

Declaration gate — checked, not assumed

The seed passes pipelineDeclarationError. The reopening's second-order worry is already handled on
main by #396: geocode and fan_out carry dispatches: ["http_request"]. The new test asserts
the gated set is exactly ["http_request"] and that it is first reached via: "dispatch" (by
geocode, not by the explicit step 2), derived from the real registry through the real rule — so
removing the explicit http_request step still requires the declaration.

Left open, on purpose — this is why the ticket stays open

• The live instance 933ebec5… is still on the 8-step copy. A seed on the agent row does not
  rewrite an existing instance. Prepared, not applied, because it is live data and the owner's
  call:
  bash curl -X PUT https://api.proagentstore.online/v1/instances/933ebec5…/pipelines/lead_finder \ -H "Authorization: Bearer $PAGS_TOKEN" -H 'Content-Type: application/json' \ --data-binary @workers/api/src/lib/pipelines/lead-finder.json
  The body is the PipelineDef (routes/tools.ts:212-242) and is byte-identical to
  lead-finder.json at c1612b9 — stated by provenance so there is no transcription risk. It
  takes that instance 8 steps → 10; the two that appear are slice (bind bounded, the
  max_places cap) and the second map (bind classified, the website_status reshape that
  follows the responseMap projection). The route normalises name to the key, so it lands as
  lead_finder either way.
• Sydney has not been run. It spends Google Places quota and real money, so it was not
  launched unasked. It remains the acceptance criterion, and it is now a meaningful one: with
  coverageShortfall a capped sweep says so in its detail line, and with max_places on the
  agent it can be raised for a capital city from the settings card rather than the caller.

Rejected, and why

Making city / type / radius settings. They are per-run arguments — every run in the history
supplies all three — and a settings default would emit on every untouched instance and outrank the
declared default. Separately real, and not fixed here: none of those three has a declared default,
so a kick supplying only city sends includedTypes: [undefined].

Gates

pnpm typecheck · pnpm vitest run (410 files, 6811 tests, 0 failures) · biome
--error-on-warnings (1044 files) · design-tokens · agents-allowlist · qa-config · file-size ·
check-migrations --require-history (110 migrations, 109 distinct, the one pre-existing recorded
collision) · test-isolation · docs:drift — all green, re-run after the final rebase onto e804b06.
test:e2e skipped: this lane touches no store/ and no agents/coder/web.

One flake seen and worth naming rather than hiding: user-ai-stall.test.ts failed once with
ERR_INVALID_STATE on an intermediate run, then passed alone and passed in the full suite twice
after. Unrelated to this diff (a migration, a JSON name field and a test file), but it is a second
data point alongside #446.

Migration number: this commit took 0111, not the 0108 or 0109 it was written against — #444 and
#451 each landed one mid-flight. Renumbered and re-verified twice; #440 holds 0110.

[serge-ivo]

Migration 0111 reached the agent row. It cannot reach the live instance, and the run detail proves it hasn't. Staying open.

Re-audited against the deployed API today (c1612b9 is an ancestor of b6f6c9f6, deployed 13:02 UTC).

What has landed — verified live, not from the migration text

GET /v1/instances/my/instances resolves the agent's capabilities, and both halves of 0111 are there:

small-business-website-lead-finder
 capabilities.tools: ["http_request", "search_knowledge", … 16 total]
 settingsSchema: [{ id: "max_places", type: "number", … }]

And the tool gate that refused every kick is open — GET /v1/instances/933ebec5-…/tools now returns
http_request with allowed: true. That was the "also true, and separate" blocker in the report body;
it is resolved.

What has not — and the measurement that settles it

The most recent lead_finder run reports its own step count:

GET /v1/instances/933ebec5-…/pipeline-runs

2026-08-06 04:38Z lead_finder completed seen=83 detail: "8 step(s), 45 → leads, 38 updated"
2026-08-04 14:09Z lead_finder completed seen=116 detail: "8 step(s), 64 → leads"

Eight steps. The reference definition is ten. No run since 0111 landed, and none would differ if
there were one, because 0111 does not touch the row that decides:

UPDATE agents … WHERE slug = 'small-business-website-lead-finder' -- twice

loadPipeline (lib/pipeline.ts:553-566) reads only agent_instances.config.pipelines[name], with
no fallback to the agent row. agents.config.pipelines is read at exactly one moment — subscribe
(routes/instances.ts:135-144) — so 0111 fixes every future subscriber and cannot reach the one
instance that exists. The migration's own header says as much; this is confirmation, not a correction.

And Sydney still has not been swept

Reading the run table rather than the completion column, because the completion column misleads here:

2026-08-03 06:26Z failed lat/lng Sydney WorkflowInternalError: Step s3-map-1 output is too large
2026-08-03 06:44Z failed Sydney, NSW WorkflowInternalError: Step s4-map-1 output is too large
2026-08-03 07:22Z completed Sydney, NSW seen=1 added=1 "8 step(s), 1 → leads"
2026-08-03 07:25Z completed Adelaide, SA seen=1 added=1 "8 step(s), 1 → leads"
2026-08-03 08:03Z failed Brisbane, QLD WorkflowInternalError: Step s3-flatten-1 output is too large
2026-08-04 14:09Z completed Hobart, TAS seen=116 added=64
2026-08-06 04:38Z completed Launceston, TAS seen=83 added=45

The two "completed" capital-city runs examined one place each — they are not sweeps. Every run that
actually looked at a capital city is in the failed column with the 1MiB error. The claim in the ticket
body stands unchanged: the only cities ever swept are Hobart and Launceston.

What remains, and who it needs

1. Put the ten-step definition on the live instance — an AGENT can do this.
PUT /v1/instances/933ebec5-…/pipelines/lead_finder (routes/tools.ts:212) attaches a definition to an
instance's config.pipelines. Body = workers/api/src/lib/pipelines/lead-finder.json as-is. Two things
to get right, both already reasoned out in 0111's header and worth not re-deriving:

• the key must be lead_finder, not lead-finder — the key is authoritative, and the reference
  JSON's name was changed to match in the same commit specifically so attaching it cannot re-create
  the two-spellings split of Configure the lead_finder declarative pipeline so the lead-finder agent can actually find leads #173;
• it replaces the hand-built 8-step copy rather than sitting beside it.

Verification is cheap and needs no sweep: a subsequent run's detail should read 10 step(s).

2. Sweep Sydney — this needs the OWNER.
It spends Google Places quota against a paid key, and this audit is explicitly not authorised to run
one. It is also the only thing that closes the ticket's actual claim, since the fix is about a payload
size that only a dense city produces. Suggested first run: { city: "Sydney, NSW", type: "cafe", radius: 900 } with max_places left at its default of 300, so the slice cap is exercised and the
coverage shortfall is reported rather than silently swallowed — which is the ticket's fourth fix item.

Expected on success: completes rather than WorkflowInternalError, detail reads 10 step(s),
and seen is bounded by max_places with a line saying how many places were left unexamined.

Nothing here is a code defect any more. Staying open because the ticket's claim — "lead_finder cannot
sweep a capital city" — is still true of the only instance that exists, and no capital city has been
swept to prove otherwise.