refactor(prompts): drop collector server names from deliverable instructions

apps/worker/prompts/exploit-auth.txt

@@ -305,7 +305,7 @@ Prioritize these based on the intelligence from your queue and vulnerability ana
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-You emit your exploitation evidence through a single tool — `add_exploit` from the `exploit-collector`. The host renderer assembles `.shannon/deliverables/auth_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
+You emit your exploitation evidence through a single tool — `add_exploit`. The host renderer assembles `.shannon/deliverables/auth_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
 
 **When to emit.** After reaching a definitive verdict on a vulnerability — either successfully exploited (Level 3+ with concrete impact evidence) or potential-but-blocked (real vulnerability, but an external operational constraint blocked full exploitation) — call `add_exploit` once with that finding's structured evidence. Call once per queue vulnerability; do not batch. Continue processing the next vuln in your todo list after each emission.
 

apps/worker/prompts/exploit-authz.txt

@@ -313,7 +313,7 @@ Remember: The most effective attacks often come from understanding the specific
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-You emit your exploitation evidence through a single tool — `add_exploit` from the `exploit-collector`. The host renderer assembles `.shannon/deliverables/authz_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
+You emit your exploitation evidence through a single tool — `add_exploit`. The host renderer assembles `.shannon/deliverables/authz_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
 
 **When to emit.** After reaching a definitive verdict on a vulnerability — either successfully exploited (Level 3+ with concrete impact evidence) or potential-but-blocked (real vulnerability, but an external operational constraint blocked full exploitation) — call `add_exploit` once with that finding's structured evidence. Call once per queue vulnerability; do not batch. Continue processing the next vuln in your todo list after each emission.
 

apps/worker/prompts/exploit-injection.txt

@@ -336,7 +336,7 @@ Prioritize your techniques based on the intelligence from the analysis deliverab
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-You emit your exploitation evidence through a single tool — `add_exploit` from the `exploit-collector`. The host renderer assembles `.shannon/deliverables/injection_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
+You emit your exploitation evidence through a single tool — `add_exploit`. The host renderer assembles `.shannon/deliverables/injection_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
 
 **When to emit.** After reaching a definitive verdict on a vulnerability — either successfully exploited (Level 3+ with concrete impact evidence) or potential-but-blocked (real vulnerability, but an external operational constraint blocked full exploitation) — call `add_exploit` once with that finding's structured evidence. Call once per queue vulnerability; do not batch. Continue processing the next vuln in your todo list after each emission.
 

apps/worker/prompts/exploit-ssrf.txt

@@ -390,7 +390,7 @@ A successful SSRF doesn't always mean data is immediately exfiltrated. Validatio
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-You emit your exploitation evidence through a single tool — `add_exploit` from the `exploit-collector`. The host renderer assembles `.shannon/deliverables/ssrf_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
+You emit your exploitation evidence through a single tool — `add_exploit`. The host renderer assembles `.shannon/deliverables/ssrf_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
 
 **When to emit.** After reaching a definitive verdict on a vulnerability — either successfully exploited (Level 3+ with concrete impact evidence) or potential-but-blocked (real vulnerability, but an external operational constraint blocked full exploitation) — call `add_exploit` once with that finding's structured evidence. Call once per queue vulnerability; do not batch. Continue processing the next vuln in your todo list after each emission.
 

apps/worker/prompts/exploit-xss.txt

