@sellable/mcp 0.1.90 → 0.1.92

package/README.md

@@ -248,9 +248,10 @@ Parallel execution contract:
   use that registry to launch the filter-leads scout and message-generation
   scout together when the host supports real subagents.
 - Claude host: use the installed `source-scout-linkedin-engagement`,
-  `source-scout-sales-nav`, and `source-scout-prospeo-contact` Task/Agent subagents
-  for parallel lead-source scouting. Launch all credible lanes in one assistant
-  message so Claude Code can run them concurrently/background.
+  `source-scout-sales-nav`, and `source-scout-prospeo-contact` Task/Agent
+  subagents for parallel lead-source scouting only when the current session
+  exposes those agent names. Launch all credible lanes in one assistant message
+  so Claude Code can run them concurrently/background.
 - Codex host: use named custom scouts for source-angle work when subagents are
   available: `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
   `source-scout-prospeo-contact`. Use `multi_tool_use.parallel` for independent
@@ -258,8 +259,9 @@ Parallel execution contract:
   batched lookups.
 - For the post-lead stage, Codex/Claude should launch
   `post-find-leads-filter-scout` and `post-find-leads-message-scout` in the
-  same turn/message when subagents are available. If not, run them sequentially
-  and do not claim parallel work.
+  same turn/message when those subagents are available in the current session.
+  If not, run them sequentially with MCP tools/assets, do not surface install
+  status to the customer, and do not claim parallel work.
 - If neither backend is available, run sequentially with the same output schema.
 
 Config path resolution (in order):

package/agents/post-find-leads-message-scout.md

@@ -18,11 +18,13 @@ Required inputs:
 Required first steps:
 
 1. Read the three required inputs.
-2. Load 100% of the real generate-messages prompt with chunked
-   `get_subskill_prompt({ subskillName: "generate-messages", offset, limit })`
-   calls until `hasMore` is false.
-3. Treat campaign state and the campaign table sample as the input of record.
+2. Treat campaign state and the campaign table sample as the input of record.
    Disk files are context/debug aids, not durable state.
+3. Use the embedded Message Review Safety Gate below. Do not load the full
+   long-form `generate-messages` subskill in this `create-campaign-v2` path. If
+   a needed rule is missing or the draft fails quality gates, return
+   `revise-messaging` with the exact failure instead of pulling the long prompt
+   into this worker.
 
 Owned outputs:
 
@@ -44,13 +46,13 @@ Do not write or modify:
 
 Process:
 
-1. Run the loaded generate-messages workflow in dry mode from the approved
-   brief, lead-review source decision, and `lead-sample.json`.
+1. Run the embedded message-review safety-gate workflow in dry mode from the
+   approved brief, lead-review source decision, and `lead-sample.json`.
 2. Use `lead-sample.json` as the only lead sample source. Do not fetch new
    prospects or invent richer row signals.
 3. Build proof inventory, token fill rules, token adherence, angle drafts,
-   kill/combine review, finalists, skeptical-prospect review, winner gate, and
-   a raw sendable selected winner.
+   kill/combine review, skeptical-prospect review, winner gate, and a raw
+   sendable selected winner.
 4. If `lead-filter.md` already exists, cite only basis rows that pass it. If it
    does not exist yet, choose probable good-fit rows from `lead-sample.json` and
    mark the final reconciliation as pending.
@@ -67,7 +69,8 @@ Process:
 Return a concise final status with:
 
 - artifacts written
-- whether the full generate-messages prompt was loaded
+- whether the embedded message-review safety-gate rules passed or returned
+  `revise-messaging`
 - lead sample basis used
 - proposed template and one sample message
 - selected winner summary
@@ -76,7 +79,56 @@ Return a concise final status with:
 Quality bar:
 
 - Do not synthesize a lightweight message from general knowledge. The artifact
-  must prove the full generate-messages workflow ran.
+  must prove the embedded message-review safety-gate workflow ran.
 - Message generation can start before `lead-filter.md`, but message review
   cannot start until the parent verifies the selected basis rows still pass the
   final filter.
+
+## Embedded Message Review Safety Gate
+
+Use this campaign-launch subset to produce a truthful first-send message,
+rendered token examples, and a decision without loading the full long-form
+message prompt.
+
+Required `message-validation.md` sections:
+
+- `Status`
+- `Mode`
+- `Lead Sample Basis`
+- `Strongest Reply Reason`
+- `Campaign Element Pool`
+- `Gold Standard Strategy Map`
+- `Current Campaign Translation`
+- `Token Fill Rules`
+- `Token Adherence Table`
+- `Angle Drafts`
+- `Kill / Combine Review`
+- `Finalizer Pass`
+- `Gold-Standard Quality Gate`
+- `Skeptical Prospect Review`
+- `Winner Gate`
+- `Selected Winner`
+- `Findings`
+- `Recommendation`
+
+Quality gates:
+
+- The selected winner is one first outbound send only. No post-accept DM,
+  follow-up, cadence branch, or sequence copy.
+- Explain what the product is and what it does in plain language before asking
+  for a call.
+- Use only proof from the brief, source review, sample, campaign state, or
+  explicit user answers. Unsupported reply-rate, meeting-rate, ROI, revenue,
+  and customer-logo claims are blocked.
+- Include at least one supported `{{token}}` when templating, plus a complete
+  rendered good-fill example and a complete rendered omit/fallback example.
+- Do not use internal tokens such as `{{profile_signal}}` in customer-facing
+  copy.
+- Do not put bracketed instructions in the message body, such as `[ROW_BRIDGE]`,
+  `[insert]`, or `[generated]`.
+- Optional row-specific personalization must be grounded in a row field or
+  omitted entirely.
+- Subjects should be short, buyer-relevant, and specific. Avoid `quick
+question`, `demo`, `founder call`, sender names, and generic `outbound`.
+- If the message is plausible but not ready to send, set `Recommendation:
+revise-messaging`.

package/dist/tools/campaigns.js

@@ -26,6 +26,17 @@ function buildWatchUrl(config, redirect) {
         : "";
     return `${config.apiUrl}/auth/continue?token=${config.token}&redirect=${redirect}${workspaceParam}`;
 }
+function isLinkedInProfileUrl(input) {
+    try {
+        const url = new URL(input);
+        const host = url.hostname.toLowerCase();
+        return ((host === "linkedin.com" || host.endsWith(".linkedin.com")) &&
+            /^\/in\/[^/]+\/?$/i.test(url.pathname));
+    }
+    catch {
+        return false;
+    }
+}
 export const campaignToolDefinitions = [
     {
         name: "get_campaigns",
@@ -613,9 +624,10 @@ export async function createCampaign(input) {
     if (!hasClientProspectId && !senderLinkedinUrl) {
         missing.push("clientProspectId or senderLinkedinUrl");
     }
-    // Cheap URL sanity check on senderLinkedinUrl when supplied.
-    if (senderLinkedinUrl && !senderLinkedinUrl.includes("linkedin.com")) {
-        throw new Error("VALIDATION_ERROR: senderLinkedinUrl must be a LinkedIn URL (must contain 'linkedin.com'). Got: " +
+    // Cheap URL sanity check on senderLinkedinUrl when supplied. This input is a
+    // profile bootstrap fallback; company pages should use clientProspectId.
+    if (senderLinkedinUrl && !isLinkedInProfileUrl(senderLinkedinUrl)) {
+        throw new Error("VALIDATION_ERROR: senderLinkedinUrl must be a LinkedIn profile URL like https://www.linkedin.com/in/name/. Company pages require clientProspectId or a discovered profile URL. Got: " +
             senderLinkedinUrl);
     }
     if (missing.length > 0) {

package/dist/tools/flow-preflight.js

@@ -16,6 +16,14 @@ export function markResearchPromptLoaded(mode = "generic", subskillName) {
             : mode === "prospect"
                 ? "research-prospect"
                 : "research");
+    const existing = researchPromptStates[mode];
+    // Re-loading the same research prompt is a context-management detail, not
+    // new research. Preserve the original load timestamp so a completed research
+    // marker does not become stale just because the host refreshed instructions.
+    if (existing?.subskillName === normalizedSubskillName) {
+        latestResearchPromptState = existing;
+        return existing;
+    }
     const state = {
         loadedAt: new Date().toISOString(),
         mode,

package/dist/tools/prompts.js

@@ -132,7 +132,7 @@ export const promptToolDefinitions = [
     },
     {
         name: "get_source_scout_registry",
-        description: "Return the canonical Sellable source-scout agent names and host filenames. Use this before lead-source scouting so Codex and Claude launch the same named scouts from one registry.",
+        description: "Return the canonical Sellable source-scout agent names and host filenames. Use this before lead-source scouting so Codex and Claude can launch the same named scouts from one registry when the current host exposes them.",
         inputSchema: {
             type: "object",
             properties: {},
@@ -242,9 +242,9 @@ export function getSourceScoutRegistry() {
             legacy: agent.legacy,
         })),
         usage: {
-            codex: "Spawn credible scouts by the returned `name` values in one assistant turn when the user approved background source scouts.",
-            claude: "Invoke Claude Code Task/Agent subagents with subagent_type equal to the returned `name` values.",
-            parentThreadRule: "Do not preload every provider prompt in the parent; each scout loads only the provider prompt for its lane.",
+            codex: "Spawn credible scouts by the returned `name` values in one assistant turn only when the current Codex host exposes those custom agents.",
+            claude: "Invoke Claude Code Task/Agent subagents with subagent_type equal to the returned `name` values only when the current Claude session lists those agents.",
+            parentThreadRule: "Named agents are optional acceleration. If they are absent, do not customer-surface install status; run the same provider probes with MCP tools from the parent thread. Do not preload every provider prompt before spawning agents; each scout loads only the provider prompt for its lane.",
         },
     };
 }
@@ -287,9 +287,9 @@ export function getPostFindLeadsScoutRegistry() {
             nextStage: "message-review",
         },
         usage: {
-            codex: "After the user approves or auto-confirms the lead source, spawn both returned scout `name` values in one assistant turn when subagents are available.",
-            claude: "After lead source approval, invoke both returned Task/Agent subagents in one assistant message so filter-leads and message generation run concurrently.",
-            parentThreadRule: "Do not run filter-leads to completion before starting message generation. Both scouts consume brief.md, lead-review.md, and lead-sample.json; join before message review.",
+            codex: "After the user approves or auto-confirms the lead source, spawn both returned scout `name` values in one assistant turn only when the current Codex host exposes those custom agents.",
+            claude: "After lead source approval, invoke both returned Task/Agent subagents in one assistant message only when the current Claude session lists those agents, so filter-leads and message generation run concurrently.",
+            parentThreadRule: "Named agents are optional acceleration. If they are absent, do not customer-surface install status; the main thread still orchestrates filter and message branches from brief.md, lead-review.md, and lead-sample.json. The message branch should use the baked-in message-scout prompt or the create-campaign-v2 message-review safety gate asset, not the full long generate-messages prompt in the normal path. Join before message review.",
         },
     };
 }

package/dist/tools/rubrics.d.ts

@@ -39,9 +39,18 @@ type WaitForRubricResultsInput = {
 type WorkflowTableStats = {
     tableId: string;
     totalRows: number;
+    enrichedCount?: number;
+    needsEnrichCount?: number;
+    messagesCount?: number;
+    needsApprovalCount?: number;
+    processingCount?: number;
+    failedCount?: number;
     passRate?: {
         completed: number;
         passed: number;
+        pending?: number;
+        percent?: number;
+        targetCount?: number;
     };
 };
 export declare const rubricToolDefinitions: ({
@@ -491,8 +500,12 @@ export declare function waitForRubricResults(input: WaitForRubricResultsInput):
         passed: number;
         percent: number;
         targetCount: number;
+        pending?: undefined;
     };
     reason?: undefined;
+    partialResult?: undefined;
+    diagnostic?: undefined;
+    guidance?: undefined;
 } | {
     ready: boolean;
     reason: string;
@@ -502,9 +515,28 @@ export declare function waitForRubricResults(input: WaitForRubricResultsInput):
     passRate: {
         completed: number;
         passed: number;
+        pending: number;
         percent: number;
         targetCount: number;
     };
+    partialResult: {
+        completed: number;
+        passed: number;
+        pending: number;
+        percent: number;
+        targetCount: number;
+        enoughToDiagnose: boolean;
+    };
+    diagnostic: {
+        totalRows: number;
+        enrichedCount: number | undefined;
+        needsEnrichCount: number | undefined;
+        messagesCount: number | undefined;
+        needsApprovalCount: number | undefined;
+        processingCount: number | undefined;
+        failedCount: number | undefined;
+    };
+    guidance: string;
     stats: WorkflowTableStats | null;
 }>;
 export {};

package/dist/tools/rubrics.js

@@ -332,7 +332,7 @@ export const rubricToolDefinitions = [
     },
     {
         name: "wait_for_rubric_results",
-        description: "Wait for ICP rubric pass-rate results to complete for queued prospects.",
+        description: "Wait for ICP rubric pass-rate results to complete for queued prospects. On timeout, returns partial diagnostic stats; create-campaign-v2 should not poll indefinitely.",
         inputSchema: {
             type: "object",
             properties: {
@@ -672,6 +672,9 @@ export async function waitForRubricResults(input) {
     const completed = lastStats?.passRate?.completed ?? 0;
     const passed = lastStats?.passRate?.passed ?? 0;
     const percent = completed > 0 ? Math.round((passed / completed) * 100) : 0;
+    const totalRows = lastStats?.totalRows ?? 0;
+    const effectiveTarget = totalRows > 0 ? Math.min(targetCount, totalRows) : targetCount;
+    const pending = Math.max(effectiveTarget - completed, 0);
     return {
         ready: false,
         reason: "timeout",
@@ -681,9 +684,28 @@ export async function waitForRubricResults(input) {
         passRate: {
             completed,
             passed,
+            pending,
             percent,
-            targetCount,
+            targetCount: effectiveTarget,
         },
+        partialResult: {
+            completed,
+            passed,
+            pending,
+            percent,
+            targetCount: effectiveTarget,
+            enoughToDiagnose: completed > 0,
+        },
+        diagnostic: {
+            totalRows,
+            enrichedCount: lastStats?.enrichedCount,
+            needsEnrichCount: lastStats?.needsEnrichCount,
+            messagesCount: lastStats?.messagesCount,
+            needsApprovalCount: lastStats?.needsApprovalCount,
+            processingCount: lastStats?.processingCount,
+            failedCount: lastStats?.failedCount,
+        },
+        guidance: "If this is create-campaign-v2 validate-sample, do not repeat waits indefinitely. Use passRate/stats to diagnose and surface sample_revision_required before Settings when the sample is under the pass floor or messages are incomplete.",
         stats: lastStats,
     };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.90",
+  "version": "0.1.92",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.md

@@ -120,23 +120,28 @@ scout those angles as independent branches when the host can actually do it:
 LinkedIn Engagement / active post engagers (internal `signal-discovery`
 provider prompt), Sales Nav / title + company filters, and Prospeo Contact /
 domains only when relevant. In Codex, explicitly spawn the named custom scouts
-`source-scout-linkedin-engagement`, `source-scout-sales-nav`, and `source-scout-prospeo-contact` for
-the credible lanes; Codex does not infer subagent fan-out from generic source
+`source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
+`source-scout-prospeo-contact` for the credible lanes only when the current host
+exposes those names; Codex does not infer subagent fan-out from generic source
 comparison wording. In Claude Code, invoke the generated `source-scout-*`
