docs: re-verify the client-library page at wharfkit antelope 1.2.0

AGENTS.md

@@ -64,6 +64,6 @@ Read the routed file in full rather than searching it. The facts there encode be
 
 Take each section at face value and do not extrapolate past what it states. A page says what was checked, and what it does not say was not checked. `reference/validation.md` records how every page was validated and against what. It grades `reference/` and `guides/` only: a tutorial's claim is that its steps run, and a concepts page restates facts the pages it links already carry, so neither takes a row there.
 
-Re-check any fact that names a version when that dependency moves. The two SDK pages are pinned to `@atomichub/atomicassets` 2.1.1, read at tag `v2.1.1`, and `@atomichub/atomicmarket` 2.4.1, read at tag `v2.4.1`; the client-library page is pinned to `@wharfkit/antelope` 1.1.1, and the AtomicAssets and AtomicMarket contract pages to `v2.0.0` and `v2.0.0`. A fact read at one of those pins is a fact about that release, not about the package name.
+Re-check any fact that names a version when that dependency moves. The two SDK pages are pinned to `@atomichub/atomicassets` 2.1.1, read at tag `v2.1.1`, and `@atomichub/atomicmarket` 2.4.1, read at tag `v2.4.1`; the client-library page is pinned to `@wharfkit/antelope` 1.2.0, and the AtomicAssets and AtomicMarket contract pages to `v2.0.0` and `v2.0.0`. A fact read at one of those pins is a fact about that release, not about the package name.
 
 Two skills sit beside these pages. `skills/atomic-integration/SKILL.md` carries the procedures a routing table cannot: the mint flow, the market composers, and the network choice. `skills/report/SKILL.md` writes a difficulty report when a page here turned out wrong, missing, or misleading, in the field shape this repository's issue forms accept.

CHANGELOG.md

@@ -2,6 +2,12 @@
 
 What each release of this corpus changed, one release per tag. `Corrected` comes first in every release, because a fact that was wrong is what a returning reader has to see before anything else. The other sections are `Added`, `Revalidated`, and `Removed`, in that order, and a section with nothing in it is left out.
 
+## 2026.08.2
+
+### Revalidated
+
+- `reference/wharfkit.md` reads at `@wharfkit/antelope` 1.2.0: the only source change since 1.1.1 is `send_transaction2` exception handling, and every fact on the page holds unchanged.
+
 ## 2026.08.1
 
 ### Corrected

reference/validation.md

@@ -16,7 +16,7 @@ This log traces how every fact in `reference/` and `guides/` was checked before
 - `atomictools-contract` at commit `d89ce79e4` (the upstream repository has no release tag; the deployed `atomictoolsx` ABI on WAX matches this commit exactly)
 - `atomicassets-sdk` at tag `v2.1.1`, commit `5c70c62` (published as `@atomichub/atomicassets` 2.1.1)
 - `atomicmarket-sdk` at tag `v2.4.1`, commit `437300b` (published as `@atomichub/atomicmarket` 2.4.1)
-- `@wharfkit/antelope` at `1.1.1`
+- `@wharfkit/antelope` at `1.2.0`
 - `@wharfkit/session` at `1.6.1`, with `@wharfkit/common` at `1.5.0` and `@wharfkit/wallet-plugin-privatekey` at `1.1.0`
 - `@atomichub/vert` at `2.2.0`, commit `a8a4160`
 - `AntelopeIO/leap` at `v5.0.3` (chain RAM billing: the billable-size constants and the call sites that charge them)
