@floomhq/signaldash 0.44.1 → 0.44.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +25 -1
- package/package.json +1 -1
- package/skills/signaldash/SKILL.md +4 -0
package/README.md
CHANGED
|
@@ -121,7 +121,7 @@ setup installs both from the same pinned npm package
|
|
|
121
121
|
the human chose to execute:
|
|
122
122
|
|
|
123
123
|
```bash
|
|
124
|
-
npx -y @floomhq/signaldash@0.44.
|
|
124
|
+
npx -y @floomhq/signaldash@0.44.2 <invite-code>
|
|
125
125
|
```
|
|
126
126
|
|
|
127
127
|
Run that command in a terminal, not in an agent chat. Do not ask an agent to
|
|
@@ -411,6 +411,13 @@ re-read itself fails, the send is refused with
|
|
|
411
411
|
and unknown is not permission. All three refusals happen before anything is
|
|
412
412
|
reserved, so none of them costs send budget.
|
|
413
413
|
|
|
414
|
+
If the provider's chat lookup itself hangs, a live WhatsApp send proves the
|
|
415
|
+
recipient from the chat's attendees and newest message instead: one counterpart
|
|
416
|
+
whose WhatsApp id equals the thread's, in this account and this chat. Every guard
|
|
417
|
+
above then runs on that record. Without that proof the send is refused with
|
|
418
|
+
`503 recipient_unverified`, before anything is reserved or written. Groups, chats
|
|
419
|
+
known only by an `@lid` id and empty threads cannot be proven this way.
|
|
420
|
+
|
|
414
421
|
A provider answer this process cannot read counts as a re-read that failed, not
|
|
415
422
|
as an empty conversation. Only the two documented list envelopes are hashed;
|
|
416
423
|
anything else yields no hash at all, so a read that hits a drifted shape records
|
|
@@ -995,3 +1002,20 @@ resolves those credentials itself, in the child process, from the file named by
|
|
|
995
1002
|
`SIGNALDASH_TRANSCRIBE_AWS_ENV_FILE`. The gateway process forwards only
|
|
996
1003
|
configuration, never a secret. That backend reports `language` as `null`: it is
|
|
997
1004
|
asked for the transcript text and nothing else.
|
|
1005
|
+
|
|
1006
|
+
### Recover an expired operator session
|
|
1007
|
+
|
|
1008
|
+
`POST /admin/recover_session` is a local-admin-only maintenance operation. It
|
|
1009
|
+
accepts exact `source_session_hash` and `target_session_hash` identifiers,
|
|
1010
|
+
`confirm: true`, and a written `reason`. The source must be expired but not
|
|
1011
|
+
revoked; the target must be active, empty, and belong to the same `data_ref`.
|
|
1012
|
+
Every source channel must still resolve to the exact ready provider account,
|
|
1013
|
+
and no other live person may own it. Recovery stores an audit record on the
|
|
1014
|
+
target and leaves the old session expired. It does not replay scheduled writes,
|
|
1015
|
+
copy tokens, change budgets, or weaken the public login/claim guards.
|
|
1016
|
+
|
|
1017
|
+
The normal local admin credential is required and Cloudflare-forwarded requests
|
|
1018
|
+
are refused. Operators should resolve identifiers inside the maintenance process
|
|
1019
|
+
from the native session store; never print bearer tokens or put them in shell
|
|
1020
|
+
arguments. After recovery, verify each requested channel through SignalDash
|
|
1021
|
+
before any previously approved action proceeds.
|
package/package.json
CHANGED
|
@@ -1321,6 +1321,10 @@ same fact: no answer about whether the conversation moved. In that case a `428
|
|
|
1321
1321
|
read_before_send_required` on the next attempt is expected too, because a read
|
|
1322
1322
|
of an unrecognised shape records no authorization.
|
|
1323
1323
|
|
|
1324
|
+
A `503 recipient_unverified` on a WhatsApp send means the provider's chat lookup
|
|
1325
|
+
hung and the recipient could not be proven another way. Nothing was sent. Retry
|
|
1326
|
+
later; never look for a similarly named chat to send into instead.
|
|
1327
|
+
|
|
1324
1328
|
A confirmed send advances the stored proof. Distinct consecutive messages can
|
|
1325
1329
|
therefore pass without a fresh read when the only movement is this account's
|
|
1326
1330
|
own outbound. Every send still re-reads the provider thread, and a counterparty
|