@tinycloud/cli 1.3.2-beta.0 → 1.3.2-beta.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tinycloud/cli",
-  "version": "1.3.2-beta.0",
+  "version": "1.3.2-beta.1",
   "description": "TinyCloud CLI - manage data, delegations, and nodes from the terminal",
   "author": "TinyCloud, Inc.",
   "license": "EGPL",

package/skills/tc-cli/REFERENCE.md

@@ -371,7 +371,7 @@ printf '%s' "$SHARE_URL" | "$TC" share inspect - --json               # verify,
 printf '%s' "$SHARE_URL" | "$TC" share receive - --stdout             # bearer link: verified bytes
 printf '%s' "$SHARE_URL" | "$TC" share receive - --output .
 
-"$TC" share list --json                                               # sender history, no complete URLs
+"$TC" share list --json                                               # sender history, no complete URLs; human rows are shareId, target, expiresAt, status (active, revoked or expired), tab-separated
 "$TC" share show <id> [--reveal-link]
 "$TC" share notify <id> --to alice@example.com                        # retry email delivery within 5 minutes of publication
 "$TC" share revoke <id>                                               # bearer or addressed share this profile created
@@ -400,6 +400,8 @@ The fragment after `#` is the read key. Browsers never send it to a server; `--n
 
 **Notification window.** The CLI requests a stable signed delivery authorization until the earlier of share expiry and 5 minutes after its sender-history `registeredAt` timestamp. The node allows an authorization no more than 5 minutes in the future; keeping the expiry stable also makes idempotent retries use the same request. After the window, `tinycloud share notify` prints `partial-failure` (exit 9; JSON `retryable: false`, `reason: "delivery-window-expired"`) and explains that the sender must publish a new share and invite the recipient then. `share publish --notify --json` includes the same failure under `notification`. A confirmed repeat within the window prints `already-delivered`; an unconfirmed failed attempt remains retryable until the window closes. If the sender history cannot record a successful delivery confirmation, the CLI warns on stderr but preserves the successful publish/notify result; a later repeat can report `delivered` again.
 
+**Email-addressed shares need decrypt.** An addressed share (`--to email:`, `did:`, `domain:`) is encrypted to the owner's encryption network, so the publishing session must hold `tinycloud.encryption/decrypt` on it. A local-key profile always does. A session-only sign-in such as `builtin:share-publishing` does not (the manifest deliberately omits it), and the CLI refuses before any upload, registry write or network call: `PERMISSION_DENIED`, exit 5, "this sign-in can't create email-addressed shares ... Nothing was shared." Share from https://share.tinycloud.xyz as the account owner, ask the owner to share it, or use `--to anyone`, which works from that sign-in.
+
 **History and node preflight.** Post-publication sender-history writes wait up to 45 seconds for another process's profile lock (including stale-lock recovery). If the first history write still fails, the CLI warns and keeps its normal exit status: human output still prints the published link, but `--json` output stays redacted, and because the share was not recorded, `share show <id> --reveal-link` cannot recover it either. A later `share list`, `share notify <id>`, or `share revoke <id>` cannot find that share by ID. An immediate `--notify` can still deliver using the in-process record. Other share-command profile-lock timeouts report `PROFILE_LOCK_TIMEOUT` with a retry hint. Standalone domain notification validates the recipient and expired delivery window locally before contacting `/info`: an expired window remains exit 9 even if the node is unavailable. A node-info transport failure, including a stalled response body, is `UNAVAILABLE` (exit 4); a completed but unsupported or malformed version is `INVALID_ARGUMENT` (exit 2). Publish-time refusals say nothing was shared and no invitation was sent; standalone notify refusals say no invitation was sent.
 
 **Concurrent history changes.** A Share command resolves its profile once for authentication and every sender-history operation, including retries; a later default-profile change cannot redirect a share link into another profile. If a write waits more than about 2 seconds to acquire the profile lock, the CLI writes one waiting notice to stderr naming that profile. A profile removed after an earlier history read or during an operation, or repeated key/salt changes, returns `SHARE_HISTORY_RETRY` (exit 1) with a retry hint; a profile missing from the outset still returns `PROFILE_NOT_FOUND` with the setup hint. If a history retry follows a revoke, check the node state before trying again: revocation might already have succeeded even though sender history could not record it.