@trydreamstate/cli 1.3.8 → 1.3.12

package/agent-plugin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "dreamstate",
-  "version": "1.3.8",
+  "version": "1.3.12",
   "description": "Dreamstate for AI agents: build workbooks of companies and people, run LinkedIn and email sequences, answer replies, post to LinkedIn and X, and manage your CRM from your coding agent.",
   "author": {
     "name": "Dreamstate",

package/agent-plugin/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "dreamstate",
-  "version": "1.3.8",
+  "version": "1.3.12",
   "description": "Dreamstate for AI agents: build workbooks of companies and people, run LinkedIn and email sequences, answer replies, post to LinkedIn and X, and manage your CRM from your coding agent.",
   "author": {
     "name": "Dreamstate",

package/agent-plugin/skills/crm/SKILL.md

@@ -3,7 +3,7 @@ name: crm
 description: "Maintain trustworthy customer and company records by separating stable facts, judgement, and time-bound activity; deduplicating only from strong identity evidence; and keeping pipeline tied to recent, evidenced work. Use it when the user needs to create, review, clean up, merge, enrich, or progress relationship records and deals. It does not rebuild source worksheets (list-building does), run outreach (outreach does), or replace a workflow with record cleanup (workflows does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # CRM
 
@@ -16,6 +16,8 @@ Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabiliti
 
 CRM is shared operating memory for customer relationships. A record lets team see who someone is, what happened, what is next, and why pipeline says what it says. Good CRM work makes future action safer; it does not make database look full.
 
+Creating or binding CRM people from otherwise unbound worksheet rows is deliberate CRM cleanup or import work. It is not required before outreach can preview, rehearse, or enroll those worksheet rows: sequence enrollment resolves identity records as part of its own staging flow.
+
 ## The invariant
 
 Preserve evidence, identity, and human judgement. Read before every change. Every read is free, so inspect current record, related records, recent timeline, ownership, and open work before creating, updating, or merging anything.
@@ -45,6 +47,8 @@ Keeping a CRM in step with the workspace usually has a blueprint: HubSpot, Attio
 8. **Run weekly hygiene pass.** Read first: review newly created records, suspected duplicate pairs, fields with conflicting or stale evidence, open deals with no activity in 21+ days, deals without next step or owner, and recently changed stages. Fix low-risk, evidence-backed field gaps; show evidence and exact change for merges and consequential stage changes, then act when the user asked or confirms; then read back sampled records and headline counts.
 9. **Find stale deals in one read.** Read open deals with stale cutoff and continue global pages until complete. Request meaningful activity only, so automated tasks, record creation, field history, and stage events cannot make deal look healthy. Do not read one timeline per deal. For every stale deal, prepare one follow-up task with deal link, owner, due date, and priority. Create them as draft tasks so nobody is notified until the user reviews them; reopening a draft makes it open work and notifies the assignee.
 
+10. **Use billing and product truth from Stripe and PostHog.** Whether a company is a customer, its plan, MRR and lifetime value come from Stripe through `provider.stripe.customer_lookup`, never from a guess or an enrichment. Use it before creating a deal (an existing customer is expansion, not new business) and before any cold list or sequence touches a company (customers are excluded unless the user asked for an expansion play). MRR and lifetime value total only within one currency; a company that pays in several currencies reads currency `mixed` with per-currency totals, so never add those numbers together. Product usage, such as last seen and recent event counts, comes from `provider.posthog.person_lookup` and is evidence for a stage change or a next step, not a field to overwrite human judgement. Stripe data is read-only here: nothing in this skill changes a customer, subscription or person in Stripe or PostHog.
+
 ## Credit posture and sensitive effects
 
 Reads, duplicate review, and timeline inspection are free and come before enrichment. For paid enrichment, state target records, fields sought, expected coverage, credit estimate, and how result will be reviewed, then run it under the paid-run consent rule. Do not enrich records merely to fill blanks.

package/agent-plugin/skills/diagnostics/SKILL.md

@@ -3,7 +3,7 @@ name: diagnostics
 description: "Answer one operational question with evidence, such as where a cell value came from or why it is empty, which runs failed and which are safe to retry, why a sequence has not sent, or where credits went and how to spend less. Use it when something in a worksheet, sequence or workflow looks wrong, stuck, missing or expensive. It reads before it changes anything. It does not redesign lists, sequences or workflows, or tidy worksheet structure (worksheet-tidy does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Diagnostics
 
@@ -33,7 +33,7 @@ Read first, change second. Pending, queued, paced, capped and unknown are not fa
 | Where did this value come from, or why is this cell empty? | The cell, its column, the run that settled it |
 | Which rows or runs failed, and which are safe to retry? | Run history, then one run's events |
 | Why has this sequence not sent? | Sequence state, enrollment, sender, sending hours, caps |
-| Why did this cost so much, and how do I spend less? | Finished runs and charged credits |
+| Why did this worksheet cost so much, and how do I spend less? | The worksheet credit summary, then individual charged runs |
 
 ## Evidence order
 
@@ -46,6 +46,12 @@ Read first, change second. Pending, queued, paced, capped and unknown are not fa
 
 Search the tool for the read you need. The search returns runnable schemas for its top hits; read any other ids together in one tools_get, then run.
 
+For worksheet costs, discover and read the worksheet credit summary before drilling into
+runs. Its decimal total and per-column breakdown cover the entire worksheet,
+including historical executions. Check completeness and pending attempts: a
+partial recorded total does not prove the remaining work was free. Current cell
+values and the visible grid window do not represent cumulative spend.
+
 ## Common findings
 
 - **Column empty on every row:** its gate reads a column that has not settled, or it was added after rows landed and never ran on them.
@@ -72,3 +78,11 @@ Search the tool for the read you need. The search returns runnable schemas for i
 Done means checked, not built. Before you report, read back everything you made or changed, and run, test or preview it where that is offered; publish or send only when the user asked. An empty, failed or wrong result means an input or setting is wrong: find which from the error or the output, correct it and check again, until it is right or a real blocker stops it. Report what you checked and what it showed.
 
 Paid and outward runs follow the paid-run consent rule.
+
+## Sequence evidence
+
+Read audience matches, eligible, duplicates, blocked rows, staged candidates, admitted people and actual sends as different measures. An unavailable count is not zero. An incomplete row sample or analytics read cannot establish a full-population total. A failed analytics request needs an explicit error and retry; cached totals need a freshness marker.
+
+Separate invitation requests from DMs waiting for acceptance. A waiting-connection timestamp is the acceptance deadline, not an earliest send time: acceptance can wake the DM sooner. Distinguish a schedule window, a daily or rolling-week limit, reservations owned by existing obligations, a provider restriction, missing identity, a disconnected sender and a service failure. Future invitation commitments can reserve weekly room even if they use no daily room today. Preserve configured limits.
+
+For a person, read the current step, pinned source and version, pause/stop reason, next check or deadline, attempt and receipt evidence before suggesting a repair. Unknown delivery requires reconciliation; proven absence is a different outcome. Resume only the system pause that the evidence allows to recover. Never resume manual stops, replies, unsubscribes or other recipient stops. Archived personalization sources and OOO without a reliable structured return date require visible review. Do not infer return dates from keywords or elapsed time.

package/agent-plugin/skills/dreamstate/SKILL.md

@@ -21,6 +21,6 @@ Lists, finds, enrichments and signals happen only inside a workbook worksheet. R
 
 For writes, credit spend or external effects: dry_run first, review the row count and credit estimate, then run live with the quote_hash that dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. Supply max_rows or max_live_sends only when the fetched capability schema declares them; when an external send accepts max_live_sends, cover at least the dry_run recipient_count. Sequence lifecycle and enrollment calls have no lifetime send ceiling. A quote returned by a refused live call is only a price, never a confirmation.
 
-A paid run above the server's row or provider-spend limit, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply.
+A paid run above the server's row or provider-spend limit, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply.
 
 `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices.

package/agent-plugin/skills/facebook-posts/SKILL.md

@@ -3,7 +3,7 @@ name: facebook-posts
 description: "Write and revise Facebook posts: conversational copy up to 63,206 characters, and where a link sits so the opening still reads as a person. Use it for the copy of any post going to Facebook. It does not cover scheduling, publishing or automations (social does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Facebook posts
 

package/agent-plugin/skills/first-win/SKILL.md

@@ -3,7 +3,7 @@ name: first-win
 description: "Run a short first session in a new workspace that confirms the user and workspace, builds or reads Company Context, creates one small sampled worksheet from the ideal customer, and suggests three next plays. Use it on a fresh workspace, when the user says \"get me started\", or when nothing has been built yet. It does not launch outreach, publish content or run anything at scale."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # First Win
 

package/agent-plugin/skills/inbox-replies/SKILL.md

@@ -3,7 +3,7 @@ name: inbox-replies
 description: "Triage and answer existing LinkedIn and email conversations, classify the latest inbound message, confirm the sequence stopped, and draft a reply grounded in the real thread and Company Context. Use it when someone replied, when the user wants to work through unanswered threads, or when a positive reply should move toward a meeting. It does not start new conversations with people who have not been contacted (the outreach skill does) or build automated reply handling (the workflows skill does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Inbox Replies
 

package/agent-plugin/skills/instagram-posts/SKILL.md

@@ -3,7 +3,7 @@ name: instagram-posts
 description: "Write and revise Instagram captions, carousel outlines, and Reels scripts: the first 125 characters, line breaks, 3 to 8 hashtags, and a comment, save, or link-in-bio close. Use it for the copy of any post going to Instagram. It does not cover scheduling, publishing or automations (social does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Instagram posts
 

package/agent-plugin/skills/knowledge/SKILL.md

@@ -3,7 +3,7 @@ name: knowledge
 description: "Read and update what the workspace knows, across the knowledge digest, the workspace wiki, cited claims, and conflict-aware revisions."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Knowledge
 

package/agent-plugin/skills/linkedin-posts/SKILL.md

@@ -3,7 +3,7 @@ name: linkedin-posts
 description: "Write and revise LinkedIn posts that earn the click and the reply: the 210 character hook, structure and formatting, length by post type (story, list, case study, belief disruption, short, paragraph), specificity, the CTA close, and phrases to avoid. Use it for the copy of any post going to LinkedIn. It does not cover scheduling, publishing or automations (social does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # LinkedIn posts
 

package/agent-plugin/skills/linkedin-warm-signals/SKILL.md

@@ -3,7 +3,7 @@ name: linkedin-warm-signals
 description: "Warm people come from worksheet sources such as post engagers, followers, profile viewers and website visits. Judge worksheet rows against Required criteria, then build a capped warm sequence while protecting sender account. Use when user wants leads from LinkedIn presence or network-first motion. Does not cover cold lists from search (list-building does), writing posts (social does) or replying in existing threads (inbox-replies does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # LinkedIn Warm Signals
 
@@ -31,9 +31,10 @@ Signals land in a workbook worksheet as a row source, with criterion columns mar
    - Engagers on the account's own posts: highest intent, reference the post.
    - Profile viewers and new followers: warm but softer; lead with relevance.
    - Engagers on a competitor or peer post: public research, on its own worksheet.
+   - Product users from a PostHog cohort, or trial and recently active Stripe customers: the warmest signal of all, because they already use the product. Build them with `source.posthog_cohort` or `source.stripe_customers` (list-building skill) and name the product action, never the tracking.
    - Sort pasted LinkedIn URLs first: person profiles (/in/) and company pages (/company/) are different sources. Build one source per kind on its own worksheet and say which went where.
 3. **Build the worksheet** (list-building skill). One signal source per worksheet. Columns: the signal (which post, what they said), a column.ai_fit_score column against the ICP with the supporting quote as a Required criterion column (column.ai_fit_score is the way to score fit, ICP, or lead qualification, and it is the cheaper option; do not add a generic AI column for that score), then contact data gated on the Required criteria.
-4. **Run a sample and read the rows.** Exclude the author's team, existing customers and open conversations with a Required criterion column and run conditions, not by hand.
+4. **Run a sample and read the rows.** Exclude the author's team, existing customers and open conversations with a Required criterion column and run conditions, not by hand. Decide "existing customer" with a `provider.stripe.customer_lookup` column on the email or company domain, not by name.
 5. **Draft the warm sequence** (outreach skill). The first LinkedIn message names the real signal in one line, adds one relevant point, and asks a light question. Three steps or fewer; warm people do not need a long cadence.
 6. **Show and start.** Show the final copy of each step, audience count, sender and expected pace in days, then enroll and start.
 7. **Recurring, if asked.** A workflow adds new signal rows on a schedule and enrolls those that pass every Required criterion.

package/agent-plugin/skills/list-building/SKILL.md

@@ -3,7 +3,7 @@ name: list-building
 description: "Build a workbook of companies or people: as few sources as possible, people at companies through the employees enrichment fanned out to a second worksheet, one column per criterion marked Required or Nice to have, run conditions that skip rows already failing, an optional score, sample then scale, and honest coverage."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Workbook building
 
@@ -35,7 +35,19 @@ When asking for a blueprint recommendation, pass `required_filters` for every us
 
 For people engaging with competitor company posts, `signal-engaged-company-posts` exact match. Prefer it. It sets `max_posts_per_company=2`, `max_engagers_per_post=25`, `sample_size=25`, then excludes employees of selected companies in first paid qualification. Attach the company engager source directly only when a custom workbook is needed: send `company_urls` as literal string array, keep same caps, add employee-exclusion qualification before outreach.
 
-For incoming messages or booked meetings, read [Incoming people sources](incoming-people.md). Use `signal-received-dm` for Received DM plus AI fit score, or `signal-meeting-booked` for Meeting booked plus profile enrichment. Each installs exactly one people worksheet and two columns. Qualification follows the user's rubric, which may describe sales pitches, support requests, or another purpose. These sources do not require the general prospecting enrichment and email chain below.
+For incoming messages or booked meetings, read Incoming people sources (`incoming-people.md`). Use `signal-received-dm` for Received DM plus AI fit score, or `signal-meeting-booked` for Meeting booked plus profile enrichment. Each installs exactly one people worksheet and two columns. Qualification follows the user's rubric, which may describe sales pitches, support requests, or another purpose. These sources do not require the general prospecting enrichment and email chain below.
+
+## Customer and product sources (Stripe, PostHog)
+
+Your own customers and product users are lists too. Use them when the request is about expansion, upsell, win-back, product-qualified leads, or keeping customers out of a cold list.
+
+- **Stripe customers.** `source.stripe_customers` lands one person row per Stripe customer from the workspace's Stripe copy, keyed by `stripe_customer_id`. Its filters are `statuses` (`active`, `trialing`, `past_due`, `canceled`, `unpaid`), `price_ids`, `plan_names`, `created_after`, `created_before`, `min_mrr` and `max_rows`; put every billing criterion there, not in a later column. Outputs include plan, subscription status, monthly MRR, lifetime value, first paid date, trial end and delinquent. Use it for expansion lists (active on a lower plan, MRR above a floor), trial conversion (trialing, trial ending soon) and win-back (canceled).
+- **Stripe lookup column.** `provider.stripe.customer_lookup` answers "is this row already a customer" from an email or company domain column, with `is_customer`, plan, status, MRR, lifetime value, first paid and canceled dates. Add it to any cold list as an exclusion: a free column whose run condition is that the email or domain is set, then make `is_customer` `neq` true a Required criterion on the first paid column and on enrollment. A free-mail domain never matches a company.
+- **PostHog cohort.** `source.posthog_cohort` lands the people in one PostHog cohort, keyed by `distinct_id`, with `signal_source_id`, `cohort_id` and `max_rows`. List the project's cohorts with `integrations.posthog.cohorts_list` and pick by name; never guess a cohort id. Use it for product-qualified lists when the cohort already states the behaviour the user means.
+- **PostHog lookup column.** `provider.posthog.person_lookup` adds last seen, 30 day event count, top events, plan and properties to rows that have an email or company domain. Use its values in run conditions and in the fit score rubric as usage evidence (active in the last 7 days, used a named feature). For a one-off question about product data that no column answers, `integrations.posthog.query_run` reads it without changing the worksheet.
+- Both sources are monitor sources: after the first landing, new Stripe or PostHog events for a person update that person's row in place, and its Stripe and PostHog lookup cells refresh. Paid columns on the row still follow their own run conditions.
+- Money: MRR and lifetime value are in major units and monthly. When a customer or domain pays in more than one currency, MRR and lifetime value are empty, currency reads `mixed`, and `revenue_by_currency_json` holds the totals per currency. Treat `mixed` as unsure, never as zero.
+- A Stripe or PostHog source or column needs that account connected in the integrations pack. A missing connection blocks running, never building.
 
 ## Free preview before build, complete chain before paid sample
 

package/agent-plugin/skills/list-building/column-authoring.md

@@ -33,6 +33,8 @@ LAST({{company_linkedin_url}}, '/')
 
 Read its current state before changing it, so an edit never overwrites a newer change.
 
+The same fence applies to the worksheet source: read `tables.table_sources.list`, then use `tables.executables.save` with a source target and the returned state and binding revision. Put the intended authored change in `binding_spec`; never construct a compiled binding or digest. Omitted policy remains intact, including event triggers. A valid demand policy may be saved before a provider account is connected, and a one-off source run never needs a policy change.
+
 ## Research columns
 
 Create research with `binding_spec`, not `prompt`: `definition_id: "column.research"`, only `input_bindings.query`, and query `{ "kind": "template", "parts": [{ "kind": "literal", "value": "What recent news matters for " }, { "kind": "column", "column_key": "company" }, { "kind": "literal", "value": "?" }] }`. Research output is fixed `{status, answer, evidence}`. Do not declare `output`.

package/agent-plugin/skills/list-building/incoming-people.md

@@ -2,7 +2,7 @@
 
 ## Choose the focused workbook
 
-- `signal-received-dm`: one Received DMs people worksheet, one `source.dm_received` source column, and one `column.ai_fit_score` column. Ask for the receiving account, qualification rubric, and minimum score only when they are not already known. The rubric is editable natural language. A high score means the message matches those criteria; it need not mean buying intent or ideal customer fit.
+- `signal-received-dm`: one Received DMs people worksheet, one `source.dm_received` source column, and one `column.ai_fit_score` column. Ask which receiving accounts (one or more), qualification rubric, and minimum score only when they are not already known. `account_ids` accepts one or more receiving accounts. Event sources add every matching event, so `run_policy.exclude` and `limit_results` do not apply. The rubric is editable natural language. A high score means the message matches those criteria; it need not mean buying intent or ideal customer fit.
 - `signal-meeting-booked`: one Booked meetings people worksheet, one `source.meeting_booked` source column, and one `provider.enrich.linkedin.profile` column. Configure provider, connection, selected or all accessible event types, then optional per-event identity question mappings. Profile enrichment reads the current row's scalar `linkedin_url` and skips a missing or invalid URL.
 
 Install with empty answers when configuration is not available. Installation creates concrete source core outputs with disabled listeners and disabled paid columns, calls no provider, and spends nothing. Read the installed source and column receipts to identify what remains to configure. Source listening and downstream paid auto-update are separate settings; use the paid-run consent rule when enabling paid work.

package/agent-plugin/skills/list-building/sourcing.md

@@ -12,6 +12,13 @@
 - To continue a list, run the same source again. Changing its inputs starts it over.
 - Enrich rows you already have; never add a second source for them. Fan out only when an enrichment returns a nested list per row and the user wants those items as rows.
 
+## Changing a source
+
+- Read `tables.table_sources.list` first. Use the returned source id, state, binding revision and binding as the current state; never reconstruct a compiled binding or its digest.
+- Author a source change with `tables.executables.save`: set target kind to `source`, copy the returned source id, state and binding revision into its target fence, and express only the intended change in `binding_spec`. The save path compiles the binding and preserves omitted existing source policy.
+- Preserve an existing event trigger and its other policy unless the user explicitly wants to change it. A source can have valid demand policy before its provider account is connected; save that draft, connect when the run says it is needed.
+- An explicit `tables.table_sources.run` does not require a policy edit. Run the current source when the user wants rows now; change its policy only when the future behavior should change.
+
 ## Social account posts and AI answers
 
 - For competitor or creator content analysis, use `source.account_posts_<platform>` with pasted account links. On an existing account URL column, use `column.account_posts_<platform>`, then Fan out for one row per post.

package/agent-plugin/skills/outreach/SKILL.md

@@ -3,7 +3,7 @@ name: outreach
 description: "Build a multi-channel sequence and enroll a workbook into it: preview one real message first, fixed scaffold with small personalized slots, channel steps with the wait inside each step, column filters decide who enrolls, paced sends."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Sequence building
 
@@ -27,7 +27,7 @@ When user says delete, delete permanently. Show impact first unless user already
 
 - Build a new sequence for each request. "Enroll in a sequence" means a new one. Use or edit an existing sequence only when the user names it or asks to change it; never ask the user to pick an existing sequence.
 - Read the ideal customer profile, the product and offer pages, and the message writing notes before asking anything. The value proposition comes from those pages; ask for it only when none of them states it. Ask one question only when a required fact is missing, then build.
-- Before writing any sequence copy, load the knowledge skill and read saved Company Context pages that govern it: Product Information and Offer for claims, Ideal Customer for audience fit, and Tone of Voice for register. Name pages used. Pass returned document ids as `context_document_ids` and returned revision ids as `context_revision_ids` on the create-from-worksheet call, so the draft receipt proves exact context lineage. Never reuse another workspace's product copy. If Company Context has no applicable page, say so and ask for the missing fact before writing prose.
+- Before writing any sequence copy, load the knowledge skill and read saved Company Context pages that govern it: Product Information and Offer for claims, Ideal Customer for audience fit, and Tone of Voice for register. Name pages used. Pass returned document ids as `context_document_ids` and returned revision ids as `context_revision_ids` on the create-from-worksheet or blueprint-install call, then read the saved definition to verify those exact ids, so the draft proves context lineage. Never reuse another workspace's product copy. If Company Context has no applicable page, say so and ask for the missing fact before writing prose.
 - The kind of sequence is a required fact. Unless the request already says it, read selected saved view's structural channel reachability, then ask once, in one question, which reachable channel and goal (a reply, a meeting, a demo). Offer only channels with reachable rows and recommend channel most rows support.
 - Use only channels the rows can be reached on. A channel step needs the field it sends to; when that field is missing, find it first with an enrichment.
 
@@ -67,10 +67,17 @@ When the user asks to enroll a list:
 - Keep filters, identity mapping, cap, and priority inside each audience. Never apply one global filter or sort across several workbooks. Use a workflow source only when entry needs logic a workbook audience cannot express.
 - When several people from one company are enrolled, turn on company pause on reply.
 
+## Workbook rows before CRM
+
+- A worksheet row with usable channel identity and copy fields is enough to render real personalized previews and rehearse sequence launch. Do this before, and without, a separate CRM-person creation step.
+- Live sequence enrollment owns identity materialization: it matches a row to one existing person or creates and binds the missing person while staging the enrollment. That staging does not send.
+- Treat a pending identity binding in a preview as planned enrollment work, not a request for the user to create contacts. Report only the actual result: missing usable identity, an identity conflict, a permission refusal, or another returned readiness blocker.
+- Creating records for otherwise unbound rows remains a deliberate CRM hygiene or import operation. It is not outreach preparation and must not be offered as a prerequisite for a workbook preview, rehearsal, or enrollment.
+
 ## State
 
 - Building never waits on connections or rows. Build, preview, validate and bind anyway, then say what to connect or what will make rows land.
-- Publishing and enrolling never send. After enrolling, leave the sequence published and never started unless the user explicitly says start; that is paused. Staged contacts on an unstarted sequence are success. `max_live_sends` is a param of the external-send sequence capabilities (activating an audience, resuming a sequence, and the rest of that family), sent inside `params`, not a gating input of `tools_run`. Sending follows the paid-run consent rule.
+- Publishing and enrolling never send. After enrolling, publish if readiness passes and leave it unstarted unless the user explicitly says start. An unstarted published sequence is distinct from a manual pause. Staged contacts on an unstarted sequence are success. `max_live_sends` is a param of the external-send sequence capabilities (activating an audience, resuming a sequence, and the rest of that family), sent inside `params`, not a gating input of `tools_run`. Sending follows the paid-run consent rule.
 - Drafted, validated, published, enrolled, started, delivered and replied are separate facts; report only what the last result proves. After an unknown outcome, read state before retrying, and never enroll or send twice.
 
 ## Done

package/agent-plugin/skills/outreach/enrollment.md

@@ -2,11 +2,13 @@
 
 Default for "enroll this list in a sequence": `sequence.sequences.create_from_worksheet`.
 
-Order of work: preview one real personalized message in chat, dry run, then build the sequence with the worksheet bound as its audience. Building from the worksheet already validates, binds the trigger and stages the rows, so never enroll the same rows again after it. Then publish. Start only when the user explicitly says start.
+Order of work: preview one real personalized message in chat, dry run, then build the sequence with the worksheet bound as its audience. Building from the worksheet already validates, binds the trigger and stages the rows, so never enroll the same rows again after it. Publish when the returned readiness checks pass. Start only when the user explicitly says start.
 
-When the user asked to enroll, do not stop at the draft: publishing is part of enrolling and sends nothing, so build from the worksheet and publish in the same turn, then report that nothing was sent. A published sequence that was never started sends nothing; that is the paused state the user asked for.
+When the user asked to enroll, build and stage the requested audience, then publish when readiness passes. A disconnected sender or missing copy evidence can leave a useful draft with an exact repair; report that state honestly. A published sequence that was never started sends nothing. Published-but-unstarted and manually paused are distinct states.
 
-Enrollment reads leads straight from the worksheet rows; do not create or import contacts first. A sequence takes one enrollment source: a workbook view, or one workflow, never both. A published sequence bound to a view keeps enrolling rows that later land in or start matching it. Filters on any worksheet column narrow who enrolls; with no filter every row enrolls. When the user said who should get the sequence, filter on the columns that hold it and report how many were held back. Enrollment is free and never sends. Starting is the moment real messages begin, paced over time.
+Enrollment reads leads straight from the worksheet rows; do not create or import contacts first. A rendered preview and a launch rehearsal use those row values even when no CRM person exists yet. On live enrollment, the system matches each usable row identity to one existing person or creates and binds the missing person automatically. A sequence can have ordered worksheet audiences, each with its own saved view, filter, identity mapping, priority and cap, or a workflow source. Keep personalization provenance on its selected source; do not silently substitute another audience when a source is archived. A published sequence bound to a view keeps enrolling rows that later land in or start matching it. Filters on any worksheet column narrow who enrolls; with no filter every row enrolls. When the user said who should get the sequence, filter on the columns that hold it and report how many were held back. Enrollment is free and never sends. Starting is the moment real messages begin, paced over time.
+
+Do not turn a pending binding preview into a request to create CRM contacts. Report the returned blocker precisely: a row without usable channel identity, an ambiguous/conflicting identity, a permission refusal, or the named launch/readiness issue. The CRM-only operation that creates records for unbound rows remains available for intentional CRM cleanup or import, never as an outreach prerequisite.
 
 Social account post and AI answer worksheets hold content rows, never an audience or subject. To reach authors, send unique author URLs to a people worksheet first.
 
@@ -14,6 +16,10 @@ Enrolling from a worksheet binds it as the sequence's trigger. Report the trigge
 
 "Enroll in a sequence" means the people worksheet of the workbook the user is looking at, or just built, into a new sequence built for it, even when a company worksheet is open. Use an existing sequence only when the user names it; never report another worksheet's enrollment as the answer.
 
-Publishing and enrolling can happen before any sender is connected. Only starting delivery needs a connected account, and then name exactly which one. Show a preview of real rows in chat as you build; it is not an approval gate. When the user asked to enroll, build and publish in the same turn and let them edit the copy after. Stop for review only when the user asked to approve copy first. There is no send cap to pass: every enrolled lead is worked through, paced by each account's daily limits and sending hours.
+Draft creation and staging can happen with an empty qualified view or disconnected sender. Keep the saved view and filters unchanged; never widen the audience to make a count nonzero. Use top-level `identity_mapping` in `sequence.sequences.create_from_worksheet`, for example `{linkedin_url_column_key:"person.linkedin_url"}`; the service saves it on the audience source. Keys name worksheet columns or declared nested outputs. Do not pass the removed `linkedin_profile_column_id` override.
+
+For an identity failure, inspect the current strict input schema and submit the exact returned identity_mapping repair on that audience without changing its worksheet, saved view or filter. Read back the saved mapping and render the intended recipient before reporting the repair complete.
+
+Publishing and starting enforce their returned readiness checks; connect the named channel sender or repair the exact missing evidence. Publishing and enrolling never send. Show previews of rich, thin and missing-evidence rows as you build, labeling fallback copy or a hold explicitly. If a row sample is incomplete, report its sample size instead of calling it the full audience. Preserve configured sequence, audience and sender limits. Start only on the user's explicit instruction and the canonical paid-run consent rule.
 
 After a timeout or an unclear result, read the current enrollment and run state before trying again. Never enroll the same leads twice and never start a second copy of the same sequence.

package/agent-plugin/skills/outreach/message-copy.md

@@ -4,9 +4,11 @@ Preview first. Draft one full message for one real qualified prospect, subject l
 
 Keep the scaffold fixed: greeting, the pitch paragraphs, the call to action, the sign-off and every paragraph break are the same for every lead. The personalized parts are short slots, such as first name, company, niche, target persona or one signal you can point to in the prospect's data.
 
-Ground every personalized claim in the prospect's row or the workspace knowledge. If the data is empty, use the fallback wording, never a guess. Use only variables the workspace offers. An unresolved variable in a preview means the copy is not ready.
+Read the current Company Context before writing. Pass its document ids and revision ids unchanged in the creation contract so the saved definition records the claims' provenance. Ground every personalized claim in the prospect's row or that workspace knowledge. If the data is empty, use the fallback wording, never a guess. Use only variables the workspace offers, including declared nested outputs such as `{{research.summary}}`, formula/lookup projections and sender fields. A column label is not a token key. An unresolved variable in a preview means the copy is not ready.
 
-For each sending step, decide row variables first. Write fallback message before personalized message, for any empty row value. Put it in that step's `fallback_template` field; it is not its own step and not a branch. Fallback must not use row variables that can be empty, sender variables always present are allowed. Never publish a sending step with row variables and no fallback. Before publishing, render every step for at least three real rows, including one row with an empty value.
+For large personalization reads, request referenced columns plus identity and filter dependencies, page within the returned row and cell limits, and continue until complete. A display limit or partial sample is not the full audience. Report completeness; never drop dependencies to fit a request.
+
+For each sending step, decide row variables first. Write fallback message before personalized message, for any empty row value. Put it in that step's `fallback_template` field; it is not its own step and not a branch. Fallback is literal copy without template variables, including sender variables. It must not claim an observed signal, previous contact or promised resource when that evidence is absent. Never publish a sending step with row variables and no fallback. Before publishing, render every step for at least three real rows, including one row with an empty value.
 
 Merge fields are the enrolled worksheet's columns. Before copy greets someone by first name, check that the worksheet has a first name column. If it does not, add a visible `first_name` formula column with `FIRST_NAME({{name}})` through `tables.columns.add` (it runs no paid work), then write `{{first_name}}`. Derive any other short slot the copy needs the same way, as a visible formula column, before drafting.
 
@@ -38,4 +40,4 @@ If the rendered messages across rows read nearly identical apart from the name,
 
 ## A/B testing
 
-When a step writes with AI, it can test variants: vary either the angle (the overall approach) or the opener (only the first line), not both, and keep each variant a genuinely different idea rather than a paraphrase. Turn on automatic winner promotion when the user wants the sequence to keep the better variant on its own. Read the results per variant before changing copy, and change the losing variant, not the whole sequence.
+When a step writes with AI, it can test variants: vary either the angle (the overall approach) or the opener (only the first line), not both, and keep each variant a genuinely different idea rather than a paraphrase. Keep assignment stable for a logical execution across retries. Use the existing variant report; do not promise automatic winner promotion or rebucket recipients after a retry. Separate human replies, positive replies and confirmed meetings, with explicit denominators and read completeness. An automatic response or OOO pause is not a human reply. Read the results per variant before changing copy, and change the losing variant, not the whole sequence.

package/agent-plugin/skills/plays/SKILL.md

@@ -3,7 +3,7 @@ name: plays
 description: "Recommend and run one named, proven go-to-market play when the user asks what to do next, picking by stage and what the workspace already has, and stating prerequisites, credit estimate and checkpoints before starting. Use it for \"what should I do\", \"how do I get leads\", \"help me start outbound or content\", or a weekly review. It does not replace the skills each step uses (knowledge, list-building, outreach, social, writing, visibility, workflows)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Plays
 
@@ -46,6 +46,21 @@ A play has no pack of its own. It routes across packs: `knowledge` for Company C
 - Each morning: the top five to ten with what they did, when, and an honest first line built on a true fact.
 - Metric: warm people contacted from the list, replies they produce.
 
+**People engaging with a prospect's competitors** (competitor-engager-prospecting). Find people already paying attention to competitors, then contact only people who fit target buyer.
+- State caps and credit estimate before any paid run. Pilot five targets first. Get review of competitor LinkedIn URLs before spend.
+- Build or reuse one target worksheet from any source. Add fit score against target buyer and run later work only where score is 70 or higher.
+- Add an AI or web-research column returning no more than five competitor LinkedIn URLs per target. Review returned URLs before spend.
+- Add Run worksheet column. For each reviewed competitor URL, run post engagers in profile mode once. Child worksheet receives engagers, excludes competitor employees and client's existing customers, then scores fit against target buyer.
+- Return top ten child rows, total count, and share link to parent row. Share link lasts 30 days and can be revoked.
+- Sequence step one states count only, with no link. Sequence step two sends share link. Before reply, teaser may name person, title, company, and what person engaged with. Never include email or phone.
+- Metric: qualified competitor engagers per target, then replies from sequence.
+
+## Choosing one result, a split, or child worksheet
+
+- Use a function when each parent row needs one value, such as one score, verdict, URL, or count.
+- Use fan out for one-off split where returned items become ordinary rows and no parent-scoped result must return.
+- Use Run worksheet when each parent must produce bounded child rows, run a child qualification chain, then return ranked rows, count, or share link. Child identity stays scoped to parent, so same person may appear under different targets.
+
 **What should I post?** (founder-posting-system). Regular LinkedIn posts in the user's own voice.
 - Learn the voice from the account's past posts; posts that drew comments are the best examples.
 - Draft a few posts or plan a week of different kinds (customer story, contrarian take, build in public), each with one concrete point, who it is for, and a call to action.

package/agent-plugin/skills/reddit-posts/SKILL.md

@@ -3,7 +3,7 @@ name: reddit-posts
 description: "Draft Reddit posts the user posts themselves: subreddit choice and rules, the title, a value first body, disclosure, post types (success story, guide, resource list, problem solving, behind the scenes, question), and what gets posts removed. Use it for the copy of any Reddit draft. It does not cover scheduling or automations (social does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Reddit posts
 

package/agent-plugin/skills/skill-authoring/SKILL.md

@@ -3,7 +3,7 @@ name: skill-authoring
 description: "Read, edit and create this workspace's skills, the editable Markdown playbooks agents and people follow, keeping each one short, revision safe and in the workspace's own words. Use it when the user wants to change how a skill works, capture a repeatable practice as a new skill, or fix a skill that reports issues. It does not change what an agent is allowed to do (a skill grants nothing) and does not edit Company Context pages (knowledge does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Skill Authoring
 

package/agent-plugin/skills/social/SKILL.md

@@ -3,7 +3,7 @@ name: social
 description: "Own a short-form social post for its whole life across connected channels. Read the channel registry and learned brand voice, draft and revise, submit for review, approve, schedule or reschedule, publish now, unschedule, and archive."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Social
 
@@ -18,7 +18,7 @@ The `social` pack lists the tools and their exact inputs.
 
 ## Published-post scoring
 
-For published-post review, read `visibility.analytics.post_score_get` for one post or `visibility.analytics.post_scores_list` for a date range. Scores compare each author account with its own same-platform recent baseline at 24h and 7d. A `not_enough_history` label means fewer than three prior posts, not poor performance. These reads use stored snapshots and never refresh a provider.
+For published-post review, find the published-post score read for one post or the published-post score list for a date range. Scores compare each author account with its own same-platform recent baseline at 24h and 7d. A `not_enough_history` label means fewer than three prior posts, not poor performance. These reads use stored snapshots and never refresh a provider.
 
 ## Delete and archive
 
@@ -38,6 +38,8 @@ Write with the channel skills: `linkedin-posts`, `x-posts` and `reddit-posts` ho
 
 Each request gets a new draft. Revise an existing draft only when the user names it or asks to change it.
 
+When a post you changed comes back different, read its version history before explaining it. Each version names its writer: `agent_edit` with the surface (MCP, CLI, Architect) or `manual_edit` from the dashboard. Report what the history shows. Never tell the user to refresh, close or reload tabs as the fix: an open editor reports a conflict instead of overwriting newer copy.
+
 Drafting needs no review, approval or human step. Match the stored voice. No em dashes in post copy.
 
 Before scheduling, resolve every @mention for each channel. People and companies can be mentioned on LinkedIn and X. Never send unresolved mention text to a provider. It publishes broken public text and cannot be edited back on every channel.
@@ -50,7 +52,7 @@ For LinkedIn, the last line must open with an ask verb or be a question addresse
 
 Per-post auto-engagement lets the workspace's connected accounts like, comment or repost after the post publishes. When the user asks for it ("add all our accounts as auto engagers"), do it: list the connected accounts, bind every account they named (or all of them), pick sensible defaults and save. Defaults: likes from every account; one comment per account, written by you in that account's voice, specific to the post and different for each account, never generic praise; stagger each account a few minutes apart instead of all at once. The post's own author does not like or comment on its own post. Report the accounts, actions, delays and exact comment copy you saved, so the user can change any of it.
 
-Keyword auto-DM rules attach to a post. A comment containing the keyword gets a DM to the commenter and can get a public reply. Write the DM and reply copy yourself from the post and the offer; keep the DM short and deliver what the post promised.
+Keyword auto-DM (comment-to-DM) rules attach to a post. Discover the rule read and replacement capabilities through the social pack, then read the current rules and replace them directly; there is no separate follow-up tool. The editor's "private follow-up" switch is `dm_enabled` with `dm_message`. On LinkedIn the DM reaches only 1st-degree connections: with the DM on, a connection gets the DM (and `comment_reply_sent` after it, when enabled) and anyone else gets `comment_reply_not_connected`, when enabled. With the DM off, every matching commenter gets `comment_reply_sent` when it is enabled, and the not-connected reply is not used. A rule that reaches nobody is refused. Make the post's CTA promise what the rule delivers: "I'll DM you" only with the DM on. Write the DM and reply copy yourself from the post and the offer; keep the DM short and deliver what the post promised. Report the keywords and what a connected and a not-connected commenter will each receive.
 
 Amplification is a standing workspace policy that engages from other people's real accounts and spends credits. Create it disabled, and arm it separately after scope, participant accounts, actions and credit ceiling are set.
 

package/agent-plugin/skills/tiktok-posts/SKILL.md

@@ -3,7 +3,7 @@ name: tiktok-posts
 description: "Write and revise TikTok video scripts and captions: the first two seconds, on-screen text, a caption up to 2,200 characters, and 3 to 5 hashtags. Use it for the copy of any post going to TikTok. It does not cover scheduling, publishing or automations (social does)."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # TikTok posts
 

package/agent-plugin/skills/visibility/SKILL.md

@@ -3,7 +3,7 @@ name: visibility
 description: "Get found by search engines and answer engines. Pick the query set, gather crawl, index, mention and citation evidence, fix pages, then measure the change."
 ---
 
-Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, a live external send above the server's recipient threshold, or a run that turns on a recurring trigger, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run`. Anything that writes, spends credits or reaches a person: dry_run first, then live with the quote_hash the dry_run returned, a max_credits ceiling and an idempotency_key. max_credits 0 is valid only when that quote is 0. A larger paid run, or a live external send above the server's recipient threshold, also needs approved: true with the same quote_hash, after reviewing the preview. Free formulas need no paid-run approval; row execution caps still apply. `max_rows` is a param of `tables.columns.run` and `tables.table_sources.run`, not of `tools_run`. `max_live_sends` goes inside `params` only when the fetched capability schema declares it (for example, a one-contact workflow run). Sequence start, resume, launch and enrollment do not accept it; they have no lifetime send ceiling. The paid-run consent rule is one sentence in the MCP server instructions, rendered from consentRule.json and PAID_RUN_APPROVAL_THRESHOLDS: rows and credits, with no provider prices. If the server asks you to sign in, approve it in the browser.
 
 # Visibility