@capxul/cli 4.20.0-beta.5 → 4.20.0-beta.7

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 CHANGED
@@ -1,7 +1,9 @@
1
1
  # Capxul CLI
2
2
 
3
- The CLI provides local diagnostics, an online backend check, and one global
4
- collection preference. It requires Node 24 or later on macOS or Linux.
3
+ The CLI provides email OTP login, persistent first-party sessions, terminal-owned
4
+ signup, personal and Organization contacts, a bundled Openfort wallet page,
5
+ backend profile and account reads, diagnostics, and one global collection
6
+ preference. It requires Node 24 or later on macOS or Linux.
5
7
 
6
8
  ```sh
7
9
  capxul --help
@@ -15,25 +17,231 @@ capxul doctor --online --timeout-ms 30000 --json
15
17
  ```
16
18
 
17
19
  Help and version do not require application credentials or a working backend.
20
+ With no arguments, `capxul` shows the same generated help as `capxul --help`.
18
21
  They use the same observation policy as ordinary commands. Shell completion
19
22
  machinery and collection controls send no observation records.
20
23
  `doctor` checks local configuration unless `--online` is present. An online
21
24
  check uses the public Capxul SDK and verifies the backend response nonce.
22
25
  It does not authenticate a person or submit a transaction.
23
26
 
