@floomhq/signaldash 0.39.6 → 0.39.9

package/README.md

@@ -120,7 +120,7 @@ setup installs both from the same pinned npm package
 the human chose to execute:
 
 ```bash
-npx -y @floomhq/signaldash@0.39.6 <invite-code>
+npx -y @floomhq/signaldash@0.39.9 <invite-code>
 ```
 
 Run that command in a terminal, not in an agent chat. Do not ask an agent to
@@ -168,7 +168,7 @@ SignalDash exposes:
 - `li_create_invitation_batch(source_label, time_zone, targets)`
 - `li_get_invitation_batch(batch_id)`
 - `li_cancel_invitation_batch(batch_id, approval_view_hash, confirm)`
-- `sd_campaign_create(source_label, time_zone, messages, target_source?, targets?, engagers?, invite_ttl_days?)`
+- `sd_campaign_create(source_label, time_zone, messages?, target_source?, targets?, engagers?, invite_ttl_days?)`
 - `sd_campaign_preview(campaign_id)`
 - `sd_campaign_approve(campaign_id, confirm_token)`
 - `sd_campaign_status(campaign_id)`
@@ -192,12 +192,17 @@ SignalDash exposes:
 - `li_my_posts(limit, member_id)`
 - `li_post_reactions(post_id, limit, cursor?)`
 - `li_post_comments(post_id, comment_id?, resolve_reply_state?, limit, cursor?)`
-- `li_reply_to_comment(post_id?, parent_comment_id?, trigger_comment_id?, text?, expected_watermark?, secretary_receipt_id?)`
+- `li_reply_to_comment(post_id?, parent_comment_id?, trigger_comment_id?, text?, mentions?, expected_watermark?, secretary_receipt_id?)`
 - `li_like_comment(post_id, parent_comment_id, comment_id, expected_watermark?)`
 - `li_delete_message(chat_id, message_id, confirm)`
 - `li_delete_comment(post_id, comment_id, confirm)`
 - `li_draft_post(text, publish, scheduled_at?, content_pipeline_id?, content_pipeline_override?, mentions?, attachments?, first_comment?)`
 - `li_set_scheduled_post_first_comment(id, first_comment, confirm)`
+- `li_save_post_draft(text, mentions?, attachments?, first_comment?, source_key?, metadata?)`
+- `li_post_drafts()`
+- `li_update_post_draft(id, text, expected_version, mentions?, attachments?, first_comment?)`
+- `li_delete_post_draft(id, expected_version, confirm)`
+- `li_post_draft_preview(id)`
 - `li_scheduled_posts()`
 - `li_scheduled_post_preview(id)`
 - `li_edit_scheduled_post(id, text, scheduled_at, mentions?, attachments?, first_comment?, confirm?, approval_hash?, expected_version?, expected_updated_at?)`
@@ -379,6 +384,35 @@ 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.
 
