@reclaimprotocol/agent 0.1.33 → 0.1.35

package/lib/proof/check-attestor.js

@@ -0,0 +1,156 @@
+/**
+ * Attestor reachability check. Proves a public request with a throwaway owner
+ * key to show whether the attestor works from this machine, independent of any
+ * developer provider or site.
+ */
+import { createClaimOnAttestor } from '@reclaimprotocol/attestor-core';
+import { generateKeypair } from '@reclaimprotocol/client';
+import "./patch-domhandler.js";
+import { claimRejection, ensureAttestorCrypto, parseClaim, resolveAttestorUrl, } from "./proof-core.js";
+import { ensureZkFiles } from "./zk-files.js";
+/**
+ * Default time budget for one check. A live run takes about 8 s; a longer
+ * budget risks the MCP client's own tool-call timeout.
+ */
+export const CHECK_ATTESTOR_TIMEOUT_MS = 45000;
+/* eslint-disable @stylistic/max-len -- the source URL cannot wrap. */
+/**
+ * Request params for the check: the public CoinGecko price request from the
+ * attestor-core examples. Source:
+ * https://raw.githubusercontent.com/reclaimprotocol/attestor-core/refs/heads/main/example/coin-gecko.json
+ */
+/* eslint-enable @stylistic/max-len */
+export const COIN_GECKO_PARAMS = {
+    url: 'https://api.coingecko.com/api/v3/simple/price'
+        + '?ids=cardano,solana&vs_currencies=usd',
+    method: 'GET',
+    body: '',
+    headers: {
+        'User-Agent': 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_5 like Mac OS X) '
+            + 'AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 Safari/604.1',
+        'Sec-Fetch-Mode': 'same-origin',
+        'Sec-Fetch-Site': 'same-origin',
+    },
+    responseMatches: [
+        {
+            invert: false,
+            type: 'regex',
+            value: 'cardano":{"usd":(?<cardanoPrice>\\d*\\.*\\d*)}',
+        },
+        {
+            invert: false,
+            type: 'regex',
+            value: 'solana":{"usd":(?<solanaPrice>\\d*\\.*\\d*)}',
+        },
+    ],
+    responseRedactions: [
+        { jsonPath: '$.cardano', regex: 'cardano":{"usd":(.*?)}', xPath: '' },
+        { jsonPath: '$.solana', regex: 'solana":{"usd":(.*?)}', xPath: '' },
+    ],
+    additionalClientOptions: {},
+};
+/** The only secret in the example request. */
+const COIN_GECKO_SECRET_HEADERS = {
+    Referer: 'https://www.coingecko.com/en/nft',
+};
+/** Prefix of the error raised when the check exceeds its time budget. */
+const CHECK_TIMEOUT_MESSAGE = 'attestor check timed out';
+/**
+ * Signals that the attestor connection failed. Bare "timeout", "timed out",
+ * and "websocket" are left out: a target site's errors contain them too.
+ */
+const NETWORK_ERROR_PATTERN = new RegExp([
+    'connection closed',
+    'ERROR_NETWORK_ERROR',
+    'ECONNRESET',
+    'ECONNREFUSED',
+    'ENOTFOUND',
+    'EAI_AGAIN',
+    'ETIMEDOUT',
+    'EHOSTUNREACH',
+    'ENETUNREACH',
+    'socket hang up',
+    'websocket (connection|error|closed|failed)',
+    '(failed|unable|could not) to connect',
+    CHECK_TIMEOUT_MESSAGE,
+].join('|'), 'i');
+/** True when `message` looks like a network failure rather than a rejection. */
+export function isNetworkError(message) {
+    return message !== undefined && NETWORK_ERROR_PATTERN.test(message);
+}
+/** Prove the public CoinGecko request once and classify the outcome. */
+export async function checkAttestor(opts = {}) {
+    const attestorUrl = resolveAttestorUrl(opts.attestorUrl);
+    const timeoutMs = opts.timeoutMs ?? CHECK_ATTESTOR_TIMEOUT_MS;
+    const createClaim = opts.createClaim ?? createClaimOnAttestor;
+    const prepare = opts.prepare ?? (async () => {
+        ensureAttestorCrypto();
+        await ensureZkFiles();
+    });
+    const startedAt = Date.now();
+    const finish = (outcome) => {
+        return { ...outcome, attestorUrl, durationMs: Date.now() - startedAt };
+    };
+    let timer;
+    const timeout = new Promise((_, reject) => {
+        timer = setTimeout(() => {
+            reject(new Error(`${CHECK_TIMEOUT_MESSAGE} after ${timeoutMs} ms`));
+        }, timeoutMs);
+    });
+    try {
+        try {
+            await Promise.race([prepare(), timeout]);
+        }
+        catch (err) {
+            const error = messageOf(err);
+            return finish({
+                ok: false,
+                error,
+                errorKind: error.startsWith(CHECK_TIMEOUT_MESSAGE)
+                    ? 'attestor-unreachable'
+                    : 'setup-failed',
+            });
+        }
+        const claim = await Promise.race([
+            createClaim({
+                name: 'http',
+                params: COIN_GECKO_PARAMS,
+                secretParams: { headers: COIN_GECKO_SECRET_HEADERS },
+                ownerPrivateKey: generateKeypair().privateKey,
+                client: { url: attestorUrl },
+                zkEngine: 'stwo',
+            }),
+            timeout,
+        ]);
+        const rejection = claimRejection(claim);
+        if (rejection !== undefined) {
+            return finish({
+                ok: false,
+                error: rejection,
+                errorKind: isNetworkError(rejection)
+                    ? 'attestor-unreachable'
+                    : 'attestor-error',
+            });
+        }
+        return finish({
+            ok: true,
+            extractedParameters: parseClaim(claim).extractedParameters,
+        });
+    }
+    catch (err) {
+        const error = messageOf(err);
+        return finish({
+            ok: false,
+            error,
+            errorKind: isNetworkError(error)
+                ? 'attestor-unreachable'
+                : 'attestor-error',
+        });
+    }
+    finally {
+        clearTimeout(timer);
+    }
+}
+function messageOf(err) {
+    return err instanceof Error ? err.message : String(err);
+}

