@floomhq/signaldash 0.13.0 → 0.27.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", "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, connection diagnosis, safe reading, drafting, approved sends, 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,42 @@ 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@0.27.0 <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 installed skill lives in a directory that the current agent discovers.
+   Common locations are:
 
-3. Confirm that the saved file begins with `name: signaldash` and contains the
+   - Claude Code: `~/.claude/skills/signaldash/SKILL.md`
+   - Codex: `~/.codex/skills/signaldash/SKILL.md`
+   - Portable project scope: `.agents/skills/signaldash/SKILL.md`
+
+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@0.27.0 skill
    ```
 
    Expected success:
@@ -73,8 +73,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
 
@@ -91,14 +92,41 @@ Typical trigger phrases include:
 - "Check my email", "summarize the thread", "draft a response", or "send the
   approved email."
 - "Draft a post", "turn this into a LinkedIn post", or "publish this post."
+- "Send a connection request to this exact person", "check my invitations",
+  "accept this invitation", or "withdraw this pending invitation."
+- "How many LinkedIn actions remain?", "check my action budget", or "can a
+  campaign act today?"
+- "Auto-accept my LinkedIn invitations", "turn invitation auto-accept off", or
+  "did auto-accept hit any errors?" Use the persistent per-user setting and
+  status tools; it is off until explicitly enabled.
+- "Search my LinkedIn connections", "find founders in my network", or "who at
+  Acme am I connected to?" Use the local connection snapshot before any
+  external or paid discovery.
+- "Find platform engineers beyond my network" or "discover people at Acme in
+  Berlin." Use `li_discover_people` only after the completed local snapshot
+  returns no matches. Preview the exact paid request and cost before confirming
+  one capped provider page.
+- "Schedule this message", "follow up automatically", or "send these as a
+  sequence." Explain the narrow campaign time boundary below; do not invent a
+  queue or claim those unsupported actions were scheduled.
+- "Create a LinkedIn invitation batch for these exact profiles." Structure the
+  human's request into exact URLs, reasons, and notes, create the immutable
+  preview, and relay its human review path. Never approve through MCP.
 - "Who engaged with my last post?", "who liked it?", "what did people comment?",
   or "which warm signals need action?"
 - "Export my connections", "download my LinkedIn network", or "make me a
   connections CSV."
 
-Do not use SignalDash for public LinkedIn research, invitations, profile
-enrichment, scraping, bulk outreach, or a new email to someone with no existing
-thread. SignalDash exposes no LinkedIn invitation tool.
+Do not use SignalDash for general public LinkedIn research, full-profile
+enrichment, email finding, unreviewed bulk outreach, unapproved automatic
+invitation processing, or a new email to someone with no existing thread.
+`li_discover_people` is the narrow exception for one capped page of public
+search cards after own-network search. Its results are planning evidence only.
+Invitation tools act on one exact provider member or invitation at a time and
+never authorize a list-wide loop. The only automatic incoming-invitation
+exception is the explicitly enabled, filterable, rate-capped auto-accept worker.
+The only multi-target outbound exception is an immutable 1–10-target invitation
+batch with separate exact browser approval and server-controlled execution.
 
 ## The operating model
 
@@ -106,8 +134,10 @@ There are two surfaces:
 
 1. The CLI handles login, account connection, status, skill installation, MCP
    startup, logout, and the paced LinkedIn connections export.
-2. MCP tools handle account reads, message sends, email, LinkedIn posts, and
-   post engagement.
+2. MCP tools handle account reads, local connection search, capped paid
+   discovery, message sends, immutable invitation-batch create/inspect/cancel,
+   exact LinkedIn invitation actions, email, LinkedIn posts, and post
+   engagement.
 
 The CLI command used by the MCP registration is:
 
@@ -257,23 +287,30 @@ Use this sequence unless the request is read-only and ends before approval:
 
 1. **Confirm connection.** Run `npx -y @floomhq/signaldash status` when channel
    state is unknown. A connected status is required.
-2. **Choose the narrowest list tool.** List recent chats, email threads, or the
-   user's recent posts. Use a modest limit.
-3. **Resolve the exact object.** Match the full chat name, thread, or post.
+2. **Choose the narrowest list or preview tool.** List recent chats, email
+   threads, invitation inboxes, or the user's recent posts. Preview an outbound
+   invitation through `li_send_invitation` with `confirm` omitted. Use a modest
+   limit.
+3. **Resolve the exact object.** Match the full chat name, thread, invitation,
+   provider member, or post.
    When names collide or identity is unclear, show the candidates and ask the
    user. Never infer from a partial name.
 4. **Read before interpreting.** Read enough recent history to understand the
    latest inbound message, earlier context, and existing outbound messages.
-   For sends, read at least 10 recent items and use the exact chat or thread.
+   For message sends, read at least 10 recent items and use the exact chat or
+   thread. For invitation maintenance, list the exact current invitation. For
+   a new invitation, inspect the server-confirmed exact target and note preview.
 5. **Return findings or draft.** Summarize concrete facts. Separate suggested
    replies from messages already sent.
 6. **Obtain explicit approval.** Before any message or public post, show the
    exact channel, recipient, and complete text. For email include subject and
    body. Discussion, editing, "looks good", or approval of a different draft is
    not approval of the final action.
-7. **Re-read immediately before sending.** Re-read the exact thread to catch a
-   human reply, a manual send, or a duplicate that appeared after drafting. If
-   context changed, revise and obtain approval again.
+7. **Re-read immediately before acting.** Re-read the exact thread or current
+   invitation list to catch a human action, reply, duplicate, acceptance, or
+   withdrawal that appeared after drafting. New invitation sends repeat the
+   exact previewed payload with `confirm:true`; the server rechecks relationship
+   and pending invitation state.
 8. **Act once.** Send one approved message or publish one approved post. Never
    parallelize sends and never loop over recipients.
 9. **Verify.** Read the exact thread again after a successful send. Confirm the
@@ -305,19 +342,51 @@ 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. |
-| `wa_list_chats` | `limit` integer 1-100, default 20 | Find an existing WhatsApp conversation and exact `chat_id`. |
+| `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. |
+| `li_invitations_received` | `limit` integer 1-100, default 50; `cursor` optional | List one bounded page of received invitations. This read authorizes only the exact returned invitation IDs for a later accept. |
+| `li_accept_invitation` | `invitation_id` required; `confirm:true` required | Accept one exact currently pending received invitation after a fresh `li_invitations_received` read and approval. |
+| `li_invitations_sent` | `limit` integer 1-100, default 50; `cursor` optional | List one bounded page of sent invitations. This read authorizes only the exact returned invitation IDs for a later withdrawal. |
+| `li_withdraw_invitation` | `invitation_id` required; `confirm:true` required | Withdraw one exact currently pending sent invitation after a fresh `li_invitations_sent` read and approval. |
+| `sd_contact_state` | `channel` required (`linkedin`, `whatsapp`, or `email`); `identifiers` required array of 1-8 exact `{kind,value}` objects; `action` optional (`get` default or `suppress`); suppression also requires an allowed `reason` and `confirm:true` | Inspect exact tenant/channel-scoped contact history or add a protective suppression. It never infers that identifiers on different channels belong to one person. |
+| `sd_budget_status` | no arguments | Read the current sender binding, daily total/manual/campaign/unknown attempts, total and combined-campaign capacity, weekly invitation usage, lock state, and UTC resets from the authoritative server ledger. |
+| `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. |
+| `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. |
+| `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. 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 | 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. |
 | `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. |
 
 Representative calls:
 