+Arbitrary saved LinkedIn drafts use a separate durable store and never enter
+the scheduling or publishing worker. `li_save_post_draft` stores exact text,
+up to 25 mentions, up to 20 ordered images, and an optional first comment.
+Each image is limited to 5 MiB and one draft to 12 MiB; each tenant is limited
+to 1,000 drafts and 100 MiB of decoded attachment bytes. Ordinary duplicate
+drafts remain distinct records. Imports may instead supply a tenant-scoped
+`source_key`: an identical replay returns the existing draft, while a replay
+with different content is refused. Bounded structured `metadata` preserves the
+source, title, storyline, readiness, hold gates, editorial notes, visual notes,
+and revision without placing those fields in the publishable post text. List
+responses expose image metadata rather than base64.
+`li_update_post_draft` is a complete compare-and-swap replacement: pass the
+current `expected_version`, and omission clears optional mentions, images, or
+first comment. `li_delete_post_draft` requires the current version and
+`confirm:true`. None of these operations calls LinkedIn, Unipile, Buffer, or an
+action-budget lane.
+
+`li_post_draft_preview` returns a short-lived, one-use
+`https://signaldash.dev/d/<token>` link for one exact saved draft. POSTing its
+confirmation creates a 15-minute cookie restricted to `/drafts`; the page and
+its `/drafts/:id/attachments/:index` media route remain bound to that tenant,
+draft, and originating live SignalDash session. Media is served byte-for-byte
+with `private, no-store`, MIME allowlisting, `nosniff`, and a restrictive CSP.
+The shared calendar displays unscheduled SignalDash and Buffer drafts with the
+same cards as scheduled posts, marked by a visible `DRAFT` tag and an
+`Unscheduled` time label. Saved SignalDash media uses separate protected
+`/calendar/drafts/...` URLs. Drafts never enter the `items` returned by
+`li_scheduled_posts`, preserving its existing calendar contract.
+
 `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,
@@ -587,9 +621,9 @@ messaging. Campaign invitations require a valid sender IANA timezone, run only
 Monday through Friday from 09:00 to 17:00 sender-local time, and reserve a new
 90–180 second per-sender pacing interval atomically with every attempted
 action. Timing is checked before final provider preflight and again during the
-write reservation. Downtime never creates a catch-up burst. Future start
-dates, recurring schedules, automatic follow-ups, acceptance-triggered
-messages, and multi-message sequences are not exposed.
+write reservation. Downtime never creates a catch-up burst. A campaign can be
+connect-only or carry an exact human-approved acceptance-triggered sequence.
+User-selected future start dates and recurring schedules are not exposed.
 
 Deleting a WhatsApp message is a write, and an irreversible one, so it is
 treated as such. SignalDash proves the chat belongs to the connected account,

package/bin/sd.mjs

@@ -133,6 +133,24 @@ export async function api(
   ) {
     json.approval_url = new URL(json.approval_path, targetBackend).toString();
   }
+  // The batch magic link gets the same rebase for the same reason: the backend
+  // stamps its own configured public origin, but the human has to open the
+  // host THIS client is actually talking to. Rebasing only the path keeps the
+  // token intact and never logs it; leaving it alone would hand a self-hosted
+  // user a link pointing at somebody else's deployment.
+  if (
+    json &&
+    typeof json === "object" &&
+    typeof json.approval_link === "string" &&
+    json.approval_link
+  ) {
+    try {
+      json.approval_link = new URL(
+        new URL(json.approval_link).pathname,
+        targetBackend,
+      ).toString();
+    } catch {}
+  }
   return { status: r.status, json };
 }
 
@@ -980,7 +998,7 @@ const TOOLS = [
   {
     name: "sd_campaign_create",
     path: "/sd/campaign/create",
-    description: "Create one campaign: a paced 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 the moment they reply. Nothing is sent until a human approves this exact recipient list and this exact message text on the approval page. Targets come from an explicit list you supply (for example one you built with li_search_connections or li_post_reactions) or from your own post engagers, which costs zero profile fetches. If the user already sent someone a connection request by hand and just wants the follow-up automated, set adopt_existing_invitation on that target instead of leaving them out. Draft the messages in the user's own voice and keep them short: the on-acceptance group is 2-3 separate short sends, never one block.",
+    description: "Create one campaign: a paced connection request to each exact person, optionally followed by exact approved message(s) once that person is PROVEN to have accepted. Omit messages or pass an empty array for a connect-only campaign; no message ever follows. Nothing is sent until a human approves the exact recipient list and actions on the approval page. Targets come from an explicit list you supply (for example one you built with li_search_connections or li_post_reactions) or from your own post engagers, which costs zero profile fetches. If the user already sent someone a connection request by hand and wants an approved follow-up automated, set adopt_existing_invitation on that target instead of leaving them out. When messages are present, draft them in the user's own voice and keep them short: the on-acceptance group is 2-3 separate short sends, never one block.",
     inputSchema: {
       type: "object",
       properties: {
@@ -1036,9 +1054,9 @@ const TOOLS = [
         },
         messages: {
           type: "array",
-          minItems: 1,
+          minItems: 0,
           maxItems: 5,
-          description: "The exact frozen texts. after_days 0 means sent once the invitation is accepted (1-3 of these, sent as separate consecutive messages); a later step needs after_days 1-30 and only goes out if there has been no reply.",
+          description: "Optional exact frozen texts. Empty means connect-only and no message ever follows. after_days 0 means sent once the invitation is accepted (1-3 of these, sent as separate consecutive messages); a later step needs after_days 1-30 and only goes out if there has been no reply.",
           items: {
             type: "object",
             properties: {
@@ -1057,7 +1075,7 @@ const TOOLS = [
           description: "An invitation not accepted within this many days is dropped and never messaged.",
         },
       },
-      required: ["source_label", "time_zone", "messages"],
+      required: ["source_label", "time_zone"],
       additionalProperties: false,
     },
   },
@@ -1546,7 +1564,7 @@ const TOOLS = [
   {
     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.",
+    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. Optional mentions tag people in the reply: spell each person's name into text exactly once as a whole word and pass a matching mentions entry, exactly as li_draft_post does. LinkedIn already notifies the comment's author, so a mention is for tagging a THIRD person. 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 whose landed text equals text, so a tag whose display name does not render exactly as written is reported unverified rather than assumed sent. A Secretary approval uses secretary_receipt_id alone.",
     inputSchema: {
       type: "object",
       properties: {
@@ -1554,6 +1572,18 @@ const TOOLS = [
         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 },
+        mentions: {
+          type: "array", maxItems: 20,
+          description: "People to tag. Each name must appear exactly once in text as a whole word; SignalDash replaces that one occurrence with the provider's mention token. Use the person's exact LinkedIn display name, because the landed comment is verified against text character for character.",
+          items: {
+            type: "object",
+            properties: {
+              name: { type: "string", minLength: 1, maxLength: 120 },
+              profile_id: { type: "string", minLength: 1, maxLength: 250 },
+            },
+            required: ["name", "profile_id"],
+          },
+        },
         expected_watermark: { type: "string", pattern: "^[0-9a-f]{64}$" },
         secretary_receipt_id: { type: "string", minLength: 1, maxLength: 500 },
       },
@@ -1609,7 +1639,7 @@ const TOOLS = [
   {
     name: "li_draft_post",
     path: "/li/create_post",
-    description: "Draft, publish, or schedule a LinkedIn post. Scheduling requires an offset-qualified scheduled_at plus publish:true after exact human approval. When the content pipeline is enabled, use an approved content_pipeline_id or preview one exact reasoned content_pipeline_override and repeat it with confirm:true plus its single-use approval_hash. Optional mentions, base64 image attachments, and an account-owner-authored first_comment are preserved for the scheduled publish.",
+    description: "Draft, publish, or schedule a LinkedIn post. Scheduling requires an offset-qualified scheduled_at plus publish:true after exact human approval. When the content pipeline is enabled, use an approved content_pipeline_id or preview one exact reasoned content_pipeline_override and repeat it with confirm:true plus its single-use approval_hash. Optional mentions, up to 20 base64 image attachments, and an account-owner-authored first_comment are preserved for the scheduled publish.",
     inputSchema: {
       type: "object",
       properties: {
@@ -1629,7 +1659,7 @@ const TOOLS = [
         },
         first_comment: { type: "string", minLength: 1, maxLength: 1250 },
         mentions: {
-          type: "array", maxItems: 20,
+          type: "array", maxItems: 25,
           items: {
             type: "object",
             properties: {
@@ -1640,7 +1670,7 @@ const TOOLS = [
           },
         },
         attachments: {
-          type: "array", maxItems: 4,
+          type: "array", maxItems: 20,
           items: {
             type: "object",
             properties: {
@@ -1671,12 +1701,238 @@ const TOOLS = [
       additionalProperties: false,
     },
   },
+  {
+    name: "li_save_post_draft",
+    path: "/li/save_post_draft",
+    description: "Persist one arbitrary LinkedIn post draft without scheduling or publishing it. Stores exact text, ordered image bytes, mentions, and an optional first comment. Duplicate drafts are allowed. No provider call or action budget is used.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        text: { type: "string", minLength: 1, maxLength: 3000 },
+        mentions: {
+          type: "array", maxItems: 25,
+          items: {
+            type: "object",
+            properties: {
+              name: { type: "string", minLength: 1, maxLength: 120 },
+              profile_id: { type: "string", minLength: 1, maxLength: 250 },
+            },
+            required: ["name", "profile_id"],
+            additionalProperties: false,
+          },
+        },
+        attachments: {
+          type: "array", maxItems: 20,
+          items: {
+            type: "object",
+            properties: {
+              filename: { type: "string", minLength: 1, maxLength: 180 },
+              content_type: { type: "string", enum: ["image/png", "image/jpeg", "image/webp", "image/gif"] },
+              content_base64: { type: "string", minLength: 1 },
+            },
+            required: ["filename", "content_type", "content_base64"],
+            additionalProperties: false,
+          },
+        },
+        first_comment: { type: "string", minLength: 1, maxLength: 1250 },
+        source_key: {
+          type: "string",
+          minLength: 1,
+          maxLength: 256,
+          description: "Optional tenant-scoped idempotency key for a durable source item. Reusing it with different content is refused.",
+        },
+        metadata: {
+          type: "object",
+          properties: {
+            source_group: { type: "string", minLength: 1, maxLength: 100 },
+            source_batch_id: { type: "string", minLength: 1, maxLength: 200 },
+            source_item_id: { type: "string", minLength: 1, maxLength: 200 },
+            title: { type: "string", minLength: 1, maxLength: 500 },
+            storyline: { type: "string", minLength: 1, maxLength: 2000 },
+            readiness: { type: "string", enum: ["ready", "held"] },
+            hold_gates: {
+              type: "array",
+              maxItems: 20,
+              items: {
+                type: "object",
+                properties: {
+                  code: { type: "string", minLength: 1, maxLength: 100 },
+                  note: { type: "string", minLength: 1, maxLength: 2000 },
+                },
+                required: ["code", "note"],
+                additionalProperties: false,
+              },
+            },
+            source: {
+              type: "object",
+              properties: {
+                label: { type: "string", minLength: 1, maxLength: 500 },
+                id: { type: "string", minLength: 1, maxLength: 500 },
+                text: { type: "string", minLength: 1, maxLength: 12000 },
+              },
+              additionalProperties: false,
+            },
+            status: { type: "string", minLength: 1, maxLength: 100 },
+            editorial_notes: {
+              type: "array",
+              maxItems: 20,
+              items: { type: "string", minLength: 1, maxLength: 4000 },
+            },
+            visual: { type: "string", minLength: 1, maxLength: 4000 },
+            revision: { type: "integer", minimum: 0 },
+          },
+          additionalProperties: false,
+        },
+      },
+      required: ["text"],
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "li_post_drafts",
+    path: "/li/post_drafts",
+    description: "List this account's durable SignalDash LinkedIn post drafts and return a fresh one-use calendar link. Attachment metadata is returned, never base64 bytes. These drafts remain separate from scheduled posts and do not appear in li_scheduled_posts items.",
+    inputSchema: { type: "object", properties: {}, additionalProperties: false },
+  },
+  {
+    name: "li_update_post_draft",
+    path: "/li/update_post_draft",
+    description: "Atomically replace one complete saved LinkedIn draft using its exact UUID and expected_version. Omitted mentions, attachments, or first_comment are cleared. A stale version is refused. No provider call or action budget is used.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        id: { type: "string", format: "uuid" },
+        text: { type: "string", minLength: 1, maxLength: 3000 },
+        mentions: {
+          type: "array", maxItems: 25,
+          items: {
+            type: "object",
+            properties: {
+              name: { type: "string", minLength: 1, maxLength: 120 },
+              profile_id: { type: "string", minLength: 1, maxLength: 250 },
+            },
+            required: ["name", "profile_id"],
+            additionalProperties: false,
+          },
+        },
+        attachments: {
+          type: "array", maxItems: 20,
+          items: {
+            type: "object",
+            properties: {
+              filename: { type: "string", minLength: 1, maxLength: 180 },
+              content_type: { type: "string", enum: ["image/png", "image/jpeg", "image/webp", "image/gif"] },
+              content_base64: { type: "string", minLength: 1 },
+            },
+            required: ["filename", "content_type", "content_base64"],
+            additionalProperties: false,
+          },
+        },
+        first_comment: { type: "string", minLength: 1, maxLength: 1250 },
+        expected_version: { type: "integer", minimum: 0 },
+      },
+      required: ["id", "text", "expected_version"],
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "li_delete_post_draft",
+    path: "/li/delete_post_draft",
+    description: "Permanently delete one exact saved LinkedIn draft. Requires its UUID, current expected_version, and confirm:true. A stale version is refused. This does not delete a LinkedIn-native or scheduled post.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        id: { type: "string", format: "uuid" },
+        expected_version: { type: "integer", minimum: 0 },
+        confirm: { type: "boolean", const: true },
+      },
+      required: ["id", "expected_version", "confirm"],
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "li_post_draft_preview",
+    path: "/li/post_draft_preview",
+    description: "Create a short-lived one-use browser link for one exact saved SignalDash LinkedIn draft. The isolated read-only page renders only that draft, its protected stored images, and its draft first comment.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        id: { type: "string", format: "uuid" },
+      },
+      required: ["id"],
+      additionalProperties: false,
+    },
+  },
   {
     name: "li_scheduled_posts",
     path: "/li/scheduled_posts",
     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 },
   },
+  {
+    name: "li_profile",
+    path: "/li/profile",
+    description: "Read one LinkedIn profile by public id or member id. Returns name, headline, public identifier, provider id, network distance and the profile picture url. Read-only, one provider call, no write. Exists because pictures were otherwise only available for people who had already reacted to or commented on your own posts, which leaves every new name in a shortlist faceless.",
+    inputSchema: {
+      type: "object",
+      properties: { identifier: { type: "string", minLength: 1, maxLength: 200 } },
+      required: ["identifier"],
+      additionalProperties: false,
+    },
+  },
+  {
+    name: "sd_share_list",
+    path: "/sd/share_list",
+    description: "Share one selection as a standalone signaldash.dev link, or list and revoke the links that exist. Pass `people` instead of `rows` for a shortlist of humans: each entry renders as a card with a photo when the provider gives one and initials when it does not, plus an optional `score` out of 100 and the `reason` that earned it. A score without a reason is a claim without evidence, so send both or neither, and put the scoring rule in `rubric` where the reader can see it. action:create returns the url ONCE and stores only its hash, so the link cannot be recovered later, only revoked. The page is a fixed snapshot: it never re-reads the source, so a list shared today does not keep disclosing tomorrow's data. action:list shows every live link with its open count; action:revoke kills one by its token.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        action: { type: "string", enum: ["create", "list", "revoke"] },
+        title: { type: "string", minLength: 1, maxLength: 200 },
+        note: { type: "string", maxLength: 4000 },
+        columns: { type: "array", minItems: 1, maxItems: 12, items: { type: "string", minLength: 1, maxLength: 80 } },
+        rows: {
+          type: "array", maxItems: 2000,
+          items: { type: "array", items: { type: "string", maxLength: 2000 } },
+        },
+        people: {
+          type: "array", maxItems: 500,
+          items: {
+            type: "object",
+            properties: {
+              name: { type: "string", minLength: 1, maxLength: 200 },
+              headline: { type: "string", maxLength: 500 },
+              reason: { type: "string", maxLength: 600 },
+              url: { type: "string", maxLength: 500 },
+              image: { type: "string", maxLength: 800 },
+              score: { type: "number", minimum: 0, maximum: 100 },
+              meta: { type: "array", maxItems: 4, items: { type: "string", maxLength: 80 } },
+              org: { type: "string", maxLength: 120 },
+              tags: { type: "array", maxItems: 5, items: { type: "string", maxLength: 28 } },
+              factors: {
+                type: "array", maxItems: 6,
+                items: {
+                  type: "object",
+                  properties: {
+                    label: { type: "string", minLength: 1, maxLength: 60 },
+                    points: { type: "number" },
+                  },
+                  required: ["label"],
+                  additionalProperties: false,
+                },
+              },
+            },
+            required: ["name"],
+            additionalProperties: false,
+          },
+        },
+        rubric: { type: "string", maxLength: 1200 },
+        token: { type: "string", minLength: 1, maxLength: 200 },
+        list_id: { type: "string", minLength: 1, maxLength: 64 },
+      },
+      additionalProperties: false,
+    },
+  },
   {
     name: "li_scheduled_post_preview",
     path: "/li/scheduled_post_preview",
@@ -1701,7 +1957,7 @@ const TOOLS = [
         text: { type: "string", minLength: 1, maxLength: 3000 },
         scheduled_at: { type: "string", format: "date-time" },
         mentions: {
-          type: "array", maxItems: 20,
+          type: "array", maxItems: 25,
           items: {
             type: "object",
             properties: {
@@ -1713,7 +1969,7 @@ const TOOLS = [
           },
         },
         attachments: {
-          type: "array", maxItems: 4,
+          type: "array", maxItems: 20,
           items: {
             type: "object",
             properties: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@floomhq/signaldash",
-  "version": "0.39.6",
+  "version": "0.39.9",
   "description": "Secure LinkedIn, WhatsApp, and email access for AI agents",
   "type": "module",
   "bin": {

package/skills/signaldash/SKILL.md

@@ -420,7 +420,7 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `li_create_invitation_batch` | `source_label` required exact string, max 120 code points; `time_zone` required IANA timezone; `targets` required array of 1-10 exact `{profile_url,inclusion_reason,note?}` objects; reason max 240 and note max 200 Unicode code points | Create one immutable durable preview from canonical LinkedIn Classic `/in/` URLs. The agent structures an explicit human request; the server never generates targets or text. |
 | `li_get_invitation_batch` | `batch_id` required | Inspect every stored target, exact note, exclusion, hash, timing, capacity, and result. Use the returned browser review path for human approval. This read also authorizes a later exact cancel. |
 | `li_cancel_invitation_batch` | `batch_id` required; `approval_view_hash` required string or null exactly as inspected; `confirm:true` required | Permanently cancel unstarted targets in one freshly inspected batch. It cannot recall an executing invitation, and restarting requires a new preview and approval. |
-| `sd_campaign_create` | `source_label` required, max 120 code points; `time_zone` required IANA timezone; `messages` required array of 1-5 exact `{text,after_days?}` objects, text max 1200 code points; `target_source` optional (`explicit` default or `post_engagers`); `targets` array of up to 150 `{profile_url?,provider_id?,inclusion_reason,note?,display_name?,headline?,adopt_existing_invitation?}` for `explicit` (at most 10 adopted targets per campaign, and an adopted target may not carry a `note`); `engagers` object with `post_limit` 1-10, `max_targets` 1-150, `inclusion_reason`, `note` for `post_engagers`; `invite_ttl_days` optional 1-60, default 21 | Create one campaign: a connection request to each exact person, then the exact approved message(s) once that person is proven to have accepted, then an optional follow-up that stops on any reply. The server never generates a target or a word of text. Nothing is sent before human approval. |
+| `sd_campaign_create` | `source_label` required, max 120 code points; `time_zone` required IANA timezone; `messages` optional array of 0-5 exact `{text,after_days?}` objects, text max 1200 code points; omit it or pass `[]` for connect-only; `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, optionally followed by exact approved messages after proven acceptance. A connect-only campaign completes after its invitations and never watches acceptance or sends a message. 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 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. |
@@ -444,15 +444,22 @@ Use the exact tool names and argument keys below. Limits are optional.
 | `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; `resolve_reply_state` optional boolean, not combinable with `comment_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. Pass `resolve_reply_state: true` before replying to anything: each comment then carries `reply_state.replied_by_me`. Skip every comment whose `replied_by_me` is `true`, and skip every comment whose `replied_by_me` is `null`, which means unknown and never means nobody replied. Only `no_replies` and `answered_by_others` are proven unanswered. Always inspect `completeness.state`, `total`, and `next_cursor`; continue with the cursor while state is `incomplete`. Also inspect `reply_resolution.state`; `partial` or `aborted` means some comments were never resolved. 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_reply_to_comment` | Manual path: `post_id`, `parent_comment_id`, `trigger_comment_id`, and `text` required; `mentions` optional array of `{name, profile_id}`; `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. Each mention name must appear exactly once in `text` as a whole word; SignalDash swaps that occurrence for the provider's token, and every tagged person is checked against suppression and protection exactly like the person being replied to. Because the landed comment is compared against `text` character for character, use the person's exact LinkedIn display name or the write is reported unverified. |
 | `li_like_comment` | `post_id`, `parent_comment_id`, and `comment_id` required; `expected_watermark` optional exact 64-character watermark | Like once one exact inbound comment on this sender's own post after `li_post_comments`. SignalDash re-proves post ownership, the unchanged comment, its author and parent, no own like, sender generation, budget, and provider health immediately before writing. A 2xx is not success until bounded readback finds exactly one own like. |
 | `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 the provider's post-delete state. Success requires `deleted:1` or a genuine 404. A present row or failed readback returns `502 deleted_unconfirmed`, locks the sender, and is never retried automatically. 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; `content_pipeline_id` normally required for scheduling while that user's pipeline is enabled; `content_pipeline_override` optional exact `{reason,confirm?,approval_hash?}`; `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. An enabled pipeline normally runs its fact, exact-text, shared-calendar, frequency, and breathing preflight. For one deliberate exception, preview the exact payload with `{reason}`, show it to the human, then repeat it with `confirm:true` and the returned single-use payload-bound `approval_hash`. The audit record preserves the reason, preview ID, and approval time; every non-pipeline provider safety guard remains active. |
