chore!: forward-merge v4.2-dev into v5.0-dev

.claude/skills/pr-description/SKILL.md

@@ -13,7 +13,8 @@ Generate a pull request title and description for the current branch using the p
 1. Determine the base branch:
    - Use the argument if provided
    - Otherwise, auto-detect: `git remote set-head origin --auto >/dev/null 2>&1 && git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/||'`
-   - Fall back to `v4.0-dev` if the command above fails
+   - If that fails, use the repository's default branch on GitHub: `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`
+   - If both fail, ask the user rather than guessing a version branch
 
 2. Gather context by running these git commands:
    - `git log --oneline $(git merge-base HEAD <base>)..HEAD` — all commits on this branch
@@ -25,19 +26,30 @@ Generate a pull request title and description for the current branch using the p
    - What specific code changes were made
    - Whether there are breaking changes
    - What tests were added or modified
+   - What value the change adds, and for whom
+   - What could go wrong: consensus impact, behaviour users could notice, slow or flaky tests
 
 4. Output a suggested PR title using conventional commits format:
-   - Scopes: `sdk`, `drive`, `dpp`, `dapi`, `dashmate`, `wasm-dpp`, `wasm-sdk`, `platform`
-   - Types: `feat`, `fix`, `refactor`, `chore`, `docs`, `test`, `build`
+   - Types and scopes: use only the `types:` and `scopes:` lists in `.github/workflows/pr.yml`. The PR title check rejects anything else, so read them from that file rather than from memory
+   - The scope is optional: leave it out (e.g. `chore: ...`) when the change spans several packages or no listed scope fits. Never invent a scope
+   - The subject must not start with an uppercase letter
    - Add `!` after the type for breaking changes (e.g. `feat!:`)
    - Format: **Suggested title:** `type(scope): description`
 
-5. Fill in this PR template (preserve all HTML comments exactly as shown):
+5. Fill in this PR template (preserve all HTML comments exactly as shown). The `## Basic explanation` section always comes first; the sections after it follow `.github/PULL_REQUEST_TEMPLATE.md`. If that file differs from the copy below, follow the file:
 
 ```markdown
 <!--- Provide a general summary of your changes in the Title above -->
 <!--- Pull request titles must use the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) format -->
 
+## Basic explanation
+
+**What this does:** <The change in the most basic terms, for a reader who does not know this code. Explain any jargon in passing, or avoid it.>
+
+**Value:** <What gets better and for whom (users, wallets, node operators, the network). Give a number when there is one.>
+
+**Risks:** <What could go wrong, sized honestly: say "Low" and why when it is low. Mention consensus impact, behaviour users could notice, and slow or flaky tests.>
+
 ## Issue being fixed or feature implemented
 <!--- Why is this change required? What problem does it solve? -->
 <!--- If it fixes an open issue, please link to the issue here. -->
@@ -69,6 +81,7 @@ Generate a pull request title and description for the current branch using the p
 - [ ] I have added or updated relevant unit/integration/functional/e2e tests
 - [ ] I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
 - [ ] I have made corresponding changes to the documentation if needed
+- [ ] If I added or changed GroveDB structure, I described it in the area's `structure.rs`, regenerated `grovedb-structure.json`, and checked the structure viewer link posted on this pull request
 
 **For repository code-owners and collaborators only**
 - [ ] I have assigned this pull request to a milestone
@@ -80,6 +93,7 @@ Output the entire PR description (title + body) as a single raw Markdown code bl
 
 ## Guidelines
 
+- Always open with `## Basic explanation`: three short paragraphs (what it does, value, risks) that someone outside this code can follow. For a security fix, keep it neutral: describe what the fix does, not how the bug could be exploited
 - Keep the description **concise** — avoid walls of text. Prefer short bullet points over paragraphs
 - Be specific — reference file paths, struct/function names, and types
 - For "How Has This Been Tested?", check `git diff` for new `*test*`, `*spec*` files. Briefly describe what tests cover (1 line per test file), not every individual test case

