test(core): add missing tests for prompts/utils.ts

.gemini/commands/strict-development-rules.md

@@ -107,7 +107,7 @@ Gemini CLI project.
   set.
 - **Logging**: Use `debugLogger` for rethrown errors to avoid duplicate logging.
 - **Keyboard Shortcuts**: Define all new keyboard shortcuts in
-  `packages/cli/src/config/keyBindings.ts` and document them in
+  `packages/cli/src/ui/key/keyBindings.ts` and document them in
   `docs/cli/keyboard-shortcuts.md`. Be careful of keybindings that require the
   `Meta` key, as only certain meta key shortcuts are supported on Mac. Avoid
   function keys and shortcuts commonly bound in VSCode.

.gemini/skills/docs-writer/SKILL.md

@@ -45,6 +45,10 @@ Write precisely to ensure your instructions are unambiguous.
   specific verbs.
 - **Examples:** Use meaningful names in examples; avoid placeholders like
   "foo" or "bar."
+- **Quota and limit terminology:** For any content involving resource capacity
+  or using the word "quota" or "limit", strictly adhere to the guidelines in
+  the `quota-limit-style-guide.md` resource file. Generally, Use "quota" for the
+  administrative bucket and "limit" for the numerical ceiling.
 
 ### Formatting and syntax
 Apply consistent formatting to make documentation visually organized and
@@ -114,6 +118,8 @@ documentation.
   reflects existing code.
 - **Structure:** Apply "Structure (New Docs)" rules (BLUF, headings, etc.) when 
   adding new sections to existing pages.
+- **Headers**: If you change a header, you must check for links that lead to
+  that header and update them.
 - **Tone:** Ensure the tone is active and engaging. Use "you" and contractions.
 - **Clarity:** Correct awkward wording, spelling, and grammar. Rephrase
   sentences to make them easier for users to understand.
@@ -129,7 +135,8 @@ and that all links are functional.
   technical behavior.
 2.  **Self-review:** Re-read changes for formatting, correctness, and flow.
 3.  **Link check:** Verify all new and existing links leading to or from modified
-    pages.
+    pages. If you changed a header, ensure that any links that lead to it are
+    updated.
 4.  **Format:** Once all changes are complete, ask to execute `npm run format`
     to ensure consistent formatting across the project. If the user confirms,
     execute the command.

.gemini/skills/docs-writer/quota-limit-style-guide.md

