@floomhq/signaldash 0.31.0 → 0.32.2

package/README.md

@@ -96,11 +96,13 @@ the same logged-in user.
 The canonical [`signaldash` skill](skills/signaldash/SKILL.md) teaches an agent
 when to use SignalDash, how to persist the skill, complete setup, interpret
 connection state, operate every tool, handle server guards, and run safe worked
-flows. The one-command setup installs the skill from the same pinned npm package
+flows. The thin [`secretary` skill](skills/secretary/SKILL.md) renders the
+stored `latest` result as one table and has no write authority. The one-command
+setup installs both from the same pinned npm package
 the human chose to execute:
 
 ```bash
-npx -y @floomhq/signaldash@0.31.0 <invite-code>
+npx -y @floomhq/signaldash@0.32.2 <invite-code>
 ```
 
 Run that command in a terminal, not in an agent chat. Do not ask an agent to
@@ -117,9 +119,14 @@ available for clients that separate operating and send-safety instructions.
 
 SignalDash exposes:
 
+- `sd_version()`
+- `sd_secretary_latest(limit?, continuation?, ack_token?)`
+- `sd_secretary_approve(disposition_id, payload_hash, confirm)`
+- `sd_secretary_reject(disposition_id, confirm)`
 - `li_list_chats`
 - `li_read_messages(chat_id)`
-- `li_send_message(chat_id, text)`
+- `li_mark_read(chat_id)`
+- `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?)`
 - `li_accept_invitation(invitation_id, confirm)`
@@ -147,17 +154,21 @@ SignalDash exposes:
 - `sd_withdrawal_batch_cancel(withdrawal_batch_id, approval_view_hash, confirm)`
 - `wa_list_chats`
 - `wa_read_messages(chat_id)`
+- `wa_mark_read(chat_id)`
 - `wa_get_attachment(chat_id, message_id, attachment_id)`
 - `wa_transcribe_voice(chat_id, message_id, attachment_id)`
-- `wa_send_message(chat_id, text?, attachments?)`
+- `wa_send_message(chat_id, text?, attachments?, expected_watermark?, mark_read?)`
 - `wa_delete_message(chat_id, message_id)`
 - `wa_delete_messages(messages)`
 - `email_list(limit)`
 - `email_read(thread_id, limit)`
 - `email_send(to, subject, body)`
 - `li_my_posts(limit, member_id)`
-- `li_post_reactions(post_id, limit)`
-- `li_post_comments(post_id, limit)`
+- `li_post_reactions(post_id, limit, cursor?)`
+- `li_post_comments(post_id, comment_id?, limit, cursor?)`
+- `li_reply_to_comment(post_id?, parent_comment_id?, trigger_comment_id?, text?, expected_watermark?, secretary_receipt_id?)`
+- `li_delete_message(chat_id, message_id, confirm)`
+- `li_delete_comment(post_id, comment_id, confirm)`
 - `li_draft_post(text, publish, scheduled_at?, mentions?, attachments?, first_comment?)`
 - `li_set_scheduled_post_first_comment(id, first_comment, confirm)`
 - `li_scheduled_posts()`
@@ -169,6 +180,24 @@ SignalDash exposes:
 Every operation runs through the hosted SignalDash backend. Agents never
 receive the Unipile access key.
 
+`li_reply_to_comment` acts only on an inbound comment on the authenticated
+sender's own post. A preceding `li_post_comments` read records an exact
+per-comment watermark. Immediately before the write, SignalDash re-proves the
+post owner, sender generation, trigger author, unchanged trigger, parent
+thread, absence of an own duplicate, action budget and sender health. A
+provider 2xx remains `outcome_unknown` until bounded readback finds exactly one
+own reply with the returned reply ID, expected parent and exact text.
+
+LinkedIn deletion is remediation after exposure, not rollback. It never
+relaxes a send or Secretary gate. `li_delete_message` is limited to the first
+60 minutes after the provider send timestamp and proves exact account, chat,
+message and own authorship before using a separate remediation budget. It
+marks success only after a readback proves the message absent. The v2
+`li_delete_comment` wrapper is installed behind the database capability flag
+`linkedin_comment_delete`, whose migration default is `untested`. It is not an
+available live capability until an exact removable comment on Federico's own
+post passes compatibility testing and the flag is separately enabled.
+
 A WhatsApp message can carry files. `wa_send_message` takes up to 4 exact
 `{filename, content_type, content_base64}` attachments, at most 16 MiB per file
 and 16 MiB per message, and accepts PNG, JPEG, WebP, GIF, PDF, CSV, plain text,
@@ -182,16 +211,23 @@ oversized attachment costs no send budget and never reaches the provider, and
 every refusal names the exact rule and the exact file that tripped it. Nothing
 is ever truncated or dropped silently. LinkedIn messages carry text only, and
 `li_send_message` refuses an `attachments` argument instead of ignoring it.
+For a Secretary draft, `sd_secretary_approve` creates one 15-minute receipt
+bound to the exact stored sender generation, recipient, thread, and text.
+`li_send_message` then accepts that receipt ID alone, derives the payload from
+storage, refuses caller-supplied overrides, and consumes the receipt atomically
+with the action reservation. Rejection records a new human disposition and
+sends nothing.
 
 A recent read is no longer sufficient on its own. A message send re-reads the
-thread immediately before sending and refuses with `409 thread_changed` unless
-it is still the exact thread that was read, which is the guard LinkedIn has
-always had and WhatsApp did not: a 30-minute read window is satisfied just as
-comfortably by a conversation that moved 29 minutes ago as by one nobody has
-touched, and a reply that arrived in between is precisely when a draft stops
-being the right thing to send. The comparison is a hash over the page that was
-read, taken at the same item limit, so the re-read has to match message for
-message. A chat whose most recent read predates this guard carries no such hash
+thread immediately before sending. A counterparty message or a mutation after
+the read refuses with `409 thread_changed`; an addition consisting only of this
+account's own outbound messages does not invalidate the draft. The 409 includes
+`new_messages`, `changed_kind`, and `current_watermark`, and both send tools
+accept optional `expected_watermark` to bind a retry to the exact state the
+caller reviewed. A 30-minute read window is satisfied just as comfortably by a
+conversation that moved 29 minutes ago as by one nobody has touched, and a
+reply that arrived in between is precisely when a draft stops being the right
+thing to send. A chat whose most recent read predates this guard carries no hash
 and is refused with `428 read_before_send_required` until it is read again,
 rather than waved through on a timestamp that cannot answer the question. If the
 re-read itself fails, the send is refused with