@@ -325,9 +394,40 @@ Representative calls:
 li_list_chats({"limit":20})
 li_read_messages({"chat_id":"chat_li_7f3a","limit":20})
 li_send_message({"chat_id":"chat_li_7f3a","text":"Yes. I’ll send it this afternoon."})
+li_send_invitation({"provider_id":"ACoAAExactMember","note":"Hi Amina, I enjoyed your post on agent safety."})
+li_send_invitation({"provider_id":"ACoAAExactMember","note":"Hi Amina, I enjoyed your post on agent safety.","confirm":true})
+li_invitations_received({"limit":20})
+li_accept_invitation({"invitation_id":"invite_received_42","confirm":true})
+li_invitations_sent({"limit":20})
+li_withdraw_invitation({"invitation_id":"invite_sent_91","confirm":true})
+sd_contact_state({"channel":"linkedin","identifiers":[{"kind":"provider_id","value":"ACoAAExactMember"}]})
+sd_contact_state({"channel":"email","identifiers":[{"kind":"email","value":"amina@example.com"}],"action":"suppress","reason":"opt_out","confirm":true})
+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."})
@@ -335,6 +435,9 @@ 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})
 ```
 
 List and read success returns JSON with `items` and often a `cursor`. A message
@@ -351,13 +454,478 @@ 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
+
+`sd_contact_state` is local and account-scoped. It makes no Unipile, LinkedIn,
+WhatsApp, or email provider request. Exact identifiers are keyed separately by
+user and channel, and the response does not echo their values.
+
+Allowed identifier kinds:
+
+- LinkedIn: `provider_id`, `public_identifier`, canonical `profile_url`,
+  `member_urn`, or `chat_id`.
+- WhatsApp: `chat_id` or an E.164 `phone`.
+- Email: normalized `email`.
+
+One fresh provider response can supply several exact identifiers for the same
+channel. Pass those together to get the conservative union of their state.
+Never combine identifiers based on a name, employer, headline, similar profile,
+phone guess, or email guess. SignalDash does not infer cross-channel identity
+and does not claim person-wide suppression.
+
+Use `action:"get"` before outreach planning. `campaign_eligible:false` and
+`blocking_reasons` report known replies, earlier outbound touches,
+already-connected state, or suppression. Automated campaign actions are
+rejected after a known reply or earlier touch. Manual approved replies remain
+available unless an exact identifier is suppressed.
+
+Use `action:"suppress"` only after the human explicitly asks to suppress the
+exact identifier. Show the channel, identifier kind, and reason, then repeat
+with `confirm:true`. Allowed reasons are `opt_out`, `not_interested`,
+`provider_block`, `manual`, and `legal`. MCP cannot clear a suppression.
+
+### LinkedIn action budget status
+
+`sd_budget_status` is read-only and account-scoped. Use it before planning
+manual LinkedIn work or any campaign action. It reports attempts that
+SignalDash has committed in its authoritative SQLite ledger:
+
+- the total daily cap (`H`);
+- the campaign-excluded portion (`R = min(4, H)`);
+- the combined ceiling across all campaigns (`C = H - R`);
+- total, manual, campaign, and unknown attempts for the UTC policy day;
+- raw total and combined-campaign capacity remaining;
+- actions available now after connection and sender-lock state;
+- weekly LinkedIn invitation usage and its Monday 00:00 UTC reset.
+
+`R` is capacity campaigns cannot consume. It is not a reserve or guaranteed
+manual allowance: manual activity can consume the total cap first, and a later
+manual action can still be rejected at `H`. Campaign capacity is shared across
+all campaigns and is additionally bounded by the total remaining capacity.
+
+The result counts SignalDash-recorded attempts only. Native LinkedIn activity
+is not fully counted, so never describe the result as a LinkedIn-safe
+allowance. A disconnected, unverified, or locked sender reports zero safe
+actions even when raw counter capacity remains. It reports the durable pacing
+time and work window after a campaign action has established them. The
+scheduler, persisted tenant-breaker, active-batch, and target-count fields
+reflect the current invitation-batch runtime.
+
+### Opt-in invitation auto-accept
+
+`sd_settings_get` is the single read surface for persistent SignalDash
+settings. `sd_settings_set` changes persistent behavior for only the
+authenticated SignalDash user. Auto-accept is the first supported setting;
+every existing and newly created user is disabled by default. Show the exact
+setting and filters, obtain explicit human approval, then call the setter once
+with `confirm:true`. Disabling also uses `confirm:true`. Never infer changes to
+future or unknown settings.
+
+With no filters, every parseable pending LinkedIn invitation is eligible. The
+optional `public_identifiers` list is an exact lowercase allowlist. Optional
+`description_keywords` are case- and accent-insensitive substring matches
+against the provider's inviter description. When both groups are present, both
+must match. Names are never used as identity filters.
+
+The server worker is the action authority. By default it reads one bounded
+page, accepts no more than five invitations per run and ten per UTC day,
+jitters before every fresh preflight, serializes writes per sender, consumes
+the shared LinkedIn daily budget, and stops on a warning, 403, 429, unknown
+outcome, sender lock, or three consecutive errors. Successful acceptance is
+written to the action audit and exact LinkedIn contact state as inbound,
+invited, and connected, so later campaigns see the relationship.
+A healthy worker run resets the consecutive provider-error streak; malformed
+invitations remain visible in status even after later healthy runs.
+
+Unipile currently places acceptance proof at `specifics.shared_secret` and
+inviter data at
+`inviter.{inviter_name,inviter_public_identifier,inviter_description}`.
+SignalDash also reads the legacy top-level secret and old inviter fields. It
+never returns or logs the secret. An invitation missing its ID, acceptance
+proof, or an exact inviter identifier is not accepted: the server emits a
+high-visibility error, stores only sanitized missing-field evidence, and
+exposes it through `sd_auto_accept_status`. Three consecutive parse or provider
+errors disable automation with `disabled_reason:"repeated_errors"`.
+
+Use `sd_auto_accept_status` after changing the setting and whenever the user
+asks whether it is healthy. Report `enabled`, exact filters, accepted today and
+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.
+
+### 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`.
+
+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.
+
+The common server write authority enforces the design-approved time controls
+for every campaign action:
+
+- a valid sender IANA timezone is mandatory;
+- actions run only Monday through Friday, 09:00-17:00 sender-local time;
+- every attempted action atomically stores the next per-sender pacing time,
+  randomized from 90 to 180 seconds;
+- timing is checked before final provider preflight and again in the same
+  SQLite transaction that reserves budget and acquires the sender lease;
+- one provider write may be in flight per sender;
+- downtime, a work-window boundary, or a UTC reset never creates a catch-up
+  burst.
+
+Manual one-object tools keep their existing exact-read, approval, duplicate,
+rate, ownership, contact-state, and sender-lock guards. A later message after
+an invitation or reply is new context and requires a fresh thread read, exact
+draft, and human approval.
+
+### Human-approved invitation batches
+
+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
+trailing whitespace; notes normalize line endings and reject control or format
+characters.
+
+The human can describe the desired batch naturally, but the agent must
+structure only facts the human explicitly supplied. Never infer or generate a
+profile URL, inclusion reason, or note. Search, discovery, reactions, comments,
+and connection exports are not batch target sources. The server performs no
+runtime target or text generation.
+
+Use the batch tools in this order:
+
+1. Call `li_create_invitation_batch` once with the exact source label, sender
+   IANA timezone, and complete ordered target list.
+2. Poll only with `li_get_invitation_batch` until the durable preview is
+   `previewed` or terminal. Inspect every target, including exclusions.
+3. Relay the returned `approval_url` to the human. The human opens it in a
+   browser, reauthenticates with the SignalDash invite credential, checks each
+   desired target (none are preselected), acknowledges the consequences, and
+   approves. MCP and agent bearer tokens cannot approve. Five failed credential
+   attempts durably block that batch's authentication surface for 15 minutes.
+4. Continue read-only status checks with `li_get_invitation_batch`. The worker
+   submits selected targets in fixed order only while the 24-hour approval,
+   sender binding, weekday work window, pacing, budgets, exact identity,
+   contact state, invitation state, chat absence, and tenant breaker remain
+   valid.
+5. To stop, first inspect the batch, show the exact state and hash, obtain
+   cancellation approval, then call `li_cancel_invitation_batch` once with
+   that hash and `confirm:true`.
+
+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. 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
+different senders within five minutes open the persisted tenant breaker.
+Tenant provider authentication failures open it immediately. While open, the
+breaker rejects new batch creation and stops queued preview work before any
+provider read.
+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
+discovery. It is account-scoped and searches the stored connection sidecar
+only. The request path performs zero LinkedIn, Unipile, HarvestAPI, or other
+paid API calls and never starts or resumes a sync.
+
+The required `query` matches accent-insensitive terms across name, headline,
+and stored company. Optional `company` and `headline_keyword` filters are
+case-insensitive substrings. `connected_after` and `connected_before` use
+inclusive `YYYY-MM-DD` bounds. Legacy v1 relation rows do not contain a
+separate company field, so their company filter is transparently matched
+against the returned headline.
+
+Each result contains only:
+
+- `name`, `headline`, `public_id`, `profile_url`, and `connected_at`;
+- `already_in_contact`, based on exact recorded inbound, outbound, reply, or
+  invitation history;
+- the joined `contact_state`, `campaign_eligible`, and `blocking_reasons`.
+
+The join checks only the row's exact LinkedIn public identifier and canonical
+profile URL for this SignalDash user. It does not infer a person, merge aliases,
+or inspect another tenant. Search results are planning evidence, not permission
+to message or invite anyone. A later action still requires its exact
+one-object read/preview, human review, approval, fresh preflight, and server
+guards. The executable invitation-batch design does not accept a search result
+as a target input.
+
+When no connection rows are stored, the tool returns
+`connections_not_synced` or `connections_sync_pending` and points to:
+
+```bash
+npx -y @floomhq/signaldash connections linkedin-connections.csv
+```
+
+Use that paced, resumable sync. Never replace the missing snapshot with a burst
+of profile reads.
+
+### Capped discovery beyond the stored network
+
+`li_discover_people` is the only supported paid discovery path. It searches
+public LinkedIn profile cards through HarvestAPI without using the connected
+LinkedIn sender. It does not fetch full profiles, find email addresses, send
+anything, or create invitation-batch targets.
+
+The server enforces local-first behavior. A completed paced connection snapshot
+is mandatory. SignalDash searches that snapshot with the requested role/title
+and company before any paid request. When local matches exist, it returns those
+matches with `source:"own_network"` and `provider_requests:0`; use
+`li_search_connections` to refine them. An incomplete snapshot returns
+`connections_sync_required` and starts no provider request.
+
+When there are no local matches:
+
+1. Call `li_discover_people` without `confirm`. The response previews the exact
+   query, filters, result limit, ten-profile maximum billing exposure, maximum
+   reserved cost, and 30-minute expiry. It makes zero paid requests.
+2. Show the human that exact paid request and maximum reserved cost. Obtain
+   explicit approval.
+3. Repeat the identical arguments once with `confirm:true`.
+
+The hosted server then makes at most one serialized
+`GET /linkedin/profile-search` request for page 1. It reserves the configured
+worst-case page cost in integer micro-dollars before the request and enforces a
+durable per-user cooldown, per-user daily request cap, tenant-wide daily
+request cap, and tenant-wide daily cost cap. The reservation consumes the exact
+preview atomically. Another paid request, including one after a failed or
+ambiguous provider result, requires a fresh preview and approval. Failed or
+ambiguous provider requests retain their reservation and are never retried
+automatically.
+
+SignalDash removes hidden `"LinkedIn Member"` cards, malformed or ambiguous
+identities, duplicates, exact stored connections, and exact contact-state rows
+already marked connected. Returned cards contain only name, headline,
+location, public identifier, canonical profile URL, and exact local contact
+state. No fuzzy or cross-channel identity merge occurs.
+
+Discovery results are planning evidence only. `CAMPAIGN-DESIGN.md` excludes
+searches and discovery as invitation-batch target sources. A later action on
+one exact person begins the complete one-object preview, approval, fresh
+preflight, contact-state, duplicate, ownership, and rate-limit flow.
 
 ### LinkedIn connections export via CLI
 