-Task/Agent subagents for all credible lanes in one assistant message; the
-installer writes them from the same canonical Sellable agent registry with
-explicit Sellable MCP tool allowlists. The create-campaign-v2 subskill calls
-`get_source_scout_registry` before dispatch so the current registry, not this
-copy, is the runtime source of truth. If the host runs them sequentially, do not
-claim they ran in parallel. In chat, call the downstream copy stage `message generation`;
+Task/Agent subagents for all credible lanes in one assistant message only when
+the current session lists those names. The installer writes them from the same
+canonical Sellable agent registry with explicit Sellable MCP tool allowlists.
+The create-campaign-v2 subskill calls `get_source_scout_registry` before
+dispatch so the current registry, not this copy, is the runtime source of truth.
+If the host runs them sequentially or the named agents are unavailable, do not
+claim they ran in parallel and do not surface install status to the customer. In
+chat, call the downstream copy stage `message generation`;
 `message-validation.md` is only an internal proof artifact.
 
 After find-leads returns a lead source and the user approves it, use the same
 registry pattern for the two post-lead branches. The create-campaign-v2 subskill
 calls `get_post_find_leads_scout_registry`, then launches the returned
 filter-leads scout and message-generation scout together when real subagents are
-available. Message generation must not wait for the filter unless the host
-cannot run the two branches concurrently.
+available and the current session exposes the returned names. Message
+generation must not wait for the filter unless the host cannot run the two
+branches concurrently. If the post-lead agents are absent, the main thread still
+orchestrates the same branches from the compact context with MCP tools/assets.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -218,18 +223,20 @@ Treat host capabilities as concrete functions, not prose conventions:
   `mcp__sellable__get_post_find_leads_scout_registry({})` after source
   approval and before dispatching the post-lead filter/message scouts.
 - `launch_source_scout`: Claude Code uses `Task` with `subagent_type` equal to