@@ -419,6 +455,31 @@ resume exactly those. WhatsApp applies its own time and role limits to deleting
 for everyone and can answer successfully without removing anything, so re-read
 the chat to confirm.
 
+## Deploying server changes
+
+A server change is not landed when only the files on disk changed. After the
+change is merged to `main`, update the production checkout, restart the
+long-running backend, and compare the live MCP result with the checked-out
+commit:
+
+```bash
+git pull --ff-only origin main
+git rev-parse HEAD
+sudo systemctl restart signaldash-api.service
+sudo systemctl is-active signaldash-api.service
+```
+
+Then call `sd_version({})` from an authenticated MCP session. Its `commit_sha`
+must equal `git rev-parse HEAD`, and its `process_started_at` must be later than
+the restart. The startup journal contains the same snapshot under the
+`[signaldash] startup` prefix. A mismatch means the deployment is stale and the
+server change is not shipped. `dirty_at_start` includes tracked changes,
+untracked files, and submodule state present when the process started.
+
+`SIGNALDASH_VERSION_ENABLED=0` removes the version route at runtime after a
+service restart. It defaults to enabled and exposes no credential, account, or
+message data.
+
 ## Releasing
 
 A release is a tag push. `.github/workflows/release.yml` runs `./release.sh` on
@@ -471,6 +532,32 @@ npm run check
 npm pack --dry-run
 ```
 
+### Offline LinkedIn archive import
+
+The server-side importer reads LinkedIn export directories or ZIP files without
+making provider requests. Preview the exact file fingerprints and row counts,
+then apply the same archive to one bound LinkedIn sender generation:
+
+```bash
+node scripts/import-linkedin-archive.mjs \
+  --archive /path/to/Complete_LinkedInDataExport \
+  --database server/sd-state-control.sqlite3 \
+  --sender-account <exact-sender-account-id> \
+  --owner-profile-url https://www.linkedin.com/in/<exact-owner-public-id>/ \
+  --dry-run
+
+node scripts/import-linkedin-archive.mjs \
+  --archive /path/to/Complete_LinkedInDataExport \
+  --database server/sd-state-control.sqlite3 \
+  --sender-account <exact-sender-account-id> \
+  --owner-profile-url https://www.linkedin.com/in/<exact-owner-public-id>/ \
+  --apply
+```
+
+The owner profile URL is required when `messages.csv` is present. It is the
+typed identity used to classify inbound and outbound rows. A display name is
+never used for that decision.
+
 `wa_transcribe_voice` runs on the SignalDash host and has two backends. The
 default, `gemini`, sends the audio to Vertex AI using that host's own
 credentials; it is the one that survives German speech with English technical

package/bin/sd.mjs

@@ -298,18 +298,72 @@ export async function cmdClaim(provider, accountId, dependencies = {}) {
 
 // ---- MCP (stdio). Every tool proxies through the backend with the token. ----
 const TOOLS = [
+  {
+    name: "sd_version",
+    path: "/sd/version",
+    description: "Report the exact SignalDash backend commit, working-tree state, process start time, and package version captured when the serving process started.",
+    inputSchema: {
+      type: "object",
+      properties: {},
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "sd_secretary_latest",
+    path: "/sd/secretary/latest",
+    description: "Read stored Secretary signals with zero provider calls. Render rows and the ignored aggregate as one table. On the next call, pass the previous ack_token; pass next as continuation when it is non-null.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        limit: { type: "integer", minimum: 1, maximum: 100, default: 50 },
+        continuation: { type: "string", minLength: 1, maxLength: 4096 },
+        ack_token: { type: "string", minLength: 1, maxLength: 4096 },
+      },
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "sd_secretary_approve",
+    path: "/sd/secretary/approve",
+    description: "Approve one exact stored Secretary draft. Pass only the disposition_id and payload_hash returned by sd_secretary_latest plus confirm:true. The result is a single-use 15-minute receipt.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        disposition_id: { type: "string", minLength: 1, maxLength: 200 },
+        payload_hash: { type: "string", pattern: "^[0-9a-f]{64}$" },
+        confirm: { type: "boolean", const: true },
+      },
+      required: ["disposition_id", "payload_hash", "confirm"],
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "sd_secretary_reject",
+    path: "/sd/secretary/reject",
+    description: "Reject one exact current stored Secretary draft and create a durable rejected disposition. Sends nothing.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        disposition_id: { type: "string", minLength: 1, maxLength: 200 },
+        confirm: { type: "boolean", const: true },
+      },
+      required: ["disposition_id", "confirm"],
+      additionalProperties: false,
+    },
+  },
   {
     name: "li_list_chats",
     ch: "li",
     action: "list_chats",
-    description: "List or search your LinkedIn chats. `search` filters on identifiers, never on a person name (a 1:1 chat has no name); the response reports how far it scanned.",
+    description: "List or search your LinkedIn chats by display name, public_id, member id, or chat fields. Pass unread:true to make the provider return unread chats only. A unique stored connection name or exact public_id is resolved to its verified LinkedIn member id before matching. A zero-match default search continues from 200 up to a hard 500-chat/five-page bound and reports the exact scan depth.",
     inputSchema: {
       type: "object",
       properties: {
         limit: { type: "integer", minimum: 1, maximum: 100, description: "How many chats to return. With `search`, how many MATCHES to return." },
         cursor: { type: "string", maxLength: 4000, description: "Continue from a previous page or a previous search." },
-        search: { type: "string", minLength: 1, maxLength: 200, description: "Filter chats on name and counterpart identifiers. The provider cannot filter a chat list, so SignalDash filters over a bounded scan and the response reports `scanned_chats` and `exhaustive` so a miss is never mistaken for a proven absence. A 1:1 chat has no name, so search by identifier or phone number, not by person name." },
-        max_scan: { type: "integer", minimum: 1, maximum: 500, description: "How many chats the search may scan before it stops and reports exhaustive:false. Default 200, and never more than five provider pages: bulk reading is the top account-restriction trigger, so go deeper with the returned cursor rather than with a bigger scan." },
+        search: { type: "string", minLength: 1, maxLength: 200, description: "Filter chats on a unique stored connection display name, exact LinkedIn public_id, verified member id, or chat fields. SignalDash resolves a stored name/public_id to its member id before the bounded chat scan." },
+        max_scan: { type: "integer", minimum: 1, maximum: 500, description: "Explicit scan bound. Without it, SignalDash scans 200 chats and, only after zero matches with more pages available, continues up to 500. Every search is capped at five provider pages and reports the real depth." },
+        unread: { type: "boolean", description: "Ask the LinkedIn provider for unread chats only. true is forwarded as unread=true; omitted or false does not apply the provider filter." },
       },
       additionalProperties: false,
     },
@@ -318,7 +372,7 @@ const TOOLS = [
     name: "li_read_messages",
     ch: "li",
     action: "read",
-    description: "Read messages in a LinkedIn chat. args: chat_id",
+    description: "Read messages and the resolved chat in one LinkedIn thread. Messages include sender_name where the exact sender can be resolved. args: chat_id",
     inputSchema: {
       type: "object",
       properties: {
@@ -329,18 +383,34 @@ const TOOLS = [
       additionalProperties: false,
     },
   },
+  {
+    name: "li_mark_read",
+    ch: "li",
+    action: "mark_read",
+    description: "Explicitly clear the unread state of one account-scoped LinkedIn chat. Reading a thread never clears it automatically.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        chat_id: { type: "string", minLength: 1, maxLength: 500 },
+      },
+      required: ["chat_id"],
+      additionalProperties: false,
+    },
+  },
   {
     name: "li_send_message",
     ch: "li",
     action: "send",
-    description: "Send a LinkedIn message (rate-safe). args: chat_id, text",
+    description: "Send a LinkedIn message (rate-safe). For a manual send, pass chat_id and text after reading the exact thread. For an approved Secretary draft, pass secretary_receipt_id alone; recipient and text are derived from storage and any override is refused. Own outbound messages added after a read do not invalidate the draft, but a counterparty message or mutation returns 409 thread_changed.",
     inputSchema: {
       type: "object",
       properties: {
         chat_id: { type: "string", minLength: 1, maxLength: 500 },
         text: { type: "string", minLength: 1, maxLength: 5000 },
+        expected_watermark: { type: "string", minLength: 64, maxLength: 64, pattern: "^[0-9a-f]{64}$", description: "Bind the send to the exact current_watermark returned by the read or a thread_changed response." },
+        mark_read: { type: "boolean", default: false, description: "After a confirmed successful send, explicitly clear this chat's unread state." },
+        secretary_receipt_id: { type: "string", minLength: 1, maxLength: 200, description: "Single-use receipt from sd_secretary_approve. Pass this field alone." },
       },
-      required: ["chat_id", "text"],
       additionalProperties: false,
     },
   },
@@ -555,7 +625,7 @@ const TOOLS = [
   {
     name: "li_search_connections",
     path: "/li/connections/search",
-    description: "Search only your locally stored LinkedIn connections by name, headline, or company and join exact local contact state. Makes zero LinkedIn, Unipile, or paid discovery API calls.",
+    description: "Search only your locally stored LinkedIn connections by name, headline, or company. Returns both public_id and the stable LinkedIn member_id when known, plus exact local contact and known-chat state. Makes zero LinkedIn, Unipile, or paid discovery API calls.",
     inputSchema: {
       type: "object",
       properties: {
@@ -969,13 +1039,13 @@ const TOOLS = [
     name: "wa_list_chats",
     ch: "wa",
     action: "list_chats",
-    description: "List or search your WhatsApp chats. `search` matches the phone number (chats carry it as attendee_public_identifier), not a person name; the response reports how far it scanned.",
+    description: "List or search your WhatsApp chats. Resolved 1:1 chats expose the contact in both name and attendee_name; unresolved names stay null. A search reports exactly how far it scanned.",
     inputSchema: {
       type: "object",
       properties: {
         limit: { type: "integer", minimum: 1, maximum: 100, description: "How many chats to return. With `search`, how many MATCHES to return." },
         cursor: { type: "string", maxLength: 4000, description: "Continue from a previous page or a previous search." },
-        search: { type: "string", minLength: 1, maxLength: 200, description: "Filter chats on name and counterpart identifiers. The provider cannot filter a chat list, so SignalDash filters over a bounded scan and the response reports `scanned_chats` and `exhaustive` so a miss is never mistaken for a proven absence. A 1:1 chat has no name, so search by identifier or phone number, not by person name." },
+        search: { type: "string", minLength: 1, maxLength: 200, description: "Filter chats on resolved name and counterpart identifiers. The provider cannot filter a chat list, so SignalDash filters over a bounded scan and the response reports `scanned_chats` and `exhaustive` so a miss is never mistaken for a proven absence. Search by the exact phone number when a 1:1 name remains unresolved." },
         max_scan: { type: "integer", minimum: 1, maximum: 500, description: "How many chats the search may scan before it stops and reports exhaustive:false. Default 200, and never more than five provider pages: bulk reading is the top account-restriction trigger, so go deeper with the returned cursor rather than with a bigger scan." },
       },
       additionalProperties: false,
@@ -985,7 +1055,7 @@ const TOOLS = [
     name: "wa_read_messages",
     ch: "wa",
     action: "read",
-    description: "Read messages in a WhatsApp chat. args: chat_id",
+    description: "Read messages and the resolved chat in one WhatsApp thread. Messages include sender_name where the exact sender can be resolved. args: chat_id",
     inputSchema: {
       type: "object",
       properties: {
@@ -996,6 +1066,20 @@ const TOOLS = [
       additionalProperties: false,
     },
   },
+  {
+    name: "wa_mark_read",
+    ch: "wa",
+    action: "mark_read",
+    description: "Explicitly clear the unread state of one account-scoped WhatsApp chat. Reading a thread never clears it automatically.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        chat_id: { type: "string", minLength: 1, maxLength: 500 },
+      },
+      required: ["chat_id"],
+      additionalProperties: false,
+    },
+  },
   {
     name: "wa_get_attachment",
     path: "/wa/get_attachment",
@@ -1031,7 +1115,7 @@ const TOOLS = [
     name: "wa_send_message",
     ch: "wa",
     action: "send",
-    description: "Send a WhatsApp message (rate-safe). args: chat_id, text, attachments. Read the chat first: a send into a thread this account has not read recently is refused. The send re-reads the thread immediately before sending and refuses with `409 thread_changed` if the conversation moved after that read, because a draft written against the old thread may now be deaf or wrong; re-read, revise, and send again. A re-read that fails is `502 thread_preflight_unavailable` and nothing was sent. `attachments` optionally carries up to 4 base64 files as exact {filename, content_type, content_base64} objects, at most 16 MiB per file and 16 MiB per message, and accepts images, PDF, CSV, plain text, JSON, xlsx and zip. `text` is the caption and may be omitted when a file is attached, but a call carrying neither text nor an attachment is refused. An attachment send is rate-limited, deduplicated and recorded exactly like a text send, and spends the same daily budget. If a send times out or the provider never confirms it, the message may still have been delivered: SignalDash records it and refuses an identical retry with `409 send_outcome_unknown`. Read the chat, and only if the message is genuinely absent, resend the identical payload with `confirm_resend:true`.",
+    description: "Send a WhatsApp message (rate-safe). args: chat_id, text, attachments, expected_watermark, mark_read. Read the chat first: the read returns current_watermark and a send into a thread this account has not read recently is refused. Own outbound messages added after that read do not invalidate the draft, but a counterparty message or mutation returns 409 thread_changed with new_messages, changed_kind, and current_watermark. Optional expected_watermark binds the send to that exact reviewed state. A re-read that fails is 502 thread_preflight_unavailable and nothing was sent. attachments optionally carries up to 4 base64 files as exact {filename, content_type, content_base64} objects, at most 16 MiB per file and 16 MiB per message, and accepts images, PDF, CSV, plain text, JSON, xlsx and zip. text is the caption and may be omitted when a file is attached, but a call carrying neither text nor an attachment is refused. Optional mark_read:true explicitly clears unread only after the send is confirmed. An attachment send is rate-limited, deduplicated and recorded exactly like a text send, and spends the same daily budget. If a send times out or the provider never confirms it, the message may still have been delivered: SignalDash records it and refuses an identical retry with 409 send_outcome_unknown. Read the chat, and only if the message is genuinely absent, resend the identical payload with confirm_resend:true.",
     inputSchema: {
       type: "object",
       properties: {
@@ -1064,6 +1148,8 @@ const TOOLS = [
           },
         },
         confirm_resend: { type: "boolean", const: true },
+        expected_watermark: { type: "string", minLength: 64, maxLength: 64, pattern: "^[0-9a-f]{64}$", description: "Bind the send to the exact current_watermark returned by the read or a thread_changed response." },
+        mark_read: { type: "boolean", default: false, description: "After a confirmed successful send, explicitly clear this chat's unread state." },
       },
       // `text` alone is no longer required: a document with no caption is a
       // legitimate message.
@@ -1188,7 +1274,7 @@ const TOOLS = [
   {
     name: "li_my_posts",
     path: "/li/posts",
-    description: "List the user's own LinkedIn posts with engagement counts (reactions, comments, impressions). args: limit",
+    description: "List LinkedIn posts with engagement counts (reactions, comments, impressions). Use each row's exact social_id, not a different numeric id, with li_post_reactions and li_post_comments.",
     inputSchema: {
       type: "object",
       properties: {
@@ -1201,12 +1287,13 @@ const TOOLS = [
   {
     name: "li_post_reactions",
     path: "/li/post_reactions",
-    description: "Who reacted to a post — name + headline. These are warm inbound signals. args: post_id, limit",
+    description: "Read one bounded page of people who reacted to a post. Pass the exact social_id returned by li_my_posts (including urn:li:ugcPost:... for multi-image posts); a numeric id is resolved against your own recent posts when possible. Read completeness.state, completeness.total, and completeness.next_cursor before treating the list as complete, then pass cursor to continue. The true total comes from the provider response when available; SignalDash does not invent one from li_my_posts. Reactions are signals only and do not authorize outreach.",
     inputSchema: {
       type: "object",
       properties: {
         post_id: { type: "string", minLength: 1, maxLength: 500 },
         limit: { type: "integer", minimum: 1, maximum: 100 },
+        cursor: { type: "string", minLength: 1, maxLength: 4000 },
       },
       required: ["post_id"],
       additionalProperties: false,
@@ -1215,17 +1302,66 @@ const TOOLS = [
   {
     name: "li_post_comments",
     path: "/li/post_comments",
-    description: "Comments on a post, with author. args: post_id, limit",
+    description: "Read one bounded page of comments and authors on a post. Pass comment_id to read replies to that exact parent comment. Pass the exact social_id returned by li_my_posts; a numeric id is resolved against your own recent posts when possible. Read completeness.state, completeness.total, and completeness.next_cursor before treating the list as complete, then pass cursor to continue. The true total comes from the provider response when available; SignalDash never guesses it from li_my_posts.",
     inputSchema: {
       type: "object",
       properties: {
         post_id: { type: "string", minLength: 1, maxLength: 500 },
+        comment_id: { type: "string", minLength: 1, maxLength: 500, description: "Optional exact parent comment id. When present, returns replies to that comment." },
         limit: { type: "integer", minimum: 1, maximum: 100 },
+        cursor: { type: "string", minLength: 1, maxLength: 4000 },
       },
       required: ["post_id"],
       additionalProperties: false,
     },
   },
+  {
+    name: "li_reply_to_comment",
+    path: "/li/reply_to_comment",
+    description: "Reply once to one exact inbound comment on the authenticated sender's own LinkedIn post. First read li_post_comments and preserve the exact post_id, parent_comment_id, trigger_comment_id, text, and returned signaldash_watermark. SignalDash re-proves post ownership, trigger identity and content, absence of an own duplicate, sender generation, budget, and provider safety immediately before writing. A 2xx is not success until bounded readback finds exactly one own reply. A Secretary approval uses secretary_receipt_id alone.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        post_id: { type: "string", minLength: 1, maxLength: 500 },
+        parent_comment_id: { type: "string", minLength: 1, maxLength: 500 },
+        trigger_comment_id: { type: "string", minLength: 1, maxLength: 500 },
+        text: { type: "string", minLength: 1, maxLength: 1250 },
+        expected_watermark: { type: "string", pattern: "^[0-9a-f]{64}$" },
+        secretary_receipt_id: { type: "string", minLength: 1, maxLength: 500 },
+      },
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "li_delete_message",
+    path: "/li/delete_message",
+    description: "Remediate one exact LinkedIn message sent by this authenticated account, only within the provider's 60-minute window. Requires exact chat and message identity plus confirm:true. SignalDash proves chat ownership, exact-chat membership, own authorship, timestamp eligibility, a separate remediation budget, and post-delete absence. Deletion cannot undo prior delivery, reading, or notifications and does not weaken any send gate.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        chat_id: { type: "string", minLength: 1, maxLength: 500 },
+        message_id: { type: "string", minLength: 1, maxLength: 500 },
+        confirm: { type: "boolean", const: true },
+      },
+      required: ["chat_id", "message_id", "confirm"],
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "li_delete_comment",
+    path: "/li/delete_comment",
+    description: "UNTESTED AND DISABLED by the database capability flag. The guarded Unipile v2 wrapper is fixture-tested but is unavailable until live compatibility is proved against the authenticated sender's own removable comment. When enabled it requires exact post_id, comment_id, confirm:true, own-comment proof, a separate remediation budget, and post-delete readback. Deletion is remediation, not rollback.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        post_id: { type: "string", minLength: 1, maxLength: 500 },
+        comment_id: { type: "string", minLength: 1, maxLength: 500 },
+        confirm: { type: "boolean", const: true },
+      },
+      required: ["post_id", "comment_id", "confirm"],
+      additionalProperties: false,
+    },
+  },
   {
     name: "li_draft_post",
     path: "/li/create_post",
@@ -1408,20 +1544,23 @@ export async function cmdSkill(dependencies = {}) {
   const { mkdirSync: mk, writeFileSync: wf, readFileSync: rf, existsSync: ex } = await import("node:fs");
   const { dirname, join } = await import("node:path");
   const here = dirname(fileURLToPath(import.meta.url));
-  const src = join(here, "..", "skills", "signaldash", "SKILL.md");
-  if (!ex(src)) { log("skill file not found in package"); process.exitCode = 1; return; }
-  const dest = join(homedir(), ".claude", "skills", "signaldash");
-  mk(dest, { recursive: true });
+  const skills = ["signaldash", "secretary"];
   // The template pins the bootstrap command to a version placeholder rather
   // than a typed-in string: package.json is the only source of truth, so an
   // installed skill can never advertise a stale published release. Rendered
   // by the shared helper (lib/skill-template.cjs) so this substitution has a
   // single source of truth shared with the public skill page and the
   // server's own /skill and /skill.md routes.
-  const template = rf(src, "utf8");
-  wf(join(dest, "SKILL.md"), renderSkillTemplate(template, PACKAGE_VERSION));
-  log(`Installed the SignalDash skill to ${dest}/SKILL.md`);
-  log("Your agent now knows how to use LinkedIn + WhatsApp safely through SignalDash.");
+  for (const name of skills) {
+    const src = join(here, "..", "skills", name, "SKILL.md");
+    if (!ex(src)) { log(`${name} skill file not found in package`); process.exitCode = 1; return; }
+    const dest = join(homedir(), ".claude", "skills", name);
+    mk(dest, { recursive: true });
+    const template = rf(src, "utf8");
+    wf(join(dest, "SKILL.md"), renderSkillTemplate(template, PACKAGE_VERSION));
+    log(`Installed the ${name === "signaldash" ? "SignalDash" : "Secretary"} skill to ${dest}/SKILL.md`);
+  }
+  log("Your agent now knows how to use SignalDash safely and render Secretary latest.");
 }
 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@floomhq/signaldash",
-  "version": "0.31.0",
+  "version": "0.32.2",
   "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/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 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/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-rules.cjs && node --check server/secretary-shadow-gate.cjs && node --check server/secretary-vault-importer.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 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/secretary/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: secretary
+description: Render Federico's stored inbound SignalDash triage when he asks for "latest", then record an exact yes or no for one displayed draft through SignalDash.
+---
+
+# Secretary latest
+
+When Federico asks `latest`, call `sd_secretary_latest`. This is a stored-data
+read. Do not call LinkedIn, list chats, read threads, draft with a model, or use
+any provider-backed tool as part of this flow.
+
+Keep the most recent successful response's `ack_token` and nullable `next`
+inside the current Claude session. On the next `latest` call:
+
+- pass the prior `ack_token` as `ack_token`;
+- when the prior `next` was non-null, pass it as `continuation` too;
+- replace both saved values only after a successful response;
+- after any error, retain the prior values and report the exact error.
+
+Render exactly one Markdown table. Before it, state collection warnings from
+`completeness` in one short sentence, or state `Collection complete` when the
+array is empty. Use these columns:
+
+| Priority | When | Who | Channel | Exact inbound | Disposition | Action | Draft |
+|---|---|---|---|---|---|---|---|
+
+Keep the server order. Copy exact inbound text and draft text byte for byte,
+using `<br>` only to render embedded line breaks inside a table cell. Escape
+literal pipe characters for Markdown without changing their meaning. Never
+invent an actor name, summary, disposition, recipient, or draft.
+
+Use these priority labels for returned categories:
+
+- `decisions_federico_owes`: Decision
+- `drafts_waiting_for_yes`: Yes or no
+- `shadow_since_last_asked`: Shadow
+- `auto_sent_since_last_asked`: Auto-sent
+- `leads_routed_to_beatriz`: Beatriz
+
+After all returned rows, add exactly one final table row for `ignored`, even
+when its total is zero. Put `Ignored` in Priority, the aggregate total and
+reason counts in Action, and `-` in the other cells. When there are no returned
+rows, this ignored row is still the only table row.
+
+For a draft, display `approval_view.text` in Draft. For a shadow row, display
+`shadow_view.exact_text` in Draft when it is non-null, byte for byte. A shadow
+view is review evidence only and never an approval surface. A missing approval view is
+not approval-ready. Ask Federico for yes or no only when the exact immutable
+approval view is present. The voice evidence comes from
+`approval_view.draft_voice`: measured LinkedIn corpus, median 7 words,
+lowercase openers, zero observed em dashes, German for German input and English
+otherwise. Never replace that evidence with a generic style prompt.
+
+On an explicit yes to one exact displayed draft, call
+`sd_secretary_approve` once with only its `disposition_id`, `payload_hash`, and
+`confirm:true`. Then call `li_send_message` once with only the returned
+`secretary_receipt_id`. Never pass a chat, recipient, text, attachment,
+watermark, or mark-read field beside the receipt. The server derives the exact
+payload and runs the existing read, freshness, duplicate, budget, queue,
+warning, and outcome guards. Report the exact refusal when any guard stops it.
+
+On an explicit no, call `sd_secretary_reject` once with only the displayed
+`disposition_id` and `confirm:true`. This records the rejection and sends
+nothing. Discussion, an edit, or approval of another draft is neither yes nor
+no for the displayed payload. An edit requires a new current disposition and
+a new approval view.

package/skills/signaldash/SKILL.md

@@ -51,7 +51,7 @@ in their terminal first, then continue.
    npx -y @floomhq/signaldash@{{PACKAGE_VERSION}} <invite-code>
    ```
 
