@jinn-network/client 0.1.2 → 0.1.3-canary.24b69ea4

package/CHANGELOG.md

@@ -1,5 +1,25 @@
 # Changelog
 
+## Unreleased
+
+- Operator-app first-run polish (jinn-mono-mc24): a brand-new operator can run `jinn run` with no env var, no setup, no input.
+  - `jinn run` now auto-generates a keystore password if `JINN_PASSWORD` isn't set and `~/.jinn-client/keystore-password` doesn't already exist (mode 0600). Replaces the previous fatal-exit on missing env var.
+  - Daemon API server now starts BEFORE init/bootstrap; the operator panel auto-opens immediately and shows progress while init/bootstrap runs.
+  - New top-level loading screen in the SPA renders during init / `mode: 'uninitialized'`, with spinner + latest event status line + collapsible event log; transitions to the four-region App once `/v1/bootstrap` is ready.
+  - `ClaudeAuthCard` is now a "Sign in with Claude" button (in `bare` runtime mode); the daemon spawns `claude /login` server-side via the existing `buildLoginCommand` helper. Docker / container modes still surface the appropriate CLI command since the daemon can't reach the operator's host browser.
+  - Keystore password change is now a `SettingsCard` in the panel (`POST /v1/setup/change-password`). The existing `jinn keys change-password` CLI continues to work for scripted use.
+  - Removed the unreachable `KeystoreCreateCard` and `POST /v1/setup/keystore` endpoint (daemon now owns keystore creation; the panel observes).
+- Removed the `jinn quickstart` verb; `jinn run` now subsumes its zero-to-running flow (resolve/generate password, init wallet, bootstrap fleet, then start the daemon in the foreground). The corresponding MCP tool was renamed `jinn_run`. Existing scripts using `jinn quickstart` should switch to `jinn run`. (jinn-mono-zqm2)
+
+## 0.1.3
+
+- Added the v0 testnet cross-chain JINN claim loop, including bundled Sepolia/Base Sepolia MVI deployment artifacts, MockMessenger burn-in support, and canonical OP-Stack verifier canary tooling.
+- Added Safe v1.3 inner-revert decoding so permanent claim and delivery races stop retrying with generic `GS013` errors.
+- Updated bundled Phase 1b deployment defaults for the proxy-deployable V2 activity checker and JINN MVI testnet stack.
+- Added release-gate coverage for contract tests, storage-layout drift checks, and Foundry invariant harness compilation.
+- Hardened the local operator release gate for the current adapter API, ERC-8004 stubbed subgraph surface, and forked-chain `setAgentWallet` deadlines.
+- Switched the docker testnet acceptance gate from legacy health-check intents to the auto-generated `prediction.v0` loop. The gate now requires both restoration and evaluation success per cycle, gates on cycles produced after `runStartAt`, and uses tighter cycle-shaping params (`JINN_PREDICTION_V0_WINDOW_MS=120000`, `JINN_PREDICTION_V0_RESOLVE_GAP_MS=60000`) so a full restoration→delivery→evaluation→claim round-trip lands inside the 20-minute timeout.
+
 ## 0.1.2
 
 - Replaced the `mech-client-ts` IPFS upload dependency with the client’s own Autonolas registry upload path, reducing the packed install footprint and removing the deprecated js-IPFS transitive chain from the release artifact.

package/CONTRIBUTING.md

