@floomhq/signaldash 0.39.19 → 0.41.0

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.19 <invite-code>
+npx -y @floomhq/signaldash@0.41.0 <invite-code>
 ```
 
 Run that command in a terminal, not in an agent chat. Do not ask an agent to
@@ -145,24 +145,46 @@ SignalDash exposes:
 - `sd_inspiration_import(source, source_author?, federico_note?, purpose?, content_kind?, credit_required?, credit_note?, format_description?)`
 - `sd_inspiration_channel_configure(chat_id, provider_id, chat_name, confirm)`
 - `sd_inspiration_channel_set(capture_enabled, confirm)`
+- `sd_x_signal_set(enabled, confirm)`
+- `sd_x_signal_import(feed, claim_key, topic, title, claim_text, source, snapshot, confirm)`
+- `sd_x_signal_add_evidence(id, expected_version, source_kind, source, confirm)`
+- `sd_x_signal_propose(id, expected_version, proposed_text, proposed_claims, confirm)`
+- `sd_x_signal_list(feed, state?, limit?)`
 - `sd_secretary_approve(disposition_id, payload_hash, confirm)`
 - `sd_secretary_reject(disposition_id, confirm)`
 - `li_list_chats`
 - `li_read_messages(chat_id)`
+- `li_get_attachment(chat_id, message_id, attachment_id)`
 - `li_mark_read(chat_id)`
 - `li_start_chat(member_ids, text, confirm?, approval_hash?, dry_run?)`
-- `li_send_message(chat_id?, text?, expected_watermark?, mark_read?, secretary_receipt_id?)`
+- `li_send_message(chat_id?, text?, expected_watermark?, mark_read?, secretary_receipt_id?)` — confirmed sends clear unread by default; `mark_read:false` preserves unread.
 - `li_send_invitation(provider_id, note?, confirm?)`
 - `li_invitations_received(limit?, cursor?)`
 - `li_accept_invitation(invitation_id, confirm)`
 - `li_invitations_sent(limit?, cursor?)`
 - `li_withdraw_invitation(invitation_id, confirm)`
+
+The X signal collector is a manual, review-first command. It pins the exact
+Apify actor build, caps each feed at 25 complete dataset rows and $0.05, stores
+the exact raw row plus run/query provenance, and imports no LinkedIn draft:
+
+```bash
+APIFY_API_TOKEN=... node scripts/collect-x-signals.mjs \
+  --feed fede --feed rocketlist --confirm
+```
+
+The deployment capability and the authenticated SignalDash user's setting must
+both be enabled. Re-running a completed observation is deterministic; a newer
+observation adds an immutable engagement snapshot. The command creates no
+timer, scheduler entry, Buffer item, or provider write.
 - `sd_contact_state(channel, identifiers, action?, reason?, confirm?)`
 - `sd_budget_status()`
 - `sd_settings_get()`
 - `sd_settings_set(auto_accept_linkedin, auto_accept_linkedin_filters?, confirm)`
 - `sd_auto_accept_status()`
 - `sd_voice_profile(channel, force_recompute?)`
+- `sd_content_automation_report(automation_key, name, schedule, state, confirm, description?, detail?, step?, next_run_at?, artifact_kind?, artifact_id?)`
+- `sd_content_automations()`
 - `li_search_connections(query, filters?, limit?)`
 - `li_discover_people(query, filters?, limit?, confirm?)`
 - `li_create_invitation_batch(source_label, time_zone, targets)`
@@ -182,8 +204,8 @@ SignalDash exposes:
 - `wa_mark_read(chat_id)`
 - `wa_get_attachment(chat_id, message_id, attachment_id)`
 - `wa_transcribe_voice(chat_id, message_id, attachment_id)`
-- `wa_start_chat(member_ids, text, confirm?, approval_hash?, dry_run?)`
-- `wa_send_message(chat_id, text?, attachments?, expected_watermark?, mark_read?)`
+- `wa_start_chat(member_ids, text, subject?, confirm?, approval_hash?, dry_run?)`: `subject` names a new group (2+ members) and is bound into the approval.
+- `wa_send_message(chat_id, text?, attachments?, expected_watermark?, mark_read?)` — confirmed sends clear unread by default; `mark_read:false` preserves unread.
 - `wa_delete_message(chat_id, message_id)`
 - `wa_delete_messages(messages)`
 - `email_list(limit)`
@@ -196,7 +218,8 @@ SignalDash exposes:
 - `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_delete_post(post_id, expected_text_prefix, confirm)` (own post only, bound account only, capability `linkedin_post_delete`)
+- `li_draft_post(text, publish, scheduled_at?, content_pipeline_id?, content_pipeline_override?, mentions?, attachments?, first_comment?, confirm?, approval_hash?)`
 - `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()`
@@ -211,6 +234,10 @@ SignalDash exposes:
 - `sd_schedule_message(channel, chat_id, text, scheduled_at, confirm)`
 - `sd_scheduled_messages(state?, channel?)`
 - `sd_cancel_scheduled_message(id, confirm)`
+- `sd_followup_create(channel, thread_id, context, due_at, completion_condition?, auto_close_on_reply?, recipient_label?, origin?, source_message_id?, baseline_at?)`
+- `sd_followups(status?, channel?, overdue?)`
+- `sd_followup_cancel(id, confirm)`
+- `sd_followup_complete(id, confirm)`
 
 Every operation runs through the hosted SignalDash backend. Agents never
 receive the Unipile access key.
@@ -272,13 +299,13 @@ whatever the page's completeness, because presence on an incomplete page is
 still presence. `replied_by_me:false` is emitted only when the reply set is
 provably whole, every reply carries a resolvable `author_details.id`, ids are
 unique, every reply belongs to this thread, and no reply is the account
-owner's. Two proofs are accepted: the provider reporting the reply page
-complete, or a zero `reply_counter` together with a reply read that came back
-empty, which is the same pair the reply preflight already requires.
-`replies_read === reply_counter` is deliberately NOT a proof; both numbers are
-returned so a caller can see the corroboration, but SignalDash will not convert
-it into a boolean, because a wrong `false` makes an agent talk over the account
-owner in public. Everything else is `replied_by_me:null` with an explicit
+owner's. Three proofs are accepted: the provider reporting the reply page
+complete; a zero `reply_counter` together with a reply read that came back
+empty; or a single cursorless reply page, shorter than the requested limit,
+holding at least `reply_counter` replies (`reply_counter_met_on_short_page`).
+The reply and like preflights accept the same three. A cursor, a full page, a
+missing counter, or fewer replies read than the counter claims stays unproven,
+because a wrong `false` makes an agent talk over the account owner in public. Everything else is `replied_by_me:null` with an explicit
 reason. The flag is off by default and unresolved comments still carry
 `reply_state.state = "unknown"`, so a miss is never mistaken for a proven
 absence. Resolution is bounded per request by
@@ -380,11 +407,50 @@ comment have human approval. The stored image bytes and comment text cannot
 drift after approval. The scheduler publishes the comment through the same
 connected LinkedIn account immediately after the post. It persists the post ID
 before attempting the comment, so a comment failure never republishes the post.
+On the `li_draft_post` create path, every future post with `attachments` and no
+`content_pipeline_override` must first preview the exact payload without
+`confirm`, then repeat it with `publish:true`, `confirm:true`, and that preview's
+single-use `approval_hash`.
 The scheduler
 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.
 
+A post carries either images or one video, never both. An image is still
+carried as `content_base64` inside the request body. A video is carried as
+`content_url`: one absolute https URL, at most 64 MiB, whose bytes are streamed
+once at publish time and never stored. 31 MB of mp4 is ~42 MB of base64, which
+would have to survive a JSON parse and then live in the `attachments_json` cell
+that is re-read on every list of the queue, so storing the URL is the point
+rather than a convenience. LinkedIn's own feed-video limit is 200 MB; the lower
+ceiling here is because the multipart encoder buffers the body and then
+concatenates it, so a publish holds roughly twice the video in memory.
+
+That fetch is fenced, because a server that follows a URL its caller supplied
+is otherwise an SSRF hole: https only; every resolved address checked against
+the private, loopback, link-local, unique-local and reserved ranges in IPv4 and
+IPv6, with the connection pinned to the address that passed so a second
+resolution cannot substitute a private one; every redirect re-running the whole
+check under a hop cap; the ceiling enforced mid-stream rather than from a
+Content-Length the same server supplied; one deadline across the whole
+operation; and an arriving Content-Type that must equal the declared one. The
+fetch runs before the provider write, so a URL that has gone dead costs no
+action budget, no idempotency record and no sender lock: the row lands on
+`failed` carrying the exact refusal code.
+
+Two things the fence alone does not give. The arriving `Content-Type` is a
+claim by the server being distrusted, so the bytes must additionally open with
+an ISO `ftyp` box or the publish fails `media_not_a_video`. And because the
+bytes are fetched later, approving a video approves a URL: whoever controls
+that host decides what reaches LinkedIn between the approval and the scheduled
+minute. An attachment may therefore carry `content_sha256`, the exact lowercase
+hex SHA-256 of the file; the fetched bytes are hashed and compared before
+anything is handed to the multipart encoder, and a mismatch fails the row
+`media_digest_mismatch`. It is bound into the approval hash alongside the URL,
+so an approval never covers a different video. Without it the guarantee is only
+that the URL did not change after approval, which is why the review page shows
+the URL itself rather than a label.
+
 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.
@@ -494,8 +560,9 @@ their normal expiry.
 
 `li_scheduled_post_attachment` is the agent-side path to the same stored bytes
 the preview page renders, without a browser session: it returns one attachment
-of one active post as `content_base64` with its `filename` and its stored
-`content_type` verbatim. It is scoped by the same `data_ref` and the same
+of one active post with its `filename` and its stored `content_type` verbatim,
+as `content_base64` for an image or as `content_url` for a video whose bytes
+are never stored here. It never fetches a URL on a caller behalf. It is scoped by the same `data_ref` and the same
 draft/scheduled/executing filter as `li_scheduled_post_preview`, so a cancelled
 or published post, a foreign post, and a missing index are one indistinguishable
 404. The bytes are deliberately not part of the preview response, which reports
@@ -741,6 +808,17 @@ untracked files, and submodule state present when the process started.
 service restart. It defaults to enabled and exposes no credential, account, or
 message data.
 
+The sanctioned WhatsApp sender is tracked at `ops/signaldash-wa-send`. Install
+that exact reviewed helper with:
+
+```bash
+sudo install -m 0755 ops/signaldash-wa-send /usr/local/bin/signaldash-wa-send
+```
+
+The helper rejects Unicode U+2014 locally. The server repeats the same check at
+the authoritative write boundary so older clients and alternate callers cannot
+bypass it.
+
 ## Releasing
 
 A release is a tag push. `.github/workflows/release.yml` runs `./release.sh` on