+| `li_draft_post` | `text` required, max 3000; `publish` optional; `scheduled_at` optional offset-qualified ISO date-time; `content_pipeline_id` normally required for scheduling while that user's pipeline is enabled; `content_pipeline_override` optional exact `{reason,confirm?,approval_hash?}`; `mentions` optional array of up to 25 exact `{name,profile_id}` objects; `attachments` optional array of up to 20 exact `{filename,content_type,content_base64}` images, max 5 MiB each and 12 MiB total; `first_comment` optional, max 1250 | Create a server-confirmed draft, publish now, or persist an exact future LinkedIn post and its approved first comment. An enabled pipeline normally runs its fact, exact-text, shared-calendar, frequency, and breathing preflight. For one deliberate exception, preview the exact payload with `{reason}`, show it to the human, then repeat it with `confirm:true` and the returned single-use payload-bound `approval_hash`. The audit record preserves the reason, preview ID, and approval time; every non-pipeline provider safety guard remains active. |
 | `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_save_post_draft` | `text` required, max 3000; `mentions` optional up to 25; `attachments` optional up to 20 exact images, max 5 MiB each and 12 MiB total; `first_comment` optional, max 1250; `source_key` optional tenant-scoped idempotency key, max 256; `metadata` optional bounded structured source/editorial context | Persist one arbitrary LinkedIn draft without scheduling or publishing. Exact ordered image bytes and ordinary duplicate drafts are retained. An identical `source_key` replay returns the existing draft; changed content under that key is refused. Tenant limits are 1,000 drafts and 100 MiB decoded attachment bytes. No provider call or action budget is used. |
