@tinycloud/cli 1.1.0 → 1.2.0-beta.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tinycloud/cli",
-  "version": "1.1.0",
+  "version": "1.2.0-beta.0",
   "description": "TinyCloud CLI - manage data, delegations, and nodes from the terminal",
   "author": "TinyCloud, Inc.",
   "license": "EGPL",
@@ -31,10 +31,10 @@
   "dependencies": {
     "@tinycloud/share-sdk": "1.1.0",
     "@tinycloud/share-envelope": "1.1.0",
-    "@tinycloud/node-sdk": "3.1.0",
+    "@tinycloud/node-sdk": "3.2.0-beta.0",
     "@tinycloud/node-sdk-wasm": "1.7.7",
-    "@tinycloud/sdk-core": "3.1.0",
-    "@tinycloud/operations": "0.4.0",
+    "@tinycloud/sdk-core": "3.2.0-beta.0",
+    "@tinycloud/operations": "0.5.0-beta.0",
     "chalk": "^5.3.0",
     "commander": "^14.0.0",
     "open": "^11.0.0",

package/skills/tc-cli/AUTH.md

@@ -105,17 +105,29 @@ tc --profile PROFILE auth request --manifest FILE --grant --device
 
 ## Imported delegations and their request bindings
 
-Delegations stored in a profile's `additional-delegations.json` are installed again on every later command. A compact-UCAN delegation, or a signed-login (CACAO) grant stored with its `siweProof`, is installed only through validated activation, and only when its record carries an `authorityRequest` binding whose `requested` capabilities contain everything the delegation's signed bytes grant. A delegation broader than its binding is refused before it is activated. The CLI, `tc secrets get`, and MCP tools all apply this rule. A stored record whose `delegationHeader` is anything but a single string `Authorization` installs nothing.
+Delegations stored in a profile's `additional-delegations.json` replay only into that profile's restored session. Compact-UCAN and signed-login (CACAO) grants must carry a verifiable proof and a valid `authorityRequest` binding whose `requested` capabilities contain all of their signed authority. The CLI, `tc secrets get`, and MCP tools all apply this rule; expired records and cross-user compact grants with a verified CID, signature, and signed audience matching the stored transport audience are skipped silently, while refused replay candidates produce fixed-code `STORED_GRANT_SKIPPED` warnings. A stored record whose `delegationHeader` is anything but a single string `Authorization` installs nothing.
 
 - **Request-bound import.** `tc auth import` of an artifact with a `requestId` (from `tc auth grant`, or MCP `tinycloud_auth_import`) binds the delegation to the stored request it was checked against. Importing a stored delegation again this way replaces its record and binding.
-- **Import without a request.** `tc auth import` of a bare portable delegation, a stored record, or an envelope with no `requestId`, addressed to this profile's session key, is validated the same way and bound to exactly its own signed capabilities: request ID `unbound-import:<cid>`, with an `authorityRequestAudit` note. No request limits it: the profile gets the delegation's full signed authority, whatever the artifact's `permissions` say. To limit what a delegation may grant, import it against a request instead (`tc auth request --emit`, then `tc auth grant` by the owner, then `tc auth import` of the result). This route never replaces or weakens a binding already stored for the same CID. A delegation whose `delegationHeader` is anything but a single string `Authorization` is refused with `INVALID_AUTH_IMPORT`.
-- **One-time migration.** Records stored by earlier releases have no binding. The first command that restores the profile's own session binds each one to exactly its own signed capabilities (`migrated:<cid>`, audit note `source: "migration"`) and writes `delegation-binding-migration.json` in the profile directory, listing the CIDs it bound and the ones it left unbound. A migrated record never grants more than it did before. A record that cannot be bound (expired, for another session key, malformed, or signing capabilities no request can hold) stays unbound and installs nothing afterwards; the others are still migrated. Migration is best-effort and restartable: it runs under the profile lock, only while the stored session is still the one the command restored, writes the bound records first and the marker last, and a command that is interrupted or finds the lock busy leaves the rest to the next command. Bindings already written are kept.
-- **After migration**, a compact-UCAN record without a valid binding installs nothing. For example, a delegation an older release imported, or a record pasted into the file. To recover it, run `tc auth import` on the artifact again with this release, or import a request-bound artifact for it.
+- **Import without a request.** `tc auth import` of a bare portable delegation, a stored record, or an envelope with no `requestId`, addressed to this profile's session key, verifies it and binds it to exactly its own signed capabilities: request ID `unbound-import:<cid>`, with an `authorityRequestAudit` note. A signed-login grant must carry its SIWE message and signature; an unproved session-addressed grant fails with `INVALID_AUTH_IMPORT`, and one with an invalid proof fails with `DELEGATION_REJECTED` without being saved. No request limits a valid import: the profile gets the delegation's full signed authority, whatever the artifact's `permissions` say. To limit authority, import against a request instead (`tc auth request --emit`, then `tc auth grant` by the owner, then `tc auth import`). This route never replaces or weakens an existing binding for the same CID.
+- **Proofless cross-user imports.** A portable grant with no signed proof is refused with `INVALID_AUTH_IMPORT` even when addressed to another key. It is not written to the profile or grant history and cannot produce repeated replay warnings.
+- **One-time migration.** Records stored by earlier releases have no binding. The first command that restores the profile's own session binds each verifiable record to exactly its own signed capabilities (`migrated:<cid>`, audit note `source: "migration"`) and writes `delegation-binding-migration.json`, listing bound and unbound CIDs. Records without proof cannot be migrated. Migration is best-effort and restartable under the profile lock: an interrupted run or a busy lock defers remaining records to the next command. The runtime never installs an unbound record during that wait or afterward; it reports `unbound` (or `proof_missing` for records without proof).
 - Older releases ignore the new fields. They do not enforce bindings, and an older `tc auth import` of a CID that is already stored replaces its record with an unbound one, which this release then refuses until it is imported again.
-- **CLI grants.** Signed-login grants from `tc auth request --grant` (OpenKey or local key) and secret-read approvals are checked against the request they answer, then stored with their `siweProof` and bound to exactly their own signed capabilities, read through the same validated activation replay uses (request ID `cli-grant:<cid>`, audit note `source: "cli-grant"`). The CLI, `tc secrets get` and MCP tools all install them under the rule above. A local-key grant of only raw decrypt on the owner's network names no space; it is verified and stored like any other grant. A new grant never replaces a stored record for the same CID that carries a binding. Signed-login grants stored by earlier releases carry neither proof nor binding: the CLI installs them as before, and the operations runtime does not use them (`proof_missing`). A signed-login record that carries an `authorityRequest` but no `siweProof` cannot be held to its binding and installs nothing; one with a `siweProof` but no valid binding installs nothing either (`unbound`). A cross-user delegation (addressed to the profile's identity rather than its session key) is not installed at all; `secrets get --delegation` reads it directly.
+- **CLI grants.** Signed-login grants from `tc auth request --grant` (OpenKey or local key) and secret-read approvals are checked against the request they answer, then stored with their `siweProof` and bound to their signed capabilities (`cli-grant:<cid>`). A local-key grant of only raw decrypt on the owner's network names no space; it is verified like any other grant. A new grant never replaces an existing bound record for the same CID. Earlier CLI releases stored signed-login grants without a proof: these are now refused with `proof_missing` on every replay path, even if a binding was later added. A grant with proof but without a valid binding reports `unbound`; cross-user delegations addressed to the profile's identity rather than its session key remain separate and are not installed by replay.
 
 The binding is local profile data. It stops records written by other paths from granting authority. A request binding limits a stored grant to its signed authority, but it does not prove where the record came from: anyone who can write the profile store and holds a valid grant for this session key can add one. It does not stop someone who can write the profile directory, who already holds the session key and the signed bytes.
 
