@sellable/mcp 0.1.191 → 0.1.193

package/skills/create-campaign-v2/references/step-15-re-cascade.md

@@ -27,8 +27,8 @@ Re-cascade runs whenever ALL of the following are true:
    to continue processing more campaign rows.
 2. A subsequent check of rubric state shows rows that were pending at
    first message-generation pass are now passed.
-3. Those newly-passed rows do NOT yet have generated messages
-   (`messagesCount` flat relative to pre-cascade).
+3. Those newly-passed rows do NOT yet have current-revision generated messages
+   (`currentRevisionGeneratedMessagesCount` flat relative to pre-cascade).
 4. Step 15 has NOT yet transitioned to `awaiting-user-greenlight`.
 
 Before that first generated-message approval, do not run this loop just to wait
@@ -41,25 +41,31 @@ rows graduated.
 ## Re-Cascade Loop Shape
 
 ```text
-1. paginate campaign table (get_rows_minimal, strip carryData) to
-   collect rowIds where:
-     - rubricStatus = "passed"
-     - messageStatus = "pending" OR messagesCount = 0
+1. use selector dry-run only if debugging:
+   `select_campaign_cells({ columnRole: "generateMessage", rowSelector: { type: "needsGeneratedMessage" } })`
+   The normal path can skip this and queue directly.
 
-2. if newlyPassedRowIds.length == 0:
+2. if selectedCellCount == 0:
      proceed to awaiting-user-greenlight
      EXIT re-cascade loop
 
 3. else:
-     queue_cells({
+     queue_campaign_cells({
        tableId,
-       cellIds: newlyPassedGenerateMessageCellIds
+       columnRole: "generateMessage",
+       rowSelector: { type: "needsGeneratedMessage" }
      })
 
-4. re-check token contract on the cascaded subset (strict mode default)
+4. wait_for_campaign_processing({
+       tableId,
+       minGeneratedMessages: 1,
+       templateRevision: "current"
+     })
+
+5. re-check token contract on the cascaded subset (strict mode default)
    — see references/thomas-revision-filters.md + gold-standard-message-patterns.md
 
-5. go back to step 1 until newlyPassedRowIds == 0
+6. go back to step 1 until selectedCellCount == 0
 ```
 
 ## Cap
@@ -86,9 +92,10 @@ silently skipped.
 ## Hard Rules
 
 - Generate Message cells do not always auto-cascade on late-passed rows —
-  Step 15 must explicitly queue newly-pending Generate Message cells.
+  Step 15 must explicitly queue `needsGeneratedMessage` cells.
 - Re-cascade iteration cap = 3. Trip escalates.
-- `messagesCount` flat + rubric graduating rows ⇒ re-cascade required.
+- `currentRevisionGeneratedMessagesCount` flat + rubric graduating rows ⇒
+  re-cascade required.
 - Token contract enforcement applies per-cascade, not once-for-all.
 - Re-cascade NEVER re-runs `import_leads`, `check_rubric`, or
   `enrich_with_prospeo`. Those are Step 13 / Step 14 actions.

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

@@ -30,9 +30,8 @@ Step 13 — materialize source list + confirm initial campaign slice
   materialize/reuse approved source with campaignOfferId
   import_leads(source-list target; SalesNav/Prospeo default ~1000, Signal Discovery default ~1500 engagers)
   wait_for_lead_list_ready
-  confirm_lead_list(reviewBatchLimit=15)
+  confirm_lead_list(reviewBatchLimit=15)  # compact reviewBatch metadata is stored on the campaign table
   wait_for_campaign_table_ready    # campaign table exists
-  get_rows_minimal                 # read initial campaign-table execution slice
   update_campaign(currentStep=filter-choice)
 
 Post-import main thread
@@ -45,22 +44,17 @@ Post-import main thread
   only then start the initial-slice cascade
 
 Step 14 — kick initial-slice cascade + observe campaign rows