-   This logs in, copies the package-bundled skill into Claude Code, registers
+   This logs in, copies the package-bundled SignalDash and Secretary skills into Claude Code, registers
    the local MCP server, and prints browser links the human opens to connect
    each account.
 
@@ -59,17 +59,19 @@ in their terminal first, then continue.
    the provider account link. Hand the link to the user and wait for them to
    complete Connect in their own browser.
 
-2. The package writes the installed copy to the one location it supports
+2. The package writes the installed copies to the one client layout it supports
    today:
 
    - Claude Code: `~/.claude/skills/signaldash/SKILL.md`
+   - Claude Code: `~/.claude/skills/secretary/SKILL.md`
 
    Other clients (Codex, a portable `.agents/skills/` layout, etc.) are not
    written automatically. Copy this same reviewed file into that client's own
    skill directory by hand and reload skill discovery there.
 
-3. Confirm that the installed file begins with `name: signaldash` and contains the
-   `Before every send` section. A partial copy is not installed.
+3. Confirm that the SignalDash file begins with `name: signaldash` and contains the
+   `Before every send` section, and the Secretary file begins with `name: secretary`.
+   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
@@ -86,7 +88,8 @@ in their terminal first, then continue.
 
    ```text
    Installed the SignalDash skill to /home/user/.claude/skills/signaldash/SKILL.md
-   Your agent now knows how to use LinkedIn + WhatsApp safely through SignalDash.
+   Installed the Secretary skill to /home/user/.claude/skills/secretary/SKILL.md
+   Your agent now knows how to use SignalDash safely and render Secretary latest.
    ```
 
 Persisting the reviewed, package-bundled skill is part of setup. Do not continue