-  the registry `name`; Codex uses named custom agents such as
+  the registry `name` only when the session lists those agents; Codex uses
+  named custom agents such as
   `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
   `source-scout-prospeo-contact` when subagents are available.
 - `launch_post_find_leads_scout`: Claude Code uses `Task` with `subagent_type`
-  equal to the returned post-lead registry `name`; Codex uses the returned
-  custom agents such as `post-find-leads-filter-scout` and
-  `post-find-leads-message-scout` when subagents are available.
+  equal to the returned post-lead registry `name` only when the session lists
+  those agents; Codex uses the returned custom agents such as
+  `post-find-leads-filter-scout` and `post-find-leads-message-scout` when
+  subagents are available.
 
-If a required interactive host function is missing, stop and explain the
-Sellable install/reload problem. Do not silently simulate structured choices,
-subprompt loading, source-scout dispatch, or post-lead scout dispatch with local
-scripts.
+If a required interactive question function or MCP loader is missing, stop and
+explain the Sellable install/reload problem. Named scout agents are optional
+acceleration: if they are absent, do not surface install status to the customer;
+fall back to product-native MCP orchestration instead of local scripts.
 
 Never narrate local draft housekeeping to the user. If you create directories,
 save drafts, write artifacts, or persist intermediate state, translate it into
@@ -480,16 +487,20 @@ updates.
    copies of this file; packaged Claude Code and Codex runs must use the MCP
    asset loader so they share the same config.
 3. Follow that prompt and workflow config exactly.
-4. For message generation, load the full `generate-messages` prompt in the
-   same run with chunked
-   `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages", offset, limit })`
-   calls until `hasMore` is false. Do not synthesize
-   `message-validation.md` from the brief, lead review, or general knowledge.
+4. For message generation, use the `post-find-leads-message-scout` agent when
+   available; its prompt carries the campaign-launch message rules. In the
+   parent-thread fallback, load
+   `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/message-review-safety-gate.md" })`.
+   Do not load the full long-form `generate-messages` subskill in this
+   create-campaign path; if the safety gate cannot safely approve the draft,
+   route to revise messaging with the concrete failure.
+   Do not synthesize `message-validation.md` from the brief, lead review, or
+   general knowledge.
 5. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Import only the first
    bounded review batch after the source is attached to the campaign; do not
    queue workflow cells, attach a sequence, or start until
-   `message-validation.md` proves the full generate-messages workflow ran,
+   `message-validation.md` proves the message-review safety-gate workflow ran,
    `message-review.md` approves the template, rubrics are saved, and the
    approved message set is synced into the campaign brief.
 6. Keep `selectedLeadListId` as the source list and `workflowTableId` as the

package/skills/create-campaign-v2/SKILL.md

@@ -189,7 +189,10 @@ Validated draft directory:
   it as the preferred `create_campaign` identity input. If it includes a
   LinkedIn profile URL, keep that URL as `senderLinkedinUrl` so the backend can
   resolve/materialize the sender prospect when the watchable campaign shell is
-  created. Do not require a connected sender before shell creation.
+  created. Do not pass a LinkedIn company page as `senderLinkedinUrl`; for a
+  company-only identity, use `clientProspectId` if already materialized or do
+  one lightweight lookup to find the relevant founder/operator profile. Do not
+  require a connected sender before shell creation.
 - If the user supplied a LinkedIn profile, website, domain, company name, or
   explicit client prospect identity in the invocation, do one lightweight lookup
   first:
@@ -217,7 +220,8 @@ Validated draft directory:
   profile, call `fetch_linkedin_profile` and infer the current or most recent
   company from the profile. For a company website, call `fetch_company` when
   possible, otherwise one web lookup. If a LinkedIn profile URL is available,
-  retain it as `senderLinkedinUrl` for `create_campaign`; if a
+  retain it as `senderLinkedinUrl` for `create_campaign`; if only a LinkedIn
+  company page is available, do not pass it as `senderLinkedinUrl`. If a
   `clientProspectId` is available, pass that instead.
 
   After the user confirms the campaign identity, check whether the company
