docs(platform-wallet): error-code registry for the FFI result space by bfoss765 · Pull Request #4318 · dashpay/platform

bfoss765 · 2026-08-06T01:52:58Z

Continues #4261 — moved from a fork branch to an in-repo branch (rebased onto v4.2-dev post-#4305) so maintainers can push changes directly, per review request. Full review history on #4261.

Problem

PlatformWalletFFIResultCode (packages/rs-platform-wallet-ffi/src/error.rs) is public ABI — cbindgen emits the integers into the generated C header, Swift mirrors them in PlatformWalletResultCode, and Kotlin branches on them in fromPlatformWalletNative. Four open PRs are currently allocating adjacent integers in that enum with no shared source of truth.

A duplicate discriminant in two branches produces no textual merge conflict. The second merge just silently misclassifies errors on every host. That is not hypothetical here: 29 is already claimed by two PRs, and review on #4185 had to issue a renumber directive (ErrorReservationWalletMismatch 29 → 30) to resolve it. Three separate PRs now carry hand-written comments trying to reserve ranges on each other's behalf, and one of those reservations is for a variant that no longer exists.

This PR adds a registry so the allocation is decided in one file instead of in four diffs.

What's here

packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:

the merged allocation table (0–26, plus the 98/99 sentinels),
the proposed allocations with their owning PRs (27–33),
the rule for claiming a new code — next free integer, recorded here in the same PR that adds it, mirrors updated alongside,
the ABI-stability rule — never renumber after release; deprecate and allocate a new integer,
the contested/pending allocations, written up below as well.

Plus a six-line pointer from the crate README's Error Handling section.

Docs-only. Zero code risk. No enum, no From mapping, no Swift/Kotlin mirror is touched, and nothing is renumbered — that stays the owning PRs' work. This PR only writes down what the branches already say.

Codes claimed by the in-flight PRs

Reconciling in one place, so this is the table to correct:

Code	Name	Owning PR
27	`ErrorStaleReservationToken`	#4185 (also carried by #4256)
28	`ErrorReservationTokenConsumed`	#4185 (also carried by #4256)
29	`ErrorReservationWalletMismatch`	#4185 — collides, see below
29	`ErrorAssetLockInsufficientFunds`	#4184 — collides, see below
30	unallocated	reserved in sibling comments only, see below
31	`ErrorSigningKeyUnavailable`	#4183 (also carried by #4204)
32	`ErrorTransactionBuild`	#4247 (also carried by #4256)
33	`ErrorTransactionSigning`	#4256

Open PRs touching this crate that claim no new code: #4186, #4191, #4194, #4195, #4240, #4251, #4258. Next free integer: 34.

rs-sdk-ffi's DashSDKErrorCode is a separate integer space and is not modified by any of these PRs.

⚠️ Previously unflagged collision: code 26 on #4196

Surveying the branches turned up a second collision that does not appear to have been raised in review.

#4196 branched before 26 = ErrorTransactionBroadcastRejected merged to v4.2-dev (in 9302c62e8b), and its head numbers the reservation trio 26 / 27 / 28:

ErrorStaleReservationToken    = 26   // collides with merged ErrorTransactionBroadcastRejected
ErrorReservationTokenConsumed = 27
ErrorReservationWalletMismatch = 28

So as it stands, #4196 would give 26 two meanings on merge, and it also contradicts #4185 — the PR it is stacked on — which numbers those same three names 27 / 28 / 29. The fix is a rebase onto current v4.2-dev plus adopting whatever numbering #4185 lands with; no new integers are needed. Flagging rather than fixing, per the docs-only scope.

Code 30 is free, despite what three branches say

ErrorAssetLockCrossDomainConsentRequired is named as the holder of 30 in in-tree comments on #4183, #4204, and in #4247/#4256's numbering rationale. It is not defined anywhere — #4184, the PR that would have introduced it, dropped it in a re-scope. 30 is therefore genuinely free, and is the slot the #4185 renumber should take. Those stale comments should be dropped by whichever PR touches them next.

Ambiguity left open for maintainers

Review on #4256 suggested mapping its signing failure onto 31; #4256 declined and took 33, arguing that 31 (ErrorSigningKeyUnavailable, #4183) asserts a narrower contract — the signer holds no usable private key for a requested public key — while BuilderError::SigningFailed also covers unresolved derivation paths, sighash failures, and malformed signature encodings. Both are currently allocated. Collapsing them is a reasonable call, but it belongs to #4183 and #4256 jointly; the registry records the split as-is rather than pre-judging it.

Please correct the table

The merged rows were read straight from v4.2-dev at ed4116b26c. The proposed rows were read from each PR's head commit (SHAs listed in the doc's provenance section) and will go stale as those PRs are updated. If a maintainer has a different intent for any allocation — particularly 30, and the 31/33 split — please say so on this PR and I'll amend, or edit the file directly. The point is that there is now one place where that correction lands.

🤖 Generated with Claude Code

Summary by CodeRabbit

Documentation
- Expanded the platform wallet FFI result-code registry with allocation rules, reserved and merged values, collision resolutions, renumbering history, and historical context.
- Documented the next available allocation point and guidance for proposing new codes while preserving ABI compatibility.
- Clarified that result codes are part of the public ABI and must remain synchronized across generated C, Swift, and Kotlin interfaces.
- Added guidance to consult the registry before introducing new result codes.

Four open PRs allocate discriminants into PlatformWalletFFIResultCode in parallel, with no shared source of truth. A duplicate discriminant does not produce a textual merge conflict, so the second merge silently misclassifies errors on every host — one such collision (code 29) has already required a renumber directive in review. Adds packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md: the merged allocation table (0-26, 98, 99), the proposed allocations with owning PRs (27-33), the rule for claiming the next free integer, the ABI-stability rule (never renumber after release, deprecate instead), and the currently contested allocations. Links it from the crate README's error-handling section. Docs only — no enum, mapping, or mirror is changed. Renumbering remains the owning PRs' work. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…ollisions The 29 collision is resolved and the renumber has now landed on #4185's branch: #4184 keeps 29 (ErrorAssetLockInsufficientFunds), #4185 takes 30 (ErrorReservationWalletMismatch). Table rows updated to match the code. Fixes the "30 is both free and assigned" inconsistency: the next-free line claimed 27-33 were claimed while the table showed 30 unallocated. 30 is now genuinely allocated to #4185, so the two agree. Adds allocations the survey had omitted, verified 2026-08-01 by reading error.rs at the head of all 62 open PRs: - #3968 numbers 26/27/28 (Persister* + a pre-merge TransactionBroadcastRejected) -> contradicts merged ABI at 26 and collides with #4185 at 27 and 28 - #3954 numbers ErrorShutdownIncomplete = 27 -> collides with #4185 at 27 - #4259 carries ErrorSigningKeyUnavailable = 31, inherited from #4183 rather than a new allocation The same sweep confirms no open PR anywhere defines a code 30.