27
+ ## Contact commands
28
+
29
+ ```sh
30
+ capxul contact list [--include-hidden]
31
+ capxul contact get --entry-id PARTY_ID
32
+ capxul contact add --input FILE|- [--confirm]
33
+ capxul contact label --entry-id PARTY_ID --label TEXT [--confirm]
34
+ capxul contact hide --entry-id PARTY_ID [--confirm]
35
+ capxul contact unhide --entry-id PARTY_ID [--confirm]
36
+
37
+ capxul org contact list --org ORGANIZATION_ID [--include-hidden]
38
+ capxul org contact get --org ORGANIZATION_ID --entry-id PARTY_ID
39
+ capxul org contact add --org ORGANIZATION_ID --input FILE|- [--confirm]
40
+ capxul org contact label --org ORGANIZATION_ID --entry-id PARTY_ID --label TEXT [--confirm]
41
+ capxul org contact hide --org ORGANIZATION_ID --entry-id PARTY_ID [--confirm]
42
+ capxul org contact unhide --org ORGANIZATION_ID --entry-id PARTY_ID [--confirm]
43
+ ```
44
+
45
+ Personal commands use the authenticated Account address book. Organization
46
+ commands require one explicit `--org` or `--org-id`; they never use the saved
47
+ Organization read default. `list` omits hidden entries unless
48
+ `--include-hidden` is present. `get`, `label`, `hide`, and `unhide` address one
49
+ stable Party with `--entry-id`.
50
+
51
+ `add --input` reads the existing `AddressBookAddInput` JSON shape. For example:
52
+
53
+ ```json
54
+ {
55
+ "ref": { "kind": "email", "email": "supplier@example.test" },
56
+ "label": "New Supplier"
57
+ }
58
+ ```
59
+
60
+ Use `--input -` to read the same object from stdin. An interactive `add` can
61
+ collect the reference kind, value, and optional label instead. Interactive
62
+ writes show the actor and exact contact change, then ask a default-no question.
63
+ JSON, CI, and other noninteractive writes require `--confirm` before the CLI
64
+ creates a client. Contact writes do not start a browser signer.
65
+
66
+ Success data is the SDK value without a CLI wrapper: `list` returns
67
+ `AddressBookEntry[]`, `get` returns `AddressBookEntry | null`, and each mutation
68
+ returns `AddressBookEntry`. Human `get` prints `No contact found` for null and
69
+ exits successfully. Entries retain their stable PartyId, exact reference,
70
+ relationships, hidden state, and last activity time.
71
+
72
+ ## Organization commands
73
+
74
+ ```sh
75
+ capxul org list --json
76
+ capxul org use --org ORGANIZATION_ID
77
+ capxul org status --org ORGANIZATION_ID --json
78
+ capxul org get --json
79
+ capxul org me --json
80
+ capxul org members --json
81
+ capxul org member list --json
82
+ capxul org member get --account-id ACCOUNT_ID --json
83
+ capxul org wait --timeout-seconds 120 --json
84
+ capxul org create --name NAME --handle HANDLE --country CC [--bio TEXT] [--size TEXT] [--confirm]
85
+ capxul org retry --org ORGANIZATION_ID [--confirm]
86
+ ```
87
+
88
+ These commands accept `--email`. Without it, they restore the protected current
89
+ session. Organization reads accept `--org` or its alias `--org-id`. Identical
90
+ repeated IDs are accepted. Different IDs are refused.
91
+
92
+ `org use` requires an explicit Organization ID. It checks current access and
93
+ saves a protected per-person read default. The default never grants authority.
94
+ Each read checks current access again. Without an explicit ID or saved default,
95
+ interactive mode asks you to select an Organization. JSON, CI, and noninteractive
96
+ mode refuse missing scope. No command starts a signer or changes backend state.
97
+
98
+ `org get` reports the canonical command `org.status`. Both member list forms
99
+ report `org.members` and retain pending members with `accountId: null`.
100
+ `org member get` matches the full AccountId, not a Safe address or ID prefix.
101
+ No match returns exit 2. Duplicate matches return exit 1.
102
+
103
+ `org wait` reads the same lifecycle every second until it reports `ready` or
104
+ `failed`. It never retries setup. The timeout accepts integers from 1 to 3600
105
+ seconds and defaults to 120. Timeout returns exit 5; interruption returns 130.
106
+ A successful read can report a failed or pending domain state.
107
+
108
+ ## Invitation commands
109
+
110
+ ```sh
111
+ capxul org invite list [--mine] [--limit N] [--cursor C] [--phase PHASE ...] [--org O]
112
+ capxul org invite get --invitation-id I [--org O]
113
+ capxul org invite wait --invitation-id I [--org O] [--timeout-seconds N]
114
+ capxul org invite review --invitation-id I --org O [--timeout-seconds N]
115
+ capxul org invite accept --invitation-id I --offer-digest D --org O [--confirm] [--timeout-seconds N]
116
+ capxul org invite decline --invitation-id I --org O [--confirm]
117
+ capxul org invite cancel --invitation-id I --org O [--confirm]
118
+ capxul org invite resend --invitation-id I --org O [--confirm]
119
+ capxul org invite retry --invitation-id I --org O [--confirm]
120
+ capxul org member invite (--to-email E | --account-id ID) [--budget-id B ...] [--permission-id M ...] [--new-budget-name N --asset A (--limit Q | --unlimited) (--recipient-account ID ... | --any-recipient) --actions pay[,commitments]] --org O [--request-key K] [--preview] [--confirm]
121
+ ```
122
+
123
+ `org invite list` returns your own offers. It accepts `--limit` (1--100),
124
+ `--cursor`, and repeated `--phase` values, and its result carries `invitations`,
125
+ `nextCursor`, and `observedAt`: pass `nextCursor` back as `--cursor`, and change
126
+ no other filter between the two calls. `--mine` names the own-offer projection,
127
+ which is already the default. With `--org O` the command returns that
128
+ Organization's invitations for a current Admin instead; the Organization list is
129
+ not filtered to you, so `--mine` together with `--org` refuses with exit 2. The
130
+ other invitation commands require an exact `--invitation-id`.
131
+
132
+ `org invite get` and `org invite wait` use `--org` when you name it. Without
133
+ `--org` they walk your own-offer pages, 100 rows per request, until they find
134
+ the invitation or the pages end. They never consult the saved read default, and
135
+ an offer you cannot see is refused. `--timeout-seconds` bounds the resolution
136
+ and the read together on both commands.
137
+
138
+ `org invite wait` only reads. It finishes when the offer settles or when the
139
+ recovery asks a person to act. It never retries, resends, or accepts.
140
+
141
+ `org invite review` requires `--org`, returns the current `InvitationView`
142
+ directly in `data`, and performs no write or signing.
143
+
144
+ The four transitions require `--org` in both modes, as `accept` does. They never
145
+ author a new offer. A noninteractive or JSON run requires `--confirm`. An
146
+ interactive run shows the resolved current offer and asks a default-no question.
147
+
148
+ `org member invite` authorizes one exact offer. `--preview` writes nothing and
149
+ needs neither a request key nor confirmation. A noninteractive write requires
150
+ `--request-key` and `--confirm`. An interactive run prints the request key it
151
+ used before it submits, so a lost response is recoverable with the same
152
+ identity. At most one `--new-budget-name` is accepted per command.
153
+
154
+ `org invite accept` is the exact grantee's consent commit. It takes the exact
155
+ digest the offer shows as `--offer-digest`: a noninteractive or JSON run must
156
+ supply it, and without it the command refuses with exit 2 before it creates a
157
+ client. An interactive run may omit it, and then reads the offer and fills the
158
+ digest from the value it displayed. A digest you state is never replaced by the
159
+ displayed one. `--expected-offer` remains a compatibility spelling, and both
160
+ spellings must match when supplied together. The command returns the
161
+ `InvitationView` directly in `data`. The grant is executed by the deployment's
162
+ technical executor, so the command needs no browser bridge and works in a
163
+ headless or CI session. A repeat with the stored digest returns the same
164
+ accepted result; a different digest refuses and cannot overwrite consent. The
165
+ returned view is the authorization-time view of the consent commit
166
+ (`pending_grant`); read the settled `active` state with `get` or `wait`.
167
+
168
+ ## Organization writes
169
+
170
+ `org create` and `org retry` restore the protected current session and start the
171
+ existing command-scoped browser signer. They never read or write the saved read
172
+ default. Local input checks run before any client, browser, or backend work, and
173
+ they include the confirmation gate:
174
+
175
+ - A noninteractive or JSON write requires `--confirm`. Without it the command
176
+ refuses with exit 2 before any client, browser, or mutation work.
177
+ - A terminal write verifies the session and performs its Organization reads
178
+ first, then prints the resolved preview and asks a default-no prompt, even when
179
+ `--confirm` is supplied. Rejection refuses with exit 2. An absent session is
180
+ exit 3 before any preview. The browser signer is built only after confirmation
181
+ succeeds, so a refused write never starts it.
182
+
183
+ `--email` selects the session explicitly. Otherwise the protected
184
+ current-session pointer decides. An invalid explicit email refuses with exit 2.
185
+
186
+ `--timeout-seconds` bounds the command's own wait, not backend execution. It
187
+ accepts integers from 1 to 3600 and defaults to 120, and it is one deadline for
188
+ the whole write: the `completeOrganization` or `retrySetup` call and the
189
+ settlement that follows share it. While a lane settles the command reads the
190
+ exact Organization lifecycle every second with no overlapping read. At the
191
+ deadline the active SDK signal is aborted, so the command stops waiting and
192
+ forwards no further signature, while the durable backend lane keeps running.
193
+ Committed lifecycle progress is flushed first, so the Organization ID stays on
194
+ stderr and the same Organization resumes with `org retry --org`. Exceeding the
195
+ deadline returns exit 5.
196
+
197
+ `org create` validates `--name`, the `--handle` grammar, and the ISO `--country`
198
+ code first, and its terminal preview also lists the Organizations the person
199
+ already has. It subscribes to the onboarding Organization-state projection, then
200
+ completes the Organization with an explicit create intent. The first committed
201
+ Organization ID is retained, and each committed lifecycle change is written to
202
+ stderr before the next Organization authorization digest reaches the signer.
203
+ JSON mode writes one newline-delimited progress object per change:
204
+
205
+ ```json
206
+ { "type": "organization.lifecycle", "organizationId": "O", "status": "settingUp" }
207
+ ```
208
+
209
+ Human mode prints the full Organization ID and lifecycle status. A refused or
210
+ failed lane still reports the Organization it is about. The command returns
211
+ success only after an exact `org(O).getLifecycle()` read reports `ready`. It
212
+ never saves a read default and never returns a different ready Organization.
213
+
214
+ `org retry` requires an explicit `--org` (or `--org-id`). It validates the ID
215
+ with the public `toOrgId` constructor, reads that exact Organization's lifecycle
216
+ for its terminal preview, resumes that same durable setup lane, then settles the
217
+ same Organization's lifecycle. A resumed lane that asks the
218
+ signer to reset its session clears the stale readiness, closes that browser
219
+ bridge, and opens the next one for the same command. `org retry` never creates a
220
+ replacement Organization and never changes the read default. An already-ready
221
+ Organization returns that exact readiness without a signature. A conflicting
222
+ failed or in-flight lane is preserved and refused.
223
+
224
+ The result data for both commands is `{ organizationId, lifecycle }`. A known
225
+ Organization ID on a `WRONG_STATE` refusal appears only in the SDK-supplied
226
+ `error.details.organizationId` field, and the refusal copy names the recovery
227
+ action instead of authentication guidance. No token, OTP, signature, or signer
228
+ capability is ever printed. Interruption returns 130 and closes both the
229
+ subscription and the browser bridge.
230
+
24
231
  ## Configuration