-  queue_cells(cellIds=<first 15 campaign-table execution-slice Enrich Prospect cells only>)  <-- starts bounded chain
-  wait_for_campaign_table_ready    # wait until sample cascade starts returning filter results
-  get_rows_minimal                 # read passesRubric + message cell status per row
-  wait_for_rubric_results(minPassedCount=1, includeRows=false)
+  queue_campaign_cells(columnRole=enrich, rowSelector=reviewBatch)  <-- starts bounded chain
+  wait_for_campaign_processing(minPassedCount=1)
   if at least one row passes: update_campaign(currentStep=auto-execute-messaging)
   compute projectedPass for later reporting / revision decisions
-  if zero rows pass: diagnose brief-vs-list; if brief: update_campaign_brief + re-queue + wait
+  if zero rows pass: diagnose brief-vs-list; if brief: update_campaign_brief + re-queue + wait with changed args
   (check_rubric / bulk_enrich_with_prospeo are NOT called here —
-   cascade already did them. wait_for_rubric_results is OK as a
-   read-only observation helper if you need to block until the first
-   passing filtered row exists.)
+   cascade already did them.)
 
 Step 15 — observe messaging
-  wait_for_rubric_results({ minPassedCount: 1, minMessagesCount: 1, includeRows: false })
-  get_rows_minimal                 # confirm the first passing generated message exists
-  (rare) queue_cells on any pending Generate Message cells
+  queue_campaign_cells(columnRole=generateMessage, rowSelector=needsGeneratedMessage)
+  wait_for_campaign_processing({ minGeneratedMessages: 1, templateRevision: "current" })
   token-contract spot check via get_rows
   update_campaign(currentStep=auto-execute-messaging) with review-ready narration
   ask the user to approve the generated message before Settings
@@ -99,19 +93,14 @@ Message` column's http_request writes those cells via the cascade.
 - Do NOT call `check_rubric`, `enrich_with_prospeo`, or
   `bulk_enrich_with_prospeo` in the tail. Those are direct-API
   mutation tools that fetch data to the caller without writing to
-  the workflow table cells. Step 13's `queue_cells` already
+  the workflow table cells. Step 14's `queue_campaign_cells` call
   triggers the column-level enrichment that populates those cells.
   Running these tools in the tail produces duplicate cost with no
   cell side effect.
-- `wait_for_rubric_results` is read-only and OK to use as an
-  observation helper when you need to block on rubric completion —
-  it does not mutate cells. Prefer `get_rows_minimal` +
-  `wait_for_campaign_table_ready` for the primary cascade-observation
-  path, but use `wait_for_rubric_results({ targetCount: cohortSize })`
-  when the table-level wait returns before rubric cells finish. In
-  create-campaign-v2 Step 14, pass `minPassedCount: 1`; one passing
-  filtered row is enough to start observing Generate Message, even if
-  other sample rows are still processing.
+- `wait_for_campaign_processing` is the stats-only observation helper for the
+  tail. In Step 14 pass `minPassedCount: 1`; in Step 15 pass
+  `minGeneratedMessages: 1` and `templateRevision: "current"`. Do not repoll
+  identical args after a timeout.
 - `start_campaign` is FORBIDDEN in the autonomous tail. It belongs only
   in the Claude-greenlight path, AFTER the user signals "start". See
   `references/final-handoff-contract.md`.
@@ -121,15 +110,16 @@ Message` column's http_request writes those cells via the cascade.
 - You MAY NOT call `start_campaign` while ANY passing row has an
   empty `Generate Message` cell. If you discover empty message cells in
   the greenlight turn, ABORT greenlight and return to Step 15 first.
-- You MAY NOT call `attach_sequence` while ANY passing row has an
-  empty `Generate Message` cell. Before `attach_sequence`, call
-  `get_rows_minimal` and confirm every row where `passesRubric=true`
-  has a `completed` Generate Message cell with non-empty `result`. If
-  any are pending, call `queue_cells` on those generateMessageCellIds
-  and wait. If rows truly won't message, ESCALATE.
-- You MAY NOT advance past Step 13 without calling `queue_cells` on
-  the initial-slice Enrich Prospect cells. Without it, every downstream
-  cell stays `pending` and the campaign ships empty.
+- You MAY NOT call `attach_sequence` while ANY reviewed passing row has an
+  empty or stale `Generate Message` cell. Before `attach_sequence`, call
+  `select_campaign_cells({ tableId, columnRole: "generateMessage",
+  rowSelector: { type: "needsGeneratedMessage" } })`. If any cells are
+  selected, call `queue_campaign_cells` with the same selector and wait with
+  `wait_for_campaign_processing({ minGeneratedMessages: 1,
+  templateRevision: "current" })`. If rows truly won't message, ESCALATE.
+- You MAY NOT advance past Step 14 without calling `queue_campaign_cells` for
+  `{ columnRole: "enrich", rowSelector: { type: "reviewBatch" } }`. Without it,
+  every downstream cell stays `pending` and the campaign ships empty.
 - You MAY NOT queue enrichment for rows outside the configured internal
   execution slice before the user approves expansion. Full-list enrichment/message
   generation is a credit-spend decision and must happen after the user