-This is the fourteenth operation. It is intentionally a paced CLI workflow, not
-an MCP bulk-read tool.
+This is intentionally a paced CLI workflow, not an MCP bulk-read tool.
 
 ```bash
 npx -y @floomhq/signaldash connections linkedin-connections.csv
@@ -389,8 +957,9 @@ different calling order cannot bypass them.
 ### 428 `read_before_send_required`
 
 Meaning: this user has not successfully read the exact chat recently, or the
-email recipient was not present in a recently read thread. The default read
-window is 30 minutes.
+email recipient was not present in a recently read thread, or an invitation
+write lacks its exact recent preview/list read. The default read window is 30
+minutes.
 
 Comply:
 
@@ -417,6 +986,41 @@ Comply:
 
 Changing whitespace or punctuation to evade the duplicate guard is prohibited.
 
+### 409 `contact_suppressed`
+
+Meaning: one of the exact channel identifiers for this contact has an active
+suppression. Message and invitation writes stop before the provider write.
+
+Comply:
+
+1. Stop the action.
+2. Inspect the exact state with `sd_contact_state`.
+3. Do not switch identifiers, channels, accounts, or sessions to evade it.
+4. Escalate a mistaken suppression to the SignalDash operator. MCP cannot clear
+   it.
+
+Campaign-mode actions also reject `recipient_replied` and `already_contacted`.
+These blocks prevent automated follow-up after a known inbound message and
+prevent another campaign from touching the same exact identifier. They do not
+claim that SignalDash has resolved a person across channels.
+
+### 409 invitation and context preflight blocks
+
+`thread_changed`, `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
+provider state no longer authorizes the action. New-invitation preflight checks
+up to 250 sent invitations, up to 100 received invitations, and the exact
+target's attendee-scoped chats. Any pagination cursor makes absence unproved.
+
+Comply:
+
+1. Stop the action.
+2. Re-read the exact thread or invitation list.
+3. Do not expand pagination or fetch profiles in a loop.
+4. Obtain new approval only for a newly previewed exact action.
+
 ### 429 `rate_limit_exceeded`
 
 Meaning: the persisted daily action cap is exhausted. The response includes
