fix(dgclaw.sh): detect provider memo in entries field (acp-cli v2 format)

[SmallThingDev]

Issue

dgclaw.sh join polls 40 attempts then times out, even though the provider already posted the trigger memo "Ready to register agent on leaderboard" in the job history.

Repro from a fresh setup following the README Quick Start:

Waiting for provider memo (phase: budget_set, attempt 40/40)...
Error: Timed out waiting for trigger memo on job <jobId> after 40 attempts

Looking at the actual job state with acp job history --chain-id 8453 --job-id <jobId> --json:

{
  "jobId": "<jobId>",
  "status": "budget_set",
  "entryCount": 2,
  "entries": [
    { "kind": "message", "from": "<my-agent>", "content": "{...}" },
    {
      "kind": "message",
      "from": "0xd478a8B40372db16cA8045F28C6FE07228F3781A",
      "content": "Ready to register agent on leaderboard"
    }
  ]
}

The memo is right there in entries[1].content, the script just doesn't see it.

Root cause

In fund_acp_job (line 82), trigger detection only looks under .memoHistory:

trigger_found=$(echo "$status_response" | jq --arg t "$trigger" '
  ...
  | .memoHistory // []
  | [.. | strings | select(contains($t))]
  | length > 0' ...)

The current acp job history --json (acp-cli main) returns the memo array under .entries, not .memoHistory, so .memoHistory // [] falls through to [], the trigger string is never found, and polling runs to timeout.

Fix

One-line jq change. Try .entries as a fallback while keeping the original .memoHistory first for backward compat:

-      | .memoHistory // []
+      | (.memoHistory // .entries // [])

The recursive descent [.. | strings | select(contains($t))] is structure-agnostic, so nothing else needs touching.

After the patch

$ ./scripts/dgclaw.sh join
Using agent: <name> (<address>)
Checking agent tokenization...
Agent tokenized: <token>
Generating RSA key pair...
Creating join_leaderboard ACP job...
ACP job created: <jobId>
Funding job...
  Provider memo posted ("Ready to register agent on leaderboard") - funding...
  Funded successfully
Waiting for registration...
Registration completed!
{
  "agentAddress": "...",
  "tokenAddress": "...",
  "encryptedApiKey": "..."
}

Registration complete! API key saved to .env

Notes

The other .memoHistory references at lines 61-62 and 128-129 (phase computation) already fall back to .status // .phase // "PENDING" when .memoHistory is missing, so they handle the new format correctly without any change. Only the trigger detection in fund_acp_job was strict about the field name.

The fix is purely additive: when .memoHistory is present, the expression returns the same value as before. Only when it's absent does .entries take over. So no behavior change for any older acp-cli version that may still return .memoHistory.

Setup tested

• Fresh V2 agent (self-hosted, non-custodial), token launched via app.virtuals.io web UI
• acp-cli: latest main (clone fresh), Node.js 20.20.2
• dgclaw-skill: commit 3839ee1 (current HEAD of main)
• Agent wallet funded with USDC + ETH on Base
• Linux Ubuntu 24.04

[desiorac]

// in jq treats [] as truthy, so if memoHistory exists but is empty, the fallback to entries won't fire. Shouldn't affect this specific timeout bug, but there's a narrow overlap window if acp-cli ever returns both fields simultaneously.

For full coverage:

| ([.memoHistory // [], .entries // []] | add)

Merges both arrays before the recursive descent, no behavior change when only one is present. One-liner is the right call for the reported case though.

[SmallThingDev]

Nice one! happy to swap to add, makes it bulletproof.

[desiorac]

Yep, add handles the empty-array edge case cleanly. One thing to keep in mind: if both fields are absent (not just empty), add on two nulls returns null, so you may want ([...] | add) // [] as a final safety net depending on how strict the upstream schema is.

[SmallThingDev]

Hmm I might be missing something, but null // [] gives [], so [null, null] becomes [[], []] before add and we get [] not null right?

[desiorac]

You're right, I overlooked the coalescing step. If // [] is applied before the values reach add, then [null, null] becomes [[], []] and add folds that into [] — the null-propagation case I mentioned never actually fires. Good catch.