Merge master to production

.changeset/config.json

@@ -12,8 +12,18 @@
   "access": "public",
   "baseBranch": "master",
   "updateInternalDependencies": "patch",
-  "ignore": [
-    "@openzeppelin/wizard-cairo-alpha",
-    "ui"
-  ]
+  "privatePackages": {
+    "version": true,
+    "tag": false
+  },
+  "changedFilePatterns": [
+    "**",
+    "!src/cairo_alpha/**",
+    "!src/polkadot/**",
+    "!api/**",
+    "!public/**",
+    "!scripts/deno/**",
+    "!src/**/App.svelte"
+  ],
+  "ignore": ["@openzeppelin/wizard-cairo-alpha"]
 }

.claude/skills/changeset/SKILL.md

@@ -30,6 +30,7 @@ First line is a high-level summary without leading dash (PR number gets appended
 5. **Multiple packages**: Multiple packages can share a changeset file with different bump levels in the frontmatter. Use separate files only when packages need unrelated descriptions.
 6. **Bump levels**: Follow semver based on current package version. `x.y.z` (>=1.0.0): major for breaking, minor for features, patch for fixes. `0.x.y`: minor for breaking, patch for features/fixes. `0.0.x`: patch for everything.
 7. **New unpublished packages**: Still need a changeset to bump the initial version in package.json and for the changes to appear in the resulting changelog.
+8. **UI that ships in MCP Apps**: `ui` is private (versioned in-repo, not published to npm). MCP App HTML is built from `ui` when `@openzeppelin/contracts-mcp` is published. Changes to Wizard controls or other UI that ships in MCP Apps need **one changeset listing both** `ui` and `@openzeppelin/contracts-mcp`. Web-only UI (Cairo Alpha, Polkadot, `App.svelte`) does not need a changeset. Never version `ui` in a changeset without also listing `@openzeppelin/contracts-mcp`.
 
 ## Steps
 

.github/workflows/changeset.yml

@@ -26,3 +26,5 @@ jobs:
         uses: ./.github/actions/setup
       - name: Check changeset
         run: npx changeset status --since=origin/${{ github.base_ref }}
+      - name: Check UI changesets include contracts-mcp
+        run: node scripts/release/check-mcp-ui-changeset.mjs origin/${{ github.base_ref }}

.github/workflows/version.yml

@@ -4,6 +4,9 @@ on:
   push:
     branches:
       - master
+    # Skip pushes that only affect the Netlify UI deployment. If changes affect
+    # contract-specific controls which are part of the packaged HTML files for MCP Apps,
+    # those PRs also add a .changeset file, so this workflow still runs.
     paths-ignore:
       - 'packages/ui/**'
 

CONTRIBUTING.md

@@ -96,5 +96,8 @@ From the `packages/mcp` directory:
 As a contributor, we ask that you fork this repository, work on your own fork and then submit pull requests. The pull requests will be reviewed and eventually merged into the main repo. See ["Fork-a-Repo"](https://help.github.com/articles/fork-a-repo/) for how this works.
 
 ### Adding Changesets
-If your PR modifies code generation logic under `packages/core`, you will need to add changesets for the relevant packages to summarize the changes. The PR's `Changeset` GitHub check will give an error if this condition is not satisfied.
+Published packages (`packages/core/*`, `packages/common`, `packages/cli`, `packages/mcp`) use [Changesets](https://github.com/changesets/changesets) for versioning. The PR's `Changeset` GitHub check fails when a changed publishable package has no changeset. Use the `ignore-changeset` label only when a bump is genuinely not needed.
+
+The `ui` package is private (Netlify + MCP App source) and is versioned in-repo but not published. MCP App HTML is built from `ui` when `@openzeppelin/contracts-mcp` is published. If your PR changes Wizard controls or other UI that ships in MCP Apps, add **one changeset that lists both** `ui` and `@openzeppelin/contracts-mcp`. Web-only UI (for example Cairo Alpha, Polkadot, or the web Wizard `App.svelte` shells) does not require a changeset.
+
 - To add a changeset: from the root directory, run `yarn changeset`

package.json

@@ -37,6 +37,7 @@
   "devDependencies": {
     "@changesets/changelog-github": "^0.5.1",
     "@changesets/cli": "^2.29.2",
+    "@changesets/read": "^0.6.5",
     "@eslint/js": "^9.21.0",
     "concurrently": "^9.1.2",
     "eslint": "^9.33.0",
@@ -49,4 +50,3 @@
     "typescript-eslint": "^8.29.0"
   }
 }
-

packages/cli/src/cli.test.ts.md

@@ -53,7 +53,7 @@ Generated by [AVA](https://avajs.dev).
       --permit                              Whether without paying gas, token holders will be able to allow third parties to transfer from their account.␊
       --votes <blocknumber|timestamp>       Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps.␊
       --flashmint                           Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction.␊
-      --crossChainBridging <custom|erc7786native|superchain>  Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain.␊
+      --crossChainBridging <custom|erc7786native|superchain>  Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain.␊
       --crossChainLinkAllowOverride         Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".␊
       --namespacePrefix <string>            The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject".␊
       --access <ownable|roles|managed>      The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.␊
@@ -81,7 +81,7 @@ Generated by [AVA](https://avajs.dev).
       --mintable                            Whether privileged accounts will be able to create more supply or emit more tokens␊
       --incremental                         Whether new tokens will be automatically assigned an incremental id␊
       --votes <blocknumber|timestamp>       Whether to keep track of individual units for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps (defaulting to block number if not specified).␊
-      --crossChainBridging <erc7786native>  Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Cross-chain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens.␊
+      --crossChainBridging <erc7786native>  Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens.␊
       --crossChainLinkAllowOverride         Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".␊
       --access <ownable|roles|managed>      The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.␊
       --upgradeable <transparent|uups>      Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.␊
@@ -106,7 +106,7 @@ Generated by [AVA](https://avajs.dev).
       --mintable                            Whether privileged accounts will be able to create more supply or emit more tokens␊
       --supply                              Whether to keep track of total supply of tokens␊
       --updatableUri                        Whether privileged accounts will be able to set a new URI for all token types␊
-      --crossChainBridging <erc7786native>  Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Cross-chain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain.␊
+      --crossChainBridging <erc7786native>  Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain.␊
       --crossChainLinkAllowOverride         Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".␊
       --access <ownable|roles|managed>      The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.␊
       --upgradeable <transparent|uups>      Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades.␊
@@ -135,7 +135,7 @@ Generated by [AVA](https://avajs.dev).
       --permit                              Whether without paying gas, token holders will be able to allow third parties to transfer from their account.␊
       --votes <blocknumber|timestamp>       Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps.␊
       --flashmint                           Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction.␊
-      --crossChainBridging <custom|erc7786native|superchain>  Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain.␊
+      --crossChainBridging <custom|erc7786native|superchain>  Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain.␊
       --crossChainLinkAllowOverride         Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".␊
       --namespacePrefix <string>            The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject".␊
       --access <ownable|roles|managed>      The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.␊
@@ -166,7 +166,7 @@ Generated by [AVA](https://avajs.dev).
       --permit                              Whether without paying gas, token holders will be able to allow third parties to transfer from their account.␊
       --votes <blocknumber|timestamp>       Whether to keep track of historical balances for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps.␊
       --flashmint                           Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction.␊
-      --crossChainBridging <custom|erc7786native|superchain>  Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain.␊
+      --crossChainBridging <custom|erc7786native|superchain>  Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain.␊
       --crossChainLinkAllowOverride         Whether to allow replacing a crosschain link that has already been registered. Only used if crossChainBridging is set to "erc7786native".␊
       --namespacePrefix <string>            The prefix for ERC-7201 namespace identifiers. It should be derived from the project name or a unique naming convention specific to the project. Used only if the contract includes storage variables and upgradeability is enabled. Default is "myProject".␊
       --access <ownable|roles|managed>      The type of access control to provision. Ownable is a simple mechanism with a single account authorized for all privileged actions. Roles is a flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. Managed enables a central contract to define a policy that allows certain callers to access certain functions.␊

packages/common/CHANGELOG.md

@@ -1,6 +1,10 @@
 # Changelog
 
 
+## 0.5.5 (2026-08-07)
+
+- Standardize crosschain terminology in user-facing text. ([#840](https://github.com/OpenZeppelin/contracts-wizard/pull/840))
+
 ## 0.5.4 (2026-07-31)
 
 - Add Solidity cross-chain options for ERC721, ERC1155, and Governor using OpenZeppelin Contracts 5.7. ([#825](https://github.com/OpenZeppelin/contracts-wizard/pull/825))

packages/common/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openzeppelin/wizard-common",
-  "version": "0.5.4",
+  "version": "0.5.5",
   "description": "Common library for OpenZeppelin Contracts Wizard components. Used internally.",
   "license": "AGPL-3.0-only",
   "repository": "https://github.com/OpenZeppelin/contracts-wizard",
@@ -34,7 +34,7 @@
     "zod": "^4.0"
   },
   "devDependencies": {
-    "@openzeppelin/wizard": "^0.10.12",
+    "@openzeppelin/wizard": "^0.10.13",
     "@openzeppelin/wizard-cairo": "^3.0.0",
     "@openzeppelin/wizard-stellar": "^0.6.3",
     "@openzeppelin/wizard-stylus": "^0.3.0",

packages/common/src/ai/descriptions/solidity.ts

@@ -36,7 +36,7 @@ export const solidityERC20Descriptions = {
   flashmint:
     "Whether to include built-in flash loans to allow lending tokens without requiring collateral as long as they're returned in the same transaction.",
   crossChainBridging:
-    'Whether to allow authorized bridge contracts to mint and burn tokens for cross-chain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain.',
+    'Whether to allow authorized bridge contracts to mint and burn tokens for crosschain transfers. Options are to use custom bridges on any chain, to embed an ERC-7786 based bridge directly in the token contract, or to use the SuperchainERC20 standard with the predeployed SuperchainTokenBridge. The SuperchainERC20 feature is only available on chains in the Superchain, and requires deploying your contract to the same address on every chain in the Superchain.',
   crossChainLinkAllowOverride: crossChainLinkAllowOverrideDescription,
   premintChainId: 'The chain ID of the network on which to premint tokens.',
   callback:
@@ -52,7 +52,7 @@ export const solidityERC721Descriptions = {
   votes:
     'Whether to keep track of individual units for voting in on-chain governance. Voting durations can be expressed as block numbers or timestamps (defaulting to block number if not specified).',
   crossChainBridging:
-    'Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Cross-chain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens.',
+    'Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the token on the source chain and mint it on the destination chain. If also using incremental token ids, mint only on a single chain and link counterparts without minting, otherwise colliding ids can strand bridged tokens.',
   crossChainLinkAllowOverride: crossChainLinkAllowOverrideDescription,
 };
 
@@ -61,7 +61,7 @@ export const solidityERC1155Descriptions = {
   supply: 'Whether to keep track of total supply of tokens',
   updatableUri: 'Whether privileged accounts will be able to set a new URI for all token types',
   crossChainBridging:
-    'Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Cross-chain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain.',
+    'Whether to embed an ERC-7786 based bridge directly in the token contract, making it natively crosschain. Crosschain transfers with registered counterparts burn the tokens on the source chain and mint them on the destination chain.',
   crossChainLinkAllowOverride: crossChainLinkAllowOverrideDescription,
 };