@@ -56,7 +56,7 @@ WAX mainnet still runs the V1 `atomicassets` and `atomicmarket` contracts (confi
 | `reference/atomicmarket/v2-changes.md` | `atomicmarket-contract` (v2.0.0): `src/atomicmarket.cpp` | source-read | The defensive-guards section has an explicit `Source:` line. The "large integers serialize as strings" section describes live nodeos JSON-serialization behavior and carries no dedicated citation in this page; it is consistent with, and narrower than, the live-chain uint64 facts in `guides/querying-the-api.md`. |
 | `reference/chain.md` | Live `nodeos`/WAX RPC behavior (`/v1/chain/get_account`); nodeos `chain_plugin.cpp` referenced for the error-message format | live-chain | No dedicated `Source:` line in this page. The error code and HTTP behavior are a live-RPC fact; the page also names the nodeos source file that emits the message text, which is not independently re-verified here. |
 | `reference/contract-releases.md` | `atomicassets-contract` / `atomicmarket-contract`: `Makefile`, `scripts/patch-abi.py`, CI release workflow | source-read | No dedicated `Source:` line and no version pin in this page's frontmatter (build tooling applies across releases, not to one tag). Resource-usage figures (NET/CPU for `setcode`) read as measured observations rather than a cited source or a live probe; treat those magnitudes as approximate. |
-| `reference/wharfkit.md` | `@wharfkit/antelope` client library source, pinned to `1.1.1` | source-read | No dedicated `Source:` line; each fact names the library behavior and, for one, an `@attention` note in the library's own source. Re-check on any `@wharfkit/antelope` upgrade, as the page itself states. |
+| `reference/wharfkit.md` | `@wharfkit/antelope` client library source, pinned to `1.2.0` | source-read | No dedicated `Source:` line; each fact names the library behavior and, for one, an `@attention` note in the library's own source. Re-verified across the 1.1.1 to 1.2.0 diff: the only source change is send_transaction2 exception handling, which touches none of this page's facts. Re-check on any `@wharfkit/antelope` upgrade, as the page itself states. |
 | `guides/asset-lifecycle.md` | `atomicassets-contract` (v2.0.0): `src/atomicassets.cpp`, `include/atomicassets.hpp`; `atomicassets-sdk` (`v2.1.1`, `5c70c62`): `src/Actions/Generator.ts` | source-read | Creator-flow walkthrough; every step cites the underlying action's source range. The SDK mint example and the numeric-guard note are source-read from the 2.1.1 builder, not executed: the guarded fields, the `-1` sentinel, and the single-object return shape are read from `Generator.ts` by line. |
 | `guides/auctions.md` | `atomicmarket-contract` (v2.0.0): `src/atomicmarket.cpp`; `atomicmarket-sdk` (`v2.4.1`, `437300b`): `src/Actions/Generator.ts`; live `get_table_rows` curl example against `wax.greymass.com` | both | Lifecycle steps cite contract source; one section shows a live `get_table_rows` curl call to illustrate reading auction state. The composer section is source-read from the 2.4.1 builder: the announce-then-transfer order, the `auction` memo literal, and the `duration` uint32 check are read by line. |
 | `guides/buyoffers.md` | `atomicmarket-contract` (v2.0.0): `src/atomicmarket.cpp`; `atomicmarket-sdk` (`v2.4.1`, `437300b`): `src/Actions/Generator.ts` | source-read | Every action (create, accept, decline, cancel, template variants) cites its source range. The two composer sections are source-read from the 2.4.1 builder: that `acceptbuyo` and `fulfilltbuyo` have no standalone builder method, the emitted order and memo literals, and the `allow_v1_bundle_buyoffer` throw are read by line. |

reference/wharfkit.md

@@ -1,13 +1,13 @@
 ---
-scope: "@wharfkit/antelope client library behavior for table reads, authority checks, and payer unwrapping, each verified against version 1.1.1 of the package"
+scope: "@wharfkit/antelope client library behavior for table reads, authority checks, and payer unwrapping, each verified against version 1.2.0 of the package"
 depends-on: []
 key-modules:
     - "@wharfkit/antelope"
 ---
 
 # @wharfkit/antelope client behavior
 
-Version-pinned facts below were verified against 1.1.1; re-check them on upgrade.
+Version-pinned facts below were verified against 1.2.0; re-check them on upgrade.
 
 ## Typed get_table_rows is not a drop-in for dynamic reads
 
@@ -32,8 +32,8 @@ Typed endpoints such as `get_account` also strict-decode responses into structs,
 
 ## hasPermission does not recurse into account weights
 
-`Authority.hasPermission` in @wharfkit/antelope (verified in 1.1.1) checks a public key only against the authority's direct `keys[]` entries; its own source carries an `@attention` note that indirect permissions via `accounts[]` weights are not considered. This matters on WAX: Cloud Wallet `.wam` accounts commonly delegate their active permission to a managing account (e.g. `managed.wax`), so verifying a recovered key with `hasPermission` alone rejects every such account. Off-chain verifiers need a recursive authority walk: fetch the account, accumulate weight from direct key matches, then recurse into each `accounts[]` entry and add its weight when the child authorizes the key, short-circuiting once the threshold is met. Bound the walk with a small depth cap (real delegations rarely exceed depth 2) and cycle detection keyed on (account, permission), removing the visited entry when a branch unwinds, or sibling branches that legitimately converge on the same downstream account are wrongly counted as zero weight. Also walk a permission's parent (e.g. `owner` for `active`) on the same account, since the chain accepts a parent-permission key wherever the child would suffice. Re-verify the no-recursion behavior on any library upgrade.
+`Authority.hasPermission` in @wharfkit/antelope (verified in 1.2.0) checks a public key only against the authority's direct `keys[]` entries; its own source carries an `@attention` note that indirect permissions via `accounts[]` weights are not considered. This matters on WAX: Cloud Wallet `.wam` accounts commonly delegate their active permission to a managing account (e.g. `managed.wax`), so verifying a recovered key with `hasPermission` alone rejects every such account. Off-chain verifiers need a recursive authority walk: fetch the account, accumulate weight from direct key matches, then recurse into each `accounts[]` entry and add its weight when the child authorizes the key, short-circuiting once the threshold is met. Bound the walk with a small depth cap (real delegations rarely exceed depth 2) and cycle detection keyed on (account, permission), removing the visited entry when a branch unwinds, or sibling branches that legitimately converge on the same downstream account are wrongly counted as zero weight. Also walk a permission's parent (e.g. `owner` for `active`) on the same account, since the chain accepts a parent-permission key wherever the child would suffice. Re-verify the no-recursion behavior on any library upgrade.
 
 ## show_payer rows are unwrapped into ram_payers
 
-With `show_payer: true`, the raw `/v1/chain/get_table_rows` endpoint wraps each row as `{ data: <row>, payer: <account> }`. The typed `@wharfkit/antelope` client (`client.v1.chain.get_table_rows`, verified on 1.1.1) unwraps that envelope: it returns the rows flat and moves the payers into a separate `ram_payers` array on the response, index-aligned with `rows`. Code ported from eosjs that expects `row.data` / `row.payer` on each element therefore gets `undefined` on every row (a failure mode that unit tests can miss entirely if they mock the raw nodeos shape the typed client never returns). Either read the payer from `response.ram_payers[i]`, or call `/v1/chain/get_table_rows` directly with `json: true, show_payer: true` to keep the `{data, payer}` row shape; in both cases, stub the actual transport in tests rather than mocking an assumed row shape.
+With `show_payer: true`, the raw `/v1/chain/get_table_rows` endpoint wraps each row as `{ data: <row>, payer: <account> }`. The typed `@wharfkit/antelope` client (`client.v1.chain.get_table_rows`, verified on 1.2.0) unwraps that envelope: it returns the rows flat and moves the payers into a separate `ram_payers` array on the response, index-aligned with `rows`. Code ported from eosjs that expects `row.data` / `row.payer` on each element therefore gets `undefined` on every row (a failure mode that unit tests can miss entirely if they mock the raw nodeos shape the typed client never returns). Either read the payer from `response.ram_payers[i]`, or call `/v1/chain/get_table_rows` directly with `json: true, show_payer: true` to keep the `{data, payer}` row shape; in both cases, stub the actual transport in tests rather than mocking an assumed row shape.