+## Stored grants
+
+`tc --profile PROFILE auth grants list --json` reads only the local profile; it makes no node request. Its `session` includes the recomputed session CID when available. Each row reports the stored CID (only if CID-shaped), expiry, source, binding, proof kind, effective scope or stored scope, and `local` verification separately from `node: "not_checked"`. `for_another_key` means the stored audience names another key: this session cannot install it, and its displayed scope is stored metadata rather than locally verified authority. For session-targeted grants, local verification checks compact signatures, CIDs, audience, expiry, resources and binding; for CACAO it checks the owner's signature, audience, lifetime, ReCap, CID and binding. The node still checks delegation chains and revocation, so `local: "verified"` alone is not proof of access. Neither host, request ID nor audit note appears in this output.
+
+The `for_another_key` label requires a valid signed compact audience and CID matching the stored Authorization, plus a matching stored `delegateDID`; an edited transport audience or invalid proof is refused with a reason instead. A double `Bearer` prefix is refused; a single prefix is removed before activation.
+
+`tc --profile PROFILE auth grants remove <cid>` removes all local rows with that exact CID, without contacting the node; delegates may do this. An owner can add `--revoke --yes` to discover the verified local node (unless a host was explicitly selected), revoke there, then remove local rows only after successful revocation. Delegate-session profiles cannot use `--revoke`. If revocation succeeds but local removal fails, `GRANT_REVOKED_LOCAL_REMOVE_FAILED` includes a hint to retry `auth grants remove <cid>` **without** `--revoke`. `tc delegation revoke <cid>` also revokes a CID directly when its target is known. OpenKey cannot sign raw `urn:cid` ReCap authority today: owner OpenKey revocation falls back to command-scoped `delegation/revoke` on an owner-signed CID-bound space, and fails immediately when no verified fallback space exists. The JavaScript SDK cannot currently issue a delegatee self-revocation, although the node accepts one. Local removal is not revocation.
+
+If another process already removed the row after the node revoke, `--revoke` succeeds with `removed: 0`. Other post-revoke local removal errors include the underlying `error.meta.causeCode` (for example `PROFILE_LOCK_TIMEOUT`) so automation can distinguish lock contention from a node failure.
+
+To replace an old grant without a proof, an owner can approve again with `tc auth request --grant [--device]`, then remove the old CID. A delegate can emit a request with `tc auth request --emit`, have the owner run `tc auth grant`, import the signed result with `tc auth import`, then remove the old CID. If the original artifact still includes `siweProof`, importing it again is also possible.
+
 ## Unscoped login and sign-out
 
 `tc init` and `tc auth login` without a manifest request broad default-space consent, including writes, and replace the profile's session as before. Prefer `init --key-only` followed by a scoped login. They still verify OpenKey's signed proof whenever it carries one, the profile records an owner, or `--expiry` is given, and they keep the recorded owner. Non-interactive `auth login` never switches to device mode on its own, and never waits on a browser that cannot open: without `--device --manifest`, `--paste` or `--no-popup` it fails fast with `INTERACTIVE_LOGIN_REQUIRED`.