@@ -323,7 +323,7 @@ POTENTIAL (Report in separate subsection):
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-You emit your exploitation evidence through a single tool — `add_exploit` from the `exploit-collector`. The host renderer assembles `.shannon/deliverables/xss_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
+You emit your exploitation evidence through a single tool — `add_exploit`. The host renderer assembles `.shannon/deliverables/xss_exploitation_evidence.md` from your tool calls after the run. You do NOT write the Markdown file directly.
 
 **When to emit.** After reaching a definitive verdict on a vulnerability — either successfully exploited (Level 3+ with concrete impact evidence) or potential-but-blocked (real vulnerability, but an external operational constraint blocked full exploitation) — call `add_exploit` once with that finding's structured evidence. Call once per queue vulnerability; do not batch. Continue processing the next vuln in your todo list after each emission.
 

apps/worker/prompts/pre-recon-code.txt

@@ -178,7 +178,7 @@ After Phase 1 completes, launch all three vulnerability-focused agents in parall
 </scope_boundaries>
 
 <deliverable_tools>
-**Emit your findings exclusively via the `pre-recon-collector` tools.** The host renders the deliverable Markdown from your tool calls; you do not write any Markdown files yourself.
+**Emit your findings exclusively via the deliverable tools.** The host renders the deliverable Markdown from your tool calls; you do not write any Markdown files yourself.
 
 You must call all seven of the following tools exactly once before terminating. Each tool's full schema and field-by-field guidance is in your tool catalog — read it there.
 

apps/worker/prompts/recon.txt

@@ -144,7 +144,7 @@ You must follow this methodical four-step process:
 </systematic_approach>
 
 <deliverable_tools>
-**Emit your findings exclusively via the `recon-collector` tools.** The host renders the deliverable Markdown from your tool calls; you do not write any Markdown files yourself.
+**Emit your findings exclusively via the deliverable tools.** The host renders the deliverable Markdown from your tool calls; you do not write any Markdown files yourself.
 
 **When to emit.** After all parallel Task sub-agents (Route Mapper, Authorization Checker, Input Validator, Session Handler, Authorization Architecture, Injection Source Tracer) have completed and you have synthesized findings, emit via the tools below.
 

apps/worker/prompts/vuln-auth.txt

@@ -195,7 +195,7 @@ For each check you perform from the list above (Transport, Rate Limiting, Sessio
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 3 one-shot tools provided by the `vuln-collector`. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
+After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 3 one-shot tools. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
 
 **Tool catalog:**
 - `set_findings_summary` — Section 1 (Executive Summary key outcome) and Section 2 (Dominant Vulnerability Patterns)

apps/worker/prompts/vuln-authz.txt

@@ -273,7 +273,7 @@ For each analysis you perform from the lists above, you must make a final **verd
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 4 one-shot tools provided by the `vuln-collector`. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
+After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 4 one-shot tools. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
 
 **Tool catalog:**
 - `set_findings_summary` — Section 1 (Executive Summary key outcome) and Section 2 (Dominant Vulnerability Patterns)

apps/worker/prompts/vuln-injection.txt

@@ -284,7 +284,7 @@ An **exploitable vulnerability** is a confirmed source-to-sink path where the en
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 4 one-shot tools provided by the `vuln-collector`. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
+After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 4 one-shot tools. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
 
 **Tool catalog:**
 - `set_findings_summary` — Section 1 (Executive Summary key outcome) and Section 2 (Dominant Vulnerability Patterns)

apps/worker/prompts/vuln-ssrf.txt

@@ -244,7 +244,7 @@ For each check you perform from the list above, you must make a final **verdict*
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 3 one-shot tools provided by the `vuln-collector`. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
+After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 3 one-shot tools. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
 
 **Tool catalog:**
 - `set_findings_summary` — Section 1 (Executive Summary key outcome) and Section 2 (Dominant Vulnerability Patterns)

apps/worker/prompts/vuln-xss.txt

@@ -206,7 +206,7 @@ This rulebook is used for the **Early Termination** check in Step 2.
 </methodology_and_domain_expertise>
 
 <deliverable_tools>
-After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 4 one-shot tools provided by the `vuln-collector`. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
+After completing your `todo_write` tasks and synthesizing findings, emit your specialist deliverable via 4 one-shot tools. Each tool maps to a section (or pair of sections) of the rendered Markdown deliverable; call each exactly once with that section's complete content.
 
 **Tool catalog:**
 - `set_findings_summary` — Section 1 (Executive Summary key outcome) and Section 2 (Dominant Vulnerability Patterns)