25
232
 
26
233
  | Variable | Use |
27
234
  | ------------------------------ | ------------------------------------------------------------------------------------------------------------ |
28
235
  | `CAPXUL_CLI_HOME` | Directory for global CLI settings. Defaults to `$XDG_CONFIG_HOME/capxul/cli`, or `$HOME/.config/capxul/cli`. |
29
- | `CAPXUL_PUBLISHABLE_KEY` | Application publishable key, required for an online check. |
30
- | `CAPXUL_BOOTSTRAP_URL` | Bootstrap origin. Defaults to `https://api.staging.capxul.com`. Convex Cloud origins are rejected. |
236
+ | `CAPXUL_PUBLISHABLE_KEY` | Optional developer override for the bundled first-party staging key. |
237
+ | `CAPXUL_BOOTSTRAP_URL` | Bootstrap origin. Defaults to `https://site.preview.abuusama.dev`. Convex Cloud origins are rejected. |
31
238
  | `CAPXUL_POSTHOG_HOST` | Optional development override for the built-in public PostHog ingestion origin. |
32
239
  | `CAPXUL_POSTHOG_PROJECT_TOKEN` | Optional development override for the built-in public project ingestion token. |
33
240
  | `CAPXUL_TELEMETRY_DISABLED` | Set to `true` to disable remote observation regardless of the saved preference. |