@@ -359,9 +362,14 @@ 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; `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. |
+| `sd_version` | no arguments | Read the backend commit, dirty-at-start state, process start time, and package version captured when the serving process started. Use it to distinguish stale deployment from a code failure. |
+| `sd_secretary_latest` | `limit` optional integer 1-100, default 50; `continuation` optional signed token; `ack_token` optional signed token from the previous successful response | Read the stored Secretary inbox with zero provider calls. Render its rows plus the ignored aggregate as one table. Preserve the prior tokens after an error; on the next successful call pass its acknowledgement and continuation exactly as returned. |
+| `sd_secretary_approve` | `disposition_id` required; `payload_hash` required exact 64-character hash from latest; `confirm:true` required | Create one single-use, 15-minute receipt for the exact current stored draft. It derives the sender and executable payload from storage. |
+| `sd_secretary_reject` | `disposition_id` required; `confirm:true` required | Reject one exact current stored draft. It sends nothing. |
+| `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_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. |
 | `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. |
@@ -387,19 +395,23 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `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_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`. Direct chats expose a resolved contact in both `name` and `attendee_name` when available; groups retain their provider group `name` and return `attendee_name:null`. 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. An unresolved 1:1 name remains null, so search the exact phone number instead of guessing. 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. The response includes `current_watermark` for an exact compare-and-swap send. |
+| `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_send_message` | `chat_id` required; `text` optional only when a file is attached, max 5000 characters; `attachments` optional array of up to 4 exact `{filename, content_type, content_base64}` files, at most 16 MiB per file and 16 MiB per message, types `image/png`, `image/jpeg`, `image/webp`, `image/gif`, `application/pdf`, `text/csv`, `text/plain`, `application/json`, `application/zip`, xlsx | Send one approved reply, one approved file, or both, in an existing WhatsApp conversation after an immediate re-read. A file spends the same daily send budget and is recorded the same way as a text message; there is no separate attachment budget. A call carrying neither text nor an attachment is refused with `400 text_or_attachment_required`. Attachments are checked before anything is reserved, so a refusal costs no send: `400 unsupported_attachment_type`, `400 attachment_too_large`, `400 attachments_too_large`, `400 too_many_attachments`, `400 malformed_attachment_base64`, `400 invalid_attachment_filename`, and `413 request_too_large` when the whole body is too big to read. Nothing is ever truncated or dropped silently. The same caption with the same file is refused as `409 duplicate_send`; the same caption with a different file is a different message and goes through. If a send times out or the provider never confirms it, the message may still have been delivered: an identical retry is refused with `409 send_outcome_unknown`. Read the chat AGAIN, and ONLY if the message is genuinely absent, resend the identical payload with `confirm_resend:true`. The re-read is enforced, not advisory: a `confirm_resend` whose most recent read of that chat predates the failed attempt is refused with `428 reread_after_failed_send_required`, because a read taken before the attempt cannot show whether the message arrived. The send also re-reads the thread immediately before sending and refuses with `409 thread_changed` if the conversation moved after the read that authorized it, or with `502 thread_preflight_unavailable` if that re-read fails; in both cases nothing was sent and no budget was spent. A chat whose most recent read predates thread-change detection is refused with `428 read_before_send_required` until it is read again. LinkedIn messages carry text only. |
+| `wa_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. |
 | `email_list` | `limit` integer 1-100, default 20; `cursor` optional, max 4096 | List the newest message in each recent email thread and obtain `thread_id`. The response carries a `cursor`; pass it back to read the next page, and omit it for the first. |
 | `email_read` | `thread_id` required; `limit` 1-100, default 30 | Read an email thread and authorize its exact participant addresses for a later send. Everyone on `cc` counts as a participant, so a read authorizes them too. The newest messages are returned, not the oldest, so the people being replied to are always in the window. |
 | `email_send` | `to` required as an array of exactly one valid address; `subject` required, max 998, single line; `body` required, max 5000; `thread_id` optional, max 500 | Send one approved email to a participant in a recently read existing thread. Pass the `thread_id` you read to reply inside that thread; omit it only when starting a new one. A blank or oversized `thread_id` is refused with `400 invalid_request` rather than quietly starting a new thread beside the original. The same subject and body to the same person in the same thread is refused as `409 duplicate_send`; the same words in a different thread are a different message and go through. A subject containing a line break is refused with `400 invalid_request`, because a subject is one header line; a body with line breaks is normal and sends. If a send leaves this host and the provider never answers, the retry is refused as `409 send_outcome_unknown`: read the thread again, and only if the email is genuinely absent resend with `confirm_resend: true`. |
