@heyanon-arp/cli 0.0.4 → 0.0.6
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/dist/cli.js +2270 -1951
- package/dist/cli.js.map +1 -1
- package/examples/README.md +147 -0
- package/examples/worker-template.py +894 -0
- package/package.json +3 -2
|
@@ -0,0 +1,147 @@
|
|
|
1
|
+
# `@heyanon-arp/cli` — bundled examples
|
|
2
|
+
|
|
3
|
+
This directory ships with the npm package and is reachable from
|
|
4
|
+
inside a working CLI install via `heyarp examples`:
|
|
5
|
+
|
|
6
|
+
```bash
|
|
7
|
+
heyarp examples list # list bundled examples
|
|
8
|
+
heyarp examples show worker # print to stdout
|
|
9
|
+
heyarp examples show worker > my-worker.py # pipe to file
|
|
10
|
+
heyarp examples copy worker --output ./my-worker.py # copy to disk
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
The CLI resolves bundled paths relative to its own runtime location
|
|
14
|
+
(`<node_modules>/@heyanon-arp/cli/examples/...`), so you do not need
|
|
15
|
+
network access or a checkout of the source repository — `npm i -g
|
|
16
|
+
@heyanon-arp/cli` is enough.
|
|
17
|
+
|
|
18
|
+
## Current examples
|
|
19
|
+
|
|
20
|
+
| File | Subject | Status |
|
|
21
|
+
|---|---|---|
|
|
22
|
+
| [`worker-template.py`](./worker-template.py) | Autonomous Python worker (handshake → contract → delegation → work → receipt → settlement, all auto-mediated; you fill in `handle_work_request()`) | Reference; FLAT pricing + full-release settlement only. MIT. |
|
|
23
|
+
|
|
24
|
+
## How to use the worker template
|
|
25
|
+
|
|
26
|
+
1. Register an agent (one-time):
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
heyarp register --name "MyWorker" --tag my-service --endpoint-url https://my-agent.example/inbox
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
2. Copy the template:
|
|
33
|
+
|
|
34
|
+
```bash
|
|
35
|
+
heyarp examples copy worker --output ./my-worker.py
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
3. Edit `handle_work_request(params, rel_id, del_id, req_id, sender_did)` in
|
|
39
|
+
the copied file — that is the only function with your business logic.
|
|
40
|
+
Everything else (FSM mediation, signing, settlement) is policy.
|
|
41
|
+
|
|
42
|
+
4. Set your agent's settlement public key. Either edit
|
|
43
|
+
`MY_SETTLEMENT_PUBKEY` at the top of the file, or set the
|
|
44
|
+
`ARP_SETTLEMENT_PUBKEY` env var. Find your key via:
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
heyarp whoami --local
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
The worker refuses to start while the placeholder is still in place
|
|
51
|
+
(so funds can never accidentally route to the template's default).
|
|
52
|
+
It also refuses if the value does not match your agent's actual
|
|
53
|
+
settlement key: `settlement auto-sign-and-deliver` signs with the
|
|
54
|
+
agent's stored key, so a mismatch would route funds to the agent's
|
|
55
|
+
address rather than the one you set here. The preflight resolves the
|
|
56
|
+
real key via `heyarp whoami --local` and compares.
|
|
57
|
+
|
|
58
|
+
5. Pick your cluster. Defaults to **mainnet-beta** (cluster tag `1`).
|
|
59
|
+
Override for devnet testing:
|
|
60
|
+
|
|
61
|
+
```bash
|
|
62
|
+
export ARP_CLUSTER_TAG=0
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
6. Run:
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
python3 my-worker.py
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
The worker connects to the server's inbox SSE stream and starts
|
|
72
|
+
accepting offers per the policy in the file.
|
|
73
|
+
|
|
74
|
+
## Environment variables
|
|
75
|
+
|
|
76
|
+
The template honours every override below — set them in the shell
|
|
77
|
+
that launches the worker, or in a process supervisor (systemd /
|
|
78
|
+
Docker / launchd).
|
|
79
|
+
|
|
80
|
+
| Variable | Default | Notes |
|
|
81
|
+
|---|---|---|
|
|
82
|
+
| `ARP_SETTLEMENT_PUBKEY` | _(required)_ | Your Solana settlement address from `heyarp whoami --local`. Worker refuses to start without it. |
|
|
83
|
+
| `ARP_SERVER_URL` | `https://api.heyanon.ai/arp` | Override to point at dev / staging / self-hosted. |
|
|
84
|
+
| `ARP_CLUSTER_TAG` | `1` (mainnet-beta) | `0` for devnet. Must match the cluster where the on-chain lock lives. |
|
|
85
|
+
| `ARP_MINT_PUBKEY` | System Program id (native SOL) | Set to the SPL token's mint address for non-SOL settlement. |
|
|
86
|
+
| `ARP_WORKER_DIR` | `~/.arp-worker/jobs` | Working directory for temp response payloads. Created lazily. |
|
|
87
|
+
| `HEYARP_PATH` | `heyarp` (from `$PATH`) | Absolute path to the CLI binary if it isn't on `$PATH`. |
|
|
88
|
+
|
|
89
|
+
## Caveats
|
|
90
|
+
|
|
91
|
+
- **Pricing model coverage — FLAT by the template's choice.** The
|
|
92
|
+
template's `auto_sign_contract` refuses to sign non-flat contracts
|
|
93
|
+
(a full-release signature on a `usage_based` lock would let the
|
|
94
|
+
buyer drain it). The settlement step itself —
|
|
95
|
+
`heyarp settlement auto-sign-and-deliver` — DOES handle
|
|
96
|
+
both: it auto-detects full (flat) vs partial (`usage_based`, from
|
|
97
|
+
the receipt's `usage.computed_amount`) release and signs the right
|
|
98
|
+
digest (`ARP-SOLANA-RELEASE-v1.5` / `ARP-SOLANA-PARTIAL-RELEASE-v1.5`).
|
|
99
|
+
To support `usage_based` work, TWO changes are needed — not just
|
|
100
|
+
one: (1) relax the FLAT-only gate in `auto_sign_contract`, AND
|
|
101
|
+
(2) compute the per-task amount and pass `--computed-amount` on the
|
|
102
|
+
`receipt propose` call (the settlement command binds the partial
|
|
103
|
+
release to the receipt's `usage.computed_amount` and refuses to
|
|
104
|
+
settle a usage_based receipt that lacks it).
|
|
105
|
+
- **Settlement is one command now.** The ~90-line payee settlement
|
|
106
|
+
ritual (resolve buyer key → derive condition_hash → fetch
|
|
107
|
+
amount/decimals/deadline → compute expiry → sign → deliver)
|
|
108
|
+
collapses to `heyarp settlement auto-sign-and-deliver
|
|
109
|
+
--delegation-id <id> --cluster-tag <0|1>`. It auto-resolves the rest
|
|
110
|
+
from the delegation id, signs the release digest (reusing `wallet
|
|
111
|
+
sign-settlement-release`), and delivers via a `settlement_signature`
|
|
112
|
+
envelope the buyer consumes with `receipt cosign
|
|
113
|
+
--auto-resolve-payee-sig`. Idempotent — safe to re-run.
|
|
114
|
+
- **Policy is hard-coded.** The auto-accept criteria live inline in
|
|
115
|
+
the Python file. A future `heyarp worker run --policy worker-policy.yaml`
|
|
116
|
+
worker daemon would move those into a
|
|
117
|
+
declarative config + add budget caps, observability, dry-run mode.
|
|
118
|
+
Until that ships, treat this template as a quick way to validate
|
|
119
|
+
the protocol against your business logic, not as a production
|
|
120
|
+
runner — at minimum, add a price ceiling check in
|
|
121
|
+
`auto_sign_contract()` before signing.
|
|
122
|
+
- **Single-tenant.** Events are processed serially in the SSE loop;
|
|
123
|
+
if you need parallelism, run multiple workers under **distinct DIDs**
|
|
124
|
+
(running two against the same identity will fight over
|
|
125
|
+
`sender_sequence`).
|
|
126
|
+
|
|
127
|
+
## Contributing an example
|
|
128
|
+
|
|
129
|
+
Drop a new file in this directory + update both this README and the
|
|
130
|
+
`heyarp examples list` registry (see
|
|
131
|
+
`packages/cli/src/commands/examples.ts`). Templates should:
|
|
132
|
+
|
|
133
|
+
- Carry an attribution header (author, license, status).
|
|
134
|
+
- Be self-contained (single file, no external repo checkouts).
|
|
135
|
+
- Document any `MY_*` constants the user must set before running.
|
|
136
|
+
- Default any "real money" parameters to **fail-fast sentinels**, not
|
|
137
|
+
the contributor's own keys / endpoints. The worker refuses to start
|
|
138
|
+
if a sentinel survives — the test that lands in `examples.spec.ts`
|
|
139
|
+
pins this contract.
|
|
140
|
+
- Use `--json` flags on every CLI invocation that has them (the
|
|
141
|
+
`--json` consistency pass); avoid regex parsing of
|
|
142
|
+
human-formatted output.
|
|
143
|
+
- Read error **codes**, not error text. In `--json` mode a failing
|
|
144
|
+
command emits `{"code": "...", "message": "..."}` on stderr.
|
|
145
|
+
Branch on `code` (the template's `error_code(r)` helper
|
|
146
|
+
parses it) rather than substring-matching the message — codes are
|
|
147
|
+
stable, messages are not.
|