@floomhq/signaldash 0.36.0 → 0.38.0

package/README.md

@@ -102,7 +102,7 @@ setup installs both from the same pinned npm package
 the human chose to execute:
 
 ```bash
-npx -y @floomhq/signaldash@0.36.0 <invite-code>
+npx -y @floomhq/signaldash@0.38.0 <invite-code>
 ```
 
 Run that command in a terminal, not in an agent chat. Do not ask an agent to
@@ -132,6 +132,7 @@ SignalDash exposes:
 - `li_list_chats`
 - `li_read_messages(chat_id)`
 - `li_mark_read(chat_id)`
+- `li_start_chat(member_ids, text, confirm?, approval_hash?, dry_run?)`
 - `li_send_message(chat_id?, text?, expected_watermark?, mark_read?, secretary_receipt_id?)`
 - `li_send_invitation(provider_id, note?, confirm?)`
 - `li_invitations_received(limit?, cursor?)`
@@ -163,6 +164,7 @@ SignalDash exposes:
 - `wa_mark_read(chat_id)`
 - `wa_get_attachment(chat_id, message_id, attachment_id)`
 - `wa_transcribe_voice(chat_id, message_id, attachment_id)`
+- `wa_start_chat(member_ids, text, confirm?, approval_hash?, dry_run?)`
 - `wa_send_message(chat_id, text?, attachments?, expected_watermark?, mark_read?)`
 - `wa_delete_message(chat_id, message_id)`
 - `wa_delete_messages(messages)`
@@ -187,6 +189,24 @@ SignalDash exposes:
 Every operation runs through the hosted SignalDash backend. Agents never
 receive the Unipile access key.
 
+`li_start_chat` and `wa_start_chat` are separate tools because LinkedIn and
+WhatsApp expose different stable member-ID formats and spend different budget
+lanes. Both use the same safety contract. A first call previews 1 to 10 exact
+member IDs and the exact first message. A confirmed call requires the
+payload-bound approval hash, resolves every member live, rejects protected or
+suppressed contacts, and checks attendee-scoped provider evidence for an exact
+existing member set. An existing match is returned without creating a chat or
+sending the text. A new chat costs one action, independent of member count,
+because the provider performs one irreversible conversation-and-message write.
+Success requires readback of exactly one matching chat and exactly one own first
+message. `dry_run:true` repeats the live preflight and stops before the provider
+write, without consuming approval or budget. Database capability flags
+`linkedin_chat_start` and `whatsapp_chat_start` disable the paths immediately.
+When WhatsApp resolves an `@lid` alias to a canonical member ID, the first
+preview returns `member_alias_requires_exact_id` and `resolved_member_id`.
+Preview again with that exact ID before approval. SignalDash never substitutes
+an unapproved member identity inside a confirmed write.
+
 The inspiration library also extracts LinkedIn post references already stored
 inside conversation `signals`. This path scans SQLite only and makes zero
 LinkedIn or Unipile calls. Feed URLs and post slugs become canonical activity
@@ -305,6 +325,16 @@ uses the same sender binding, action ledger, duplicate guard, daily budget, and
 provider-warning lock as immediate publishing. An interrupted or ambiguous
 execution fails closed and is never retried automatically.
 
+`li_scheduled_posts` is the shared planning read across posts stored by
+SignalDash and the configured Buffer LinkedIn channel. Every item names its
+source, and the response reports independent completeness for SignalDash,
+Buffer, and native LinkedIn. Unipile has no documented endpoint for posts or
+drafts scheduled natively in LinkedIn, so that source is always explicit as
+`unavailable`. SignalDash does not call undocumented Voyager routes or automate
+linkedin.com to fill the gap. An empty item list therefore means only that the
+visible SignalDash and Buffer sources are empty, never that the native LinkedIn
+calendar is empty.
+
 `sd_schedule_message` puts one exact message into one exact chat at one exact
 time, on WhatsApp or LinkedIn, text only. It enqueues; it never sends. The
 attachment bytes a WhatsApp send accepts are refused here rather than held on
@@ -361,9 +391,10 @@ explicitly enables it with `confirm:true`. The optional filters are an exact
 public-identifier allowlist and description-keyword matches; when both groups
 are configured, both must match. The single backend worker reads one bounded
 received-invitation page, accepts at most five invitations per run and ten per