-| `li_my_posts` | `limit` default 10, max 50; `member_id` optional | Find the user's latest posts and post IDs. Omit `member_id` to use the connected user's own ID. |
-| `li_post_reactions` | `post_id` required; `limit` default 50, max 100 | Identify who reacted to one post and assess warm signals. A reaction does not authorize outreach. |
-| `li_post_comments` | `post_id` required; `limit` default 50, max 100 | Read comments and authors for one post; prioritize questions and substantive responses. |
+| `li_my_posts` | `limit` default 10, max 50; `member_id` optional | Find the user's latest posts and exact `social_id` values. Omit `member_id` to use the connected user's own ID. Pass `social_id`, not a different numeric `id`, to the engagement tools. |
+| `li_post_reactions` | `post_id` required; use the exact `social_id` from `li_my_posts`; `limit` default 50, max 100; `cursor` optional | Read one bounded page of reactors. Always inspect `completeness.state`, `total`, and `next_cursor`; continue with the cursor while state is `incomplete`. Numeric ids are resolved against the user's own recent posts when possible, including ugcPost-backed multi-image posts. The provider total is reported when available and is never guessed from `li_my_posts`. A reaction does not authorize outreach. |
+| `li_post_comments` | `post_id` required; `comment_id` optional exact parent id; use the exact `social_id` from `li_my_posts`; `limit` default 50, max 100; `cursor` optional | Read one bounded page of comments, or pass `comment_id` to read replies to that exact parent. Always inspect `completeness.state`, `total`, and `next_cursor`; continue with the cursor while state is `incomplete`. Numeric ids are resolved against the user's own recent posts when possible. The provider total is reported when available and is never guessed from `li_my_posts`. |
+| `li_reply_to_comment` | Manual path: `post_id`, `parent_comment_id`, `trigger_comment_id`, and `text` required; `expected_watermark` optional exact 64-character watermark. Secretary path: `secretary_receipt_id` alone. | Reply once to one exact inbound comment on this sender's own post after `li_post_comments`. SignalDash re-proves post ownership, the unchanged trigger, its author and parent, no own duplicate, sender generation, budget, and provider health immediately before writing. A 2xx is not success until readback finds exactly one matching own reply. |
+| `li_delete_message` | `chat_id`, `message_id`, and `confirm:true` required | Remediate one exact own LinkedIn message within 60 minutes of sending. SignalDash proves account, exact chat, own authorship, timestamp eligibility, a separate remediation budget, and post-delete absence. This cannot undo delivery, reading, or notifications and never relaxes a send gate. |
+| `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. |
@@ -411,6 +423,8 @@ Use the exact tool names and argument keys below. Limits are optional.
 Representative calls:
 
 ```text