34
241
 
35
- The published CLI includes Capxul-owned public ingestion configuration. You do
36
- not need PostHog environment variables. Collection defaults to enabled for
242
+ The published CLI includes the verified first-party staging application key and
243
+ Capxul-owned public ingestion configuration. You do not need key or PostHog
244
+ environment variables. A different bootstrap origin requires an explicit key. Collection defaults to enabled for
37
245
  ordinary local and online commands, help, version, and safely attributed argument
38
246
  refusals. Parser refusals produce a completion without a start. Early native
39
247
  global errors with no resolved command route send nothing, because the CLI
@@ -59,7 +267,8 @@ unsafe permissions, symlinks, and corrupt state produce a storage failure.
59
267
 
60
268
  ## Output
61
269
 
62
- `--json` writes one version 1 envelope to stdout. Success contains `data`.
270
+ `--json` writes one version 1 envelope to stdout. Success contains `data`, which
271
+ can be an object, array, or null according to the command's SDK result.
63
272
  Failure contains `error.code` and CLI-owned `error.message`. Each envelope has
64
273
  `command`, `invocationId`, and `outcome`. An invocation ID is null before a
65
274
  command starts. Human errors go to stderr.
@@ -109,6 +318,15 @@ compinit
109
318
  Use `npm update -g @capxul/cli` or `brew upgrade xelmar-tech/tap/capxul` to update.
110
319
  Use one installer for the `capxul` executable to avoid conflicting PATH entries.
111
320
 
321
+ After a successful human command, help, or version request, the CLI can show an
322
+ update notice on terminal stderr. It checks the public npm `latest` tag at most
323
+ once per 24 hours. It shows only the command for the verified running npm-global
324
+ or Homebrew installation. It does not execute that command. Unknown installations,
325
+ development versions, JSON output, redirected stderr, CI, shell completion, and
326
+ all `telemetry` commands receive no notice. The optional check has one 500 ms
327
+ budget. Safe failed attempts are cached. Storage or network failures remain
328
+ silent and do not change the command result. This check sends no telemetry.
329
+
112
330
  ## Development commands
