Chore/gbbe 374 update upstream

.cursor/commands/create-pr.md

@@ -0,0 +1,39 @@
+# Create PR
+
+## Overview
+Create a well-structured pull request with proper description, labels, and reviewers.
+
+## Steps
+
+_Note_ in the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`
+
+1. **Check that the pull request is not already open in the remote repository**
+   - If it is opened, write only PR summary (see step 3) and skip all other steps
+
+2. **Prepare branch**
+   - Ensure all changes are committed
+   - Push branch to remote
+   - Verify branch is up to date with main
+
+3. **Write PR description**
+   - Use template from `./docs/PULL_REQUEST_TEMPLATE.md`
+   - Check if the branch name contains an issue number (use the regexp `/issue-\d+/`)
+     - If found, fetch the issue details using `gh issue view [issue_number]`
+     - Include "Resolves #[issue_number]" at the very beginning of the description (in the "Description and Related Issue(s)" section)
+   - Summarize the changes clearly and concisely, using no more than two paragraphs. If necessary, use bullet points to highlight the main changes in the codebase. Be precise, this description should not be very long.
+   - List any changes in the enviroment variables (look at the `./docs/ENVS.md` file) in a separate section, describe purpose of each variable change
+      - Bad example: "Added `NEXT_PUBLIC_VIEWS_TX_GROUPED_FEES` environment variable to the documentation"
+      - Good example: "Added `NEXT_PUBLIC_VIEWS_TX_GROUPED_FEES` to group transaction fees into one section on the transaction page"
+      - Good example: "Extended possible values for `NEXT_PUBLIC_VIEWS_TX_ADDITIONAL_FIELDS` with set_max_gas_limit to display the maximum gas price set by the transaction sender"
+      - Good example: "Introduced a new option, `"fee reception"`, for the `NEXT_PUBLIC_NETWORK_VERIFICATION_TYPE` variable"
+   - Keep the "Checklist for PR Author" section and check the appropriate items in it.
+   - When finished, ask the user for confirmation or changes before moving on to the next step.
+
+4. **Set up PR**
+   - Create a pull request with a descriptive title. Use draft mode for the pull request if specified in the prompt.
+   - Add appropriate labels
+     - If something has added or changed in `./docs/ENVS.md` file, add label "ENVs"
+     - If the `package.json` file has changed, add label "dependencies"
+     - If the branch name has the issue number (use the regexp `/issue-\d+/`), copy all tags from the related issue
+   - Include a link to the created pull request in the command output.
+

.cursor/commands/deploy-demo.md

@@ -0,0 +1,36 @@
+# Deploy demo
+
+## Overview
+Create Github deployment for current branch using `.github/workflows/deploy-review.yml` workflow.
+
+## Steps
+
+_Note_ in the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`
+
+1. **Ensure all changes are pushed to remote**
+
+2. **Check if there is a running deployment workflow for current branch**
+    - If yes, abort the command
+
+3. **Detect value for "envs_preset" workflow input**
+    - Get all possible options from workflow file
+    - Figure out from the prompt with which preset user wants to deploy demo. Examples:
+        - "/deploy-demo for base" - preset name "base"
+        - "/deploy-demo using main preset" - preset name "main"
+        - "/deploy-demo without preset" - preset name "none"
+    - Be aware that this input is optional, and if user didn't mention any preset, skip this step completely
+    - If the preset is not listed in the worklow input options, notify user and abort the command
+
+4. **Run workflow from the current branch with appropriate inputs**
+   - Get the workflow run ID after triggering
+
+5. **Monitor workflow execution**
+   - Watch the workflow run until it completes (use `gh run watch`)
+   - Track the workflow status (success, failure, cancelled)
+   - Once completed, retrieve the workflow outputs and deployment URL
+
+6. **Send system notification with results**
+   - On workflow start: notify that deployment has been triggered
+   - On workflow completion: notify with final status (success/failure), deployment URL if available, and any relevant outputs
+   - On failure: notify about the error with details
+

.cursor/commands/get-checks-status.md