@@ -368,11 +372,12 @@ Validated draft directory:
   not "looks good".
   Approval options should refer to what the user just read, e.g. `Approve this
 brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
-  When the user chose `Find people for me` and the host supports subagents,
-  make the recommended approval label explicit: `Approve brief + use background
-  source scouts`. That gives Codex/Claude a user-visible request to launch
-  source-scout subagents after approval instead of silently falling back to
-  parent-thread provider probes.
+  When the user chose `Find people for me` and the current runtime exposes the
+  named Sellable source-scout agents, make the recommended approval label
+  explicit: `Approve brief + use background source scouts`. If those agents are
+  not visible in this session, use `Approve brief + compare source paths`
+  instead. The customer approves the sourcing decision, not the host
+  implementation detail.
   Include an `Open artifact:` link to `brief.md` before the approval question.
   The visible brief must come before local persistence chrome. After the brief
   is synthesized, render the approval-ready brief in chat before running visible
@@ -402,7 +407,7 @@ campaign table, then use that same batch to tighten the fit filter and draft the
 message we should test.`
 - During long post-intake work, show concise progress checkpoints before the
   next expensive stage: source being checked, source switch/tradeoff if any,
-  lead sample usable, filter/message drafting, and full message prompt loading.
+  lead sample usable, filter/message drafting, and message-review rule loading.
   Each checkpoint should include a rough remaining time when useful. If a step
   exceeds its estimate by roughly a minute or more, acknowledge it lightly once
   and explain why the extra care helps the campaign. Example:
@@ -423,6 +428,10 @@ message we should test.`
 - `brief.md` is the single user-facing debug copy of the brief. The
   `CampaignOffer.campaignBrief` field is the stable downstream thesis source.
 - `lead-review.md` and `lead-sample.json` are the required outputs of `find leads`.
+  `lead-review.md` is customer-readable: describe source paths as provider
+  lanes checked (Signals, Sales Nav, Prospeo) and never include custom agent
+  names, host availability, install state, allowed-tool state, or fallback
+  implementation details.
 - `lead-filter.md` is the primary output of `filter leads`.
 - `rubric.json` is optional and secondary to `lead-filter.md`.
 - `message-prep.md` is an optional speed artifact produced by the explicit
@@ -443,14 +452,18 @@ message we should test.`
   campaign table `workflowTableId` exist, the normal path is the
   `post-lead-workstreams` step. Launch `filter leads` and `message generation`
   from the same basis (`brief.md`, `lead-review.md`, `lead-sample.json`, and
-  the imported review-batch rows) as separate workstreams when the host supports
-  real subagents/background work.
+  the imported review-batch rows) as separate workstreams when the host exposes
+  the named Sellable post-find-leads agents or real background work.
   First call `get_post_find_leads_scout_registry` and use the returned
-  canonical `name` values. In Claude Code, use both returned Task/Agent
-  subagents in the same assistant message; in Codex, use both returned custom
-  scouts as disjoint subagents in the same assistant turn when the host exposes
-  them. The existing `filter-rubric` and `message-generation` steps remain
-  focused retry and resume targets.
+  canonical `name` values only when those names are available in the current
+  runtime. In Claude Code, use both returned Task/Agent subagents in the same
+  assistant message when the session lists them; in Codex, use both returned
+  custom scouts as disjoint subagents in the same assistant turn when the host
+  exposes them. If the names are absent, the main thread still orchestrates the
+  same filter and message branches with MCP tools/assets from the same compact
+  context. Do not surface agent install status to the customer. The existing
+  `filter-rubric` and `message-generation` steps remain focused retry and
+  resume targets.
 - Message generation does not need `lead-filter.md` to start. The moment the
   bounded review batch is imported and `workflowTableId` is ready, start the
   message-generation workstream from `brief.md`, `lead-review.md`,
@@ -473,19 +486,23 @@ message we should test.`
 - Parallel means real parallel execution, not optimistic progress copy. For the
   lead-source scout, first call `get_source_scout_registry` and use the
   returned canonical `name` values. In Codex, explicitly spawn one named custom scout per
-  credible source lane when subagents are available: `source-scout-linkedin-engagement`
+  credible source lane when those subagents are visible in the current runtime:
+  `source-scout-linkedin-engagement`
   (display: LinkedIn Engagement Scout, powered by the `signal-discovery`
   provider prompt), `source-scout-sales-nav` (Sales Nav Scout), and
-  `source-scout-prospeo-contact` (Prospeo Contact Scout). For Claude Code, explicitly
-  invoke the generated `source-scout-*` Task/Agent subagents installed by
-  `@sellable/install` for all credible lanes in one assistant message; they are
-  installed from the same canonical Sellable agent registry and carry explicit
-  Sellable MCP tool allowlists. The parent thread should not preload every provider prompt before
-  spawning scouts; each scout loads only its own provider prompt. If host
-  subagents are unavailable, use independent MCP/tool calls
-  in the same model turn or dedicated Sellable MCP tools that perform
-  server-side `Promise.all` fan-out. If real parallel execution is not available
-  or not allowed, run the same DAG sequentially and use honest copy: `I’ll tighten the filter first,
+  `source-scout-prospeo-contact` (Prospeo Contact Scout). For Claude Code,
+  invoke the generated `source-scout-*` Task/Agent subagents for all credible
+  lanes in one assistant message only when the session exposes those names.
+  They are installed from the same canonical Sellable agent registry and carry
+  explicit Sellable MCP tool allowlists when `@sellable/install` is active. The
+  parent thread should not preload every provider prompt before spawning scouts;
+  each scout loads only its own provider prompt. If host subagents are
+  unavailable or the names are not visible, use the same provider probes via
+  independent MCP/tool calls in the parent thread or dedicated Sellable MCP
+  tools that perform server-side `Promise.all` fan-out. Do not write "source
+  scout agents are not installed" or similar host status into customer-facing
+  output. If real parallel execution is not available or not allowed, run the
+  same DAG sequentially and use honest copy: `I’ll tighten the filter first,
 then draft the message from the same sample.` Never say `kicking off two
 workstreams`, `in parallel`, or `background` unless parallel branches were
   actually launched.
@@ -698,15 +715,19 @@ Required behavior:
   branches, then compare the outputs in `lead-review.md`. Call
   `get_source_scout_registry` first so new scouts can be added without prompt
   rewrites. In Codex, explicitly