package/lib/tools/registry.d.ts

@@ -1,8 +1,20 @@
 import type { JSONSchema } from 'zod/v4/core';
+/** MCP tool hints that let a client decide when to ask for approval. */
+export interface ToolAnnotations {
+    /** The tool never changes state. */
+    readOnlyHint?: boolean;
+    /** The tool can delete or overwrite state. */
+    destructiveHint?: boolean;
+    /** Repeating a call with the same input has no further effect. */
+    idempotentHint?: boolean;
+    /** The tool reaches systems outside this machine. */
+    openWorldHint?: boolean;
+}
 export interface ToolDefinition {
     name: string;
     description: string;
     inputSchema: JSONSchema.ObjectSchema;
+    annotations?: ToolAnnotations;
 }
 export interface RegisteredTool {
     definition: ToolDefinition;

package/lib/tools/registry.js

@@ -75,6 +75,7 @@ export function extendTool(tool, extra) {
             name: base.name,
             description: extra.description ?? base.description,
             inputSchema,
+            ...(base.annotations ? { annotations: base.annotations } : {}),
         },
         handler: tool.handler,
     };

package/package.json

@@ -1,7 +1,7 @@
 {
 	"name": "@reclaimprotocol/agent",
 	"title": "Reclaim Agent",
-	"version": "0.1.33",
+	"version": "0.1.35",
 	"description": "Reclaim Protocol tools for AI coding agents. Reclaim lets your app verify data points about its users, such as a follower count, an account balance, or an order history. This package is the Reclaim MCP server: it gives your agent the tools to find, build, test, and fix data verification providers by capturing and replaying browser requests, drafting provider recipes, running zkTLS proofs, and publishing provider versions.",
 	"type": "module",
 	"main": "./lib/index.js",
@@ -83,7 +83,7 @@
 		"@modelcontextprotocol/sdk": "^1.29.0",
 		"@noble/hashes": "^2.2.0",
 		"@reclaimprotocol/attestor-core": "^5.1.5",
-		"@reclaimprotocol/client": "0.1.33",
+		"@reclaimprotocol/client": "0.1.35",
 		"@reclaimprotocol/tls": "^0.1.3",
 		"chrome-remote-interface": "^0.33.0",
 		"domhandler": "^6.0.0",

package/skill/SKILL.builder.md

@@ -11,32 +11,38 @@ Builder.
 
 ## The loop, at a glance
 
-Copy this checklist and check off each step as you finish it. Read the linked
-topic before a step you aren't already fluent in.
-
-- [ ] 1. `attach_browser` — pick a browser source with the developer.
-      → topic `browser`
-- [ ] 2. `list_tabs` → `start_capture(tabId)` ⇒ **`captureId`**, your handle for
-      everything below. → topic `capture`
-- [ ] 3. Drive the page: `navigate`, `wait_for_page`, `eval_in_page`,
-      `get_cookies`. Detect login, land on the page showing the value, trigger
-      the request. → topic `capture`
-- [ ] 4. `find_requests_containing` → `analyze_request_constraints` → pick an
-      **authenticated** request. → topic `capture`
-- [ ] 5. `propose_provider(captureId, requestId, …)` ⇒ **`draftId`** (recipe +
-      captured secrets, held server-side — secrets never enter the transcript).
-      → topic `draft`
-- [ ] 6. Parameterize user-specific URL segments; mark secrets. → topic `params`
-- [ ] 7. `replay_request(captureId, draftId)`, then again with
+Build a new org-private provider for the claim the developer described. Ask
+one question if the site, account, or value is ambiguous. Copy this checklist
+and check off each step. Read the linked topic before a step you don't know.
+
+- [ ] 1. Name the data points: only the values the claim must prove, usually
+      one or two. No identity or profile fields.
+- [ ] 2. `attach_browser`, then `list_tabs` → `start_capture(tabId)` ⇒
+      **`captureId`**. → topics `browser`, `capture`
+- [ ] 3. Open the sign-in page and wait for the developer to sign in
+      (`wait_for_page`). → topic `capture`
+- [ ] 4. Write the navigation script: sign-in redirect, then each data
+      point's page in order. → topic `user-script`
+- [ ] 5. `test_user_script({ script, keep: true })`. Fix and retest until it
+      reaches every page, also after a reload.
+- [ ] 6. Capture by letting the script navigate: `find_requests_containing` →
+      `analyze_request_constraints` → pick an **authenticated** request per
+      data point. → topic `capture`
+- [ ] 7. `propose_provider(captureId, requestId, …)` ⇒ **`draftId`**
+      (`targets` = the data points). → topic `draft`
+- [ ] 8. Parameterize user-specific URL segments; mark secrets.
+      → topic `params`
+- [ ] 9. `replay_request(captureId, draftId)`, then again with
       `withoutSecrets: true`. → topic `prove`
-- [ ] 8. `run_proof(captureId, draftId, ownerAddress)`.
+- [ ] 10. `run_proof(captureId, draftId, ownerAddress)`.
       → topics `prove`, `credentials`
-- [ ] 9. Resolve a `providerId` (**reuse before create**) →
-      `create_provider_version_from_capture` → `publish_provider_version` or
+- [ ] 11. `create_provider` (or a new version of a provider your org owns) →
+      `create_provider_version_from_capture` (publishes the kept script as
+      `webSettings.jsUserScripts`) → `publish_provider_version` or
       `submit_provider_version_for_review`. → topic `publish`
 
-Multi-request provider? Run steps 5–8 once per request, then publish every
-proven draft in one call. See topic `publish`.
+Data points on different requests? Run steps 7-10 once per request, then
+publish every proven draft in one call. See topic `publish`.
 
 <!-- topic: contributions -->
 
@@ -84,7 +90,7 @@ integration. Prefer Builder for new integrations.
 2. **Pick a tab and start the capture.** `list_tabs`, then
    `start_capture(tabId)` ⇒ a **`captureId`**: the session handle every browser
    and inspect tool takes as its first argument (`navigate`, `eval_in_page`,
-   `wait_for_page`, `get_cookies`, `list_requests`, `find_requests_containing`,
+   `wait_for_page`, `list_requests`, `find_requests_containing`,
    `propose_provider`). If a tab is already on the right origin use it,
    otherwise the first is usually fine. Capturing from the start is harmless —
    it also records the login navigation. Then `navigate(captureId, url)` to
@@ -93,13 +99,18 @@ integration. Prefer Builder for new integrations.
 
 3. <!-- common: login-detect -->
 
-4. **Navigate to the page that displays the value.** Construct the URL from what
-   you know about the site; eval for anything you need (for example, GitHub's
-   `meta[name="user-login"]`'s `content`), then `navigate(captureId, url)`.
+4. **Write and keep the navigation script** (topic `user-script`) as soon as
+   the developer is signed in, or the sign-in URL is known. Test it with
+   `test_user_script` and `keep: true`. The script visits each data point's
+   page; build its URLs from what you know about the site and read page state
+   with `eval_in_page` when needed (for example, GitHub's
+   `meta[name="user-login"]`'s `content`).
 
-5. **Trigger the request.** Capture has been live since step 2, so make the
-   call fire: `eval_in_page(captureId, "location.reload()")`, or click an
-   element / hit a SPA route programmatically. Don't ask the developer to click.
+5. **Trigger the requests by letting the script navigate.** Capture has been
+   live since step 2. Reload the page (`eval_in_page(captureId,
+   "location.reload()")`) so the kept script runs from the start. Don't click
+   by hand or ask the developer to; if a request needs an interaction, add it
+   to the script.
 
 6. <!-- common: identify-value -->
 
@@ -126,8 +137,9 @@ integration. Prefer Builder for new integrations.
 under that `draftId`; the secrets never enter the transcript, so you carry the
 `draftId`, not the provider JSON, into replay/prove.
 
-**Extracting more than one value?** Prefer a **single request whose response
-contains all of them** and draft them together — one `responseMatches` +
+**Extracting more than one value?** Add a value only when the claim needs it.
+Prefer a **single request whose response contains all of them** and draft them
+together — one `responseMatches` +
 `responseRedactions` pair per value. Find that request by running
 `find_requests_containing` for each value and picking a `requestId` common to
 all. Then pass a `targets` array, each entry with its `value` (exactly as it
@@ -136,7 +148,7 @@ appears) and a distinct `name`:
 ```
 propose_provider(captureId, requestId, name, targets: [
   { value: "Scratch-net", name: "username" },
-  { value: "Alex",        name: "name" },
+  { value: "2019",        name: "member_since_year" },
 ])
 ```
 
@@ -303,6 +315,11 @@ provider JSON. That's the final result.
 developer what's happening and drive the bootstrap yourself — see topic
 `credentials`. No restart needed, and the existing `draftId` stays valid.
 
+**Network error from `run_proof`.** Read its `diagnosis`. Attestor reachable
+→ the target site likely blocks the attestor's network; call
+`run_proof_via_pod`. Attestor unreachable → `check_attestor` confirms it; the
+fix is on the developer's network. Don't loop retries.
+
 <!-- common: prove-tail -->
 
 <!-- topic: publish -->
@@ -313,16 +330,13 @@ parameterization applied. `initialUrl` is the page where the user logs in / the
 value is displayed (for example, `https://github.com/Syed`) — **not** the API
 endpoint URL inside the provider.
 
-**1. Reuse before create — this is how duplicates happen.**
-`create_provider_version_from_capture` requires a `providerId`. Before minting a
-new one, search your existing providers with `providers` (by domain / data
-point) — a site you've already built is there. Match → pass its
-`providerId` and the capture lands as a NEW VERSION on it. Only call
-`create_provider(orgId, domain, slug, title, description)` when none exists
-(`orgId` from `list_orgs`; `domain` such as `github.com`, `slug` such as
-`github-username`, `title` such as "GitHub Username"). It starts PRIVATE with an
-empty seed version. Routing every run through `create_provider` is what stacks
-duplicates in "My providers".
+**1. Resolve the `providerId`.** For a new claim, call
+`create_provider(orgId, domain, slug, title, description)` (`orgId` from
+`list_orgs`; `domain` such as `github.com`, `slug` such as `github-username`,
+`title` such as "GitHub Username"). It starts PRIVATE with an empty seed
+version. Use an existing `providerId` only when your org owns the provider and
+you are revising it: the capture lands as a NEW VERSION on it. For another
+org's provider that almost fits, create your own provider and version.
 
 **2. Persist the version.**
 `create_provider_version_from_capture(providerId, provider, initialUrl, notes)`
@@ -339,12 +353,13 @@ or archive an existing version to apply provider changes.
   required at verification time. This proves that every request matched; it
   does not automatically bind a value extracted from one response to another
   request.
-- **Login/navigation-gated data:** supply `jsUserScripts` (plain page JS that
-  drives login/waits/navigation so the target request fires), or
-  `allowedJsRequests` (extra requests the script may fire, for example,
-  pagination). → topic `user-script`. Before populating `allowedJsRequests` for
-  a `verifyRequestProof({ providerId })` use case, read topic `hash-validation` — a
-  session-unique URL there makes verifyRequestProof reject every real proof.
+- **Navigation script:** the script kept with `test_user_script` (`keep: true`)
+  is published as `webSettings.jsUserScripts`. Pass `jsUserScripts` only to
+  override it. → topic `user-script`. For extra requests the script may fire
+  (for example, pagination), pass `allowedJsRequests`. Before populating it for
+  a `verifyRequestProof({ providerId })` use case, read topic
+  `hash-validation`: a session-unique URL there makes `verifyRequestProof`
+  reject every real proof.
 
 **3. `requiredContext` is derived for you.** The publish tool scans the recipe's
 url/body for `{{context.<name>}}` placeholders and emits a JSON Schema requiring
@@ -367,10 +382,8 @@ developer it's awaiting admin review.
 context params — for example, `context: { "username": "…" }` in
 `create_verification_session`. Quote the `requiredContext` from the created
 version verbatim — a session missing those fields gets a 400, and verification
-matches the supplied values exactly. Then ask once how they want to use it —
-try it now here, integrate it into an existing backend or frontend, or create a
-new app — unless they already said (see "Using a provider" in the server
-instructions).
+matches the supplied values exactly. Then continue as the server
+instructions say under "What the developer wants".
 
 **6. If the response includes `_notes` for an attached browser, follow them for
 an optional authenticated-state retest.** Only when its profile is still signed
@@ -383,35 +396,30 @@ the session for further edits; call `dispose_browser` only after they confirm.
 A `builder` session is quota-accounted, so don't leave it idle.
 
 <!-- topic: discover -->
-## Discover and resolve providers for the developer's app
+## Discover and resolve existing providers
 
-When a developer wants to add verification but doesn't know which providers to
-use, run the same flow the Discover UI does:
+Use this flow only when the developer asks to reuse existing providers or
+doesn't know what a site supports. Otherwise build a new provider (server
+instructions, "Choose the provider").
 
 1. Ask which website their users prove data from.
 2. `discover_data_points({ domain })` → what's verifiable there. Confirm the
    data points with the developer.
 3. `discover_resolve({ domain, dataPoints })` → the smallest provider set
    (`providers`, greedy combine), the `requiredContext` inputs to collect, and
-   any `uncovered` points (author those with the flow above, then re-resolve).
-4. Resolved providers are published and usable as-is: don't capture, replay,
-   or prove them unless the developer asks you to check or test one. Ask once
-   whether they just want to try them or want them in an app — just try it
-   now, integrate into an existing backend or frontend (this directory or
-   another path), or create a new app — unless they already said.
-5. Just try it (no app, callback, or client package) →
-   `create_verification_session({ providers: [{ providerId }, …], context,
-   verificationClientUrl })` with EVERY resolved provider id and the collected
-   context, give them `verificationUrl`, poll `get_verification_session` until
-   it is terminal, and report the outcome with `get_verification_result`
-   (builder-mode instructions cover the org key and temporary callback).
-   Integrate or new app → topic `integration`.
-
-`merge.mergeable` only signals the set *could* collapse into one provider — you
-still pass them all; the Builder runs them in one session.
-
-For client integration, result verification, or TEE binding, read topic
-`integration`.
+   any `uncovered` points (author those with the checklist in topic
+   `overview`, then re-resolve).
+4. Use only the data points the developer confirmed: show and read only those
+   and ignore the rest. A provider that needs any change gets your own copy
+   (server instructions, "Choose the provider"). Otherwise it's usable as-is;
+   don't capture, replay, or prove it unless the developer asks.
+5. To try them: `create_verification_session({ providers: [{ providerId }, …],
+   context, verificationClientUrl })` with EVERY resolved provider id and the
+   collected context. The server instructions ("Try a provider without an
+   app") cover the callback and polling. To integrate: topic `integration`.
+
+`merge.mergeable` only signals the set *could* collapse into one provider. Pass
+them all; the Builder runs them in one session.
 
 <!-- topic: integration -->
 
@@ -453,6 +461,7 @@ or omit `interceptorOptions`). If that fixes the provider, keep interception
 off and replace intercepted claims with `window.Reclaim.requestClaim`. Full
 checklist and remedies: topic `interception`.
 
-**Proof failures / attestor errors** → topic `prove`.
+**Proof failures / attestor errors** → topic `prove`. For a network error,
+read `run_proof`'s `diagnosis`, then `check_attestor` or `run_proof_via_pod`.
 **Browser won't launch or attach** → topic `browser`.
 **Missing signing key** → topic `credentials`.

package/skill/SKILL.common.md

@@ -112,13 +112,18 @@ Ask plainly:
 
 If they say yes:
 
-1. Call `share_browser_view` with no arguments. It returns the viewer `port` and
-   the `command` (`cloudflared tunnel --url http://localhost:<port>`). The MCP
-   server does not run cloudflared.
-2. Run `command` yourself in the background. If `cloudflared` is not installed,
-   ask the developer to install it; do not install it without their approval.
-3. Read its output for the `https://<words>.trycloudflare.com` URL. Never guess
-   or reconstruct the hostname.
+1. Call `share_browser_view` with no arguments. It returns the viewer `port`
+   and the `command` (`cloudflared tunnel --url http://localhost:<port>`). The
+   MCP server does not run cloudflared.
+2. Ask the developer to choose, and start no tunnel until they answer:
+   - **They run it (recommended).** They run `! <command>` in this session and
+     paste the `https://<words>.trycloudflare.com` URL. The tunnel then lives
+     in their shell, and they decide when it closes.
+   - **You run it.** They approve you running `command` in the background. If
+     `cloudflared` is not installed, ask them to install it; do not install it
+     without their approval.
+3. When you run it, read its output for the URL. Never guess or reconstruct the
+   hostname.
 4. Call `share_browser_view({ publicUrl })` with that URL. **Relay the returned
    `url` verbatim, on its own line.** It includes `liveview.html?magnify=1`.
 
@@ -138,8 +143,8 @@ If they say yes:
 - **Opening it on a phone lays the page out for that phone**, with touch,
   pinch-zoom and the soft keyboard. That is the reason to reach for `container`
   when a site only works on mobile.
-- **Stop the cloudflared process you started as soon as they're done.** The
-  browser keeps running. `dispose_browser` and `reset_session` stop the
+- **Stop a cloudflared process you started as soon as they're done.** If they
+  started it, tell them to stop it. The browser keeps running. `dispose_browser` and `reset_session` stop the
   container itself, but not your cloudflared process.
 - **Expose only the viewer port** that `share_browser_view` returns, never the
   browser's CDP port.
@@ -381,6 +386,13 @@ supplies are context params.
     `result.attestorLogs` and dumps `~/.reclaim/proof-runs/<timestamp>.json`
     (`runLogPath`). Off by default — suggest it for a recurring failure.
 
+    **Network errors** ("connection closed", `ERROR_NETWORK_ERROR`, timeouts):
+    read the result's `diagnosis`. It says whether the attestor is reachable
+    from this machine. If it is, the target site likely blocks the attestor's
+    network; in builder mode, run `run_proof_via_pod`. If it is not, call
+    `check_attestor` after the developer fixes their network. Do not loop
+    retries; one `run_proof` per change.
+
     **Do not auto-retry with a different `attestorUrl`.** There is one live
     public attestor; backup hostnames (`attestor-2.*`, and so on) **do not
     exist**. `attestorUrl` is only for a developer-supplied private/staging URL.
@@ -424,7 +436,8 @@ conversation.
 1. **`resolve_owner_key`** returns only the derived address.
    - `{ ready: true, address }` → call `run_proof` with it. No prompts.
    - `{ ready: false }` → ask the developer once: **their own key** →
-     `import_credentials({ privateKey: "0x…" })` (a `keyFile` path also works),
+     `import_credentials({ keyFile })` (a path to a file holding the key; never
+     ask them to paste it),
      or **a fresh one** → `issue_credentials({})` (a fine default for test
      proofs — owner identity doesn't matter). Either writes to the project
      `.env` (mode 0600, added to `.gitignore`), never to `~/.reclaim`. Then