+| `li_post_drafts` | no arguments | List durable SignalDash drafts with attachment metadata, never base64, and return a fresh one-use calendar link. The calendar uses the scheduled-post card design for unscheduled SignalDash and Buffer drafts, with a visible `DRAFT` tag. Stored drafts remain separate from scheduled posts and never appear in `li_scheduled_posts.items`. |
+| `li_update_post_draft` | `id`, complete replacement `text`, and current `expected_version` required; `mentions`, `attachments`, and `first_comment` optional | Atomically replace the complete saved draft. A stale version is refused with the current version and timestamp. Omitting an optional field clears it. No provider call occurs. |
+| `li_delete_post_draft` | `id`, current `expected_version`, and `confirm:true` required | Permanently delete one exact saved SignalDash draft. Unknown, foreign, deleted, and replayed identifiers are indistinguishable. This cannot delete LinkedIn-native or scheduled content. |
+| `li_post_draft_preview` | `id` required UUID | Create a short-lived, single-use `https://signaldash.dev/d/<token>` browser handoff for one exact saved draft. Its page and exact image bytes are protected by a tenant-, draft-, and originating-session-scoped cookie under `/drafts`. |
 | `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_profile` | `identifier` required, a public id or member id | Read one LinkedIn profile: name, headline, public identifier, provider id, network distance and the profile picture url. Read-only, one provider call, and it returns those six fields rather than the provider's whole record about a person. It exists because pictures were otherwise a by-product of engagement only: reactions and comments carry one, the stored connections carry no picture field, chats carry none, and the invitation preview refuses anyone already connected, so every new name in a shortlist stayed faceless. |