@@ -141,9 +131,8 @@ All subsequent steps read the already-parsed config. Do not re-load mid-run,
 and do not read repo-local config files; packaged Claude Code and Codex runs
 must use the MCP asset loader.
 Load each subskill prompt (`create-campaign-v2`, `research-sender`,
-`generate-messages`) at most once per run. A multi-call chunk sequence counts
-as one load. If a tool result already told you to load a prompt, load all
-chunks once and remember; do not restart the same prompt from offset 0 later.
+`generate-messages`) at most once per run. If a tool result already told
+you to load a prompt, remember it; do not restart the same prompt later.
 
 After every `update_campaign({ currentStep: ... })` in the tail, narrate
 what changed and orient the user to what the already-open app will show next —
@@ -265,16 +254,17 @@ searchId, targetLeadCount: 1000 })`.
    the source list and `workflowTableId` is the campaign table.
 4. `wait_for_campaign_table_ready` until the initial campaign-table execution slice rows are
    available in the campaign table.
-5. Call `get_rows_minimal({ tableId: workflowTableId })` and confirm the
-   15-row internal execution slice is present. Do not queue cells in Step 13.
+5. Confirm the compact `reviewBatch` returned by `confirm_lead_list` has the
+   expected 15-row internal execution slice metadata. Do not fetch row payloads
+   or queue cells in Step 13.
 6. If the import returns zero usable leads, ESCALATE per
    `references/escalation-ladder.md` (hard fail).
 7. `update_campaign({ campaignId, currentStep: "filter-choice" })`.
 8. Describe the filter-choice screen now visible in the already-open app. Do not
    repeat the watch URL.
 
-**Do NOT call `check_rubric`, `wait_for_rubric_results`,
-`queue_cells`, `enrich_with_prospeo`, or `bulk_enrich_with_prospeo` in Step 13.**
+**Do NOT call `check_rubric`, `wait_for_campaign_processing`,
+`queue_campaign_cells`, `enrich_with_prospeo`, or `bulk_enrich_with_prospeo` in Step 13.**
 Those are direct-API tools that fetch enrichment/scoring data to the
 caller or start the workflow-table cascade too early. The cascade starts in
 Step 14 only after `save_rubrics` and `update_campaign_brief` have both
@@ -299,18 +289,16 @@ message is ready. It does NOT call `check_rubric`,
 Shape:
 
 ```text
-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, minPassedCount: 1, includeRows: false })
+queue_campaign_cells({ tableId: workflowTableId, columnRole: "enrich", rowSelector: { type: "reviewBatch" } })
+wait_for_campaign_processing({ tableId: workflowTableId, minPassedCount: 1 })
 passInSample = count of first sampleSize review/process sample rows with passesRubric === true
 projectedPass = round(passInSample / sampleSize * importLimit)
 
-if wait_for_rubric_results.ready === true and passRate.passed >= 1:
+if wait_for_campaign_processing.ready === true and passRate.passed >= 1:
     advance to Step 15 to observe or queue Generate Message for currently passing rows
     do not wait for every sample row to finish before message generation starts
     stop for review as soon as one passing generated message is ready
-else if wait_for_rubric_results.ready === false and reason === "timeout":
+else if wait_for_campaign_processing.ready === false and reason === "timeout":
     use the partial passRate/stats as the sample diagnostic
     if passRate.passed >= 1:
         advance to Step 15 to observe/queue Generate Message for passing rows