+sd_version({})
+sd_secretary_latest({})
 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."})
@@ -452,8 +466,11 @@ 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.","thread_id":"thread_email_c402"})
 li_my_posts({"limit":5})
-li_post_reactions({"post_id":"post_urn_8821","limit":50})
-li_post_comments({"post_id":"post_urn_8821","limit":50})
+li_post_reactions({"post_id":"urn:li:activity:8821","limit":50})
+li_post_comments({"post_id":"urn:li:activity:8821","limit":50})
+li_reply_to_comment({"post_id":"urn:li:activity:8821","parent_comment_id":"comment-root","trigger_comment_id":"comment-root","text":"Thanks!","expected_watermark":"exact-64-character-watermark-from-the-read"})
+li_delete_message({"chat_id":"chat_li_7f3a","message_id":"msg_li_5c71","confirm":true})
+li_delete_comment({"post_id":"exact-v2-post-id","comment_id":"exact-own-comment-id","confirm":true})
 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({})
@@ -933,14 +950,17 @@ 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;
+- `name`, `headline`, `public_id`, `member_id`, `profile_url`, and
+  `connected_at`; `member_id` is null only for a legacy row that has not yet
+  been refreshed or verified by chat search;
+- `already_in_contact`, based on an exact known chat or 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
+The join checks only the row's exact LinkedIn member id, public identifier,
+canonical profile URL, and verified known-chat mapping 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
@@ -1084,19 +1104,20 @@ message you cannot yet schedule.
 
 ### 409 `thread_changed`
 