.claude/skills/prs/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: prs
+description: "Your pull requests and the ones waiting on you, across Platform, rust-dashcore, Tenderdash, GroveDB and Dash Evo Tool: what each is blocked on, how long it has waited, and how many of your five slots per repository are taken. Use for /prs or any request to inspect the review queue."
+---
+
+# PRs
+
+Use the shared policy reporter in `dashpay/stale_prs_are_bad`. Clone or locate that repository (`$PR_REVIEW_HOME` if set, else `gh repo clone dashpay/stale_prs_are_bad` into a temporary directory) and read its `guides/PR_REVIEW_ARCHITECTURE.md` for the policy and `guides/PR_REVIEW_OPERATIONS.md` for setup and limitations.
+
+1. Resolve the current GitHub user with `gh api user --jq .login`, unless the user names another reviewer.
+2. From that checkout's root run `python3 -m pr_review.aggregate report --user USER`. For structured output add `--format json`; to limit repositories add `--repo dashpay/REPOSITORY`. For one PR run `python3 -m pr_review.main report --repo dashpay/REPOSITORY --pr NUMBER`; the policy comes from that checkout's `policies/`.
+3. Present two sections. First, what is waiting on this person to review: oldest first, with links, touched areas and the next action. Second, their own pull requests and what each is blocked on — a bot that has not reported, an unresolved bot thread, a change request, a missing self-review, or a slot that is still queued. Use repository-qualified PR identifiers. Distinguish author action, bot work, missing access, and the five-PR admission queue within each repository. Combined totals above five are workload warnings, not a global hard cap.
+4. Waiting time is the current recorded human-review cycle. If no controller state exists, say the age is not recorded. Do not equate total PR age with review waiting time.
+5. The report says nothing about CI. It reads this policy's own commit status and never the repository's check runs, so never state or imply that a build passed or failed. If asked about CI, say it is not covered and read the checks directly.
+
+This command is read-only. It does not perform the code review itself. Never post `/self-reviewed`, submit an approval, request reviewers, change labels, or send Slack messages merely because this skill was invoked. Author self-review is a personal attestation after inspecting the current diff and bot outcomes; it cannot be inferred from a bot run.
+
+If any repository evidence is incomplete or inaccessible, name that repository and state that totals are partial. Preview policy rows are computed recommendations, not live enforcement. Report the error. Do not invent readiness or approval. Report preview results as computed policy, not proof that repository enforcement has been activated.

.codecov.yml

@@ -1,11 +1,12 @@
 codecov:
   require_ci_to_pass: true
 
-# The rust-strategy and rust-shielded suites run only on push/nightly (PRs
-# skip them for speed); carryforward makes codecov reuse the base commit's
-# coverage for a flag when a PR run doesn't upload it, so PR reports don't
-# show a spurious project-coverage drop for tests that intentionally didn't
-# run.
+# Coverage is collected by the nightly run of tests.yml only (23:00 UTC on
+# the dev branches); pull request and post-merge push runs execute the same
+# tests uninstrumented and upload nothing. Every nightly uploads all three
+# flags; carryforward only matters when one phase fails and its report is
+# missing, so a single broken phase doesn't read as a coverage drop for the
+# whole suite.
 flags:
   rust:
     carryforward: true
@@ -52,6 +53,8 @@ ignore:
   - "packages/data-contracts/src/**"
   - "packages/dpns-contract/src/**"
   - "packages/keyword-search-contract/src/**"
+  - "packages/app-connect-contract/src/**"
+  - "packages/moderation-charters-contract/src/**"
   - "packages/masternode-reward-shares-contract/src/**"
   - "packages/token-history-contract/src/**"
   - "packages/wallet-utils-contract/src/**"
@@ -108,11 +111,6 @@ ignore:
   - "packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/**/v1_methods.rs"
   # Platform wallet — requires Core wallet integration, not unit-testable
   - "packages/rs-platform-wallet/src/**"
-  # Platform wallet storage — its tests run in the wallet fast-path
-  # workflow (tests-rs-wallet.yml), which intentionally omits coverage
-  # upload, so codecov never receives data for this crate on
-  # wallet-scoped PRs and patch status would fail spuriously
-  - "packages/rs-platform-wallet-storage/**"
   # Proof-verifier response types and unproved handling
   - "packages/rs-drive-proof-verifier/src/types.rs"
   - "packages/rs-drive-proof-verifier/src/unproved.rs"