@@ -0,0 +1,17 @@
+# Get Checks Status
+
+## Overview
+Fetch the status of the "Checks" workflow run (workflow file `.github/workflows/checks.yml`) for __current branch__.
+
+## Steps
+
+_Note_ in the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`
+1. **Fetch the status of the most recent workflow run**
+    - Use the GitHub API to get the workflow status for the *current branch*.
+    - If the workflow is pending, subscribe to its completion.
+    - If the workflow has failed, retrieve the list of all failed jobs and steps.
+    - If the workflow was never run for the current branch, report that and skip other steps.
+
+2. **Report the status with a system notification**
+   - Upon workflow completion, notify with the final status (success or failure).
+   - In case of failure, notify about the error along with the list of failed jobs and steps.

.cursor/commands/prepare-release.md

@@ -0,0 +1,52 @@
+# Prepare Release
+
+## Overview
+Prepare the next release of the application.
+
+## Steps
+1. **Get the next release tag name**
+    - Fetch the latest release from GitHub and retrieve its name.
+    - If not specified, calculate the next __minor__ version according to [semantic versioning](https://semver.org).
+    - If specified, calculate the next __major__ or __patch__ version.
+
+2. **Update `./docs/ENVS.md` and `./docs/DEPRECATED_ENVS.md` files**
+    - In these files, update all placeholders containing "upcoming" text with the next release tag, adding a "+" at the end. Examples:
+        - "upcoming" -> "v1.2.3+"
+        - "<upcoming>" -> "v1.2.3+"
+
+3. **Create release notes**
+    - Use `./RELEASE_NOTES.md` as a reference and this release notes [link](https://github.com/blockscout/frontend/releases/tag/v2.3.0) as an example.
+    - Get all commits between the head of the remote main branch and the latest release tag.
+    - Use the GitHub API to draft the next release notes using the main branch as a target. Parse the response to obtain the list of pull requests and new contributors.
+    - Copy `./RELEASE_NOTES.md` into a new file named `./RELEASE_NOTES_<release-tag>.md`.
+    - For every section (except "Changes in ENV variables") in the file, add the appropriate pull requests from previous steps using the pattern for each line: `- <pull-request-name> by <pull-request-author> in <link-to-pull-request>`. Example: "- API documentation page by @tom2drum in https://github.com/blockscout/frontend/pull/2725". Capitalize first letter in the PR name if needed.
+    - To determine the correct section in the release notes file, use the labels assigned to each pull request (which need to be fetched separately from the GitHub API alongside the pull request description, as the description will be used in the next step) and the table below. If a pull request belongs to several sections, mention it in each section. If a pull request lacks labels or its section cannot be determined, place it in the "Other Changes" section.
+
+        | Section                     | Labels                                          |
+        | --------------------------- | ----------------------------------------------- |
+        | New Features                | feature, enhancement, client feature           |
+        | Bug Fixes                  | bug                                            |
+        | Performance Improvements     | performance                                    |
+        | Dependencies updates        | dependencies                                   |
+        | Design updates              | design                                        |
+
+    - Compose the "Changes in ENV Variables" section following these rules:
+        - Find all pull requests tagged with "ENVs."
+        - Create a temporary file and paste the pull request numbers along with their descriptions, excluding the "Checklist for PR Author" section.
+        - Analyze the changes made to the ENV variables based on those descriptions. Feel free to rephrase sentences if necessary. If you cannot determine the correct changes or are unsure of their accuracy, use "Cannot find any changes in ENVs in PR description" as a placeholder in the next step.
+        - Compose the section according to the following template (note that changes are grouped by the related pull request number):
+            ```
+            - <pull-request-number>:
+                - <change-1>
+                - <change-2>
+            ```
+            Examples:
+            - #3005
+                - Added `NEXT_PUBLIC_AD_BANNER_ENABLE_SPECIFY` to enable the Specify ad provider for users with a connected wallet.
+                - Removed the `hype` option from the `NEXT_PUBLIC_AD_BANNER_PROVIDER` variable values.
+            - #2968 
+                - Added `NEXT_PUBLIC_MEGA_ETH_SOCKET_URL_METRICS` to display information on the uptime dashboard page.
+    - Update the "Full list of the ENV variables" and "Full Changelog" with the correct version tags.
+    - Update the "New Contributors" section if necessary.
+    - Keep the "Compatibility" section unchanged.
+    - Remove all empty sections.

.cursor/mcp.json

@@ -0,0 +1,8 @@
+{
+    "mcpServers": {
+      "chakra-ui": {
+        "command": "npx",
+        "args": ["-y", "@chakra-ui/react-mcp"]
+      }
+    }
+  }

.cursor/rules/frontend.mdc

@@ -0,0 +1,37 @@
+---
+description: 
+globs: *.tsx,*.ts
+alwaysApply: false
+---
+You are an expert senior software engineer specializing in modern web development, with deep expertise in TypeScript, React 19, Next.js 15 (Pages Router), Chakra UI, and React Query. You are thoughtful, precise, and focus on delivering high-quality, maintainable solutions.
+
+## Code Style and Structure
+
+### General Principles
+
+- Write concise, readable TypeScript code
+- Use functional and declarative programming patterns; avoid classes
+- Prefer iteration and modularization over code duplication
+- Implement early returns for better readability
+- Structure components logically: exports, subcomponents, helpers, types
+
+### Naming Conventions
+
+- Use descriptive names with auxiliary verbs (isLoading, hasError)
+- Prefix event handlers with "handle" (handleClick, handleSubmit)
+- Favor default exports for React components
+
+### TypeScript Usage
+
+- Use TypeScript for all code
+- Prefer interfaces over types
+- Avoid enums; use const maps instead
+- Implement proper type safety and inference
+- Use `satisfies` operator for type validation
+
+### UI and Styling
+- Utilize Chakra UI v3 components for consistent design
+- Be aware that some components are tailored for the project's specific requirements. They are all located in the "toolkit/chakra" directory. Always use these instead of the native Chakra components.
+
+
+