@@ -431,21 +1035,54 @@ Comply:
    to work around the cap.
 4. Do not queue a burst for the reset boundary.
 
+Invitation sends also return `invitation_rate_limit_exceeded` when the separate
+weekly policy is exhausted. The default policy is 100 attempts per sender,
+resetting Monday at 00:00 UTC. It is a SignalDash policy, not a claim about a
+LinkedIn-safe threshold.
+
+Paid discovery returns `paid_discovery_cooldown`,
+`paid_discovery_user_daily_cap`, `paid_discovery_tenant_daily_cap`, or
+`paid_discovery_cost_cap` before the HarvestAPI request when its pacing,
+request, or spend boundary is reached. Stop and use `retry_at` or the UTC reset
+reported by the server. Do not switch users, sessions, or machines to bypass a
+paid-provider cap.
+
+### 423 sender locks and 502 `outcome_unknown`
+
+A provider warning, HTTP 403, HTTP 429, sender identity mismatch, or ambiguous
+provider outcome locks all later LinkedIn writes for that logical sender. An
+ambiguous result returns `outcome_unknown`, consumes the action budget, and is
+never retryable.
+
+Comply:
+
+1. Do not retry or switch sessions.
+2. Inspect the provider account manually for a restriction and verify whether
+   the action landed.
+3. Escalate for human reconciliation. Only the hosted operator can clear the
+   durable lock after verification.
+
 Any upstream 429, provider warning, checkpoint, restriction, unusual-activity
 prompt, or HTTP 403 also means stop. Do not retry.
 
 ## Before every send
 