-  spawn named custom subagents in the same turn: `source-scout-linkedin-engagement`,
-  `source-scout-sales-nav`, and `source-scout-prospeo-contact` for the credible lanes. Codex
-  does not infer this from generic "compare paths" wording. If the realistic
+  spawn named custom subagents in the same turn when the host exposes them:
+  `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
+  `source-scout-prospeo-contact` for the credible lanes. Codex does not infer
+  this from generic "compare paths" wording. If the realistic
   source set is LinkedIn Engagement + Sales Nav (Signals + Sales Nav), run both.
   If it is LinkedIn Engagement + Prospeo Contact (Signals + Prospeo), run both.
   If all three are credible, run all three when the host/runtime supports it.
   In Claude Code, launch the matching `source-scout-linkedin-engagement`,
-  `source-scout-sales-nav`, and/or `source-scout-prospeo-contact` Task/Agent subagents
-  in the same assistant message, not as sequential scout turns.
+  `source-scout-sales-nav`, and/or `source-scout-prospeo-contact` Task/Agent
+  subagents in the same assistant message only when the current session lists
+  those names, not as sequential scout turns. If they are absent, run the same
+  provider probes with MCP tools from the parent thread and keep
+  `lead-review.md` focused on source evidence, not host-agent availability.
   - Branch A: LinkedIn Engagement / active LinkedIn posts (internal provider:
     Signals / `signal-discovery`). Search relevant keyword lanes, review
     finalist posts, fetch top-post engagers, and estimate warm-fit volume.
@@ -1042,17 +1063,29 @@ Do not:
 
 ## Step 3: Generate Message
 
-Step 3 follows the canonical `generate-messages` subskill — gold-standard examples, REPLY framework fallback, Proof Inventory, Token Fill Rules, Token Adherence Table, Angle Drafts, Kill/Combine Review, Finalists, Finalizer Pass, Gold-Standard Quality Gate, Skeptical Prospect Review, Winner Gate, and the message-review-decision contract. The `generate-messages` subskill is the authoritative source — this entry prompt does not duplicate it.
-
-When you reach Step 3, load the canonical subskill verbatim via chunked reads:
+Step 3 is orchestrated by the main thread and executed either by the
+`post-find-leads-message-scout` worker or by the parent-thread fallback. The
+worker carries the campaign-launch message rules in its agent prompt. The
+parent-thread fallback must load the small safety-gate reference before writing
+message artifacts:
 
 ```
-mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages", offset, limit })
+mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/message-review-safety-gate.md" })
 ```
 
-Continue chunked-read until `hasMore=false`. Treat all chunks as one prompt load. Follow it verbatim once loaded. The same directive is locked in `flow.v2.json::messageGeneration.toolRules`.
-
-Do NOT proceed to Step 4 (message review gate) without loading and following the full generate-messages workflow. `message-validation.md` must prove the full workflow ran (all required sections present + raw sendable Selected Winner + explicit single-send-unit PASS) before `message-review.md` can recommend `approve-message`. If the message review is ready but the generate-messages prompt was not retrieved in this run, route back to message-generation before queueing the 10-lead test cascade. If `message-validation.md` contains post-accept DM, follow-up, second-touch, cadence, branch, or other sequence-shaped copy, do not summarize it as ready; route back to message-generation and require a single first outbound send.
+Do not load the full long-form `generate-messages` subskill in
+`create-campaign-v2`. The safety-gate asset is a parent-thread fallback for hosts
+that cannot launch `post-find-leads-message-scout`, not the preferred route. If
+the safety gate is missing a needed campaign-specific rule or the draft fails
+quality gates, stop at `revise-messaging` with the exact failure instead of
+pulling the long prompt into the main thread.
+
+Do NOT proceed to Step 4 (message review gate) unless `message-validation.md`
+contains the safety-gate required sections, a raw sendable Selected Winner, and an
+explicit single-first-send PASS. If `message-validation.md` contains post-accept
+DM, follow-up, second-touch, cadence, branch, or other sequence-shaped copy, do
+not summarize it as ready; route back to message-generation and require a
+single first outbound send.
 
 After the main-chat message approval, update_campaign_brief writes `## Approved
 Message Template` with `{{...}}` tokens before any Generate Message cascade is

package/skills/create-campaign-v2/SOUL.md

@@ -233,22 +233,26 @@ supplied and multiple source angles are viable, scout Signals, Sales Nav, and
 relevant domain/contact paths as independent branches when the host can do so.
 Call `get_source_scout_registry` first and use the returned canonical `name`
 values; the names below are the current registry entries. In Codex, explicitly
-spawn named custom scouts in the same turn:
+spawn named custom scouts in the same turn when the current runtime exposes
+them:
 `source-scout-linkedin-engagement` (LinkedIn Engagement Scout, backed by the
 `signal-discovery` provider prompt), `source-scout-sales-nav` (Sales Nav Scout), and
 `source-scout-prospeo-contact` (Prospeo Contact Scout) for the credible lanes. Codex
 does not infer subagent fan-out from generic "compare paths" wording. In Claude
 Code, invoke the generated `source-scout-linkedin-engagement`, `source-scout-sales-nav`,
-and/or `source-scout-prospeo-contact` Task/Agent subagents in one assistant message so
-Claude can run the source lanes concurrently/background. These agents come from
-the same canonical Sellable registry and must load their matching provider
-prompt before searching. The parent thread should not fetch every provider
-prompt first; that burns time and often degenerates into parallel tool calls
-instead of true subagents. When asking the user to approve a brief with
-Sellable finding leads, use an explicit label like `Approve brief + use
-background source scouts` so the next turn has a user-visible request to spawn
-scouts. If the host runs them sequentially, keep the output numeric but do not
-claim the source scout was parallel.
+and/or `source-scout-prospeo-contact` Task/Agent subagents in one assistant
+message only when the session lists those names, so Claude can run the source
+lanes concurrently/background. These agents come from the same canonical
+Sellable registry and must load their matching provider prompt before
+searching. The parent thread should not fetch every provider prompt first; that
+burns time and often degenerates into parallel tool calls instead of true
+subagents. When asking the user to approve a brief with Sellable finding leads,
+use an explicit label like `Approve brief + use background source scouts` only
+when the current runtime exposes the named agents; otherwise use `Approve brief
+
+- compare source paths`. If the host runs them sequentially or the named agents
+  are absent, keep the output numeric but do not claim the source scout was
+  parallel or surface install status to the customer.
 
 For post-lead work, call `get_post_find_leads_scout_registry` after source
 approval and use the returned canonical `name` values. Launch both returned

package/skills/create-campaign-v2/core/flow.v2.json

@@ -947,11 +947,11 @@
               "ownership": "proof inventory, token strategy, angle drafting, skeptical-prospect review, and selected winner only"
             }
           ],
-          "earlyMessageStartRule": "After auto-execute-leads confirms the 10-row review batch and workflowTableId is ready, launch message-generation from brief.md, lead-review.md, lead-sample.json, and the imported campaign table sample. Legacy/resume preview prep still requires at least 5 probable good-fit rows. It may run beside filter-leads, but the cascade cannot queue until save_rubrics and update_campaign_brief both succeed.",
+          "earlyMessageStartRule": "After auto-execute-leads confirms the 10-row review batch and workflowTableId is ready, launch message-generation from brief.md, lead-review.md, lead-sample.json, and the imported campaign table sample. The message worker carries the campaign-launch message rules in its agent prompt; parent-thread fallback loads references/message-review-safety-gate.md. Legacy/resume preview prep still requires at least 5 probable good-fit rows. It may run beside filter-leads, but the cascade cannot queue until save_rubrics and update_campaign_brief both succeed.",
           "finalMessageReconcileRule": "message-validation.md may start before lead-filter.md exists, but before message-review it must cite only imported review-batch rows that still pass lead-filter.md. If the selected winner depends on a row later excluded by lead-filter.md, revise message-generation before message review.",
-          "claudeRule": "In Claude Code, launch both returned post-find-leads scouts with Task/Agent subagents in the same assistant message when Task is available. Do not run filter first and then message generation unless subagents/background work are unavailable.",
-          "codexRule": "In Codex, launch both returned post-find-leads scout names as disjoint subagents in the same assistant turn when the host exposes subagents for this run. If the host cannot spawn them, run the same branches sequentially and say so.",
-          "fallback": "If real parallel branches are unavailable, run filter-leads and then message-generation in the parent thread. Do not claim background or parallel work in that fallback."
+          "claudeRule": "In Claude Code, launch both returned post-find-leads scouts with Task/Agent subagents in the same assistant message only when the current session lists those agent names. Do not run filter first and then message generation unless subagents/background work are unavailable.",
+          "codexRule": "In Codex, launch both returned post-find-leads scout names as disjoint subagents in the same assistant turn only when the host exposes those custom agents for this run. If the host cannot spawn them, run the same branches sequentially and say so.",
+          "fallback": "If real parallel branches are unavailable or the named agents are absent, run filter-leads and then message-generation in the parent thread with product MCP tools/assets. Do not customer-surface agent install status, and do not claim background or parallel work in that fallback."
         },
         {
           "action": "wait_for_post_lead_artifacts",
@@ -1014,7 +1014,7 @@
         "The post-lead workstreams are disjoint: filter-leads owns lead-filter.md/rubric.json; message-generation owns message-validation.md/message-prep.md/message-candidate-drafts.md.",
         "message-generation can start before lead-filter.md, but message-review cannot start until both lead-filter.md and message-validation.md exist and reconcile against the same lead-sample.json.",
         "Do not let filter-leads create a new message sample. Do not let message-generation fetch new prospects.",
-        "Before writing message-validation.md, message-generation must read 100% of the real generate-messages prompt via chunked get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) calls.",
+        "Before writing message-validation.md, message-generation must either run in the post-find-leads-message-scout agent that carries the campaign-launch message rules in its prompt or load get_subskill_asset({ subskillName: \"create-campaign-v2\", assetPath: \"references/message-review-safety-gate.md\" }) in the parent-thread fallback. Do not load the full long generate-messages prompt in create-campaign-v2; if the safety gate cannot safely approve the draft, route to revise-messaging with the concrete failure.",
         "Do not queue, enrich, attach sequence, or start until save_rubrics succeeds and the approved message set is synced into campaignBrief."
       ],
       "doNotAllow": [
@@ -1181,11 +1181,11 @@
       "onEnter": [
         {
           "action": "run_or_reconcile_subskill",
-          "target": "generate-messages",
+          "target": "message-review-safety-gate",
           "mode": "DRY MODE",
           "sampleSource": "lead-sample.json from find-leads",
           "toolCallRequiredBeforeArtifacts": [
-            "get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) until hasMore=false"
+            "get_subskill_asset({ subskillName: \"create-campaign-v2\", assetPath: \"references/message-review-safety-gate.md\" }) unless the post-find-leads-message-scout agent prompt already supplied these rules"
           ],
           "skipIfFreshArtifactExists": "message-validation.md",
           "reconcileWith": "lead-filter.md; lead-sample.json remains the sample source"
@@ -1204,18 +1204,17 @@
         "message-validation.md"
       ],
       "allowedTools": [
-        "get_subskill_prompt",
         "get_subskill_asset",
         "AskUserQuestion",
         "request_user_input"
       ],
       "toolRules": [
-        "Before writing message-validation.md, message-review.md, or a message-review AskUserQuestion, the current run must read 100% of the real generate-messages prompt via chunked get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) calls.",
+        "Before writing message-validation.md, message-review.md, or a message-review AskUserQuestion, the current run must either execute inside the post-find-leads-message-scout agent that carries the campaign-launch message rules in its prompt or load get_subskill_asset({ subskillName: \"create-campaign-v2\", assetPath: \"references/message-review-safety-gate.md\" }) in the parent-thread fallback.",
         "Lead Sample Basis must cite rows from lead-sample.json produced by find-leads. lead-filter.md only gates those rows; it is not a source for a new sample.",
         "Do not hand-write message-validation.md from message-prep.md, message-candidate-drafts.md, or general campaign knowledge.",
-        "message-validation.md must prove the full generate-messages workflow ran: Gold Standard Strategy Map, Proof Inventory, Token Fill Rules, Token Adherence Table, Angle Drafts, Kill / Combine Review, Finalists, Finalizer Pass, Gold-Standard Quality Gate, Skeptical Prospect Review, Winner Gate, and a raw sendable Selected Winner are required before message-review can recommend approve-message.",
-        "If the Codex-hosted output is plausible but weaker than the loaded gold-standard examples, stop at message-review with revise-messaging. Do not continue to approval or mint just because the mechanical flow worked.",
-        "If message review is ready but the generate-messages prompt was not retrieved in this run, route back to message-generation instead of asking the user to approve the message.",
+        "message-validation.md must prove the message-review safety-gate workflow ran: Gold Standard Strategy Map, Campaign Element Pool, Current Campaign Translation, Token Fill Rules, Token Adherence Table, Angle Drafts, Kill / Combine Review, Finalizer Pass, Gold-Standard Quality Gate, Skeptical Prospect Review, Winner Gate, and a raw sendable Selected Winner are required before message-review can recommend approve-message.",
+        "If the hosted output is plausible but weaker than the safety-gate gold-standard rules, stop at message-review with revise-messaging. Do not continue to approval or mint just because the mechanical flow worked.",
+        "Do not load the full generate-messages subskill in create-campaign-v2. If the safety gate is missing a needed campaign-specific rule or the first safety-gate draft fails quality gates, route to revise-messaging with the concrete failure instead of loading the long prompt.",
         "The approved message set must be written back into campaignBrief before validate-sample queues the review-batch cascade."
       ],
       "doNotAllow": [
@@ -1867,6 +1866,19 @@
           "doNotRetain": "rows_payload",
           "contextBloatNote": "Pass includeRows=false so the MCP tool returns stats only; 25 rows ≈ 67KB and 100 rows ≈ 268KB when row payloads are retained (see references/sample-validation-loop.md §Known Tool Behaviors #2)."
         },
+        {
+          "action": "handle_partial_or_timeout_sample",
+          "when": "wait_for_rubric_results.ready_false_or_reason_timeout",
+          "rule": "Do not repeat waits indefinitely. If active processing is visible, wait once more at most. Otherwise treat returned passRate/stats as a partial sample and stop before Settings with sample_revision_required when passed rows are below minProjectedPass or generated messages are incomplete.",
+          "customerStatus": "sample-needs-revision",
+          "showFields": [
+            "passRate.completed",
+            "passRate.passed",
+            "passRate.pending",
+            "passRate.percent",
+            "stats.messagesCount"
+          ]
+        },
         {
           "action": "compute_projected_pass",
           "formula": "round(passInSample / sampleSize * importLimit)",
@@ -1906,6 +1918,8 @@
         "revision_round_persists_across_resume",
         "wait_for_rubric_results_never_retain_rows_payload_in_tail_context",
         "wait_for_rubric_results_targetCount_always_explicit",
+        "timeout_never_repeats_without_customer_handoff",
+        "timeout_or_underfloor_sample_never_advances_to_settings",
         "review_batch_cascade_waits_for_saved_rubrics_and_approved_template"
       ],
       "watchRequired": true,
@@ -1915,6 +1929,9 @@
       ],
       "transitions": {
         "sample_validated": "auto-execute-messaging",
+        "sample_revision_required": "lead-review",
+        "revise_leads": "find-leads",
+        "revise_rubric": "filter-rubric",
         "escalation_triggered": "escalation"
       },
       "requiredCampaignState": [

package/skills/create-campaign-v2/references/approval-gate-framing.md

@@ -32,12 +32,14 @@ Before showing the commit gate, the draft directory must contain all of:
 - `message-validation.md`
 - `approval-packet.md`
 
-The current run must also have retrieved the real message-generation prompt
-through `get_message_prompt({ promptName: "generate-messages" })` or
-`get_subskill_prompt({ subskillName: "generate-messages" })` before
-`message-validation.md`, `approval-packet.md`, or the commit gate is written.
-If the message template was written directly from memory or planning artifacts,
-do not show the commit gate; route back to message generation.
+The current run must also have retrieved message-generation rules before
+`message-validation.md`, `approval-packet.md`, or the commit gate is written. In
+`create-campaign-v2`, use the compact
+`references/message-review-safety-gate.md` asset or the embedded
+`post-find-leads-message-scout` prompt. Do not load the full long-form
+`generate-messages` subskill for the hosted campaign launch path. If the message
+template was written directly from memory or planning artifacts, do not show the
+commit gate; route back to message generation.
 
 `rubric.json` is optional but strongly preferred — when missing, derive it from
 `lead-filter.md` in the atomic mint step.

package/skills/create-campaign-v2/references/message-review-safety-gate.md

@@ -0,0 +1,96 @@
+# Message Review Safety Gate
+
+Use this reference for `create-campaign-v2` message review only in two cases:
+when these rules are embedded inside the `post-find-leads-message-scout` agent
+prompt, or when the host cannot launch that agent and the parent thread needs a
+compact fallback. It is the campaign-launch subset of `generate-messages`: enough
+to prove a truthful first-send message, rendered token examples, and an approval
+decision without loading the full long-form message-generation prompt into the
+main Claude/Codex thread.
+
+In a normal installed Claude/Codex session, the message scout owns these rules.
+The parent-thread asset is a compatibility fallback, not a shortcut. Do not load
+the full `generate-messages` subskill in this flow. If the safety gate is missing
+a needed campaign-specific rule or the draft fails quality gates, stop at
+`revise-messaging` with the exact missing rule/failure instead of pulling the
+long prompt into the main thread.
+
+## Required Workflow
+
+1. Read `brief.md`, `lead-review.md`, `lead-sample.json`, and `lead-filter.md`
+   when present.
+2. Pick 2-3 sample rows from `lead-sample.json`, preferring rows that pass the
+   filter or are likely to pass. Do not invent new rows.
+3. Build the message from the approved brief and the sampled rows. Use only
+   proof that appears in the brief, source review, sample, or explicit user
+   answers. Unsupported reply-rate, meeting-rate, ROI, revenue, and customer-logo
+   claims are blocked.
+4. Produce `message-validation.md` with the required sections below.
+5. Produce `message-review.md` as the customer-facing checkpoint.
+6. Ask exactly `approve-message` or `revise-messaging`. Do not import, queue,
+   attach sequence, or start before `approve-message`.
+
+## Required `message-validation.md` Sections
+
+- `Status`
+- `Mode`
+- `Lead Sample Basis`
+- `Strongest Reply Reason`
+- `Campaign Element Pool`
+- `Gold Standard Strategy Map`
+- `Current Campaign Translation`
+- `Token Fill Rules`
+- `Token Adherence Table`
+- `Angle Drafts`
+- `Kill / Combine Review`
+- `Finalizer Pass`
+- `Gold-Standard Quality Gate`
+- `Skeptical Prospect Review`
+- `Winner Gate`
+- `Selected Winner`
+- `Findings`
+- `Recommendation`
+
+Keep this artifact concise. It should prove the reasoning path, not reproduce
+the full framework.
+
+## Message Quality Gates
+
+- The selected winner must be one first outbound send only. No post-accept DM,
+  follow-up, cadence branch, or sequence copy.
+- The message must explain what the product is and what it does in plain
+  language before asking for a call.
+- The message must use a truthful buyer-side reply reason, not just sender
+  biography.
+- If using a template, include at least one supported `{{token}}` and show a
+  complete rendered good-fill example and complete rendered omit/fallback
+  example.
+- Do not use internal tokens such as `{{profile_signal}}` in customer-facing
+  copy.
+- Do not put bracketed instructions in the message body, such as `[ROW_BRIDGE]`,
+  `[insert]`, `[generated]`, or any instruction for a later model to fill.
+- Optional row-specific personalization must be grounded in a row field or
+  omitted entirely. Never use generic filler like "your work" or "your team."
+- Subject lines should be short, buyer-relevant, and specific. Avoid
+  `quick question`, `demo`, `founder call`, sender names, and generic `outbound`.
+- If the message is plausible but not ready to send, set
+  `Recommendation: revise-messaging`.
+
+## Customer-Facing `message-review.md`
+
+Render this in chat before asking:
+
+- `Status: message-review`
+- `Subject:`
+- `Message:` with the tokenized template or approved AI-native message
+- `Rendered examples:`
+- `Good token fill:`
+- `Good omit:`
+- `Token notes:`
+- `My take:`
+- `Suggested adjustment:`
+- `Question: approve-message or revise-messaging?`
+- `Recommendation: approve-message` or `Recommendation: revise-messaging`
+
+`My take` and `Suggested adjustment` must be specific. The adjustment can be
+"approve as-is, or revise once to X if you want Y"; it must not be empty.

package/skills/create-campaign-v2/references/sample-validation-loop.md

@@ -58,18 +58,37 @@ auto-revise leads.
 
 7. call `wait_for_rubric_results` with `includeRows=false`; extract ONLY:
    - ready: boolean
+   - reason: string when `ready=false`
    - passRate.completed: number
+   - passRate.passed: number
+   - partialResult: object when present
    - stats: object
    Never retain the full rows payload in tail context.
    - 25 rows ≈ 67KB of payload (full post bodies in carryData)
    - 100 rows ≈ 268KB; 500 rows ≈ 1.3MB — blows context on Opus
      (see §Known Tool Behaviors #2)
 
-8. compute metrics:
+8. if `ready=false` and `reason="timeout"`:
+   - do NOT keep polling indefinitely
+   - treat the returned passRate/stats as a partial sample
+   - if active processing is visible (`processingCount > 0` or a similar
+     running-cell stat), one additional wait is allowed
+   - otherwise diagnose the partial sample now
+   - if passed rows are below `sample.minProjectedPass` or generated messages
+     are missing for passing rows, stop before Settings with:
+     `Status: sample-needs-revision`
+   - show the concrete numbers: completed, passed, pending, pass percent, and
+     message count when available
+   - offer the next product choices: revise source, revise filter/rubric, or
+     wait once only if there is active processing
+   - never advance to Settings or awaiting-user-greenlight on a timeout or
+     underfloor partial sample
+
+9. compute metrics:
    passInSample       = count of review-batch rows where rubric passed
    projectedPass      = round(passInSample / sampleSize * importLimit)
 
-9. branch:
+10. branch:
    if projectedPass >= minProjectedPass:
        proceed to Step 15 (auto-execute-messaging) with this review batch
    else:
@@ -140,6 +159,19 @@ Workaround: strip `carryData` from each row IMMEDIATELY after reading
 and BEFORE retaining. Prefer a minimal projection (name, title,
 company, enrichCellId, enrichStatus) over the default shape.
 
+### 5. `wait_for_rubric_results` can timeout with enough signal to decide
+
+Observed: a 10-row review batch may return `ready=false`, `reason="timeout"`,
+and partial stats such as 9/10 scored, 2 passing, 2 messages generated. That is
+enough to diagnose an underperforming sample. Waiting again without active
+processing makes the experience feel frozen.
+
+Workaround: treat timeout stats as a partial sample. If the pass count is below
+the configured floor or message generation has not covered the passing rows,
+stop at `Status: sample-needs-revision` before Settings. Show the completed /
+passed / pending counts and ask whether to revise source, revise filter/rubric,
+or wait once only if active processing is still visible.
+
 ## Projected Pass Math
 
 ```text