…cord #4196 scope Clears the two review blockers on #4261 and re-syncs the registry with what the code on each branch actually does, re-read at every head rather than trusted from this file. Blocker (a) — #3968 / #3954 / #4259 were described in prose but had no rows, which is exactly what rule 2 forbids. They now have them: - A "Non-conforming allocations" table for #3968 (26/27/28) and #3954 (27). These are deliberately kept out of the proposed table: each row is a claim to be withdrawn and reissued, not an allocation of record. - An inherited-code table for the 31 that #4204 and #4259 carry but did not allocate (#4183 owns it), so it is not double-counted. - #4196 is recorded as claiming no integer at all: it routes a new token-less `StaleReservation` variant through the existing `ErrorStaleReservationToken`. The #3968 half is the serious one and is called out as such. Its 28 is not a new claim — it *moves the already-shipped* `ErrorTransactionBroadcastRejected` off 26 to make room for its own persister code. Rule 3 forbids that: a host compiled against merged ABI returns 26 for a broadcast rejection, and after #3968 the same condition returns 28 while 26 means a transient persister failure. Neither branch's diff shows the contradiction. Blocker (b) — 30 marked both free and assigned was already resolved by the preceding commit; verified consistent here (30 is allocated to #4185 throughout, frontier is 34, and the one remaining "genuinely free" is past tense explaining why #4185 could take it). Also corrected, all verified against the branches: - Survey provenance had #4185 at `0b0d5c76d6` labelled "(post-renumber)". Wrong twice: that commit is the *parent* of the renumber `d854debb`, and the head has since moved to `6c37e8679e`. #4184, #4247 and #4256 SHAs refreshed too. - #4256 has now taken 30 (`9481e5783b`) and dropped its stale "30 is reserved for the consent code" rationale; the equivalent comments on #4183 and #4204 are flagged as still present. - #4184 has a comment-only drift: it reserves "Codes 27-28" but names three codes. Correct when the trio was 27/28/29; it is now 27/28/30. Its discriminant is right and is the resolution of record — only the prose is stale, and #4184 is left untouched. - The #4196 section now records why the restack has not happened: its three own commits conflict in 3 files / 10 hunks against #4185's head, and the registry redesign underneath it (mandatory `registered_height`, new `WalletRemoved` variant, owner-stamped funding token) makes it author work rather than conflict resolution. Its trio numbers come from the #4185 copy it carries, so the restack fixes 28 -> 30 for free; the number #4196 itself must chase is 27, not 30. Verified: cargo fmt --all -- --check clean; cargo test -p platform-wallet-ffi -p platform-wallet = 738 passed / 0 failed. Docs-only change.

#4268 merged `ErrorShutdownIncomplete = 27` into the v4.2-dev ABI on 2026-08-02, taking the number #4185 had held. #4185 and #4256 moved the deferred-token trio to the contiguous block 34-36 in response. Registry changes: * 27 enters the merged table, owned by #4268. * The proposed table moves the trio to 34/35/36 and marks 28 and 30 free but deliberately not reissued. Next free integer is now 37. * New "Collision history" section records all three numberings of the trio (26/27/28 -> 27/28/30 -> 34/35/36) and, more usefully, corrects this file's own reasoning: on 2026-08-01 it recorded #3954's `ErrorShutdownIncomplete = 27` as a non-conforming claim that had to be withdrawn because #4185's claim was older. Seniority among open PRs does not decide an ABI number — merging does. #3954 was closed, its work landed as #4268, and 27 is now merged ABI. The trio therefore moved above every claimed number rather than into the next free gap, so nothing currently in flight can hit it again. * #3968's 27 is re-characterised: it was a proposed-vs-proposed collision, and is now a contradiction of merged ABI. Its frontier is 37+. * #4196 is now two moves behind at 26/27/28; the doc reference it owns has to chase 34, not 27. * Records a mirror gap found while grepping for this move: #4256 declares `ErrorTransactionBuild` (32) and `ErrorTransactionSigning` (33) in Rust and maps both in Kotlin, but declares neither in Swift, so both reach Swift hosts as `.errorUnknown`. Rule 5's Swift clause; left for that PR's author. * Provenance re-verified against v4.2-dev `5d68612a45`, including the check that 32 and 33 were already taken — which is why the trio went to 34-36 and not 32-34. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

… allocation frontier

…e 32 collision #4204 allocated 32 without a row here, colliding with #4247's ErrorTransactionBuild. Caught for real during the v41int13 integration as an E0081, not on paper — the first collision this file has actually stopped. #4204 moves to 37; frontier advances to 38. Also records that the code was unmirrored on both hosts, which had Kotlin misclassifying it as ReservationWalletMismatch wherever #4185's 32 was present. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Resolves the two blocking review findings and the live suggestions on #4261. Blocking — advance #3968's reissue frontier to 38. Code 37 is allocated to #4204, so the branch-specific guidance in the non-conforming section and in the 27/28 detail section could still have sent #3968 to 37 and recreated the collision with ErrorShieldedInviteAlreadyClaimed. Both references now say 38+, and both state that the reserved 28 and 30 are not available either. Blocking — 28 and 30 were labelled RESERVED in the table and the frontier paragraph but "free" in the code-30 section and the collision history. Rule 1 lets a contributor claim a gap this file marks free, so the two labels gave two different allocation frontiers. Everything now says reserved-not-free and cites rule 1 explicitly. Open-PR inventory: verified 2026-08-03 against each PR's file list and the error.rs at its head. Adds #3417, #3549, #3992 and #4243 (all touch the crate without claiming an integer; #4243 maps new wallet errors onto the existing ErrorInvalidParameter). Removes #4240 and #4251, whose heads touch no file under this crate; removes #4258, merged on 2026-08-03; records #4264 as closed with its work carried by #4243. Also in this pass: - #4204's Swift mirror is recorded as PARTIALLY fixed. At d78b940 the raw case and its init(ffi:) arm exist, but PlatformWalletError has no typed case and its exhaustive init(result:) has no arm, so the Swift package does not compile as written. Rule 5's Swift clause is not yet satisfied there. - The preamble no longer claims duplicate discriminants are always silent. Two different names on one integer is an E0081 after a merge (that is how the code-32 collision surfaced); the silent case is a meaning moving to a new integer, or an un-updated host mirror. - Code 13 ErrorArithmeticOverflow does have an in-tree producer (shielded_send.rs); the row said it had none. - #3968 is no longer described as simply un-rebased: its head does contain the 2026-08-01 base, it is behind the current base, and a rebase alone fixes nothing because git sees no conflict — the branch must edit its own enum. - Provenance re-read on 2026-08-03 from GitHub rather than carried forward, now as a table with a note per PR. #4183 and #4184 were rebased onto 5d68612 today and keep 31 and 29 respectively; their stale in-enum reservation comments were corrected in the same rebase, so the code-30 section now lists #4204 as the only branch still carrying one. - markdownlint: MD018 (18 occurrences) and MD004 (mixed bullet styles) are both clean; MD013 is down to long table rows only.

