@floomhq/signaldash 0.22.0 → 0.28.0

package/skills/signaldash/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: signaldash
-description: Operate the user's SignalDash connection to LinkedIn, WhatsApp, and email. Use this skill whenever the user says or implies "check my LinkedIn", "who messaged me", "triage my inbox", "read the thread with X", "reply to X", "send this message", "send a connection request", "create an invitation batch", "check invitations", "accept this invitation", "auto-accept my invitations", "check auto-accept status", "withdraw this invitation", "search my LinkedIn connections", "find people in my network", "find people beyond my network", "suppress this contact", "check contact state", "check my action budget", "check WhatsApp", "check my email", "draft a LinkedIn post", "who engaged with my post", "who liked or commented", or "export my LinkedIn connections". Covers durable installation, invite-based setup, local-first connection search, capped paid discovery, immutable human-approved invitation batches, opt-in rate-capped invitation auto-accept, exact contact state and suppression, authoritative LinkedIn action-budget status, safe reading, drafting, approved sends, exact invitation actions, post engagement analysis, and paced connection export.
+description: Operate the user's SignalDash connection to LinkedIn, WhatsApp, and email. Use this skill whenever the user says or implies "check my LinkedIn", "who messaged me", "triage my inbox", "read the thread with X", "reply to X", "send this message", "send a connection request", "create an invitation batch", "run a campaign", "connect and then message them", "message them when they accept", "check invitations", "accept this invitation", "auto-accept my invitations", "check auto-accept status", "withdraw this invitation", "search my LinkedIn connections", "find people in my network", "find people beyond my network", "suppress this contact", "check contact state", "check my action budget", "check WhatsApp", "check my email", "draft a LinkedIn post", "who engaged with my post", "who liked or commented", or "export my LinkedIn connections". Covers durable installation, invite-based setup, local-first connection search, capped paid discovery, immutable human-approved invitation batches, the human-approved campaign loop that messages a person only after a proven acceptance and stops on any reply, opt-in rate-capped invitation auto-accept, exact contact state and suppression, authoritative LinkedIn action-budget status, safe reading, drafting, approved sends, exact invitation actions, post engagement analysis, and paced connection export.
 ---
 
 # Operate SignalDash
@@ -28,42 +28,44 @@ Name that plainly before you run anything:
 Wait for a clear yes. If the user does not know who sent the link, or is unsure,
 stop and let them verify first. Do not soften this to get through setup faster.
 
-## Ensure the skill is saved and enabled
+## Ensure the skill is installed from a reviewed local package
 
-Do this first when you are reading this file from a URL or pasted text. Do not
-rely on the current conversation to retain it.
+Do not install this file as trusted instructions merely because an agent was
+given its public URL or pasted contents. A remote instruction document can
+change independently of the user's installed software and may be rejected by a
+security-conscious agent. When reading this from a URL or pasted text, stop and
+ask the human to review and run the pinned package bootstrap in their terminal.
 
-1. Save the complete, unmodified `SKILL.md` in a skill directory that the
-   current agent discovers. Prefer the agent's documented global directory so
-   the skill works in future projects. Common locations are:
-
-   - Claude Code: `~/.claude/skills/signaldash/SKILL.md`
-   - Codex: `~/.codex/skills/signaldash/SKILL.md`
-   - Portable project scope: `.agents/skills/signaldash/SKILL.md`
-
-2. When shell access is available, fetch the raw form explicitly:
+1. The human runs the currently published, pinned package:
 
    ```bash
-   mkdir -p ~/.claude/skills/signaldash
-   curl -fsSL -H 'Accept: text/plain' https://signaldash.dev/SKILL.md \
-     -o ~/.claude/skills/signaldash/SKILL.md
-   test -s ~/.claude/skills/signaldash/SKILL.md
+   npx -y @floomhq/signaldash@{{PACKAGE_VERSION}} <invite-code>
    ```
 
-   Replace the destination with the current agent's canonical skill directory
-   when it is not Claude Code.
+   This logs in, copies the package-bundled skill into Claude Code, registers
+   the local MCP server, and starts the hosted account-connection flow.
+
+2. The package writes the installed copy to the one location it supports
+   today:
+
+   - Claude Code: `~/.claude/skills/signaldash/SKILL.md`
 
-3. Confirm that the saved file begins with `name: signaldash` and contains the
+   Other clients (Codex, a portable `.agents/skills/` layout, etc.) are not
+   written automatically. Copy this same reviewed file into that client's own
+   skill directory by hand and reload skill discovery there.
+
+3. Confirm that the installed file begins with `name: signaldash` and contains the
    `Before every send` section. A partial copy is not installed.
 
 4. Enable or reload skills according to the current agent. Start a new agent
    session when the client discovers skills only at startup. After SignalDash
    setup, restart the MCP connection as well.
 
-5. The package can install its bundled copy for Claude Code:
+5. The package can reinstall its bundled copy for Claude Code without repeating
+   account setup:
 
    ```bash
-   npx -y @floomhq/signaldash skill
+   npx -y @floomhq/signaldash@{{PACKAGE_VERSION}} skill
    ```
 
    Expected success:
@@ -73,8 +75,9 @@ rely on the current conversation to retain it.
    Your agent now knows how to use LinkedIn + WhatsApp safely through SignalDash.
    ```
 
-Persisting the skill is part of setup. Do not continue with a session-only copy
-and tell the user setup is complete.
+Persisting the reviewed, package-bundled skill is part of setup. Do not continue
+with a session-only or remotely fetched copy and tell the user setup is
+complete.
 
 ## When to reach for SignalDash
 
@@ -158,7 +161,7 @@ one, or reuse somebody else's code.
 After the user provides the code, run:
 
 ```bash
