verex

Verex — What to Check / Analyze (review of work to date)

Generated 2026-06-17. A prioritized review list for the work completed through S2.4 (SDK + CLI migrated to the Polymarket CTF stack). This is what to verify and decide next, not a status report — see docs/features/README.md §1.4 for the roadmap and docs/history/README.md for the milestone log.

TL;DR — current state

1. Blockers — fix/verify before S2.5

2. Decisions needed (your input) — analyze trade-offs

3. Security / contract areas to analyze

4. Plan ↔ code gaps to reconcile

5. Watch-list (external triggers — no action until fired)

From docs/features/watch-list.md:

Quick verify commands

Root uses Turbo — pnpm build / pnpm test / pnpm lint run across every package at once. To exercise just one, cd into it:

Package Build / test command Notes
contracts (Solidity · Foundry) cd packages/contracts && forge test expect 34/34. forge test -vvv for traces, forge snapshot for gas, forge build to compile.
sdk (TypeScript · viem) cd packages/sdk && pnpm build && pnpm test vitest, expect 3/3 (EIP-712 parity, sign roundtrip, raw-pk signer).
cli cd packages/cli && pnpm build && pnpm demo — or root pnpm verex <cmd> no unit tests; smoke-test the 10 commands on anvil.
api (Web API · Fastify) cd packages/api && pnpm build then pnpm dev (tsx watch) ⚠️ build currently FAILS — broken VerexClient import (item #1 above). Fix first, then pnpm dev and curl the endpoints.
web (Next.js frontend) cd packages/web && pnpm build / pnpm dev / pnpm lint may have stale v1-SDK imports (see “Plan ↔ code gaps”).

Whole monorepo (Turbo)

pnpm build    # turbo run build — all packages
pnpm test     # turbo run test  — contracts (forge) + sdk (vitest)
pnpm lint     # turbo run lint

Local end-to-end (anvil)

Bring up a local chain, deploy the CTF stack, then drive it via CLI/SDK. The exact 7-step flow + flags are in docs/history/2026-05-26-s2-fillorder-e2e.md §4.2 and the S2.4 demo in docs/history/2026-05-27-s2.4-sdk-cli-migration.md:

anvil &                                  # local chain on :8545 (prints test private keys)
cd packages/contracts
forge script script/DeployCTF.s.sol --rpc-url http://localhost:8545 --broadcast --private-key <anvil-key>
# then DemoMarket.s.sol setup / resolve, and CLI: split | merge | redeem | order sign|fill

How to grant Claude permissions (stop repeat prompts)

When a Claude Code tool call keeps prompting for approval, add an allow rule to a settings file so it auto-approves next time. This is useful for the safe, read-only commands a reviewer runs over and over (git log, forge test, pnpm build).

Where the rules live (scope — later overrides earlier)

| File | Scope | Git | Use for | |——|——-|—–|———| | ~/.claude/settings.json | global, all projects | n/a | personal, broadly-useful rules | | .claude/settings.json | this project, committed | commit | team-wide rules | | .claude/settings.local.json | this project, gitignored | ignore | personal / experimental rules for verex only |

Verex already has a .claude/settings.local.json for repo-specific rules.

Rule syntax (permissions.allow array)

{
  "permissions": {
    "allow": [
      "Bash(forge test:*)",   // prefix match: "forge test" + anything after it
      "Bash(pnpm build)",      // exact match
      "Read"                    // whole tool: allow all reads
    ]
  }
}

Safety rule: allow read-only only

Safe to auto-allow: git log/status/diff/show/branch, forge test, forge snapshot, pnpm build/test. Do not broadly allow writes — git commit/push/reset --hard, rm, forge script --broadcast — keep those prompting so a human stays in the loop (matches the after-hours workflow in .claude/CLAUDE.md).

Gotcha: cd … && git still prompts

A compound command like cd packages/contracts && forge test does not match a Bash(forge test:*) rule (it starts with cd, not forge). Either run the tool from the directory so the command starts with the allowed prefix, or use a path flag (forge test --root packages/contracts, git -C <dir> log). Avoid a blanket rule like Bash(git -C:*) — it would also wave through git commit/reset.

Easiest way to edit

Both merge into the existing allow array safely — never hand-replace the whole array, and remember invalid JSON silently disables every setting in that file.