-These rules apply to LinkedIn, WhatsApp, email, and public LinkedIn posts.
+These rules apply to LinkedIn messages and invitations, WhatsApp, email, and
+public LinkedIn posts.
 
 1. Never send or publish without explicit human approval of the exact
-   recipient or audience and the exact final text.
-2. Read the exact thread immediately before the action. Check the recipient,
-   latest inbound message, prior context, and whether the proposed text already
-   exists as an outbound item.
+   recipient or audience and the exact final text. The only standing-action
+   exception is invitation auto-accept after explicit approval of its exact
+   persistent setting and filters.
+2. Read the exact thread immediately before a message action. For invitations,
+   preview the exact target and note or list the exact current invitation.
+   Check the recipient, latest inbound message, prior context, relationship,
+   pending state, and whether the proposed action already exists.
 3. Never infer a recipient from a partial name. Resolve duplicate names with
    the user.
-4. Never bulk-send, fan out, loop over people, or parallelize actions.
+4. Never loop or parallelize single-object send tools. Only the immutable
+   invitation-batch runner may submit more than one target, and only after the
+   separate exact browser approval.
 5. Never turn reactions, comments, connections, or exported rows into an
    unsolicited outreach list.
 6. Send one message at human pace. Let server pacing finish.
@@ -456,9 +1093,19 @@ These rules apply to LinkedIn, WhatsApp, email, and public LinkedIn posts.
 9. Confirm delivery by reading the thread after the action.
 10. Account health outranks throughput and task completion.
 