113
331
 
114
332
  ```sh
@@ -121,3 +339,65 @@ vp exec node --test --test-name-pattern='@capxul/cli' scripts/__tests__/pack-ins
121
339
  The last command installs the tarball outside the workspace and exercises the
122
340
  installed executable with isolated settings and a local HTTP server. The CI
123
341
  `CLI / Linux / Node 24.0.0` job runs this proof at the declared minimum version.
342
+
343
+ ## Email login and session restoration
344
+
345
+ This CLI establishes a first-party BetterAuth session. It has broader authority
346
+ than the earlier native `account:read` grant. Existing native grants remain
347
+ stored and tagged as `legacy-native-grant` in status. A profile read asks for an
348
+ explicit new login; it never exchanges the old grant for a broader session.
349
+ Logout forgets and attempts to revoke both credential types for the selected email.
350
+
351
+ For a human, `capxul auth login` prompts for email and a hidden OTP. `auth signup`
352
+ also prompts for the current Profile fields: display name, two-letter country
353
+ code, and handle. The browser opens only when the shared Core onboarding journey
354
+ needs Openfort wallet readiness. It shows wallet status only. It has no email,
355
+ OTP, Profile, or approval form.
356
+
357
+ For an agent, send and verify in separate processes:
358
+
359
+ ```sh
360
+ capxul auth send --email "$TEST_EMAIL" --json
361
+ # Supply the delivered six-digit OTP through stdin, not a command argument.
362
+ capxul auth verify --email "$TEST_EMAIL" --otp-stdin --json
363
+ capxul auth signup --email "$TEST_EMAIL" --display-name "Test Person" --country GH --handle test_person --json
364
+ capxul auth profile --email "$TEST_EMAIL" --json
365
+ # A later process uses the same protected CLI home; no new OTP is required.
366
+ capxul auth profile --email "$TEST_EMAIL" --json
367
+ capxul auth status --email "$TEST_EMAIL" --json
368
+ capxul auth logout --email "$TEST_EMAIL" --json
369
+ ```
370
+
371
+ `--otp-stdin` reads up to 64 bytes, ending at EOF. Pipe from a secret provider or
372
+ use input redirection from a protected file. OTPs are never accepted in argv,
373
+ persisted in the continuation, or included in output. Non-interactive commands
374
+ without the required input refuse with exit 2 instead of prompting.
375
+
376
+ A fresh non-interactive signup can do verification and setup in one command:
377
+
378
+ ```sh
379
+ # Supply only the delivered OTP through stdin.
380
+ capxul auth signup --email "$TEST_EMAIL" --otp-stdin \
381
+ --display-name "Test Person" --country GH --handle test_person --json
382
+ ```
383
+
384
+ The local page binds to an OS-selected loopback port. A random launch capability
385
+ is redeemed once and removed from the URL before Openfort starts. The page receives
386
+ only the authenticated wallet token and encryption session in memory. Closing it
387
+ ends the current wallet attempt. Re-run `auth signup` with the same CLI home to
388
+ resume the same Profile and Account without another OTP while the backend session
389
+ remains valid.
390
+
391
+ The version 2 `first-party-session` record stores the opaque provider credential
392
+ in the existing protected plaintext store. Its scope includes the application
393
+ key, issuer, environment, and email. Each process validates restoration with the
394
+ backend; cached session data is not authority. Conditional replacement prevents
395
+ a concurrent logout from being undone by a delayed credential save. The backend
396
+ owns expiry and revocation. A failed remote logout is reported as `unconfirmed`;
397
+ local sign-out remains in effect.
398
+
399
+ `auth profile` returns a backend-read Profile and account lifecycle without opening
400
+ the browser. Successful email authentication can return `setupState: "setup-required"`.
401
+ `auth signup` returns `setupState: "ready"` only after Core reads a ready Account.
402
+ After logout, profile reads refuse with `NOT_AUTHENTICATED` and exit 3. An invalid
403
+ or expired OTP refuses with exit 2.
Binary file