@jinn-network/client 0.1.1 → 0.1.2-canary.647548b7

package/CHANGELOG.md

@@ -0,0 +1,14 @@
+# Changelog
+
+## 0.1.2
+
+- Added `jinn intents enable --impl <name>` plus `jinn intents reset <kind>` so operators can switch intent implementations without hand-editing config.
+- Removed the default legacy health-check desired state; testnet now relies on the deterministic auto-generated `prediction.v0` intent path by default.
+- Added graceful legacy Claude skip behavior (`claude_unavailable`) when auth/quota blocks health-check restoration attempts.
+- Fixed no-install invocation so `npx @jinn-network/client@<version> <verb>` works directly via a `client` bin alias.
+- Added canonical `jinn mcp` command and kept `jinn-mcp` as a deprecation shim.
+- Extended package smoke tests to validate both direct `npx` and legacy `npx -p ... jinn ...` execution paths.
+- Includes prior validated canary fixes now rolled into stable:
+  - PR #21 default Base Sepolia ClaimRegistry
+  - PR #22 idempotent replayed `claimDelivery`
+  - PR #23 prediction evaluator support for signed engine manifests

package/CONTRIBUTING.md

@@ -0,0 +1,123 @@
+# Contributing to @jinn-network/client
+
+Development happens in the [jinn-mono](https://github.com/Jinn-Network/mono) monorepo. This guide covers running the client from source.
+
+## Prerequisites
+
+- Node.js 22 (`corepack enable` once so Yarn matches this package's `packageManager` field)
+- [Claude Code CLI](https://docs.anthropic.com/en/docs/claude-code) (`claude` in PATH — the daemon spawns it as a subprocess)
+- [Foundry](https://book.getfoundry.sh/) (only needed for `yarn e2e` against an Anvil fork)
+
+## Setup
+
+```bash
+cd client
+yarn install
+yarn test              # vitest suite — 267 tests
+yarn typecheck         # tsc --noEmit
+```
+
+## Running from source
+
+```bash
+JINN_PASSWORD=your-keystore-password yarn jinn run
+```
+
+The `yarn jinn` script uses `tsx` to run TypeScript directly without a build step.
+
+## Running against an Anvil fork
+
+```bash
+# Terminal 1
+anvil --fork-url https://sepolia.base.org --port 8545
+
+# Terminal 2
+JINN_RPC_URL=http://127.0.0.1:8545 JINN_PASSWORD=test yarn jinn run
+```
+
+The bootstrap pauses at the funding gate. Fund the printed master address from one of Anvil's pre-funded keys with `cast send`, then re-run.
+
+## Project structure
+
+```
+src/
+  bin/jinn.ts           CLI entry point (compiled to dist/bin/jinn.js)
+  cli/                  CLI dispatcher and commands
+  adapters/             Execution adapters (local, mech)
+  daemon/               Concurrent loop orchestration
+  earning/              Fleet bootstrap state machine
+  runner/               Claude subprocess management
+  store/                SQLite persistence
+  api/                  HTTP API (Hono)
+  types/                Core type definitions
+  errors/               Error envelope system
+  mcp/                  MCP server for Claude subprocess
+
+deployments/            Bundled deployment artifacts (contract addresses)
+test/                   Vitest tests (mirrors src/ structure)
+scripts/                Dev utilities (e2e, staking validation, sync)
+```
+
+## Build and pack
+
+```bash
+yarn build                 # tsc output → dist/
+yarn pack -o test.tgz      # create publishable tarball
+```
+
+The `files` field in `package.json` ensures only `dist/`, `deployments/`, `README.md`, and `LICENSE` are included in the tarball.
+
+## Releases
+
+Use [RELEASING.md](./RELEASING.md) for the package bootstrap publish, npm trusted-publishing setup, canary/stable release flow, the fork-based operator gate (`yarn release:operator-gate`), and the manual Docker-first real testnet acceptance gate (`yarn release:testnet-acceptance`) that must pass on the exact stable release commit. The dedicated Docker acceptance environment and evidence expectations are documented in [TESTNET_ACCEPTANCE.md](./TESTNET_ACCEPTANCE.md).
+
+## Updating deployment artifacts
+
+After deploying new contracts on testnet, sync the bundled defaults:
+
+```bash
+./scripts/sync-deployments.sh
+```
+
+This copies the 4 deployment JSON files from `contracts/` into `client/deployments/`. Commit the updated files.
+
+## Scripts reference
+
+| Command | Description |
+|---|---|
+| `yarn jinn run` | Run daemon from source (requires JINN_PASSWORD) |
+| `yarn test` | Run vitest suite |
+| `yarn build` | TypeScript compile |
+| `yarn typecheck` | Typecheck without emitting |
+| `yarn e2e` | End-to-end validation on Anvil fork |
+| `yarn staking` | Earning bootstrap validation on Anvil fork |
+| `yarn pack:smoke` | Pack tarball and run smoke tests |
+| `yarn release:operator-gate` | Run the stable-release operator gate (`staking` then `e2e`) |
+| `yarn release:testnet-acceptance` | Run the manual Docker-first real testnet acceptance harness |
+| `yarn setup:testnet-acceptance-operator` | First-time Docker acceptance setup + bootstrap/funding helper (`TESTNET_ACCEPTANCE.md`) |
+| `yarn release:testnet-acceptance:host` | Legacy host-installed acceptance smoke/debug harness |
+| `yarn setup:testnet-acceptance-operator:host` | Legacy host-installed acceptance setup helper |
+
+## CI
+
+In CI, use `yarn install --immutable` (equivalent to a clean `npm ci`). The CI workflow (`ci.yml`) runs:
+
+1. `typecheck` + `test` + `build`
+2. `yarn pack` + smoke test the packed artifact in a clean directory
+
+## On-chain addresses
+
+The client resolves contract addresses automatically from deployment artifacts bundled in `deployments/` (testnet) and hardcoded constants (mainnet). Operators don't need to set any `JINN_TESTNET_*_DEPLOYMENT` env var — those exist only as overrides for protocol developers running against a custom deploy.
+
+Base mainnet reference addresses:
+
+| Component | Address |
+|---|---|
+| JinnRouter | `0xfFa7118A3D820cd4E820010837D65FAfF463181B` |
+| Mech marketplace | `0xf24eE42edA0fc9b33B7D41B06Ee8ccD2Ef7C5020` |
+| Staking contract | `0x51c5f4982b9b0b3c0482678f5847ea6228cc8e54` |
+| OLAS token | `0x54330d28ca3357F294334BDC454a032e7f353416` |
+
+## Spec
+
+The stable command-line and JSON surface is defined in [`spec/2026-04-14-client-surface.md`](../spec/2026-04-14-client-surface.md). Error envelopes emitted on non-zero exits conform to §6 of that spec.

package/README.md

@@ -2,6 +2,9 @@
 
 Jinn protocol client. Runs a headless daemon that participates in the Jinn training loop: create, restore, and evaluate desired states, and earn rewards for measured work.
 
+**New operator?** Start with the full testnet runbook:
+<https://github.com/Jinn-Network/mono/blob/main/docs/operator-testnet.md>
+
 ## Install
 
 ```bash
@@ -19,37 +22,83 @@ yarn global add @jinn-network/client@latest
 The fast path for a new operator on Base Sepolia:
 
 ```bash
-# Zero-to-running in one command (init + funding check + bootstrap + run).
-JINN_PASSWORD=your-keystore-password jinn quickstart
+# One-time: pick runtime mode + authenticate Claude Code (interactive).
+jinn auth
+
+# Zero-to-running (wallet + funding check + bootstrap + run).
+jinn quickstart
+```
+
+On first run, `jinn quickstart` generates a random keystore password, saves
+it to `~/.jinn-client/keystore-password` (mode 0600), and prints a summary
+with the master address and a pointer to back up your mnemonic. Subsequent
+verbs (`jinn run`, `jinn bootstrap`, `jinn claim-rewards`, …) pick up the
+password from that file automatically — no env var needed.
+
+**Back up your mnemonic before you fund anything:**
+
+```bash
+jinn keys backup --output ~/jinn-mnemonic.txt  # mode 0600; treat as seed material
+```
+
+Prefer to manage the password yourself? Set `JINN_PASSWORD` before
+`quickstart` and no file will be written:
+
+```bash
+JINN_PASSWORD=your-secret jinn quickstart
 ```
 
-Or step by step:
+**Step by step** (skip if `quickstart` worked):
 
 ```bash
 # 1. Generate the encrypted keystore (picks an HD wallet deterministically).
-JINN_PASSWORD=your-keystore-password jinn init
+JINN_PASSWORD=your-secret jinn init
 
 # 2. Verify the environment and resolved deployment.
 jinn doctor --human
 
-# 3. List the exact funding gaps (ETH and stOLAS on Base Sepolia).
+# 3. List exact funding gaps. On testnet this is ETH only — the staking pool
+#    is managed protocol-side and operators don't hold bond tokens directly.
 jinn fund-requirements --human
 
 # 4. Send the requested testnet funds to the printed master address, then:
-JINN_PASSWORD=your-keystore-password jinn bootstrap
+jinn bootstrap
 
 # 5. Start the daemon.
-JINN_PASSWORD=your-keystore-password jinn run
+jinn run
 ```
 
 `jinn init`, `jinn fund-requirements`, `jinn bootstrap`, and `jinn run` all
-share the same encrypted keystore and fleet state under
-`~/.jinn-client/earning/`. They are idempotent — re-run any of them safely.
+share the same encrypted keystore and fleet state under `~/.jinn-client/earning/`
+by default. They are idempotent — re-run any of them safely.
+
+To keep testnet and mainnet state side-by-side on the same machine, set
+`JINN_EARNING_DIR` to a network-specific path:
 
-`JINN_PASSWORD` encrypts the local keystore and is **required** for every
-verb that touches private keys (`init`, `bootstrap`, `run`,
-`fund-requirements`, `keys backup`, `submit-intent`, `claim-rewards`,
-`withdraw`). It is env-only; never put it in a config file.
+```bash
+# Testnet (Phase 1b default):
+JINN_EARNING_DIR=~/.jinn-client/earning-testnet jinn run
+
+# Mainnet (after Phase 2 launch):
+JINN_NETWORK=mainnet JINN_EARNING_DIR=~/.jinn-client/earning-mainnet jinn run
+```
+
+### Password resolution
+
+Any verb that touches private keys resolves its password in this order:
+
+1. `--password-fd N` — read from a file descriptor (scripted / CI)
+2. `JINN_PASSWORD` env var — explicit operator-set
+3. `~/.jinn-client/keystore-password` — auto-generated by `jinn quickstart`
+
+The password is never read from config files. `jinn keys change-password`
+rotates the keystore and deletes the auto-generated password file; after
+rotation, set `JINN_PASSWORD` yourself.
+
+**Security note:** when `quickstart` auto-generates the password, it lives
+in plaintext next to the encrypted keystore. That's convenient for tester
+workflows but means anyone with shell access can decrypt your mnemonic —
+treat the wallet as hot and keep funds to the gas + rewards minimum.
 
 ## Try without installing
 
@@ -57,32 +106,116 @@ verb that touches private keys (`init`, `bootstrap`, `run`,
 npx @jinn-network/client@latest doctor
 ```
 
-## Docker (Recommended for Operators)
+## Let your agent do it
+
+If you already use Claude Code, Codex, Cursor, Gemini CLI, VS Code, or another
+MCP-capable tool, you can skip the shell commands above. After installing
+the client, wire Jinn into your agent:
+
+```bash
+jinn plugin install
+```
 
-The Jinn daemon runs pure Node, but spawns the Anthropic `claude` CLI as a subprocess for restorations. To keep your costs low, operators should use Claude's OAuth authentication (which leverages prompt caching and app tiers) instead of brute-forcing API keys.
+This detects every supported tool on your machine and, for each one, adds the
+`jinn mcp` MCP server plus a copy of the `jinn-operator` skill. Supported:
+Claude Code, Claude Desktop, Cursor, VS Code, Gemini CLI, Antigravity, Codex.
+Run `jinn plugin list --human` to see what's detected.
 
-Because the macOS keychain securely encrypts OAuth tokens, you **cannot** simply mount `~/.claude` from a Mac host into Docker. Instead, the most robust way to manage credentials and daemon state is using our included `docker-compose.yml`.
+Then open your agent and paste:
 
-### Zero-Friction Setup
+> Set up a Jinn Network testnet operator on this machine. Run `jinn quickstart`,
+> fund the master address via CDP if needed, and report back when the daemon is
+> running. Keep me in the loop if anything needs my input.
 
-1. **Configure Environment:** Create a `.env` file with your master password:
+The `jinn-operator` skill activates on mentions of "jinn", "jinn network", and
+"jinn quickstart", then walks your agent through install, auth, bootstrap, and
+daemon lifecycle. You stay in the loop for funding decisions.
+
+## Opting in to specific intent kinds
+
+After `quickstart`, your daemon participates in deterministic `prediction.v0`
+intents by default on testnet (via the auto-intent generator). Other kinds —
+like `portfolio.v0`, which
+executes trades against a Hyperliquid master account — are **off by default**
+because they need credentials only you can provide. This prevents your daemon
+from claiming a request it can't actually fulfill.
+
+Inspect and toggle participation with `jinn intents`:
+
+```bash
+jinn intents list --human                          # every kind, current state
+jinn intents status portfolio.v0 --human           # details for one kind
+jinn intents enable prediction.v0 --impl claude-mcp-prediction
+jinn intents enable portfolio.v0 --hl-master 0x... # start the opt-in flow
+jinn intents enable portfolio.v0 --confirm-approved
+jinn intents disable portfolio.v0                  # opt out, keep state
+jinn intents reset prediction.v0                   # reset kind->impl override
+```
+
+Each `enable` is an idempotent state machine. Rerun until the envelope reports
+`"status": "ready"`. When the flow needs something from you (an exchange
+approval, an API key), it returns `waiting_for_external_action` with the URL
+and the exact command to rerun next. Agents with the `jinn-operator` skill
+installed know how to walk an operator through any kind automatically — just
+paste "enable portfolio.v0 for me" and they'll take it from there.
+
+**Safety net:** before spending gas on a claim, the daemon checks whether the
+responsible impl is actually ready. If a portfolio.v0 request arrives and your
+api-wallet isn't approved, the daemon records the intent as FAILED locally
+with a clear reason instead of wasting gas claiming it.
+
+## Docker
+
+The daemon spawns the Anthropic `claude` CLI as a subprocess for
+restorations; to keep costs low, use Claude's OAuth authentication (prompt
+caching + app tiers) rather than raw API keys. On macOS the host keychain
+encrypts OAuth tokens, so mounting `~/.claude` directly into Docker
+doesn't work — instead, run one `claude setup-token` on the host to mint
+a long-lived OAuth token, then pass it to the daemon via `.env`.
+
+### Recommended path: `claude setup-token` + `.env`
+
+1. **Mint a long-lived OAuth token on the host** (one-time, opens browser):
    ```bash
-   echo "JINN_PASSWORD=your-secure-password" > .env
+   claude setup-token
    ```
+   Copy the `sk-ant-oat01-...` string it prints.
 
-2. **Authenticate Claude (One-Time):** The image entrypoint is the `jinn` binary, so run the Anthropic CLI directly by overriding the entrypoint. This performs the OAuth flow and saves the token to the persistent `jinn-claude-state` volume (same volumes as the daemon service):
+2. **Create a `.env` file** next to the compose file:
    ```bash
-   docker compose run --rm -it --entrypoint claude jinn-daemon auth login
+   cat > .env <<EOF
+   JINN_PASSWORD=your-secure-password
+   CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat01-...
+   EOF
    ```
-   Use `-it` so the CLI can open a browser (or show a URL to visit) and receive input. The process stays in the foreground until you finish sign-in.
-   *Follow the URL to authenticate in your browser.*
 
-3. **Start the Fleet:** Now that the Docker volume holds the token, start the headless daemon:
+3. **Start the daemon:**
    ```bash
    docker compose up -d
+   docker compose logs -f jinn-daemon
    ```
 
-### Quick Test
+The compose file lives at `client/docker-compose.yml` if you cloned the
+repo. If you installed via `npm install -g @jinn-network/client@latest`,
+copy it out first:
+
+```bash
+cp "$(npm root -g)/@jinn-network/client/docker-compose.yml" .
+```
+
+### Fallback: interactive OAuth inside the container
+
+If `claude setup-token` isn't available on your host (e.g., you don't
+have Claude Code installed locally), run the interactive OAuth flow
+inside the container instead — it saves the token to a persistent volume
+so the daemon can use it on subsequent runs:
+
+```bash
+docker compose run --rm -it --entrypoint claude jinn-daemon auth login
+docker compose up -d
+```
+
+### Quick test
 
 ```bash
 docker run --rm ghcr.io/jinn-network/client:latest version --json
@@ -115,6 +248,9 @@ docker run --rm ghcr.io/jinn-network/client:latest version --json
 | `jinn history` | Recent protocol activity |
 | `jinn rewards` | Earned vs claimed per service |
 | `jinn logs` | Structured event stream |
+| `jinn logs --follow` | Live tail of lifecycle events |
+
+Dashboard: when `jinn run` is active, open [`http://127.0.0.1:7331/`](http://127.0.0.1:7331/) for live in-flight intents, verdicts, earnings, fleet balances, recent activity, and next actions.
 
 ### Actions
 
@@ -136,9 +272,10 @@ All action verbs support `--dry-run` and `--yes`.
 - Add `--human` for readable terminal output.
 - `stderr` is reserved for progress, warnings, and runtime logs.
 - Non-zero exits emit a structured error envelope on stdout with `schemaVersion`, `code`, `exitCode`, `message`, `hint`, and `exampleCli`.
-- Without a global install, use `npx @jinn-network/client@latest <verb> ...` instead of `jinn ...` (the package name is scoped; `npx jinn` resolves a different package).
+- Without a global install, use `npx @jinn-network/client@latest <verb> ...`.
+- Backward-compatible legacy form still works: `npx -p @jinn-network/client@latest jinn <verb> ...`.
 
-See [`spec/2026-04-14-client-surface.md`](../spec/2026-04-14-client-surface.md) for the full surface spec.
+See the [client surface spec](https://github.com/Jinn-Network/mono/blob/main/spec/2026-04-14-client-surface.md) for the full CLI reference.
 
 ## Configuration
 
@@ -150,7 +287,7 @@ JINN_PASSWORD=secret jinn run --config ./my-config.json
 
 | Config key | Env override | Default |
 |---|---|---|
-| network | JINN_NETWORK | testnet (flips to mainnet at launch) |
+| network | JINN_NETWORK | `testnet` (Phase 1b default; flips to `mainnet` at Phase 2 launch) |
 | rpcUrl | BASE_RPC_URL / JINN_RPC_URL | network-appropriate public RPC |
 | claudeModel | JINN_CLAUDE_MODEL | claude-haiku-4-5-20251001 |
 | claudePath | JINN_CLAUDE_PATH | claude |
@@ -159,7 +296,7 @@ JINN_PASSWORD=secret jinn run --config ./my-config.json
 | dbPath | JINN_DB_PATH | ~/.jinn-client/jinn.db |
 | earningDir | JINN_EARNING_DIR | ~/.jinn-client/earning |
 | peers | JINN_PEERS | [] |
-| desiredStates | JINN_DESIRED_STATES | [health-check] |
+| desiredStates | JINN_DESIRED_STATES | [] (testnet auto-intent generator posts `prediction.v0`) |
 
 `JINN_PASSWORD` is env-only (keystore encryption, never in config files). Alternatively, use `--password-fd <N>` to read from a file descriptor.
 
@@ -167,23 +304,62 @@ JINN_PASSWORD=secret jinn run --config ./my-config.json
 
 | Role | Phase 1b (testnet, Base Sepolia) | Phase 2 (mainnet, Base) |
 |---|---|---|
-| Gas (native) | ETH | ETH |
-| Staking bond | stOLAS | OLAS |
+| Gas (native) | ETH (CDP auto-funded on testnet) | ETH |
+| Staking bond | Pooled, protocol-managed via stOLAS distributor (operators hold nothing) | OLAS (operator-held) |
 | Reward | stOLAS | OLAS (+ JINN incentives after launch) |
 
-On testnet, stOLAS is the liquid-staked OLAS variant used for bonds and
-incentives; OLAS backs stOLAS upstream and is not required directly.
-`jinn fund-requirements` surfaces the exact per-wallet needs for the
-current phase.
+**Important:** under stOLAS standard mode (the Phase 1b default), operators
+**do not hold a bond token themselves**. The stOLAS distributor pools JINN
+contributed by stakers and stakes on behalf of operators; your service gets
+created against that shared pool. `jinn fund-requirements` surfaces only the
+per-wallet ETH you need. If the distributor pool is drained, `jinn doctor`
+will warn you — the fix is a protocol-team refill, not operator action.
 
 ## Switching to mainnet
 
 When Phase 2 launches, the default flips. Until then:
 
 ```bash
-JINN_NETWORK=mainnet JINN_PASSWORD=secret jinn run
+JINN_NETWORK=mainnet \
+JINN_EARNING_DIR=~/.jinn-client/earning-mainnet \
+JINN_PASSWORD=secret \
+jinn run
 ```
 
+Use a distinct `JINN_EARNING_DIR` to keep testnet and mainnet keystore
+state isolated. Mixing them on the same directory is an easy way to
+point a mainnet daemon at a testnet-derived master wallet.
+
+## Troubleshooting
+
+Quick answers to the things that typically surprise new operators:
+
+- **Bootstrap loops for a minute then exits with `funding_required`** —
+  the CDP faucet drip is small (~0.0001 ETH per call) and the bootstrap
+  floor is 0.005 ETH. The client now drains the faucet up to 60 times per
+  invocation automatically; if you still see `funding_required`, CDP rate-
+  limited your master address. Wait 24h or fund manually:
+  <https://portal.cdp.coinbase.com/products/faucet>.
+- **Claude session exits in ~18 seconds with no trades** — usually means
+  the daemon ran from source (via `tsx`) instead of the compiled `dist/`,
+  so the MCP wrapper couldn't load `mcp-tools.js`. Run `yarn build && yarn
+  dev` (dev) or reinstall via `npm install -g @jinn-network/client@latest`
+  (operator). `jinn doctor` flags this as `daemon_runtime_ready`.
+- **Bootstrap fails with `Overflow(20, 0)` at `distributor.stake()`** —
+  the testnet stOLAS distributor pool is drained. Operators cannot fix
+  this; the Jinn protocol team has to refill it. Report to the testnet
+  status channel and re-run `jinn bootstrap` once the pool is topped up.
+- **Position auto-closed within seconds of opening** — most likely
+  a competing trading bot is active on the same Hyperliquid master. Use a
+  fresh HL master per protocol test; do not share master accounts between
+  experiments.
+- **`jinn doctor` passes but `jinn run` fails** — check the specific
+  check names in doctor's output vs the specific error from `run`. The
+  most common mismatch is auth-context: if you're in the `client/` git
+  checkout dir, `detectAuthContext` infers `docker-compose` mode even on
+  a bare host. Run the daemon from `$HOME` or any directory without a
+  `docker-compose.yml` that names `jinn-daemon`.
+
 ## How it works
 
 The daemon runs three concurrent loops:
@@ -196,4 +372,4 @@ Each loop call increments on-chain activity counters. Staking contracts read the
 
 ## Development
 
-See [CONTRIBUTING.md](./CONTRIBUTING.md) for development setup, running from source, and testing.
+See [CONTRIBUTING.md](https://github.com/Jinn-Network/mono/blob/main/client/CONTRIBUTING.md) for development setup, running from source, and testing.

package/deployments/deployment-claim-registry-baseSepolia.json

@@ -0,0 +1,13 @@
+{
+  "network": "baseSepolia",
+  "chainId": 84532,
+  "deployer": "0x15e78734481bD31F6e183dad05225505a45ACd07",
+  "deployedAt": "2026-04-18T00:00:00.000Z",
+  "config": {
+    "claimTTL": 300
+  },
+  "contracts": {
+    "claimRegistry": "0xd229A2C20333B747675090Ce38B8a1Fb2dafe6AC",
+    "acceptAllChecker": "0x2E5AB5b281EAb5b6556165e701b5da923223787D"
+  }
+}

package/deployments/deployment-jinn-testnet-faucet-baseSepolia-fast.json

@@ -0,0 +1,15 @@
+{
+  "network": "baseSepolia",
+  "chainId": 84532,
+  "deployer": "0x15e78734481bD31F6e183dad05225505a45ACd07",
+  "deployedAt": "2026-04-20T13:14:18.413Z",
+  "config": {
+    "jinnToken": "0xAB9a01cd4A379e36006ec6df2960CF39EF79df63",
+    "dripAmount": "100000000000000000000",
+    "dripInterval": 86400,
+    "initialSupplyBridged": "1000000000000000000000"
+  },
+  "contracts": {
+    "faucet": "0xa7c2DBA07E41F16eF94cbEAeAEd97bC904032619"
+  }
+}

package/dist/adapters/claim-registry/abi.d.ts

@@ -0,0 +1,127 @@
+/**
+ * Typed ABI fragments for ClaimRegistry.
+ *
+ * Mirrors the Solidity interface in contracts/src/claiming/ClaimRegistry.sol.
+ * Use these instead of the inline fragment in adapters/mech/types.ts when
+ * constructing a ClaimRegistryClient — they include the full event set.
+ */
+export declare const CLAIM_REGISTRY_ABI: readonly [{
+    readonly name: "claimJob";
+    readonly type: "function";
+    readonly stateMutability: "nonpayable";
+    readonly inputs: readonly [{
+        readonly name: "requestId";
+        readonly type: "bytes32";
+    }];
+    readonly outputs: readonly [];
+}, {
+    readonly name: "releaseClaim";
+    readonly type: "function";
+    readonly stateMutability: "nonpayable";
+    readonly inputs: readonly [{
+        readonly name: "requestId";
+        readonly type: "bytes32";
+    }];
+    readonly outputs: readonly [];
+}, {
+    readonly name: "expireClaim";
+    readonly type: "function";
+    readonly stateMutability: "nonpayable";
+    readonly inputs: readonly [{
+        readonly name: "requestId";
+        readonly type: "bytes32";
+    }];
+    readonly outputs: readonly [];
+}, {
+    readonly name: "getJobClaim";
+    readonly type: "function";
+    readonly stateMutability: "view";
+    readonly inputs: readonly [{
+        readonly name: "requestId";
+        readonly type: "bytes32";
+    }];
+    readonly outputs: readonly [{
+        readonly name: "claimer";
+        readonly type: "address";
+    }, {
+        readonly name: "expiresAt";
+        readonly type: "uint256";
+    }];
+}, {
+    readonly name: "claims";
+    readonly type: "function";
+    readonly stateMutability: "view";
+    readonly inputs: readonly [{
+        readonly name: "";
+        readonly type: "bytes32";
+    }];
+    readonly outputs: readonly [{
+        readonly name: "claimer";
+        readonly type: "address";
+    }, {
+        readonly name: "expiresAt";
+        readonly type: "uint256";
+    }];
+}, {
+    readonly name: "claimTTL";
+    readonly type: "function";
+    readonly stateMutability: "view";
+    readonly inputs: readonly [];
+    readonly outputs: readonly [{
+        readonly name: "";
+        readonly type: "uint256";
+    }];
+}, {
+    readonly name: "expiredClaimCount";
+    readonly type: "function";
+    readonly stateMutability: "view";
+    readonly inputs: readonly [{
+        readonly name: "";
+        readonly type: "address";
+    }];
+    readonly outputs: readonly [{
+        readonly name: "";
+        readonly type: "uint256";
+    }];
+}, {
+    readonly name: "JobClaimed";
+    readonly type: "event";
+    readonly inputs: readonly [{
+        readonly name: "requestId";
+        readonly type: "bytes32";
+        readonly indexed: true;
+    }, {
+        readonly name: "claimer";
+        readonly type: "address";
+        readonly indexed: true;
+    }, {
+        readonly name: "expiresAt";
+        readonly type: "uint256";
+        readonly indexed: false;
+    }];
+}, {
+    readonly name: "ClaimExpired";
+    readonly type: "event";
+    readonly inputs: readonly [{
+        readonly name: "requestId";
+        readonly type: "bytes32";
+        readonly indexed: true;
+    }, {
+        readonly name: "previousClaimer";
+        readonly type: "address";
+        readonly indexed: true;
+    }];
+}, {
+    readonly name: "ClaimReleased";
+    readonly type: "event";
+    readonly inputs: readonly [{
+        readonly name: "requestId";
+        readonly type: "bytes32";
+        readonly indexed: true;
+    }, {
+        readonly name: "claimer";
+        readonly type: "address";
+        readonly indexed: true;
+    }];
+}];
+export type ClaimRegistryAbi = typeof CLAIM_REGISTRY_ABI;