@@ -322,9 +310,10 @@ else if wait_for_rubric_results.ready === false and reason === "timeout":
         ask whether to revise source, revise filter/rubric, or wait once only if still processing
 else:
     diagnose brief-vs-list per sample-validation-loop.md
-    - brief: autonomous update_campaign_brief, then re-kick cascade
-             (queue_cells on enrichCellIds) and wait for the new
-             results
+    - brief: autonomous update_campaign_brief, then re-kick cascade with
+             queue_campaign_cells({ columnRole: "enrich", rowSelector:
+             { type: "reviewBatch" }, forceRerun: true }) and wait for the
+             new results
     - list:  ESCALATE (no auto-revision of leads)
     - unknown: ESCALATE
     revisionRound += 1
@@ -361,8 +350,8 @@ Entered on `CampaignOffer.currentStep === "auto-execute-messaging"`.
 
 **Messages are produced by the `Generate Message` column cascade, not
 by a separate tool.** Do NOT call a `generate_messages` MCP tool —
-that tool does not exist; `generate-messages` is a subskill prompt
-loaded during live messaging drafts. In the autonomous tail, messages
+that tool does not exist; the full `generate-messages` subskill prompt is the
+Message Draft Builder contract for the approved template. In the autonomous tail, messages
 flow through the column pipeline: `Enrich Prospect` →
 `DNC Check` → `ICP Score` → `Passes Rubric` → `Generate Message`.
 Each column's http_request auto-fires when its upstream dependency
@@ -373,21 +362,19 @@ the output — not to generate messages manually.
 
 **What Step 15 does:**
 
-1. `get_rows_minimal` to read `passesRubric` + `generateMessageCellId`
-   - the Generate Message cell's `status` and `result` per row.
-     Before queueing or waiting on Generate Message cells, confirm the
-     minted campaign brief still contains `{{...}}` in `## Approved Message
-Template`. If it does not, fail before the cascade runs. Do not repair
-     after mint; the template must be present during mint so Step 15 never
-     starts in freeform generation mode.
-2. For every row where `passesRubric === true`:
-   - The Generate Message cell should be `running` or `completed`
-     already (cascade auto-fired it). If it is still `pending`, queue
-     it explicitly: `queue_cells({ tableId, cellIds:
-<generateMessageCellIds> })`.
-3. `wait_for_rubric_results({ tableId, targetCount: reviewBatchSize,
-minPassedCount: 1, minMessagesCount: 1, includeRows: false })` until the
-   first passing generated message is ready. Do not wait for every passing row's
+1. Before queueing or waiting on Generate Message cells, confirm the minted
+   campaign brief still contains `{{...}}` in `## Approved Message Template`.
+   If it does not, fail before the cascade runs. Do not repair after mint; the
+   template must be present during mint so Step 15 never starts in freeform
+   generation mode.
+2. Use `select_campaign_cells({ tableId, columnRole: "generateMessage",
+   rowSelector: { type: "needsGeneratedMessage" } })` only if you need a dry-run
+   count. If any passing row has a pending, empty, or stale Generate Message
+   cell, queue it explicitly with `queue_campaign_cells({ tableId, columnRole:
+   "generateMessage", rowSelector: { type: "needsGeneratedMessage" } })`.
+3. `wait_for_campaign_processing({ tableId, minGeneratedMessages: 1,
+templateRevision: "current" })` until the first current-revision generated
+   message is ready. Do not wait for every passing row's
    Generate Message cell, and do not add "one more wait" for a stronger sample.
    Remaining review/process sample rows can continue processing in the background.
 4. Read the first ready generated message back via `get_rows` (full) and

package/skills/generate-messages/SKILL.md

@@ -46,8 +46,8 @@ Reject the branch as blocked if the campaign id, selected lead list, workflow
 table, or review-batch row ids/hash do not match. Do not reconstruct state from
 stale local markdown artifacts or direct database reads.
 
-Return compact output only: template recommendation, token fill rules, rendered
-sample, concerns, status, basis token, output timestamp/hash, and error or
+Return message-draft output only: template recommendation, token fill rules,
+rendered sample, concerns, status, basis token, output timestamp/hash, and error or
 retry detail. Do not write message cells, enrich rows, update the campaign
 brief, attach sequence, or imply send readiness from this branch.