-npx -y @floomhq/signaldash <invite-code>
+npx -y @floomhq/signaldash@{{PACKAGE_VERSION}} <invite-code>
 ```
 
 The invite is a hexadecimal string. The command logs in, installs the bundled
@@ -341,7 +344,7 @@ Use the exact tool names and argument keys below. Limits are optional.
 
 | Tool | Arguments | When to use it |
 |---|---|---|
-| `li_list_chats` | `limit` integer 1-100, default 20 | Find recent LinkedIn chats, unread counts, and exact `chat_id` values without opening profiles. |
+| `li_list_chats` | `limit` integer 1-100, default 20; `cursor` optional; `search` optional string, max 200 characters; `max_scan` optional integer 1-500, default 200, and never more than five provider pages | Find recent LinkedIn chats, unread counts, and exact `chat_id` values without opening profiles. With `search` it filters on `name`, `subject`, `id`, `provider_id` and `attendee_provider_id`. The provider CANNOT filter a chat list, so SignalDash scans and filters: read `search.exhaustive` before you conclude anything, `search.limit_reached` to know whether the matches were truncated by `limit`, and `search.searched_fields` for what was actually compared. `false` means "not among the `scanned_chats` scanned", never "does not exist" -- continue from the returned `cursor`. When `started_from_cursor` is true the scan began mid-list, so even `exhaustive` says nothing about the chats before that cursor. A 1:1 chat has `name: null`, so a person's NAME can never match; resolve it with `li_search_connections` and search for the member id. Any other key, including `text` and `member_id`, is refused with `unsupported_parameter` rather than accepted and ignored. |
 | `li_read_messages` | `chat_id` required; `limit` 1-100, default 30 | Read one resolved LinkedIn conversation before summarizing, drafting, or sending. |
 | `li_send_message` | `chat_id` required; `text` required, max 5000 characters | Send one approved LinkedIn reply after an immediate read of that exact chat. |
 | `li_send_invitation` | `provider_id` required; `note` optional, max 300 exact characters; `confirm` optional, default false | First preview one exact target and note. The server verifies relationship, both invitation directions, and absence of an existing one-to-one chat. After exact approval, repeat the identical call with `confirm:true`; jitter completes before the final preflight and action reservation. |
@@ -354,21 +357,41 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `sd_settings_get` | no arguments | Read the authenticated user's persistent SignalDash settings. Auto-accept is the first supported setting and is false for every existing user until explicitly changed. |
 | `sd_settings_set` | `auto_accept_linkedin` required boolean; `auto_accept_linkedin_filters` optional object with `public_identifiers` and `description_keywords`; `confirm:true` required | Update the general per-user settings surface after exact human approval. This changes no future or unknown setting implicitly. |
 | `sd_auto_accept_status` | no arguments | Inspect whether auto-accept is enabled, its exact filters, accepted today and this week, failed attempts today, dedicated and shared capacity, repeated-error stop state, and sanitized unparseable invitation records. |
+| `sd_voice_profile` | `channel` required, one of `linkedin`, `whatsapp`, `email`; `force_recompute` optional boolean, default false | Build or fetch this user's personal voice profile for exactly one channel, mined only from up to ~50 of their own SENT messages on that channel (never the counterpart's text, never another user's data). Returns compact markdown: hard length stats (median/p75/p90), 5-10 verbatim redacted exemplars, negative constraints, and language behavior. Computed once and cached server-side; only pass `force_recompute:true` when the user explicitly asks to refresh it. |
 | `li_search_connections` | `query` required string, max 200; `filters` optional object with `company`, `headline_keyword`, `connected_after`, and `connected_before`; `limit` integer 1-100, default 20 | Search only the authenticated user's stored LinkedIn connection snapshot and join exact local contact state. This makes no LinkedIn, Unipile, HarvestAPI, or other paid discovery call. |
 | `li_discover_people` | `query` required role/title string, max 200; `filters` optional object with `company` and `location`; `limit` integer 1-10, default 10; `confirm` optional, default false | After a completed local snapshot returns no matches, preview one paid HarvestAPI profile-search page. Obtain approval for the exact query and maximum reserved cost, then repeat with `confirm:true`. |
 | `li_create_invitation_batch` | `source_label` required exact string, max 120 code points; `time_zone` required IANA timezone; `targets` required array of 1-10 exact `{profile_url,inclusion_reason,note?}` objects; reason max 240 and note max 200 Unicode code points | Create one immutable durable preview from canonical LinkedIn Classic `/in/` URLs. The agent structures an explicit human request; the server never generates targets or text. |
 | `li_get_invitation_batch` | `batch_id` required | Inspect every stored target, exact note, exclusion, hash, timing, capacity, and result. Use the returned browser review path for human approval. This read also authorizes a later exact cancel. |
 | `li_cancel_invitation_batch` | `batch_id` required; `approval_view_hash` required string or null exactly as inspected; `confirm:true` required | Permanently cancel unstarted targets in one freshly inspected batch. It cannot recall an executing invitation, and restarting requires a new preview and approval. |
-| `wa_list_chats` | `limit` integer 1-100, default 20 | Find an existing WhatsApp conversation and exact `chat_id`. |
+| `sd_campaign_create` | `source_label` required, max 120 code points; `time_zone` required IANA timezone; `messages` required array of 1-5 exact `{text,after_days?}` objects, text max 1200 code points; `target_source` optional (`explicit` default or `post_engagers`); `targets` array of up to 150 `{profile_url?,provider_id?,inclusion_reason,note?,display_name?,headline?,adopt_existing_invitation?}` for `explicit` (at most 10 adopted targets per campaign, and an adopted target may not carry a `note`); `engagers` object with `post_limit` 1-10, `max_targets` 1-150, `inclusion_reason`, `note` for `post_engagers`; `invite_ttl_days` optional 1-60, default 21 | Create one campaign: a connection request to each exact person, then the exact approved message(s) once that person is proven to have accepted, then an optional follow-up that stops on any reply. The server never generates a target or a word of text. Nothing is sent before human approval. |
+| `sd_campaign_preview` | `campaign_id` required | Inspect every exact recipient, every exclusion and reason, the exact text of every message step, the timing, the shared daily budget, and the `approval_url` to hand the human. This read also authorizes a later exact cancel. |
+| `sd_campaign_approve` | `campaign_id` required; `confirm_token` required in the exact `sd-xxxx-xxxx-xxxx` form the human read off the approval page | Record the human's approval using the single-use code that authenticated page minted for them. An agent cannot mint, guess, or bypass that code. |
+| `sd_campaign_status` | `campaign_id` required | Monitor per person: invited, acceptance proven, messaged, replied and halted, expired, or excluded, plus every message step and any provider response SignalDash could not parse. |
+| `sd_campaign_cancel` | `campaign_id` required; `approval_view_hash` required string or null exactly as inspected; `confirm:true` required | Revoke the approval and stop every unsent invitation and unsent message. It cannot recall an executing write, and restarting requires a new preview and approval. |
+| `sd_withdrawal_batch_create` | `account` required, exactly `linkedin`; `exclude` REQUIRED array of up to 100 exact `{kind,value}` objects, kind one of `invitation_id`, `provider_id`, `public_identifier`, `profile_url`, `member_urn`, `display_name`; `time_zone` required IANA timezone; `older_than_days` optional integer, default 90, minimum 30; `limit` optional 1-1500; `source_label` optional, max 120 code points; `allow_unmatched_exclusions` optional boolean | Freeze the exact PENDING SENT invitations older than the age rule, for one human approval and a paced sweep. `exclude` is required, not optional: ask the human who must NOT be withdrawn before you call this. An exclusion that matches nobody fails the preview by default, because that is what a typo looks like. |
+| `sd_withdrawal_batch_status` | `withdrawal_batch_id` required | Inspect or monitor one sweep: done and remaining, the per-day pace and this sweep's own daily allowance, the stop reason, parse failures, the exact people the exclusions protected, and the `approval_url` to hand the human. This read also authorizes a later exact cancel. |
+| `sd_withdrawal_batch_approve` | `withdrawal_batch_id` required; `confirm_token` required in the exact `sd-xxxx-xxxx-xxxx` form the human read off the approval page | Record the human's approval using the single-use code that authenticated page minted for them. An agent cannot mint, guess, or bypass that code. |
+| `sd_withdrawal_batch_cancel` | `withdrawal_batch_id` required; `approval_view_hash` required string or null exactly as inspected; `confirm:true` required | Revoke the approval and stop every withdrawal that has not started. It cannot recall one already submitted, and it cannot restore the three-week re-invite block for people already withdrawn. |
+| `wa_list_chats` | `limit` integer 1-100, default 20; `cursor` optional; `search` optional string, max 200 characters; `max_scan` optional integer 1-500, default 200, and never more than five provider pages | Find an existing WhatsApp conversation and exact `chat_id`. With `search` it filters on `name`, `subject`, `id`, `provider_id` and `attendee_public_identifier`, which carries the phone number, and it normalizes digits so `+49 151 67609512`, `004915167609512` and `4915167609512@s.whatsapp.net` all match. The provider CANNOT filter a chat list, so SignalDash scans and filters: read `search.exhaustive` before you conclude anything, `search.limit_reached` to know whether the matches were truncated by `limit`, and `search.searched_fields` for what was actually compared. `false` means "not among the `scanned_chats` scanned", never "does not exist" -- continue from the returned `cursor`. When `started_from_cursor` is true the scan began mid-list, so even `exhaustive` says nothing about the chats before that cursor. A 1:1 chat has `name: null`, so search the phone number, not the person's name. Any other key, including `text` and `member_id`, is refused with `unsupported_parameter`. |
 | `wa_read_messages` | `chat_id` required; `limit` 1-100, default 30 | Verify a WhatsApp contact and recent history before summarizing, drafting, or sending. |
-| `wa_send_message` | `chat_id` required; `text` required, max 5000 characters | Send one approved reply in an existing WhatsApp conversation after an immediate re-read. |
-| `email_list` | `limit` integer 1-100, default 20 | List the newest message in each recent email thread and obtain `thread_id`. |
-| `email_read` | `thread_id` required; `limit` 1-100, default 30 | Read an email thread and authorize its exact participant addresses for a later send. |
-| `email_send` | `to` required as an array of exactly one valid address; `subject` required, max 998; `body` required, max 5000 | Send one approved email to a participant in a recently read existing thread. |
+| `wa_get_attachment` | `chat_id`, `message_id`, `attachment_id` all required, max 500 characters each | Download one attachment of one message in a chat this account owns. Read the chat first: the exact `message_id` and `attachment_id` come from `wa_read_messages`. Returns the stored path on the SignalDash host, mimetype, byte size and sha256. |
+| `wa_transcribe_voice` | `chat_id`, `message_id`, `attachment_id` all required, max 500 characters each; `backend` optional, exactly `gemini` or `whisper` | Turn one WhatsApp voice note into text through SignalDash instead of fetching provider bytes yourself. Always read the returned `backend`: `gemini` is the accurate default, `whisper-small` is the weak local fallback and mangles German with English terms mixed in, and a fallback also carries `fallback_reason`. Non-audio attachments are refused with `415 not_audio`; an unknown backend with `400 unknown_backend`; a transcription that exceeds its time limit returns `504 transcription_timeout` with the stored audio path. |
+| `wa_send_message` | `chat_id` required; `text` optional only when a file is attached, max 5000 characters; `attachments` optional array of up to 4 exact `{filename, content_type, content_base64}` files, at most 16 MiB per file and 16 MiB per message, types `image/png`, `image/jpeg`, `image/webp`, `image/gif`, `application/pdf`, `text/csv`, `text/plain`, `application/json`, `application/zip`, xlsx | Send one approved reply, one approved file, or both, in an existing WhatsApp conversation after an immediate re-read. A file spends the same daily send budget and is recorded the same way as a text message; there is no separate attachment budget. A call carrying neither text nor an attachment is refused with `400 text_or_attachment_required`. Attachments are checked before anything is reserved, so a refusal costs no send: `400 unsupported_attachment_type`, `400 attachment_too_large`, `400 attachments_too_large`, `400 too_many_attachments`, `400 malformed_attachment_base64`, `400 invalid_attachment_filename`, and `413 request_too_large` when the whole body is too big to read. Nothing is ever truncated or dropped silently. The same caption with the same file is refused as `409 duplicate_send`; the same caption with a different file is a different message and goes through. If a send times out or the provider never confirms it, the message may still have been delivered: an identical retry is refused with `409 send_outcome_unknown`. Read the chat AGAIN, and ONLY if the message is genuinely absent, resend the identical payload with `confirm_resend:true`. The re-read is enforced, not advisory: a `confirm_resend` whose most recent read of that chat predates the failed attempt is refused with `428 reread_after_failed_send_required`, because a read taken before the attempt cannot show whether the message arrived. The send also re-reads the thread immediately before sending and refuses with `409 thread_changed` if the conversation moved after the read that authorized it, or with `502 thread_preflight_unavailable` if that re-read fails; in both cases nothing was sent and no budget was spent. A chat whose most recent read predates thread-change detection is refused with `428 read_before_send_required` until it is read again. LinkedIn messages carry text only. |
+| `wa_delete_message` | `chat_id`, `message_id` both required, max 500 characters each | Retract one message THIS account sent, in a chat this account owns. The exact `message_id` comes from `wa_read_messages`. Irreversible and never retried: someone else's message is refused with `403 message_not_own`, a message outside this chat with `403 message_forbidden`, and a delete already recorded for this exact chat and message with `409 duplicate_delete`. Deletes spend their own daily budget, so `429 rate_limit_exceeded` here never means you are out of sends. WhatsApp applies its own time and role limits to deleting for everyone and can answer successfully without removing anything, so read the chat again to confirm the message is gone. |
+| `wa_delete_messages` | `messages` required array of 1-200 exact `{chat_id, message_id}` objects | Retract several messages this account sent. Same ownership, budget and audit path as `wa_delete_message`, executed strictly one at a time with a pause between them, never in parallel. Always read the per-entry `ok`, `code` and `error`: a partial result is normal. Entries the batch never reached before its time limit come back with `skipped:true` and `code:batch_deadline`, and were not attempted; resend exactly those to resume. |
+| `email_list` | `limit` integer 1-100, default 20; `cursor` optional, max 4096 | List the newest message in each recent email thread and obtain `thread_id`. The response carries a `cursor`; pass it back to read the next page, and omit it for the first. |
+| `email_read` | `thread_id` required; `limit` 1-100, default 30 | Read an email thread and authorize its exact participant addresses for a later send. Everyone on `cc` counts as a participant, so a read authorizes them too. The newest messages are returned, not the oldest, so the people being replied to are always in the window. |
+| `email_send` | `to` required as an array of exactly one valid address; `subject` required, max 998, single line; `body` required, max 5000; `thread_id` optional, max 500 | Send one approved email to a participant in a recently read existing thread. Pass the `thread_id` you read to reply inside that thread; omit it only when starting a new one. A blank or oversized `thread_id` is refused with `400 invalid_request` rather than quietly starting a new thread beside the original. The same subject and body to the same person in the same thread is refused as `409 duplicate_send`; the same words in a different thread are a different message and go through. A subject containing a line break is refused with `400 invalid_request`, because a subject is one header line; a body with line breaks is normal and sends. If a send leaves this host and the provider never answers, the retry is refused as `409 send_outcome_unknown`: read the thread again, and only if the email is genuinely absent resend with `confirm_resend: true`. |
 | `li_my_posts` | `limit` default 10, max 50; `member_id` optional | Find the user's latest posts and post IDs. Omit `member_id` to use the connected user's own ID. |
 | `li_post_reactions` | `post_id` required; `limit` default 50, max 100 | Identify who reacted to one post and assess warm signals. A reaction does not authorize outreach. |
 | `li_post_comments` | `post_id` required; `limit` default 50, max 100 | Read comments and authors for one post; prioritize questions and substantive responses. |
-| `li_draft_post` | `text` required, max 3000; `publish` optional, default false | Create a server-confirmed draft. Use `publish:true` only after explicit approval of the final public text. |
+| `li_draft_post` | `text` required, max 3000; `publish` optional; `scheduled_at` optional offset-qualified ISO date-time; `mentions` optional array of up to 20 exact `{name,profile_id}` objects; `attachments` optional array of up to 4 exact `{filename,content_type,content_base64}` images; `first_comment` optional, max 1250 | Create a server-confirmed draft, publish now, or persist an exact future LinkedIn post and its approved first comment. A schedule is stored only with `publish:true` after approval of the exact text, time, mentions, images, and comment. |
+| `li_set_scheduled_post_first_comment` | `id` required UUID; `first_comment` required, max 1250; `confirm:true` required | Attach one exact approved first comment to a scheduled post. SignalDash publishes it through the same connected account after the post and never republishes the post if the comment fails. |
+| `li_scheduled_posts` | no arguments | List only this authenticated user's scheduled LinkedIn posts and their durable states. |
+| `li_cancel_scheduled_post` | `id` required UUID; `confirm:true` required | Cancel one exact post while it is still scheduled. It cannot recall an executing or published post. |
+| `sd_schedule_message` | `channel` required, `whatsapp` or `linkedin`; `chat_id` required, max 500; `text` required, max 5000; `scheduled_at` required offset-qualified ISO date-time from 60 seconds to 365 days ahead; `confirm:true` required | Schedule one exact message into one chat you have already read. Read that exact chat first, at `limit` 10 or more on LinkedIn: SignalDash records what the thread looked like and refuses at send time if the conversation moved. Text only; attachments are refused rather than dropped. One message at one time, never a sequence. |
+| `sd_scheduled_messages` | `state` optional, one of `scheduled`, `executing`, `sent`, `cancelled`, `failed`, `needs_review`; `channel` optional | List only this authenticated user's scheduled messages and their durable states. Returns every matching row, unpaginated, and always reports `needs_review_count` outside your filter. |
+| `sd_cancel_scheduled_message` | `id` required UUID; `confirm:true` required | Cancel one exact message while its state is still `scheduled`. It cannot stop one already being sent, and it cannot unsend one that has been sent. |
 
 Representative calls:
 
@@ -388,22 +411,42 @@ sd_budget_status({})
 sd_settings_get({})
 sd_settings_set({"auto_accept_linkedin":true,"auto_accept_linkedin_filters":{"public_identifiers":["amina-rahman"],"description_keywords":["Founder"]},"confirm":true})
 sd_auto_accept_status({})
+sd_voice_profile({"channel":"whatsapp"})
+sd_voice_profile({"channel":"linkedin","force_recompute":true})
 li_search_connections({"query":"founder agents","filters":{"company":"Acme","headline_keyword":"Founder","connected_after":"2025-01-01","connected_before":"2026-01-01"},"limit":20})
 li_discover_people({"query":"Platform Engineer","filters":{"company":"Acme","location":"Berlin"},"limit":5})
 li_discover_people({"query":"Platform Engineer","filters":{"company":"Acme","location":"Berlin"},"limit":5,"confirm":true})
 li_create_invitation_batch({"source_label":"Approved Berlin founder shortlist","time_zone":"Europe/Berlin","targets":[{"profile_url":"https://www.linkedin.com/in/amina-rahman/","inclusion_reason":"Named by the user for this exact batch","note":"Hi Amina, I enjoyed your post on agent safety."}]})
 li_get_invitation_batch({"batch_id":"00000000-0000-4000-8000-000000000000"})
 li_cancel_invitation_batch({"batch_id":"00000000-0000-4000-8000-000000000000","approval_view_hash":"exact-64-character-hash-from-the-read","confirm":true})
+sd_campaign_create({"source_label":"Follow up on invitations I already sent","time_zone":"Europe/Berlin","targets":[{"profile_url":"https://www.linkedin.com/in/amina-rahman/","inclusion_reason":"I sent this connection request by hand last week","adopt_existing_invitation":true}],"messages":[{"text":"Thanks for connecting, Amina."}]})
+sd_campaign_create({"source_label":"People who engaged with my launch post","time_zone":"Europe/Berlin","target_source":"post_engagers","engagers":{"post_limit":3,"max_targets":40,"inclusion_reason":"Reacted to or commented on my post"},"messages":[{"text":"Thanks for connecting, Amina."},{"text":"I build the guardrails layer for agent sends."},{"text":"Worth a short call?","after_days":4}]})
+sd_campaign_preview({"campaign_id":"00000000-0000-4000-8000-000000000000"})
+sd_campaign_approve({"campaign_id":"00000000-0000-4000-8000-000000000000","confirm_token":"sd-4f2a-91bc-73de"})
+sd_campaign_status({"campaign_id":"00000000-0000-4000-8000-000000000000"})
+sd_campaign_cancel({"campaign_id":"00000000-0000-4000-8000-000000000000","approval_view_hash":"exact-64-character-hash-from-the-read","confirm":true})
 wa_list_chats({"limit":20})
 wa_read_messages({"chat_id":"chat_wa_91b2","limit":20})
+wa_get_attachment({"chat_id":"chat_wa_91b2","message_id":"msg_wa_5c71","attachment_id":"att_wa_0a33"})
+wa_transcribe_voice({"chat_id":"chat_wa_91b2","message_id":"msg_wa_5c71","attachment_id":"att_wa_0a33"})
 wa_send_message({"chat_id":"chat_wa_91b2","text":"16:30 works. See you then."})
+wa_send_message({"chat_id":"chat_wa_91b2","text":"Q3 numbers attached.","attachments":[{"filename":"q3-arr.csv","content_type":"text/csv","content_base64":"<base64>"}]})
+wa_delete_message({"chat_id":"chat_wa_91b2","message_id":"msg_wa_5c71"})
+wa_delete_messages({"messages":[{"chat_id":"chat_wa_91b2","message_id":"msg_wa_5c71"},{"chat_id":"chat_wa_91b2","message_id":"msg_wa_5c72"}]})
 email_list({"limit":20})
 email_read({"thread_id":"thread_email_c402","limit":30})
-email_send({"to":["amina@example.com"],"subject":"Re: Case study","body":"Hi Amina,\n\nHere is the case study."})
+email_send({"to":["amina@example.com"],"subject":"Re: Case study","body":"Hi Amina,\n\nHere is the case study.","thread_id":"thread_email_c402"})
 li_my_posts({"limit":5})
 li_post_reactions({"post_id":"post_urn_8821","limit":50})
 li_post_comments({"post_id":"post_urn_8821","limit":50})
 li_draft_post({"text":"Most agents need better context, not more autonomy."})
+li_set_scheduled_post_first_comment({"id":"00000000-0000-4000-8000-000000000000","first_comment":"https://github.com/xai-org/x-algorithm","confirm":true})
+li_scheduled_posts({})
+li_cancel_scheduled_post({"id":"00000000-0000-4000-8000-000000000000","confirm":true})
+sd_schedule_message({"channel":"whatsapp","chat_id":"chat_wa_91b2","text":"Following up on the Q3 numbers, as promised.","scheduled_at":"2026-08-19T09:00:00Z","confirm":true})
+sd_scheduled_messages({})
+sd_scheduled_messages({"state":"needs_review"})
+sd_cancel_scheduled_message({"id":"00000000-0000-4000-8000-000000000000","confirm":true})
 ```
 
 List and read success returns JSON with `items` and often a `cursor`. A message