-The hosted backend defaults to 20 action attempts per authenticated user per
-UTC day, shared across message sends, email sends, and post publishing. A
-deployment can configure a different cap. Never promise a particular remaining
+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.
+
+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
@@ -529,7 +1176,9 @@ User: "Who engaged with my last LinkedIn post, and what should I do?"
    Do not invent profile facts absent from the result.
 6. If the user asks to message one person, locate the exact existing chat,
    read it, draft a contextual message, obtain exact approval, re-read, and
-   send once. SignalDash cannot invite or mass-message reactors.
+   send once. If the user explicitly asks to invite one exact reactor, resolve
+   the exact provider ID, run the invitation preview, obtain exact approval,
+   and send once. Engagement never authorizes an invitation or a loop.
 
 ### Flow 3: find and reply to a WhatsApp thread
 
@@ -572,7 +1221,130 @@ 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.
 
-### Flow 4: export LinkedIn connections
+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:
+
+1. Resolve one exact `provider_id`. A display name or fuzzy match is
+   insufficient.
+2. Preview without confirmation:
+
+   ```text
+   li_send_invitation({
+     "provider_id":"ACoAAExactMember",
+     "note":"Hi Amina, I enjoyed your post on agent safety."
+   })
+   ```
+
+3. Show the server-confirmed sender, target, exact note, and character count.
+4. Obtain approval for that exact target and note.
+5. Repeat the identical payload once with `"confirm":true`.
+6. Stop on relationship, existing-conversation, incomplete-state,
+   pending-invitation, cap, warning, lock, or `outcome_unknown` errors. Never
+   retry an ambiguous result.
+
+For received or sent invitation maintenance:
+
+1. Call `li_invitations_received` or `li_invitations_sent`.
+2. Resolve the exact invitation ID and show the exact person and action.
+3. Obtain approval.
+4. Call `li_accept_invitation` or `li_withdraw_invitation` once with that ID
+   and `"confirm":true`.
+5. List again to verify that the invitation is no longer pending.
+
+Never loop over the returned page. Incoming acceptance and stale withdrawal
+are human-approved, single-object operations only.
+
+### Flow 4b: enable and inspect invitation auto-accept
+
+User: "Auto-accept LinkedIn invitations from these exact public IDs when their
+description contains Founder."
+
+1. Call `sd_settings_get({})`, then show the exact persistent setting:
+
+   ```text
+   Enabled: true
+   Public identifiers: amina-rahman, marco-silva
+   Description keywords: Founder
+   Matching rule: exact public ID AND description keyword
+   ```
+
+2. Obtain explicit approval, then call once:
+
+   ```text
+   sd_settings_set({
+     "auto_accept_linkedin":true,
+     "auto_accept_linkedin_filters":{
+       "public_identifiers":["amina-rahman","marco-silva"],
+       "description_keywords":["Founder"]
+     },
+     "confirm":true
+   })
+   ```
+
+3. Verify with:
+
+   ```text
+   sd_auto_accept_status({})
+   ```
+
+4. Report the setting, accepted count today and this week, failed attempts
+   today, both remaining capacities, repeated-error state, and every
+   unparseable invitation. If the worker disabled itself, stop and surface the
+   exact `disabled_reason` and missing fields. Do not silently re-enable it.
+5. To disable, obtain explicit approval and call
+   `sd_settings_set({"auto_accept_linkedin":false,"confirm":true})`, then
+   verify both `sd_settings_get({})` and status.
+
+### Flow 5: search LinkedIn connections locally
+
+User: "Find product leaders at Acme in my LinkedIn network."
+
+1. Call:
+
+   ```text
+   li_search_connections({
+     "query":"product leader",
+     "filters":{"company":"Acme"},
+     "limit":20
+   })
+   ```
+
+2. Confirm the response has `local_only:true` and `provider_requests:0`.
+3. Return only the stored profile fields and exact contact-state result. Do not
+   add inferred profile facts or cross-channel identity.
+4. If the response says `connections_not_synced` or
+   `connections_sync_pending`, relay its paced-sync instruction. Do not trigger
+   profile reads or discovery as a substitute.
+5. Stop after the read-only results. A later action on one exact person starts
+   the complete guarded one-object flow with fresh provider context and
+   approval. Never turn the result page into a send loop.
+
+### Flow 6: export LinkedIn connections
 
 User: "Export my LinkedIn connections to CSV."
 