-UTC day by default, jitters every action, and also consumes the shared daily
-LinkedIn action budget. Three consecutive parse or provider errors disable the
-setting. `sd_auto_accept_status` exposes accepted counts today and this week,
+UTC day by default, jitters every action, and also consumes the invitation
+daily lane and aggregate LinkedIn brake. Three consecutive parse or provider
+errors disable the setting. `sd_auto_accept_status` exposes accepted counts
+today and this week,
 failed attempts today, remaining capacity, the stop reason, and sanitized
 records for invitations whose provider shape could not be parsed. Both the current nested
 `specifics.shared_secret` and legacy top-level shape are supported; secrets are
@@ -415,22 +446,30 @@ npx -y @floomhq/signaldash connections linkedin-connections.csv
 
 ## Safety limits
 
-SignalDash enforces a daily send cap. The operating skill adds the human
+SignalDash enforces daily write caps. The operating skill adds the human
 workflow around that runtime control:
 
-- Every successful send includes `rate_limit.limit`, `used`, `remaining`, and
-  `resets_at`, plus matching `X-RateLimit-*` headers. When the per-user cap is
-  exhausted, SignalDash returns HTTP 429 with `code: "rate_limit_exceeded"` and
-  `Retry-After`. Usage is persisted server-side and resets at midnight UTC.
-- The caps are per channel lane: LinkedIn actions, WhatsApp and email sends
-  together, and message deletes each spend their own daily budget. A `429` names
+- Every successful LinkedIn write includes aggregate `rate_limit` data and its
+  applicable `lane_rate_limit` when classified. `rate_limit.limit`, `used`,
+  `remaining`, and `resets_at` retain their stable response shape. A lane
+  refusal returns HTTP
+  429 with an exact invitation, message, or engagement code and
+  `rate_limit_lane`; the aggregate brake retains
+  `code: "rate_limit_exceeded"`. Every 429 includes `Retry-After`.
+  Counters are persisted server-side and reset at midnight UTC.
+- LinkedIn uses three per-sender lanes: 20 invitation actions, 30 messages in
+  existing threads, and 50 replies or reactions on own posts per UTC day by
+  default. Publishing and first comments count with own-post engagement. A
+  separate aggregate cap of 75 is the emergency brake across the lanes. Sent
+  invitations retain the unchanged 100-attempt UTC-week policy.
+- WhatsApp and email sends together, and message deletes, retain their own
+  independent budgets. A `429` names
   the cap it hit; it is never a statement about another lane. Two caveats worth
   knowing: on the day a deployment first upgrades past the lane split, that
   day's existing count is still read on the LinkedIn side (it is ambiguous, and
   the conservative reading is the safe one) and clears at the next UTC midnight;
-  and the WhatsApp/email lane is keyed per access token while the LinkedIn
-  ledger is keyed per user, so several live tokens for one user get one LinkedIn
-  budget but a WhatsApp budget each.
+  LinkedIn, WhatsApp/email, and delete ledgers are keyed to the stable logical
+  user or sender rather than multiplied by live bearer sessions.
 - Read the exact thread before every send.
 - Preview an exact invitation target and note before sending it.
 - List the exact received or sent invitation before accepting or withdrawing it.
@@ -439,7 +478,8 @@ workflow around that runtime control:
 - Never infer a recipient from a partial name.
 - Never send a duplicate or retry an ambiguous timeout without re-reading.
 - Invitation auto-accept remains off until explicitly enabled, consumes both
-  its dedicated daily cap and the shared LinkedIn action cap, and disables
+  its dedicated daily cap, the invitation lane, and the aggregate LinkedIn
+  brake, and disables
   itself after three consecutive parse or provider errors.
 - Do not parallelize sends or work around a rate limit.
 - Do not bypass paid-discovery previews, pacing, request caps, or cost caps.
@@ -449,8 +489,8 @@ workflow around that runtime control:
 
 LinkedIn invitation writes are single-object actions. SignalDash serializes
 them with other LinkedIn writes, requires an exact preview or list read,
-applies the shared daily action cap, and enforces a separate 100-attempt weekly
-policy by default. For a new invitation, jitter completes before the final
+applies the invitation daily lane and aggregate brake, and enforces a separate
+100-attempt weekly policy by default. For a new invitation, jitter completes before the final
 preflight and action reservation; that preflight verifies relationship state,
 pending invitations in both directions, and absence of an existing one-to-one
 chat. Provider timeouts become non-retryable `outcome_unknown` locks.

package/bin/sd.mjs

@@ -491,6 +491,23 @@ const TOOLS = [
       additionalProperties: false,
     },
   },