@@ -420,8 +463,17 @@ result is deterministic:
 ```
 
 Publishing is public and irreversible. Never interpret "draft a post" as
-permission to publish. `email_send` cannot start a cold thread and must never be
-looped over recipients.
+permission to publish or schedule. For a future post, first call
+`li_draft_post` without `publish:true` and show the exact returned text,
+offset-qualified UTC instant, mentions, attachment count, and first comment.
+After explicit
+approval, repeat the identical payload with `publish:true`. Verify the stored
+record with `li_scheduled_posts`. For an existing scheduled post, use
+`li_set_scheduled_post_first_comment` only after approval of the exact comment.
+SignalDash persists the published post ID before sending the comment, so a
+comment failure never republishes the post. It fails interrupted or ambiguous
+executions closed and never retries them automatically. `email_send` cannot
+start a cold thread and must never be looped over recipients.
 
 ### Exact contact state and suppression
 
@@ -522,12 +574,77 @@ this week, failed attempts today, remaining dedicated and shared capacity,
 `consecutive_errors`, `disabled_reason`, and every recent unparseable record.
 Never describe a disabled or erroring worker as active.
 
-### Campaign time boundary
-
-SignalDash does not expose a general message scheduler. The first executable
-campaign scope has no user-selected future start date, recurring schedule,
-automatic follow-up, acceptance-triggered message, or multi-message
-("double text") sequence. Do not claim that any such action was queued.
+### Scheduling one exact message
+
+`sd_schedule_message` holds one exact message for one exact future instant and
+sends it once. It is not a follow-up, a sequence, or a reminder that repeats.
+Schedule a message only when the user asked for that message at that time.
+
+A scheduled send is the only write in SignalDash that reaches a person with
+nobody watching, so it is guarded twice: once when you schedule it and once
+again at the moment it fires.
+
+At schedule time you must have read the exact chat, on LinkedIn at `limit` 10 or
+more. SignalDash records what that read returned. A message you cannot prove was
+written against a real, recent view of the conversation is refused now rather
+than accepted and quietly parked days later, while there is still a human in the
+room to hear about it. This is why `watermark` and `item_limit` are not
+arguments: they are read off the record of your own read, and a proof a caller
+could supply is not a proof.
+
+At fire time SignalDash re-reads the thread and compares it. If the conversation
+moved, the message is not sent. It goes to `needs_review` for a human instead,
+because a message written on Monday against Monday's conversation may be deaf or
+wrong by Thursday, and the person receiving it has no way to know it was written
+before their reply existed. Everything else the live send path checks still
+applies at that moment: chat ownership, contact suppression, the duplicate
+guard, and the daily send budget.
+
+`confirm:true` is required, and it means the human approved this exact channel,
+chat, text, and time. `scheduled_at` must carry `Z` or an explicit numeric UTC
+offset. SignalDash does not infer a timezone: it does not know which one you
+meant, and the cost of guessing wrong is a message arriving in the middle of
+somebody's night.
+
+Check `sd_scheduled_messages` after scheduling, and read `needs_review_count`
+every time even when you filtered it out. A row in `needs_review` stopped at
+send time and is waiting on a person; its `failure_detail` says what stopped it.
+For some of those rows whether the message reached the other person is genuinely
+unknown, and that is the answer to report, not a guess in either direction.
+
+`sd_cancel_scheduled_message` works only while the state is `scheduled`. It
+cannot stop a message that is already being sent, and it cannot unsend one that
+has been sent: that text is in the other person's chat and nothing here takes it
+back. If a sent message was wrong, say so in the chat. A cancel that names an id
+belonging to somebody else is refused in exactly the same words as an id that
+never existed, so a refusal never tells you whether another account's message is
+real.
+
+### Post scheduling and campaign time boundary
+
+SignalDash supports an exact one-time future LinkedIn post through
+`li_draft_post`. It does not infer a timezone: `scheduled_at` must contain `Z`
+or an explicit numeric UTC offset. Mention names must appear exactly in the
+approved text. Image bytes are frozen with the schedule, so later file changes
+cannot alter the approved payload. An optional approved `first_comment` is
+frozen with the same schedule and is posted through the same connected account
+after the post provider ID is durably stored. A failed or ambiguous comment is
+never retried and never causes the post to be published again. Use
+`li_scheduled_posts` to verify the durable post and comment states. Cancellation
+requires a fresh list, the exact id, approval, and
+`confirm:true`; it works only while state is `scheduled`.
+
+Everything SignalDash can schedule is one exact thing at one exact time:
+`li_draft_post` for a post, `sd_schedule_message` for a message. There is no
+recurring schedule, no automatic follow-up, no acceptance-triggered message and
+no multi-message ("double text") sequence anywhere in this tool set, and the
+first executable campaign scope has no user-selected future start date either.
+Do not claim that any such action was queued, and do not try to assemble one out
+of several scheduled messages into the same chat. That is not only forbidden, it
+does not work: the first message landing is itself a change to the conversation,
+so the second one, written against the thread as it was before, fails its
+fire-time freshness check and parks as `needs_review` for a human. You get one
+message sent and one waiting, which is worse than having scheduled nothing.
 
 The common server write authority enforces the design-approved time controls
 for every campaign action:
@@ -549,7 +666,9 @@ draft, and human approval.
 
 ### Human-approved invitation batches
 
-An invitation batch is the only executable campaign form. It contains 1–10
+An invitation batch is the invitation-only form: it stops permanently at the
+invitation result. For the request-then-message loop use the campaign tools in
+the next section. A batch contains 1–10
 exact canonical LinkedIn Classic profile URLs, one exact inclusion reason per
 target, and one optional exact invitation note per target. The note limit is
 200 Unicode code points. Source labels, reasons, and notes reject leading or
@@ -584,9 +703,11 @@ Use the batch tools in this order:
 
 Cancel permanently terminates the batch and affects only unstarted targets.
 It cannot recall an executing provider action. A restart requires a new batch,
-preview, and human approval. There is no pause/resume, priority, future start,
-recurring schedule, automatic follow-up, acceptance polling, acceptance
-message, multi-message sequence, or action after a successful invitation.
+preview, and human approval. A batch itself has no pause/resume, priority,
+future start, recurring schedule, follow-up, acceptance polling, acceptance
+message, or action after a successful invitation. Those belong to the separate
+campaign loop below, which requires its own explicit human approval of both the
+invitation and every message.
 
 Unknown outcomes, provider warnings, checkpoints, HTTP 403, and HTTP 429 stop
 the batch and lock the sender. Two campaign `outcome_unknown` writes on
@@ -598,6 +719,189 @@ Definite provider rejections consume attempts but can leave later exact targets
 eligible to run. SignalDash limits are not LinkedIn-safe thresholds, and
 native LinkedIn activity can still race the final reads.
 
+
+### The human-approved campaign loop
+
+A campaign is exactly one thing: a connection request, then the approved
+message once that person accepts. It is the only place SignalDash acts after an
+acceptance, and it acts only on the exact text a human read and approved.
+
+What the server proves, and refuses to assume:
+
+- A pending invitation that simply disappeared is NOT an acceptance. It may have
+  been withdrawn, expired, or declined. A target advances only when a fresh
+  profile read, fetched by the STABLE provider id rather than the mutable
+  `/in/<slug>` vanity URL, returns BOTH that same provider id and a connected
+  network distance. If the profile now resolves to a different member, the
+  target is excluded as `target_identity_changed` and is never messaged: a
+  vanity URL can be freed and reissued to somebody else. A distance SignalDash
+  cannot classify leaves the target waiting and is reported in
+  `sd_campaign_status.parse_failures`, never guessed in either direction.
+- The sequence stops permanently the moment that person sends anything back.
+- A first message is refused if the thread already holds an outbound message,
+  and any step whose exact text is already in the thread is skipped.
+- A provider list SignalDash cannot recognise is never read as an empty list.
+  Every absence proof -- no reply, no prior outbound, no existing conversation,
+  no pending invitation -- blocks and is reported rather than passing silently.
+- Campaign invitations and campaign messages consume the SAME per-sender daily
+  budget as your manual sends, plus the campaign ceiling and the weekly
+  invitation cap. They obey the Monday-Friday 09:00-17:00 sender-local window
+  and the 90-180 second pacing interval, and they never burst to catch up.
+- Building a target list from post engagers fetches no profiles: the reactions
+  and comments endpoints already return the member id and the network distance.
+  Prefer that and `li_search_connections` over anything that opens profiles.
+
+Use the campaign tools in this order:
+
+1. Get the exact people and the exact words from the human. Draft the messages
+   in the user's own voice and keep them short: the on-acceptance group is two
+   or three separate sends, never one block. Never invent a recipient or a
+   sentence. Ask whether they already sent any of these people a connection
+   request themselves; if so, mark that target `adopt_existing_invitation`
+   instead of dropping them.
+2. Call `sd_campaign_create` once.
+3. Poll `sd_campaign_preview` until the campaign is `previewed` or terminal.
+   Show the human every recipient, every exclusion and its reason, and the exact
+   text of every message step.
+4. Relay the returned `approval_url`. The human authenticates with the
+   SignalDash invite credential, reads the rows, ticks the recipients they
+   approve (none are preselected), and acknowledges the consequences. They then
+   either approve there, or press the button that mints a one-time
+   `confirm_token` for you. Only then call `sd_campaign_approve`. An agent
+   bearer token cannot approve, and you cannot mint that code. Five failed
+   credential attempts durably block that campaign's authentication surface for
+   15 minutes.
+5. Watch progress with `sd_campaign_status`. Report acceptances, replies,
+   exclusions, and parse failures honestly, including people who never accepted.
+6. To stop, inspect first, show the exact state and `approval_view_hash`, obtain
+   cancellation approval, then call `sd_campaign_cancel` once with that hash and
+   `confirm:true`.
+
+#### The user already sent the invitation by hand
+
+The most common real shape is not a cold list. It is: the human sent somebody a
+connection request themselves, from the LinkedIn app, and now wants the
+follow-up automated. A campaign normally REFUSES that person with
+`invitation_already_pending`, because that exclusion exists to stop a duplicate
+invitation.
+
+Set `adopt_existing_invitation: true` on that exact target instead of leaving
+them out. It inverts one check and nothing else:
+
+- a still-pending sent invitation to that person becomes REQUIRED, not
+  disqualifying;
+- SignalDash sends **no invitation at all** for that person, ever. If the
+  pending invitation is not there when SignalDash looks, the person is dropped
+  with `adopted_invitation_missing`. A missing invitation is never replaced by
+  a new one, so this can never become a send the human did not ask for;
+- the invitation is matched to the target by the STABLE PROVIDER ID from a
+  fresh profile read, never by the profile URL. LinkedIn frees and reissues
+  vanity URLs, so a URL can resolve to a different human;
+- the approval page states, in that person's own row, that no invitation is
+  sent, which invitation is being adopted, and how old it is. Say the same
+  thing to the human before you send them the link;
+- an adopted target may not carry a `note`, because no invitation goes out and
+  a note would only misrepresent what is about to happen;
+- at most 10 adopted targets per campaign: each one costs one profile read in
+  the preview to resolve its provider id.
+
+Everything after that is identical to any other target. Acceptance is still
+proven only by a fresh profile read showing a connected network distance, the
+messages still need their own approval on the same page, the thread is still
+read before the first message, and anything in that thread the campaign did not
+send halts the sequence permanently. If the recipient answered the invitation
+note without accepting, that conversation already exists and the target is
+dropped with `existing_conversation`: it is a human conversation in progress,
+not a campaign to resume.
+
+The acceptance window (`invite_ttl_days`) for an adopted target is counted from
+the moment SignalDash adopts it, not from the hand-sent invitation, whose age
+LinkedIn only reports as a bucket. Tell the human that if it matters.
+
+An invitation nobody accepted within `invite_ttl_days` is dropped and never
+messaged. The approval window is derived from the schedule the human approved --
+the acceptance window plus every follow-up wait plus two days -- so no approved
+step can fall outside its own receipt, and a schedule that would not fit inside
+60 days is refused at creation. Every individual write still re-proves identity,
+relationship, pending state, and conversation absence immediately before it
+happens, and `sd_campaign_status` reports the exact expiry.
+
+### Clearing a backlog of old pending sent invitations
+
+A user with hundreds or thousands of pending sent invitations has no supported
+way to clear them one at a time: `li_withdraw_invitation` needs `confirm:true`
+per action, and generating 824 confirmations would defeat that contract rather
+than satisfy it. The withdrawal sweep is the supported path.
+
+**Two things you MUST tell the human, because both are LinkedIn's own
+documented behaviour, and getting either wrong is a false claim:**
+
+1. **This does NOT free up sending capacity.** LinkedIn's help page states that
+   withdrawing an invitation does not lift an active sending restriction.
+   Withdrawal and the weekly invitation limit are decoupled. Never sell this as
+   a way to send more. What it does do is clear a stale backlog, and LinkedIn
+   does name invitations that are "ignored, left pending, or marked as spam"
+   among the things it looks at.
+2. **After withdrawing, the human cannot re-invite that person for up to three
+   weeks.** That cost is per person and irreversible for that window. Approving
+   824 withdrawals accepts it for 824 people. Say the number.
+
+Do not repeat the widely-quoted "3000 pending invitations" ceiling. It is in no
+LinkedIn document and vendor numbers contradict each other. Do not suggest that
+invitation behaviour causes hidden reach suppression; LinkedIn's restrictions
+are explicit and notified.
+
+**`exclude` is required and load bearing.** Ask the human, before you call
+anything, who must NOT be withdrawn. A real request came with three specific
+people the owner had just protected, and two of the three fell inside his own
+blanket age rule. Passing `[]` is allowed but it means nobody is protected, and
+the review page says so in those words. An exclusion that matches nobody fails
+the preview by default: that is the shape of a typo, and a typo means the
+person they meant to protect ends up in the withdraw list.
+
+**Age labels are buckets, not dates.** LinkedIn does not expose a send date. It
+exposes "Sent 4 months ago", and the timestamp is derived from that label, so
+ordering inside a bucket is meaningless and any day-based filter is
+bucket-accurate at best. SignalDash selects an invitation only when its WHOLE
+bucket is older than the threshold. On a real account a naive label filter
+matched 1384 invitations while this conservative rule matched 1036; the 348
+difference is people whose bucket straddles the threshold. They are held back,
+because withdrawing them costs three weeks and cannot be undone.
+`sd_withdrawal_batch_status` reports both counts.
+
+Pace and budget:
+
+- One withdrawal per tick, 4-12 seconds apart, at most 44 a day across 4 short
+  runs of 11 with a 45-minute gap between runs. Never one continuous session.
+  The only documented hard failure was roughly 8000 withdrawals in one
+  uninterrupted burst producing "Account Network Blocked".
+- Monday-Friday 09:00-17:00 in the sender timezone you supply.
+- The sweep has its OWN daily allowance and never consumes the send budget, so
+  it cannot starve real invitations and messages. It is visible in
+  `sd_budget_status` under `withdrawal_sweep`, explicitly not counted in
+  `safe_actions_remaining_today`.
+- A 403, a 429, any provider warning, an unrecognised provider response, or an
+  account status change stops the WHOLE sweep, not just one item. Restarting
+  needs a new preview and a new human approval.
+- An invitation that stopped being pending, because the person accepted or it
+  expired, is skipped rather than forced, and the sweep continues.
+
+Use the tools in this order:
+
+1. Ask the human for the age rule and, explicitly, the people to protect.
+2. Call `sd_withdrawal_batch_create` once with `exclude` filled in.
+3. Poll `sd_withdrawal_batch_status` until it is `previewed` or terminal. Show
+   the human the count, the protected names, both age counts, the three-week
+   consequence, and that this does not free sending capacity.
+4. Relay the returned `approval_url`. The human authenticates, reads the rows,
+   unticks anyone they want kept, and either approves there or presses the
+   button that mints a one-time `confirm_token` for you. Only then call
+   `sd_withdrawal_batch_approve`. An agent bearer token cannot approve.
+5. Watch with `sd_withdrawal_batch_status`. Report the stop reason honestly if
+   it stopped.
+6. To stop early, inspect first, then `sd_withdrawal_batch_cancel` with the
+   `approval_view_hash` it returned and `confirm:true`.
+
 ### Search your stored LinkedIn network
 
 `li_search_connections` is the primary list-building path before any external
@@ -712,6 +1016,29 @@ and the command exits with failure.
 These controls run on the server. Prompt instructions, a new session, or a
 different calling order cannot bypass them.
 
+### 403 `channel_required`
+
+Meaning: this session has not yet completed its own QR scan, so it has no
+linked channel. An invite code proves an operator sent it to this person. It
+does not prove the person still controls a channel some earlier session
+linked, so a session that has not scanned cannot read stored data about the
+person or about third parties, and cannot change persistent settings. This
+covers `sd_contact_state`, `li_search_connections`, `sd_settings_set`, and
+every campaign and withdrawal-batch tool.
+
+Comply:
+
+1. Do not retry the tool and do not switch to another tool to read the same
+   data.
+2. Relay the personal setup link to the human and have them finish the QR
+   scan, exactly as in "First-time setup".
+3. Confirm with the status check in step 3 of that section, then retry.
+
+`sd_settings_get`, `sd_budget_status`, `sd_auto_accept_status`, and
+`sd_voice_profile` are deliberately not behind this guard: the first three are
+how you verify a live session during setup, and `sd_voice_profile` reports
+`<channel>_not_connected` instead.
+
 ### 428 `read_before_send_required`
 
 Meaning: this user has not successfully read the exact chat recently, or the
@@ -728,6 +1055,48 @@ Comply:
 
 Do not satisfy this guard by reading a different chat with a similar name.
 
+A LinkedIn or WhatsApp message send also returns this code when the most recent
+read of that chat predates thread-change detection and therefore carries no
+record of what the thread looked like. Read the chat again and send.
+
+`sd_schedule_message` returns it for the same reason and one more: a LinkedIn
+read of fewer than 10 messages is not recorded as proof at all, so reading that
+thread again at the same shallow depth returns this code again. Read at `limit`
+10 or more. The refusal names the depth and the window it enforced; read what it
+says rather than repeating the call. The check runs before the `confirm` gate,
+so you find out you have to read the chat before you ask anyone to approve a
+message you cannot yet schedule.
+
+### 409 `thread_changed`
+
+Meaning: the exact chat moved after the read that authorized the send. Both
+`li_send_message` and `wa_send_message` re-read the thread immediately before
+sending and refuse unless it is still the thread that was read. A read inside
+the 30-minute window is not enough on its own: a thread that changed 29 minutes
+ago satisfies the window and is still not the conversation the draft was
+written against.
+
+Comply:
+
+1. Do not resend the same text.
+2. Re-read the exact chat and read the new messages.
+3. Revise the draft against what the thread now says, and obtain approval again.
+4. Send once, promptly.
+
+A `502 thread_preflight_unavailable` on a send means that re-read itself failed,
+so whether the thread changed is unknown and nothing was sent. Retry the send
+later; do not treat it as a delivery. It also covers a re-read the provider
+answered successfully but in a shape SignalDash does not recognise, which is the
+same fact: no answer about whether the conversation moved. In that case a `428
+read_before_send_required` on the next attempt is expected too, because a read
+of an unrecognised shape records no authorization.
+
+Your own send moves the thread too, so two messages in a row are refused unless
+you read the chat between them. This is not a glitch to work around: the second
+message was drafted against a conversation that no longer exists, if only
+because the first message is now in it. Read, confirm the first message landed
+as intended, then send the second. If you meant one message, send one message.
+
 ### 409 `duplicate_send`
 
 Meaning: the exact message was already sent to that chat, or the exact email
@@ -764,7 +1133,8 @@ claim that SignalDash has resolved a person across channels.
 
 ### 409 invitation and context preflight blocks
 
-`thread_changed`, `already_connected`, `existing_conversation`,
+`thread_changed` (also returned by a message send, see above),
+`already_connected`, `existing_conversation`,
 `conversation_state_incomplete`, `invitation_already_pending`,
 `inbound_invitation_pending`, `invitation_not_pending`,
 `invitation_state_incomplete`, and `relationship_unverified` mean the exact
@@ -854,8 +1224,16 @@ public LinkedIn posts.
 The hosted backend defaults to 20 LinkedIn action attempts per stable logical
 sender per UTC day, shared across messages, invitations, invitation
 maintenance, and post publishing. Invitation sends also use the default
-100-attempt weekly policy. Email and WhatsApp retain their hosted send caps. A
-deployment can configure different caps. Never promise a particular remaining
+100-attempt weekly policy.
+
+WhatsApp and email share ONE separate daily bucket, and it is independent of
+the LinkedIn one: a WhatsApp message never spends LinkedIn capacity and a
+LinkedIn message never spends WhatsApp capacity.
+Deletes have a third bucket again, so a `429` on a delete never means you are
+out of sends. Read which cap the `429` names before you conclude anything about
+another channel. `sd_budget_status` is authoritative for the LinkedIn one.
+
+A deployment can configure different caps. Never promise a particular remaining
 allowance until the response reports `rate_limit.limit` and `remaining`.
 
 ## Worked flows
@@ -971,6 +1349,30 @@ User: "Find my WhatsApp thread with Sara and reply that 16:30 works."
 8. Read the chat again and confirm the text appears once as an outbound
    message.
 
+If the user then asks to take that message back:
+
+1. Read the chat again and quote back the exact message you are about to
+   remove, with its `message_id`, and get explicit approval for that exact
+   message. A delete cannot be undone and there is no draft state to review.
+2. Delete once:
+
+   ```text
+   wa_delete_message({"chat_id":"chat_wa_91b2","message_id":"msg_wa_5c71"})
+   ```
+
+3. Read the chat again. WhatsApp enforces its own time and role limits and can
+   answer a delete successfully without removing anything, so a 200 is not
+   proof. Only the re-read is.
+4. Never delete a message the user did not name. `403 message_not_own` means
+   the message is the other person's and cannot be removed by anyone,
+   including a group admin. `409 duplicate_delete` means SignalDash already
+   recorded this exact delete; do not retry it, re-read instead.
+
+For several messages, pass them to `wa_delete_messages` in one call rather than
+looping `wa_delete_message` yourself: it paces them and never runs two at once.
+Read the per-entry results, and resend only the entries marked
+`code:batch_deadline`, which were never attempted.
+
 ### Flow 4: send, accept, or withdraw one LinkedIn invitation
 
 For a new invitation:
@@ -1167,6 +1569,74 @@ User: "Invite these two exact LinkedIn profiles with these notes."
 8. Report that planned targets were cancelled and any executing action was not
    recalled. Never claim the batch was paused or can resume.
 
+### Flow 9: create, approve, and watch one campaign
+
+User: "Send connection requests to everyone who engaged with my last post and
+message them when they accept."
+
+1. Confirm the exact source (their own post engagers, or an exact list they
+   supply), the sender timezone, and the exact wording of every message. Draft
+   in their voice, two or three short sends for the on-acceptance group, and
+   read them back for approval before creating anything.
+2. Call `sd_campaign_create` once, then poll `sd_campaign_preview` until it is
+   `previewed` or terminal.
+3. Report the recipient count, every exclusion reason, and the exact message
+   text. Relay the `approval_url` and do not fetch, submit, or automate that
+   page.
+4. If the human hands you a `sd-xxxx-xxxx-xxxx` code, call
+   `sd_campaign_approve` with it once. If they approved in the browser instead,
+   just confirm with `sd_campaign_status`.
+5. Report progress from `sd_campaign_status` only. Never treat a disappeared
+   invitation as an acceptance, and never claim a message was sent unless the
+   step state says `sent`.
+6. For cancellation, inspect immediately, show the state and
+   `approval_view_hash`, obtain approval, then call `sd_campaign_cancel`.
+
+### Flow 10: clear a backlog of old pending sent invitations
+
+User: "I have 1668 pending invitations. Withdraw everything older than a month."
+
+1. Before calling anything, ask two questions and wait for the answers:
+   **"Who must NOT be withdrawn?"** and the sender timezone. Do not guess
+   either. If they say "nobody", that is a real answer and you pass `[]`, but
+   read back that nobody will be protected.
+2. Tell them, in plain words, before they approve:
+   - this does **not** free up sending capacity, LinkedIn does not lift a
+     sending restriction when you withdraw;
+   - they will **not be able to re-invite these people for up to three weeks**,
+     and say how many people that is;
+   - "older than a month" is bucket-accurate at best, because LinkedIn only
+     exposes labels like "sent 4 months ago", so the count they see may be
+     smaller than they expect and that is deliberate.
+3. Call it once:
+
+   ```text
+   sd_withdrawal_batch_create({
+     "account":"linkedin",
+     "older_than_days":90,
+     "time_zone":"Europe/Berlin",
+     "exclude":[
+       {"kind":"display_name","value":"the exact name they gave you"},
+       {"kind":"public_identifier","value":"their-linkedin-slug"}
+     ]
+   })
+   ```
+
+4. Poll `sd_withdrawal_batch_status` until `previewed` or terminal. If it comes
+   back `failed_preview` with `exclusion_matched_nothing`, do NOT retry with
+   `allow_unmatched_exclusions:true` on your own initiative: show the human the
+   unmatched entries and ask whether it is a typo. A typo means the person they
+   meant to protect would be withdrawn.
+5. Report the count, the exact protected names, the naive versus conservative
+   age counts, and the expected number of working days at 44 a day. Relay the
+   `approval_url` and do not fetch, submit, or automate that page.
+6. If the human hands you a `sd-xxxx-xxxx-xxxx` code, call
+   `sd_withdrawal_batch_approve` with it once. Otherwise confirm with
+   `sd_withdrawal_batch_status`.
+7. Report progress from `sd_withdrawal_batch_status` only. If `state` is
+   `stopped`, say the `stop_reason` plainly and do not create a replacement
+   sweep until the human decides.
+
 ## Read-only requests and drafts
 
 Read-only account work does not require send approval. You can list, read,
@@ -1224,8 +1694,9 @@ Before reporting completion, verify:
 - No duplicate, bulk, parallel, warning, 403, or 429 path was bypassed.
 - No sender lock or `outcome_unknown` result was retried.
 - A send was confirmed by a post-send read.
-- A post draft remained unpublished unless `publish:true` was explicitly
-  approved.
+- A post draft remained unpublished and unscheduled unless `publish:true` was
+  explicitly approved. Every scheduled post was read back with its exact UTC
+  instant, mention count, attachment count, first comment, and durable states.
 - An export ended with `+ saved` and a non-empty CSV.
 
 If any item is unverified, state exactly what remains incomplete.
@@ -1248,15 +1719,19 @@ LinkedIn or WhatsApp it gets ignored. Less is more, always.
   fuer). Never translate their language away.
 - **Read the thread first, then sound like the user.** Their own recent messages
   in that thread are the style reference. Copy that register, not a template.
+- **Call `sd_voice_profile(channel)` before drafting.** It returns this exact
+  user's own hard length stats (median/p75/p90) and verbatim redacted
+  exemplars for that one channel, mined from their real sent messages. Match
+  the returned numbers and rhythm, not a generic idea of "their style" from
+  the thread alone.
 
 Before/after, same intent:
 
-> Bad: "Hi Mircea, I hope you're doing well! Thanks so much for reaching out
+> Bad: "Hi Alex, I hope you're doing well! Thanks so much for reaching out
 > about scheduling a call. I'd be delighted to connect and would love to explore
 > how we might be able to work together. Please let me know what times work best
 > for you and I'll do my best to accommodate your schedule."
 
-> Good: "hey Mircea, ja gerne. hier mein link: [cal]"
+> Good: "hey Alex, sure. here's my link: [cal]"
 
 If a draft is longer than the thread's own messages, cut it before showing it.
-