@@ -595,11 +1367,156 @@ User: "Export my LinkedIn connections to CSV."
 6. Report the saved path and row count. If the CLI reports a paused or partial
    sync, say that the export is partial and rerun later to resume.
 
+### Flow 7: discover people beyond the stored network
+
+User: "Find platform engineers at Acme in Berlin beyond my network."
+
+1. Call without confirmation:
+
+   ```text
+   li_discover_people({
+     "query":"Platform Engineer",
+     "filters":{"company":"Acme","location":"Berlin"},
+     "limit":5
+   })
+   ```
+
+2. If it returns `source:"own_network"`, return those local matches and stop.
+   The paid provider was not called.
+3. If it returns `connections_sync_required`, run or resume the paced
+   connections sync and stop. Do not bypass it.
+4. If it returns a paid preview, show the exact query, filters, result limit,
+   and `maximum_cost_reserved_usd`. Obtain explicit approval.
+5. Repeat the identical payload once with `"confirm":true`.
+6. Report only the returned public profile-card fields and exact contact state.
+   State that hidden/unusable and exact already-connected cards were excluded.
+7. Stop after the read-only results. Do not enrich profiles, find emails,
+   create a batch, or loop into invitations or messages.
+
+### Flow 8: create, review, or cancel one invitation batch
+
+User: "Invite these two exact LinkedIn profiles with these notes."
+
+1. Confirm the human supplied every canonical profile URL, exact inclusion
+   reason, exact optional note, source label, and sender timezone. Ask for any
+   missing value. Do not fill gaps with search or generation.
+2. Call:
+
+   ```text
+   li_create_invitation_batch({
+     "source_label":"User-approved event follow-up",
+     "time_zone":"Europe/Berlin",
+     "targets":[
+       {
+         "profile_url":"https://www.linkedin.com/in/amina-rahman/",
+         "inclusion_reason":"The user met Amina at the named event",
+         "note":"Hi Amina, great meeting you at the agent safety meetup."
+       }
+     ]
+   })
+   ```
+
+3. Store the exact `batch_id`. Call `li_get_invitation_batch` until its state
+   is `previewed` or terminal. Report every excluded row and reason.
+4. Show the sender, source, ordered targets, full profile URLs, reasons, exact
+   notes, reused-copy counts, current limits, timing, expiry, cancellation
+   limit, and residual native-activity race.
+5. Relay the exact `approval_url`. Do not fetch, submit, or automate that
+   browser page. The human reauthenticates and selects the desired unchecked
+   rows.
+6. Inspect the batch to report `approved`, `running`, or terminal progress.
+   Never interpret an approval-page visit as approval; only server state proves
+   it.
+7. For cancellation, inspect immediately, show the exact state and
+   `approval_view_hash`, obtain explicit cancellation approval, then call:
+
+   ```text
+   li_cancel_invitation_batch({
+     "batch_id":"00000000-0000-4000-8000-000000000000",
+     "approval_view_hash":"the exact hash from the fresh read",
+     "confirm":true
+   })
+   ```
+
+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 work does not require send approval. You can list, read, summarize,
-analyze engagement, and create a non-published post draft as requested. Still
-use narrow limits, protect private content, and avoid bulk collection.
+Read-only account work does not require send approval. You can list, read,
+search the stored connection snapshot, summarize, analyze engagement, and
+create a non-published post draft as requested. Paid discovery separately
+requires approval of its exact preview and maximum reserved cost. Still use
+narrow limits, protect private content, and avoid bulk collection. Search and
+discovery results do not authorize an outbound action.
 
 For every draft, label it clearly as a draft. Never present a suggested reply
 as sent. Never present `{"drafted":true,"published":false}` as a published post.
