[pentarim]

Why

An agent could open a dispute or request a deal but never read one back:

• tribeunal_await_ruling blocks for at least 5 s and returns a ruling summary, not the dispute (no parties, value, rounds or case uuids).
• Nothing listed the disputes an account is a party to, so a respondent had no direct way to find one opened against it, and no agent could recover a disputeUuid in a new session.
• tribeunal_create_deal returned {slug, url, shareUrl, termsHash} and that was the last an agent saw of the deal: no way to learn whether the payer had deposited.

What

Three read-only tools, each a thin call over an endpoint the server already has. 50 tools, up from 47; 18 read-only.

Tool	Route	Returns
tribeunal_get_dispute	GET /api/disputes/{uuid}	The dispute document, at once: parties, value, every round, the standing ruling, final
tribeunal_list_disputes	GET /api/disputes	The caller's disputes as claimant or respondent, newest first, paginated
tribeunal_get_deal	GET /api/deals/{slug}	The deal request: hashed terms, wallets, amount, dates and the status the indexer last recorded

• tribeunal_get_deal takes an optional share (the ?share= value of a shareUrl), so the agent of a payer or payee who was sent the link can read the deal, not only its creator. Its description and honesty row say the status trails the network and that live.bridge.stale means the indexer has not kept up.
• Results carry only documented keys; a field the server adds later is not forwarded.
• Reads are never scope-gated and do not consult the disputes or deals switch, so they work where opening disputes or creating deals is switched off.

Also in this PR:

• tribeunal_open_dispute and the shared disputeUuid parameter description now name tribeunal_list_disputes (the pinned description tests are updated to match).
• tribeunal_mark_evidence's kind description no longer says case files are uploaded from the case web page: they are attached when a case is created on the website, and no tool uploads one.
• README gains the Disputes section its "Available tools" list never had (all seven dispute tools).
• Version 2.3.0 in every manifest, CHANGELOG entry, regenerated skills/using-tribeunal/references/tools.md, errors.md rows for deal_not_found and invalid_pagination.

Verification

• npm run test:unit: 466 pass, 0 fail (434 before; 29 new cases in tests/dispute-reads.test.ts and tests/get-deal.test.ts, each watched failing first).
• tsc --noEmit clean for the root project and worker/.
• mcp-tdqs lint: 0 errors; its 3 shadow-candidate warnings are all between tools that predate this PR.
• Live over stdio against a dev server: tools/list reports 2.3.0 and 50 tools; all three tools returned real data; unknown ids answered the coded 404 with its hint; a URL passed as slug was refused before any request.
• tribeunal_get_deal share path, live: no credential and no share → deal_not_found; with share → 200, viewer.isCreator: false, shareUrl: null; wrong share → deal_not_found.

Not exercised:

• tribeunal_list_disputes as a respondent (the dev server had no second credential); the server query matches claimant or respondent.
• The remote Worker: type-checked only, not run.
• npm run lint cannot run: the repo has no ESLint config. That predates this PR.

Release

Nothing is published. After merge: tag v2.3.0, npm publish, Worker deploy, registry publish.

🤖 Generated with Claude Code