package/skills/create-campaign-v2-tail/SKILL.md

@@ -269,10 +269,19 @@ Shape:
 queue_cells({ tableId: workflowTableId, cellIds: reviewBatchEnrichCellIds })
 wait_for_campaign_table_ready({ tableId: workflowTableId })
 get_rows_minimal({ tableId: workflowTableId })
+wait_for_rubric_results({ tableId: workflowTableId, targetCount: cohortSize, includeRows: false })
 passInSample = count of first sampleSize review-batch rows with passesRubric === true
 projectedPass = round(passInSample / sampleSize * importLimit)
 
-if projectedPass >= minProjectedPass:
+if wait_for_rubric_results.ready === false and reason === "timeout":
+    use the partial passRate/stats as the sample diagnostic
+    if active processing is visible:
+        wait one more time at most
+    else:
+        stop before Settings with Status: sample-needs-revision
+        show completed, passed, pending, pass percent, and message count when available
+        ask whether to revise source, revise filter/rubric, or wait once only if still processing
+else if projectedPass >= minProjectedPass:
     advance to Step 15
 else:
     diagnose brief-vs-list per sample-validation-loop.md
@@ -293,6 +302,11 @@ Do NOT reset to 0 on resume — a stale resume must still respect the
 A "list problem" diagnosis NEVER triggers autonomous
 `update_campaign_brief`. Escalate instead.
 