-Meaning: the exact chat moved after the read that authorized the send. Both
-`li_send_message` and `wa_send_message` re-read the thread immediately before
-sending and refuse unless it is still the thread that was read. A read inside
-the 30-minute window is not enough on its own: a thread that changed 29 minutes
-ago satisfies the window and is still not the conversation the draft was
-written against.
+Meaning: the counterparty added a message, an existing item changed or was
+deleted, or an explicit `expected_watermark` no longer matches. Both send tools
+return `new_messages`, `changed_kind`, and `current_watermark`. Additions made
+only by this account are classified as `own_outbound` and do not invalidate a
+send unless the caller supplied an explicit watermark that no longer matches.
 
 Comply:
 
-1. Do not resend the same text.
-2. Re-read the exact chat and read the new messages.
-3. Revise the draft against what the thread now says, and obtain approval again.
-4. Send once, promptly.
+1. Inspect `new_messages` and `changed_kind`.
+2. Revise the draft against the new context and obtain approval again when the
+   change affects the approved text.
+3. Pass the returned `current_watermark` as `expected_watermark` to bind the
+   next attempt to exactly that reviewed state.
+4. Send once, promptly. A second change returns another observable 409.
 
 A `502 thread_preflight_unavailable` on a send means that re-read itself failed,
 so whether the thread changed is unknown and nothing was sent. Retry the send