+  {
+    name: "li_start_chat",
+    path: "/li/start_chat",
+    description: "Preview or start one LinkedIn direct or group chat with 1 to 10 exact provider member IDs and one exact first message. First call without confirm. After human approval of the complete member set and text, repeat the exact payload with confirm:true and approval_hash. dry_run:true runs the full live preflight twice and stops immediately before the provider write. One created chat spends one thread-message and aggregate action regardless of member count. Existing exact member sets are returned without creating or sending anything.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        member_ids: { type: "array", minItems: 1, maxItems: 10, uniqueItems: true, items: { type: "string", minLength: 3, maxLength: 500, pattern: "^(?:ACo|ACw|AE)[A-Za-z0-9_-]+$" } },
+        text: { type: "string", minLength: 1, maxLength: 5000 },
+        confirm: { type: "boolean", default: false },
+        approval_hash: { type: "string", minLength: 64, maxLength: 64, pattern: "^[0-9a-f]{64}$" },
+        dry_run: { type: "boolean", const: true },
+      },
+      required: ["member_ids", "text"],
+      additionalProperties: false,
+    },
+  },
   {
     name: "li_send_message",
     ch: "li",
@@ -637,7 +654,7 @@ const TOOLS = [
   {
     name: "sd_budget_status",
     path: "/sd/budget_status",
-    description: "Read authoritative SignalDash LinkedIn attempt capacity for this UTC day and week across manual work and all campaigns. Reports the campaign-excluded portion without promising a reserved manual slot.",
+    description: "Read authoritative SignalDash LinkedIn attempt capacity for the invitation, existing-thread message, and own-post engagement daily lanes, the aggregate emergency brake, and the unchanged weekly invitation cap.",
     inputSchema: {
       type: "object",
       properties: {},
@@ -948,7 +965,7 @@ const TOOLS = [
   {
     name: "sd_campaign_preview",
     path: "/sd/campaign/preview",
-    description: "Inspect one campaign before approval: every exact recipient, every exclusion and its reason, the exact message text for each step, the timing, the shared daily budget, and the approval_url to send the human. Show the human this content. This read also authorizes a later exact cancel. An agent cannot approve a campaign; only the authenticated human page can, and it can hand you a one-time code for sd_campaign_approve.",
+    description: "Inspect one campaign before approval: every exact recipient, every exclusion and its reason, the exact message text for each step, the timing, the invitation and existing-thread message lanes, the aggregate brake, and the approval_url to send the human. Show the human this content. This read also authorizes a later exact cancel. An agent cannot approve a campaign; only the authenticated human page can, and it can hand you a one-time code for sd_campaign_approve.",
     inputSchema: {
       type: "object",
       properties: {
@@ -1205,6 +1222,23 @@ const TOOLS = [
       additionalProperties: false,
     },
   },
+  {
+    name: "wa_start_chat",
+    path: "/wa/start_chat",
+    description: "Preview or start one WhatsApp direct or group chat with 1 to 10 exact @s.whatsapp.net or @lid member IDs and one exact first message. First call without confirm. If the provider maps an @lid alias to a canonical ID, repeat the preview with the returned resolved_member_id so the human approves the exact provider-write identity. After human approval of the complete member set and text, repeat the exact payload with confirm:true and approval_hash. dry_run:true runs the full live preflight twice and stops immediately before the provider write. One created chat spends one WhatsApp/email send action regardless of member count. Existing exact member sets are returned without creating or sending anything.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        member_ids: { type: "array", minItems: 1, maxItems: 10, uniqueItems: true, items: { type: "string", minLength: 5, maxLength: 500, pattern: "^[A-Za-z0-9._-]+@(?:s\\.whatsapp\\.net|lid)$" } },
+        text: { type: "string", minLength: 1, maxLength: 5000 },
+        confirm: { type: "boolean", default: false },
+        approval_hash: { type: "string", minLength: 64, maxLength: 64, pattern: "^[0-9a-f]{64}$" },
+        dry_run: { type: "boolean", const: true },
+      },
+      required: ["member_ids", "text"],
+      additionalProperties: false,
+    },
+  },
   {
     name: "wa_send_message",
     ch: "wa",
@@ -1529,7 +1563,7 @@ const TOOLS = [
   {
     name: "li_scheduled_posts",
     path: "/li/scheduled_posts",
-    description: "List this authenticated user's scheduled LinkedIn posts and their current states.",
+    description: "Read the shared LinkedIn content calendar from SignalDash and the configured Buffer channel. Always inspect completeness and per-source state. Native LinkedIn scheduled posts and drafts are NOT visible because Unipile has no documented read route for them, and SignalDash does not use raw Voyager routes or linkedin.com browser access. An empty items array is never proof that the native LinkedIn calendar is empty.",
     inputSchema: { type: "object", properties: {}, additionalProperties: false },
   },
   {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@floomhq/signaldash",
-  "version": "0.36.0",
+  "version": "0.38.0",
   "description": "Secure LinkedIn, WhatsApp, and email access for AI agents",
   "type": "module",
   "bin": {
@@ -18,7 +18,7 @@
   },
   "scripts": {
     "test": "node --test",
-    "check": "node --check bin/sd.mjs && node --check server/server.cjs && node --check server/composio-email.cjs && node --check server/attachments.cjs && node --check server/write-control.cjs && node --check server/secretary-store.cjs && node --check server/secretary-collector.cjs && node --check server/secretary-latest.cjs && node --check server/secretary-approvals.cjs && node --check server/secretary-push.cjs && node --check server/secretary-rules.cjs && node --check server/secretary-shadow-gate.cjs && node --check server/secretary-vault-importer.cjs && node --check server/secretary-inspiration.cjs && node --check server/linkedin-archive-importer.cjs && node --check server/voice-profile.cjs && node --check server/campaign-store.cjs && node --check server/campaign-runner.cjs && node --check server/withdrawal-store.cjs && node --check server/post-scheduler.cjs && node --check server/message-scheduler.cjs && node --check scripts/import-linkedin-archive.mjs && node --check scripts/import-secretary-vault-snapshot.mjs && node --check scripts/rebuild-secretary-actors.mjs && node --check scripts/extract-conversation-inspiration.mjs && node --check bin/signaldash.js && node --check lib/cli.js && node --check lib/config-file.js && node --check lib/mcp.js && node --check lib/rate-guard.js && node --check lib/secrets.js && node --check lib/unipile.js"
+    "check": "node --check bin/sd.mjs && node --check server/server.cjs && node --check server/buffer-calendar.cjs && node --check server/composio-email.cjs && node --check server/attachments.cjs && node --check server/write-control.cjs && node --check server/secretary-store.cjs && node --check server/secretary-collector.cjs && node --check server/secretary-latest.cjs && node --check server/secretary-approvals.cjs && node --check server/secretary-push.cjs && node --check server/secretary-rules.cjs && node --check server/secretary-shadow-gate.cjs && node --check server/secretary-vault-importer.cjs && node --check server/secretary-inspiration.cjs && node --check server/linkedin-archive-importer.cjs && node --check server/voice-profile.cjs && node --check server/campaign-store.cjs && node --check server/campaign-runner.cjs && node --check server/withdrawal-store.cjs && node --check server/post-scheduler.cjs && node --check server/message-scheduler.cjs && node --check scripts/import-linkedin-archive.mjs && node --check scripts/import-secretary-vault-snapshot.mjs && node --check scripts/rebuild-secretary-actors.mjs && node --check scripts/extract-conversation-inspiration.mjs && node --check bin/signaldash.js && node --check lib/cli.js && node --check lib/config-file.js && node --check lib/mcp.js && node --check lib/rate-guard.js && node --check lib/secrets.js && node --check lib/unipile.js"
   },
   "keywords": [
     "mcp",

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", "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.
+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", "start a chat", "create a group chat", "introduce these people", "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, exact human-approved direct and group chat creation, 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
@@ -375,6 +375,7 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `li_list_chats` | `limit` integer 1-100, default 20; `cursor` optional; `search` optional string, max 200 characters; `max_scan` optional integer 1-500; `unread` optional boolean | Find recent LinkedIn chats, unread counts, and exact `chat_id` values. `unread:true` is forwarded to the provider as `unread=true`; SignalDash does not fetch a full chat page and filter it locally. Search accepts a unique stored display name, exact `public_id`, member id, or ordinary chat field. A stored name/public id is resolved to its verified member id before matching, so a provider row with `name:null` remains findable. Without an explicit `max_scan`, a zero-match search extends from 200 up to a hard 500-chat/five-page bound; explicit bounds remain exact. Read `scanned_chats`, `pages_fetched`, `scan_limit`, and `exhaustive` before concluding absence. The response also reports any resolved public/member ids. 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. The response includes `current_watermark`, the resolved `chat`, and `sender_name` on each message where the exact sender identity can be resolved. |
 | `li_mark_read` | `chat_id` required | Explicitly clear one LinkedIn chat's unread state. Reading never clears unread automatically. |
+| `li_start_chat` | `member_ids` required array of 1-10 exact `ACo`, `ACw`, or `AE` provider member IDs; `text` required exact first message; `confirm`, `approval_hash`, and `dry_run:true` apply only after preview | Start one direct or group chat. Preview first, show the complete member-ID set and exact text, then repeat that exact payload with the returned approval hash only after explicit approval. SignalDash resolves every member live, blocks protected or suppressed contacts, returns an existing exact member-set chat without sending, and charges one thread-message plus aggregate action for a new chat regardless of member count. `dry_run:true` proves the full path up to the provider write without consuming approval or budget. |
 | `li_send_message` | Manual path: `chat_id` and `text` required; `expected_watermark` optional exact 64-character watermark; `mark_read` optional boolean. Secretary path: `secretary_receipt_id` alone. | Send one approved LinkedIn reply after an immediate read of that exact chat. A Secretary receipt derives the exact stored chat and text and refuses every caller-supplied override. |
 | `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. |
@@ -382,7 +383,7 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `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_budget_status` | no arguments | Read the current sender binding, separate invitation, existing-thread message, and own-post engagement daily lanes, the aggregate emergency brake, 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. |
@@ -393,7 +394,7 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `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_preview` | `campaign_id` required | Inspect every exact recipient, every exclusion and reason, the exact text of every message step, the timing, the invitation and existing-thread message lanes, the aggregate brake, 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. |
@@ -406,6 +407,7 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `wa_mark_read` | `chat_id` required | Explicitly clear one WhatsApp chat's unread state. Reading never clears unread automatically. |
 | `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_start_chat` | `member_ids` required array of 1-10 exact `@s.whatsapp.net` or `@lid` provider member IDs; `text` required exact first message; `confirm`, `approval_hash`, and `dry_run:true` apply only after preview | Start one direct or group chat under the same exact approval, live member resolution, protected-contact, duplicate-set, and readback contract as LinkedIn. If an `@lid` resolves to another canonical ID, repeat the preview with the returned `resolved_member_id`; SignalDash never substitutes an unapproved identity. A new chat spends one WhatsApp/email send action regardless of member count. An existing exact member-set chat is returned without sending. |
 | `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; `expected_watermark` optional exact 64-character watermark; `mark_read` optional boolean, default false | Send one approved reply, one approved file, or both, in an existing WhatsApp conversation after an immediate re-read. Own outbound additions do not invalidate the read; inbound additions or mutations return `new_messages`, `changed_kind`, and `current_watermark`. Pass `expected_watermark` to bind the send to the exact reviewed state and `mark_read:true` only when the approved workflow also calls for clearing unread after the confirmed send. 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. A re-read failure remains `502 thread_preflight_unavailable`, and a legacy proof with no watermark remains `428 read_before_send_required`; neither costs send budget. 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. |
@@ -421,7 +423,7 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `li_delete_comment` | `post_id`, `comment_id`, and `confirm:true` required | Currently unavailable: the fixture-tested Unipile v2 wrapper is held at database capability state `untested` until live compatibility is proved against Federico's own removable comment. When enabled it proves own comment identity and readback. Deletion is remediation, not rollback. |
 | `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_scheduled_posts` | no arguments | Read one shared content-calendar view across SignalDash and the configured Buffer LinkedIn channel. Inspect `completeness` and every `sources.*.state` before treating absence as an empty calendar. Native LinkedIn scheduled posts and drafts are invisible because Unipile has no documented read route for them; SignalDash does not use raw Voyager routes or linkedin.com browser access. An empty `items` array proves only that the visible sources returned no entries. |
 | `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. |
@@ -436,6 +438,7 @@ sd_secretary_push_set({"enabled":false,"confirm":true})
 sd_inspiration_list({})
 li_list_chats({"limit":20})
 li_read_messages({"chat_id":"chat_li_7f3a","limit":20})
+li_start_chat({"member_ids":["ACoAAExactMemberOne","ACoAAExactMemberTwo"],"text":"Amina, meet Jo. I think you two have a lot to compare."})
 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})
@@ -467,6 +470,7 @@ 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_start_chat({"member_ids":["4915111111111@s.whatsapp.net","202700000000000@lid"],"text":"Amina, meet Jo. I think you two have a lot to compare."})
 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"})
@@ -510,7 +514,11 @@ permission to publish or schedule. For a future post, first call
 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
+record with `li_scheduled_posts`. Before scheduling, read that shared view and
+inspect its `completeness` plus the SignalDash, Buffer, and native LinkedIn
+source states. A date conflict in either visible source blocks planning until
+the human resolves it. Native LinkedIn remains explicitly blind, so never call
+an empty result an empty calendar. 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
@@ -553,14 +561,24 @@ with `confirm:true`. Allowed reasons are `opt_out`, `not_interested`,
 manual LinkedIn work or any campaign action. It reports attempts that
 SignalDash has committed in its authoritative SQLite ledger:
 
-- the total daily cap (`H`);
+- invitations, including accept and single-object withdrawal maintenance;
+- messages into existing threads;
+- replies, reactions, publishing, and first comments on the sender's own posts;
+- the aggregate daily emergency brake (`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;
+- raw per-lane, aggregate, 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.
 
+The code defaults are 20 invitation actions, 30 existing-thread messages, and
+50 own-post engagement actions per UTC day. A separate aggregate cap of 75 is
+the emergency brake across them. The three lane caps do not add into a promise
+of 100 actions. Every lane still uses the same serialized provider queue and
+its existing action-specific randomized pacing. The default 100-attempt UTC
+week for sent invitations remains separate and unchanged.
+
 `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
@@ -1270,10 +1288,14 @@ 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 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.
+The hosted backend defaults to three LinkedIn lanes per stable logical sender
+and UTC day: 20 invitation actions, 30 messages in existing threads, and 50
+own-post engagement actions. An aggregate 75-attempt emergency brake bounds the
+combined lanes. Invitation sends also use the unchanged default 100-attempt
+weekly policy. Separate counters do not alter randomized action spacing, the
+single serialized provider queue, duplicate protection, or provider-warning
+locks. An exact comment reply text already submitted by that sender on the same
+UTC day is refused as `duplicate_comment_text`.
 
 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
@@ -1750,8 +1772,10 @@ Before reporting completion, verify:
 - No sender lock or `outcome_unknown` result was retried.
 - A send was confirmed by a post-send read.
 - 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.
+  explicitly approved. The shared calendar was read first, its source-specific
+  completeness was reported, and every visible scheduled post was read back
+  with its exact UTC instant, source, and durable state. Native LinkedIn
+  blindness was never represented as an empty calendar.
 - An export ended with `+ saved` and a non-empty CSV.
 
 If any item is unverified, state exactly what remains incomplete.

package/skills/signaldash-safe-usage/SKILL.md

@@ -77,15 +77,20 @@ On no, call `sd_secretary_reject` for that exact disposition and send nothing.
   Inspect `already_in_contact`, `contact_state`, and `blocking_reasons`.
   Resolve, review, and approve every later action through its one-object flow.
 - Read `sd_budget_status` before planning multiple LinkedIn actions. Treat its
-  campaign-excluded portion as capacity campaigns cannot consume, never as a
-  reserved or guaranteed manual allowance. Its counts cover SignalDash
-  attempts, not all native LinkedIn activity.
-- Keep normal messaging at human volume. Use the cap reported in each hosted
-  response; LinkedIn messages, invitations, invitation maintenance, and post
-  publishing share the stable sender's daily action budget.
+  invitation, existing-thread message, and own-post engagement lanes
+  separately. Treat the aggregate cap and campaign-excluded portion as brakes,
+  never as a promised allowance. Its counts cover SignalDash attempts, not all
+  native LinkedIn activity.
+- Keep normal messaging at human volume. Code defaults are 20 invitation
+  actions, 30 existing-thread messages, 50 own-post engagement actions, and a
+  75-attempt aggregate brake per UTC day. The unchanged sent-invitation policy
+  also caps attempts at 100 per UTC week.
 - Let SignalDash serialize LinkedIn writes and apply action-specific jitter. Do
   not parallelize write calls or bypass the guard. Invitation jitter completes
   before the server's final provider preflight and action reservation.
+- Never reuse exact comment reply text during the same UTC day. SignalDash
+  refuses it as `duplicate_comment_text`; changing punctuation only to evade
+  that guard is prohibited.
 - Campaign invitations use a sender-local Monday-Friday 09:00-17:00 work
   window and a durable 90-180 second per-sender pacing interval. Timing is
   checked before final preflight and atomically during action reservation.