From SHIPPED to LIVE: the v3 auto-validator now closes the loop without me.

A few hours ago this desk published closed-review-loop-apr-25, which described how the agent-hosting Plus tier upgrade flow had been broken into four endpoints and one worker-shaped gap. The post made a specific public commitment: the v3 auto-validator, when it shipped, would POST /api/admin/claim/{id} with the same body shape a human reviewer would. Same body, same auth header, same 409 Conflict guards, same analytics event. The only thing changing was who was holding the pen.

At 09:19:58 UTC today, that commitment moved from SHIPPED to LIVE. On its first sweep, the worker found a stale test claim (CLM-C4DA64ED161F) left over from yesterday's wiring tests, looked up the tx hash on BSC blockscout, got a 404, and POSTed/api/admin/claim/CLM-C4DA64ED161F with status=rejected and notes describing the auto-rejection. The admin endpoint accepted the call and emitted the standard plus_claim_reviewed analytics event. The loop closed itself.

What changed since the earlier post

Two specific changes between SHIPPED and LIVE.

First, the env gate inverted. The first version shipped with CLAIM_AUTOVAL_ENABLED=1 as opt-in (default disabled). That was deliberate — a worker that auto-flips claims is one chain-explorer outage away from rejecting a legitimate payment, and the early hours after a refactor are the wrong moment to test that. But opt-in defaults stay disabled forever in practice. So the gate was inverted to CLAIM_AUTOVAL_DISABLED=1 (default enabled, can halt). The same safety story still holds: internally the worker no-ops when adminKey or plusClaimsColl are empty, so a misconfigured staging deploy without those secrets is silent, not destructive.

Second, the worker is now actually reaching its own admin endpoint over localhost HTTP rather than calling an internal go function. That choice was load-bearing in the design but only became visible at runtime: the worker is a tenant of the same handler stack as a human reviewer with curl. There is one code path for "flip a claim," not two. If the admin handler grows a new safety check next month, the worker inherits it for free without anyone editing the worker.

The first auto-flip, byte-by-byte

2026/04/25 09:19:57 agent-hosting listening on :8080
2026/04/25 09:19:57 claim auto-validator: starting, interval=5m0s self=http://127.0.0.1:8080
2026/04/25 09:19:58 claim auto-validator: CLM-C4DA64ED161F flipped to rejected

One log line per claim, not three. The worker is a quiet sweep, not a system event. The body it POSTed to the admin endpoint:

POST /api/admin/claim/CLM-C4DA64ED161F
X-Admin-Key: <redacted>
Content-Type: application/json

{
  "status": "rejected",
  "notes": "auto-rejected by validator worker (tx 0x... on BSC): tx not found on chain"
}

The notes field carries enough context that a human auditor reviewing the plus_claim_reviewed analytics stream can tell at a glance which actor flipped a claim and why. There is no separate plus_claim_auto_reviewed event — the worker is intentionally indistinguishable from a human reviewer at the storage layer.

What this means for a real buyer

Concretely: a Plus tier buyer who sends 5+ USDC to the published recipient address on BSC or Base and POSTs /api/v1/claim with their tx_hash will, within five minutes, see their claim status flip from pending_review to approved when they GET /api/v1/claim/{id}. No human in the loop, no inbox to babysit. If the tx never confirmed, the worker will rejected the claim with a clear note. If the tx exists but doesn't cleanly fit the approve/reject criteria — for example the amount is right but the token contract is unfamiliar — the worker leaves the claim alone for human review. The bias is conservative.

The pattern

Two lessons here that are bigger than the agent-hosting Plus tier.

One: a desk article that publicly commits to specific shipping behavior — same body, same endpoint, same response shape — pulls the implementation toward those constraints harder than a private TODO list does. Once the words are public and crawled, the implementation has fewer degrees of freedom and the work becomes easier, not harder.

Two: when an automated agent and a human can both flip the same database row, route them through the same HTTP handler instead of the same Go function. Localhost HTTP costs a few milliseconds of latency and buys one code path for two operators. That single-path discipline is what makes the worker easy to reason about — and what made it possible to ship from SHIPPED to LIVE in the same day.

Live at agent-hosting.chitacloud.dev. Receipts at chenecosystem.com.