@@ -1106,11 +1127,10 @@ same fact: no answer about whether the conversation moved. In that case a `428
 read_before_send_required` on the next attempt is expected too, because a read
 of an unrecognised shape records no authorization.
 
-Your own send moves the thread too, so two messages in a row are refused unless
-you read the chat between them. This is not a glitch to work around: the second
-message was drafted against a conversation that no longer exists, if only
-because the first message is now in it. Read, confirm the first message landed
-as intended, then send the second. If you meant one message, send one message.
+A confirmed send advances the stored proof. Distinct consecutive messages can
+therefore pass without a fresh read when the only movement is this account's
+own outbound. Every send still re-reads the provider thread, and a counterparty
+message or mutation still refuses before budget or provider write.
 
 ### 409 `duplicate_send`
 
@@ -1299,16 +1319,22 @@ User: "Who engaged with my last LinkedIn post, and what should I do?"
    ```
 
 2. Select the newest post by its provider timestamp, not by list position when
-   timestamps disagree. Record its exact `post_id`.
-3. Call:
+   timestamps disagree. Record its exact `social_id`.
+3. Call with the exact `social_id` from that post, not a different numeric `id`:
 
    ```text
-   li_post_reactions({"post_id":"post_urn_8821","limit":50})
-   li_post_comments({"post_id":"post_urn_8821","limit":50})
+   li_post_reactions({"post_id":"urn:li:activity:8821","limit":50})
+   li_post_comments({"post_id":"urn:li:activity:8821","limit":50})
    ```
 
 4. Group the result:
 
+   Before grouping, inspect `completeness` on both responses. While its state
+   is `incomplete`, repeat the call with `cursor: completeness.next_cursor`.
+   A state of `unknown` is not a complete sweep; report that the provider did
+   not prove completeness. Never substitute `li_my_posts.reaction_counter` as
+   a fabricated result total.
+
    - Direct questions in comments: respond publicly or draft a reply.
    - Existing contacts with substantive engagement: warm follow-up candidate,
      but no message without thread verification and approval.

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

@@ -1,6 +1,6 @@
 ---
 name: signaldash-safe-usage
-description: Safely search stored LinkedIn connections, inspect exact contact state and action budgets, read and send LinkedIn, WhatsApp, or email messages, and operate exact LinkedIn invitations or human-approved invitation batches through the SignalDash MCP without triggering account restrictions or contacting the wrong person. Use whenever an agent uses li_search_connections, sd_contact_state, sd_budget_status, li_list_chats, li_read_messages, li_send_message, li_send_invitation, li_invitations_received, li_accept_invitation, li_invitations_sent, li_withdraw_invitation, li_create_invitation_batch, li_get_invitation_batch, li_cancel_invitation_batch, wa_list_chats, wa_read_messages, wa_get_attachment, wa_transcribe_voice, wa_send_message, email_list, email_read, or email_send.
+description: Safely search stored LinkedIn connections, inspect exact contact state and action budgets, approve or reject exact Secretary drafts, read, mark read, reply to comments, delete exact own content, and send LinkedIn, WhatsApp, or email messages through the SignalDash MCP without triggering account restrictions or contacting the wrong person. Use whenever an agent uses a SignalDash read, send, invitation, comment-reply, or delete tool.
 ---
 
 # Use SignalDash safely
@@ -23,6 +23,15 @@ Treat LinkedIn, WhatsApp, and email as human accounts, not bulk messaging APIs.
 Never infer a recipient from a partial name. Never send blind. Never retry a
 send after an ambiguous timeout without first reading the thread.
 
+Reading is non-mutating. Clear unread only through an explicit `li_mark_read`
+or `wa_mark_read` call, or an approved send with `mark_read:true`.
+
+For a Secretary draft, approve only the exact `disposition_id` and
+`payload_hash` returned by `sd_secretary_latest`. Pass the resulting
+`secretary_receipt_id` alone to `li_send_message`. Never add or edit a chat,
+recipient, text, attachment, watermark, or mark-read field beside the receipt.
+On no, call `sd_secretary_reject` for that exact disposition and send nothing.
+
 ## Contact-state limits
 
 - `sd_contact_state` uses exact user-and-channel identifiers only. It does not
@@ -113,6 +122,15 @@ send after an ambiguous timeout without first reading the thread.
   cached records.
 - Stop all LinkedIn activity on any checkpoint, warning, restriction, unusual
   verification prompt, HTTP 403, or HTTP 429.
+- Before `li_reply_to_comment`, read the exact own post comments, preserve the
+  exact parent, trigger and watermark, show the full reply text, and obtain
+  approval. The server readback, not the provider 2xx alone, proves success.
+- Before `li_delete_message` or any future enabled `li_delete_comment`, read
+  and show the exact own object and obtain explicit approval. Deletion is
+  remediation after exposure, not rollback. It cannot undo a notification or
+  a recipient having read the content, and it never weakens any send gate.
+- Treat `li_delete_comment` as unavailable while its capability reports
+  `untested`. Never change that flag merely to complete a task.
 
 LinkedIn detects behavior, not only API request frequency. Repeated copy,
 bursting sends, high profile-view volume, many ignored invitations, concurrent