@@ -628,11 +1545,65 @@ Before reporting completion, verify:
 - The skill is persisted in a discovered skill directory.
 - `status` proves the required provider is connected.
 - The exact chat, thread, post, or export path was resolved.
+- A connection search reported `local_only:true`, made zero provider requests,
+  and did not authorize an outbound action.
+- A paid discovery had a completed connection snapshot, returned no own-network
+  matches, used an unexpired exact preview and approval, made at most one
+  serialized provider request, reported its cost budget, and remained planning
+  evidence only.
 - Every send used a fresh exact-thread read and exact human approval.
+- Every invitation send used an exact server preview and exact approval.
+- Every invitation accept or withdrawal used a fresh exact invitation-list
+  read and exact approval.
+- Invitation auto-accept was explicitly enabled for the exact user, preserved
+  both the dedicated and shared caps, stopped on repeated errors, and exposed
+  every unparseable invitation through `sd_auto_accept_status`.
+- Every invitation batch used only exact user-supplied canonical profile URLs,
+  reasons, and notes; exposed every target; used the separate browser approval;
+  and never approved through MCP.
+- Every batch cancel followed a fresh exact batch read and stated that an
+  executing action cannot be recalled.
 - 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.
+
+## How to write the message (this is where agents fail hardest)
+
+Agents pad. Padding is the clearest tell that a human did not write it, and on
+LinkedIn or WhatsApp it gets ignored. Less is more, always.
+
+- **Short.** A reply is usually 1-3 sentences. If they wrote one line, reply
+  with one line. Match the length and register of the thread.
+- **One idea per message.** Do not stack context, ask and pleasantry into one
+  block. Split into 2-3 short consecutive sends instead of one paragraph.
+- **No preamble, no summary-back.** Never "I hope this finds you well", never
+  restate what they just said, never a formal sign-off in a chat.
+- **No em dashes.** Use commas, periods, colons.
+- **No hype filler.** Cut "excited to", "reaching out", "just wanted to",
+  "circling back", "leverage", "synergies", and any eager closer.
+- **Their language.** German thread stays German, with real umlauts (für, not
+  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 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 Alex, sure. here's my link: [cal]"
+
+If a draft is longer than the thread's own messages, cut it before showing it.