+| `sd_share_list` | `action` create/list/revoke, plus `title`, `columns`, `rows`, optional `note`, or `token` to revoke | Share one selection as a standalone `https://signaldash.dev/l/<token>` page that anyone with the link can open. `create` returns the url ONCE and stores only its SHA-256 hash, so a lost link can be revoked but never recovered. The page is a fixed snapshot and never re-reads the source, so a list shared today does not keep disclosing tomorrow's data. Pass `people` instead of `rows` for a shortlist of humans: each renders as a card with a photo where the provider supplies one and initials where it does not, an optional `score` out of 100, and the `reason` that earned it, with the scoring rule in `rubric` so the reader can check it. For a plain table, every row must have exactly as many cells as there are columns, because a crooked table reads as a claim about the wrong person. `list` shows every live link with its non-secret `list_id` and open count, so a link whose url is lost can still be switched off and a forgotten one stays visible; `revoke` takes either the `token` or that `list_id` and kills it immediately, and a revoked token is indistinguishable from one that never existed. |
 | `li_scheduled_post_preview` | `id` required UUID | Create a short-lived, single-use `https://signaldash.dev/p/<token>` browser handoff for one exact active SignalDash post. The isolated page includes its stored image attachments through account- and post-scoped protected media routes. |
-| `li_edit_scheduled_post` | `id`, `text`, and offset-qualified `scheduled_at` required; full replacement `mentions`, `attachments`, and `first_comment` optional; confirmation repeats the identical payload with `confirm:true`, `approval_hash`, `expected_version`, and `expected_updated_at` from preview | Atomically replace one scheduled post in place. The UUID, creation time, provider account, and content-pipeline audit fields remain unchanged. A changed or non-scheduled row is refused, approval is single-use and expires, and no provider call occurs. Omitting an optional replacement field clears it. Duplicate identity covers the complete normalized payload, including exact attachment bytes, and only active scheduled or executing rows participate; cancelled history never blocks a replacement. |
+| `li_edit_scheduled_post` | `id`, `text`, and offset-qualified `scheduled_at` required; full replacement `mentions` (up to 25), image `attachments` (up to 20, max 5 MiB each and 12 MiB total), and `first_comment` optional; confirmation repeats the identical payload with `confirm:true`, `approval_hash`, `expected_version`, and `expected_updated_at` from preview | Atomically replace one scheduled post in place. The UUID, creation time, provider account, and content-pipeline audit fields remain unchanged. A changed or non-scheduled row is refused, approval is single-use and expires, and no provider call occurs. Omitting an optional replacement field clears it. Duplicate identity covers the complete normalized payload, including exact attachment bytes, and only active scheduled or executing rows participate; cancelled history never blocks a replacement. |
 | `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. |
@@ -516,6 +523,11 @@ li_delete_message({"chat_id":"chat_li_7f3a","message_id":"msg_li_5c71","confirm"
 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_save_post_draft({"text":"A durable idea with no publication date.","first_comment":"Source link goes here."})
+li_post_drafts({})
+li_update_post_draft({"id":"00000000-0000-4000-8000-000000000000","text":"Complete replacement copy.","expected_version":0})
+li_post_draft_preview({"id":"00000000-0000-4000-8000-000000000000"})
+li_delete_post_draft({"id":"00000000-0000-4000-8000-000000000000","expected_version":1,"confirm":true})
 li_scheduled_posts({})
 li_scheduled_post_preview({"id":"00000000-0000-4000-8000-000000000000"})
 li_edit_scheduled_post({"id":"00000000-0000-4000-8000-000000000000","text":"Exact replacement","scheduled_at":"2026-09-07T08:00:00Z"})
@@ -568,6 +580,16 @@ comment failure never republishes the post. It fails interrupted or ambiguous
 executions closed and never retries them automatically. `email_send` cannot
 start a cold thread and must never be looped over recipients.
 
+When the user wants to keep an arbitrary idea without choosing a publication
+time, use `li_save_post_draft`, not `li_draft_post` with invented scheduling
+arguments. Read it back with `li_post_drafts`; use its returned calendar link
+for the combined read-only scheduled/draft view, or `li_post_draft_preview` for
+one exact draft and its visuals. Updates are complete replacements and require
+the current version, so preserve every optional field the user still wants and
+omit only fields they explicitly want cleared. A saved draft does not grant
+permission to schedule or publish it. Deletion requires explicit approval of
+the exact draft and current version.
+
 ### Exact contact state and suppression
 
 `sd_contact_state` is local and account-scoped. It makes no Unipile, LinkedIn,
@@ -833,11 +855,12 @@ eligible to run. SignalDash limits are not LinkedIn-safe thresholds, and
 native LinkedIn activity can still race the final reads.
 
 
-### The human-approved campaign loop
+### Human-approved campaigns
 
-A campaign is exactly one thing: a connection request, then the approved
-message once that person accepts. It is the only place SignalDash acts after an
-acceptance, and it acts only on the exact text a human read and approved.
+A campaign sends a connection request and may stop there. When it has an
+approved message sequence, SignalDash continues only after acceptance is
+proven and acts only on the exact text a human read and approved. A connect-only
+campaign never watches acceptance and completes after its invitations are sent.
 
 What the server proves, and refuses to assume:
 
@@ -866,16 +889,17 @@ What the server proves, and refuses to assume:
 
 Use the campaign tools in this order:
 
-1. Get the exact people and the exact words from the human. Draft the messages
-   in the user's own voice and keep them short: the on-acceptance group is two
-   or three separate sends, never one block. Never invent a recipient or a
+1. Get the exact people and whether the campaign is connect-only. For a message
+   campaign, get the exact words from the human. Draft the messages in the
+   user's own voice and keep them short: the on-acceptance group is two or
+   three separate sends, never one block. Never invent a recipient or a
    sentence. Ask whether they already sent any of these people a connection
-   request themselves; if so, mark that target `adopt_existing_invitation`
-   instead of dropping them.
+   request themselves; for a message campaign, mark that target
+   `adopt_existing_invitation` instead of dropping them.
 2. Call `sd_campaign_create` once.
 3. Poll `sd_campaign_preview` until the campaign is `previewed` or terminal.
-   Show the human every recipient, every exclusion and its reason, and the exact
-   text of every message step.
+   Show the human every recipient, every exclusion and its reason, and either
+   the exact text of every message step or the explicit connect-only statement.
 4. Relay the returned `approval_url`. The human authenticates with the
    SignalDash invite credential, reads the rows, ticks the recipients they
    approve (none are preselected), and acknowledges the consequences. They then
@@ -884,8 +908,10 @@ Use the campaign tools in this order:
    bearer token cannot approve, and you cannot mint that code. Five failed
    credential attempts durably block that campaign's authentication surface for
    15 minutes.
-5. Watch progress with `sd_campaign_status`. Report acceptances, replies,
-   exclusions, and parse failures honestly, including people who never accepted.
+5. Watch progress with `sd_campaign_status`. A connect-only campaign completes
+   after its invitations are sent. For a message campaign, report acceptances,
+   replies, exclusions, and parse failures honestly, including people who never
+   accepted.
 6. To stop, inspect first, show the exact state and `approval_view_hash`, obtain
    cancellation approval, then call `sd_campaign_cancel` once with that hash and
    `confirm:true`.
@@ -918,14 +944,14 @@ them out. It inverts one check and nothing else:
 - at most 10 adopted targets per campaign: each one costs one profile read in
   the preview to resolve its provider id.
 
-Everything after that is identical to any other target. Acceptance is still
-proven only by a fresh profile read showing a connected network distance, the
-messages still need their own approval on the same page, the thread is still
-read before the first message, and anything in that thread the campaign did not
-send halts the sequence permanently. If the recipient answered the invitation
-note without accepting, that conversation already exists and the target is
-dropped with `existing_conversation`: it is a human conversation in progress,
-not a campaign to resume.
+For a campaign with messages, everything after that is identical to any other
+target. Acceptance is still proven only by a fresh profile read showing a
+connected network distance, the messages still need their own approval on the
+same page, the thread is still read before the first message, and anything in
+that thread the campaign did not send halts the sequence permanently. If the
+recipient answered the invitation note without accepting, that conversation
+already exists and the target is dropped with `existing_conversation`: it is a
+human conversation in progress, not a campaign to resume.
 
 The acceptance window (`invite_ttl_days`) for an adopted target is counted from
 the moment SignalDash adopts it, not from the hand-sent invitation, whose age
@@ -1366,8 +1392,9 @@ 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`.
+locks. The same exact comment reply text is allowed up to ten times per sender
+per UTC day; the eleventh is refused as `duplicate_comment_text`. A true resend
+to the SAME comment stays blocked by the idempotency key regardless.
 
 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

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

@@ -88,8 +88,9 @@ On no, call `sd_secretary_reject` for that exact disposition and send nothing.
 - 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
+- The same exact comment reply text is allowed up to ten times per UTC day,
+  which covers a human replying briefly and repeatedly. The eleventh is
+  refused 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