Three more live review findings, all verified against current PR heads. Rule 5 named a `PlatformWalletResultCode.init(result:)` that does not exist — `init(result:)` belongs to the downstream `PlatformWalletError`. As written, a contributor could add the Swift raw case and the typed error handling and still omit `PlatformWalletResultCode.init(ffi:)`, which is where the generated C constant is recognised; that switch has a `default:` yielding `.errorUnknown`, so the omission compiles and silently loses the code's identity before typed handling sees it. Rule 5 now enumerates all three Swift sites and says how each one fails: (1) the raw case, (2) the `init(ffi:)` arm — silent, and (3) `PlatformWalletError` + its `init(result:)` arm — a hard compile error, since that switch is exhaustive with no `default:`. That third failure is exactly what #4204 is sitting on at `d78b940a03`. #4196 is no longer blocked. Its head moved to `12492e8c54`, the restack onto #4185 is done, #4185's head `8813e98533` is an ancestor, the trio reads 34/35/36, and the PR is MERGEABLE against v4.2-dev. Verified the numeric references it owns were carried too: the `StaleReservationToken` KDoc and `fromPlatformWalletNative` mapping in `DashSdkError.kt` both read 34, and the V2 broadcast KDoc in `ManagedCoreWallet.kt` reads 34 with the rest symbolic. `PlatformWalletError::StaleReservation` refers to the code symbolically and never carried a number. The section is now a resolution rather than an open item; the account of why the restack was hard is kept, since that was the substance of the delay. The code-30 sweep was overstated. "No PR anywhere defines a code 30" is false for the surveyed heads — #4185 and #4256 both did; that was the allocation, not a competing claim. It now reads "no PR unrelated to #4185 defines a code 30", which is the claim that actually supports the conclusion. The list of branches carrying the stale consent-code reservation is corrected to #4183, #4204 and #4256's pre-renumber rationale (#4247 was never one of them). Provenance and the proposed table pick up #4196's new head. markdownlint MD018/MD004 remain at 0.