@@ -0,0 +1,61 @@
+# Style Guide: Quota vs. Limit
+
+This guide defines the usage of "quota," "limit," and related terms in
+user-facing interfaces.
+
+## TL;DR
+
+- **`quota`**: The administrative "bucket." Use for settings, billing, and
+  requesting increases. (e.g., "Adjust your storage **quota**.")
+- **`limit`**: The real-time numerical "ceiling." Use for error messages when a
+  user is blocked. (e.g., "You've reached your request **limit**.")
+- **When blocked, combine them:** Explain the **limit** that was hit and the
+  **quota** that is the remedy. (e.g., "You've reached the request **limit** for
+  your developer **quota**.")
+- **Related terms:** Use `usage` for consumption tracking, `restriction` for
+  fixed rules, and `reset` for when a limit refreshes.
+
+---
+
+## Detailed Guidelines
+
+### Definitions
+
+- **Quota is the "what":** It identifies the category of resource being managed
+  (e.g., storage quota, GPU quota, request/prompt quota).
+- **Limit is the "how much":** It defines the numerical boundary.
+
+Use **quota** when referring to the administrative concept or the request for
+more. Use **limit** when discussing the specific point of exhaustion.
+
+### When to use "quota"
+
+Use this term for **account management, billing, and settings.** It describes
+the entitlement the user has purchased or been assigned.
+
+**Examples:**
+
+- **Navigation label:** Quota and usage
+- **Contextual help:** Your **usage quota** is managed by your organization. To
+  request an increase, contact your administrator.
+
+### When to use "limit"
+
+Use this term for **real-time feedback, notifications, and error messages.** It
+identifies the specific wall the user just hit.
+
+**Examples:**
+
+- **Error message:** You’ve reached the 50-request-per-minute **limit**.
+- **Inline warning:** Input exceeds the 32k token **limit**.
+
+### How to use both together
+
+When a user is blocked, combine both terms to explain the **event** (limit) and
+the **remedy** (quota).
+
+**Example:**
+
+- **Heading:** Daily usage limit reached
+- **Body:** You've reached the maximum daily capacity for your developer quota.
+  To continue working today, upgrade your quota.

.gemini/skills/string-reviewer/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: string-reviewer
+description: >
+  Use this skill when asked to review text and user-facing strings within the codebase. It ensures that these strings follow rules on clarity,
+  usefulness, brevity and style.
+---
+
+# String Reviewer
+
+## Instructions
+
+Act as a Senior UX Writer. Look for user-facing strings that are too long,
+unclear, or inconsistent. This includes inline text, error messages, and other
+user-facing text.
+
+Do NOT automatically change strings without user approval. You must only suggest
+changes and do not attempt to rewrite them directly unless the user explicitly
+asks you to do so.
+
+## Core voice principles
+
+The system prioritizes deterministic clarity over conversational fluff. We
+provide telemetry, not etiquette, ensuring the user retains absolute agency..
+
+1. **Deterministic clarity:** Distinguish between certain system/service states
+   (Cloud Billing, IAM, the System) and probabilistic AI analysis (Gemini).
+2. **System transparency:** Replace "Loading..." with active technical telemetry
+   (e.g., Tracing stack traces...). Keep status updates under 5 words.
+3. **Front-loaded actionability:** Always use the [Goal] + [Action] pattern.
+   Lead with intent so users can scan left-to-right.
+4. **Agentic error recovery:** Every error must be a pivot point. Pair failures
+   with one-click recovery commands or suggested prompts.
+5. **Contextual humility:** Reserve disclaimers and "be careful" warnings for P0
+   (destructive/irreversible) tasks only. Stop warning-fatigue.
+
+## The writing checklist
+
+Use this checklist to audit UI strings and AI responses.
+
+### Identity and voice
+- **Eliminate the "I":** Remove all first-person pronouns (I, me, my, mine).
+- **Subject attribution:** Refer to the AI as Gemini and the infrastructure as
+  the - system or the CLI.
+- **Active voice:** Ensure the subject (Gemini or the system) is clearly
+  performing the action.
+- **Ownership rule:** Use the system for execution (doing) and Gemini for
+  analysis (thinking)
+
+### Structural scannability
+- **The skip test:** Do the first 3 words describe the user’s intent? If not,
+  rewrite.
+- **Goal-first sequence:** Use the template: [To Accomplish X] + [Do Y].
+- **The 5-word rule:** Keep status updates and loading states under 5 words.
+- **Telemetry over etiquette:** Remove polite filler (Please wait, Thank you,
+  Certainly). Replace with raw data or progress indicators.
+- **Micro-state cycles:** For tasks $> 3$ seconds, cycle through specific
+  sub-states (e.g., Parsing logs... ➔ Identifying patterns...) to show momentum.
+
+
+### Technical accuracy and humility
+- **Verb signal check:** Use deterministic verbs (is, will, must) for system
+  state/infrastructure.
+  - Use probabilistic verbs (suggests, appears, may, identifies) for AI output.
+- **No 100% certainty:** Never attribute absolute certainty to model-generated
+  content.
+- **Precision over fuzziness:** Use technical metrics (latency, tokens, compute) instead of "speed" or "cost."
+- **Instructional warnings:** Every warning must include a specific corrective action (e.g., "Perform a dry-run first" or "Review line 42").
+
+### Agentic error recovery
+- **The one-step rule:** Pair every error message with exactly one immediate
+  path to a fix (command, link, or prompt).
+- **Human-first:** Provide a human-readable explanation before machine error
+  codes (e.g., 404, 500).
+-  **Suggested prompts:** Offer specific text for the user to copy/click like
+   “Ask Gemini: 'Explain this port error.'”
+
+### Use consistent terminology
+
+Ensure all terminology aligns with the project [word
+list](./references/word-list.md). 
+
+If a string uses a term marked "do not use" or "use with caution," provide a
+correction based on the preferred terms.
+
+## Ensure consistent style for settings
+
+If `packages/cli/src/config/settingsSchema.ts` is modified, confirm labels and
+descriptions specifically follow the unique [Settings
+guidelines](./references/settings.md).
+
+## Output format
+When suggesting changes, always present your review using the following list
+format. Do not provide suggestions outside of this list..
+
+```
+1. **{Rationale/Principle Violated}**
+  - ❌ "{incorrect phrase}"
+  - ✅ `"{corrected phrase}"`
+```

.gemini/skills/string-reviewer/references/settings.md

@@ -0,0 +1,28 @@
+# Settings
+
+## Noun-First Labeling (Scannability)
+
+Labels must start with the subject of the setting, not the action. This allows
+users to scan for the feature they want to change.
+
+- **Rule:** `[Noun]` `[Attribute/Action]`
+- **Example:** `Show line numbers` becomes simply `Line numbers`
+
+## Positive Boolean Logic (Cognitive Ease)
+
+Eliminate "double negatives." Booleans should represent the presence of a
+feature, not its absence.
+
+- **Rule:** Replace `Disable {feature}` or `Hide {Feature}` with
+  `{Feature} enabled` or simply `{Feature}`.
+- **Example:** Change "Disable auto update" to "Auto update".
+- **Implementation:** Invert the boolean value in your config loader so true
+  always equals `On`
+
+## Verb Stripping (Brevity)
+
+Remove redundant leading verbs like "Enable," "Use," "Display," or "Show" unless
+they are part of a specific technical term.
+
+- **Rule**: If the label works without the verb, remove it
+- **Example**: Change `Enable prompt completion` to `Prompt completion`

.gemini/skills/string-reviewer/references/word-list.md

@@ -0,0 +1,61 @@
+## Terms
+
+### Preferred
+
+- Use **create** when a user is creating or setting up something.
+- Use **allow** instead of **may** to indicate that permission has been granted
+  to perform some action.
+- Use **canceled**, not **cancelled**.
+- Use **configure** to refer to the process of changing the attributes of a
+  feature, even if that includes turning on or off the feature.
+- Use **delete** when the action being performed is destructive.
+- Use **enable** for binary operations that turn a feature or API on. Use "turn
+  on" and "turn off" instead of "enable" and "disable" for other situations.
+- Use **key combination** to refer to pressing multiple keys simultaneously.
+- Use **key sequence** to refer to pressing multiple keys separately in order.
+- Use **modify** to refer to something that has changed vs obtaining the latest
+  version of something.
+- Use **remove** when the action being performed takes an item out of a larger
+  whole, but doesn't destroy the item itself.
+- Use **set up** as a verb. Use **setup** as a noun or adjective.
+- Use **show**. In general, use paired with **hide**.
+- Use **sign in**, **sign out** as a verb. Use **sign-in** or **sign-out** as a
+  noun or adjective.
+- Use **update** when you mean to obtain the latest version of something.
+- Use **want** instead of **like** or **would like**.
+
+#### Don't use
+
+- Don't use **etc.** It's redundant. To convey that a series is incomplete,
+  introduce it with "such as" instead.
+- Don't use **hostname**, use "host name" instead.
+- Don't use **in order to**. It's too formal. "Before you can" is usually better
+  in UI text.
+- Don't use **one or more**. Specify the quantity where possible. Use "at least
+  one" when the quantity is 1+ but you can't be sure of the number. Likewise,
+  use "at least one" when the user must choose a quantity of 1+.
+- Don't use the terms **log in**, **log on**, **login**, **logout** or **log
+  out**.
+- Don't use **like** or **would you like**. Use **want** instead. Better yet,
+  rephrase so that it's not referring to the user's emotional state, but rather
+  what is required.
+
+#### Use with caution
+
+- Avoid using **leverage**, especially as a verb. "Leverage" is considered a
+  buzzword largely devoid of meaning apart from the simpler "use".
+- Avoid using **once** as a synonym for "after". Typically, when "once" is used
+  in this way, it is followed by a verb in the perfect tense.
+- Don't use **e.g.** Use "example", "such as", "like", or "for example". The
+  phrase is always followed by a comma.
+- Don't use **i.e.** unless absolutely essential to make text fit. Use "that is"
+  instead.
+- Use **disable** for binary operations that turn a feature or API off. Use
+  "turn on" and "turn off" instead of "enable" and "disable" for other
+  situations. For UI elements that are not available, use "dimmed" instead of
+  "disabled".
+- Use **please** only when you're asking the user to do something inconvenient,
+  not just following the instructions in a typical flow.
+- Use **really** sparingly in such constructions as "Do you really want to..."
+  Because of the weight it puts on the decision, it should be used to confirm
+  actions that the user is extremely unlikely to make.

.github/CODEOWNERS

@@ -14,4 +14,9 @@
 
 # Docs have a dedicated approver group in addition to maintainers
 /docs/ @google-gemini/gemini-cli-maintainers @google-gemini/gemini-cli-docs
-/README.md @google-gemini/gemini-cli-maintainers @google-gemini/gemini-cli-docs
+/README.md @google-gemini/gemini-cli-maintainers @google-gemini/gemini-cli-docs
+
+# Prompt contents, tool definitions, and evals require reviews from prompt approvers
+/packages/core/src/prompts/ @google-gemini/gemini-cli-prompt-approvers
+/packages/core/src/tools/ @google-gemini/gemini-cli-prompt-approvers
+/evals/ @google-gemini/gemini-cli-prompt-approvers

.github/actions/publish-release/action.yml

@@ -192,6 +192,13 @@ runs:
         INPUTS_CLI_PACKAGE_NAME: '${{ inputs.cli-package-name }}'
         INPUTS_A2A_PACKAGE_NAME: '${{ inputs.a2a-package-name }}'
 
+    - name: '📦 Prepare bundled CLI for npm release'
+      if: "inputs.npm-registry-url != 'https://npm.pkg.github.com/' && inputs.npm-tag != 'latest'"
+      working-directory: '${{ inputs.working-directory }}'
+      shell: 'bash'
+      run: |
+        node ${{ github.workspace }}/scripts/prepare-npm-release.js
+
     - name: 'Get CLI Token'
       uses: './.github/actions/npm-auth-token'
       id: 'cli-token'

.github/actions/push-sandbox/action.yml

@@ -44,6 +44,8 @@ runs:
     - name: 'npm build'
       shell: 'bash'
       run: 'npm run build'
+    - name: 'Set up QEMU'
+      uses: 'docker/setup-qemu-action@v3'
     - name: 'Set up Docker Buildx'
       uses: 'docker/setup-buildx-action@v3'
     - name: 'Log in to GitHub Container Registry'
@@ -69,16 +71,19 @@ runs:
       env:
         INPUTS_GITHUB_REF_NAME: '${{ inputs.github-ref-name }}'
         INPUTS_GITHUB_SHA: '${{ inputs.github-sha }}'
+    # We build amd64 just so we can verify it.
+    # We build and push both amd64 and arm64 in the publish step.
     - name: 'build'
       id: 'docker_build'
       shell: 'bash'
       env:
         GEMINI_SANDBOX_IMAGE_TAG: '${{ steps.image_tag.outputs.FINAL_TAG }}'
         GEMINI_SANDBOX: 'docker'
+        BUILD_SANDBOX_FLAGS: '--platform linux/amd64 --load'
         STEPS_IMAGE_TAG_OUTPUTS_FINAL_TAG: '${{ steps.image_tag.outputs.FINAL_TAG }}'
       run: |-
         npm run build:sandbox -- \
-          --image google/gemini-cli-sandbox:${STEPS_IMAGE_TAG_OUTPUTS_FINAL_TAG} \
+          --image "google/gemini-cli-sandbox:${STEPS_IMAGE_TAG_OUTPUTS_FINAL_TAG}" \
           --output-file final_image_uri.txt
         echo "uri=$(cat final_image_uri.txt)" >> $GITHUB_OUTPUT
     - name: 'verify'
@@ -92,10 +97,14 @@ runs:
     - name: 'publish'
       shell: 'bash'
       if: "${{ inputs.dry-run != 'true' }}"
-      run: |-
-        docker push "${STEPS_DOCKER_BUILD_OUTPUTS_URI}"
       env:
-        STEPS_DOCKER_BUILD_OUTPUTS_URI: '${{ steps.docker_build.outputs.uri }}'
+        GEMINI_SANDBOX_IMAGE_TAG: '${{ steps.image_tag.outputs.FINAL_TAG }}'
+        GEMINI_SANDBOX: 'docker'
+        BUILD_SANDBOX_FLAGS: '--platform linux/amd64,linux/arm64 --push'
+        STEPS_IMAGE_TAG_OUTPUTS_FINAL_TAG: '${{ steps.image_tag.outputs.FINAL_TAG }}'
+      run: |-
+        npm run build:sandbox -- \
+          --image "google/gemini-cli-sandbox:${STEPS_IMAGE_TAG_OUTPUTS_FINAL_TAG}"
     - name: 'Create issue on failure'
       if: |-
         ${{ failure() }}

.github/workflows/chained_e2e.yml

@@ -264,6 +264,27 @@ jobs:
         run: 'npm run build'
         shell: 'pwsh'
 
+      - name: 'Ensure Chrome is available'
+        shell: 'pwsh'
+        run: |
+          $chromePaths = @(
+            "${env:ProgramFiles}\Google\Chrome\Application\chrome.exe",
+            "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe"
+          )
+          $chromeExists = $chromePaths | Where-Object { Test-Path $_ } | Select-Object -First 1
+          if (-not $chromeExists) {
+            Write-Host 'Chrome not found, installing via Chocolatey...'
+            choco install googlechrome -y --no-progress --ignore-checksums
+          }
+          $installed = $chromePaths | Where-Object { Test-Path $_ } | Select-Object -First 1
+          if ($installed) {
+            Write-Host "Chrome found at: $installed"
+            & $installed --version
+          } else {
+            Write-Error 'Chrome installation failed'
+            exit 1
+          }
+
       - name: 'Run E2E tests'
         env:
           GEMINI_API_KEY: '${{ secrets.GEMINI_API_KEY }}'