@finchtech/cli 0.4.1 → 0.5.1
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 +44 -14
- package/dist/finch.js +39788 -40032
- package/package.json +5 -5
package/README.md
CHANGED
|
@@ -2,11 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
Install the public npm package with `npm install -g @finchtech/cli`, then run `finch --help`. The primary executable is `finch`; `finchtech` is an equivalent fallback for machines where another application already owns the `finch` command.
|
|
4
4
|
|
|
5
|
-
The Finch Agent CLI stores wallet keys
|
|
5
|
+
The Finch Agent CLI stores wallet keys and AgentCLI Session bearers only in an owner-only `FINCHTECH_HOME`, which defaults to `~/.finchtech`; secrets are never accepted as command arguments or emitted to stdout.
|
|
6
6
|
|
|
7
|
-
For an existing private key, run `finch wallet use --file <PATH>` on a fresh installation, then `finch login --help` to choose an authentication chain. The file must contain a single
|
|
7
|
+
For an existing private key, run `finch wallet use --file <PATH>` on a fresh installation, then `finch login --help` to choose an authentication chain. The file must contain a single 32-byte hex private key (64 hexadecimal digits, optionally prefixed with `0x`) and have owner-only permissions. First import is offline and makes that wallet current. `finch wallet create` generates a new identity instead. An existing Account switch with a stored Session revokes that Account before changing the current wallet. With no stored Session, switching is offline and does not claim remote revocation. A pending login must be recovered before switching; other partial or corrupt Session state requires explicit repair. Incomplete wallet files require recovery from backup; residual local authorization requires restoring the original wallet or explicitly clearing local authorization with `finch logout --local`.
|
|
8
8
|
|
|
9
|
-
`finch logout` revokes Account-bound remote authority before removing local Session and grant state.
|
|
9
|
+
`finch logout` revokes Account-bound CLI/MCP remote authority before removing local Session and grant state. `finch logout --local` clears only local `session/` and `grants/`, makes no network request and reports `remoteRevoked: false`. Both preserve profiles, registered wallets and transaction/publication journals. Ordinary logout and wallet switching proceed independently of unfinished journals; resume a journal later with its original wallet and matching Account/environment.
|
|
10
10
|
|
|
11
11
|
CLI-authored EVM addresses accept canonical lowercase or valid EIP-55 input and are normalized to lowercase before request validation and transport. Invalid mixed-case and uppercase forms are rejected. Remote responses and Remote MCP plans remain strictly lowercase so normalization cannot change signed or hashed plan bytes.
|
|
12
12
|
|
|
@@ -16,11 +16,11 @@ Skill upload failures also retain the final `uploadBytes`, `uploadObjectKind`, H
|
|
|
16
16
|
|
|
17
17
|
ZIP import failures return `AGENT_MARKET_REQUEST_INVALID`, exit code `2`, and `fix_request` before upload. The JSON-encoded `state` identifies `SKILL_SOURCE_ZIP_INVALID` and a `zipReason`: `archive_too_large`, `expanded_content_too_large`, `utf8_flag_missing`, `filename_encoding_invalid`, or `invalid_archive`. Size failures include `actualBytes`, `maxBytes` (10,485,760), and `sizeBasis`: `archive` measures the compressed input; `declared_expanded` is the cumulative uncompressed size declared by entries at the first limit violation, before decompression. A safely decoded root-relative entry `path` is included when available. Non-ASCII filenames require valid UTF-8 bytes and bit 11 in the ZIP headers; rebuilding with those flags preserves file contents. These import limits are independent of final upload admission.
|
|
18
18
|
|
|
19
|
-
|
|
19
|
+
Publication intent HTTP failures identify the Session-owned `/api/v1/agent-cli/signing-intents/skills/<intentId>/prepare` resource in `remotePath`. Failures include `remoteStatus` and available safe correlation IDs. `responseIssue` distinguishes `transport_failed`, `body_read_failed`, `empty_body`, `invalid_content_length`, `response_too_large`, `invalid_json`, and `schema_mismatch`. Schema failures include at most eight `schemaIssues` with known field paths and validation keywords; an empty path means the response root or an unrecognized field, whose name is withheld. No response values, arbitrary property names, URLs, or raw causes are printed. Malformed success responses are rejected during `intent`, before signing or writing a pending-send marker. Use the returned recovery command for the same publication; the CLI never automatically retries intent requests or resubmits transactions. The fingerprint identifies the local recovery journal, not a server trace; use returned remote IDs to correlate server logs.
|
|
20
20
|
|
|
21
21
|
The CLI measures the exact final multipart request, including metadata and framing. At or below 4,000,000 bytes it posts that request to the inline upload route. Above it the object goes through the staged transport instead: the CLI asks for a signed URL, writes the bytes straight to storage, and has the server read them back, verify them and pin them, so the platform's 4,500,000-byte request-body limit does not apply. These MB thresholds are decimal. The per-object ceilings are enforced against the final object either way: 30 MiB (31,457,280 bytes) for a package, 5 MiB for a cover, and 3 MiB (3,145,728 bytes) for a manifest. The package ceiling is one shared constant, applied by upload admission, by the retrieval route, by this client before it uploads, and by this client when it downloads, so a package that publishes is a package that reads back. Repacking a compressed source ZIP may increase its size. Passing admission does not certify production upload success or authorize replaying a previously failed publication.
|
|
22
22
|
|
|
23
|
-
The command groups are `wallet`, `login/status/logout`, `site`, `mcp doctor`, `mcp connect`, `mcp authorize`, `
|
|
23
|
+
The command groups are `wallet`, `login/status/logout`, `site`, `mcp doctor`, `mcp connect`, `mcp authorize`, `credentials`, `intent`, `purchase`, `task`, and `skill`. Run `finch --help` for the exact command list as one JSON value.
|
|
24
24
|
|
|
25
25
|
`finch site open` creates a sixty-second one-use handoff from the active AgentCLI Session and opens the exact configured Finch origin in the local default Browser. `finch site login <REQUEST_URL>` binds a website-created five-minute request once, then opens the same confirmation page. Both commands require the wallet, CLI, and graphical Browser on the user's machine. A launch failure returns `BROWSER_OPEN_FAILED` without printing the secret completion URL. The Browser receives only a normal seven-day Finch Web Session; wallet signing, broadcast, and market confirmation remain local CLI actions.
|
|
26
26
|
|
|
@@ -36,25 +36,45 @@ Each entry point applies the same origin, redirect, state, scope, and RFC 9207 i
|
|
|
36
36
|
|
|
37
37
|
Doctor's `ready: true` is scoped by `readinessScope: "cli_session_and_mcp_discovery"`. Its `harnessOAuth.status` is always `not_checked`: CLI login and valid discovery metadata do not establish that the connected Harness has usable OAuth credentials, a saved issuer, or working refresh. The result includes identity-verification and native reauthorization guidance. If the Harness reports an OAuth failure, start its native MCP authorization flow again, approve the fresh request through the entry points above, then verify MCP identity again.
|
|
38
38
|
|
|
39
|
-
Run `finch login --help` to list supported production authentication chain IDs (1, 10, 56, 8453, 42161). For example, `finch login --chain-id 56` selects BNB Smart Chain for authentication only.
|
|
39
|
+
Run `finch login --help` to list supported production authentication chain IDs (1, 10, 56, 8453, 42161, 43114). For example, `finch login --chain-id 56` selects BNB Smart Chain for authentication only.
|
|
40
40
|
|
|
41
41
|
Ordinary installs require no profile file or environment selection. Network commands default to the PROD endpoint at `https://www.finchtech.ai`. `finch login --chain-id <CHAIN_ID>` explicitly selects only the authentication chain, which the selected server must support. Market transaction chains come from Remote MCP/API plans and are independent of the login chain. `intent approve` signs only the shared publication-v2 or Local-purchase-v1 EIP-712 authorization; it cannot sign arbitrary transaction calldata.
|
|
42
42
|
|
|
43
|
-
|
|
43
|
+
Signing-decision recovery queries only the owned signing intent through the AgentCLI Session and never reads an MCP grant.
|
|
44
|
+
|
|
45
|
+
Business discovery, Creator configuration, preparation and operation queries belong to the Harness's Remote MCP connection. CLI 0.5.0 removes `creator …`, `operation show`, `skill search`, and all `mcp grant …` commands. Use their market-specific MCP tools and execute only the returned local wallet/credential actions.
|
|
46
|
+
|
|
47
|
+
On the first stateful command after upgrading, the CLI removes obsolete `grants/` files and manual-grant idempotency keys without reading their bearers. Profiles, wallet keys, the current Session and all signing/transaction recovery journals remain intact. Help/version remain state-free. This local purge does not revoke remote grants or Harness OAuth credentials; ordinary `finch logout` revokes Account-bound authority when that is intended. Updating Finch CLI never reads or deletes the Harness's OAuth store.
|
|
48
|
+
|
|
49
|
+
Repeated `finch login --chain-id <CHAIN_ID>` first recovers a pending login, then verifies and returns an existing Session on that same authentication chain. A confirmed 401 starts a fresh login; a network failure or mismatched identity preserves local authority and reports the failure. Use `finch logout` before changing authentication authority. On Unix, the default state directory requires `chmod 700 ~/.finchtech`, and a private-key input file requires `chmod 600 <KEY_FILE>`; apply the same modes to a custom state home. The CLI creates and protects a missing home itself.
|
|
50
|
+
|
|
51
|
+
If the server returns `AGENT_SESSION_INVALID`, run `finch login --chain-id <CHAIN_ID>` with the same wallet, endpoint and authentication chain. The CLI preserves the remote error JSON and prints renewal guidance on stderr. Use `finch mcp doctor` to read the stored login chain when needed. After login, verify CLI/MCP identity and resume the original recovery command.
|
|
52
|
+
|
|
53
|
+
`finch logout --local` clears local Session and legacy grant files while preserving wallets and recovery journals; it leaves server authorization unchanged. Ordinary logout and wallet switching retain Account-wide CLI/MCP revocation. CLI 0.5.1 allows these transitions independently of unfinished journals. Resume each journal under its original wallet and matching Account/environment. The obsolete `mutations/recovery-index.json` is retained during upgrade but is no longer read or written; the protected journal is the sole local progress record. Upgrade to CLI 0.5.1 to receive this fix; changing the Skill alone does not update an installed CLI.
|
|
54
|
+
|
|
44
55
|
|
|
45
|
-
Creator commands are thin projections of the shared Agent Market merchant operations. Reads require `agent_market:merchant:read`; mutations require `agent_market:merchant:write`, a stable caller-chosen `--request-id` UUID for local idempotency recovery, and `--expected-revision` wherever the shared operation requires If-Match. Structured request bodies come from bounded JSON `--from-file` documents and are validated against the same shared schemas before HTTP.
|
|
46
56
|
|
|
47
57
|
Local AgentOn HMAC generation is not a product command. `credentials material-download <setupId> --out-file <absolute-path>` claims the AgentOn setup, downloads only its exact live lease as raw FCR1, and creates a new owner-only file; stdout contains only `keyId` and `path`. `credentials fulfill` accepts only Direct credential uploads. It accepts either an existing protected FCR1 with `--from-file <path>`, or a protected raw Bearer token with `--bearer-token-file <path> --key-id <keyId>`; the latter validates one whitespace-free token and adds the `Bearer ` prefix only in CLI memory. Secret bytes never enter argv or stdout.
|
|
48
58
|
|
|
49
|
-
`purchase transaction <operationId>` is read-only. It
|
|
59
|
+
`purchase transaction <operationId>` is read-only. It uses the active AgentCLI Session and returns the two server-composed transaction requests plus their chain authority; it does not sign or broadcast arbitrary calldata.
|
|
50
60
|
|
|
51
|
-
`purchase submit <operationId>`
|
|
61
|
+
`purchase submit <operationId>` uses the same AgentCLI Session and uses only the source-controlled public RPCs for the plan's chain. It uses the protected wallet to re-encode and submit the exact server-composed USDC approval and AgentService Vault purchase. Before signing it verifies `eth_chainId`, the reviewed chain contract authority, every transaction field, and a successful `eth_call` simulation. Every returned broadcast hash is atomically checkpointed before receipt waiting; a restart re-verifies the exact wallet, call, receipt, block, and current server authority and never re-broadcasts a known phase. Finch then verifies the canonical confirmation event and creates Call Rights. After a successful chain receipt, a durable confirmation-only checkpoint lets the same command recover a lost confirmation response without retrieving a fresh transaction plan or broadcasting again. If the purchase receipt conclusively reverts, the paired zero-allowance cleanup follows the same checkpoint discipline; unknown receipts are never guessed. The RPC owns nonce selection. User RPC and environment variables are ignored, and neither RPC URLs nor wallet keys are emitted.
|
|
52
62
|
|
|
53
63
|
`purchase recover-approval <operationId> --transaction-hash <hash>` is the narrow adoption path for an approval broadcast before its durable checkpoint was written. It re-fetches the current server authority and active wallet, then verifies the exact successful approval transaction and sufficient live token allowance on the plan chain before writing one owner-only recovery journal. It never broadcasts, confirms, scans chain history, or accepts a nonce. A subsequent `purchase submit` continues with the purchase phase without approving again.
|
|
54
64
|
|
|
55
65
|
If the process exits after broadcasting the Vault purchase but before confirmation returns, recover with `purchase confirm <operationId> --transaction-hash <hash>`. This command never trusts the supplied hash: Finch fetches and decodes the canonical chain receipt before any Call Rights mutation.
|
|
56
66
|
|
|
57
|
-
Task and Skill business discovery and preparation stay in the Remote MCP server.
|
|
67
|
+
Task and Skill business discovery and preparation stay in the Remote MCP server. Task preparation responses include `walletIntent` and a structured `localAction`. With a CLI build that supports `--intent`, run `finch task publish-submit <taskId> --intent <intentId>`, `finch task award-sign <taskId> --intent <intentId>`, or `finch task reclaim-submit <taskId> --intent <intentId>`. These commands read the immutable owned preparation and confirm its wallet result using only the active CLI Session. They neither read nor create an MCP business grant. `--from-file` accepts a response containing the same intent reference; transaction bytes always come from the authenticated server. Successful output is a wallet receipt; query business state through MCP.
|
|
68
|
+
|
|
69
|
+
Recover an interrupted action with `finch task recover <taskId> <publish|award|reclaim>`. Recovery reuses the saved transaction hash or signature batch. Existing v2 journals without an intent ID are adopted using their original server preparation audit receipt and confirmation idempotency key, then compared with the server plan before recovery. Keep journals intact; missing source receipts or changed plans require reconciliation. Deploy the Task intent migration and routes before distributing this CLI change. CLI 0.5.0 introduces the Session-only handoff; check installed command help before using returned actions.
|
|
70
|
+
|
|
71
|
+
Skill preparations return `walletIntent.intentId`. With the updated CLI, run `skill purchase-submit`, `convert-submit`, `price-submit`, or `supply-submit` with `--intent <intentId>`. The commands fetch server-bound transaction bytes and use only the CLI Session for execution and confirmation. `--from-file` reads only the handoff reference; changing price, chain or calldata in the file cannot change the signed call. Prepare unexecuted old plan files again through MCP. CLI 0.5.0 supports this handoff; npm publication is a separate release step.
|
|
72
|
+
|
|
73
|
+
`skill publish-submit --path <file-or-directory> --intent <intentId>` and `skill version-submit` retain local filtering, ZIP construction, packaging, encryption, upload and key custody. The server fixes the prepared business metadata and records each transaction stage once. `skill asset-upload --path <cover> --intent <intentId>` uploads a prepared public cover. `skill presentation-submit --intent <intentId>` publishes only the prepared public presentation and checkpoints its wallet result. Repeating an intent with a recorded transaction resumes confirmation. An unfinished publication requires its original protected material journal; restoring it preserves uploaded bytes and keys.
|
|
74
|
+
|
|
75
|
+
Recover wallet results with `skill recover intent <fingerprint>` and publication material with `skill recover publication <fingerprint>`. Recovery preserves broadcast hashes and the publication pending-send protections. Old buyer journals are admitted only as receipt-only recovery after the server reconstructs and verifies their confirmed canonical transaction. Existing publication journals retain their conservative typed recovery path. A confirmed receipt or projected stage can replay without another signature/broadcast; preserve journals during projection lag.
|
|
76
|
+
|
|
77
|
+
`skill download --intent <intentId> --out-file <new-file>` requires an active CLI Session for plaintext and protected content. It fetches the owned MCP delivery preparation, retrieves through the authenticated gateway, signs locally for protected keys, verifies the SkillRoot/files or historical ZIP hash, acknowledges delivery, and then creates an exclusive owner-only output file. Upload size/type admission, staged tickets, Oracle V2, Lit sealing and raw key locality remain unchanged. Each transaction is reconstructed from its explicit reviewed chain deployment and rejects different destinations, calldata, values, source commits or envelope tags.
|
|
58
78
|
|
|
59
79
|
## ZIP import and SkillRoot publication
|
|
60
80
|
|
|
@@ -63,7 +83,7 @@ Version 0.3.1 fixes Skill search continuation: pass the returned `nextCursor` un
|
|
|
63
83
|
Older clients receive an upgrade message from the Skill search API.
|
|
64
84
|
|
|
65
85
|
Version 0.3.0 upgrades Skill publication and encrypted delivery together. Upgrade with
|
|
66
|
-
`
|
|
86
|
+
`npm install -g @finchtech/cli@0.5.1` and verify `finch --version` before publishing new Skills
|
|
67
87
|
or downloading encrypted Skills from the upgraded gateway. Older CLI versions cannot use
|
|
68
88
|
the new encrypted delivery, including for historical Skills; 0.3.0 retains historical package support.
|
|
69
89
|
|
|
@@ -121,7 +141,7 @@ and use that command rather than repeating publish-submit. Cleanup failures do n
|
|
|
121
141
|
still exists. If source is unavailable or its excluded-path inventory changed across CLI versions,
|
|
122
142
|
the fingerprint-only recovery command can use the already stored publication bytes.
|
|
123
143
|
|
|
124
|
-
These fixes require CLI 0.3.3 or newer; npm 0.3.2 does not include them. Updating a Skill does not upgrade the installed CLI. Journal v6 saves a pending stage before signing/submitting. Missing hashes in creating stages of a pending or legacy v4/v5 journal block automatic resubmission; follow the reported chain-state checks and contact support. CLI 0.3.7 permits the URI assignment stage to converge through its typed recovery path. Known hashes are verified without rebroadcast. The pending marker
|
|
144
|
+
These fixes require CLI 0.3.3 or newer; npm 0.3.2 does not include them. Updating a Skill does not upgrade the installed CLI. Journal v6 saves a pending stage before signing/submitting. Missing hashes in creating stages of a pending or legacy v4/v5 journal block automatic resubmission; follow the reported chain-state checks and contact support. CLI 0.3.7 permits the URI assignment stage to converge through its typed recovery path. Known hashes are verified without rebroadcast. The pending marker protects transaction resubmission while authorization cleanup and wallet switching preserve the journal.
|
|
125
145
|
|
|
126
146
|
## Bootstrap and health reports (CLI 0.3.4+)
|
|
127
147
|
|
|
@@ -149,4 +169,14 @@ CLI 0.4.0 adds `finch mcp connect` and `finch mcp authorize --stdin`, delivers l
|
|
|
149
169
|
|
|
150
170
|
## Avalanche Skill transactions (CLI 0.4.1+)
|
|
151
171
|
|
|
152
|
-
CLI 0.4.1 supports Skill publication, acquisition, management, and delivery on Avalanche C-Chain (`43114`), alongside Ethereum, Optimism, BNB Smart Chain, Base, and Arbitrum. Preserve the Remote MCP plan's exact chain for every custody action; Avalanche transactions use AVAX for prices and gas.
|
|
172
|
+
CLI 0.4.1 supports Skill publication, acquisition, management, and delivery on Avalanche C-Chain (`43114`), alongside Ethereum, Optimism, BNB Smart Chain, Base, and Arbitrum. Preserve the Remote MCP plan's exact chain for every custody action; Avalanche transactions use AVAX for prices and gas. The current PROD server supports Avalanche wallet authentication directly on Avalanche. CLI 0.5.1 also includes Avalanche in the PROD authentication-chain help; use `finch login --help` for the supported list. Updating the website or the Finch Market Skill does not upgrade an installed CLI.
|
|
173
|
+
|
|
174
|
+
## Session-only release order (CLI 0.5.0)
|
|
175
|
+
|
|
176
|
+
CLI 0.5.0 depends on the Agent, Task and Skill intent migrations/routes from Issue #1144 parts 1–3. Apply the ordered migrations through the separately authorized workflow and deploy the corresponding Session endpoints before distributing this package. Validate CLI custody/recovery against the intended environment, publish the reviewed package, then release the matching Finch Market Skill instructions. A repository version bump or website deployment is not npm publication; before that release, public npm 0.4.1 retains its older command and preparation-file workflow.
|
|
177
|
+
|
|
178
|
+
Keep existing journals when upgrading. Agent recovery uses the owned operation/intent endpoints; old Task v2 journals adopt their original preparation audit receipt; old Skill purchase/convert checkpoints adopt only an already verified receipt. Unexecuted old plan files must be prepared again through MCP. Historical Skill publication journals without an intent ID cannot safely manufacture one or fall back to business authority: preserve the journal and reconcile any broadcast stages before continuing. Old clients' server interfaces remain available during rollout; their eventual retirement is separate work.
|
|
179
|
+
|
|
180
|
+
## Recovery-preserving Account transitions (CLI 0.5.1)
|
|
181
|
+
|
|
182
|
+
CLI 0.5.1 allows ordinary logout and wallet switching with unfinished transaction/publication journals, preserving Account-wide CLI/MCP revocation and the original recovery evidence. It removes the redundant local recovery index. Invalid or expired Sessions receive direct same-authority login guidance. The bundle also includes the shared Avalanche PROD authentication allowlist already deployed on Finch.
|