@@ -13,10 +13,15 @@ Development happens in the [jinn-mono](https://github.com/Jinn-Network/mono) mon
 ```bash
 cd client
 yarn install
-yarn test              # vitest suite — 267 tests
+yarn test              # vitest suite — see docs/runbooks/testing.md
 yarn typecheck         # tsc --noEmit
 ```
 
+## Tests
+
+See [`docs/runbooks/testing.md`](../docs/runbooks/testing.md) for the SOP.
+Shared helpers live in `test/_support/`.
+
 ## Running from source
 
 ```bash
@@ -69,7 +74,7 @@ The `files` field in `package.json` ensures only `dist/`, `deployments/`, `READM
 
 ## 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).
+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`), the cross-operator donation consumption gate (`yarn release:donation-consumption`), the contracts release gate (`cd ../contracts && yarn test && forge install foundry-rs/forge-std --no-git && forge test --match-contract Invariant`), 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
 
@@ -93,6 +98,8 @@ This copies the 4 deployment JSON files from `contracts/` into `client/deploymen
 | `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:donation-consumption` | Prove two isolated operators can consume donated SWE execution data through real testnet IPFS/subgraph/MCP paths |
+| `cd ../contracts && yarn test && forge install foundry-rs/forge-std --no-git && forge test --match-contract Invariant` | Run the contracts release gate |
 | `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 |

package/README.md

@@ -1,10 +1,33 @@
 # @jinn-network/client
 
-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.
+Jinn protocol client. Runs a headless daemon that participates in the Jinn training loop: create Tasks, solve them through Harnesses, evaluate Solutions, 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>
 
+## Operator panel (local web UI)
+
+Running `jinn run` opens a browser to `http://127.0.0.1:7331`
+with the operator panel — Status, Visibility (live event stream), Setup
+(bootstrap state machine), and an embedded Claude Code session in Auto Mode
+(when available).
+
+To suppress auto-open: `jinn run --no-ui`.
+
+To open the panel manually for an already-running daemon: `jinn ui`.
+
+The panel uses a localhost-only session token written to `~/.jinn-client/ui-token`
+(mode 0600). Browser auth happens via a one-shot handshake URL the daemon prints
+on startup (`[api] UI handshake URL: http://127.0.0.1:<port>/auth/handshake?k=<key>`).
+The launcher automatically opens this URL; subsequent loads reuse the cookie.
+
+Setup-mode behaviour: while the fleet bootstrap is incomplete, the API surface
+and SPA come up immediately, and the daemon's intent loops are gated until
+bootstrap reaches `complete`. The Setup region of the SPA renders the 11-step
+state machine and an "awaiting funding" card with the address to fund.
+
+For SPA development, see [`src/dashboard/spa/README.md`](src/dashboard/spa/README.md).
+
 ## Install
 
 ```bash
@@ -26,10 +49,10 @@ The fast path for a new operator on Base Sepolia:
 jinn auth
 
 # Zero-to-running (wallet + funding check + bootstrap + run).
-jinn quickstart
+jinn run
 ```
 
-On first run, `jinn quickstart` generates a random keystore password, saves
+On first run, `jinn run` 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
@@ -41,14 +64,15 @@ password from that file automatically — no env var needed.
 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:
+**Advanced / CI — manage the password yourself:** set `JINN_PASSWORD` before
+`jinn run` and no file will be written to disk. Use `--password-fd N` for
+CI pipelines that read from a secret manager:
 
 ```bash
-JINN_PASSWORD=your-secret jinn quickstart
+JINN_PASSWORD=your-secret jinn run
 ```
 
-**Step by step** (skip if `quickstart` worked):
+**Step by step** (skip if `jinn run` worked):
 
 ```bash
 # 1. Generate the encrypted keystore (picks an HD wallet deterministically).
@@ -89,13 +113,13 @@ 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`
+3. `~/.jinn-client/keystore-password` — auto-generated by `jinn run`
 
 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
+**Security note:** when `jinn run` 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.
@@ -113,55 +137,57 @@ MCP-capable tool, you can skip the shell commands above. After installing
 the client, wire Jinn into your agent:
 
 ```bash
-jinn plugin install
+jinn integrations install
 ```
 
 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.
+Run `jinn integrations doctor --human` to see what's detected.
 
 Then open your agent and paste:
 
-> Set up a Jinn Network testnet operator on this machine. Run `jinn quickstart`,
+> Set up a Jinn Network testnet operator on this machine. Run `jinn run`,
 > 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.
 
 The `jinn-operator` skill activates on mentions of "jinn", "jinn network", and
-"jinn quickstart", then walks your agent through install, auth, bootstrap, and
+"jinn run", 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
+## Opting in to SolverNets
 
-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
+After `jinn run`, your daemon participates in deterministic `prediction.v0`
+Tasks by default on testnet through the Prediction SolverNet. Other SolverNets,
+like one for `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`:
+Inspect and toggle participation with `jinn solver-nets`:
 
 ```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
+jinn solver-nets list --human
+jinn solver-nets show prediction --human
+jinn solver-nets enable prediction --harness claude-code-learner
+jinn solver-nets set-harness prediction prediction-v0-baseline
+jinn solver-nets add-plugin prediction bundled:jinn-prediction-plugin
+jinn solver-nets disable prediction
+jinn solver-nets doctor prediction
 ```
 
-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.
+SolverPlugins are attached to SolverNets, not Harnesses. Changing a SolverNet's
+Harness changes the executor used for future Tasks, while the SolverNet's
+canonical and extra plugin set follows the SolverNet. 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 a SolverNet automatically.
 
 **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
+responsible Harness is actually ready. If a portfolio.v0 request arrives and your
+api-wallet isn't approved, the daemon records the Task as FAILED locally
 with a clear reason instead of wasting gas claiming it.
 
 ## Docker
@@ -227,16 +253,15 @@ docker run --rm ghcr.io/jinn-network/client:latest version --json
 
 | Command | Purpose | Idempotent |
 |---|---|---|
-| `jinn quickstart` | One-shot init + funding check + bootstrap + run | Yes |
+| `jinn run` | One-shot init + funding check + bootstrap + start the daemon (foreground) | Yes |
 | `jinn init` | Generate wallet + keystore + fleet state | Yes |
 | `jinn doctor` | Preflight checks without mutation | Yes |
 | `jinn bootstrap` | Advance toward a running fleet | Yes |
 | `jinn fund-requirements` | List what needs funding | Yes |
-| `jinn run` | Start the daemon (foreground) | N/A |
 | `jinn stop` | Signal a running daemon to stop | Yes |
 | `jinn version` | Version, phase, deployment digest | Yes |
-| `jinn update` | Update the client package + refresh plugins | Yes |
-| `jinn plugin install` | Wire Jinn into Claude Code / Codex / other AI tools | Yes |
+| `jinn update` | Update the client package + refresh integrations | Yes |
+| `jinn integrations install` | Wire Jinn into Claude Code / Codex / other AI tools | Yes |
 
 ### Monitoring
 
@@ -250,7 +275,7 @@ docker run --rm ghcr.io/jinn-network/client:latest version --json
 | `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.
+Operator panel: when `jinn run` is active, open [`http://127.0.0.1:7331/`](http://127.0.0.1:7331/) for live in-flight Tasks, verdicts, earnings, fleet balances, recent activity, and next actions. See [Operator panel](#operator-panel-local-web-ui) above for auth + setup-mode details.
 
 ### Actions
 
@@ -258,7 +283,7 @@ All action verbs support `--dry-run` and `--yes`.
 
 | Command | Purpose |
 |---|---|
-| `jinn submit-intent` | Publish a desired state |
+| `jinn tasks submit` | Publish a Task |
 | `jinn claim-rewards` | Pull pending protocol rewards |
 | `jinn fleet scale --to N` | Grow or shrink fleet |
 | `jinn fleet retire <index>` | Retire one service |
@@ -293,10 +318,11 @@ JINN_PASSWORD=secret jinn run --config ./my-config.json
 | claudePath | JINN_CLAUDE_PATH | claude |
 | pollIntervalMs | JINN_POLL_INTERVAL_MS | 5000 |
 | apiPort | JINN_API_PORT | 7331 |
+| apiBindHost | JINN_API_BIND_HOST | `127.0.0.1` (loopback only; set to `0.0.0.0` for LAN access — pairs with bearer-token auth on cost-mutating routes) |
 | dbPath | JINN_DB_PATH | ~/.jinn-client/jinn.db |
 | earningDir | JINN_EARNING_DIR | ~/.jinn-client/earning |
 | peers | JINN_PEERS | [] |
-| desiredStates | JINN_DESIRED_STATES | [] (testnet auto-intent generator posts `prediction.v0`) |
+| tasks | JINN_TASKS | [] (testnet auto-task 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.
 
@@ -362,13 +388,7 @@ Quick answers to the things that typically surprise new operators:
 
 ## How it works
 
-The daemon runs three concurrent loops:
-
-1. **CreatorLoop** — posts desired states as restoration jobs
-2. **RestorerLoop** — claims requests, spawns Claude to attempt restoration, submits results
-3. **DeliveryWatcherLoop** — claims deliveries, creates evaluation jobs
-
-Each loop call increments on-chain activity counters. Staking contracts read these at checkpoints to determine reward eligibility.
+See [`client/ARCHITECTURE.md`](https://github.com/Jinn-Network/mono/blob/main/client/ARCHITECTURE.md) for the integrating narrative — operator app, CLI, daemon loops, task lifecycle, and extension points — with code pointers for each layer.
 
 ## Development
 

package/deployments/deployment-jinn-mvi-l1-sepolia-fast.json

@@ -0,0 +1,36 @@
+{
+  "network": "sepolia",
+  "chainId": 11155111,
+  "deployer": "0x15e78734481bD31F6e183dad05225505a45ACd07",
+  "deployedAt": "2026-04-29T12:14:01.626Z",
+  "config": {
+    "timingProfile": "fast-test",
+    "votingDelaySeconds": 60,
+    "votingPeriodSeconds": 600,
+    "proposalThreshold": "0",
+    "quorumNumerator": 4,
+    "timelockMinDelaySeconds": 60
+  },
+  "distributor": {
+    "operatorRatio": "750000000000000000",
+    "daoRatio": "250000000000000000",
+    "wCreation": "1",
+    "wRestorationDelivery": "1",
+    "wEvaluationDelivery": "1"
+  },
+  "messenger": {
+    "mode": "mock",
+    "address": "0x30E2f1A5691a999053A54e8DAf9496CD7ccF2DFD",
+    "owner": "0x34516dB851f03f8E14d0c1cD56200175e914cCf0"
+  },
+  "handover": {
+    "renounceAdmin": false
+  },
+  "contracts": {
+    "JINN": "0x0bc0B2f733bF4229FD58Baaac5ebFEf2AEc83C4A",
+    "TimelockController": "0x5CE9c7E24f0509490a91a1cD285DDFF70A9C058D",
+    "JinnGovernor": "0xbbc43A1B5AC699de09577dAE4A1007a3bA704D9E",
+    "JinnDistributor": "0xaC9CD847660d05e77D82A3684aFC4EbFd94fBfe6",
+    "Messenger": "0x30E2f1A5691a999053A54e8DAf9496CD7ccF2DFD"
+  }
+}

package/deployments/deployment-jinn-mvi-l1-sepolia.json

@@ -0,0 +1,36 @@
+{
+  "network": "sepolia",
+  "chainId": 11155111,
+  "deployer": "0x15e78734481bD31F6e183dad05225505a45ACd07",
+  "deployedAt": "2026-04-29T12:14:01.626Z",
+  "config": {
+    "timingProfile": "fast-test",
+    "votingDelaySeconds": 60,
+    "votingPeriodSeconds": 600,
+    "proposalThreshold": "0",
+    "quorumNumerator": 4,
+    "timelockMinDelaySeconds": 60
+  },
+  "distributor": {
+    "operatorRatio": "750000000000000000",
+    "daoRatio": "250000000000000000",
+    "wCreation": "1",
+    "wRestorationDelivery": "1",
+    "wEvaluationDelivery": "1"
+  },
+  "messenger": {
+    "mode": "mock",
+    "address": "0x30E2f1A5691a999053A54e8DAf9496CD7ccF2DFD",
+    "owner": "0x34516dB851f03f8E14d0c1cD56200175e914cCf0"
+  },
+  "handover": {
+    "renounceAdmin": false
+  },
+  "contracts": {
+    "JINN": "0x0bc0B2f733bF4229FD58Baaac5ebFEf2AEc83C4A",
+    "TimelockController": "0x5CE9c7E24f0509490a91a1cD285DDFF70A9C058D",
+    "JinnGovernor": "0xbbc43A1B5AC699de09577dAE4A1007a3bA704D9E",
+    "JinnDistributor": "0xaC9CD847660d05e77D82A3684aFC4EbFd94fBfe6",
+    "Messenger": "0x30E2f1A5691a999053A54e8DAf9496CD7ccF2DFD"
+  }
+}

package/deployments/deployment-jinn-mvi-l2-baseSepolia.json

@@ -0,0 +1,12 @@
+{
+  "network": "baseSepolia",
+  "chainId": 84532,
+  "deployer": "0x15e78734481bD31F6e183dad05225505a45ACd07",
+  "deployedAt": "2026-04-29T11:37:34.801Z",
+  "contracts": {
+    "JinnClaimEmitter": "0xDB2f776D78d9aF12792C2C0f9875465eDaa859E7",
+    "RestorationActivityCheckerV2": "0x0e1B5f264F4FAdcFAA950fb00c58d9A39C040f70",
+    "JinnRouterV2": "0x13dae57a54A7DF862113BcA8Ee2fd3dEf6a6A94A",
+    "ServiceRegistry": "0x31D3202d8744B16A120117A053459DDFAE93c855"
+  }
+}

package/deployments/deployment-phase1b-mech-baseSepolia-fast.json

@@ -18,9 +18,9 @@
     "mechMarketplace": "0xD3233FdAaB51E9775f6bFCE8242B02C181D7c0e7",
     "balanceTracker": "0xDbeEF1947F7BB3657f984aA6b230a0ca6578229D",
     "mechFactory": "0x206183F35B2450Ca15A906BB923E74d945F78d67",
-    "jinnRouter": "0x6059Dd37eB0FD3a55BCe7A3C1fA86AB84F2d9675",
+    "jinnRouter": "0x13dae57a54A7DF862113BcA8Ee2fd3dEf6a6A94A",
     "serviceRegistry": "0x31D3202d8744B16A120117A053459DDFAE93c855",
-    "activityChecker": "0xF4Ca4943Eb0b0927d754A6A95206364f017D45f6",
-    "stakingToken": "0xf358b5c1ac4ddc4e807b5baf008826bf193eab3b"
+    "activityChecker": "0x0e1B5f264F4FAdcFAA950fb00c58d9A39C040f70",
+    "stakingToken": "0x24e34E5037956a5Feca1AAAfaA30297084C228B8"
   }
 }

package/deployments/deployment-stolas-l2-baseSepolia-fast.json

@@ -21,7 +21,7 @@
     "safeMultisigWithRecoveryModule": "0x20F7b9b55a88e3b2561fe83B076DE52916C7eaf0",
     "collectorImpl": "0x6A7a3aBdbfF301A6212ebA1523E579399833C718",
     "collector": "0x21c52Be4F656435F97d0335B37e21B417c8b6DFa",
-    "distributorImpl": "0xf734551289f11431486D60621F4BDB0081887B34",
+    "distributorImpl": "0xD47e4Ff84d930631dbcfadc1C27d916D9a5cc2e1",
     "distributor": "0x20951FBDb4F9cB1f051ef416BCB11A9Cfe3CEf81",
     "multisigGuardImpl": "0xD6229A8b3D1b5824e824E6589469F85987379183",
     "multisigGuard": "0x77aE56B2B745b3e81002090749Ef59B72B688D5F",

package/deployments/deployment-task-coordinator-router-v3-baseSepolia-fast.json

@@ -0,0 +1,38 @@
+{
+  "network": "baseSepolia",
+  "chainId": 84532,
+  "deployer": "0x15e78734481bD31F6e183dad05225505a45ACd07",
+  "owner": "0x15e78734481bD31F6e183dad05225505a45ACd07",
+  "deployedAt": "2026-05-02T12:27:26.420Z",
+  "config": {
+    "timingProfile": "fast-test",
+    "mechMarketplaceSource": "deployment-phase1b-mech-baseSepolia-fast.json",
+    "activityCheckerSource": "deployment-phase1b-router-checker-baseSepolia-fast.json",
+    "coordinatorInitialOwner": "0x15e78734481bD31F6e183dad05225505a45ACd07"
+  },
+  "contracts": {
+    "taskCoordinatorImpl": "0x830bFdBdA48D599e414c51888c8CDA6c84e67B18",
+    "taskCoordinator": "0x9ce736d3CB367cC5Db538B7962bdf416EbD7451B",
+    "jinnRouterV3Impl": "0x5f3E1e26Fd26b7A6BE4171976e555d62Bd3dcFC0",
+    "jinnRouterV3": "0xdC9BCcEB7aca21Ad4Ca2Fc5B4d7aea6b4F6CedD9",
+    "mechMarketplace": "0xD3233FdAaB51E9775f6bFCE8242B02C181D7c0e7",
+    "activityChecker": "0x0e1B5f264F4FAdcFAA950fb00c58d9A39C040f70",
+    "activityCheckerImpl": "0x9e573CFbbc52729528199005A9F3d274FE7052C4"
+  },
+  "upgrades": [
+    {
+      "upgradedAt": "2026-05-02T12:27:26.420Z",
+      "deployer": "0x15e78734481bD31F6e183dad05225505a45ACd07",
+      "previous": {
+        "taskCoordinatorImpl": "0x9707fC9681B0da32A0D4256f76f51654FCdD7125",
+        "jinnRouterV3Impl": "0x947291377b33F7F560df093a812A22128063efE1",
+        "activityCheckerImpl": null
+      },
+      "current": {
+        "taskCoordinatorImpl": "0x830bFdBdA48D599e414c51888c8CDA6c84e67B18",
+        "jinnRouterV3Impl": "0x5f3E1e26Fd26b7A6BE4171976e555d62Bd3dcFC0",
+        "activityCheckerImpl": "0x9e573CFbbc52729528199005A9F3d274FE7052C4"
+      }
+    }
+  ]
+}

package/dist/adapters/adapter.d.ts

@@ -1,18 +1,29 @@
-import type { DesiredState, RequestId, RestorationRequest, RestorationResult, DeliveredResult } from '../types/index.js';
+import type { Task, RequestId, PostedTask, TaskAnnouncement, TaskRequest, TaskResult, DeliveredResult } from '../types/index.js';
+import type { Hex } from 'viem';
 export interface ExecutionAdapter {
     readonly name: string;
     initialize(): Promise<void>;
-    postDesiredState(state: DesiredState): Promise<RequestId>;
+    postTask(state: Task): Promise<PostedTask>;
     /**
-     * Optional: returns the IPFS CID of the most recently posted intent payload.
-     * Populated by adapters that upload to IPFS as part of `postDesiredState`
+     * Optional: returns the IPFS CID of the most recently posted Task payload.
+     * Populated by adapters that upload to IPFS as part of `postTask`
      * (e.g. MechAdapter). Used by the posting service for ERC-8004 registration.
      * Returns undefined for adapters that do not upload (e.g. LocalAdapter).
      */
-    getLastPostedIntentCid?(): string | undefined;
-    watchForRequests(): AsyncIterable<RestorationRequest>;
-    claimRequest(requestId: RequestId): Promise<void>;
-    submitResult(requestId: RequestId, result: RestorationResult): Promise<void>;
+    getLastPostedTaskCid?(): string | undefined;
+    watchForTasks(): AsyncIterable<TaskAnnouncement>;
+    claimTask(taskId: string): Promise<TaskRequest>;
+    submitResult(requestId: RequestId, result: TaskResult): Promise<void>;
+    claimEvaluation?(taskId: string, attemptIndex: number, evaluationTaskCidDigest: Hex): Promise<{
+        taskId: string;
+        attemptIndex: number;
+        verdictIndex: number;
+        requestId: string;
+        txHash: Hex;
+        blockNumber?: number;
+    }>;
+    submitSolutionDelivery?(requestId: RequestId, solutionDigest: Hex): Promise<void>;
+    submitVerdictDelivery?(requestId: RequestId, verdictDigest: Hex, verdictCode?: number): Promise<void>;
     watchForDeliveries(): AsyncIterable<DeliveredResult>;
     stop(): Promise<void>;
 }

package/dist/adapters/local/adapter.d.ts

@@ -1,20 +1,21 @@
 import type { ExecutionAdapter } from '../adapter.js';
-import type { DesiredState, RequestId, RestorationRequest, RestorationResult, DeliveredResult } from '../../types/index.js';
+import type { Task, RequestId, PostedTask, TaskAnnouncement, TaskRequest, TaskResult, DeliveredResult } from '../../types/index.js';
 export declare class LocalAdapter implements ExecutionAdapter {
     readonly name = "local";
+    private nextTaskId;
+    private tasks;
     private requests;
-    private pendingRequests;
-    private deferredEvalRequests;
+    private claimCounts;
+    private pendingTasks;
     private pendingDeliveries;
-    private requestWaiters;
+    private taskWaiters;
     private deliveryWaiters;
-    private deliveredRequestIds;
     private stopped;
     initialize(): Promise<void>;
-    postDesiredState(state: DesiredState): Promise<RequestId>;
-    watchForRequests(): AsyncIterable<RestorationRequest>;
-    claimRequest(_requestId: RequestId): Promise<void>;
-    submitResult(requestId: RequestId, result: RestorationResult): Promise<void>;
+    postTask(state: Task): Promise<PostedTask>;
+    watchForTasks(): AsyncIterable<TaskAnnouncement>;
+    claimTask(taskId: string): Promise<TaskRequest>;
+    submitResult(requestId: RequestId, result: TaskResult): Promise<void>;
     watchForDeliveries(): AsyncIterable<DeliveredResult>;
     stop(): Promise<void>;
 }