@@ -158,20 +156,20 @@ ignore:
   # Versioned dispatch methods — pure version routing with no logic
   - "packages/rs-dpp/src/data_contract/document_type/methods/versioned_methods.rs"
 
+# Statuses attach to the nightly commit only (no PR ever uploads), so they
+# are informational: a nightly dip shows on the Codecov commit page without
+# painting the branch tip red. Patch coverage has no meaningful base without
+# PR uploads, and PR comments have nothing to attach to.
 coverage:
   status:
     project:
       default:
         target: auto
         threshold: 2%
-    patch:
-      default:
-        target: 50%
+        informational: true
+    patch: off
 
-comment:
-  layout: "condensed_header, diff, components, condensed_files"
-  behavior: default
-  require_changes: true
+comment: false
 
 component_management:
   individual_components:

.editorconfig

@@ -11,5 +11,13 @@ end_of_line = lf
 [*.rs]
 indent_size = 4
 
+# Swift and Kotlin follow their languages' 4-space convention.
+[*.{swift,kt,kts}]
+indent_size = 4
+
+# Preserve the existing indentation of the Swift SDK Python scripts.
+[packages/swift-sdk/scripts/*.py]
+indent_size = 4
+
 [*.{md,markdown}]
 trim_trailing_whitespace = false

.github/CODEOWNERS

@@ -0,0 +1,8 @@
+# Generated from dashpay/stale_prs_are_bad policies/platform.json; do not edit by hand.
+#
+# Review routing for this repository is controlled by PR Hygiene:
+#   https://github.com/dashpay/stale_prs_are_bad/blob/master/policies/platform.json
+#
+# This file has no rules on purpose. Reviewers are requested by the policy
+# once the bots have reported and the author has self-reviewed, not by
+# GitHub the moment a pull request is opened.

.github/NPM_RUNNER.md

@@ -0,0 +1,103 @@
+# NPM release runners
+
+NPM release compilation uses a fresh single-job runner with a unique
+`platform-release-<run-id>-<attempt>-npm` label in the `platform-release-builds`
+runner group. Kotlin releases use the same lifecycle with a `-kotlin` label. Publishing
+continues on GitHub-hosted Ubuntu with OIDC; the builder receives no publishing
+credentials. The `npm-release-build` action is shared by releases and image
+validation so both compile and pack with the same setup.
+
+## Image contract
+
+`.github/runner-requirements.json` pins the complete Linux image requirements and
+recipe commit. The job runs `ci-image-contract verify` before compiling. The
+runner must have `/opt/client-codegen` matching `packages/dapi-grpc/codegen.json`.
+Its protobuf 3.18.1 compiler is intentionally separate from Rust's protoc 32.0.
+TypeScript generation comes from the workspace's pinned `ts-protoc-gen` dependency.
+
+Image-owned native dependencies are verified, never installed using sudo. Rust,
+Node and the pinned WASM tools use writable runner/user locations. Cargo targets
+remain in job-local HOME; each release starts with fresh runner, HOME and workspace state. The
+runner needs no Docker CLI/socket or KVM device.
+
+## Provisioning and promotion
+
+Use the reviewed `dashpay/dash-selfhosted-image` recipe and a tested immutable
+image digest, not a moving tag. Deploy the host-side disposable release controller
+only after the NPM validation workflow succeeds on that image. Do not add generic
+release labels to persistent CI registrations. See the
+[controller installation and cleanup runbook](https://github.com/dashpay/dash-selfhosted-image/blob/main/docs/disposable-releases.md).
+Old release tags
+still contain their original workflows and do not automatically gain this fix.
+
+Requirements-changing PRs select a candidate label bound to the complete PR head
+and image digest. The image controller must support the `npm` job kind and
+`.github/workflows/npm-runner-validation.yml`. Manifests requesting native client
+generation require successful Rust, Kotlin and NPM candidate jobs for promotion;
+skipped fork jobs do not qualify. Existing same-repository/trusted-fork guards
+remain in effect.
+
+The trusted `runner-image-candidate.yml` bootstrap, controller and Rust/Kotlin
+candidate routing must be installed on each consuming branch before candidate
+promotion can work. Platform PRs #4702 and #4912 establish those pieces; reconcile
+their requirements/selector files with this NPM extension when landing them. In
+particular, update both the bootstrap's reusable-workflow SHA and its
+`control_revision` to a reviewed image-repository revision supporting
+`client_codegen` and `npm`. Merely changing `recipe_revision` is insufficient.
+The default `v4.2-dev` and `v4.3-dev` branches must each use an explicit compatible
+manifest; this change does not alter an existing release tag or deploy a runner.
+
+## Verification
+
+`npm-runner-validation.yml` runs the real release build and packing action, DAPI
+unit tests, and a byte-for-byte check that packed Node/web clients match the
+freshly generated files. It uploads tarballs but never publishes them.
+`test-client-codegen.yml` also builds the native compilers on hosted Linux/macOS,
+checks committed generated output, tests failure recovery and validates packing.
+
+Local setup and generator test commands are in `packages/dapi-grpc/README.md`.
+
+After installing the controller, use the `release.yml` dispatch with
+`tag=npm-test:v<package.json version>` on a protected development branch for a non-publishing
+NPM build. For Kotlin, dispatch `release-kotlin-sdk.yml` from the protected branch
+with an existing published `tag` and `dry_run=true`: compilation/artifact upload
+run, but release attachment and Maven publication are both skipped. Check that
+the image contract matches the selected source. Neither controller unit tests
+nor an image smoke test establishes that these end-to-end jobs pass.
+
+## Separate PR and release state
+
+The `platform-release-builds` organization runner group selects only
+`dashpay/platform` and contains only controller-created one-job registrations.
+Each build requests:
+
+```yaml
+runs-on:
+  group: platform-release-builds
+  labels: [self-hosted, Linux, X64, 'platform-release-${{ github.run_id }}-${{ github.run_attempt }}-npm']
+```
+
+There is no fallback to `npm-build`, `rust-ci` or `kotlin-ci`. Without the
+controller, builds stay queued. Runtime markers reject accidental routing to an
+ordinary runner; they are not cryptographic attestation. The host controller
+independently checks repository, event, workflow, run, attempt and commit before
+creating fresh JIT capacity. Only one job can consume each registration; the host
+destroys its container/processes, HOME, registration and workspace afterward.
+
+**Ordinary PR caching is unchanged.** PR validation keeps its own persistent
+Cargo/Gradle/Yarn caches. Releases reuse the prebaked image/toolchains but never
+mount PR state or restore shared executable dependency caches. Yarn caching is
+opted out only for the release runtime; Kotlin release build/publication disable
+Gradle cache restores. A cold release compile is the intentional tradeoff; do not
+reintroduce shared caches to speed it up without reviewing their writer trust.
+
+`release.yml` calls its local reusable workflow, so the workflow travels with the
+release source. Port it and the matching image requirements to 4.3; the host
+controller needs no branch-specific allowlist. Branch protection, trusted tags,
+fork approvals and hosted publishing authorization remain necessary. Optional
+selected-workflow group restrictions are defense in depth, not the mechanism
+that erases prior-job state. Labels alone are not authorization.
+
+This assumes a trusted host and pinned image. A fresh container does not repair
+host compromise or retroactively secure old release tags/artifacts. Merge/deploy
+the controller before relying on this workflow change for a release.

.github/PULL_REQUEST_TEMPLATE.md

@@ -28,6 +28,7 @@
 - [ ] I have added or updated relevant unit/integration/functional/e2e tests
 - [ ] I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
 - [ ] I have made corresponding changes to the documentation if needed
+- [ ] If I added or changed GroveDB structure, I described it in the area's `structure.rs`, regenerated `grovedb-structure.json`, and checked the structure viewer link posted on this pull request
 
 **For repository code-owners and collaborators only**
 - [ ] I have assigned this pull request to a milestone