Re-verified the whole document against the CURRENT `origin/v4.2-dev` (`97904ed2fc`), not the `f53e5eef0a` the review comment cited and not the `5d68612a45` this file was last compiled against. `ErrorSigningKeyUnavailable = 31` is merged ABI. It landed in `189a3abb1c` (#4183, stacked on #4191) together with its Rust C-facing discriminant and complete Swift and Kotlin mirrors — the raw case, the `init(ffi:)` arm, the typed `PlatformWalletError` case with its `init(result:)` arm, and Kotlin's `31 -> PlatformWallet.SigningKeyUnavailable`. Leaving it under "Proposed allocations", whose preamble explicitly permits renumbering, contradicted rule 3. Moved to the merged table. Four PRs merged into `v4.2-dev` on 2026-08-04 and this file still treated all four as open: #4191 (`0e2282b586`), #4183 (`189a3abb1c`), #4277 (`6704a41a85`), #4251 (`7afc8a8ff3`). Only #4183 claimed an integer; the other three claimed none, and #4277 is now recorded as the merged precedent for "touches error.rs but allocates nothing" (it routes TxMetadataPayloadTooLarge onto the existing ErrorInvalidParameter). Dependent sections updated so nothing implies 31 may still move: the frontier breakdown (unchanged at 38), the proposed table, the inherited-code table (31 is trunk now, not an inheritable claim), the collision-history bullet list, the no-new-code open-PR inventory, the 31-vs-33 note (collapsing 31 is no longer available; only #4256's 33 is still open), and the survey provenance plus the PR-heads-of-record table. Also refreshed, because a re-dated provenance section must not carry claims that are now false: #4204's and #4256's Swift mirror gaps are both closed, and the stale ErrorAssetLockCrossDomainConsentRequired comments are gone from every branch that carried them. Every discriminant, mirror, PR state, and SHA above was read from git or the GitHub API on 2026-08-04. The four merge SHAs were confirmed ancestors of `97904ed2fc`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…st outcomes Two corrections from the #4261 review round: - The code-32 collision peer was misidentified. #4204 defined ErrorShieldedInviteAlreadyClaimed = 32 (b6992a5) and #4247 defines ErrorTransactionBuild = 32 (error.rs:257) — that is the E0081 pair. ErrorReservationWalletMismatch never held 32; its history runs 26/28 -> 30 -> 36. - "silently wrong on every host" overstated it. The three host outcomes differ and only one is a misclassification; spell them out. Also describe the inherited-code table as reduced to one row and retained for provenance rather than gone, since the row is rendered right below. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Three leading `#<number>` line starts survived the earlier sweep (lines 173, 177, 334) and markdownlint still read them as malformed ATX headings. markdownlint-cli2 now reports zero MD018 on this file. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

coderabbitai · 2026-08-06T01:53:08Z

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

@coderabbitai resume to resume automatic reviews.
@coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

▶️ Resume reviews
🔍 Trigger review

📝 Walkthrough

Walkthrough

The change adds a central PlatformWalletFFIResultCode ABI registry. It documents allocation rules, code history, collision resolutions, mirror requirements, verification results, and the workflow for adding future result codes.

Changes

FFI error-code registry

Layer / File(s)	Summary
ABI registry and allocation workflow `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`, `packages/rs-platform-wallet-ffi/README.md`	The registry defines ABI scope, allocation rules, reserved values, retirement policy, and code 43 as the next allocation frontier. The README documents ABI stability and synchronization with C, Swift, and Kotlin interfaces.
Allocation history and collision resolution `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`	The registry records merged, proposed, conflicting, migrated, lapsed, inherited, and no-code allocations. It documents code reassignment, collision resolutions, and Swift and Kotlin mirror mappings.
Registry verification and code-space boundaries `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`	The registry distinguishes the platform-wallet FFI code space from `rs-sdk-ffi` and records dated surveys, mirror-gap status, historical PR heads, and direct verification results.

Estimated code review effort: 2 (Simple) | ~15 minutes

Possibly related PRs

dashpay/platform#4185: Documents related PlatformWalletFFIResultCode allocations, including codes 34–36.
dashpay/platform#4204: Relates to the shielded-invite allocation and renumbering from code 37 to the allocation frontier.
dashpay/platform#4261: Updates the same registry and README for Platform Wallet FFI allocations.

Suggested reviewers: lklimek, quantumexplorer, zocolini

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the documentation change that adds an error-code registry for the platform-wallet FFI result space.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch docs/ffi-error-code-registry

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

thepastaclaw · 2026-08-06T01:54:11Z

ℹ️ Review superseded (commit 24e10a7)
Last checked: 2026-08-27 01:53 UTC

thepastaclaw

Preliminary review — Codex only

The documented numeric allocations still match the active replacement branches, including their Rust, Swift, and Kotlin mirrors. However, the registry identifies closed PRs as the current allocation owners and records an obsolete base revision, which defeats this PR's stated purpose of providing an authoritative coordination point; refresh the ownership, inventory, and provenance before merging.
Source: reviewer backends gpt-5.6-sol (codex general) and gpt-5.6-sol (codex ffi-engineer); final verifier backend gpt-5.6-sol (codex). openclaw-agent/cliproxy/gpt-5.6-sol is orchestration-only and not reviewer evidence.

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — ffi-engineer (completed)
Verifier: gpt-5.6-sol — verifier
Opus: not run (deferred by blocker gate)

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:115-130: Replace closed allocation owners with the active successor PRs
  This section is explicitly the allocation table for open PRs, but every named owner is now closed. The active in-repository successors are #4316 for code 29; #4310 for code 32, also carried by #4311; #4311 for code 33; #4308 for codes 34–36, also carried by #4309, #4310, and #4311; and #4313 for code 37. Their current heads retain the documented Rust discriminants and corresponding Swift/Kotlin mappings, so the numbers remain correct but ownership does not. The same stale references continue through the open-PR inventory, contested-allocation history, and provenance, which calls `97904ed2fc` the current base even though this PR's merge base is post-#4305 `b703f82ab5`. Because the README directs contributors here as the authoritative place to coordinate claims and mirror changes, linking claims to closed PRs sends updates and reconciliation work to the wrong branches. Refresh the proposed table and all dependent ownership/provenance references against the active successor heads.

The proposed-allocations table named the fork-era owners (#4184, #4185, #4204, #4247, #4256), all closed when the estate was recreated in-repository. Ownership now names the active successors (29 -> #4316, 32 -> #4310, 33 -> #4311, 34-36 -> #4308, 37 -> #4313, carriers updated), the no-code inventory is marked as the fork-era snapshot it is, and the provenance base is date-stamped instead of claiming to be current. Collision history keeps the fork-era numbers — it is record. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- Line 301: Refresh the allocation-status documentation around the “Still
outstanding” entry and the August 4 open-PR inventory: replace stale `#4196`
references and head-table entries with the current successor PRs, or explicitly
mark those rows as historical and remove claims that they represent open PRs.
Keep the status consistent with the restack closure and fork-era replacement
notes.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fae0d6d3-100f-4cf9-af8e-4cd2f069f39b

📥 Commits

Reviewing files that changed from the base of the PR and between b703f82 and 68f7a3f.

📒 Files selected for processing (2)

packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md
packages/rs-platform-wallet-ffi/README.md

codecov · 2026-08-11T12:49:27Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.77%. Comparing base (bea4122) to head (cde58c4).
⚠️ Report is 18 commits behind head on v4.2-dev.

Additional details and impacted files

@@             Coverage Diff              @@
##           v4.2-dev    #4318      +/-   ##
============================================
- Coverage     87.39%   80.77%   -6.63%     
============================================
  Files          2735     2790      +55     
  Lines        347804   381484   +33680     
============================================
+ Hits         303979   308149    +4170     
- Misses        43825    73335   +29510

Components	Coverage Δ
dpp	`82.65% <ø> (-6.32%)`	⬇️
drive	`81.74% <ø> (-4.60%)`	⬇️
drive-abci	`83.56% <ø> (-6.17%)`	⬇️
sdk	`∅ <ø> (∅)`
dapi-client	`∅ <ø> (∅)`
platform-version	`∅ <ø> (∅)`
platform-value	`92.92% <ø> (ø)`
platform-wallet	`∅ <ø> (∅)`
drive-proof-verifier	`40.03% <ø> (-7.38%)`	⬇️

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

thepastaclaw

Preliminary review — Codex only

The registry remains materially behind the target branch: several proposed owners are already merged or closed, and codes 37–41 are now shipped ABI while the document still allocates 37 elsewhere and advertises 38 as free. Both issues undermine this PR's stated purpose as the authoritative allocation source and must be synchronized before merge.
Source: reviewer backend gpt-5.6-sol (Codex general); final verifier backend gpt-5.6-sol (Codex verifier).
Orchestration-only: openclaw-agent/cliproxy/gpt-5.6-sol; not reviewer evidence.

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed)
Verifier: gpt-5.6-sol — verifier
Sonnet: not run (deferred by blocker gate)

🔴 2 blocking

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:106-113: Account for the merged allocations at codes 37 through 41
  The current `v4.2-dev` ABI assigns 37–40 to `ErrorDocumentNotForSale`, `ErrorDocumentPriceChanged`, `ErrorInsufficientIdentityCredits`, and `ErrorContestedNameNotTradable` from merged #4348 (`6373e00f0c`), and assigns 41 to `ErrorShieldedInsufficientBalance` from merged #4360 (`e0b8baa850`). The registry instead says 38 is the next free value and still assigns 37 to #4313's `ErrorShieldedInviteAlreadyClaimed`; #4313 remains open, is currently unmergeable, and its head still defines that variant as 37. Rebasing it onto the target would therefore produce a duplicate-discriminant collision with the shipped code 37. Add the merged 37–41 rows, advance the allocation frontier to 42, and record that #4313 must take a fresh value.
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:120-140: Replace closed allocation owners with the active successor PRs
  (existing thread: https://github.com/dashpay/platform/pull/4318#discussion_r3726182822)
  The ownership update still does not describe the current state. #4308 merged codes 34–36 into `v4.2-dev` as commit `438153da39`, so those codes belong in the merged table rather than under open proposals. #4310 and #4311 closed without merging on 2026-08-10, while #4316 closed on 2026-08-07 and its active code-29 continuation is #4361. The stale state continues later in the file: line 301 calls #4196 “Still outstanding” even though lines 383–396 describe its resolution as closed, and lines 565–590 present an August 4 head inventory as rows describing open PRs. Because this registry is the coordination source for new allocations, these entries direct contributors to inactive branches and misclassify shipped ABI as provisional. Move 34–36 into the merged table, point code 29 to #4361, remove or reserve abandoned 32/33 claims as appropriate, and rewrite the old inventory as explicitly historical or replace it with current heads.

The proposed-allocation era this file tracked has largely settled: #4308 merged the reservation trio (34-36, 438153d), #4348 took 37-40 (6373e00) and #4360 took 41 (e0b8baa) - all now in the merged table. Codes 29/32/33 lapse to RESERVED (their in-repo owners closed without merging), the shielded-invite claim loses 37 to merged ABI and takes the frontier on revival, the frontier moves 38 -> 42, the #4196 'still outstanding' note is corrected to its 2026-08-03 close-out, and the 2026-08-04 heads-of-record table is labeled the historical snapshot it is. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md (1)
145-150: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Update the stale frontier references to 42.

The merged table establishes 42 as the next allocatable integer at Lines 114-122. The proposed-allocation section still says the frontier is unchanged at 38, and the #3968 guidance still says to allocate from 38+. Codes 38–41 are already documented as merged, so those instructions can cause an ABI collision.

Update the current references to 42 and 42+. Keep 38 only in clearly dated historical snapshots.
Proposed fix
- the frontier is unchanged at 38.
+ the frontier is 42.

- from the frontier (38+)
+ from the frontier (42+)
Also applies to: 230-236
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md` around lines 145 -
150, Update the proposed-allocation guidance and frontier references in
ERROR_CODE_REGISTRY.md from 38 to 42, including the `#3968` instruction to
allocate from 42+. Preserve 38 only where it appears in clearly dated historical
snapshots, and ensure the current frontier statement reflects 42 without
changing merged-code history.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- Around line 131-133: Rewrite the affected lines in ERROR_CODE_REGISTRY.md so
each pull request reference, including `#4184` and `#4316`, follows normal prose
rather than appearing as the first token. Keep the references unescaped and
outside backticks so GitHub autolinking remains active, while preserving the
existing meaning and table details.
- Around line 103-110: Add typed SDK mappings for ErrorStaleReservationToken,
ErrorReservationTokenConsumed, ErrorReservationWalletMismatch,
ErrorDocumentNotForSale, ErrorDocumentPriceChanged,
ErrorInsufficientIdentityCredits, ErrorContestedNameNotTradable, and
ErrorShieldedInsufficientBalance in DashSdkError.kt and
PlatformWalletResult.swift, assigning ABI codes 34–41 consistently. Replace the
existing generic/unknown handling for these codes while preserving fallback
behavior for unmapped codes.

---

Outside diff comments:
In `@packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- Around line 145-150: Update the proposed-allocation guidance and frontier
references in ERROR_CODE_REGISTRY.md from 38 to 42, including the `#3968`
instruction to allocate from 42+. Preserve 38 only where it appears in clearly
dated historical snapshots, and ensure the current frontier statement reflects
42 without changing merged-code history.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 4b236099-1e70-41e5-ad12-bf6f1e79f81b

📥 Commits

Reviewing files that changed from the base of the PR and between 68f7a3f and 34f5790.

📒 Files selected for processing (1)

packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md

…ence (MD018) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

thepastaclaw

Preliminary review — Codex only

The merged 34–41 ABI entries are now documented, but the registry still omits the active code-29 allocation, contains live instructions to allocate from the obsolete code-38 frontier, and presents code 42 as both proposed and free. These contradictions undermine the PR's stated goal of providing an authoritative collision-prevention registry, so three blocking documentation fixes remain.
Source: Codex general reviewer backend gpt-5.6-sol; Codex FFI engineer reviewer backend gpt-5.6-sol; final Codex verifier backend gpt-5.6-sol.
Orchestration-only: openclaw-agent/cliproxy/gpt-5.6-sol; not reviewer evidence.

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — ffi-engineer (completed)
Verifier: gpt-5.6-sol — verifier
Sonnet: not run (deferred by blocker gate)

🔴 3 blocking

2 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:145: Resolve whether code 42 is allocated or free
  The proposed-allocation table lists `37→42` for open PR #4313 and says that PR will renumber its Rust and host mappings to 42 when revived, while lines 114–122 simultaneously declare that any new code takes 42. Rule 1 says an integer listed as proposed is not free, so these instructions can lead two contributors to claim the same value. Either reserve 42 for #4313 now and advance the public frontier to 43, or remove the concrete 42 assignment and state that #4313 must claim whichever frontier is current when its branch is updated.
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:141: Replace closed allocation owners with the active successor PRs
  (existing thread: https://github.com/dashpay/platform/pull/4318#discussion_r3726182822)
  Code 29 is not merely an ownerless reservation after #4316 closed. Open PR #4361, at head `fc97ca38d07b7225723b1e54283f92ccc26e718e`, explicitly salvages this allocation: it defines `ErrorAssetLockInsufficientFunds = 29`, maps `29` to Kotlin's typed `PlatformWallet.AssetLockInsufficientFunds`, and pins the Rust discriminant in a test. Its Swift mirror is still incomplete—the PR changes no Swift file, and its inherited `PlatformWalletResult.swift` contains only a comment about code 29, not the required raw case, `init(ffi:)` arm, typed error case, and `init(result:)` arm. Recording 29 as lapsed and ownerless hides both an active claim and the mirror work still required by rule 5. Record #4361 as the current owner and mark the Swift mirror incomplete; also update the surrounding statements that currently attribute the lapse to #4316.
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:147-150: Account for the merged allocations at codes 37 through 41
  (existing thread: https://github.com/dashpay/platform/pull/4318#discussion_r3758342008)
  The merged table and primary frontier statement now include codes 37–41, but this paragraph still says the frontier is unchanged at 38. The same live instruction remains at lines 233–234 and 390–392, where #3968 is told to allocate its persister errors from `38+`. On current `v4.2-dev`, codes 38–41 already belong to `ErrorDocumentPriceChanged`, `ErrorInsufficientIdentityCredits`, `ErrorContestedNameNotTradable`, and `ErrorShieldedInsufficientBalance`, with corresponding host mappings. Following these instructions would therefore assign duplicate ABI discriminants. Replace every current `38`/`38+` frontier directive with the post-41 frontier that remains free after resolving #4313's code-42 status; the explicitly dated August 4 survey at line 563 can retain 38 as historical state.

The shielded-invite row both promised 42 to #4313-on-revival and named 42 the next allocatable integer, letting two contributors claim the same value. The held PR now explicitly holds nothing; it takes whatever the frontier is at revival, recording the claim here first. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

bfoss765 · 2026-08-19T01:48:03Z

Fixed in cc7e72e. You were right that the row claimed more than #4361 delivered. At the time it was written Kotlin had mirrored 29 since a711c55 but Swift carried none of rule 5's three edits, so 29 fell through init(ffi:)'s default: to .errorUnknown — the exact one-host-typed, one-host-blind failure this file exists to catch, going unrecorded on a row in this table.

Rather than soften the claim, I closed the gap: #4361 now ships the Swift mirror at 15aa2ca (raw case, init(ffi:) arm, typed PlatformWalletError case with its init(result:) arm, and an ErrorHandlingTests pin on the raw value). The row now says rule 5 is satisfied as of that commit and was not before it, and cites it alongside the Rust sibling 2eac8a8, which is what lets 29 reach either host from the exact-amount funding path at all — that path was flattening the variant to ErrorWalletOperation (6) before the blanket From arm could run. Row format unchanged.

…ped retryable code (45) `ShieldedLifecycleBusy` had no FFI code of its own, so it reached hosts as the generic `ErrorWalletOperation` (6) — a non-retryable classification — through both the blanket conversion's catch-all and the claim entry point's. That is the wrong polarity in both of the variant's directions: * a one-time-key claim refused because a Clear / wallet removal holds destructive admission over its wallet, or because another claimant holds this invitation's claim-record key, scanned/built/broadcast nothing; * a Clear / wallet removal refused because in-flight claims did not drain purged nothing. Both are contended-lifecycle refusals that resolve by waiting a moment and retrying, and both consumed nothing. Surfaced as code 6 they read as a hard failure of the invitation itself. Allocate `ErrorShieldedLifecycleBusy = 45` — the next free integer past this PR's 44, taken from the registry frontier and NOT from a vacated gap (28, 30, 32 and 33 are RESERVED, not reissuable). Add its blanket conversion arm, add it to the claim entry point's pass-through arm, and mirror it in the Kotlin SDK as `DashSdkError.PlatformWallet.ShieldedLifecycleBusy` with `isRetryable = true` and a `45 ->` mapping — the same shape 44 -> `ShieldedScanBudgetExhausted` uses. The Swift mirror and the ERROR_CODE_REGISTRY.md row (the registry lives on docs/ffi-error-code-registry, #4318) are FOLLOW-UPS, not part of this commit. Tests: * Rust `shielded_invite_codes_are_pinned_at_43_through_45` — the numeric ABI, pinned like the marketplace block, since nothing checks it across the language boundary at compile time. * Rust `shielded_lifecycle_busy_maps_to_its_own_retryable_code` — both directions land on 45, Display payload preserved verbatim. * Kotlin `platformWalletCodesMapToPlatformWalletSubtree` — code 45 maps to the typed class and `isRetryable` is true, mirroring the code-44 assertions immediately above it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

thepastaclaw

Preliminary review — Codex only

PR #4318 still advertises code 43 as free and says #4313 owns no number, although open PR #4313 allocates, emits, and pins codes 43–45. The prior code-29 Swift-mirror issue is fixed, but the registry must reserve #4313's allocations, advance the frontier to 46, and disclose Swift's missing handling for 44–45 before merge.
Source: reviewer gpt-5.6-sol; final verifier gpt-5.6-sol. openclaw-agent/cliproxy/gpt-5.6-sol is orchestration-only and is not reviewer evidence.

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed)
Verifier: gpt-5.6-sol — verifier
Sonnet: not run (deferred by blocker gate)

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:114-148: Reserve the codes already allocated by revived PR #4313
  The frontier note says a new code takes 43, and the proposed row says #4313 is on hold, owns no number, and will claim the frontier only when revived. That is already false. Open #4313 at `484233af825cc755f4238a92d311aaafc70a4c55` defines `ErrorShieldedInviteAlreadyClaimed = 43`, `ErrorShieldedScanBudgetExhausted = 44`, and `ErrorShieldedLifecycleBusy = 45`; its Rust producers map all three variants to those FFI codes, and its pinning test asserts the 43–45 discriminants. Kotlin maps and tests all three values. Swift currently mirrors only code 43, so generated C values 44 and 45 fall through `PlatformWalletResultCode.init(ffi:)` to `.errorUnknown` and have no typed `PlatformWalletError` handling. Following the registry's current instruction would let another PR claim 43 and create the duplicate ABI allocation this file exists to prevent. Record 43–45 under active #4313, advance the frontier to 46, and mark Swift handling for 44 and 45 incomplete under rule 5.

… was stale The proposed table still said #4313 holds no number and a new code takes 43. False at #4313's head 0302b18: the revived branch defines and tests ErrorShieldedInviteAlreadyClaimed = 43, ErrorShieldedScanBudgetExhausted = 44 and ErrorShieldedLifecycleBusy = 45. Kotlin maps all three (typed cases, fromPlatformWalletNative arms, DashSdkErrorTest pins — all present at that commit's parent already), and Swift mirrors all three as of 0302b18 itself, which added 44/45's raw cases, init(ffi:) arms, typed cases with init(code:message:) arms, errorDescription coverage, and ErrorHandlingTests raw-value pins (43's Swift mirror predates it; its raw-value pin is Kotlin's). Record 43-45 as allocated by active #4313 with per-code rule-5 status, advance the frontier to 46, and update the three downstream frontier cites (the code-31 paragraph and both #3968 notes). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

bfoss765 · 2026-08-19T18:17:20Z

Registry brought current in 530791a: the stale on-hold row is replaced by three allocation rows recording 43–45 as owned by active #4313 (head 0302b18), and the frontier advances to 46 with the three downstream frontier cites updated.

Mirror state re-verified against the #4313 branch rather than trusted from its description: Kotlin maps all three codes (typed cases, arms, raw-value test pins — present before 0302b18); Swift mirrors all three as of 0302b18 itself, which added 44/45's raw cases, init(ffi:) arms, typed cases with init(code:message:) arms, errorDescription, and ErrorHandlingTests pins — before that commit, 44/45 were the exact Kotlin-typed/Swift-blind→.errorUnknown failure shape this file exists to catch. Rule 5 is satisfied for all three at that head, and the rows say so with commit cites.

bfoss765 · 2026-08-23T20:13:11Z

@HashEngineering requesting your review on this one — it's part of the Android-migration estate and is bot-clean/ready for human review. (GitHub won't accept a formal review request yet: your collaborator access on dashpay/platform hasn't been provisioned — flagged to be fixed alongside the #4449 team setup.)

…rage Review + CI follow-ups: * `ErrorMasternodeListUnavailable` moves 43 → 46: 43/44/45 are held by the in-flight shielded-invite error trio (#4313) across Rust, Kotlin and Swift, and the error-code registry (#4318) records 46 as the next allocatable value. Same renumber on the Swift raw case. * `InvitationPersistenceTests` capability pin gains the genuinely-attested `trackedMasternodes` bit (the handler wires the persist/load/free trio onto `PersistentTrackedMasternode`). * Storage Explorer covers `PersistentTrackedMasternode`: count row (scoped by its own networkRaw — tracked rows have no wallet join), list view, and a detail view showing the opaque Rust-owned snapshot document verbatim.

…4356 must renumber 42: merged #4451 took the number active #4356 had claimed for ErrorAssetLockInputConflict — merged ABI wins, the open PR renumbers via the frontier. 46: #4465 initially minted 43 (held by #4313), was flagged in review, and renumbered to the frontier before merging — Rust and Swift together. Frontier moves to 47. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

thepastaclaw

Preliminary review — Codex only

The prior code 43–45 allocation finding is fixed: active PR #4313 now owns those values with complete host mirrors. Two blocking contradictions remain in the registry: code 47 is simultaneously assigned to #4356 and advertised as free, while a separate live instruction still directs #3968 to start at merged code 46.
Source: reviewer backend gpt-5.6-sol (Codex general); final verifier backend gpt-5.6-sol (Codex verifier). openclaw-agent/cliproxy/gpt-5.6-sol is orchestration-only and not reviewer evidence.

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed)
Verifier: gpt-5.6-sol — verifier
Sonnet: not run (deferred by blocker gate)

🔴 2 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:151: Resolve whether code 47 belongs to #4356 or remains free
  This row directs active PR #4356 to renumber `ErrorAssetLockInputConflict` to 47, but lines 116–126 simultaneously advertise 47 as the next allocatable integer for any new code and omit #4356 from the frontier inventory. Because rule 1 makes every proposed allocation unavailable to other contributors, these instructions can assign 47 twice. Either record 47 as #4356's proposed allocation and advance the public frontier to 48, or stop naming 47 here and require #4356 to claim whatever the canonical frontier is when its branch is updated.
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:414-416: Stop directing #3968 to allocate from merged code 46
  This live remediation instruction tells #3968 to allocate its two persister codes from `46+`, even though code 46 is now shipped ABI for `ErrorMasternodeListUnavailable` and the canonical frontier starts at 47 before resolving #4356's competing claim. Following the paragraph literally would recreate the duplicate allocation this registry exists to prevent. Defer to the canonical frontier without retaining another numeric copy.

…remediation Resolves both review blockers on 32d7628: 47 is now #4356's recorded proposed allocation (rule 1 shields it), so the public frontier advances to 48; the #3968 paragraph defers to the canonical frontier note instead of carrying a numeric copy that goes stale on every merge. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

bfoss765 · 2026-08-24T11:39:53Z

@QuantumExplorer maintainer ask re the codecov/project check: it's red on this PR, #4361 and #4377 with a uniform ~−2.2–2.9% "project coverage" drop — including on this PR, which is markdown-only, so the metric demonstrably isn't measuring these changes (the wallet crates' large untested FFI surface moves the project denominator on every base advance). Could you either apply the codecov override on these three or adjust the project threshold/component config for the wallet packages? It's the only red check left on all three.

thepastaclaw

Preliminary review — Codex only

The latest commit resolves the prior code-47 double-allocation by reserving 47 for #4356 and advancing the canonical frontier to 48. Two blocking contradictions remain: #4356's row presents its three-layer renumber as completed even though the cited head still uses 42, and a second live #3968 instruction still directs allocation from merged code 46. Source: reviewer backend gpt-5.6-sol (Codex general); final verifier backend gpt-5.6-sol (Codex verifier); openclaw-agent/cliproxy/gpt-5.6-sol is orchestration-only and not reviewer evidence.

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed)
Verifier: gpt-5.6-sol — verifier
Sonnet: not run (deferred by blocker gate)

🔴 2 blocking

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:152: Mark #4356's code-47 implementation as pending
  Reserving 47 for active PR #4356 is correct, but this row incorrectly presents the three-layer renumber as completed. At the cited #4356 head `7d9be71a08`, Rust still defines and tests `ErrorAssetLockInputConflict = 42`, Swift still declares `errorAssetLockInputConflict = 42`, and Kotlin still maps and tests native code 42. Current `v4.2-dev` now assigns 42 to merged `ErrorMasternodeWithdrawalUnconfirmed`, so #4356 cannot merge until Rust, Swift, Kotlin, and their tests move together to 47. Record 47 as reserved while explicitly marking that implementation work as pending.
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:417-419: Stop directing #3968 to allocate from merged code 46
  (existing thread: https://github.com/dashpay/platform/pull/4318#discussion_r3842222018)
  The earlier #3968 remediation paragraph now correctly defers to the canonical frontier, but this second live instruction still says `46+`. Code 46 is merged ABI for `ErrorMasternodeListUnavailable`, and the current frontier is 48 after reserving 47 for #4356. Following these lines literally would assign a persister error to an existing public ABI value, recreating the collision this registry is intended to prevent. Remove this remaining numeric copy and defer exclusively to the frontier note.

…ending The row reserved 47 correctly but presented the 42-to-47 renumber as complete; at the cited #4356 head all three layers and their tests still implement 42. Record the reservation with the implementation explicitly pending. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

thepastaclaw

Preliminary review — Codex only

The latest commit correctly marks #4356's code-47 reservation and three-layer renumber as pending. One blocking contradiction remains: the live #3968 remediation still advertises merged code 46 as available even though code 47 is reserved and the canonical frontier is 48.
Source: reviewer backend gpt-5.6-sol (Codex general and FFI engineer); final verifier backend gpt-5.6-sol (Codex). Orchestration-only: openclaw-agent/cliproxy/gpt-5.6-sol; not reviewer evidence.

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — ffi-engineer (completed)
Verifier: gpt-5.6-sol — verifier
Sonnet: not run (deferred by blocker gate)

🔴 1 blocking

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:417-419: Stop directing #3968 to allocate from merged code 46
  (existing thread: https://github.com/dashpay/platform/pull/4318#discussion_r3842222018)
  This live remediation instruction still tells #3968 to allocate its persister codes from `46+`. Current `v4.2-dev` defines `ErrorMasternodeListUnavailable = 46`, while this registry reserves 47 for active PR #4356 and identifies 48 as the canonical frontier. Following the paragraph literally would therefore collide first with merged public ABI and then with an active reservation, recreating the exact allocation conflict this registry is intended to prevent. Remove the stale numeric copy and defer exclusively to the canonical frontier note.

HashEngineering

uACK

thepastaclaw

Preliminary review — Codex only

The merged allocation table and canonical frontier match the exact target head, but the live #3968 documentation remains stale in two places: one instruction still advertises merged code 46, and the non-conforming allocation table still describes #3968's superseded 26/27/28 layout instead of its current conflicting 42/43 allocation. These contradictions undermine the registry's purpose as the authoritative collision-prevention source and require correction.
Source: reviewer backend gpt-5.6-sol (Codex general and FFI engineer); final verifier backend gpt-5.6-sol (Codex verifier). Orchestration-only: openclaw-agent/cliproxy/gpt-5.6-sol; not reviewer evidence.

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — ffi-engineer (completed)
Verifier: gpt-5.6-sol — verifier
Sonnet: not run (deferred by blocker gate)

🔴 2 blocking

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:236-240: Refresh #3968's non-conforming allocations to codes 42 and 43
  The live non-conforming table still describes #3968's old `26 / 27 / 28` layout. At the supplied current open head `396977be4e7c600344364a86aba5973538ce3b4d`, #3968 instead keeps `ErrorTransactionBroadcastRejected = 26` and assigns `ErrorPersisterTransient = 42` and `ErrorPersisterFatal = 43`; that move entered in `9d0dd5a49d`. Code 42 already belongs to merged `ErrorMasternodeWithdrawalUnconfirmed`, so #3968's Rust enum and Swift mirror each contain duplicate value 42, while code 43 is reserved by active #4313 for `ErrorShieldedInviteAlreadyClaimed`. Refresh the live table, branch-state introduction, and current collision-history section to record these 42/43 conflicts and require both persister codes to move to fresh frontier values. Preserve the explicitly dated August 4 survey as historical evidence rather than rewriting that snapshot.
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:417-419: Stop directing #3968 to allocate from merged code 46
  (existing thread: https://github.com/dashpay/platform/pull/4318#discussion_r3842222018)
  This live remediation paragraph still directs #3968 to allocate its persister codes from `46+`. At the exact target head, code 46 is merged public ABI for `ErrorMasternodeListUnavailable`, code 47 is reserved for active PR #4356, and the canonical frontier at lines 116–127 is 48. Following this instruction would collide first with shipped ABI and then with an active reservation. Remove the duplicated numeric value and defer exclusively to the canonical frontier note, as the earlier remediation paragraph at lines 249–253 already does.

…new collisions At #3968's current head 396977b the old 26/27/28 layout is gone: base merges (9d0dd5a on 08-20, c86d237/4dbf38f5da on 08-25) restored ErrorTransactionBroadcastRejected = 26 and inherited ErrorShutdownIncomplete = 27, curing the rule-3 renumber. But the 08-20 merge minted ErrorPersisterTransient = 42 / ErrorPersisterFatal = 43 below the frontier: 42 is now merged ABI (#4451's ErrorMasternodeWithdrawalUnconfirmed) and duplicated in #3968's own tree (E0081 in error.rs, duplicate Swift raw value 42), and 43 is active #4313's ErrorShieldedInviteAlreadyClaimed. Refresh the non-conforming table, its branch-state introduction, and the contested-section closer to the 42/43 state; both persister codes owe fresh frontier integers (48 as of 2026-08-26). The dated 2026-08-04 survey is untouched, per review. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

thepastaclaw

Preliminary review — Codex only

The two prior #3968 blockers are fixed: the live registry now records the 42/43 conflicts and no longer directs allocation from merged code 46. One blocking lifecycle mismatch remains because code 29 merged into v4.2-dev with #4361, while the registry still classifies it as an active proposal.
Source: Codex general reviewer gpt-5.6-sol; Codex FFI engineer reviewer gpt-5.6-sol; final verifier gpt-5.6-sol. Orchestration-only: openclaw-agent/cliproxy/gpt-5.6-sol (not reviewer evidence).

Validated blockers were found in the Codex precheck. Opus is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — ffi-engineer (completed)
Verifier: gpt-5.6-sol — verifier
Sonnet: not run (deferred by blocker gate)

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md`:
- [BLOCKING] packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md:151: Move code 29 into the merged allocation table
  This row still classifies `ErrorAssetLockInsufficientFunds = 29` as an in-review allocation owned by active PR #4361, but #4361 has merged into `v4.2-dev` as `699d25704a`. That target-branch commit contains the pinned Rust discriminant and the complete Swift and Kotlin mappings and tests, so code 29 is now shipped ABI protected by rule 3 rather than a movable proposal. Move code 29 into the merged table, remove this proposed row, and update the frontier inventory and migration paragraph at lines 117 and 142 to describe #4361 as merged. The numeric frontier remains 48.

…rged table #4361 merged into v4.2-dev on 2026-08-26 as 699d257, so ErrorAssetLockInsufficientFunds = 29 is shipped ABI under rule 3, not a movable proposal. Verified at that commit: the Rust discriminant with its raw-value test pin, Swift's raw case, init(ffi:) arm, typed PlatformWalletError case and ErrorHandlingTests pin, and Kotlin's typed error with the `29 ->` arm in fromPlatformWalletNative and a DashSdkErrorTest pin. Moves the row into the merged allocation table (keeping the rule-5 history that made it worth recording), drops the proposed row, and updates the frontier inventory and the ownership-migration paragraph to describe #4361 as merged. The numeric frontier is unchanged at 48. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ult:) At 699d257 the typed-case arm sits in init(code:message:) (L578); init(result:) delegates to it. Matches how row 43 states the same thing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

HashEngineering

ACK

bfoss765 and others added 11 commits August 5, 2026 21:09

docs(ffi): registry — vacated codes 28/30 are reserved, not free; one…

584746e

… allocation frontier

bfoss765 requested review from QuantumExplorer, ZocoLini, lklimek, llbartekll and shumkov as code owners August 6, 2026 01:52

github-actions Bot added this to the v4.2.0 milestone Aug 6, 2026

bfoss765 mentioned this pull request Aug 6, 2026

docs(platform-wallet): error-code registry for the FFI result space #4261

Closed

thepastaclaw suggested changes Aug 6, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

coderabbitai Bot reviewed Aug 11, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

thepastaclaw suggested changes Aug 11, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

coderabbitai Bot reviewed Aug 11, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

docs(ffi): rewrap the migration note so no line opens with a PR refer…

4568cd1

…ence (MD018) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

thepastaclaw suggested changes Aug 11, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

thepastaclaw suggested changes Aug 19, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

coderabbitai Bot mentioned this pull request Aug 19, 2026

fix(platform-wallet): fail a double-spending asset lock with a typed terminal error #4356

Open

4 tasks

bfoss765 mentioned this pull request Aug 19, 2026

fix(platform-wallet): harden FFI runtime vs panic-abort + #4360 preflight findings #4428

Closed

bfoss765 mentioned this pull request Aug 24, 2026

feat(platform-wallet): locate and track masternodes independently of any wallet #4465

Merged

thepastaclaw suggested changes Aug 24, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

thepastaclaw suggested changes Aug 24, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

thepastaclaw suggested changes Aug 25, 2026

View reviewed changes

HashEngineering previously approved these changes Aug 26, 2026

View reviewed changes

Merge branch 'v4.2-dev' into docs/ffi-error-code-registry

8b0932d

thepastaclaw suggested changes Aug 26, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

bfoss765 dismissed HashEngineering’s stale review via cde58c4 August 26, 2026 21:55

thepastaclaw suggested changes Aug 26, 2026

View reviewed changes

Comment thread packages/rs-platform-wallet-ffi/ERROR_CODE_REGISTRY.md Outdated

HashEngineering and others added 3 commits August 26, 2026 16:52

Merge branch 'v4.2-dev' into docs/ffi-error-code-registry

a6cd82c

docs(ffi): row 29's Swift arm is in init(code:message:), not init(res…

24e10a7

…ult:) At 699d257 the typed-case arm sits in init(code:message:) (L578); init(result:) delegates to it. Matches how row 43 states the same thing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

HashEngineering approved these changes Aug 27, 2026

View reviewed changes

shumkov approved these changes Aug 27, 2026

View reviewed changes

shumkov merged commit 13f3720 into v4.2-dev Aug 27, 2026
16 checks passed

shumkov deleted the docs/ffi-error-code-registry branch August 27, 2026 01:45

Uh oh!

Conversation

bfoss765 commented Aug 6, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

What's here

Codes claimed by the in-flight PRs

⚠️ Previously unflagged collision: code 26 on #4196

Code 30 is free, despite what three branches say

Ambiguity left open for maintainers

Please correct the table

Summary by CodeRabbit

Uh oh!

coderabbitai Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviews paused

Walkthrough

Changes

Uh oh!

thepastaclaw commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thepastaclaw left a comment

Choose a reason for hiding this comment

Preliminary review — Codex only

Review provenance

Uh oh!

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

codecov Bot commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

thepastaclaw left a comment

Choose a reason for hiding this comment

Preliminary review — Codex only

Review provenance

Uh oh!

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

thepastaclaw left a comment

Choose a reason for hiding this comment

Preliminary review — Codex only

Review provenance

Uh oh!

Uh oh!

bfoss765 commented Aug 19, 2026

Uh oh!

thepastaclaw left a comment

Choose a reason for hiding this comment

Preliminary review — Codex only

Review provenance

Uh oh!

Uh oh!

bfoss765 commented Aug 19, 2026

Uh oh!

bfoss765 commented Aug 23, 2026

Uh oh!

thepastaclaw left a comment

Choose a reason for hiding this comment

Preliminary review — Codex only

Review provenance

Uh oh!

Uh oh!

Uh oh!

bfoss765 commented Aug 24, 2026

Uh oh!

thepastaclaw left a comment

Choose a reason for hiding this comment

Preliminary review — Codex only

Review provenance

Uh oh!

Uh oh!

bfoss765 commented Aug 6, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Aug 6, 2026 •

edited

Loading

thepastaclaw commented Aug 6, 2026 •

edited

Loading

codecov Bot commented Aug 11, 2026 •

edited

Loading