primcli 3.0.0-preview.5 → 3.0.0-preview.6

package/README.md

@@ -219,15 +219,15 @@ boundary to at most 60 characters. The whole message is the body.
 
 ## Authentication
 
-Use `primitive signin` or `primitive login` for existing accounts. With no email, both use browser approval; `primitive signin browser` and `primitive login browser` are the explicit browser forms.
+Use `primitive signin` or `primitive login` to log in. With no email, both use browser approval; `primitive signin browser` and `primitive login browser` are the explicit browser forms.
 
-Use `primitive signin <email> --accept-terms`, then `primitive signin confirm <email> <code>` for email-code sign-in. `primitive login <email>` and `primitive otp <email>` support the same email-code flow with matching `confirm` and `resend` subcommands.
+Use `primitive signin <email> --accept-terms`, then `primitive signin confirm <email> <code>` for email-code sign-in. `primitive login <email>` and `primitive otp <email>` support the same email-code flow with matching `confirm` and `resend` subcommands. The code logs you in to the account that uses the address, or creates a new account when none does. Primitive sends no emailed code to an address on a domain it receives mail for; log in with `primitive login browser` instead. Without a terminal to answer the terms prompt, these commands stop and ask for `--accept-terms`.
 
 Use `primitive logout --force` to remove local CLI credentials, pending email-code auth state, and stale credential locks without contacting Primitive. This is the recovery command when an interrupted auth command leaves the CLI saying another credential operation is already in progress.
 
-Use `primitive org leave` to leave the organization you are signed in to. It asks for confirmation first; pass `--yes` to skip the prompt in scripts. Leaving is final. Only a person signed in with `primitive login` can leave; API keys are refused. The only owner of an organization cannot leave it until someone else is made an owner. If the server asks you to confirm in the dashboard, the command prints the confirmation page and, in a terminal, asks for the token it shows; in a script, pass the token with `--step-up-token`. Refusals from the server are printed as returned, and the command exits 1.
+Use `primitive org leave` to leave the organization you are signed in to. It asks for confirmation first; pass `--yes` to skip the prompt in scripts. Leaving is final. Only a person signed in with `primitive login` can leave; API keys are refused. The only owner of an organization cannot leave it until someone else is made an owner. If the server asks you to confirm in the dashboard, the command prints the confirmation page and, in a terminal, asks for the token it shows; in a script, pass the token with `--step-up-token`. Refusals from the server are printed as returned, and the command exits 1. Without a terminal and without `--yes`, it exits 2 before anything is sent.
 
-Use `primitive signup <email>` for new account creation, then `primitive signup confirm <email> <code>` with the emailed verification code. Non-interactive signup is available with `--accept-terms`.
+Use `primitive signup <email>` for new account creation, then `primitive signup confirm <email> <code>` with the emailed verification code. Without a terminal, pass `--accept-terms`.
 
 ### Switching organizations
 
@@ -247,24 +247,25 @@ Against a server without organization switching, and for logins saved by earlier
 
 ### Grants and keys
 
-`primitive whoami` shows your organization, role and grant when the server reports them. `primitive whoami --check mail:send` asks whether the current credential may use a permission, prints the decision, and exits 1 when it may not; nothing is enforced by asking. A request refused because the credential's grant lacks a permission fails with `grant_forbidden`, and the CLI names the permission.
+`primitive whoami` shows your member address, your organization, your built-in role and the credential's grant when the server reports them; only a person's own login has a role line. `primitive whoami --check mail:send` asks whether the current credential may use a permission, prints the decision, and exits 1 when it may not; nothing is enforced by asking. A request refused because the credential's grant lacks a permission fails with `grant_forbidden`, and the CLI names the permission.
 
 ```bash
 primitive keys list
 primitive keys get <id> --json
 primitive keys create --name orders --permission mail:read --rule <rule-id>
 primitive keys update <id> --add mail:send,mail:reply
+primitive keys update <id> --expires-at 2027-02-08T00:00:00Z
 primitive keys rotate <id>
 primitive keys revoke <id>
 ```
 
 `keys list` shows each key's id, prefix, name, permissions, the mail it reaches, expiry and last use, and `keys get` shows one key in full. Neither shows a secret. You see your own keys, and every key if your role may read them all.
 
-`keys create` needs you to say what the key can do: a `--preset`, or `--permission` with the mail it reaches (`--address`, `--domain`, `--rule`, each repeatable, or `--all-mailboxes`). There is no default, and a super admin key needs `--preset super_admin`. A key never holds more than you do, and your organization's credential policy applies. `keys update` adds or removes permissions (`--add`, `--remove`) or replaces the key's email rules (`--rule`); the key keeps its id and secret. A request already held open with that key, such as a long poll or a wait, ends once when its permissions change.
+`keys create` needs you to say what the key can do: a `--preset`, or `--permission` with the mail it reaches (`--address`, `--domain`, `--rule`, each repeatable, or `--all-mailboxes`). There is no default, and a super admin key needs `--preset super_admin`. A key never holds more than you do, and your organization's credential policy applies. `keys update` adds or removes permissions (`--add`, `--remove`), adds or removes email rules (`--add-rule`, `--remove-rule`), or replaces them all (`--rule`); the key keeps its id and secret. A request already held open with that key, such as a long poll or a wait, ends once when its permissions change. `keys update --expires-at <time>` extends a key before it expires, within your organization's credential policy, and `--no-expiry` removes its expiry where the policy allows. Rotating keeps the expiry: `keys rotate` gives the new key the old key's expiry unless you pass `--expires-at` or `--no-expiry`. An expired key cannot be extended.
 
 Creating, rotating and changing a key run directly. If your organization requires approval, the command prints the approval link, opens it where it can, and waits for the one-time token the page shows. In a script it prints the link and exits: approve, then run it again with `--step-up-token`. The new secret is printed once, alone on stdout (or in the JSON with `--json`), and the CLI never saves it, so store it right away. `keys revoke` asks for confirmation; pass `--yes` in scripts.
 
-`primitive roles list`, `primitive roles groups`, `primitive roles mailbox-access` and `primitive roles access-mode` read roles, groups, mailbox access and the access mode. `primitive roles members` (also `primitive members list`) lists the members and their roles. Where the server has not enabled them, they print `feature_disabled`. The built-in roles are `owner`, `admin`, `operator` and `member`. `operator` has every permission `admin` has except managing members, changing roles, sending invitations and billing. By default, owners, admins and operators may use the CLI. An organization can open it to every member by setting `cli_access` to `all_members` in its credential policy.
+`primitive roles list`, `primitive roles groups`, `primitive roles mailbox-access` and `primitive roles access-mode` read roles, groups, mailbox access and the access mode. `primitive roles members` (also `primitive members list`) lists the members and their roles. Where the server has not enabled them, they print `feature_disabled`. The built-in roles are `owner`, `admin` and `member`. Operator is a template with every permission `admin` has except managing members, changing roles, managing mailbox delegations, sending invitations and billing. By default, owners, admins and operators may use the CLI. An organization can open it to every member by setting `cli_access` to `all_members` in its credential policy.
 
 ### Trying the preview