+A timeout or underfloor partial sample NEVER advances to Settings,
+awaiting-user-greenlight, or start-campaign. It must hand off as
+`sample_revision_required` with the observed counts so the user can decide
+whether the source or filter should change.
+
 When the sample passes the projected-pass floor, call
 `update_campaign({ campaignId, currentStep: "auto-execute-messaging" })`
 and orient the user that messaging will complete for the review batch only.

package/skills/find-leads/SKILL.md

@@ -68,9 +68,10 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
 - Before source-scout dispatch, call `get_source_scout_registry` and use the
   returned `name` values. The current canonical names are listed below for
   readability, but the registry is the source of truth for install/runtime.
-- If Codex subagents are available, run the scout lanes with named custom
-  agents. Spawn one agent per credible lane in the same turn, then wait for all
-  lane results before synthesizing `lead-review.md`:
+- If Codex subagents are available and the current runtime exposes the returned
+  names, run the scout lanes with named custom agents. Spawn one agent per
+  credible lane in the same turn, then wait for all lane results before
+  synthesizing `lead-review.md`:
   - `source-scout-linkedin-engagement` (display: LinkedIn Engagement Scout) for
     active LinkedIn posts and engagers; internally this uses the
     `signal-discovery` provider prompt plus `search_signals` /
@@ -81,15 +82,20 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
     account/domain and verified-contact expansion.
 - Common parallel comparisons are LinkedIn Engagement + Sales Nav, LinkedIn
   Engagement + Prospeo Contact, or all three when each lane is credible.
-- If Claude `Task`/`Agent` is available, deep exploration uses the file-backed
-  Claude explorer agents installed from the same canonical Sellable agent
-  registry. Launch every credible lane in the same assistant message so Claude
-  Code can run them concurrently/background:
+- If Claude `Task`/`Agent` is available and the current Claude session lists
+  the returned source-scout names, deep exploration uses the file-backed Claude
+  explorer agents installed from the same canonical Sellable agent registry.
+  Launch every credible lane in the same assistant message so Claude Code can
+  run them concurrently/background:
   - `./.claude/agents/source-scout-linkedin-engagement.md`
   - `./.claude/agents/source-scout-sales-nav.md`
   - `./.claude/agents/source-scout-prospeo-contact.md`
 - These Claude agents must have explicit Sellable MCP tool allowlists and must
-  load the matching provider prompt before searching.
+  load the matching provider prompt before searching. They are optional
+  acceleration: if the names are absent, do not mention the missing install or
+  agent availability in customer-facing output. Run the same provider probes
+  from the parent thread with MCP tools and keep `lead-review.md` focused on
+  source evidence.
 - The parent thread should not preload every provider prompt before launching
   scouts. Spawn the credible scouts first; each scout loads only the provider
   prompt for its lane and returns structured evidence.
@@ -261,9 +267,10 @@ If the first probe is weak or noisy and enough context exists, try 1-2 alternate
 If the first probe has good quality but insufficient scale, iterate 1-2 times to widen intelligently before returning.
 When two or more source angles are viable, run the provider probes in real
 parallel when the host/runtime allows it. For Codex, explicitly spawn the
-named source scout agents above; Codex will not infer subagent fan-out from
-general "compare sources" wording. For Claude Code, explicitly invoke the
-matching `source-scout-*` Task/Agent subagents in one message instead of
+named source scout agents above only when those returned names are visible;
+Codex will not infer subagent fan-out from general "compare sources" wording.
+For Claude Code, explicitly invoke the matching `source-scout-*` Task/Agent
+subagents in one message only when the current session exposes them, instead of
 probing one lane, waiting, then probing the next. Examples: LinkedIn Engagement
 
 - Sales Nav, LinkedIn Engagement + Prospeo Contact, or Sales Nav + Prospeo
@@ -433,8 +440,10 @@ Show the light-touch results and ask whether to deep-dispatch or iterate.
 ## Layer 3: Selective deep exploration
 
 Spawn only the validated paths from Gate 1. In Claude Code, invoke all selected
-`source-scout-*` agents in one turn so source scouting is concurrent when the
-runtime supports it.
+`source-scout-*` agents in one turn only when the current session exposes those
+agent names, so source scouting is concurrent when the runtime supports it. If
+they are absent, run the validated provider probes from the parent thread
+without telling the customer about host-agent install state.
 
 - `source-scout-linkedin-engagement`
 - `source-scout-sales-nav`