package/skills/tc-cli/REFERENCE.md

@@ -5,7 +5,7 @@ This release has **Commander coverage tracked, not complete parity**:
 
 - 1 migrated registration(s).
 - 1 partially migrated registration(s).
-- 122 legacy registration(s) remain Commander-owned.
+- 125 legacy registration(s) remain Commander-owned.
 
 - `auth import [source]` → `tinycloud.auth.import@1` (partial; legacy inputs: v1 delegation artifact, v1 permission artifact without command, bare portable delegation, stored delegation wrapper, cross-user delegation persisted with activated=false).
 - `secrets get <name>` → `tinycloud.secrets.get@1` (migrated).
@@ -80,7 +80,23 @@ tc delegation revoke <cid>
 
 Actions are auto-prefixed with `tinycloud.` if not already.
 
-`tc auth import` stores delegations in the profile's `additional-delegations.json`; a compact-UCAN delegation addressed to the profile's session key is stored with an `authorityRequest` binding. Later commands install such a delegation only when its signed capabilities fit inside that binding. [AUTH.md](AUTH.md#imported-delegations-and-their-request-bindings) describes how each import route binds a delegation, the one-time migration of records from earlier releases, and how to recover a record that installs nothing.
+`tc auth import` stores delegations in `additional-delegations.json`. Every replay path installs only a grant with a locally verified proof and a binding containing its signed authority; unbound and proof-less grants never install, including while migration is deferred. [AUTH.md](AUTH.md#imported-delegations-and-their-request-bindings) covers migration and recovery.
+
+### Stored grants
+
+```bash
+tc --profile PROFILE auth grants list --json
+tc --profile PROFILE auth grants remove <cid>
+tc --profile PROFILE auth grants remove <cid> --revoke --yes
+```
+
+`list` is local and does not contact the node. Its JSON contains `profile`, `session` (`cid` recomputed from stored header and `expiresAt`, or `null`), `localVerification` (`available`, `session_missing`, `session_expired`, `session_invalid`), and `grants`. Each indexed grant row contains `cid` (CID-shaped or `null`), `expiry`, `expired`, `local` (`verified`, `refused`, `not_checked`, `for_another_key`), `reason` (fixed skip code or `null`), `node: "not_checked"`, `bound`, `proof` (`siwe`, `compact`, `missing`, or `null`), `source`, `scope`, and `scopeSource` (`signed` or `stored`). `for_another_key` means the stored audience names another key; its scope is unverified stored metadata and it cannot install in this session. Local verification checks signed scope and binding, not the node's delegation chain or revocation status. Human output shows `CID | LOCAL | EXPIRES | SOURCE | BOUND | SCOPE` and the session CID.
+
+`for_another_key` is decided from a verified signed compact audience, CID, and matching transport DID, not an unsigned `delegateDID` alone. Tampered records retain their refusal reason, and proofless records retain `proof_missing`.
+
+Local `remove` deletes every row matching that exact CID, and is available to delegates. `--revoke` alone is owner-only: it uses normal verified local-node discovery unless a host is explicit, revokes on the node, and removes the rows only after success. If the local removal then fails, `GRANT_REVOKED_LOCAL_REMOVE_FAILED` directs a local-only retry without `--revoke`. OpenKey cannot sign raw `urn:cid` authority on the deployed version; owner OpenKey revocation uses a verified CID-bound owner-space fallback, or immediately fails `RAW_RECAP_RESOURCE_UNSUPPORTED`. Local removal does not revoke the delegation; delegated sessions cannot use `--revoke` because this SDK cannot issue a delegatee self-revocation.
+
+A concurrent local removal after revocation reports `removed: 0` as success. Other local cleanup failures include `error.meta.causeCode` (for example `PROFILE_LOCK_TIMEOUT`).
 
 ## Spaces