From c7c68920d81871a39584ee2642e10af64fae2572 Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 21:01:00 +0100
Subject: [PATCH 01/14] ci: add spam issue detection scripts

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .../scripts/spam-detection/check-issue.sh     |   45 +
 .../workflows/scripts/spam-detection/eval.sh  |   26 +
 .../scripts/spam-detection/generate-prompt.sh |   23 +
 .../spam-detection/generate-sys-prompt.sh     |  126 +
 .../scripts/spam-detection/process-issue.sh   |   31 +
 .../scripts/spam-detection/prompt.yml         | 5087 +++++++++++++++++
 6 files changed, 5338 insertions(+)
 create mode 100755 .github/workflows/scripts/spam-detection/check-issue.sh
 create mode 100755 .github/workflows/scripts/spam-detection/eval.sh
 create mode 100755 .github/workflows/scripts/spam-detection/generate-prompt.sh
 create mode 100755 .github/workflows/scripts/spam-detection/generate-sys-prompt.sh
 create mode 100755 .github/workflows/scripts/spam-detection/process-issue.sh
 create mode 100644 .github/workflows/scripts/spam-detection/prompt.yml

diff --git a/.github/workflows/scripts/spam-detection/check-issue.sh b/.github/workflows/scripts/spam-detection/check-issue.sh
new file mode 100755
index 000000000..d2c60d8fe
--- /dev/null
+++ b/.github/workflows/scripts/spam-detection/check-issue.sh
@@ -0,0 +1,45 @@
+#!/bin/bash
+
+# Check if an issue is spam or not and output "PASS" (not spam) or "FAIL" (spam).
+#
+# Regardless of the spam detection result, the script always exits with a zero
+# exit code, unless there's a runtime error.
+#
+# This script must be run from the root directory of the repository.
+
+set -euo pipefail
+
+_prompt_file=".github/workflows/scripts/spam-detection/prompt.yml"
+_generate_sys_prompt_script=".github/workflows/scripts/spam-detection/generate-sys-prompt.sh"
+_generate_prompt_script=".github/workflows/scripts/spam-detection/generate-prompt.sh"
+
+_issue_url="$1"
+if [[ -z "$_issue_url" ]]; then
+    echo "error: issue URL is empty" >&2
+    exit 1
+fi
+
+_issue="$(gh issue view --json title,body "$_issue_url")"
+
+_issue_body="$(jq -r ".body" <<< "$_issue")"
+_issue_title="$(jq -r ".title" <<< "$_issue")"
+
+_system_prompt="$($_generate_sys_prompt_script)"
+_input_prompt="$($_generate_prompt_script "$_issue_title" "$_issue_body")"
+
+_updated_prompt_file_content="$(
+    cat "$_prompt_file" |
+    yq eval 'del(.testData, .evaluators)' | # drop test data
+    _system="$_system_prompt" _input="$_input_prompt" yq eval ".messages[0].content = strenv(_system) | .messages[1].content = strenv(_input)"
+)"
+
+gh extension install github/gh-models 2>/dev/null
+
+_result="$(gh models run --file <(echo "$_updated_prompt_file_content") | cat)"
+
+if [[ "$_result" != "PASS" && "$_result" != "FAIL" ]]; then
+    echo "error: expected PASS or FAIL but got an unexpected result: $_result" >&2
+    exit 1
+fi
+
+echo "$_result"
diff --git a/.github/workflows/scripts/spam-detection/eval.sh b/.github/workflows/scripts/spam-detection/eval.sh
new file mode 100755
index 000000000..f4a5dc0f7
--- /dev/null
+++ b/.github/workflows/scripts/spam-detection/eval.sh
@@ -0,0 +1,26 @@
+#!/bin/bash
+
+# Run the eval tests for the spam detection AI model.
+#
+# This script must be run from the root directory of the repository.
+
+set -euo pipefail
+
+_prompt_file=".github/workflows/scripts/spam-detection/prompt.yml"
+_generate_sys_prompt_script=".github/workflows/scripts/spam-detection/generate-sys-prompt.sh"
+
+_system_prompt="$($_generate_sys_prompt_script)"
+_updated_prompt_file="$(_value="$_system_prompt" yq eval '.messages[0].content = strenv(_value)' "$_prompt_file")"
+
+# We should be able to just run the following command:
+#
+# ```
+# gh models eval <(echo "$_updated_prompt_file")
+# ```
+#
+# But since `gh-models` does not throttle the rate of API requests, we need to
+# modify the extension code and introduce a deliberate delay between the runs.
+# Here, we assume a binary of the `gh-models` extension (with appropriate
+# throttling) is available in the root directory of the repository and we're
+# calling it directly (not though `gh`).
+./gh-models eval <(echo "$_updated_prompt_file")
diff --git a/.github/workflows/scripts/spam-detection/generate-prompt.sh b/.github/workflows/scripts/spam-detection/generate-prompt.sh
new file mode 100755
index 000000000..9437bf751
--- /dev/null
+++ b/.github/workflows/scripts/spam-detection/generate-prompt.sh
@@ -0,0 +1,23 @@
+#!/bin/bash
+
+# Generate the prompt for the spam detection AI model. The issue title and body
+# should be provided as arguments.
+#
+# This script must be run from the root directory of the repository.
+
+set -euo pipefail
+
+_issue_title="$1"
+_issue_body="$2"
+
+_prompt="
+<TITLE>
+$_issue_title
+</TITLE>
+
+<BODY>
+$_issue_body
+</BODY>
+"
+
+echo "$_prompt"
diff --git a/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh b/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
new file mode 100755
index 000000000..76c104946
--- /dev/null
+++ b/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
@@ -0,0 +1,126 @@
+#!/bin/bash
+
+# Generate the system prompt for the spam detection AI model.
+#
+# This script must be run from the root directory of the repository.
+
+set -euo pipefail
+
+_system_prompt='
+# Your role
+
+You are a spam detection AI who helps identify spam issues submitted to the GitHub CLI repository.
+
+Note that:
+- More context about the GitHub CLI project is provided in section "Context" below.
+- Criteria for spam issues are provided in section "Spam content indicators" below.
+- Criteria for legitimate issues are provided in section "Legitimate content indicators" below.
+
+With every prompt you are given the title and a body of a GitHub issue. Your task is to determine if the issue is spam
+or not.
+
+Prompts will be formatted as follows, where the title and body of an issue are surrounded by `<TITLE>` and `<BODY>` tags:
+
+```
+<TITLE>
+[issue title goes here]
+</TITLE>
+
+<BODY>
+[issue body goes here]
+</BODY>
+```
+
+Your response must be single word `FAIL` if the issue looks like a spam, and `PASS` otherwise.
+
+## Context
+
+The GitHub CLI (also known as `gh`) project is a command-line tool for GitHub. It provides many commands to interact
+with various GitHub features.
+
+You can find a the general docs of the GitHub CLI tool in section "GitHub CLI docs" below, which helps you understand
+the available commands and their usages.
+
+## Legitimate content indicators
+
+- Clear description of a bug with steps to reproduce.
+- Feature requests with detailed explanations and use cases.
+- Documentation improvements with specific suggestions.
+- Questions about usage with context and examples.
+- Reports that reference specific code, files, or functionality.
+
+## Spam content indicators
+
+Here are the common patterns of spam issues:
+
+- A body that is a copy, or a small variation, of one of the issue templates defined under the "Issue templates" section below.
+  - When comparing with a template, you should ignore the headings and commented lines enclosed in `<!--`-`-->` tags, and
+    focus on the content.
+- Unrelated body and title that do not provide any useful information about the issue.
+- An empty issue body.
+- A body that contains only a single word or a few words, such as "bug", "help", "issue", "problem".
+- A meaningless body that does not provide any useful information about the issue.
+- A body that is just one or more links without any context or explanation.
+- Generic placeholder text like "Lorem ipsum" or "test test test".
+- Repetitive content (same word/phrase repeated multiple times).
+- Content that appears to be copied from other sources without relevance to the project.
+- Promotional content, advertisements, or unrelated marketing material.
+- Content in languages that seem inappropriate for the project context.
+- Issues that don''t relate to the project''s purpose (e.g. personal messages, off-topic discussions).
+- Content that seems like to be taken from, or quoting, another discussion or issue which does not not establish a sensible
+  context, or problem statement, or feedback.
+
+'
+
+# Append the help output for the root `gh` command
+_system_prompt="${_system_prompt}
+
+## GitHub CLI docs
+
+The GitHub CLI tool has many commands, below is a piece of the help output, surrounded with \`<GitHub CLI docs>\` tags,
+for the root \`gh\` command.
+
+<GitHub CLI docs>
+\`\`\`
+$(gh --help)
+\`\`\`
+</GitHub CLI docs>
+"
+
+# Append the issue templates to the system prompt.
+_system_prompt="${_system_prompt}
+
+## Issue templates
+
+Here are the issue templates already defined in the project. The templates are surrounded with \`<Template N>\` tags and
+triple backticks, where N is the template number. The templates are provided to help you understand the common patterns
+of issues.
+
+"
+
+_template_index=1
+for template_file in .github/ISSUE_TEMPLATE/*.md; do
+    if ! [[ -f "$template_file" ]]; then
+        continue
+    fi
+
+    _template_content="$(cat "$template_file")"
+
+    # Remove YAML front matter (everything between the first two --- lines)
+    _template_content="$(echo "$_template_content" | sed '1,/^---$/d; /^---$/,$d')"
+    _escaped_template="$(sed -e 's/^```/\\```/g' <<< "$_template_content" )"
+
+    _system_prompt="${_system_prompt}
+
+<Template ${_template_index}>
+
+\`\`\`
+${_escaped_template}
+\`\`\`
+</Template ${_template_index}>
+"
+
+    ((_template_index++))
+done
+
+echo "$_system_prompt"
diff --git a/.github/workflows/scripts/spam-detection/process-issue.sh b/.github/workflows/scripts/spam-detection/process-issue.sh
new file mode 100755
index 000000000..f64aee31c
--- /dev/null
+++ b/.github/workflows/scripts/spam-detection/process-issue.sh
@@ -0,0 +1,31 @@
+#!/bin/bash
+
+# Performs spam detection on an issue and labels if if it's spam.
+#
+# Regardless of the spam detection result, the script always exits with a zero
+# exit code, unless there's a runtime error.
+#
+# This script must be run from the root directory of the repository.
+
+set -euo pipefail
+
+_issue_url="$1"
+if [[ -z "$_issue_url" ]]; then
+    echo "error: issue URL is empty" >&2
+    exit 1
+fi
+
+_suspected_spam_label="suspected-spam"
+_check_issue_script=".github/workflows/scripts/spam-detection/check-issue.sh"
+
+_result="$($_check_issue_script "$_issue_url")"
+
+if [[ "$_result" == "PASS" ]]; then
+    exit 0
+fi
+
+echo "spam issue detected: $_issue_url"
+
+gh issue edit --add-label "$_suspected_spam_label" "$_issue_url"
+
+echo "issue labelled as suspected spam"
diff --git a/.github/workflows/scripts/spam-detection/prompt.yml b/.github/workflows/scripts/spam-detection/prompt.yml
new file mode 100644
index 000000000..2b6f0c738
--- /dev/null
+++ b/.github/workflows/scripts/spam-detection/prompt.yml
@@ -0,0 +1,5087 @@
+name: Evaluate spam detection
+model: openai/gpt-4o-mini
+messages:
+  - role: system
+    content: "" # Since it's not a fix value, it should be generated and replaced at runtime
+  - role: user
+    content: "{{input}}"
+evaluators:
+  - name: assert response
+    string:
+      equals: "{{expected}}"
+testData:
+  - name: not-spam, staff issue
+    expected: PASS
+    input: |
+      <TITLE>
+      Automatically update third party licenses during Dependabot PRs
+      </TITLE>
+
+      <BODY>
+      ## Overview
+
+      With `cli/cli` lint process erring if 3rd party license information is not updated in https://github.com/cli/cli/pull/11047, Dependabot PRs will require maintainers to manually run `make licenses`.
+
+      Recently, @williammartin opened https://github.com/cli/cli/pull/11269 with the [`script/fix-dependabot-licenses.sh`](https://github.com/cli/cli/blob/26d70bfb7bcc0b41dbdd50bfc51f827f1a5ad4c4/script/fix-dependabot-licenses.sh) script for maintainers to run that will find all Dependabot PRs and attempt to fix them where the lint workflow failed.  This script is a manual repair effort, however it is possible to [use a GitHub Actions workflow to run the `make license` script for Dependabot PRs](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions):
+
+      > ```yaml
+      > name: Dependabot fetch metadata
+      > on: pull_request
+      > 
+      > permissions:
+      >   pull-requests: write
+      >   issues: write
+      > 
+      > jobs:
+      >   dependabot:
+      >     runs-on: ubuntu-latest
+      >     if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
+      >     steps:
+      >       - name: Dependabot metadata
+      >         id: metadata
+      >         uses: dependabot/fetch-metadata@d7267f607e9d3fb96fc2fbe83e0af444713e90b7
+      >         with:
+      >           github-token: "${{ secrets.GITHUB_TOKEN }}"
+      >       # The following properties are now available:
+      >       #  - steps.metadata.outputs.dependency-names
+      >       #  - steps.metadata.outputs.dependency-type
+      >       #  - steps.metadata.outputs.update-type
+      > ```
+
+      This issue is aimed at implementing GitHub Actions workflow changes that will automatically update `third-party` license source code and `third-party-*.md` reports, eliminating the need for maintainers to manually repair Dependabot PRs.
+
+      > [!NOTE]
+      > To download the `script/fix-dependabot-licenses.sh` script, run the following command:
+      > ```shell
+      > curl -o fix-dependabot-licenses.sh https://raw.githubusercontent.com/cli/cli/26d70bfb7bcc0b41dbdd50bfc51f827f1a5ad4c4/script/fix-dependabot-licenses.sh
+      > ```
+      >
+      > Or checkout the original PR:
+      >
+      > ```shell
+      > gh pr checkout https://github.com/cli/cli/pull/11269
+      > ```
+
+      ## Expected outcomes
+
+      - When Dependabot PRs are opened, automation attempts to regenerate and commit updated license information via `make licenses`
+      - When Dependabot PRs are updated, status checks pass without maintainer action outside of reviewing PR
+          - name: not-spam, template-based
+          spam: true
+          title: |
+              Incorrect check summary with v2.45 and v2.75
+          body: |
+              ### Describe the bug
+
+              I got below confusing reports with v2.45 CLI on Ubuntu 22.04:
+
+              ```sh
+              $ gh pr status
+
+              Relevant pull requests in micropython/micropython
+              ...
+              Created by you
+              #17660  tests/extmod: Close UDP timely. [yf13:pull-udp-close]
+              ✓ Checks passing
+              #17638  unix/make: Drop i686-linux-gnu path. [yf13:pull-drop-i686-linux-gnu]
+              × 1/94 checks failing
+              $ gh pr checks 17638
+              All checks were successful
+              0 cancelled, 0 failing, 48 successful, 0 skipped, and 0 pending checks
+              ```
+              I downloaded latest v2.75 CLI but it is the same.
+
+              Meanwhile. from browser UI it seems checks passed.
+
+              ### Affected version
+
+              Please run `gh version` and paste the output below.
+
+              ```
+              $ gh version
+              gh version 2.75.0 (2025-07-09)
+              https://github.com/cli/cli/releases/tag/v2.75.0
+              ```
+
+              ### Steps to reproduce the behavior
+
+              see above descriptions.
+
+              ### Expected vs actual behavior
+
+              A clear and concise description of what you expected to happen and what actually happened.
+
+              ### Logs
+
+              Paste the activity from your command line. Redact if needed.
+
+              <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+
+      </BODY>
+  - name: not-spam, short/focused
+    expected: PASS
+    input: |
+      <TITLE>
+      Include `isImmutable` in `release list`
+      </TITLE>
+
+      <BODY>
+      Update the list of available JSON fields in the `release list` command to include `isImmutable` flag.
+
+      This boolean flag indicates whether a particular release has been marked as immutable.
+      </BODY>
+  - name: spam, two words
+    expected: FAIL
+    input: |
+      <TITLE>
+      Aliya Janell
+      </TITLE>
+
+      <BODY>
+      Account
+      </BODY>
+  - name: spam, a hyperlink
+    expected: FAIL
+    input: | # this is a legit title to focus the model on the body
+      <TITLE>
+      Bug in authentication on multiple GitHub hosts
+      </TITLE>
+
+      <BODY>
+      [File-host-2025-07-04.pdf](https://github.com/user-attachments/files/12345678/File-2025-07-04.pdf)
+      </BODY>
+  - name: spam, template copy with title in a different language
+    expected: FAIL
+    input: |
+      <TITLE>
+      Phiên bản cập nhật
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      A clear and concise description of what the bug is. 
+
+      ### Affected version
+
+      Please run `gh version` and paste the output below.
+
+      ### Steps to reproduce the behavior
+
+      1. Type this '...'
+      2. View the output '....'
+      3. See error
+
+      ### Expected vs actual behavior
+
+      A clear and concise description of what you expected to happen and what actually happened.
+
+      ### Logs
+
+      Paste the activity from your command line. Redact if needed.
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+
+      </BODY>
+  - name: spam, template copy (bug report)
+    expected: FAIL
+    input: | # this is a legit title to focus the model on the body
+      <TITLE>
+      Bug in authentication on multiple GitHub hosts
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      A clear and concise description of what the bug is. 
+
+      ### Affected version
+
+      Please run `gh version` and paste the output below.
+
+      ### Steps to reproduce the behavior
+
+      1. Type this '...'
+      2. View the output '....'
+      3. See error
+
+      ### Expected vs actual behavior
+
+      A clear and concise description of what you expected to happen and what actually happened.
+
+      ### Logs
+
+      Paste the activity from your command line. Redact if needed.
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+
+      </BODY>
+  - name: spam, quoting a valid comment
+    expected: FAIL
+    input: |
+      <TITLE>
+      ❯ gh release list --json notes Unknown JSON field: "notes" Available fields:   createdAt   isDraft   isLatest   isPrerelease   name   publishedAt   tagName
+      </TITLE>
+
+      <BODY>
+      > Thanks for submitting this, @brettdh! 🙏 
+      > 
+      > Currently, this is similar to the GraphQL API request that `gh` uses to fetch the list of releases:
+      > 
+      > ```gql
+      > query {
+      >   repository(owner:"cli", name:"cli") {
+      >     name
+      >     releases(first: 2) {
+      >       nodes {
+      >         name
+      >         tagName
+      >         isDraft
+      >         isLatest
+      >         isPrerelease
+      >         createdAt
+      >         publishedAt
+      >       }
+      >     }
+      >   }
+      > }
+      > ```
+      > 
+      > You can simply try it on [GraphQL Explorer](https://docs.github.com/en/graphql/overview/explorer).
+      > 
+      > There's a bit of terminology difference here, but I think what you're referring to as *notes* is actually the `description` field on a `Release` type. Can you please confirm that's what you're asking for? You can try adding `description` to the list of fields in the above query and see if that fits your purpose.
+      > 
+      >  
+
+      _Originally posted by @babakks in [#11241](https://github.com/cli/cli/issues/11241#issuecomment-3049268353)_
+      </BODY>
+  - name: spam, legible nonsense
+    expected: FAIL
+    input: |
+      <TITLE>
+      Found a bug
+      </TITLE>
+
+      <BODY>
+      ###I believe there might be a bug or just looking for work jobid 
+
+      Maybe theirs problem in the with log fails
+
+      ###  I'm going to pill and put a "branch" what a namespace and use cli/cli
+
+      How will it benefit CLI and its users?
+
+      ### Additional context
+
+      Add any other context like screenshots or mockups are helpful, if applicable.
+      </BODY>
+  - name: spam, template copy (submit a request)
+    expected: FAIL
+    input: |-  # this is a legit title to focus the model on the body
+      <TITLE>
+      Bug in authentication flow
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      A clear and concise description of what the feature or problem is.
+
+      ### Proposed solution
+
+      How will it benefit CLI and its users?
+
+      ### Additional context
+
+      Add any other context like screenshots or mockups are helpful, if applicable.
+      </BODY>
+  - name: 'spam, legit but too general #10368 (https://github.com/cli/cli/issues/10368)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Instructions in install_linux.md do not result in installation
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      Bug: the instructions meant to install gh instead don't install gh.
+
+      ### Affected version
+
+      Latest
+
+      ### Steps to reproduce the behavior
+
+      Follow instructions in install_linux.md
+
+      ### Expected vs actual behavior
+
+      Expect: gh is installed and can be used.
+
+      ### Logs
+
+      A bunch of errors
+      </BODY>
+  - name: 'spam, #11304 (https://github.com/cli/cli/issues/11304)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Z ENT
+      </TITLE>
+
+      <BODY>
+      Our companies name put
+      </BODY>
+  - name: 'spam, #11242 (https://github.com/cli/cli/issues/11242)'
+    expected: FAIL
+    input: "<TITLE>\nAliya Janell\n</TITLE>\n\n<BODY>\nAccount login \n</BODY>"
+  - name: 'spam, #11230 (https://github.com/cli/cli/issues/11230)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Brew install
+      </TITLE>
+
+      <BODY>
+
+      </BODY>
+  - name: 'spam, #11223 (https://github.com/cli/cli/issues/11223)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      my files on sannathistreetWLC
+      </TITLE>
+
+      <BODY>
+      [Schematic_SannthiStreet-WLC_2025-07-04.pdf](https://github.com/user-attachments/files/21049802/Schematic_SannthiStreet-WLC_2025-07-04.pdf)
+      </BODY>
+  - name: 'spam, #11222 (https://github.com/cli/cli/issues/11222)'
+    expected: FAIL
+    input: "<TITLE>\n[indexx.md](https://github.com/user-attachments/files/21049107/indexx.md)\n</TITLE>\n\n<BODY>\n[indexx.md](https://github.com/user-attachments/files/21049107/indexx.md)\r\n\r\n- [ ]\r\n\r\n_Originally posted by @Minhaj2232 in https://github.com/cli/cli/discussions/11221_\n</BODY>"
+  - name: 'spam, template copy (feedback)'
+    expected: FAIL
+    input: |-  # this is a legit title to focus the model on the body
+      <TITLE>
+      Bug in authentication flow
+      </TITLE>
+
+      <BODY>
+      # CLI Feedback
+
+      You can use this template to give us structured feedback or just wipe it and leave us a note. Thank you!
+
+      ## What have you loved?
+
+      _eg "the nice colors"_
+
+      ## What was confusing or gave you pause?
+
+      _eg "it did something unexpected"_
+
+      ## Are there features you'd like to see added?
+
+      _eg "gh cli needs mini-games"_
+
+      ## Anything else?
+
+      _eg "have a nice day"_
+      </BODY>
+  - name: 'spam, #11199 (https://github.com/cli/cli/issues/11199)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Hyjiu
+      </TITLE>
+
+      <BODY>
+      - [- [ ] [`Hhhhjhgfhh__`](url)]([url](url))
+      </BODY>
+  - name: 'spam, #11198 (https://github.com/cli/cli/issues/11198)'
+    expected: FAIL
+    input: "<TITLE>\nFhgk\n</TITLE>\n\n<BODY>\n> \n\n- [ ] \n\n[ ] Duplicate of #11180 `[](url)`\n\n> \n\n> ``Frf****`[](url)[](url)`\n</BODY>"
+  - name: 'spam, #11114 (https://github.com/cli/cli/issues/11114)'
+    expected: FAIL
+    input: "<TITLE>\nFound a bug\n</TITLE>\n\n<BODY>\n###I believe there might be a bug or just looking for work jobid \n\nMaybe theirs problem in the with log fails\n\n###  I'm going to pill and put a \"branch\" what a namespace and use cli/cli\n\nHow will it benefit CLI and its users?\n\n### Additional context\n\nAdd any other context like screenshots or mockups are helpful, if applicable.\n</BODY>"
+  - name: 'spam, #11016 (https://github.com/cli/cli/issues/11016)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      idokoizuc@gmail.co
+      </TITLE>
+
+      <BODY>
+      Trading app to start a business into it can you create it for me please the best that you can
+      </BODY>
+  - name: 'spam, #11014 (https://github.com/cli/cli/issues/11014)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Gh
+      </TITLE>
+
+      <BODY>
+
+      </BODY>
+  - name: 'spam, #10933 (https://github.com/cli/cli/issues/10933)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      C.2.22.f31.0
+      </TITLE>
+
+      <BODY>
+      ![Image](https://github.com/user-attachments/assets/0c4561c5-70b2-4163-a7b9-b3e539f3bd18)
+      https://github.com/cli/cli/blame/f85cf1daf528d177da1f45bd177bc5dc1d84cec2/acceptance/testdata/pr/pr-view-status-respects-branch-pushremote.txtar#L36
+      </BODY>
+  - name: 'spam, #10923 (https://github.com/cli/cli/issues/10923)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Delete clones
+      </TITLE>
+
+      <BODY>
+      ![Image](https://github.com/user-attachments/assets/02694e0d-6c09-4da9-bf86-697ae7fb9e6a)
+
+      ### Describe the feature or problem you’d like to solve
+
+      A clear and concise description of what the feature or problem is.
+
+      ### Proposed solution
+
+      How will it benefit CLI and its users?
+
+      ### Additional context
+
+      Add any other context like screenshots or mockups are helpful, if applicable.
+      </BODY>
+  - name: 'spam, #10866 (https://github.com/cli/cli/issues/10866)'
+    expected: FAIL
+    input: "<TITLE>\nI see no option. What is the default model being used?\n</TITLE>\n\n<BODY>\nI see no option. What is the default model being used?\r\n\r\n_Originally posted by @BrajBliss in https://github.com/cli/cli/discussions/10809_\n</BODY>"
+  - name: 'spam, #10854 (https://github.com/cli/cli/issues/10854)'
+    expected: FAIL
+    input: "<TITLE>\nKamil Yalçın\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nA clear and concise descript\nion of what the bug is. \n\n### Affected version\n\nPlease run `gh version` and paste the output below.\n\n### Steps to reproduce the behavior\n\n1. Type this '...'\n2. View the output '....'\n3. See error\n\n### Expected vs actual behavior\n\nA clear and concise description of what you expected to happen and what actually happened.\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\n</BODY>"
+  - name: 'spam, #10844 (https://github.com/cli/cli/issues/10844)'
+    expected: FAIL
+    input: "<TITLE>\nРешение\U0001F4AA\U0001F604\U0001F44C\n</TITLE>\n\n<BODY>\n<!-- See [CONTRIBUTING.md](../CONTRIBUTING.md#pgh pr checkout 38273roposing-a-design) for more information.-->\n\n### Link to issue for design submission\n\n<!-- \nProvide a link to the issue this design is for.\n\nAll design submissions must be linked to an open issue that\nhas both the `needs-design` and `help-wanted` labels.\n-->\n\n### Proposed Design\n\n<!--\nDescribe the design you are proposing to resolve the issue.\n\nAll CLI designs must adhere to the [Primer CLI design reference](https://primer.style/cli/).\n-->\n\n### Mockup\n\n<!--\nProvide a mockup of the design you are proposing. All mockups should clearly illustrate the command(s) being run and the expected output(s). \n\nWhen color and formatting are important, consider using our [CLI design Google Docs Template](https://docs.google.com/document/d/1JIRErIUuJ6fTgabiFYfCH3x91pyHuytbfa0QLnTfXKM/edit#heading=h.or54sa47ylpg).\n\nCode blocks can also be used to submit a design mockup - remember to include the command(s) being run. Example:\n\n```shell\n$ gh issue list --json title -L 5\n[\n  {\n    \"title\": \"`gh pr checks <pr> --required` should not fail when there are no required checks\"\n  },\n  {\n    \"title\": \"gh pr view commits should include commit description\"\n  },\n  {\n    \"title\": \"Adapt the color of the device code to the color used by the terminal\"\n  },\n  {\n    \"title\": \"`gh pr create` does not default to fork when user has write access to upstream\"\n  },\n  {\n    \"title\": \"First party discussions support\"\n  }\n]\n```\n-->\n</BODY>"
+  - name: 'spam, #10827 (https://github.com/cli/cli/issues/10827)'
+    expected: FAIL
+    input: "<TITLE>\nCli\n</TITLE>\n\n<BODY>\n> @samcoe You're right, `GLAMOUR_STYLE` does indeed work for `gh repo view`.\r> \n> \r> \n> Having said that I agree that the output you are seeing is quite low contrast. We just introduced the table headers so perhaps we need to pick a different color to use there. Are you using one of the default color schemes in the terminal app? Or is this a color scheme you found/created?\r> \n> \r> \n> It's the unmodified builtin \"Basic\" theme (though it's possible the theme settings were carried over from an earlier macOS version and the theme now looks different in a fresh Sonoma install). \n\n _Originally posted by @jwodder in [#8292](https://github.com/cli/cli/issues/8292#issuecomment-1794607298)_\n</BODY>"
+  - name: 'spam, #10826 (https://github.com/cli/cli/issues/10826)'
+    expected: FAIL
+    input: "<TITLE>\nCli\n</TITLE>\n\n<BODY>\n> @samcoe You're right, `GLAMOUR_STYLE` does indeed work for `gh repo view`.\r> \n> \r> \n> Having said that I agree that the output you are seeing is quite low contrast. We just introduced the table headers so perhaps we need to pick a different color to use there. Are you using one of the default color schemes in the terminal app? Or is this a color scheme you found/created?\r> \n> \r> \n> It's the unmodified builtin \"Basic\" theme (though it's possible the theme settings were carried over from an earlier macOS version and the theme now looks different in a fresh Sonoma install). \n\n _Originally posted by @jwodder in [#8292](https://github.com/cli/cli/issues/8292#issuecomment-1794607298)_\n</BODY>"
+  - name: 'spam, #10765 (https://github.com/cli/cli/issues/10765)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Title
+      </TITLE>
+
+      <BODY>
+      Type your description here..
+      </BODY>
+  - name: 'spam, #10735 (https://github.com/cli/cli/issues/10735)'
+    expected: FAIL
+    input: "<TITLE>\nBug\n</TITLE>\n\n<BODY>\n<!-- See [CONTRIBUTING.md](../CONTRIBUTING.md#proposing-a-design) for more information.-->\n\n### Link to issue for design submission\n\n<!-- \nProvide a link to the issue this design is for.\n\nAll design submissions must be linked to an open issue that\nhas both the `needs-design` and `help-wanted` labels.\n-->\n\n### Proposed Design\n\n<!--\nDescribe the design you are proposing to resolve the issue.\n\nAll CLI designs must adhere to the [Primer CLI design reference](https://primer.style/cli/).\n-->\n\n### Mockup\n\n<!--\nProvide a mockup of the design you are proposing. All mockups should clearly illustrate the command(s) being run and the expected output(s). \n\nWhen color and formatting are important, consider using our [CLI design Google Docs Template](https://docs.google.com/document/d/1JIRErIUuJ6fTgabiFYfCH3x91pyHuytbfa0QLnTfXKM/edit#heading=h.or54sa47ylpg).\n\nCode blocks can also be used to submit a design mockup - remember to include the command(s) being run. Example:\n\n```shell\n$ gh issue list --json title -L 5\n[\n  {\n    \"title\": \"`gh pr checks <pr> --required` should not fail when there are no required checks\"\n  },\n  {\n    \"title\": \"gh pr view commits should include commit description\"\n  },\n  {\n    \"title\": \"Adapt the color of the device code to the color used by the terminal\"\n  },\n  {\n    \"title\": \"`gh pr create` does not default to fork when user has write access to upstream\"\n  },\n  {\n    \"title\": \"First party discussions support\"\n  }\n]\n```\n--\n\n![Image](https://github.com/user-attachments/assets/969643bf-ed1a-464a-a59f-6ee04633559e)\n</BODY>"
+  - name: 'spam, #10724 (https://github.com/cli/cli/issues/10724)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Divident
+      </TITLE>
+
+      <BODY>
+
+
+      ### Describe the feature or problem you’d like to solve
+
+      A clear and concise description of what the feature or problem is.
+
+      ### Proposed solution
+
+      How will it benefit CLI and its users?
+
+      ### Additional context
+
+      Add any other context like screenshots or mockups are helpful, if applicable.
+      </BODY>
+  - name: 'spam, #10723 (https://github.com/cli/cli/issues/10723)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Priscila furtado leite desbloquear minha conta já foi desbloqueado
+      </TITLE>
+
+      <BODY>
+      Uai os brotou minha conta do nada por outra por causa que os outros me roubou falei para ele brotou minha conta
+      </BODY>
+  - name: 'spam, #10700 (https://github.com/cli/cli/issues/10700)'
+    expected: FAIL
+    input: "<TITLE>\nknoands@gmail.com\n</TITLE>\n\n<BODY>\n> Note that an earlier version of the instructions used the location `/usr/share/keyrings` instead of `/etc/apt/keyrings` in the `sources.list.d` file, so I had to update that to make it work with the above update instructions, and remove the old keyring file from `/usr/share/keyrings`.\r> \n> \r> \n> Alternatively, one could of course download the updated key to `/usr/share/keyrings`, but we don't really want to pollute `/usr` with non-packaged files! \n\n _Originally posted by @rrthomas in [#9569](https://github.com/cli/cli/issues/9569#issuecomment-2333981674)_\n</BODY>"
+  - name: 'spam, #10697 (https://github.com/cli/cli/issues/10697)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      https://community.home-assistant.io/t/greetings/870794?u=sentrycode
+      </TITLE>
+
+      <BODY>
+      https://community.home-assistant.io/t/greetings/870794?u=sentrycode
+      </BODY>
+  - name: 'spam, #10675 (https://github.com/cli/cli/issues/10675)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Coinbase
+      </TITLE>
+
+      <BODY>
+      https://www.coinbase.com/setup/onboarding-guidance
+      </BODY>
+  - name: 'spam, #10666 (https://github.com/cli/cli/issues/10666)'
+    expected: FAIL
+    input: "<TITLE>\n/Lo\n</TITLE>\n\n<BODY>\n> Yes.  On Windows, a credential with id `gh:github.com` is created by `gh auth login` in the system credentials manager.  When answering the prompt with `yes` additionally it will create a `git:https://github.com` credential in the credential helper.  This is the missing piece.\n> \n> However, I was unaware of `gh auth setup-git`.  This does indeed provide the missing piece. \n\n _Originally posted by @kristjanvalur in [#10658](https://github.com/cli/cli/issues/10658#issuecomment-2747897081)_\n</BODY>"
+  - name: 'spam, #10655 (https://github.com/cli/cli/issues/10655)'
+    expected: FAIL
+    input: "<TITLE>\n```powershell\n</TITLE>\n\n<BODY>\n              ```powershell\r\n\r\n```\r\n\r\n_Originally posted by @sukuna119 in https://github.com/cli/cli/issues/10654#issuecomment-2746100807_\r\n            \n</BODY>"
+  - name: 'spam, #10647 (https://github.com/cli/cli/issues/10647)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      dt
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      A clear and concise description of what the feature or problem is.
+
+      ### Proposed solution
+
+      How will it benefit CLI and its users?
+
+      ### Additional context
+
+      Add any other context like screenshots or mockups are helpful, if applicable.
+      [](url)
+      </BODY>
+  - name: 'spam, #10634 (https://github.com/cli/cli/issues/10634)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Fix magic8.py error
+      </TITLE>
+
+      <BODY>
+      The code for magic8.py uses the Python random library without importing it. This causes issues during runtime.
+      </BODY>
+  - name: 'spam, #10631 (https://github.com/cli/cli/issues/10631)'
+    expected: FAIL
+    input: "<TITLE>\nKlh\n</TITLE>\n\n<BODY>\n> `` \n\n _Originally posted by @Infinnet in [#9139](https://github.com/cli/cli/issues/9139#issuecomment-2225951245)_\n</BODY>"
+  - name: 'spam, #10581 (https://github.com/cli/cli/issues/10581)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Typescript Spec / standard spec
+      </TITLE>
+
+      <BODY>
+      One of the things thats been mentioned before in the community rewrites is that Typescript has no working working specs/standard. It makes rewriting in community harder.
+
+      With typescript now being ported to go ("native"). Can we start saying a language spec / standard rather than just a huge implementation?
+      </BODY>
+  - name: 'spam, #10571 (https://github.com/cli/cli/issues/10571)'
+    expected: FAIL
+    input: "<TITLE>\nRevision request for policy review\n</TITLE>\n\n<BODY>\n> `review Anti-trust and Zero-trust compliance and recovery policy options for SEP (Stakeholder Enterprise Portal). \r> \n> Introduction to accelerated entrepreneurs ` \n\n _Originally posted by @chrisspradling1980 in [fee7adf](https://github.com/cli/cli/commit/fee7adf9baf426bc2a4ea19ad253dc3125159dc3#r153479657)_\n</BODY>"
+  - name: 'spam, #10564 (https://github.com/cli/cli/issues/10564)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Tv
+      </TITLE>
+
+      <BODY>
+
+      </BODY>
+  - name: 'spam, #10542 (https://github.com/cli/cli/issues/10542)'
+    expected: FAIL
+    input: "<TITLE>\ncementing supervisor\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nA clear and concise description of what the bug is. \n\n### Affected version\n\nPlease run `gh version` and paste the output below.\n\n### Steps to reproduce the behavior\n\n1. Type this '...'\n2. View the output '....'\n3. See error\n\n### Expected vs actual behavior\n\nA clear and concise description of what you expected to happen and what actually happened.\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\n\n[P237317.json](https://github.com/user-attachments/files/19079462/P237317.json)\n</BODY>"
+  - name: 'spam, #10524 (https://github.com/cli/cli/issues/10524)'
+    expected: FAIL
+    input: "<TITLE>\nPhoneInfoga #3\n</TITLE>\n\n<BODY>\nhttps://github.com/Billyum50/RealTime-PhoneNumberLocation/actions \n</BODY>"
+  - name: 'spam, #10523 (https://github.com/cli/cli/issues/10523)'
+    expected: FAIL
+    input: "<TITLE>\nPhoneInfoga/learning \n</TITLE>\n\n<BODY>\nhttps://github.com/Billyum50/PhoneInfoga/blob/master/README.md\n</BODY>"
+  - name: 'spam, #10506 (https://github.com/cli/cli/issues/10506)'
+    expected: FAIL
+    input: "<TITLE>\ns\n</TITLE>\n\n<BODY>\n> s \n\n _Originally posted by @labubunews in [0268d95](https://github.com/cli/cli/commit/0268d95f561a1e225ed19b381be9c37c635cbf11#r153006793)_\n</BODY>"
+  - name: 'spam, #10470 (https://github.com/cli/cli/issues/10470)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Erick Reyes González
+      </TITLE>
+
+      <BODY>
+      [#](
+
+      [open_cv_license.pdf](https://github.com/user-attachments/files/18878966/open_cv_license.pdf)
+
+      #10384 url) CLI Feedback
+
+      You can use this template to give us structured feedback or just wipe it and leave us a note. Thank you!
+
+      ## What have you loved?
+
+      _eg "the nice colors"_
+
+      ## What was confusing or gave you pause?
+
+      _eg "it did something unexpected"_
+
+      ## Are there features you'd like to see added?
+
+      _eg "gh cli needs mini-games"_
+
+      ## Anything else?
+
+      _eg "have a nice day"_
+      </BODY>
+  - name: 'spam, #10455 (https://github.com/cli/cli/issues/10455)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Изменить понимания о ценностях.
+      </TITLE>
+
+      <BODY>
+      Каждый человек но этой земле индивидуален нету ни талантливых людей на земле каждый человек талантлив по-своему видя то что происходит сейчас на земле то что дети рождаются инвалидами Но от этих детей рождаются другие дети и у них уже другой ген а так все люди абсолютно каждый человек на земле индивидуален талантлив поэтому мне кажется надо разбить ценности которые сейчас создал нам мир эти все корпорации травящие нас алкоголь всё это наркотики страшно это дело надо менять ценности когда мы поменяем ценности и будем взаимодействовать с другими более эффективными средствами для связи с тем что происходит сейчас в вселенной. Это рабство на земле я не знаю где нам жить чтобы не было такого чтобы всё было для человека медицина ну как так когда у людей много денег и одному ребенку требуется один укол чтобы сделать из него счастливой.
+      </BODY>
+  - name: 'spam, #10450 (https://github.com/cli/cli/issues/10450)'
+    expected: FAIL
+    input: "<TITLE>\nimanuelimanuel600@gmail.com\n</TITLE>\n\n<BODY>\n<!-- See [CONTRIBUTING.md](../CONTRIBUTING.md#proposing-a-design) for more information.-->\n\n### Link to issue for design submission\n\n<!-- \nProvide a link to the issue this design is for.\n\nAll design submissions must be linked to an open issue that\nhas both the `needs-design` and `help-wanted` labels.\n-->\n\n### Proposed Design\n\n<!--\nDescribe the design you are proposing to resolve the issue.\n\nAll CLI designs must adhere to the [Primer CLI design reference](https://primer.style/cli/).\n-->\n\n### Mockup\n\n<!--\nProvide a mockup of the design you are proposing. All mockups should clearly illustrate the command(s) being run and the expected output(s). \n\nWhen color and formatting are important, consider using our [CLI design Google Docs Template](https://docs.google.com/document/d/1JIRErIUuJ6fTgabiFYfCH3x91pyHuytbfa0QLnTfXKM/edit#heading=h.or54sa47ylpg).\n\nCode blocks can also be used to submit a design mockup - remember to include the command(s) being run. Example:\n\n```shell\n$ gh issue list --json title -L 5\n[\n  {\n    \"title\": \"`gh pr checks <pr> --required` should not fail when there are no required checks\"\n  },\n  {\n    \"title\": \"gh pr view commits should include commit description\"\n  },\n  {\n    \"title\": \"Adapt the color of the device code to the color used by the terminal\"\n  },\n  {\n    \"title\": \"`gh pr create` does not default to fork when user has write access to upstream\"\n  },\n  {\n    \"title\": \"First party discussions support\"\n  }\n]\n```\n\n-->\n</BODY>"
+  - name: 'spam, #10446 (https://github.com/cli/cli/issues/10446)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Cli
+      </TITLE>
+
+      <BODY>
+      https://github.com/levlesec/lockup/tree/main/app%2Fsrc%2Fmain%2Fres
+      </BODY>
+  - name: 'spam, #10444 (https://github.com/cli/cli/issues/10444)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Independent
+      </TITLE>
+
+      <BODY>
+
+      </BODY>
+  - name: 'spam, #10414 (https://github.com/cli/cli/issues/10414)'
+    expected: FAIL
+    input: "<TITLE>\nDebugger and fixed error  code need simple fix \n</TITLE>\n\n<BODY>\nhttps://github.com/whit86rhin086/whit86rhin086/blob/main/game.js\n</BODY>"
+  - name: 'spam, #10401 (https://github.com/cli/cli/issues/10401)'
+    expected: FAIL
+    input: "<TITLE>\nRestore factory components \n</TITLE>\n\n<BODY>\nhttps://github.com/docker/docs/issues/21989.restore factory components. public override DTSExecResult Validate(Connections, VariableDispenser, IDTSComponentEvents componentEvents, IDTSLogging log) \n\n{                                                                                                                             \n\nVariables vars = null;                                                                                                        \n\nvariableDispenser.LockForRead(\"System::ClusterID\");                                                                           \n\nvariableDispenser.LockForRead(\"System::ClusterNodeCount\");                                                                    \n\nvariableDispenser.GetVariables(ref vars);                                                                                     \n\n// Validate Activation Key with ClusterID                                                                                     \n\n// Report on ClusterNodeCount                                                                                                 \n\nvars.Unlock();                                                                                                                \n\nreturn base.Validate(connections, variableDispenser, componentEvents, log);                                                   \n\n}\n</BODY>"
+  - name: 'spam, #10396 (https://github.com/cli/cli/issues/10396)'
+    expected: FAIL
+    input: "<TITLE>\n$ gh dependency-report --help\n</TITLE>\n\n<BODY>\n[BixbyPDSS.log](https://github.com/user-attachments/files/18717401/BixbyPDSS.log)\n\n### Describe the bug\n\nA clear and concise description of what the bug is. \n\n### Affected version\n\nPlease run `gh version` and paste the output below.\n\n### Steps to reproduce the behavior\n\n1. Type this '...'\n2. View the output '....'\n3. See error\n\n### Expected vs actual behavior\n\nA clear and concise description of what you expected to happen and what actually happened.\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\n</BODY>"
+  - name: 'spam, #10375 (https://github.com/cli/cli/issues/10375)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      https://github.com/pytorch/pytorch/commit/d9d6492110dfd13704878002264608ee25b5a2ac
+      </TITLE>
+
+      <BODY>
+      https://github.com/pytorch/pytorch/commit/d9d6492110dfd13704878002264608ee25b5a2ac
+      </BODY>
+  - name: 'spam, #10360 (https://github.com/cli/cli/issues/10360)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      Chucuoi0209.com
+      </TITLE>
+
+      <BODY>
+
+      </BODY>
+  - name: 'spam, #10359 (https://github.com/cli/cli/issues/10359)'
+    expected: FAIL
+    input: "<TITLE>\nJeff brown did it\n</TITLE>\n\n<BODY>\n### Describe the bug\n[](url)\nA clear and concise description of what the bug is. \n\n### Affected version\n\nPlease run `gh version` and paste the output below.\n\n### Steps to reproduce the behavior\n\n1. Type this '...'\n2. View the output '....'\n3. See error\n\n### Expected vs actual behavior\n\nA clear and concise description of what you expected to happen and what actually happened.\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\n</BODY>"
+  - name: 'spam, #10347 (https://github.com/cli/cli/issues/10347)'
+    expected: FAIL
+    input: "<TITLE>\nHi! Thanks for the pull request. Please ensure that this change is linked to an issue by mentioning an issue number in the description of the pull request. If this pull request would close the issue, please put the word 'Fixes' before the issue number somewhere in the pull request body. If this is a tiny change like fixing a typo, feel free to ignore this message.\n</TITLE>\n\n<BODY>\n              Hi! Thanks for the pull request. Please ensure that this change is linked to an issue by mentioning an issue number in the description of the pull request. If this pull request would close the issue, please put the word 'Fixes' before the issue number somewhere in the pull request body. If this is a tiny change like fixing a typo, feel free to ignore this message.\r\n\r\n_Originally posted by @cliAutomation in https://github.com/cli/cli/issues/10340#issuecomment-2625220766_\r\n            \n</BODY>"
+  - name: 'spam, #10343 (https://github.com/cli/cli/issues/10343)'
+    expected: FAIL
+    input: "<TITLE>\n@tiagopicon I am unsure of what you are referring to when you say \"GitHub dashboard\", can you please elaborate?\n</TITLE>\n\n<BODY>\n@tiagopicon I am unsure of what you are referring to when you say \"GitHub dashboard\", can you please elaborate?\r\n\r\n_Originally posted by @sistemcat in https://github.com/cli/cli/discussions/3903#discussioncomment-933376_\n</BODY>"
+  - name: 'spam, #10267 (https://github.com/cli/cli/issues/10267)'
+    expected: FAIL
+    input: "<TITLE>\nI think you're missing a few words here:\n</TITLE>\n\n<BODY>\n\r\n![Screenshot_2025-01-17-02-12-51-263_com google android youtube](https://user-images.githubusercontent.com/193741011/404322912-ebbc1750-3471-4150-b274-9ad4bda889f1.jpg)\r\n              I think you're missing a few words here:\r\n\r\n> \"...keep in mind this may (missing words) the single value of GH_HOST.\"\r\n\r\n_Originally posted by @jtmcg in https://github.com/cli/cli/pull/10110#discussion_r1895980059_\r\n            \n</BODY>"
+  - name: 'spam, #10264 (https://github.com/cli/cli/issues/10264)'
+    expected: FAIL
+    input: "<TITLE>\nGitHub\n</TITLE>\n\n<BODY>\n<!-- See [CONTRIBUTING.md](../CONTRIBUTING.md#proposing-a-design) for more information.-->\n\n### Link to issue for design submission\n\n<!-- \nProvide a link to the issue this design is for.\n\nAll design submissions must be linked to an open issue that\nhas both the `needs-design` and `help-wanted` labels.\n-->\n\n### Proposed Design\n\n<!--\nDescribe the design you are proposing to resolve the issue.\n\nAll CLI designs must adhere to the [Primer CLI design reference](https://primer.style/cli/).\n-->\n\n### Mockup\n\n<!--\nProvide a mockup of the design you are proposing. All mockups should clearly illustrate the command(s) being run and the expected output(s). \n\nWhen color and formatting are important, consider using our [CLI design Google Docs Template](https://docs.google.com/document/d/1JIRErIUuJ6fTgabiFYfCH3x91pyHuytbfa0QLnTfXKM/edit#heading=h.or54sa47ylpg).\n\nCode blocks can also be used to submit a design mockup - remember to include the command(s) being run. Example:\n\n```shell\n$ gh issue list --json title -L 5\n[\n  {\n    \"title\": \"`gh pr checks <pr> --required` should not fail when there are no required checks\"\n  },\n  {\n    \"title\": \"gh pr view commits should include commit description\"\n  },\n  {\n    \"title\": \"Adapt the color of the device code to the color used by the terminal\"\n  },\n  {\n    \"title\": \"`gh pr create` does not default to fork when user has write access to upstream\"\n  },\n  {\n    \"title\": \"First party discussions support\"\n  }\n]\n```\n-->\n</BODY>"
+  - name: 'spam, #10252 (https://github.com/cli/cli/issues/10252)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      LibraryManager
+      </TITLE>
+
+      <BODY>
+
+      </BODY>
+  - name: 'spam, #10237 (https://github.com/cli/cli/issues/10237)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      git remote add origin <REMOTE_URL>
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      A clear and concise description of what the bug is. Include version by typing `gh --version`.
+
+      ### Steps to reproduce the behavior
+
+      1. Type this '...'
+      2. View the output '....'
+      3. See error
+
+      ### Expected vs actual behavior
+
+      A clear and concise description of what you expected to happen and what actually happened.
+
+      ### Logs
+
+      Paste the activity from your command line. Redact if needed.
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->origin https://github.com/user/repo.git
+
+      git remote add origin
+      <REMOTE_URL>
+      </BODY>
+  - name: 'spam, #10232 (https://github.com/cli/cli/issues/10232)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      https://github.com/cli/cli/issues/new/choose
+      </TITLE>
+
+      <BODY>
+      [/](url)
+      </BODY>
+  - name: 'spam, #10144 (https://github.com/cli/cli/issues/10144)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      New
+      </TITLE>
+
+      <BODY>
+
+      </BODY>
+  - name: 'spam, #9842 (https://github.com/cli/cli/issues/9842)'
+    expected: FAIL
+    input: "<TITLE>\nIn the dnf steps, option 1 (reinstall) will not work, it will keep complaining even if you remove the key from rpm. I was required to go with option 2 to fetch key and feed it for rpm and after this dnf installation worked. Problem is though that I did this already with last update and now I had to do this again ... will this be happening with each gh update?\n</TITLE>\n\n<BODY>\n              In the dnf steps, option 1 (reinstall) will not work, it will keep complaining even if you remove the key from rpm. I was required to go with option 2 to fetch key and feed it for rpm and after this dnf installation worked. Problem is though that I did this already with last update and now I had to do this again ... will this be happening with each gh update?\r\n\r\n_Originally posted by @tpalli in https://github.com/cli/cli/issues/9569#issuecomment-2355723961_\r\n\r\n            \n</BODY>"
+  - name: 'spam, #9841 (https://github.com/cli/cli/issues/9841)'
+    expected: FAIL
+    input: "<TITLE>\n@williammartin yes, and I think it's a more straightforward solution (minus the `wget` check). If you got the new keypath it'll do nothing.\n</TITLE>\n\n<BODY>\n              @williammartin yes, and I think it's a more straightforward solution (minus the `wget` check). If you got the new keypath it'll do nothing.\r\n\r\n_Originally posted by @pirafrank in https://github.com/cli/cli/issues/9569#issuecomment-2352848108_\r\n            \n</BODY>"
+  - name: 'spam, #9733 (https://github.com/cli/cli/issues/9733)'
+    expected: FAIL
+    input: "<TITLE>\n## What's Changed\n</TITLE>\n\n<BODY>\n## What's Changed\r\n* Better messaging for `attestation verify` custom issuer mismatch error by @bdehamer in https://github.com/cli/cli/pull/9616\r\n* Enhance gh repo create docs, fix random cmd link by @andyfeller in https://github.com/cli/cli/pull/9630\r\n* Add HasActiveToken method to AuthConfig to refactor auth check for `attestation trusted-root` command by @BagToad in https://github.com/cli/cli/pull/9635\r\n* Improve the suggested command for creating an issue when an extension doesn't have a binary for your platform by @timrogers in https://github.com/cli/cli/pull/9608\r\n* Disable auth check for `attestation trusted-root` command by @bdehamer in https://github.com/cli/cli/pull/9610\r\n* build(deps): bump github.com/henvic/httpretty from 0.1.3 to 0.1.4 by @dependabot in https://github.com/cli/cli/pull/9645\r\n* Fix tenant-awareness for `trusted-root` command by @bdehamer in https://github.com/cli/cli/pull/9638\r\n* Replace \"GitHub Enterprise Server\" option with \"other\" in gh auth login prompting by @jtmcg in https://github.com/cli/cli/pull/9642\r\n* build(deps): bump github.com/cpuguy83/go-md2man/v2 from 2.0.4 to 2.0.5 by @dependabot in https://github.com/cli/cli/pull/9634\r\n* Add `dnf5` instructions to `docs/install_linux.md` by @its-miroma in https://github.com/cli/cli/pull/9660\r\n* build(deps): bump github.com/theupdateframework/go-tuf/v2 from 2.0.0 to 2.0.1 by @dependabot in https://github.com/cli/cli/pull/9688\r\n\r\n## New Contributors\r\n* @its-miroma made their first contribution in https://github.com/cli/cli/pull/9660\r\n\r\n**Full Changelog**: https://github.com/cli/cli/compare/v2.57.0...v2.58.0\r\n\r\n<hr /><em>This discussion was created from the release <a href='https://github.com/cli/cli/releases/tag/v2.58.0'>GitHub CLI 2.58.0</a>.</em>\r\n\r\n_Originally posted by @github-actions in https://github.com/cli/cli/discussions/9689_\n</BODY>"
+  - name: 'spam, #9693 (https://github.com/cli/cli/issues/9693)'
+    expected: FAIL
+    input: "<TITLE>\n39\n</TITLE>\n\n<BODY>\n# CLI Feedback\r\n\r\nYou can use this template to give us structured feedback or just wipe it and leave us a note. Thank you!\r\n\r\n## What have you loved?\r\n\r\n_eg \"the nice colors\"_\r\n\r\n## What was confusing or gave you pause?\r\n\r\n_eg \"it did something unexpected\"_\r\n\r\n## Are there features you'd like to see added?\r\n\r\n_eg \"gh cli needs mini-games\"_\r\n\r\n## Anything else?\r\n\r\n_eg \"have a nice day\"_\r\n</BODY>"
+  - name: 'spam, #9591 (https://github.com/cli/cli/issues/9591)'
+    expected: FAIL
+    input: "<TITLE>\n目前不能直接在termux中调用\n</TITLE>\n\n<BODY>\n目前不能直接在texmux中调用\r\nOS: Termux\n</BODY>"
+  - name: 'spam, #9456 (https://github.com/cli/cli/issues/9456)'
+    expected: FAIL
+    input: "<TITLE>\n## What's Changed\n</TITLE>\n\n<BODY>\n## What's Changed\r\n* Remove redundant whitespace by @jessehouwing in https://github.com/cli/cli/pull/9334\r\n* Remove attestation test that requires being online by @steiza in https://github.com/cli/cli/pull/9340\r\n* Update documentation for gh api PATCH by @cmbuckley in https://github.com/cli/cli/pull/9352\r\n* Clarify usage of template flags for PR and issue creation by @williammartin in https://github.com/cli/cli/pull/9354\r\n* Expose json databaseId field for release commands by @williammartin in https://github.com/cli/cli/pull/9356\r\n* Expose fullDatabaseId for PR json export by @williammartin in https://github.com/cli/cli/pull/9355\r\n* Handle `--bare` clone targets by @hyperrealist in https://github.com/cli/cli/pull/9271\r\n* Slightly clarify when CLI exits with code 4 by @williammartin in https://github.com/cli/cli/pull/9358\r\n* Update sigstore-go in gh CLI to v0.5.1 by @steiza in https://github.com/cli/cli/pull/9366\r\n* Exit with 1 on authentication issues by @Stausssi in https://github.com/cli/cli/pull/9240\r\n* build(deps): bump github.com/gabriel-vasile/mimetype from 1.4.4 to 1.4.5 by @dependabot in https://github.com/cli/cli/pull/9372\r\n* build(deps): bump github.com/google/go-containerregistry from 0.20.0 to 0.20.1 by @dependabot in https://github.com/cli/cli/pull/9373\r\n* Add `--remove-milestone` option to `issue edit` and `pr edit` by @babakks in https://github.com/cli/cli/pull/9344\r\n* handle attest case insensitivity by @ejahnGithub in https://github.com/cli/cli/pull/9392\r\n\r\n## New Contributors\r\n* @cmbuckley made their first contribution in https://github.com/cli/cli/pull/9352\r\n* @hyperrealist made their first contribution in https://github.com/cli/cli/pull/9271\r\n* @Stausssi made their first contribution in https://github.com/cli/cli/pull/9240\r\n* @ejahnGithub made their first contribution in https://github.com/cli/cli/pull/9392\r\n\r\n**Full Changelog**: https://github.com/cli/cli/compare/v2.53.0...v2.54.0\r\n\r\n<hr /><em>This discussion was created from the release <a href='https://github.com/cli/cli/releases/tag/v2.54.0'>GitHub CLI 2.54.0</a>.</em>\r\n\r\n_Originally posted by @github-actions in https://github.com/cli/cli/discussions/9405_\n</BODY>"
+  - name: 'spam, #9259 (https://github.com/cli/cli/issues/9259)'
+    expected: FAIL
+    input: |-
+      <TITLE>
+      gh repo clone cli/cli
+      </TITLE>
+
+      <BODY>
+
+      </BODY>
+  - name: 'spam, #9930 (https://github.com/cli/cli/issues/9930)'
+    expected: FAIL
+    input: "<TITLE>\nهل من مخاطر امنيه\n</TITLE>\n\n<BODY>\nهل من مخاطر امنيه\r\n\r\n_Originally posted by @yahyaalhass in https://github.com/cli/cli/discussions/9929_\n</BODY>"
+  - name: 'spam, #9928 (https://github.com/cli/cli/issues/9928)'
+    expected: FAIL
+    input: "<TITLE>\nNote that an earlier version of the instructions used the location `/usr/share/keyrings` instead of `/etc/apt/keyrings` in the `sources.list.d` file, so I had to update that to make it work with the above update instructions, and remove the old keyring file from `/usr/share/keyrings`.\n</TITLE>\n\n<BODY>\n              Note that an earlier version of the instructions used the location `/usr/share/keyrings` instead of `/etc/apt/keyrings` in the `sources.list.d` file, so I had to update that to make it work with the above update instructions, and remove the old keyring file from `/usr/share/keyrings`.\r\n\r\nAlternatively, one could of course download the updated key to `/usr/share/keyrings`, but we don't really want to pollute `/usr` with non-packaged files!\r\n\r\n_Originally posted by @rrthomas in https://github.com/cli/cli/issues/9569#issuecomment-2333981674_\r\n            \n</BODY>"
+  - name: 'not spam, #11277 (https://github.com/cli/cli/issues/11277)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh pr create --web` now always overwrites autofilled content
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      `gh pr create --web` now always generates autofilled content; previously, the contents of `.github/PULL_REQUEST_TEMPLATE.md` would be populated. It looks like the behaviour now defaults to `--fill`, even though I don't provide that flag.
+
+      ### Affected version
+
+      This was introduced in #10547 (fixes #10527) and released in [v2.75.0](https://github.com/cli/cli/releases/tag/v2.75.0).
+
+      ### Steps to reproduce the behavior
+
+      1. Make sure the repository has a non-empty `.github/PULL_REQUEST_TEMPLATE.md`
+      2. On a topic branch, create and push a few commits
+      3. Run `gh pr create --web`
+
+      ### Expected vs actual behavior
+
+      Actual: the title is prefilled with the branch name, and the body is a list of commit titles.
+
+      The previous (and expected) behaviour was to leave the title empty (I think...) and have the body pre-populated with the contents of `.github/PULL_REQUEST_TEMPLATE.md`.
+
+      ### Logs
+
+      <details><summary>Click for logs</summary>
+
+      ```console
+      $ GH_DEBUG=api gh pr create --web
+      [git remote -v]
+      [git config --get-regexp ^remote\..*\.gh-resolved$]
+      * Request at 2025-07-11 10:12:13.294054503 -0700 PDT m=+0.036090788
+      * Request to https://api.github.com/graphql
+      > POST /graphql HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Length: 392
+      > Content-Type: application/json; charset=utf-8
+      > Graphql-Features: merge_queue
+      > Time-Zone: America/Vancouver
+      > User-Agent: GitHub CLI 2.75.0
+
+      GraphQL query:
+      fragment repo on Repository {
+          id
+          name
+          owner { login }
+          viewerPermission
+          defaultBranchRef {
+            name
+          }
+          isPrivate
+        }
+        query RepositoryNetwork {
+          viewer { login }
+
+          repo_000: repository(owner: "myorg", name: "myrepo") {
+            ...repo
+            parent {
+              ...repo
+            }
+          }
+
+        }
+      GraphQL variables: null
+
+      < HTTP/2.0 200 OK
+      < Access-Control-Allow-Origin: *
+      < Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
+      < Content-Security-Policy: default-src 'none'
+      < Content-Type: application/json; charset=utf-8
+      < Date: Fri, 11 Jul 2025 17:12:15 GMT
+      < Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+      < Server: github.com
+      < Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
+      < Vary: Accept-Encoding, Accept, X-Requested-With
+      < X-Accepted-Oauth-Scopes: repo
+      < X-Content-Type-Options: nosniff
+      < X-Frame-Options: deny
+      < X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
+      < X-Github-Request-Id: CC7C:289371:4546EF1:8BFE0B0:687145EE
+      < X-Oauth-Client-Id: 178c6fc778ccc68e1d6a
+      < X-Oauth-Scopes: admin:enterprise, admin:org, admin:org_hook, admin:public_key, gist, project, repo
+      < X-Ratelimit-Limit: 5000
+      < X-Ratelimit-Remaining: 4998
+      < X-Ratelimit-Reset: 1752257518
+      < X-Ratelimit-Resource: graphql
+      < X-Ratelimit-Used: 2
+      < X-Xss-Protection: 0
+
+      {
+        "data": {
+          "viewer": {
+            "login": "bewuethr"
+          },
+          "repo_000": {
+            "id": "someID=",
+            "name": "myrepo",
+            "owner": {
+              "login": "myorg"
+            },
+            "viewerPermission": "ADMIN",
+            "defaultBranchRef": {
+              "name": "main"
+            },
+            "isPrivate": true,
+            "parent": null
+          }
+        }
+      }
+
+      * Request took 522.365894ms
+      [git status --porcelain]
+      [git symbolic-ref --quiet HEAD]
+      [git config --get-regexp ^branch\.topic-branch\.(remote|merge|pushremote|gh-merge-base)$]
+      [git rev-parse --symbolic-full-name fix-annotation@{push}]
+      [git show-ref --verify -- HEAD refs/remotes/origin/topic-branch]
+      [git -c log.ShowSignature=false log --pretty=format:%H%x00%s%x00%b%x00 --cherry origin/main...topic-branch]
+      Opening https://github.com/myorg/myrepo/compare/main...topic-branch in your browser.
+      Opening in existing browser session.
+      ```
+
+      </details>
+      </BODY>
+  - name: 'not spam, #11258 (https://github.com/cli/cli/issues/11258)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Create automation around stale issues
+      </TITLE>
+
+      <BODY>
+      As a follow up to a team discussion, we are going to introduce an automation to nudge on stale issues (those waiting for more info from users), and close them after a given period.
+
+      We can use the GitHub Desktop [workflow](https://github.com/desktop/desktop/blob/72d126ea90cf1ff23dfd5cd808ad573d8a7206cf/.github/workflows/stale-issues.yml) as a source of inspiration.
+
+      ## Expected Output
+
+      We have an automation to nudge on issues waiting for user info (like after one week), and close the issue if there's no further activity (like after one more week).
+
+      - Automatically add the stale label to issues labelled needs-user-input after 30 days of inactivity. When the stale label is added, also post a comment to the issue explaining what this means: the issue will close after 30 days of inactivity; contributors can comment on the issue to remove the stale label and keep it open. Maintainers can also add the keep label to make the stale automation ignore that issue.
+      - Automatically close issues labelled stale after they have been stale for 30 days. When the issue is closed, add a comment explaining why this happened. Encourage them to leave a comment if the close was done in error.
+      - The above automation should only act on new issues after the date of the automation's implementation.
+      </BODY>
+  - name: 'not spam, #11238 (https://github.com/cli/cli/issues/11238)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh run list` should default to runs for the current branch
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      In interactive uses, when running `gh run list` to get a list of runs, most of the times users probably want to look at the current branch's runs not the main/master branch's. Since a lot of github cli's commands like `gh pr view` auto detect branch, it makes sense for `gh run list` to auto detect it.
+
+      ### Proposed solution
+
+      This will save having to add an additional `-b <branch-name>` everytime when running the command
+
+      ### Additional context
+
+      This breaks existing scripts relying on this behavior of `gh run list` defaulting to the main/master branch. Not sure about the amount of people relying on this behavior though, maybe the GitHub team has more idea about it from some internal telemetry.
+
+      Thanks, feel free to reject this request if the breakage is not worth the convenience added by the change
+      </BODY>
+  - name: 'not spam, #11228 (https://github.com/cli/cli/issues/11228)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh search` does not properly handle multi-word search query terms
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When using `gh search prs` with `--limit 1000`, the request fails with the error message "Invalid search query <enormous quantity of backslashes> The search is longer than 256 characters."
+
+      It appears that internally, an extra layer of escaping is applied every for every subsequent page of results, until the search string becomes so long that it is rejected by the server.
+
+      ### Affected version
+
+      ```
+      gh version 2.74.2 (2025-06-17)
+      https://github.com/cli/cli/releases/tag/v2.74.2
+      ```
+
+      ### Steps to reproduce the behavior
+
+      Run:
+      ```
+      gh search prs 'bump client' --created=='>=2024-06-11' --match title --limit 1000 --json 'title,url,state'
+      ```
+      Observe
+      ```
+      Invalid search query "\"\\\"\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"bump client\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\"\\\"\" created:=>=2024-06-11 in:title".
+      The search is longer than 256 characters.
+      ```
+      and an exit code of 1.
+
+      ### Expected vs actual behavior
+
+      The expected behaviour is that a short query that succeeds for `--limit 30` should not result in "Invalid search query" with `--limit 1000`.
+
+      ### Logs
+
+      ```
+      $ GH_DEBUG=1 gh search prs 'bump client' --created=='>=2024-06-11' --match title --limit 1000 --json 'title,url,state'
+      * Request at 2025-07-04 09:44:31.069311 +0100 BST m=+0.102011834
+      * Request to https://api.github.com/repos/cli/cli/releases/latest
+      ⣾* Request at 2025-07-04 09:44:31.117253 +0100 BST m=+0.149953709
+      * Request to https://github.skyscannertools.net/api/v3/search/issues?page=1&per_page=100&q=%22bump+client%22+created%3A%3D%3E%3D2024-06-11+in%3Atitle+type%3Apr
+      ⣻* Request took 269.649792ms
+      ⢿* Request took 1.37664225s
+      ⡿* Request at 2025-07-04 09:44:32.620046 +0100 BST m=+1.652743918
+      * Request to https://github.skyscannertools.net/api/v3/search/issues?page=2&per_page=100&q=%22%5C%22bump+client%5C%22%22+created%3A%3D%3E%3D2024-06-11+in%3Atitle+type%3Apr
+      ⣯* Request took 1.14711725s
+      * Request at 2025-07-04 09:44:33.856533 +0100 BST m=+2.889227501
+      * Request to https://github.skyscannertools.net/api/v3/search/issues?page=3&per_page=100&q=%22%5C%22%5C%5C%5C%22bump+client%5C%5C%5C%22%5C%22%22+created%3A%3D%3E%3D2024-06-11+in%3Atitle+type%3Apr
+      ⣾* Request took 1.192825125s
+      ⣽* Request at 2025-07-04 09:44:35.116841 +0100 BST m=+4.149533084
+      * Request to https://github.skyscannertools.net/api/v3/search/issues?page=4&per_page=100&q=%22%5C%22%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%22bump+client%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%22%5C%22%22+created%3A%3D%3E%3D2024-06-11+in%3Atitle+type%3Apr
+      ⣻* Request took 1.144724167s
+      ⢿* Request at 2025-07-04 09:44:36.343849 +0100 BST m=+5.376538126
+      * Request to https://github.skyscannertools.net/api/v3/search/issues?page=5&per_page=100&q=%22%5C%22%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22bump+client%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%22%5C%22%22+created%3A%3D%3E%3D2024-06-11+in%3Atitle+type%3Apr
+      ⣯* Request took 1.386538667s
+      ⣷* Request at 2025-07-04 09:44:37.813457 +0100 BST m=+6.846143126
+      * Request to https://github.skyscannertools.net/api/v3/search/issues?page=6&per_page=100&q=%22%5C%22%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22bump+client%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%22%5C%22%22+created%3A%3D%3E%3D2024-06-11+in%3Atitle+type%3Apr
+      ⢿* Request took 1.434989792s
+      * Request at 2025-07-04 09:44:39.311696 +0100 BST m=+8.344378168
+      * Request to https://github.skyscannertools.net/api/v3/search/issues?page=7&per_page=100&q=%22%5C%22%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22bump+client%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%5C%5C%5C%5C%22%5C%5C%5C%22%5C%22%22+created%3A%3D%3E%3D2024-06-11+in%3Atitle+type%3Apr
+      ⡿* Request took 58.694791ms
+      Invalid search query "\"\\\"\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"bump client\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\"\\\"\" created:=>=2024-06-11 in:title type:pr".
+      The search is longer than 256 characters.
+      ```
+
+      As can be seen, every subsequent request made to the search has multiplied the size of the previous request. They consist primarly of backslashes. It's unclear whether they are actually performing the intended search.
+      </BODY>
+  - name: 'not spam, #11219 (https://github.com/cli/cli/issues/11219)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `repo view` resolves to upstream on forks
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      `gh repo view` **(no arg parameter)** on a fork resolves to the upstream repo.
+
+      ### Affected version
+
+      ```
+      ➜  shelljs-fork git:(shelljs-find-tests) gh version
+      gh version 2.74.2 (2025-06-18)
+      https://github.com/cli/cli/releases/tag/v2.74.2
+      ```
+
+      ### Steps to reproduce the behavior
+
+      1. fork a repo and clone it
+      2. run `gh repo view -w`
+      3. `gh` opens the upstream repo instead of the fork.
+
+
+      ### Expected vs actual behavior
+
+      I had this shell alias:
+      `ghbo=gh repo view -w --branch $(git branch --show-current)`
+
+      so when I ran it on a fork today I was expecting to open the branch on my fork and open a PR in the web ui.
+      Instead, it opened the upstream repo.
+
+      ### Logs
+      see how it resolves from `upstream` instead of `origin`
+
+      ![Image](https://github.com/user-attachments/assets/581eca71-3e51-4a2c-948b-d43a1a7c0f4c)
+      </BODY>
+  - name: 'not spam, #11207 (https://github.com/cli/cli/issues/11207)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Consume dependabot minor upgrades
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      Currently, [Dependabot will open pull requests for new patch versions](https://github.com/cli/cli/blob/dc7b22b65971f0937211bab26a7b00b2a26d2d83/.github/dependabot.yml#L3-L11):
+
+      ```yaml
+      version: 2
+      updates:
+      - package-ecosystem: gomod
+        directory: "/"
+        schedule:
+          interval: "daily"
+        ignore:
+          - dependency-name: "*"
+            update-types:
+              - version-update:semver-minor
+              - version-update:semver-major
+      - package-ecosystem: "github-actions"
+        directory: "/"
+        schedule:
+            interval: "daily"
+      ```
+
+      We want to start consuming minor versions.
+
+      ### Expected Output
+
+      Dependabot is configured to consume minor versions.
+      </BODY>
+  - name: 'not spam, #11193 (https://github.com/cli/cli/issues/11193)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      README code mixes tabs and spaces in the same block
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      The code below used spaces to indent two of the lines, and tabs for the other 6 lines. This makes indenting inconsistent in settings where tabs are not rendered as 8 spaces.
+
+      ### Affected version
+
+      gh version 2.74.2 (2025-06-18)
+      ### Steps to reproduce the behavior
+
+      See the code block in this [README](https://github.com/cli/cli/blob/trunk/docs/install_linux.md)
+
+      ### Expected vs actual behavior
+
+      Actual code, highlighting tabs and spaces with respective unicode characters
+      ```
+      (type -p wget >/dev/null || (sudo apt update && sudo apt-get install wget -y)) \
+      ␉ && sudo mkdir -p -m 755 /etc/apt/keyrings \
+      ␣␣␣␣␣␣␣␣&& out=$(mktemp) && wget -nv -O$out https://cli.github.com/packages/githubcli-archive-keyring.gpg \
+      ␣␣␣␣␣␣␣␣&& cat $out | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
+       ␉ && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
+       ␉ && sudo mkdir -p -m 755 /etc/apt/sources.list.d \
+       ␉ && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
+       ␉ && sudo apt update \
+       ␉ && sudo apt install gh -y
+      ```
+
+      Expected code: Use either tabs or spaces.
+      ```
+      (type -p wget >/dev/null || (sudo apt update && sudo apt-get install wget -y)) \
+      	&& sudo mkdir -p -m 755 /etc/apt/keyrings \
+      	&& out=$(mktemp) && wget -nv -O$out https://cli.github.com/packages/githubcli-archive-keyring.gpg \
+      	&& cat $out | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
+      	&& sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
+      	&& sudo mkdir -p -m 755 /etc/apt/sources.list.d \
+      	&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
+      	&& sudo apt update \
+      	&& sudo apt install gh -y
+      ```
+      </BODY>
+  - name: 'not spam, #11187 (https://github.com/cli/cli/issues/11187)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `--delete-branch` fails, if branch is deleted already (race condition)
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When using `gh pr merge --delete-branch`, the command sometimes fails, if the branch was deleted already. This is unintuitive, since I want to make sure the branch is cleaned up and don't care how it happens, unless it interferes with the actual command.
+
+      https://github.com/cli/cli/pull/1279 already addresses this behavior, but I'm still getting an error.
+      I wondered, whether this is intentional or not. If intentional, where is the difference to the behavior addressed in the aforementioned PR and how I should go about ensuring the branch is gone after the merge, without risking a pipeline fail.
+
+      ### Affected version
+
+      GitHub CLI 2.74.2 (pipeline ran today and was using the [Ubuntu 24.04 runner image](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md#cli-tools), thus this is the installed version)
+
+      ### Steps to reproduce the behavior
+
+      1. Write pipeline which merges a PR
+      2. Set the repository to delete the branch itself (or insert a sleep into the pipeline and do it yourself)
+      3. Let the pipeline run the "gh pr merge --delete-branch" command on that PR
+      4. `gh` will error with a `HTTP 404`
+
+      ### Expected vs actual behavior
+
+      I'd expect the command to not error, but gracefully handle the error and suppressing it, since it matches the intent.
+      Currently it fails with `failed to delete remote branch <redacted>: HTTP 404: Reference does not exist (https://api.github.com/repos/<redacted>)`.
+      https://github.com/cli/cli/pull/1279 already addresses this issue, but the caught error doesn't include the `HTTP 404` I'm observing here.
+
+      I'd argue, that the command should not raise this error, since my intention is "branch should be cleaned up and gone after merge". If the branch is already gone, that's fine, as far as I'm concerned. The fact, that the branch was deleted by some other actor has no impact on my `gh pr merge` command, since the merge already happened, thus the command shouldn't care and shouldn't fail, just because it could not delete the branch by itself.
+
+      ### Logs
+
+      There is only one relevant log line, as `gh pr merge` doesn't output anything else for me.
+
+      `failed to delete remote branch <redacted>: HTTP 404: Reference does not exist (https://api.github.com/repos/<redacted>)`
+      </BODY>
+  - name: 'not spam, #11180 (https://github.com/cli/cli/issues/11180)'
+    expected: PASS
+    input: "<TITLE>\nAllow the PR help-wanted check to be run manually\n</TITLE>\n\n<BODY>\nFollow up from https://github.com/cli/cli/issues/11100\n\nI would like to run the workflow manually in the case of the PR author editing in the closing issue references after the PR is opened. Currently the workflow only triggers on open events, and this is by design to avoid managing state complexity.\n\nTo keep it simple, I just want to be able to manually run the workflow when needed in these cases. \n</BODY>"
+  - name: 'not spam, #11171 (https://github.com/cli/cli/issues/11171)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh run list` links to commits
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When I run `gh run list` and then use my terminal emulator's hyperlink shortcut (command-click) on the run ID column, I am linked to a repository commit page with the run ID.
+
+      ### Affected version
+
+      ```
+      $ gh version
+      gh version 2.74.2 (2025-06-17)
+      https://github.com/cli/cli/releases/tag/v2.74.2
+      ```
+
+      ### Steps to reproduce the behavior
+
+      1. Run `gh run list` in a repository with GitHub Actions configured and past runs.
+      2. Hover the ID column with pointer device
+      3. Command-click (or similar) an entry
+
+      ### Expected vs actual behavior
+
+      Expected behaviour would link to the run page.
+
+      Instead, you're taken to a non-existent/nonsense commit page.
+
+      ### Logs
+
+      Not useful, afaict:
+
+      ```
+      GH_DEBUG=true gh run list
+      [git remote -v]
+      [git config --get-regexp ^remote\..*\.gh-resolved$]
+      ⣾* Request at 2025-06-25 23:25:44.920252 +0100 BST m=+0.112185043
+      * Request to https://api.github.com/repos/django/django/actions/runs?per_page=20&exclude_pull_requests=true
+      ⡿* Request took 580.170625ms
+      ⣟* Request at 2025-06-25 23:25:45.54287 +0100 BST m=+0.734803085
+      * Request to https://api.github.com/repos/django/django/actions/workflows?per_page=100&page=1
+      ⣯* Request took 196.171791ms
+      STATUS  TITLE                                                              WORKFLOW                        BRANCH              EVENT                ID           ELAPSED  AGE
+      -       Fixed #36470 -- Potential log injection in development server ...  Selenium Tests                  ticket_36470        pull_request         15888394219  1s       about 5 minutes ago
+      ✓       Fixed #36470 -- Potential log injection
+      ...
+      ```
+
+      The ID in the output is still incorrectly linked.
+      </BODY>
+  - name: 'not spam, #11169 (https://github.com/cli/cli/issues/11169)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Use Actions API to retrieve job run logs as a fallback mechanism
+      </TITLE>
+
+      <BODY>
+      This issue is a follow-up to #11118.
+
+      We want to use the Actions API ([here](https://docs.github.com/en/rest/actions/workflow-jobs?apiVersion=2022-11-28#download-job-logs-for-a-workflow-run)) as a fallback mechanism to retrieve job run logs when the current approach (extracting logs from a downloaded ZIP archive) fails.
+
+      **Other context**
+      - If there's 1 job log missing, there are probably others, but fixing that holistically is a larger conversation with the Actions team.
+      - It's common for projects to have a lot of logs for matrix workflows.
+
+      As a middle ground to avoid hitting the API too many times in case of huge runs (lots of jobs), we need to apply a restriction on the number of fallback API calls, and display an actionable error message to users.
+
+      ## Acceptance Criteria
+
+      ### 1. Fallback to API call
+
+      **Given** I have a job run that is missing from the downloaded ZIP archive
+      **When** I run `gh run view --log -j <JOB-RUN-ID>`
+      **Then** I see the job logs, with the step name column filled with "UNKNOWN STEP"
+
+      > [!NOTE]
+      > Reproducing this with read data is a bit tricky. Since this fix coincidentally fixes the cases reported in #10868, we can also use those cases to verify the current PR.
+
+      ### 2. Error when too many API calls are needed
+
+      **Given** I have a workflow run where more than 25 job log files are missing from the downloaded ZIP archive
+      **When** I run `gh run view --log <RUN-ID>`
+      **Then** I get an error indicating I should use the `--job` option (without any API calls being made)
+      </BODY>
+  - name: 'not spam, #11165 (https://github.com/cli/cli/issues/11165)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Reduce friction around go version releases with automation
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      As discussed in https://miro.com/app/board/uXjVIne_7aw=/, we've recently gone through a version update for Go and I got annoyed that it was a manual process and each time I had to remember my previous decisions around the `go` directive and the `toolchain` directive.
+
+      This issue suggests adding some automation that would ease this.
+
+      ### Expected Output
+
+      A new workflow that runs periodically and opens Pull Requests when there is a new version release, bumping the `go` and `toolchain` directives.
+
+      ### Out of Scope
+
+      Devcontainer images are built on a periodic schedule So we don't expect for them to be available immediately when the Go release comes out: https://github.com/devcontainers/images/tree/main/src/go/history
+      </BODY>
+  - name: 'not spam, #11141 (https://github.com/cli/cli/issues/11141)'
+    expected: PASS
+    input: "<TITLE>\nBump go toolchain to 1.24\n</TITLE>\n\n<BODY>\n## Description\n\nWe're a little bit behind on our Go releases, and probably are missing a few security patches as called out correctly in https://github.com/cli/cli/pull/10893. I'd like us to bump out toolchain to latest, and while we're at it, I think we should just bump the go module version since we are shipping a binary anyway, it's not a huge issue. It also gives access to some minor goodies like `t.Chdir` in tests.\n\nLess important, I think there's also one or more dependabot PRs that might depend on go1.24 but I can't quite find them right now.\n\n### Expected Output\n\n* The go directive is 1.24\n* The go toolchain directive is 1.24.4 \n\n### Follow On\n\nI believe we should investigate whether dependabot can notify us of toolchain updates. I don't think there's any reason we shouldn't be bumping it each time.\n</BODY>"
+  - name: 'not spam, #11126 (https://github.com/cli/cli/issues/11126)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Exclude third-party source code from CodeQL and security scans
+      </TITLE>
+
+      <BODY>
+      Relates #11047
+
+      With enabling GHAS review of CodeQL and secret scanning for `cli/cli`, there has been an increase of false positive alerts within pull requests due to #11047.
+
+      This issue is to reduce the alerts by excluding the `third-party` directory, which contains source code for 3rd modules we must redistribute due to licenses.
+
+      ### Expected outcomes
+
+      - [ ] Code scanning alerts ignore `third-party` directory and related markdown reports
+      - [ ] Secret scanning alerts ignore `third-party` directory and related markdown reports
+      </BODY>
+  - name: 'not spam, #11119 (https://github.com/cli/cli/issues/11119)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Suggested run list command for workflows with space in name doesn't work
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When a workflow with a space in the name is run with `gh workflow run` the output suggestion of how to see the runs for the workflow doesn't wrap the name in quotes.
+
+      ### Affected version
+
+      gh version 2.74.1 (2025-06-10)
+      https://github.com/cli/cli/releases/tag/v2.74.1
+
+      ### Steps to reproduce the behavior
+
+      1. Create and register a workflow with a space in the name. eg. 'My Workflow'
+      2. Run `gh workflow run "My Workflow"
+      3. See error
+
+      ### Expected vs actual behavior
+
+      The output of the command to run should either escape the spaces or wrap the name in quotes. Both work.
+      eg.
+
+      `gh run list --workflow="My Workflow"`
+      or
+      `gh run list --workflow=My\ Workflow`
+
+
+      ### Logs
+
+      N/A
+      </BODY>
+  - name: 'not spam, #11118 (https://github.com/cli/cli/issues/11118)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Investigate using Actions API to retrieve single job run logs
+      </TITLE>
+
+      <BODY>
+      ## Context
+
+      We have had a good number of issues pointing out `gh run view (--log | --log-failed)` command fails to display the requested job run logs. One of the reasons, for most of the cases, was the changes made to the ZIP file structure (i.e. file naming and sanitisation of special chars) that `gh` downloads to extract the logs from.
+
+      ## Suggested approach
+
+      As of our internal comms, @robherley, suggested using [this][endpoint] API endpoint to fetch individual job run logs.
+
+      We need to investigate this and see how we can use this endpoint, and potentially replacing the code around handling downloaded ZIP archives.
+
+      [endpoint]: https://docs.github.com/en/rest/actions/workflow-jobs?apiVersion=2022-11-28#download-job-logs-for-a-workflow-run
+
+      ## Expected outcomes
+
+      - We know if we can safely replace the current behaviour, with the use of the new endpoint API, or at least use the mentioned endpoint in specific scenarios.
+      - Either:
+        - Another issue is created with clear expectations to proceed with the implementation.
+        - This is issue is closed with a comment explaining why we're abandoning the idea.
+      </BODY>
+  - name: 'not spam, #11109 (https://github.com/cli/cli/issues/11109)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh run view --job <jobid> --log` fails to return any data
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      We have been using gh.exe to grab job output logs and parse them for test failures in our testing apps. This had been working, but a week or so ago stopped working. The command gh run view --job --log no longer yields any output to std out.
+
+      In looking at the .zip file downloaded by gh, it looks like the format of the file names for the steps have changed. I can run this command on a workflow that ran last week and I get the output as expected, but any newer output fails.
+
+      When I search in the zip file for my job name on the new workflow run, I see:
+      15_test_windows11_Arm64_driver_verifier (Arm64, Release) _ install_and_reboot_target.txt
+      16_test_windows11_Arm64_driver_verifier (Arm64, Release) _ wait_for_reboot.txt
+      19_test_windows11_Arm64_driver_verifier (Arm64, Release) _ component_test.txt
+
+      In the zip file from the older run (which works) I see:
+      0_test_windows11_Arm64_driver_verifier (Arm64, Release)  com.txt
+      0_test_windows11_Arm64_driver_verifier (Arm64, Release)  ins.txt
+      0_test_windows11_Arm64_driver_verifier (Arm64, Release)  wai.txt
+
+      This leads me to believe that the parsing logic that looks forms the expected file name is no longer matching the file name in the zip file.
+
+      https://github.com/cli/cli/blame/73b7d61475426e8690b1f4d9b4ae725b38d57390/pkg/cmd/run/view/view.go#L540
+
+      ### Affected version
+
+      I would guess this is all versions, but I am using:
+
+      gh version 2.74.1 (2025-06-10)
+      https://github.com/cli/cli/releases/tag/v2.74.1
+
+      ### Steps to reproduce the behavior
+
+      run gh run view --job <jobid> --log with some jobid from the last week
+
+      No output
+
+      ### Expected vs actual behavior
+
+      Should get output from job, but get none
+      A clear and concise description of what you expected to happen and what actually happened.
+
+      ### Logs
+
+      Paste the activity from your command line. Redact if needed.
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+      </BODY>
+  - name: 'not spam, #11101 (https://github.com/cli/cli/issues/11101)'
+    expected: PASS
+    input: "<TITLE>\nUse `golangci-lint` version 2\n</TITLE>\n\n<BODY>\n# Description\n\nSome months ago `golangci-lint` [released version 2](https://ldez.github.io/blog/2025/03/23/golangci-lint-v2/). We should probably just move forward. Also, I think we should use golangci-lint action in our workflows rather than this [weird old way of downloading the binary directly](https://github.com/cli/cli/blob/b83d335f2ffa9be296546f872407778f38a661b0/.github/workflows/lint.yml). See `github-mcp-server` for an example: https://github.com/github/github-mcp-server/blob/c423a52511d6a7c10947b42c5e8c3345aeaf7f96/.github/workflows/lint.yaml\n\nIt would probably help us move forward with https://github.com/cli/cli/pull/11015 as well because I don't really \nwant to dig into finding a golangci-lint version 1 that is built with 1.24.\n\n## Expected Output\n\nThe same linters are applied at minimum.\n\nIf I have `golangci-lint` version 2 installed locally, when I run `golangci-lint run` I see no errors.\n\nThe workflow uses golangci-lint action.\n</BODY>"
+  - name: 'not spam, #11100 (https://github.com/cli/cli/issues/11100)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Automate comment on Pull Requests that fix issues without `help-wanted`
+      </TITLE>
+
+      <BODY>
+      # Description
+
+      Increasingly, we get Pull Requests for issues that are not labelled `help-wanted`. I want an automated comment e.g. from `cliAutomation` that looks for issues that will be closed by the PR and if they don't have the label, informs the user of our contribution guide and what is likely to happen to their PR.
+
+      ## Expected Output
+
+      A workflow that runs when a PR is opened in non-draft mode, if the author is not on the team or a bot.
+
+      ### Notes
+
+      I do not expect this to happen when `ready_for_review` or when the PR description is edited to add a closing issue reference. While these might be valuable, it's extra work to maintain state on whether we previously commented or not, and I suspect `opened` is 90% of the value. We can adjust later if it is not.
+      </BODY>
+  - name: 'not spam, #11097 (https://github.com/cli/cli/issues/11097)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Duplicate Review Requests When Using `gh pr edit --add-reviewer`
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When running the command `gh pr edit --add-reviewer`, the specified reviewer receives two review requests instead of one. This causes the reviewer to approve the same pull request twice.
+
+      ### Affected version
+
+      ```
+      gh version 2.74.1 (2025-06-10)
+      https://github.com/cli/cli/releases/tag/v2.74.1
+      ```
+
+      ### Steps to reproduce the behavior
+
+      - Run the following command: `gh pr edit <PR_NUMBER> --add-reviewer <REVIEWER_IDS>`
+
+      ### Expected vs actual behavior
+
+      #### Expected
+      - The reviewer should receive only one review request
+      - The reviewer should need to approve only once
+
+      #### Actual
+      - The reviewer receives two separate review requests
+      - The reviewer must approve the PR twice for it to be fully approved
+
+      ### Logs
+
+      ```
+      [git remote -v]
+      [git config --get-regexp ^remote\..*\.gh-resolved$]
+      * Request at 2025-06-11 06:47:10.13476036[9](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:10) +0000 UTC m=+0.060470440
+      * Request to https://api.github.com/graphql
+      > POST /graphql HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Length: 657
+      > Content-Type: application/json; charset=utf-8
+      > Graphql-Features: merge_queue
+      > Time-Zone: Etc/UTC
+      > User-Agent: GitHub CLI 2.74.0
+
+      GraphQL query:
+      query PullRequestByNumber($owner: String!, $repo: String!, $pr_number: Int!) {
+          repository(owner: $owner, name: $repo) {
+            pullRequest(number: $pr_number) {id,url,title,body,baseRefName,reviewRequests(first: [10](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:11)0) {nodes {requestedReviewer {__typename,...on User{login},...on Team{organization{login}name,slug}}}},labels(first:100){nodes{id,name,description,color},totalCount},milestone{number,title,description,dueOn},assignedActors(first: 10) {nodes {...on User {id,login,name,__typename}...on Bot {id,login,__typename}},totalCount},number}
+          }
+        }
+      GraphQL variables: {"owner":"Mildwhale","pr_number":62,"repo":"app-deploy-slack-bot"}
+
+      < HTTP/2.0 200 OK
+      < Access-Control-Allow-Origin: *
+      < Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
+      < Content-Security-Policy: default-src 'none'
+      < Content-Type: application/json; charset=utf-8
+      < Date: Wed, [11](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:12) Jun 2025 06:47:10 GMT
+      < Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+      < Server: github.com
+      < Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
+      < Vary: Accept-Encoding, Accept, X-Requested-With
+      < X-Content-Type-Options: nosniff
+      < X-Frame-Options: deny
+      < X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
+      < X-Github-Request-Id: A009:223FC2:1F97927:3F1BC29:6849266E
+      < X-Ratelimit-Limit: 5000
+      < X-Ratelimit-Remaining: 4997
+      < X-Ratelimit-Reset: 1749628029
+      < X-Ratelimit-Resource: graphql
+      < X-Ratelimit-Used: 3
+      < X-Xss-Protection: 0
+
+      {
+        "data": {
+          "repository": {
+            "pullRequest": {
+              "id": "PR_kwDOFb5pX86Z-PaA",
+              "url": "https://github.com/Mildwhale/app-deploy-slack-bot/pull/62",
+              "title": "zzz",
+              "body": "",
+              "baseRefName": "master",
+              "reviewRequests": {
+                "nodes": []
+              },
+              "labels": {
+                "nodes": [],
+                "totalCount": 0
+              },
+              "milestone": null,
+              "assignedActors": {
+                "nodes": [],
+                "totalCount": 0
+              },
+              "number": 62
+            }
+          }
+        }
+      }
+
+      * Request took 216.91861ms
+      * Request at 2025-06-11 06:47:10.352963763 +0000 UTC m=+0.278673824
+      * Request to https://api.github.com/graphql
+      > POST /graphql HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Length: 470
+      > Content-Type: application/json
+      > Graphql-Features: merge_queue
+      > Time-Zone: Etc/UTC
+      > User-Agent: GitHub CLI 2.74.0
+
+      GraphQL query:
+      query PullRequestProjectItems($endCursor:String$name:String!$number:Int!$owner:String!){repository(owner: $owner, name: $name){pullRequest(number: $number){projectItems(first: 100, after: $endCursor){nodes{id,project{id,title},status:fieldValueByName(name: "Status"){... on ProjectV2ItemFieldSingleSelectValue{optionId,name}}},pageInfo{hasNextPage,endCursor}}}}}
+      GraphQL variables: {"endCursor":null,"name":"app-deploy-slack-bot","number":62,"owner":"Mildwhale"}
+
+      < HTTP/2.0 200 OK
+      < Access-Control-Allow-Origin: *
+      < Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
+      < Content-Security-Policy: default-src 'none'
+      < Content-Type: application/json; charset=utf-8
+      < Date: Wed, 11 Jun 2025 06:47:10 GMT
+      < Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+      < Server: github.com
+      < Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
+      < Vary: Accept-Encoding, Accept, X-Requested-With
+      < X-Content-Type-Options: nosniff
+      < X-Frame-Options: deny
+      < X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
+      < X-Github-Request-Id: A009:223FC2:1F97A33:3F1BE32:6849266E
+      < X-Ratelimit-Limit: 5000
+      < X-Ratelimit-Remaining: 4996
+      < X-Ratelimit-Reset: 1749628029
+      < X-Ratelimit-Resource: graphql
+      < X-Ratelimit-Used: 4
+      < X-Xss-Protection: 0
+
+      {
+        "data": {
+          "repository": {
+            "pullRequest": {
+              "projectItems": {
+                "nodes": [],
+                "pageInfo": {
+                  "hasNextPage": false,
+                  "endCursor": null
+                }
+              }
+            }
+          }
+        }
+      }
+
+      * Request took 174.997079ms
+      * Request at 2025-06-11 06:47:10.528196507 +0000 UTC m=+0.453906588
+      * Request to https://api.github.com/graphql
+      > POST /graphql HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Length: 45
+      > Content-Type: application/json
+      > Graphql-Features: merge_queue
+      > Time-Zone: Etc/UTC
+      > User-Agent: GitHub CLI 2.74.0
+
+      {
+        "query": "query UserCurrent{viewer{login}}"
+      }
+
+      * Request at 2025-06-11 06:47:10.528506341 +0000 UTC m=+0.4542164[12](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:13)
+      * Request to https://api.github.com/graphql
+      > POST /graphql HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Length: 401
+      > Content-Type: application/json
+      > Graphql-Features: merge_queue
+      > Time-Zone: Etc/UTC
+      > User-Agent: GitHub CLI 2.74.0
+
+      GraphQL query:
+      query RepositoryAssignableActors($endCursor:String$name:String!$owner:String!){repository(owner: $owner, name: $name){suggestedActors(first: 100, after: $endCursor, capabilities: CAN_BE_ASSIGNED){nodes{... on User{id,login,name,__typename},... on Bot{id,login,__typename}},pageInfo{hasNextPage,endCursor}}}}
+      GraphQL variables: {"endCursor":null,"name":"app-deploy-slack-bot","owner":"Mildwhale"}
+
+      * Request at 2025-06-11 06:47:10.528706338 +0000 UTC m=+0.454416419
+      * Request to https://api.github.com/graphql
+      > POST /graphql HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Length: 278
+      > Content-Type: application/json
+      > Graphql-Features: merge_queue
+      > Time-Zone: Etc/UTC
+      > User-Agent: GitHub CLI 2.74.0
+
+      GraphQL query:
+      query OrganizationTeamList($endCursor:String$owner:String!){organization(login: $owner){teams(first: 100, orderBy: {field: NAME, direction: ASC}, after: $endCursor){nodes{id,slug},pageInfo{hasNextPage,endCursor}}}}
+      GraphQL variables: {"endCursor":null,"owner":"Mildwhale"}
+
+      < HTTP/2.0 200 OK
+      < Access-Control-Allow-Origin: *
+      < Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
+      < Content-Security-Policy: default-src 'none'
+      < Content-Type: application/json; charset=utf-8
+      < Date: Wed, 11 Jun 2025 06:47:10 GMT
+      < Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+      < Server: github.com
+      < Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
+      < Vary: Accept-Encoding, Accept, X-Requested-With
+      < X-Content-Type-Options: nosniff
+      < X-Frame-Options: deny
+      < X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
+      < X-Github-Request-Id: A009:223FC2:1F97B1F:3F1C009:6849266E
+      < X-Ratelimit-Limit: 5000
+      < X-Ratelimit-Remaining: 4995
+      < X-Ratelimit-Reset: 1749628029
+      < X-Ratelimit-Resource: graphql
+      < X-Ratelimit-Used: 5
+      < X-Xss-Protection: 0
+
+      {
+        "data": {
+          "organization": null
+        },
+        "errors": [
+          {
+            "type": "NOT_FOUND",
+            "path": [
+              "organization"
+            ],
+            "locations": [
+              {
+                "line": 1,
+                "column": 61
+              }
+            ],
+            "message": "Could not resolve to an Organization with the login of 'Mildwhale'."
+          }
+        ]
+      }
+
+      * Request took 57.76367ms
+      < HTTP/2.0 200 OK
+      < Access-Control-Allow-Origin: *
+      < Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
+      < Content-Security-Policy: default-src 'none'
+      < Content-Type: application/json; charset=utf-8
+      < Date: Wed, 11 Jun 2025 06:47:10 GMT
+      < Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+      < Server: github.com
+      < Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
+      < Vary: Accept-Encoding, Accept, X-Requested-With
+      < X-Content-Type-Options: nosniff
+      < X-Frame-Options: deny
+      < X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
+      < X-Github-Request-Id: A009:223FC2:1F97B1E:3F1C002:6849266E
+      < X-Ratelimit-Limit: 5000
+      < X-Ratelimit-Remaining: 4994
+      < X-Ratelimit-Reset: 1749628029
+      < X-Ratelimit-Resource: graphql
+      < X-Ratelimit-Used: 6
+      < X-Xss-Protection: 0
+
+      {
+        "data": {
+          "viewer": {
+            "login": "github-actions[bot]"
+          }
+        }
+      }
+
+      * Request took 124.497[14](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:15)8ms
+      < HTTP/2.0 200 OK
+      < Access-Control-Allow-Origin: *
+      < Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
+      < Content-Security-Policy: default-src 'none'
+      < Content-Type: application/json; charset=utf-8
+      < Date: Wed, 11 Jun 2025 06:47:10 GMT
+      < Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+      < Server: github.com
+      < Strict-Transport-Security: max-age=3[15](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:16)36000; includeSubdomains; preload
+      < Vary: Accept-Encoding, Accept, X-Requested-With
+      < X-Content-Type-Options: nosniff
+      < X-Frame-Options: deny
+      < X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
+      < X-Github-Request-Id: A009:223FC2:1F97B1F:3F1C005:6849266E
+      < X-Ratelimit-Limit: 5000
+      < X-Ratelimit-Remaining: 4993
+      < X-Ratelimit-Reset: [17](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:18)49628029
+      < X-Ratelimit-Resource: graphql
+      < X-Ratelimit-Used: 7
+      < X-Xss-Protection: 0
+
+      {
+        "data": {
+          "repository": {
+            "suggestedActors": {
+              "nodes": [
+                {
+                  "id": "MDQ6VXNlcjMxMTM4MTA=",
+                  "login": "Mildwhale",
+                  "name": "Kyujin Kim",
+                  "__typename": "User"
+                }
+              ],
+              "pageInfo": {
+                "hasNextPage": false,
+                "endCursor": "Mg"
+              }
+            }
+          }
+        }
+      }
+
+      * Request took 334.424312ms
+      * Request at 2025-06-11 06:47:10.863264[18](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:19)2 +0000 UTC m=+0.788974253
+      * Request to https://api.github.com/graphql
+      > POST /graphql HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Length: 277
+      > Content-Type: application/json
+      > Graphql-Features: merge_queue
+      > Time-Zone: Etc/UTC
+      > User-Agent: GitHub CLI 2.74.0
+
+      GraphQL query:
+      mutation PullRequestUpdateRequestReviews($input:RequestReviewsInput!){requestReviews(input: $input){pullRequest{id}}}
+      GraphQL variables: {"input":{"pullRequestId":"PR_kwDOFb5pX86Z-PaA","userIds":["MDQ6VXNlcjMxMTM4MTA=","MDQ6VXNlcjMxMTM4MTA="],"teamIds":[],"union":false}}
+
+      * Request at 2025-06-11 06:47:10.864124385 +0000 UTC m=+0.789834456
+      * Request to https://api.github.com/graphql
+      > POST /graphql HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Length: 179
+      > Content-Type: application/json
+      > Graphql-Features: merge_queue
+      > Time-Zone: Etc/UTC
+      > User-Agent: GitHub CLI 2.74.0
+
+      GraphQL query:
+      mutation PullRequestUpdate($input:UpdatePullRequestInput!){updatePullRequest(input: $input){__typename}}
+      GraphQL variables: {"input":{"pullRequestId":"PR_kwDOFb5pX86Z-PaA"}}
+
+      < HTTP/2.0 200 OK
+      < Access-Control-Allow-Origin: *
+      < Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
+      < Content-Security-Policy: default-src 'none'
+      < Content-Type: application/json; charset=utf-8
+      < Date: Wed, 11 Jun 2025 06:47:11 GMT
+      < Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+      < Server: github.com
+      < Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
+      < Vary: Accept-Encoding, Accept, X-Requested-With
+      < X-Content-Type-Options: nosniff
+      < X-Frame-Options: deny
+      < X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
+      < X-Github-Request-Id: A009:223FC2:1F97CE8:3F1C35E:6849266E
+      < X-Ratelimit-Limit: 5000
+      < X-Ratelimit-Remaining: 4991
+      < X-Ratelimit-Reset: 1749628029
+      < X-Ratelimit-Resource: graphql
+      < X-Ratelimit-Used: 9
+      < X-Xss-Protection: 0
+
+      {
+        "data": {
+          "requestReviews": {
+            "pullRequest": {
+              "id": "PR_kwDOFb5pX86Z-PaA"
+            }
+          }
+        },
+        "extensions": {
+          "warnings": [
+            {
+              "type": "DEPRECATION",
+              "message": "The id MDQ6VXNlcjMxMTM4MTA= is deprecated. Update your cache to use the next_global_id from the data payload.",
+              "data": {
+                "legacy_global_id": "MDQ6VXNlcjMxMTM4MTA=",
+                "next_global_id": "U_kgDOAC-DUg"
+              },
+              "link": "https://docs.github.com"
+            },
+            {
+              "type": "DEPRECATION",
+              "message": "The id MDQ6VXNlcjMxMTM4MTA= is deprecated. Update your cache to use the next_global_id from the data payload.",
+              "data": {
+                "legacy_global_id": "MDQ6VXNlcjMxMTM4MTA=",
+                "next_global_id": "U_kgDOAC-DUg"
+              },
+              "link": "https://docs.github.com"
+            }
+          ]
+        }
+      }
+
+      * Request took 273.085601ms
+      < HTTP/2.0 200 OK
+      < Access-Control-Allow-Origin: *
+      < Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
+      < Content-Security-Policy: default-src 'none'
+      < Content-Type: application/json; charset=utf-8
+      < Date: Wed, 11 Jun 2025 06:47:11 GMT
+      < Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+      < Server: github.com
+      < Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
+      < Vary: Accept-Encoding, Accept, X-Requested-With
+      < X-Content-Type-Options: nosniff
+      < X-Frame-Options: deny
+      < X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
+      < X-Github-Request-Id: A009:223FC2:1F97CE9:3F1C362:6849266E
+      < X-Ratelimit-Limit: 5000
+      < X-Ratelimit-Remaining: 4992
+      < X-Ratelimit-Reset: 1749628029
+      < X-Ratelimit-Resource: graphql
+      < X-Ratelimit-Used: 8
+      < X-Xss-Protection: 0
+
+      {
+        "data": {
+          "updatePullRequest": {
+            "__typename": "UpdatePullRequestPayload"
+          }
+        }
+      }
+
+      * Request took 300.5679[19](https://github.com/Mildwhale/app-deploy-slack-bot/actions/runs/15577973994/job/43866492547#step:5:20)ms
+      ```
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+
+      ### Log Analysis
+
+      While analyzing the internal GraphQL request made by the CLI, I found that the userIds field contains the same user ID twice, which likely causes the duplication:
+
+      ```graphql
+      GraphQL query:
+      mutation PullRequestUpdateRequestReviews($input:RequestReviewsInput!){requestReviews(input: $input){pullRequest{id}}}
+      GraphQL variables: {"input":{"pullRequestId":"PR_kwDOJ1e7tM6Z-KSE","userIds":["MDQ6VXNlcjMxMTM4MTA=","MDQ6VXNlcjMxMTM4MTA="],"teamIds":["T_kwDOAsZIZs4Afapn"],"union":false}}
+      ```
+      As shown above, the same userId is passed twice in the mutation request.
+      </BODY>
+  - name: 'not spam, #11095 (https://github.com/cli/cli/issues/11095)'
+    expected: PASS
+    input: "<TITLE>\nImprove branch name generation for issues with international characters\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you'd like to solve\n\nWhen using `gh issue develop <issue_id> --checkout` to create branches from issues that contain international characters (accents, diacritics, non-ASCII characters), the generated branch names should be valid Git branch names while preserving readability.\n\nCurrently, users with issue titles containing characters like:\n- French: \"Créer les tâches avec açã\" \n- Spanish: \"Añadir función para niños\"\n- Mixed special characters: \"!@#$%^&*()\"\n\nMay encounter problems when the CLI attempts to create Git branches, as Git has strict naming requirements that don't allow many Unicode characters.\n\n### Proposed solution\n\nImplement intelligent character normalization for branch name generation that:\n\n1. **Transliterates accented characters** to their ASCII equivalents:\n   - é, è, ê → e\n   - ç → c  \n   - ñ → n\n   - ã, á, à → a\n\n2. **Handles edge cases gracefully**:\n   - Converts spaces to hyphens\n   - Removes or converts special characters that aren't Git-safe\n   - Falls back to issue number if title has no valid characters\n   - Maintains issue number prefix for uniqueness\n\n3. **Examples of expected behavior**:\n   - \"Créer les tâches avec açã\" → `456-creer-les-taches-avec-aca`\n   - \"Añadir función para niños\" → `789-anadir-funcion-para-ninos`  \n   - \"!@#$%^&*()\" → `999` (fallback to number only)\n\n### Additional context\n\nThis feature would benefit:\n- **International users** who write issues in their native languages\n- **Global teams** working across different locales\n- **Open source projects** with contributors worldwide\n\nThe solution should maintain Git compatibility while preserving as much semantic meaning as possible from the original issue title. This ensures branch names remain recognizable and meaningful to developers while being technically valid.\n</BODY>"
+  - name: 'not spam, #11090 (https://github.com/cli/cli/issues/11090)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Decouple arg/URL parsing from PR finder in `pr` commands
+      </TITLE>
+
+      <BODY>
+      Follow-up to #11057
+
+      As a follow-up to the temporary fix we made in #11057, we should do a proper fix by decoupling arg parsing from PR finder. @williammartin has already explained what needs to be done in the PR's description and the code.
+
+      Since this is a refactoring task, there should be no observable changes. Specifically, The affected/refactored `pr` subcommands (e.g. `pr edit` or `pr view`) must support PR URLs as argument.
+
+      ### Expected Outcomes
+
+      - Existing tests related to affected `pr` commands will still pass
+      </BODY>
+  - name: 'not spam, #11089 (https://github.com/cli/cli/issues/11089)'
+    expected: PASS
+    input: "<TITLE>\nAdd isLatest to Release Json fields\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\n\nIsLatest is a key flag when working with releases.\nHappens that although this field is part of the graphQL query for releases is not part of the valid JSON fields when using the --JSON option\n\nI propose to add the isLatest field as a valid JSON field when listing releases\n\n### Proposed solution\n\nThis will allow the use of `gh release list --json id,isLatest` to list available releases and find the latests for later, maybe, download the artifacts on the release that many times is the valid app binary.\n\nThis enables repo release to ve a valid deploy system as gh extensions install does.\n\n### Additional context\n\nIs a very low risk change. \nJust 3 lines in 2 files.\nAlready tested in fork `rulasg/github-cli` branch [`rulasg-add-isLatest-to-release`](https://github.com/rulasg/github-cli/tree/rulasg-add-isLatest-to-release)\n\n```sh\nvscode ➜ /workspaces/cli (rulasg-add-isLatest-to-release) $ go run ./cmd/gh/main.go release list -R rulasg/gh-kk --json tagName,isLatest\n[\n  {\n    \"isLatest\": true,\n    \"tagName\": \"v0.1.2-preview\"\n  },\n  {\n    \"isLatest\": false,\n    \"tagName\": \"v0.2.0-preview\"\n  },\n  {\n    \"isLatest\": false,\n    \"tagName\": \"v0.1.1-preview\"\n  },\n  {\n    \"isLatest\": false,\n    \"tagName\": \"v0.1.0\"\n  }\n]\n```\n\n### Patch file\n\n```sh\nvscode ➜ /workspaces/cli (rulasg-add-release-islatest) $ cat staged_changes.patch \ndiff --git a/pkg/cmd/release/shared/fetch.go b/pkg/cmd/release/shared/fetch.go\nindex 4c0a014b9..8c54784bf 100644\n--- a/pkg/cmd/release/shared/fetch.go\n+++ b/pkg/cmd/release/shared/fetch.go\n@@ -29,6 +29,7 @@ var ReleaseFields = []string{\n        \"databaseId\",\n        \"id\",\n        \"isDraft\",\n+       \"isLatest\",\n        \"isPrerelease\",\n        \"name\",\n        \"publishedAt\",\n@@ -47,6 +48,7 @@ type Release struct {\n        Name         string     `json:\"name\"`\n        Body         string     `json:\"body\"`\n        IsDraft      bool       `json:\"draft\"`\n+       IsLatest     bool       `json:\"latest\"`\n        IsPrerelease bool       `json:\"prerelease\"`\n        CreatedAt    time.Time  `json:\"created_at\"`\n        PublishedAt  *time.Time `json:\"published_at\"`\ndiff --git a/pkg/cmd/release/view/view_test.go b/pkg/cmd/release/view/view_test.go\nindex be345b186..bc98819f4 100644\n--- a/pkg/cmd/release/view/view_test.go\n+++ b/pkg/cmd/release/view/view_test.go\n@@ -30,6 +30,7 @@ func TestJSONFields(t *testing.T) {\n                \"databaseId\",\n                \"id\",\n                \"isDraft\",\n+               \"isLatest\",\n                \"isPrerelease\",\n                \"name\",\n                \"publishedAt\",\n````\n</BODY>"
+  - name: 'not spam, #11064 (https://github.com/cli/cli/issues/11064)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `pr edit --add-assignee` drops unspecified current assignees
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      Found by @williammartin.
+
+      `gh pr edit --add-assignee` drops any current assignees on the issue. Likely only a problem on GitHub.com and not on GHES due to Actor assignee changes around making Copilot assignable.
+
+      ### Affected version
+
+      gh version 2.74.0 (2025-05-29)
+      https://github.com/cli/cli/releases/tag/v2.74.0
+
+      ### Steps to reproduce the behavior
+
+      1. Have issue with `foo` assigned.
+      2. `gh pr edit 1234 --add-assignee bar`
+      3. `foo` gets unassigned and `bar` gets assigned.
+
+      ### Expected vs actual behavior
+
+      Current assignees must be preserved.
+      </BODY>
+  - name: 'not spam, #11012 (https://github.com/cli/cli/issues/11012)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Add tests to presentation functions used in `run watch` and `run view`
+      </TITLE>
+
+      <BODY>
+      The `run watch` and `run view` commands use `RenderJobs` and `RenderJobsCompact` functions to display that status of a workflow run. However, we do not have proper tests for them. This issue is about adding tests for those functions.
+
+      Related to #10629
+
+      ## Expected Output
+
+      We have tests for `RenderJobs` and `RenderJobsCompact` covering various scenarios.
+      </BODY>
+  - name: 'not spam, #10981 (https://github.com/cli/cli/issues/10981)'
+    expected: PASS
+    input: "<TITLE>\n`gh release create` occasionally returns `502 Bad Gateway`\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nWe call `gh release create` as part of our GitHub Actions workflow when we merge to `main`. Seemingly random, this will fail with `502 Bad Gateway`. \n\n### Affected version\n\nVersion: `GitHub CLI 2.72.0`\n\n### Steps to reproduce the behavior\n\nCannot reproduce, but the following is our workflow:\n\n1. Call this in a workflow: `gh release create \"v25-05-13-1354\" --generate-notes --latest`\n2. Sometimes, this fails and returns `502 Bad Gateway`\n\n### Expected vs actual behavior\n\nI expect this to rarely fail (unless GitHub experiences an outage). But in reality, I'd say we see this fail in ~1/10 merges to `main`.\n\n### Logs\n\n<details><summary>Debug logs</summary>\n\n```\n* Request at 2025-05-13 14:04:21.237906816 +0000 UTC m=+0.186359355\n* Request to https://api.github.com/repos/myorg/myrepo/releases\n> POST /repos/myorg/myrepo/releases HTTP/1.1\n> Host: api.github.com\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\n> Authorization: token\n> Content-Length: 1[13](https://github.com/myorg/myrepo/actions/runs/14998244591/job/42139547476#step:3:14)\n> Content-Type: application/json; charset=utf-8\n> Time-Zone: Etc/UTC\n> User-Agent: GitHub CLI 2.72.0\n\n{\n  \"draft\": false,\n  \"generate_release_notes\": true,\n  \"make_latest\": \"true\",\n  \"prerelease\": false,\n  \"tag_name\": \"v25-05-13-1354\"\n}\n\n< HTTP/2.0 502 Bad Gateway\n< Content-Length: 32\n< Content-Type: application/json\n< Date: Tue, 13 May 2025 [14](https://github.com/myorg/myrepo/actions/runs/14998244591/job/42139547476#step:3:15):04:31 GMT\n< Etag: \"68234d0e-20\"\n< Server: github.com\n< Vary: Accept-Encoding, Accept, X-Requested-With\n< X-Github-Request-Id: 1C00:14D949:84C01F:109FFAB:68235[16](https://github.com/myorg/myrepo/actions/runs/14998244591/job/42139547476#step:3:17)5\n\n{\n  \"message\": \"Server Error\"\n}\n\n* Request took 10.28[17](https://github.com/myorg/myrepo/actions/runs/14998244591/job/42139547476#step:3:18)85163s\nHTTP 502: Server Error (https://api.github.com/repos/myorg/myrepo/releases)\n```\n\n</details> \n</BODY>"
+  - name: 'not spam, #10976 (https://github.com/cli/cli/issues/10976)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Fix none-echo mode flaky tests
+      </TITLE>
+
+      <BODY>
+      The accessible prompter tests that check the none-echo mode are still a bit flaky. For example, I observed this failure:
+      https://github.com/cli/cli/actions/runs/14992835636/job/42120038531?pr=10975#step:5:44
+
+      For now, it makes sense to increase `beforePasswordSendTimeout` from 20 us to 100us to make sure there's enough time for `huh` to set the none-echo mode. Since the sleep is very small this seems like a viable solution. If we again see the flaky behaviour, then we might want to try another approach (e.g. waiting for the terminal configuration to be set before sending in the password/token, as suggested by @williammartin).
+      </BODY>
+  - name: 'not spam, #10972 (https://github.com/cli/cli/issues/10972)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Support `--from-file` flag for `gh issue create`
+      </TITLE>
+
+      <BODY>
+      ### Description
+
+      It would be helpful to have a `--from-file` flag for the `gh issue create` command, similar to the `--body-file` flag, allowing users to create issues by passing a file with structured data containing all the required information (e.g., title, body, labels, assignees).
+
+      **Note: This is not a request for attaching a file to an issue.**
+
+      **Note: This is not a request for using a file as an issue template.**
+
+      Context: I (and certain colleagues) regularly create notes in a text file for creation as "new issues" and adding to a specific repository and project; adding the issues in GitHub "as I go" takes me away from the focus and flow of the things I'm working on, so I make notes about what issues need to be created, and batch create them later.
+
+      If the suggested option existed, I would add each new issue to a document containing segments of structured data instead (at present, I'm usually using Markdown to take these notes, so turning the content into YAML isn't a big stretch).
+
+      I would either write using one-issue-per-file and iterate this new `gh` command over multiple files, or put all the issues into one file with delimiters. Either option would only need some very light scripting, and creation of new issues *en masse* from my text file "notes" would then be significantly streamlined.
+
+      ### Proposed Solution
+
+      * Simplifies creating complex issues with multiple fields pre-defined.
+      * Useful for automation and scripting, allowing users to define issue templates in YAML/JSON format and reuse them.
+      * Enhances consistency in issue creation for teams working on large projects.
+
+      ### (One) Suggested Implementation
+
+      1. Add support for a `--from-file` flag that accepts a file with structured data (exact flag name subject to suitable bikeshedding…)
+      1. Whether structured data *format* is YAML, JSON, TOML or something else is irrelevant to me; but IMHO multiple formats seems like a doable idea (will use YAML in the following examples).
+      1. Example Invocation: `gh issue create --from-file issue.yml`
+      1. The file should allow specifying fields such as:
+      	* title
+      	* body
+      	* labels
+      	* assignees
+      	* milestone
+      	* project
+      1. Validate the structure of the file and provide helpful error messages if required fields are missing or invalid.
+      1. If structure is valid, create a new issue and provide the CLI user a URL directly to the newly-created issue.
+
+      ### Example issue file
+
+      #### YAML file (issue.yml):
+      ```yaml
+      title: "Feature request: Support `--from-file` flag"
+      body: |
+        It would be great if `gh issue create` supported a `--from-file` flag.
+        This would simplify scripting and automation for issue creation.
+      labels:
+        - enhancement
+        - core
+      assignees:
+        - Cueball
+      milestone: "v3.0"
+      project: "New Features Project"
+      ```
+      </BODY>
+  - name: 'not spam, #10962 (https://github.com/cli/cli/issues/10962)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      feature request: add package management sub-command for gh CLI
+      </TITLE>
+
+      <BODY>
+      Hello GitHub team,
+      I want to propose a new sub-command for managing GitHub packages using gh CLI.
+
+      ```{zsh}
+      gh package <sub-command>
+      ```
+      </BODY>
+  - name: 'not spam, #10958 (https://github.com/cli/cli/issues/10958)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      gh pr edit --remove-reviewer does not work when removing all reviewers
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      I can request a review from a team for a pull-request using the following command:
+
+      ```bash
+      gh pr edit 180 --add-reviewer <org>/<team-name> --repo <org-name>/<repo-name>
+      ```
+
+      But I can not remove the same team with the following command:
+
+      ```bash
+      gh pr edit 180 --remove-reviewer <org>/<team-name> --repo <org-name>/<repo-name>
+      ```
+
+      (it works for regular users)
+
+      The CLI exits with code 0 and no error is logged, but the team is not removed from the PR.
+      I can remove the team through the PR UI though.
+
+      The repository is an internal one and I'm an owner of the organization.
+
+      ### Affected version
+
+      2.72.0
+      </BODY>
+  - name: 'not spam, #10957 (https://github.com/cli/cli/issues/10957)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Add an example of `--head` option usage to `pr list` docs
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      Related to #10945
+
+      As a small improvement, another example should be added to `pr list` docs to show how the `--head` option can be used. Something like this:
+
+      ```
+      EXAMPLES
+        ...
+
+        # List PRs with a specific head branch name
+        $ gh pr list --head "typo"
+      ```
+
+      The reason I'm suggesting this is that the `--head` option does not work with values formatted as `<owner>:<branch>`. It's actually our API's limit. We cannot explicitly say this in `gh` docs, because it's an undocumented behaviour which may change in the future; especially since branch names cannot include `:`, supporting this new format in the API will not be a breaking change.
+
+      ## Acceptance Criteria
+
+      **When** I run `gh pr list --help`
+      **Then** the docs include an example of the `--head` option usage
+      </BODY>
+  - name: 'not spam, #10953 (https://github.com/cli/cli/issues/10953)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Return value not documented
+      </TITLE>
+
+      <BODY>
+      # CLI Feedback
+
+      ## What was confusing or gave you pause?
+
+      I think "gh pr create" outputs the URL of the PR, right? Shouldn't that be in the docs? https://cli.github.com/manual/gh_pr_create
+      </BODY>
+  - name: 'not spam, #10936 (https://github.com/cli/cli/issues/10936)'
+    expected: PASS
+    input: "<TITLE>\nAccessible prompter: default selections not always printed, not clear, or sometimes not readable by speech synthesis\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nDefault values in the accessible prompter are not indicated and sometimes not respected at all like they are with the other prompter.\n\n### Steps to reproduce the behavior\n\nAs one example, the multi select form does not indicate which options are selected aside from the checkmarks, which as far as I can tell, are _not guaranteed to be audible by speech synthesis_.\n\n```\nAssignees\n1.   ✓ BagToad\n\nSelect up to 1 options. 0 to continue.\n\n```\n\nAnother example is the select form, which does not indicate the default selection at all - below if I press enter, `BagToad` is selected.\n\n```\nRepository owner\n1. BagToad\n<snip>\nInput a number between 1 and 17: \n```\n\nAnother example is the text input, which has a couple issues. It displays empty parenthesis when there is no default, and displays no _readable text_ that indicates what is being spoken is the default value.\n\n```\nRepository name ()\n\nInput: \n```\n\nThis list is not exhaustive - we need to look through all the prompters and harmonize how we display defaults \U0001F914 \n\n### Expected vs actual behavior\n\nEvery a11y prompt needs to display its defaults in a way that is readable by speech synthesis. Brief example:\n\n```\nWould you like to add a .gitignore? (default: No)\n\nChoose [y/N]: \n```\n\n☝ The change being the addition of `(default: No)`\n</BODY>"
+  - name: 'not spam, #10916 (https://github.com/cli/cli/issues/10916)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      FAIL: TestAccessiblePrompter/AuthToken_-_blank_input_returns_error
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+      Hello,
+      we're building `gh` for openSUSE a SUSE Linux and new error in tests just appeared:
+
+      ```
+      [   91s] ?   	github.com/cli/cli/v2/internal/keyring	[no test files]
+      [   93s] --- FAIL: TestAccessiblePrompter (1.04s)
+      [   93s]     --- FAIL: TestAccessiblePrompter/AuthToken_-_blank_input_returns_error (1.00s)
+      [   93s]         expect.go:76: Failed to find [" \r\n\r\n"] in "\r\nPaste your authentication token: 12345abcdefg\r\n\r\n\r\n": read |0: i/o timeout
+      [   93s] FAIL
+      [   93s] FAIL	github.com/cli/cli/v2/internal/prompter	1.049s
+      ```
+
+      ### Affected version
+
+      `v2.72.0`
+
+      ### Steps to reproduce the behavior
+
+      ```
+      cd /home/abuild/rpmbuild/BUILD
+      cd cli-2.72.0
+      GOFLAGS='-buildmode=pie -trimpath -mod=vendor -modcacherw'
+      make test
+      ```
+
+      ### Expected vs actual behavior
+
+      The previous version (v2.70.0 in our case) passed the tests just fine.
+      I'm aware that this is new functionality and that the error might be specific to Open Build Service which we use for packaging.
+
+      ### Logs
+
+      The full log is available on [build.opensuse.org/package/live_build_log/home:pdostal:branches:devel:tools:scm/gh/openSUSE_Tumbleweed/x86_64](https://build.opensuse.org/package/live_build_log/home:pdostal:branches:devel:tools:scm/gh/openSUSE_Tumbleweed/x86_64)
+      </BODY>
+  - name: 'not spam, #10900 (https://github.com/cli/cli/issues/10900)'
+    expected: PASS
+    input: "<TITLE>\nAccessible multi-select prompter does not respect defaults\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nAccessible multi-select prompter does not respect defaults. This can be seen in commands like `gh issue edit`\n\n### Affected version\n\n```\n❯ gh version                                 \ngh version 2.71.0 (2025-04-23)\nhttps://github.com/cli/cli/releases/tag/v2.71.0\n```\n\n### Steps to reproduce the behavior\n\nWith an issue that already has assignees:\n\n1. `GH_ACCESSIBLE_PROMPTER=true gh issue edit <number>`\n2. Select `Assignees`\n3. See that the currently assigned users are not already selected.\n\n### Expected vs actual behavior\n\nDefaults should be respected. Compare to non-accessible prompter.\n\n### Logs\n\n```\n❯ GH_ACCESSIBLE_PROMPTER=true gh issue edit 1\nWhat would you like to edit?\n1.   Title\n2.   Body\n3.   Assignees\n4.   Labels\n5.   Projects\n6.   Milestone\n\nSelect up to 6 options. 0 to continue.\nSelect: 3\nSelected: Assignees\n\nWhat would you like to edit?\n1.   Title\n2.   Body\n3. ✓ Assignees\n4.   Labels\n5.   Projects\n6.   Milestone\n\nSelect up to 6 options. 0 to continue.\nSelect: 0\nSelected: Assignees\n                   \nAssignees\n1.   BagToad\n\n```\n</BODY>"
+  - name: 'not spam, #10887 (https://github.com/cli/cli/issues/10887)'
+    expected: PASS
+    input: "<TITLE>\nExpected error message in `TestRepo/repo-rename-transfer-ownership` acceptance test is out of date\n</TITLE>\n\n<BODY>\nSimilar to #10883, another test in the acceptance tests suite is failing because we are asserting an outdated message.\n\nIn this test, we are expecting to receive\n\n> New repository name cannot contain '/' character - to transfer a repository to a new owner, you must follow additional steps on GitHub.com. For more information on transferring repository ownership, see <https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository>. \n\nBut we receive\n\n> New repository name cannot contain '/' character - to transfer a repository to a new owner, you must follow additional steps on **<github.com>**. For more information on transferring repository ownership, see <https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository>.\n</BODY>"
+  - name: 'not spam, #10883 (https://github.com/cli/cli/issues/10883)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Expected error message in `TestRepo/repo-set-default` acceptance test is out of date
+      </TITLE>
+
+      <BODY>
+      While running acceptance tests, I found that one test is failing because the error message we expect (and validate) is different than the error message we are receiving.
+
+      While running `TestRepo/repo-set-default`, we do:
+
+      ```
+      # Ensure that no default is set
+      cd $SCRIPT_NAME-$RANDOM_STRING
+      exec gh repo set-default --view
+      stderr 'no default repository has been set; use `gh repo set-default` to select one'
+      ```
+
+      But the output while running the test is:
+
+      ```
+      # Ensure that no default is set (2.091s)
+      > cd $SCRIPT_NAME-$RANDOM_STRING
+      $WORK/repo_set_default-oaJIlaRWss
+      > exec gh repo set-default --view
+      [stderr]
+      X No default remote repository has been set. To learn more about the default repository, run: gh repo set-default --help
+      > stderr 'no default repository has been set; use `gh repo set-default` to select one'
+      FAIL: testdata/repo/repo-set-default.txtar:10: no match for "no default repository has been set; use `gh repo set-default` to select one" found in stderr
+      ```
+
+      If I change the test to do:
+
+      ```
+      # Ensure that no default is set
+      cd $SCRIPT_NAME-$RANDOM_STRING
+      exec gh repo set-default --view
+      stderr 'No default remote repository has been set. To learn more about the default repository, run: gh repo set-default --help'
+      ```
+
+      then the test passes.
+      </BODY>
+  - name: 'not spam, #10862 (https://github.com/cli/cli/issues/10862)'
+    expected: PASS
+    input: "<TITLE>\nCreating PR cannot determine remote branch name\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nUsing `gh pr create` to create a new pull request fails whereas previously it worked.\n\n### Affected version\n\nPlease run `gh version` and paste the output below.\n\n```\ngh version 2.71.1 (2025-04-24)\nhttps://github.com/cli/cli/releases/tag/v2.71.1\n```\n\n### Steps to reproduce the behavior\n\n1. Create new branch\n2. Create a commit\n3. Run `gh pr create`\n4. See error `could not determine remote branch name`\n\n### Expected vs actual behavior\n\nI expect to be asked to provide the pull request details e.g. title.\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n```\n$ GH_DEBUG=true gh pr create --assignee cs278 \n[git remote -v]\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\n* Request at 2025-04-24 16:28:54.65877698 +0100 BST m=+0.201817171\n* Request to https://api.github.com/graphql\n* Request took 401.056089ms\n[git status --porcelain]\n[git symbolic-ref --quiet HEAD]\n[git config --get-regexp ^branch\\.issue/8670-update-docs\\.(remote|merge|pushremote|gh-merge-base)$]\n[git rev-parse --symbolic-full-name issue/8670-update-docs@{push}]\n[git config push.default]\ncould not determine remote branch name\n```\n</BODY>"
+  - name: 'not spam, #10857 (https://github.com/cli/cli/issues/10857)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh pr create --web` fails if branch name contains a forward slash
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      I have a branch created with a name of `TICKET/test-name`. In github-cli versions prior to 2.71.0, `gh pr create --web` worked successfully. As of 2.71.0, the command fails with an error:
+
+      ```
+      ➜ gh pr create --web
+      remote tracking branch must have format refs/remotes/<remote>/<branch> but was: refs/remotes/origin/TICKET/test-name
+      ```
+
+      ### Affected version
+
+      Please run `gh version` and paste the output below.
+
+      ```
+      ➜ gh version
+      gh version 2.71.0 (2025-04-23)
+      ```
+
+      ### Steps to reproduce the behavior
+
+      1. Create a branch with a name containing a forward slash.
+      2. Run `gh pr create --web`
+      3. See error
+
+      ### Expected vs actual behavior
+
+      I'd expect the PR to be created successfully.
+
+      ### Logs
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+
+      ```
+      ➜ GH_DEBUG=true gh pr create --web
+      [git remote -v]
+      [git config --get-regexp ^remote\..*\.gh-resolved$]
+      * Request at 2025-04-24 15:06:27.579786 +0900 JST m=+0.115545042
+      * Request to https://api.github.com/graphql
+      * Request took 749.412042ms
+      [git status --porcelain]
+      [git symbolic-ref --quiet HEAD]
+      [git config --get-regexp ^branch\.TICKET/test-name\.(remote|merge|pushremote|gh-merge-base)$]
+      [git rev-parse --symbolic-full-name TICKET/test-name@{push}]
+      [git config push.default]
+      [git config remote.pushDefault]
+      [git show-ref --verify -- HEAD refs/remotes/origin/TICKET/test-name]
+      remote tracking branch must have format refs/remotes/<remote>/<branch> but was: refs/remotes/origin/TICKET/test-name
+      ```
+      </BODY>
+  - name: 'not spam, #10852 (https://github.com/cli/cli/issues/10852)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Investigate upgrading to the latest `charmbracelet/huh` release (v0.7.0)
+      </TITLE>
+
+      <BODY>
+      In order to upgrade `gh` dependency on `charmbracelet/huh` to the latest version (v0.7.0, as of now), we have to investigate the changes made to the module and make sure the accessibility support in `gh` is not impacted.
+
+      ## Expected Output
+
+      - Create improvement issues in `cli/cli` or `charmbracelet/huh`, if required.
+      - Upgrade `huh` to 0.7.0 if feasible
+      </BODY>
+  - name: 'not spam, #10851 (https://github.com/cli/cli/issues/10851)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Add Resume Support for gh run download Command
+      </TITLE>
+
+      <BODY>
+      Currently, the gh run download <id> command does not support resuming a partially downloaded artifact if the download is interrupted. This limitation forces users to restart the download from the beginning, which can be inefficient and result in unnecessary energy and bandwidth usage, especially for large artifacts.
+
+      I would like to request adding a resume feature to the gh run download command. This would allow users to continue a failed or interrupted download from where it left off, improving the overall efficiency of the tool.
+
+      Thank you for considering this suggestion. I believe it would greatly enhance the usability of the GitHub CLI.
+      </BODY>
+  - name: 'not spam, #10797 (https://github.com/cli/cli/issues/10797)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh release download` errors confusingly when release is a draft
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      Running `gh release download` targeting a draft release errors in a confusing manner:
+
+      ```
+      ➜ gh release download v0.0.2 --archive=zip
+      Get "": unsupported protocol scheme ""
+      ```
+
+      ### Affected version
+
+      Please run `gh version` and paste the output below.
+
+      ### Steps to reproduce the behavior
+
+      Steps to reproduce the behavior:
+
+      1. Create a draft release
+      1. Set it to use a tag that will be created when the release is published
+      1. Save it but don't publish it
+      1. Use the `gh release download -R org/repo <tag-from-step-2> --archive=zip`
+      1. Watch the GitHub CLI throw the Get "": unsupported protocol scheme "" error
+
+      This occurs because we attempt to use the `zipball_url`, which is unmarshaled into an empty string here: https://github.com/cli/cli/blob/408e21ebdddf9cd14289e49135389a6e5125eff4/pkg/cmd/release/download/download.go#L168
+
+      ```
+      > GET /repos/williammartin-test-org/test-repo/releases/212464261 HTTP/1.1
+      > Host: api.github.com
+      > Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
+      > Authorization: token ████████████████████
+      > Content-Type: application/json; charset=utf-8
+      > Time-Zone: Europe/Amsterdam
+      > User-Agent: GitHub CLI 2.68.0
+
+      ...
+
+      {
+        "url": "https://api.github.com/repos/williammartin-test-org/test-repo/releases/212464261",
+      ...
+        "tarball_url": null,
+        "zipball_url": null,
+        "body": ""
+      }
+      ```
+      </BODY>
+  - name: 'not spam, #10768 (https://github.com/cli/cli/issues/10768)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Resolve to new job run log when both old and new logs are present
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      > [!NOTE]
+      > This is a follow up to [this](https://github.com/cli/cli/pull/10740#issuecomment-2789634995) comment on #10740.
+
+      Sometimes when the CLI downloads the ZIP archive of a workflow run, *two* top-level `.txt` files are in the archive, both of which supposed to contain the logs for an entire *job* run. Here is an example:
+
+      ```
+      $ gh run view --log -R cli/cli 14233257584
+      $ unzip -l ~/.cache/gh/run-log-14233257584-1743645262.zip
+      Archive:  run-log-14233257584-1743645262.zip
+        Length      Date    Time    Name
+      ---------  ---------- -----   ----
+            808  2025-04-03 17:30   issue-auto/2_label incoming issue.txt
+            510  2025-04-03 17:30   -2147483648_issue-auto.txt                      <<< Here
+              0  2025-04-03 17:30   issue-auto/
+           2580  2025-04-03 17:30   0_issue-auto.txt                                <<< & here
+           1289  2025-04-03 17:30   issue-auto/1_Set up job.txt
+             58  2025-04-03 17:30   issue-auto/3_Complete job.txt
+      ---------                     -------
+           5245                     6 files
+      ```
+
+      Here, both normal and legacy top-level `.txt` files are there, and their contents are different (See below). Supposedly, The legacy file (i.e., `-2147483648_issue-auto.txt`) should be produced by the API when it couldn't find the data of a run; however, in this case, this is not a correct assumption.
+
+      For this particular example, since the step logs are also there, when we do `gh run view --log` the output is fine because the step logs are the preferred source of data for the CLI.
+
+      The problem surfaces when there are no step logs. In such cases CLI falls back to display the entire job run log, and to do that it picks one of the top-level `.txt` files, depending on the ZIP content's ordering. The implementation should be fixed so that it prefers the `0_issue-auto.txt` over the legacy log file (i.e., `-2147483648_issue-auto.txt`).
+
+      ## File contents
+
+      **`-2147483648_issue-auto.txt`:**
+      ```
+      2025-04-03T01:54:23.1894394Z ##[section]Starting: Prepare job issue-auto
+      2025-04-03T01:54:23.1896693Z Evaluating strategy
+      2025-04-03T01:54:23.1901835Z Creating job '__default'
+      2025-04-03T01:54:23.1904320Z Evaluating timeout
+      2025-04-03T01:54:23.1904373Z Evaluating cancel timeout
+      2025-04-03T01:54:23.1904415Z Evaluating continue on error
+      2025-04-03T01:54:23.1904441Z Evaluating target
+      2025-04-03T01:54:23.1904913Z Evaluating environment
+      2025-04-03T01:54:23.1906350Z ##[section]Finishing: Prepare job issue-auto
+      ```
+
+      **`0_issue-auto.txt`:**
+      ```
+      2025-04-03T01:54:23.7907259Z Requested labels: ubuntu-latest
+      2025-04-03T01:54:23.7907520Z Job defined at: cli/cli/.github/workflows/issueauto.yml@refs/heads/trunk
+      2025-04-03T01:54:23.7907618Z Waiting for a runner to pick up this job...
+      2025-04-03T01:54:24.2730185Z Job is waiting for a hosted runner to come online.
+      2025-04-03T01:54:26.9708943Z Job is about to start running on the hosted runner: GitHub Actions 693 (hosted)
+      2025-04-03T01:54:28.8828327Z Current runner version: '2.323.0'
+      2025-04-03T01:54:28.8857448Z ##[group]Operating System
+      2025-04-03T01:54:28.8858217Z Ubuntu
+      2025-04-03T01:54:28.8858729Z 24.04.2
+      2025-04-03T01:54:28.8859319Z LTS
+      2025-04-03T01:54:28.8859772Z ##[endgroup]
+      2025-04-03T01:54:28.8860299Z ##[group]Runner Image
+      2025-04-03T01:54:28.8860943Z Image: ubuntu-24.04
+      2025-04-03T01:54:28.8861475Z Version: 20250316.1.0
+      2025-04-03T01:54:28.8862551Z Included Software: https://github.com/actions/runner-images/blob/ubuntu24/20250316.1/images/ubuntu/Ubuntu2404-Readme.md
+      2025-04-03T01:54:28.8863985Z Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20250316.1
+      2025-04-03T01:54:28.8864920Z ##[endgroup]
+      2025-04-03T01:54:28.8865511Z ##[group]Runner Image Provisioner
+      2025-04-03T01:54:28.8866268Z 2.0.422.1
+      2025-04-03T01:54:28.8866896Z ##[endgroup]
+      2025-04-03T01:54:28.8867997Z ##[group]GITHUB_TOKEN Permissions
+      2025-04-03T01:54:28.8869791Z Issues: write
+      2025-04-03T01:54:28.8870441Z Metadata: read
+      2025-04-03T01:54:28.8871128Z ##[endgroup]
+      2025-04-03T01:54:28.8874087Z Secret source: Actions
+      2025-04-03T01:54:28.8874824Z Prepare workflow directory
+      2025-04-03T01:54:28.9179205Z Prepare all required actions
+      2025-04-03T01:54:28.9269537Z Complete job name: issue-auto
+      2025-04-03T01:54:29.0127709Z ##[group]Run if ! gh api orgs/cli/public_members/$ISSUEAUTHOR --silent 2>/dev/null
+      2025-04-03T01:54:29.0128780Z if ! gh api orgs/cli/public_members/$ISSUEAUTHOR --silent 2>/dev/null
+      2025-04-03T01:54:29.0129485Z then
+      2025-04-03T01:54:29.0129996Z   gh issue edit $ISSUENUM --add-label "needs-triage"
+      2025-04-03T01:54:29.0130596Z fi
+      2025-04-03T01:54:29.0614473Z shell: /usr/bin/bash -e {0}
+      2025-04-03T01:54:29.0615274Z env:
+      2025-04-03T01:54:29.0615669Z   GH_REPO: cli/cli
+      2025-04-03T01:54:29.0616625Z   GH_TOKEN: ***
+      2025-04-03T01:54:29.0617062Z   ISSUENUM: 10725
+      2025-04-03T01:54:29.0617629Z   ISSUEAUTHOR: saidakrommuminov52
+      2025-04-03T01:54:29.0618121Z ##[endgroup]
+      2025-04-03T01:54:30.4210011Z https://github.com/cli/cli/issues/10725
+      2025-04-03T01:54:30.4302059Z Cleaning up orphan processes
+      ```
+
+      ## Acceptance Criteria
+
+      ### 1. Both new and legacy job run log files in the archive
+      **Given** I have a job run whose logs include both new and legacy job run logs
+      **When** I run `gh run view --logs <JOB-ID>`
+      **Then** the content of the new job run log file is displayed
+
+      ### 2. Only new job run log files in the archive
+      **Given** I have a job run whose logs include only the new job run logs
+      **When** I run `gh run view --logs <JOB-ID>`
+      **Then** the content of the new job run log file is displayed
+
+      ### 3. Only legacy job run log files in the archive
+      **Given** I have a job run whose logs include only the legacy job run logs
+      **When** I run `gh run view --logs <JOB-ID>`
+      **Then** the content of the legacy job run log file is displayed
+      </BODY>
+  - name: 'not spam, #10756 (https://github.com/cli/cli/issues/10756)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh attestation` integration tests are flakey
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      We are seeing some flakey `gh attestation` [test failures](https://github.com/cli/cli/actions/runs/14310467893/job/40103955286?pr=10740#step:5:113) related timeout when fetching TUF content. The tests will succeed after being re-run.
+
+      ### Affected version
+
+      2.69.0
+
+      ### Steps to reproduce the behavior
+
+      `gh attestation` tests will randomly fail with a message related to client timeout.
+
+      ### Expected vs actual behavior
+
+      Tests should always pass on first run.
+      </BODY>
+  - name: 'not spam, #10741 (https://github.com/cli/cli/issues/10741)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Escape dots in regexp pattern in `README.md`
+      </TITLE>
+
+      <BODY>
+      In the command example below in the `README.md`:
+
+      ```shell
+      $ cosign verify-blob-attestation --bundle cli-cli-attestation-3120304.sigstore.json \
+            --new-bundle-format \
+            --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
+            --certificate-identity-regexp="^https://github.com/cli/cli/.github/workflows/deployment.yml@refs/heads/trunk$" \
+            gh_2.62.0_macOS_arm64.zip
+      Verified OK
+      ```
+
+      The dots in the regexp pattern (i.e., `--certificate-identity-regexp`) should be escaped:
+
+      ```shell
+      $ cosign verify-blob-attestation --bundle cli-cli-attestation-3120304.sigstore.json \
+            --new-bundle-format \
+            --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
+            --certificate-identity-regexp='^https://github\.com/cli/cli/\.github/workflows/deployment\.yml@refs/heads/trunk$' \
+            gh_2.62.0_macOS_arm64.zip
+      Verified OK
+      ```
+      </BODY>
+  - name: 'not spam, #10714 (https://github.com/cli/cli/issues/10714)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Commands that interact with classic projects should continue to work in the absence of GitHub App Installation Access Token repository projects permission
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      In preparation for sunsetting the projects v1 API, the Fine Grained Token permissions on GitHub app were removed from the UI, which resulted in failures for commands that use `projectCards` in GQL queries (`issue/pr create`, `issue/pr edit`, `issue/pr view`), with newly generated tokens.
+
+      We should modify the CLI so that it continues to work after they remove this, because it's not a good situation for the owning team to continue exposing this token that isn't used for anything.
+
+      ### Acceptance Criteria
+
+      **Given** I am targeting a host that has sunset v1 projects
+      **And Given** I have a token that doesn't have Fine Grained Permission for repository projects
+      **When** I run commands that currently interact with v1 projects
+      **Then** they do not fail horribly with `GraphQL: Resource not accessible by integration (repository.pullRequest.projectCards.nodes)`
+
+      ### Notes
+
+      This does not affect cases in which the user has used the `--json` flag, or `gh api`.
+
+      The implementation for this may simply be removing requests for `projectCards` and `projects` for non-enterprise servers.
+
+      Probably use **https://github.com/cli/cli/compare/trunk...cli-9430**
+      </BODY>
+  - name: 'not spam, #10686 (https://github.com/cli/cli/issues/10686)'
+    expected: PASS
+    input: "<TITLE>\n`run view` returns 404 and fails on runs from org/enterprise ruleset workflows\n</TITLE>\n\n<BODY>\n### Describe the bug\n\n`run view` fails on runs originating from org/enterprise ruleset workflows AKA \"required workflows\"\n\nRelated: \n- #10076 (same problem except for `run list`)\n- #10660\n\n### Affected version\n\nn/a\n\n### Steps to reproduce the behavior\n\n```\ngh run view #######\nfailed to get run: HTTP 404: Not Found (https://api.github.com/repos/<owner>/<repo>/actions/workflows/######)\n\n```\n\n### Expected vs actual behavior\n\n`run view` should not fail, it should display without the workflow metadata.\n</BODY>"
+  - name: 'not spam, #10681 (https://github.com/cli/cli/issues/10681)'
+    expected: PASS
+    input: "<TITLE>\n`gh pr edit` returns an error with `--add-project`\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nI'm not able to use `gh pr edit --add-project \"anything\"` anymore, since this afternoon (EU time).\n\n<img width=\"1083\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/226835b3-40e9-429c-8f6f-733c33b10692\" />\n\nAnd my project used for this is V2 compliant, see the icon: \n\n<img width=\"254\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/bdf2ec07-6037-4ea2-9f74-198dafd39c4b\" />\n\n### Affected version\n\n```\ngh version 2.69.0 (2025-03-19)\nhttps://github.com/cli/cli/releases/tag/v2.69.0\n```\n\nTested with version 2.67 too, same issue.\n\n### Steps to reproduce the behavior\n\n1. In a project within an organization, with at least one PR and one Project\n2. run this command on the PR mentioned above: `gh pr edit <pr_id> --add-project \"project_name\"`\n3. See error\n\n```log\nerror fetching organization projects (classic): GraphQL: Projects (classic) is being deprecated in favor of the new Projects experience, see: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/. (organization.projects.nodes.0), Projects (classic) is being deprecated in favor of the new Projects experience, see: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/. (organization.projects.nodes.1), Projects (classic) is being deprecated in favor of the new Projects experience, see: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/. (organization.projects.nodes.2), Projects (classic) is being deprecated in favor of the new Projects experience, see: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/. (organization.projects.nodes.3)\n```\n\n### Expected vs actual behavior\n\nI expect the PR to be updated, as described in the documentation\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n```\n⣾* Request at 2025-03-26 17:56:09.332114 +0100 CET m=+0.043415293\n* Request to https://api.github.com/graphql\n⢿* Request took 410.302291ms\n* Request at 2025-03-26 17:56:09.744357 +0100 CET m=+0.455659209\n* Request to https://api.github.com/graphql\n⣯* Request took 383.43725ms\n⣾* Request at 2025-03-26 17:56:10.12827 +0100 CET m=+0.839571834\n* Request to https://api.github.com/graphql\n* Request at 2025-03-26 17:56:10.128317 +0100 CET m=+0.839618834\n* Request to https://api.github.com/graphql\n* Request at 2025-03-26 17:56:10.128344 +0100 CET m=+0.839646293\n* Request to https://api.github.com/graphql\n* Request at 2025-03-26 17:56:10.12827 +0100 CET m=+0.839571834\n* Request at 2025-03-26 17:56:10.128364 +0100 CET m=+0.839665626\n* Request to https://api.github.com/graphql\n* Request to https://api.github.com/graphql\n⣻* Request took 248.469ms\n* Request took 352.49675ms\n* Request took 352.472292ms\n⡿* Request took 549.782958ms\n⣻* Request took 1.250581084s\nerror fetching organization projects (classic): GraphQL: Projects (classic) is being deprecated in favor of the new Projects experience, see: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/. (organization.projects.nodes.0), Projects (classic) is being deprecated in favor of the new Projects experience, see: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/. (organization.projects.nodes.1), Projects (classic) is being deprecated in favor of the new Projects experience, see: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/. (organization.projects.nodes.2), Projects (classic) is being deprecated in favor of the new Projects experience, see: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/. (organization.projects.nodes.3)\n```\n</BODY>"
+  - name: 'not spam, #10678 (https://github.com/cli/cli/issues/10678)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      PowerShell completion code has pipe `|` as `&#124` on website
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      The PowerShell completion code has what should be a pipe `|` as its escaped characters `&#124` on the website https://cli.github.com/manual/gh_completion
+
+      ### Affected version
+
+      N/A
+
+      ### Steps to reproduce the behavior
+
+      1. Go to https://cli.github.com/manual/gh_completion
+      2. Scroll to PowerShell section
+
+      ### Expected vs actual behavior
+
+      Expected:
+      ```powershell
+      Invoke-Expression -Command $(gh completion -s powershell | Out-String)
+      ```
+
+      Actual:
+      ```powershell
+      Invoke-Expression -Command $(gh completion -s powershell &#124; Out-String)
+      ```
+
+      ### Logs
+
+      N/A
+      </BODY>
+  - name: 'not spam, #10677 (https://github.com/cli/cli/issues/10677)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Shell function aliases do not get passed arguments
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      Aliases that are shell functions do not get passed arguments.
+
+      ### Affected version
+
+      gh version 2.63.2 (2024-12-05)
+
+      ### Steps to reproduce the behavior
+
+      Create the following aliases and run them.
+
+      ```sh
+      gh alias set --shell hi 'echo $1'
+      gh alias set --shell there 'f() { echo $1; }; f'
+      ```
+
+      ### Expected vs actual behavior
+
+      Running `gh hi there` and `gh there there` should both echo `there`.
+
+      `gh hi there` works fine. `gh there there` echoes nothing.
+      </BODY>
+  - name: 'not spam, #10626 (https://github.com/cli/cli/issues/10626)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh gist edit` can panic index of range when no file in a gist
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      `bash repro.sh`:
+      ```bash
+      echo foo | gh gist create
+
+      cat <<EOF >dummy_editor
+      #!/bin/sh
+      printf '' > "\$1"
+      EOF
+
+      chmod +x dummy_editor
+
+      # make file "foo" empty (seems deleting the file from gist)
+      GH_EDITOR=$(realpath dummy_editor) ./bin/gh gist edit "$(gh gist list | head -1 | awk '{ print $1 }')"
+      ./bin/gh gist edit # panic
+      ```
+
+      Then panic with:
+      ```
+      goroutine 1 [running]:
+      github.com/cli/cli/v2/pkg/cmd/gist/shared.Gist.Filename({{0xc000c020a0, 0x20}, {0x0, 0x0}, 0xc000c06690, {0x0, 0xedf6b06e9, 0x0}, 0x0, {0x0, ...}, ...})
+              github.com/cli/cli/v2/pkg/cmd/gist/shared/shared.go:48 +0x176
+      github.com/cli/cli/v2/pkg/cmd/gist/shared.PromptGists({0x2414f20, 0xc00061c5f0}, 0xf?, {0xc0003ff020?, 0x1?}, 0xc00038a71a)
+              github.com/cli/cli/v2/pkg/cmd/gist/shared/shared.go:233 +0x1b8
+      github.com/cli/cli/v2/pkg/cmd/gist/edit.editRun(0xc00046f4d0)
+              github.com/cli/cli/v2/pkg/cmd/gist/edit/edit.go:115 +0x105
+      github.com/cli/cli/v2/pkg/cmd/gist/edit.NewCmdEdit.func3(0xc000671208?, {0x2f72940?, 0x4?, 0x17fc4f0?})
+              github.com/cli/cli/v2/pkg/cmd/gist/edit/edit.go:79 +0x98
+      github.com/spf13/cobra.(*Command).execute(0xc000671208, {0x2f72940, 0x0, 0x0})
+              github.com/spf13/cobra@v1.8.1/command.go:985 +0xaaa
+      github.com/spf13/cobra.(*Command).ExecuteC(0xc0005ac908)
+              github.com/spf13/cobra@v1.8.1/command.go:1117 +0x3ff
+      github.com/spf13/cobra.(*Command).ExecuteContextC(...)
+              github.com/spf13/cobra@v1.8.1/command.go:1050
+      github.com/cli/cli/v2/internal/ghcmd.Main()
+              github.com/cli/cli/v2/internal/ghcmd/cmd.go:119 +0x53b
+      main.main()
+              github.com/cli/cli/v2/cmd/gh/main.go:10 +0x13
+      ```
+
+      ### Affected version
+      Test on 2.65.0 and HEAD, both reproduced.
+
+      ### Expected vs actual behavior
+      No panic.
+      </BODY>
+  - name: 'not spam, #10601 (https://github.com/cli/cli/issues/10601)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Version information missing from exe file
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      ProductVersion and FileVersion should be set in .exe at buildtime.
+      This affects version management and ability to find any vulnerable versions
+
+      ### Affected versions
+      Probably all, but verified with these `gh --version`
+      gh version 2.63.1 (2024-12-03)
+      https://github.com/cli/cli/releases/tag/v2.63.1
+      gh version 2.67.0 (2025-02-11)
+      https://github.com/cli/cli/releases/tag/v2.67.0
+      gh version 2.68.1 (2025-03-06)
+      https://github.com/cli/cli/releases/tag/v2.68.1
+
+      ### Steps to reproduce the behavior
+
+      Check details from explorer, or this in powershell:
+      ```powershell
+      [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Program Files\GitHub CLI\gh.exe")
+      ```
+
+      ### Expected vs actual behavior
+
+      ```
+      ProductVersion   FileVersion      FileName
+      --------------   -----------      --------
+      2.68.1 (2025-03-26)             2.68.1                     C:\Program Files\GitHub CLI\gh.exe
+      ```
+
+      Actual:
+      ```
+      ProductVersion   FileVersion      FileName
+      --------------   -----------      --------
+                                        C:\Program Files\GitHub CLI\gh.exe
+      ```
+
+      ![Image](https://github.com/user-attachments/assets/f9898c07-b17d-427d-942f-217236f81f77)
+      </BODY>
+  - name: 'not spam, #10590 (https://github.com/cli/cli/issues/10590)'
+    expected: PASS
+    input: "<TITLE>\nExecuting `TestDeleteRun` alias test does not safe guard pre-existing configuration\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nCollaborating with @BagToad after raising awareness of his aliases disappearing unpredictably, we have been periodically checking in whether my aliases have disappeared.  This morning, I believe I found the cause due to a missing safeguard within the `gh alias delete` test below, which does not mock `Config.WriteFunc()` function the same as `gh alias set` test does: \n\nhttps://github.com/cli/cli/blob/7924274ef9d03738c9ef58595e94dcd4e6ede8e7/pkg/cmd/alias/delete/delete_test.go#L87-L185\n\nhttps://github.com/cli/cli/blob/7924274ef9d03738c9ef58595e94dcd4e6ede8e7/pkg/cmd/alias/set/set_test.go#L98-L290\n\nStepping through the debugger shows the `deleteRun()` call will overwrite the test executor's `config.yaml` _(all of it!)_ with the final test scenario wiping out all aliases.\n\nI believe this is due to the test missing the following safeguard:\n\nhttps://github.com/cli/cli/blob/7924274ef9d03738c9ef58595e94dcd4e6ede8e7/pkg/cmd/alias/set/set_test.go#L285-L287\n\n### Affected version\n\nN/A\n\n### Steps to reproduce the behavior\n\n```shell\n$ go clean -testcache \n\n$ cat ~/.config/gh/config.yml                                                 \naliases: {slackd: slack read -d}\nversion: \"1\"\n\n$ go test -run \"^TestDeleteRun$\" github.com/cli/cli/v2/pkg/cmd/alias/delete     \nok  \tgithub.com/cli/cli/v2/pkg/cmd/alias/delete\t0.253s\n\n$ cat ~/.config/gh/config.yml                                              \naliases: {}\n```\n\n### Expected vs actual behavior\n\n`gh alias` tests do not affect the test executor's configuration file.\n\n### Logs\n\nUnsure how to get better logs here as part of the testing suite and being related to non-HTTP behavior.\n</BODY>"
+  - name: 'not spam, #10585 (https://github.com/cli/cli/issues/10585)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh release upload` replaces spaces in filenames with dots
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+      When uploading a release asset using `gh release upload`, spaces in the filename are unexpectedly replaced with dots (`.`). This alters the filename in the release assets.
+
+      ### Affected version
+      ```
+      gh --version
+      gh version 2.65.0 (2025-01-06)
+      https://github.com/cli/cli/releases/tag/v2.65.0
+      ```
+
+      ### Steps to reproduce the behavior
+      1. Run the following command using gh CLI:
+         `gh release upload "1.0.0" "electron-app/dist/My App 1.0.0 Setup.exe" --clobber`
+      2. View the uploaded release asset on GitHub.
+      3. The filename appears as `My.App.1.0.0.Setup.exe` instead of the expected `My App 1.0.0 Setup.exe`.
+
+
+      ### Expected vs actual behavior
+      Expected behavior: The uploaded file should retain its original name: `My App 1.0.0 Setup.exe`
+      Actual behavior: The uploaded file appears as: `My.App.1.0.0.Setup.exe`
+
+      ### Additional context
+      This issue seems related to previous reports:
+      - https://github.com/cli/cli/issues/4863
+      - https://github.com/cli/cli/issues/7024
+
+      These issues suggest this problem was resolved in 2023, but the issue persists in gh version 2.65.0.
+      </BODY>
+  - name: 'not spam, #10580 (https://github.com/cli/cli/issues/10580)'
+    expected: PASS
+    input: "<TITLE>\ngh pr comment --edit-last now creates if no previous comment\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nPrior to [https://github.com/cli/cli/pull/10427](https://github.com/cli/cli/pull/10427), --edit-last didn't comment if there wasn't a previous comment. That seems to have changed with this, and now it creates (by default) if no comment. \n\nThis means we can no longer use it or expect it to fail if there's no previous comment, which is breaking many of our flows from github actions - it's commenting when we wouldn't expect\n\nAt least in 26.8.1\n\n### Affected version\n\n`\ngh version 2.68.1 (2025-03-06)\nhttps://github.com/cli/cli/releases/tag/v2.68.1\n`\n\n### Steps to reproduce the behavior\n\n1. create a PR\n2. type this: `gh pr comment PR_ID_OR_URL --edit-last --body \"test from gh pr\"\n3. See comment is added\n\nTry again with a previous gh version, it doesn't do this (as per the recommendation here for why it's asking for a different feature for this: [https://github.com/cli/cli/issues/6790](https://github.com/cli/cli/issues/6790)\n\n### Expected vs actual behavior\n\n--edit-last behaviour shouldn't have changed, or else we need a flag to not have it create a comment\n\nCC: @latzskim and @BagToad as the mergers of that PR. Sorry for the ping; if there's an alternate workaround to get back old behavior, let us know.\n</BODY>"
+  - name: 'not spam, #10575 (https://github.com/cli/cli/issues/10575)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Test Issue
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      Testing that environment secrets are correctly injected into our labelling workflow.
+      </BODY>
+  - name: 'not spam, #10573 (https://github.com/cli/cli/issues/10573)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh repo sync` fails with surprising error if `workflow` scope is missing and token is from GitHub App
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      This is an extension of https://github.com/cli/cli/issues/7574 based on the comment that the [previous fix](https://github.com/cli/cli/pull/7612) doesn't work for [GitHub App tokens.](https://github.com/cli/cli/issues/7574#issuecomment-2709551166)
+
+      ### Affected version
+
+      `v2.68.1`
+
+      ### Acceptance Criteria
+
+      **Given** I have a GitHub App token that is missing `workflow` scope
+      **When** I run `gh repo sync` where the upstream repo has `workflow` changes to be synced
+      **Then** I get an informative error rather than a 404.
+      </BODY>
+  - name: 'not spam, #10563 (https://github.com/cli/cli/issues/10563)'
+    expected: PASS
+    input: "<TITLE>\nAdd field to retrieve linked PRs (closingPRsReferences) in `gh issue view <number`\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\n\nAs per my comment in #10529, `gh issue view <number>` should list the linked PRs that would close the issue\n\n### Proposed solution\n\nExposing `closingPRsReferences` as a field. E.g. `gh view issue<number> --json closingPRsReferences`\n\n### Additional context\n\nThis is an improvement linked to [my comment](https://github.com/cli/cli/issues/10529#issuecomment-2701532800) in #10529 \n</BODY>"
+  - name: 'not spam, #10559 (https://github.com/cli/cli/issues/10559)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `./script/sign` seems to have unnecessary windows signing debris
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      Whilst writing the [release deep dive doc](https://github.com/cli/cli/blob/fc19ff321a4b7f4198f788f08da20249c7950fbd/docs/release-process-deep-dive.md) I noticed that our `./script/sign` script still has [references to signing for windows](https://github.com/cli/cli/blob/fc19ff321a4b7f4198f788f08da20249c7950fbd/script/sign#L9-L30). However, I do not believe that this codepath is exercised anymore, since we moved to Azure HSM:
+
+      https://github.com/cli/cli/blob/fc19ff321a4b7f4198f788f08da20249c7950fbd/.github/workflows/deployment.yml#L238-L240
+
+      ### Expected Output
+
+      The expected output for this issue is:
+       * The windows signing sections are removed from `./script/sign` (including the loop which decides to call `sign_windows`
+       * The `goreleaser.yml` does not [reference `./script/sign`](https://github.com/cli/cli/blob/fc19ff321a4b7f4198f788f08da20249c7950fbd/.goreleaser.yml#L43)
+       * The release deep dive doc warning about this issue under the "Windows" section is removed
+      </BODY>
+  - name: 'not spam, #10557 (https://github.com/cli/cli/issues/10557)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Add interactive fork deletion to `gh repo` commands
+      </TITLE>
+
+      <BODY>
+      I’d like to propose a new feature for `gh` that allows users to interactively delete forked repositories. The command could list all forks (via `gh repo list --fork`) and prompt the user with a `y/n` choice for each one before deleting.
+
+      Example usage:
+      $ gh repo delete --forks --interactive
+      Repository: username/old-fork1 (Last updated: 2022-05-10)
+      Delete this repository? (y/n): y
+      Deleting username/old-fork1...
+      Repository: username/old-fork2 (Last updated: 2023-12-01)
+      Delete this repository? (y/n): n
+      Skipping username/old-fork2...
+
+      This would streamline cleanup of old forks without needing external scripts.
+      </BODY>
+  - name: 'not spam, #10551 (https://github.com/cli/cli/issues/10551)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      gh run view (--log||--log-failed) no longer produces logs?
+      </TITLE>
+
+      <BODY>
+      I started to use this feature quite recently and initially it seemed to
+      work but now I simply cannot get any log, but no error either.
+
+      Is there any trick I can use to debug? Shall I provide an example of a
+      repo and run id for which I encounter this problem?
+      </BODY>
+  - name: 'not spam, #10548 (https://github.com/cli/cli/issues/10548)'
+    expected: PASS
+    input: "<TITLE>\nv2.68.0 failed to run secret commands\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nI am trying to run the `gh secret list` after installing the `gh@2.68.0` version,\nbut it throws out error:\n\n```\n$ gh secret list\npanic: runtime error: invalid memory address or nil pointer dereference\n[signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x10588be10]\n\ngoroutine 1 [running]:\ngithub.com/cli/cli/v2/pkg/cmd/secret/list.NewCmdList.func1.RequireNoAmbiguityBaseRepoFunc.1()\n \tgithub.com/cli/cli/v2/pkg/cmd/secret/shared/base_repo.go:69 +0x90\ngithub.com/cli/cli/v2/pkg/cmd/secret/list.NewCmdList.func1.PromptWhenAmbiguousBaseRepoFunc.2()\n \tgithub.com/cli/cli/v2/pkg/cmd/secret/shared/base_repo.go:26 +0x44\ngithub.com/cli/cli/v2/pkg/cmd/secret/list.listRun(0x140006ca880)\n \tgithub.com/cli/cli/v2/pkg/cmd/secret/list/list.go:117 +0xd0\ngithub.com/cli/cli/v2/pkg/cmd/secret/list.NewCmdList.func1(0x140004de008?, {0x107389100?, 0x4?, 0x105900851?})\n \tgithub.com/cli/cli/v2/pkg/cmd/secret/list/list.go:94 +0x254\ngithub.com/spf13/cobra.(*Command).execute(0x140004de008, {0x107389100, 0x0, 0x0})\n \tgithub.com/spf13/cobra@v1.8.1/command.go:985 +0x830\ngithub.com/spf13/cobra.(*Command).ExecuteC(0x14000554908)\n \tgithub.com/spf13/cobra@v1.8.1/command.go:1117 +0x344\ngithub.com/spf13/cobra.(*Command).ExecuteContextC(...)\n \tgithub.com/spf13/cobra@v1.8.1/command.go:1050\ngithub.com/cli/cli/v2/internal/ghcmd.Main()\n \tgithub.com/cli/cli/v2/internal/ghcmd/cmd.go:119 +0x4b0\nmain.main()\n \tgithub.com/cli/cli/v2/cmd/gh/main.go:10 +0x1c\n```\n\n### Affected version\n\nPlease run `gh version` and paste the output below.\n\n```\ngh --version\ngh version 2.68.0 (2025-03-05)\nhttps://github.com/cli/cli/releases/tag/v2.68.0\n```\n\n### Expected vs actual behavior\n\nExpected secrets can be viewed, but actually throwing out error.\n\n### Workaround\n\nI have downloaded `gh@2.63.0` and replaced `/opt/homebrew/Cellar/gh/2.68.0`,\nwhich makes it working again. \n</BODY>"
+  - name: 'not spam, #10537 (https://github.com/cli/cli/issues/10537)'
+    expected: PASS
+    input: "<TITLE>\n`gh attestation` calls to `list attestation` GitHub API endpoints use API predicate type filtering param\n</TITLE>\n\n<BODY>\nUpdate the `gh attestation` code so that calls to the GitHub API list attestations endpoints use the predicate type filtering query parameter. \n</BODY>"
+  - name: 'not spam, #10529 (https://github.com/cli/cli/issues/10529)'
+    expected: PASS
+    input: "<TITLE>\nAdd field to retrieve linked issues (`closingIssuesReferences`) in `gh pr view <number>` \n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\n\nAccess to issues linked to Pull Requests in the Development panel. This field is available in GraphQL but not yet exposed in gh CLI. The GraphQL query to retrieve this field was shared in https://github.com/cli/cli/discussions/7097 \n\n```bash\ngh api graphql -F owner='{owner}' -F repo='{repo}' -F pr=PRNUMBER -f query='\nquery ($owner: String!, $repo: String!, $pr: Int!) {\n\trepository(owner: $owner, name: $repo) {\n\t\tpullRequest(number: $pr) {\n\t\t\tclosingIssuesReferences(first: 100) {\n\t\t\t\tnodes {\n\t\t\t\t\tnumber\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t}\n}'  --jq '.data.repository.pullRequest.closingIssuesReferences.nodes[].number'\n```\n\n### Proposed solution\n\nExposing `closingIssuesReferences` as a field. E.g. `gh view pr <number> --json closingIssuesReferences`.\n</BODY>"
+  - name: 'not spam, #10525 (https://github.com/cli/cli/issues/10525)'
+    expected: PASS
+    input: "<TITLE>\n`gh secret` subcommands don't work anymore if called outside of Git repository\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nAfter upgrading to GitHub CLI `2.67.0` all `gh secret set` commands that are run outside of git repository fails with this message:\n\n```\nfailed to run git: fatal: not a git repository (or any parent up to mount point /)\nStopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).\n```\n\nActions like [this](https://github.com/AnimMouse/setup-rclone/blob/main/update-config/action.yaml#L20) are now failing if they are run without using `actions/checkout`.\n\nRelated: #4688 #10209\n\nMaybe related: #10352\n\n### Affected version\n\n`2.67.0` `2.66.1` `2.66.0`\n\n### Steps to reproduce the behavior\n\n1. Upgrade to GitHub CLI 2.67.0\n2. Run `GH_REPO=AnimMouse/test-repo gh secret set test_secret`\n3. See error:\n\n```\nfailed to run git: fatal: not a git repository (or any parent up to mount point /)\nStopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).\n```\n\n### Expected vs actual behavior\n\nEarlier version of `gh secret` worked without checking out the repository.\n\n```\nGH_REPO=AnimMouse/test-repo gh secret set test_secret\n? Paste your secret: \n```\n</BODY>"
+  - name: 'not spam, #10519 (https://github.com/cli/cli/issues/10519)'
+    expected: PASS
+    input: "<TITLE>\nPanic using `gh workflow run` in GitHub Actions\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nI was trying to use `gh workflow run` at the end of a step in a GitHub action to trigger another workflow run. After reading some documentation though it seems I'm doing things wrong and should be using [reusable workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) instead, so I'll figure that out elsewhere...\n\n_Anyway,_ when trying to do this in a GitHub Action, the `gh workflow run` call always ended in a panic. Here's the step in the job:\n\n```yaml\n      - name: Trigger Release Workflow\n        env:\n          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n        run: |\n          gh workflow run release.yml -f tag_name=\"${TAG}\"\n```\n\n(the `$TAG` is correctly set in a previous job step) \n\nNote the use of `secrets.GITHUB_TOKEN`, which might be part of the problem due to how that token is limited in GHA to prevent recursive actions, etc... but maybe not...\n\nHere's the panic:\n\n```\n2025-02-28T14:35:15.4937350Z ##[group]Run printf '%s\\n' \"${TAG}\"\n2025-02-28T14:35:15.4937658Z ^[[36;1mprintf '%s\\n' \"${TAG}\"^[[0m\n2025-02-28T14:35:15.4937964Z ^[[36;1mgh workflow run release.yml -f tag_name=\"${TAG}\"^[[0m\n2025-02-28T14:35:15.4983044Z shell: /usr/bin/bash -e {0}\n2025-02-28T14:35:15.4983277Z env:\n2025-02-28T14:35:15.4983452Z   TAG: v0.1.0-nightly\n2025-02-28T14:35:15.4983829Z   GITHUB_TOKEN: ***\n2025-02-28T14:35:15.4984034Z ##[endgroup]\n2025-02-28T14:35:15.5049366Z v0.1.0-nightly\n2025-02-28T14:35:15.9590013Z panic: runtime error: invalid memory address or nil pointer dereference\n2025-02-28T14:35:15.9591635Z [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x13eed8a]\n2025-02-28T14:35:15.9592318Z \n2025-02-28T14:35:15.9596306Z goroutine 1 [running]:\n2025-02-28T14:35:15.9598926Z github.com/cli/cli/v2/pkg/cmd/workflow/shared.FindWorkflow(0xc000abd8f0, {0x22c13c0, 0xc0002e48d0}, {0x7ffecc3d2c67, 0xb}, {0xc000abd8e0, 0x1, 0x1})\n2025-02-28T14:35:15.9600986Z \t/home/runner/work/cli/cli/pkg/cmd/workflow/shared/shared.go:139 +0x1aa\n2025-02-28T14:35:15.9604432Z github.com/cli/cli/v2/pkg/cmd/workflow/shared.ResolveWorkflow({0x7fd132b6afc8, 0xc000724b40}, 0xc0003b4790, 0xc00061f9a0?, {0x22c13c0?, 0xc0002e48d0?}, 0x0?, {0x7ffecc3d2c67, 0xb}, {0xc000abd8e0, ...})\n2025-02-28T14:35:15.9606415Z \t/home/runner/work/cli/cli/pkg/cmd/workflow/shared/shared.go:207 +0x2b5\n2025-02-28T14:35:15.9607292Z github.com/cli/cli/v2/pkg/cmd/workflow/run.runRun(0xc00084b180)\n2025-02-28T14:35:15.9608084Z \t/home/runner/work/cli/cli/pkg/cmd/workflow/run/run.go:273 +0x251\n2025-02-28T14:35:15.9609089Z github.com/cli/cli/v2/pkg/cmd/workflow/run.NewCmdRun.func2(0xc000856008?, {0xc0002b6f30?, 0x4?, 0x178a487?})\n2025-02-28T14:35:15.9610121Z \t/home/runner/work/cli/cli/pkg/cmd/workflow/run/run.go:128 +0x311\n2025-02-28T14:35:15.9610972Z github.com/spf13/cobra.(*Command).execute(0xc000856008, {0xc0002b6f00, 0x3, 0x3})\n2025-02-28T14:35:15.9611919Z \t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:985 +0xaaa\n2025-02-28T14:35:15.9612678Z github.com/spf13/cobra.(*Command).ExecuteC(0xc0006d6008)\n2025-02-28T14:35:15.9613440Z \t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1117 +0x3ff\n2025-02-28T14:35:15.9614179Z github.com/spf13/cobra.(*Command).ExecuteContextC(...)\n2025-02-28T14:35:15.9615150Z \t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1050\n2025-02-28T14:35:15.9615811Z github.com/cli/cli/v2/internal/ghcmd.Main()\n2025-02-28T14:35:15.9616459Z \t/home/runner/work/cli/cli/internal/ghcmd/cmd.go:119 +0x53b\n2025-02-28T14:35:15.9617003Z main.main()\n2025-02-28T14:35:15.9619832Z \t/home/runner/work/cli/cli/cmd/gh/main.go:10 +0x13\n2025-02-28T14:35:15.9629795Z ##[error]Process completed with exit code 2.\n\n```\n\nI believe the panic comes from the [cli/cli/pkg/cmd/workflow/shared/shared.go:139](https://github.com/cli/cli/blob/f8d9aac7e50aa3370d6824e7f2b71049af5176a1/pkg/cmd/workflow/shared/shared.go#L139) in the stack there. \n\nhttps://github.com/cli/cli/blob/f8d9aac7e50aa3370d6824e7f2b71049af5176a1/pkg/cmd/workflow/shared/shared.go#L131-L140\n\nOn line 135 we check for `errors.As() && httpErr.StatusCode == 404` in order to return an `err`, so I'm speculating that the `getWorkflowByID()` call on 132 is returning a `nil` workflow with some other error code that's not a http error or not a `404`, and as a result we get the `nil pointer dereference` on 139. \n\nI was going to add a PR to return a generic error message between line 137 and 138, but the contributing guide asks (suggests?) to not open PRs unless there's a `help-wanted` on a bug or something, plus in the short time I looked I wasn't sure how to write a test for this so I just opt to give all this info here. \n\nAgain just speculation but maybe something to do with the token I'm using, because using `gh workflow run` on my machine while authenticated works fine:\n\n```\n ➜ gh workflow run release.yml -f tag_name=\"v0.1.0-nightly\"\n✓ Created workflow_dispatch event for release.yml at main\n\nTo see runs for this workflow, try: gh run list --workflow=release.yml\n```\n\nSo maybe the `getWorkflowByID()` call is returning a `403` or something due to the token being used? \n\n### Affected version\n\nThis is happening inside GitHub Actions, so I'm not totaly sure what `gh version`, but here's the runner version:\n\n```\n2025-02-28T14:34:58.2988493Z Current runner version: '2.322.0'\n2025-02-28T14:34:58.3029586Z ##[group]Operating System\n2025-02-28T14:34:58.3031098Z Ubuntu\n2025-02-28T14:34:58.3032312Z 24.04.2\n2025-02-28T14:34:58.3033375Z LTS\n2025-02-28T14:34:58.3034492Z ##[endgroup]\n2025-02-28T14:34:58.3035920Z ##[group]Runner Image\n2025-02-28T14:34:58.3037214Z Image: ubuntu-24.04\n2025-02-28T14:34:58.3038421Z Version: 20250223.1.0\n```\n\n### Steps to reproduce the behavior\n\n1. Add a workflow (a) that does something and can be dispatched from another workflow (b)\n2. In workflow (b) add the step above that uses `gh workflow run`\n3. Run workflow (b)\n4. Panic? \n\n### Expected vs actual behavior\n\nReturn an error instead of panic, to help educate me on what I'm doing wrong.\n\n\nI'm happy to PR a fix here as I suspect even if my speculations on tokens are wrong, we probably still want to return `nil, err` between 137 and 138. Tips on how/where to test for that would be cool too, if we want to have a regression test there. \n</BODY>"
+  - name: 'not spam, #10510 (https://github.com/cli/cli/issues/10510)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Checking out a PR from a fork by URL no longer works
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      The following [Acceptance test](https://github.com/cli/cli/blob/69fff52026428c0130d812037573b5c9cc0e77bb/acceptance/testdata/pr/pr-checkout-with-url-from-fork.txtar) demonstrates the issue:
+
+      ```
+      # Set up env vars
+      env REPO=${SCRIPT_NAME}-${RANDOM_STRING}
+
+      # Use gh as a credential helper
+      exec gh auth setup-git
+
+      # Create a repository with a file so it has a default branch
+      exec gh repo create ${ORG}/${REPO} --add-readme --private
+
+      # Defer upstream cleanup
+      defer gh repo delete --yes ${ORG}/${REPO}
+
+      # Create a fork
+      exec gh repo fork ${ORG}/${REPO} --org ${ORG} --fork-name ${REPO}-fork
+
+      # Defer fork cleanup
+      defer gh repo delete --yes ${ORG}/${REPO}-fork
+
+      # Clone both repos
+      exec gh repo clone ${ORG}/${REPO}
+      exec gh repo clone ${ORG}/${REPO}-fork
+
+      # Prepare a branch to PR in the fork itself
+      cd ${REPO}-fork
+      exec git checkout -b feature-branch
+      exec git commit --allow-empty -m 'Empty Commit'
+      exec git push -u origin feature-branch
+
+      # Create the PR inside the fork
+      exec gh repo set-default ${ORG}/${REPO}-fork
+      exec gh pr create --title 'Feature Title' --body 'Feature Body'
+      stdout2env PR_URL
+
+      # Checkout the PR by full URL in the upstream repo
+      cd ${WORK}/${REPO}
+      exec gh pr checkout ${PR_URL}
+      stderr 'Switched to branch ''feature-branch'''
+      ```
+
+      It fails at this point:
+
+      ```
+              [git -c credential.helper= -c credential.helper=!"/var/folders/45/sdnm1hp10nj1s9q57dp3bc5h0000gn/T/testscript-main1265888467/bin/gh" auth git-credential fetch origin +refs/heads/feature-branch:refs/remotes/origin/feature-branch --no-tags]
+              fatal: couldn't find remote ref refs/heads/feature-branch
+              failed to run git: exit status 128
+      ```
+
+      ### Affected version
+
+      Regressed after https://github.com/cli/cli/pull/9868
+
+      ### Notes
+
+      The issue is that the `base` repo of the PR may not be the same as the `base` repo of the current working directory. See in this diff, that the `BaseRepo` from the `PRFinder` is ignored, and instead the return of `opts.BaseRepo` is used:
+
+      https://github.com/cli/cli/pull/9868/files#diff-b5ec653aa1e550e4c5f2df8ad7fc22dfbaedf71270cb5a328d7327f2a8093d66R96-R294
+      </BODY>
+  - name: 'not spam, #10500 (https://github.com/cli/cli/issues/10500)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Issuing OAuth Tokens with More Restricted Scopes
+      </TITLE>
+
+      <BODY>
+      The gh cli is likely used on many developers' laptops as the recommended tool for easily obtaining GitHub permissions from the CLI. However, there is a significant security-related blocking when using this optimally.
+
+      When accessing npm.pkg.github.com, we need to write credentials into the `~/.npmrc` file. The gh cli supports custom scopes, and with tokens obtained via the commands:
+
+      ```
+      $ gh auth login --scopes read:packages
+      $ gh auth token
+      ```
+
+      ```
+      @your-org:registry=https://npm.pkg.github.com
+      //npm.pkg.github.com/:_authToken=TOKEN
+      ```
+
+      you can access internal or private packages. However, the credentials written in plain text in this `~/.npmrc` file by default request `repo`, `read:org`, and `gist` scopes, which include a wide range of permissions, including write access.
+
+      This means that if malware operates on a developer's laptop, GitHub credentials could be leaked without much difficulty. To minimize this risk, we want to support an option in the gh cli to issue credentials with only the `read:packages` permission.
+
+      However, upon reviewing the source code, there seems to be an undocumented blocker that checks for the inclusion of `repo`, `read:org`, and `gist` scopes.
+
+      Is it technically possible for the gh cli to support an option to issue credentials with only the `read:packages` permission?
+
+      Thank you!
+      </BODY>
+  - name: 'not spam, #10467 (https://github.com/cli/cli/issues/10467)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      gh search prs messing query with flags and raising "unknown shorthand flag: 'l' in -label:some-label"
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      gh help states `queries built with GitHub search syntax are supported` but it looks like gh is messing query with flags and raising `unknown shorthand flag: 'l' in -label:some-label`
+
+      ### Affected version
+
+      2.67.0
+
+      ### Steps to reproduce the behavior
+
+      1. Type this:
+      `gh search prs org:OCA -label:approved state:open --sort=created --order=asc`
+      3. View the output
+      `unknown shorthand flag: 'l' in -label:approved
+
+      ### Expected vs actual behavior
+
+      I was hopping default output for search results
+
+      ### Findings
+
+      I don't get any logs when setting GH_DEBUG. gh help states `gh search prs [<query>] [flags]` as general structure for calls so gh is misleadingly recognizing `-label` as flag instead as query.
+      </BODY>
+  - name: 'not spam, #10466 (https://github.com/cli/cli/issues/10466)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Browser opening could be faster on Windows by avoiding `wslview`
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      Extracted from https://github.com/cli/browser/pull/14
+
+      ---
+
+      After noticing that `wslview` felt really slow, I looked into the source code to see what the cause was. I noticed that `wslview` was doing a lot of stuff which, IMO, is unnecessary for the purposes of `gh`.
+
+      What `wslview` does is:
+
+      * Queries the Windows Registry via `reg.exe` to check if the build number is high enough (not used when opening URLs)
+      * Validates the URL by `curl`ing it and asserting that content was returned (a potential source of slowness, this can be skipped with `--skip-validation-check` on newer versions of `wslview`).
+
+      And, after these validations, what it boils down to is calling either `/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command "explorer.exe $URL"` or `/mnt/c/Windows/System32/cmd.exe /c explorer.exe "$URL"`. Starting a PowerShell process seems to contribute a lot to the slowness.
+
+      There's a bit of extra work in case a different prefix is used than `/mnt` or Windows is installed to a different drive than `C:`, but this should sum up the vast majority of cases.
+
+      I think these validations aren't necessary as long as `LookPath` is used, and `explorer.exe` can be called directly. I've noticed a pretty decent gain in speed when using `GH_BROWSER=explorer.exe` over `GH_BROWSER=wslview`.
+
+      ---
+      </BODY>
+  - name: 'not spam, #10454 (https://github.com/cli/cli/issues/10454)'
+    expected: PASS
+    input: "<TITLE>\nInconsistent format of description of flags (starting with lowercase letter)\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nMost of the descriptions for flags start with an uppercase letter.\nFollowing are a few cases where it starts with a lowercase letter:\n\n```\n21 results - 13 files\n\npkg/cmd/extension/command.go:\n  414: \t\t\tcmd.Flags().BoolVar(&forceFlag, \"force\", false, \"force upgrade extension, or ignore if latest already installed\")\n  415: \t\t\tcmd.Flags().StringVar(&pinFlag, \"pin\", \"\", \"pin extension to a release tag or commit ref\")\n  529: \t\t\tcmd.Flags().BoolVar(&debug, \"debug\", false, \"log to /tmp/extBrowse-*\")\n\npkg/cmd/gist/delete/delete.go:\n  74: \tcmd.Flags().BoolVar(&opts.Confirmed, \"yes\", false, \"confirm deletion without prompting\")\n\npkg/cmd/gpg-key/delete/delete.go:\n  52: \t_ = cmd.Flags().MarkDeprecated(\"confirm\", \"use `--yes` instead\")\n\npkg/cmd/issue/delete/delete.go:\n  60: \tcmd.Flags().BoolVar(&opts.Confirmed, \"confirm\", false, \"confirm deletion without prompting\")\n  61: \t_ = cmd.Flags().MarkDeprecated(\"confirm\", \"use `--yes` instead\")\n  62: \tcmd.Flags().BoolVar(&opts.Confirmed, \"yes\", false, \"confirm deletion without prompting\")\n\npkg/cmd/issue/develop/develop.go:\n  123: \t_ = cmd.Flags().MarkDeprecated(\"issue-repo\", \"use `--repo` instead\")\n\npkg/cmd/label/delete.go:\n  56: \t_ = cmd.Flags().MarkDeprecated(\"confirm\", \"use `--yes` instead\")\n\npkg/cmd/repo/archive/archive.go:\n  63: \t_ = cmd.Flags().MarkDeprecated(\"confirm\", \"use `--yes` instead\")\n\npkg/cmd/repo/delete/delete.go:\n  68: \tcmd.Flags().BoolVar(&opts.Confirmed, \"confirm\", false, \"confirm deletion without prompting\")\n  69: \t_ = cmd.Flags().MarkDeprecated(\"confirm\", \"use `--yes` instead\")\n  70: \tcmd.Flags().BoolVar(&opts.Confirmed, \"yes\", false, \"confirm deletion without prompting\")\n\npkg/cmd/repo/list/list.go:\n  111: \t_ = cmd.Flags().MarkDeprecated(\"public\", \"use `--visibility=public` instead\")\n  112: \t_ = cmd.Flags().MarkDeprecated(\"private\", \"use `--visibility=private` instead\")\n\npkg/cmd/repo/rename/rename.go:\n  102: \t_ = cmd.Flags().MarkDeprecated(\"confirm\", \"use `--yes` instead\")\n\npkg/cmd/repo/setdefault/setdefault.go:\n  108: \tcmd.Flags().BoolVarP(&opts.ViewMode, \"view\", \"v\", false, \"view the current default repository\")\n  109: \tcmd.Flags().BoolVarP(&opts.UnsetMode, \"unset\", \"u\", false, \"unset the current default repository\")\n\npkg/cmd/repo/unarchive/unarchive.go:\n  62: \t_ = cmd.Flags().MarkDeprecated(\"confirm\", \"use `--yes` instead\")\n\npkg/cmd/ssh-key/delete/delete.go:\n  52: \t_ = cmd.Flags().MarkDeprecated(\"confirm\", \"use `--yes` instead\")\n```\n\n### Affected version\n\n```shell\n$ gh --version \ngh version 2.67.0 (2025-02-11)\nhttps://github.com/cli/cli/releases/tag/v2.67.0\n```\n\n### Steps to reproduce the behavior\n\n- Search codebase with regex `cmd.Flags().*, \"[a-z]+ .*\"\\)`\n\n### Expected vs actual behavior\n\nThe descriptions in above cases should also start with an uppercase letter.\n\n### Logs\n\nN/A\n</BODY>"
+  - name: 'not spam, #10449 (https://github.com/cli/cli/issues/10449)'
+    expected: PASS
+    input: "<TITLE>\nInconsistent format of examples in help text\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nThe format of examples is not consistent.\n\nHere are a few examples:\n\nhttps://github.com/cli/cli/blob/b642da26d0331f6e44af302a6a07eb458df38cd3/pkg/cmd/attestation/trustedroot/trustedroot.go#L57-L59\n\nhttps://github.com/cli/cli/blob/b642da26d0331f6e44af302a6a07eb458df38cd3/pkg/cmd/auth/refresh/refresh.go#L79-L84\n\nhttps://github.com/cli/cli/blob/b642da26d0331f6e44af302a6a07eb458df38cd3/pkg/cmd/api/api.go#L126-L133\n\nhttps://github.com/cli/cli/blob/b642da26d0331f6e44af302a6a07eb458df38cd3/pkg/cmd/cache/list/list.go#L43-L45\n\n### Affected version\n\n```shell\n$ gh --version \ngh version 2.67.0 (2025-02-11)\nhttps://github.com/cli/cli/releases/tag/v2.67.0\n```\n\n### Steps to reproduce the behavior\n\nRun commands from above examples with `--help` flag.\n\n### Expected vs actual behavior\n\nA consistent format should be followed across all commands.\n\nSuggested format:\n\n```\n# Description (Sentence case)\n$ gh ...\n```\n\n### Logs\n\nN/A\n</BODY>"
+  - name: 'not spam, #10442 (https://github.com/cli/cli/issues/10442)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Persistent login issues
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      It's been a week or so since the behavior of gh cli became a bit unbearable. It forces me to sign in to the account for almost every operation. The issue is not related to changing the IDE or rebooting the PC (this happens even during a single session). Everything was properly working before though.
+
+      ### Affected version
+
+      Please run `gh version` and paste the output below.
+
+      ```
+      krau5@pc % gh version
+      gh version 2.66.1 (2025-01-31)
+      https://github.com/cli/cli/releases/tag/v2.66.1
+      ```
+
+      ### Expected vs actual behavior
+
+      I do not remember that the gh cli session has ended at least once before. Now it's almost a part of daily routine, that I have to sign in to GitHub for almost every operation. You can see that `gh auth status` shows that I am logged in to the account and the account is actually active. Although it still asks me to sign in to the account, when I want to do anything with Github (create/manage pr/gist/etc.).
+
+      ### Logs
+
+      Output of `gh auth status`
+      ```
+      krau5@pc % gh auth status -a
+      * Request at 2025-02-13 20:36:39.56569 +0100 CET m=+0.171794168
+      * Request to https://api.github.com/
+      * Request took 274.515833ms
+      github.com
+        ✓ Logged in to github.com account krau5 (keyring)
+        - Active account: true
+        - Git operations protocol: ssh
+        - Token: gho_************************************
+        - Token scopes: 'admin:public_key', 'gist', 'read:org', 'repo'
+      ```
+
+      **Similar issue:** https://github.com/cli/cli/issues/7359
+      </BODY>
+  - name: 'not spam, #10438 (https://github.com/cli/cli/issues/10438)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Data Race when running attestation tests
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      In https://github.com/cli/cli/actions/runs/13301543234/job/37143755142?pr=10430, there is a data race when running the tests:
+
+      ```
+      ==================
+      WARNING: DATA RACE
+      Read at 0x00c000440ae0 by goroutine 72:
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*failAfterNCallsHttpClient).Get()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/mock_httpClient_test.go:69 +0x68
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*LiveClient).getBundle.func1()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client.go:194 +0x78
+        github.com/cenkalti/backoff/v4.RetryNotifyWithTimer.Operation.withEmptyData.func1()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:18 +0x30
+        github.com/cenkalti/backoff/v4.doRetryNotify[go.shape.struct {}]()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:88 +0x15c
+        github.com/cenkalti/backoff/v4.RetryNotifyWithTimer()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:61 +0x80
+        github.com/cenkalti/backoff/v4.RetryNotify()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:49 +0x1b0
+        github.com/cenkalti/backoff/v4.Retry()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:38 +0x190
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*LiveClient).getBundle()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client.go:193 +0x138
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*LiveClient).fetchBundleFromAttestations.func1()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client.go:169 +0x1f0
+        golang.org/x/sync/errgroup.(*Group).Go.func1()
+            /Users/runner/go/pkg/mod/golang.org/x/sync@v0.10.0/errgroup/errgroup.go:78 +0x7c
+
+      Previous write at 0x00c000440ae0 by goroutine 73:
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*failAfterNCallsHttpClient).Get()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/mock_httpClient_test.go:69 +0x7c
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*LiveClient).getBundle.func1()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client.go:194 +0x78
+        github.com/cenkalti/backoff/v4.RetryNotifyWithTimer.Operation.withEmptyData.func1()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:18 +0x30
+        github.com/cenkalti/backoff/v4.doRetryNotify[go.shape.struct {}]()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:88 +0x15c
+        github.com/cenkalti/backoff/v4.RetryNotifyWithTimer()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:61 +0x80
+        github.com/cenkalti/backoff/v4.RetryNotify()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:49 +0x1b0
+        github.com/cenkalti/backoff/v4.Retry()
+            /Users/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.3.0/retry.go:38 +0x190
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*LiveClient).getBundle()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client.go:193 +0x138
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*LiveClient).fetchBundleFromAttestations.func1()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client.go:169 +0x1f0
+        golang.org/x/sync/errgroup.(*Group).Go.func1()
+            /Users/runner/go/pkg/mod/golang.org/x/sync@v0.10.0/errgroup/errgroup.go:78 +0x7c
+
+      Goroutine 72 (running) created at:
+        golang.org/x/sync/errgroup.(*Group).Go()
+            /Users/runner/go/pkg/mod/golang.org/x/sync@v0.10.0/errgroup/errgroup.go:75 +0x10c
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*LiveClient).fetchBundleFromAttestations()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client.go:1[54](https://github.com/cli/cli/actions/runs/13301543234/job/37143755142?pr=10430#step:5:55) +0xb4
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.TestFetchBundleFromAttestations_FailOnTheSecondAttestation()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client_test.go:215 +0x2e0
+        testing.tRunner()
+            /Users/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.5.darwin-arm64/src/testing/testing.go:1690 +0x184
+        testing.(*T).Run.gowrap1()
+            /Users/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.5.darwin-arm64/src/testing/testing.go:1743 +0x40
+
+      Goroutine 73 (running) created at:
+        golang.org/x/sync/errgroup.(*Group).Go()
+            /Users/runner/go/pkg/mod/golang.org/x/sync@v0.10.0/errgroup/errgroup.go:75 +0x10c
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.(*LiveClient).fetchBundleFromAttestations()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client.go:154 +0xb4
+        github.com/cli/cli/v2/pkg/cmd/attestation/api.TestFetchBundleFromAttestations_FailOnTheSecondAttestation()
+            /Users/runner/work/cli/cli/pkg/cmd/attestation/api/client_test.go:215 +0x2e0
+        testing.tRunner()
+            /Users/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.5.darwin-arm64/src/testing/testing.go:1690 +0x184
+        testing.(*T).Run.gowrap1()
+            /Users/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.5.darwin-arm64/src/testing/testing.go:1743 +0x40
+      ==================
+      --- FAIL: TestFetchBundleFromAttestations_FailOnTheSecondAttestation (0.[63](https://github.com/cli/cli/actions/runs/13301543234/job/37143755142?pr=10430#step:5:64)s)
+          testing.go:1399: race detected during execution of test
+      ```
+      </BODY>
+  - name: 'not spam, #10432 (https://github.com/cli/cli/issues/10432)'
+    expected: PASS
+    input: "<TITLE>\nInconsistent use of curly braces and square brackets for command args syntax e.g. `{args}` and `[args]` respectively\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nAs mentioned in the title, the command args syntax is inconsistent.\n\n### Affected version\n\n```shell\n$ gh --version \ngh version 2.67.0 (2025-02-11)\nhttps://github.com/cli/cli/releases/tag/v2.67.0\n```\n\n### Steps to reproduce the behavior\n\n- Use regex `Use:\\s+\".* \\{.*\\}.*\"` to find occurrences with curly braces\n\nHere's a list of such occurrences from VSCode:\n\n```\n20 results - 19 files\n\npkg/cmd/alias/delete/delete.go:\n  28: Use:   \"delete {<alias> | --all}\",\n\npkg/cmd/extension/command.go:\n  423: \t\tUse:   \"upgrade {<name> | --all}\",\n\npkg/cmd/gist/delete/delete.go:\n  38: Use:   \"delete {<id> | <url>}\",\n\npkg/cmd/gist/edit/edit.go:\n  59: Use:   \"edit {<id> | <url>} [<filename>]\",\n\npkg/cmd/gist/rename/rename.go:\n  38: Use:   \"rename {<id> | <url>} <oldFilename> <newFilename>\",\n\npkg/cmd/issue/close/close.go:\n  38: Use:   \"close {<number> | <url>}\",\n\npkg/cmd/issue/comment/comment.go:\n  25: Use:   \"comment {<number> | <url>}\",\n\npkg/cmd/issue/delete/delete.go:\n  41: Use:   \"delete {<number> | <url>}\",\n\npkg/cmd/issue/develop/develop.go:\n  45: Use:   \"develop {<number> | <url>}\",\n\npkg/cmd/issue/edit/edit.go:\n  52: Use:   \"edit {<numbers> | <urls>}\",\n\npkg/cmd/issue/lock/lock.go:\n  128: Use:   \"lock {<number> | <url>}\",\n  171: Use:   \"unlock {<number> | <url>}\",\n\npkg/cmd/issue/pin/pin.go:\n  35: Use:   \"pin {<number> | <url>}\",\n\npkg/cmd/issue/reopen/reopen.go:\n  36: Use:   \"reopen {<number> | <url>}\",\n\npkg/cmd/issue/transfer/transfer.go:\n  35: Use:   \"transfer {<number> | <url>} <destination-repo>\",\n\npkg/cmd/issue/unpin/unpin.go:\n  35: Use:   \"unpin {<number> | <url>}\",\n\npkg/cmd/issue/view/view.go:\n  49: Use:   \"view {<number> | <url>}\",\n\npkg/cmd/pr/close/close.go:\n  40: Use:   \"close {<number> | <url> | <branch>}\",\n\npkg/cmd/pr/reopen/reopen.go:\n  32: Use:   \"reopen {<number> | <url> | <branch>}\",\n\npkg/cmd/repo/license/view/view.go:\n  37: Use:   \"view {<license-key> | <SPDX-ID>}\",\n```\n\nThe majority of the commands are using square brackets syntax:\n\n- **curly braces** (`Use:\\s+\".* \\{.*\\}.*\"`) (**20 results**)\n- **square brackets** (`Use:\\s+\".* \\[.*\\].*\"`) (**75 results**)\n\n### Expected vs actual behavior\n\nThe syntax should be consistent.\n\n### Logs\n\nN/A\n</BODY>"
+  - name: 'not spam, #10424 (https://github.com/cli/cli/issues/10424)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Add option to not delete resource group when running azd down command
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      Presently, it appears that the `azd down` command always deletes the entire resource group and there isn't any way to change that (unless I'm missing something in [the documentation](https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/reference#azd-down)). This discourages the use of `azd down` if the user running the command doesn't have subscription-wide permissions to create a new resource group and must use an existing resource group created by someone else, with the template modified for a [resource group scoped deployment](https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/resource-group-scoped-deployments).
+
+      In such cases, the user needs to manually delete the individual resources through the Azure Portal or Azure CLI to avoid deleting the resource group, thus pulling the user away from using azd exclusively and towards using other tools. This has been my personal experience.
+
+      ### Proposed solution
+
+      I think this could be an additional flag for the `azd down` command that allows you to choose whether the resource group gets deleted or not. It might be worth exploring whether it makes sense to have the resource group be **not** deleted by default when `targetScope = 'resourceGroup'` in main.bicep.
+
+      ### Additional context
+
+      What shows up when I try to run `azd down` even though I want to avoid deleting the resource group:
+
+      ![Image](https://github.com/user-attachments/assets/b6866bba-f5ee-4319-890f-c92b688fbf3e)
+
+      For context, there are only 8 individual resources within this resource group, meaning that the displayed total of 9 resources to delete must also include the resource group itself. I don't want the resource group to be deleted.
+      </BODY>
+  - name: 'not spam, #10418 (https://github.com/cli/cli/issues/10418)'
+    expected: PASS
+    input: "<TITLE>\ngh attestation verify always returns a 0 exit code\n</TITLE>\n\n<BODY>\n### Describe the bug\n\ngh attestation verify always returns a 0 exit code, even when it does not find the correct attestation. \n\n### Affected version\n\ngh version 2.66.1 (2025-01-31)\nhttps://github.com/cli/cli/releases/tag/v2.66.1\n\n### Steps to reproduce the behavior\n\n```bash\n#!/bin/bash\n\n# Run a command\ngh attestation verify oci://ghcr.io/repo:5.20.6 --repo repo --signer-repo signer-repo --predicate-type https://slsa.dev/provenance/v1\n\n# Capture the exit code\nexit_code=$?\n\n# Show the exit code\necho \"Exit code: $exit_code\"\n```\n\n```bash\n✗ No attestations found with predicate type: https://slsa.dev/provenance/v1\nExit code: 0\n```\n### Expected vs actual behavior\nIs this the intended behaviour ? I would expect to get a non-zero exit code if the command fails to find any attestations. \n</BODY>"
+  - name: 'not spam, #10390 (https://github.com/cli/cli/issues/10390)'
+    expected: PASS
+    input: "<TITLE>\nTestLiveSigstoreVerifier/with_2/3_verified_attestations is flaky\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nTestLiveSigstoreVerifier/with_2/3_verified_attestations occasionally fails\n\n### Affected version\n\nPRs to trunk\n\n### Steps to reproduce the behavior\n\n1. Type this '...'\n2. View the output '....'\n3. See error\n\n### Expected vs actual behavior\n\nExpected: pass\n\nActual:\n\nhttps://github.com/cli/cli/actions/workflows/go.yml?query=is%3Afailure\n\n#### windows-latest\nhttps://github.com/cli/cli/actions/runs/13184622557/job/36803634377#step:5:59\n```\n\n--- FAIL: TestLiveSigstoreVerifier (3.12s)\n    --- FAIL: TestLiveSigstoreVerifier/with_2/3_verified_attestations (1.12s)\n        sigstore_integration_test.go:79: \n            \tError Trace:\tD:/a/cli/cli/pkg/cmd/attestation/verification/sigstore_integration_test.go:79\n            \tError:      \t\"[0xc00004b0f0]\" should have 2 item(s), but has 1\n            \tTest:       \tTestLiveSigstoreVerifier/with_2/3_verified_attestations\nFAIL\nFAIL\tgithub.com/cli/cli/v2/pkg/cmd/attestation/verification\t3.468s\n```\n\nhttps://github.com/cli/cli/actions/runs/13202858867/job/36858853456#step:5:61\n\n```\n--- FAIL: TestVerifyAttestations (1.78s)\n    --- FAIL: TestVerifyAttestations/passes_verification_with_2/3_attestations_passing_Sigstore_verification (0.37s)\n        attestation_integration_test.go:65: \n            \tError Trace:\tD:/a/cli/cli/pkg/cmd/attestation/verify/attestation_integration_test.go:65\n            \tError:      \t\"[0xc000875820]\" should have 2 item(s), but has 1\n            \tTest:       \tTestVerifyAttestations/passes_verification_with_2/3_attestations_passing_Sigstore_verification\nFAIL\nFAIL\tgithub.com/cli/cli/v2/pkg/cmd/attestation/verify\t12.350s\n```\n\n#### macos-latest\nhttps://github.com/cli/cli/actions/runs/12916504935/job/36020835039#step:5:60\n```\n--- FAIL: TestVerifyAttestations (1.45s)\n    --- FAIL: TestVerifyAttestations/all_attestations_pass_verification (0.37s)\n        attestation_integration_test.go:53: \n            \tError Trace:\t/Users/runner/work/cli/cli/pkg/cmd/attestation/verify/attestation_integration_test.go:53\n            \tError:      \t\"[0xc000409e[60](https://github.com/cli/cli/actions/runs/12916504935/job/36020835039#step:5:61)]\" should have 2 item(s), but has 1\n            \tTest:       \tTestVerifyAttestations/all_attestations_pass_verification\nFAIL\n```\n\n#### ubuntu-latest\nhttps://github.com/cli/cli/actions/runs/12680772503/job/35343196076#step:5:64\n```\n--- FAIL: TestVerifyAttestations (1.32s)\n    --- FAIL: TestVerifyAttestations/passes_verification_with_2/3_attestations_passing_Sigstore_verification (0.26s)\n        attestation_integration_test.go:[65](https://github.com/cli/cli/actions/runs/12680772503/job/35343196076#step:5:66): \n            \tError Trace:\t/home/runner/work/cli/cli/pkg/cmd/attestation/verify/attestation_integration_test.go:65\n            \tError:      \t\"[0xc0009[67](https://github.com/cli/cli/actions/runs/12680772503/job/35343196076#step:5:68)ae0]\" should have 2 item(s), but has 1\n            \tTest:       \tTestVerifyAttestations/passes_verification_with_2/3_attestations_passing_Sigstore_verification\nFAIL\nFAIL\tgithub.com/cli/cli/v2/pkg/cmd/attestation/verify\t6.048s\n```\n\nhttps://github.com/cli/cli/actions/runs/12659904205/job/35279973709#step:5:64\n```\n--- FAIL: TestVerifyAttestations (1.34s)\n    --- FAIL: TestVerifyAttestations/all_attestations_pass_verification (0.45s)\n        attestation_integration_test.go:53: \n            \tError Trace:\t/home/runner/work/cli/cli/pkg/cmd/attestation/verify/attestation_integration_test.go:53\n            \tError:      \t\"[0xc0008511f0]\" should have 2 item(s), but has 1\n            \tTest:       \tTestVerifyAttestations/all_attestations_pass_verification\nFAIL\nFAIL\tgithub.com/cli/cli/v2/pkg/cmd/attestation/verify\t6.936s\n```\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\n</BODY>"
+  - name: 'not spam, #10380 (https://github.com/cli/cli/issues/10380)'
+    expected: PASS
+    input: "<TITLE>\n`gh project item-edit` should allow explicit `--number 0` field values\n</TITLE>\n\n<BODY>\n### Describe the bug\n\n> Here's another case that I found out for `--number` that 0 is discarded as an invalid value:\n> \n> ```shell\n> $ bin/gh project item-edit --project-id $projectId --id $itemId --field-id $fieldId --number 0\n> error: no changes to make\n> ```\n> \n> However, given above valid ranges, it is a valid value and can be set from UI:\n> \n> ![Image](https://github.com/user-attachments/assets/9b1591dc-82f8-4a5d-a3e5-2fb5f685a111)\n\n _Originally posted by @iamazeem in [#10342](https://github.com/cli/cli/issues/10342#issuecomment-2639592210)_\n\nAs stated in the issue, this appears to prevent users from accidentally setting item field values to zero due to zero value for float flags:\n\nhttps://github.com/cli/cli/blob/756ba75c9ded6d1d201ddef4f271f4ba37057659/pkg/cmd/project/item-edit/item_edit.go#L79-L96\n\nhttps://github.com/cli/cli/blob/756ba75c9ded6d1d201ddef4f271f4ba37057659/pkg/cmd/project/item-edit/item_edit.go#L148-L155\n\n### Affected version\n\n`2.66.1`\n\n### Steps to reproduce the behavior\n\n1. Create v2 project with `Number` fields\n2. Add issue to project\n3. `gh project item-edit --project-id $projectId --id $itemId --field-id $fieldId --number 0`\n\n### Expected vs actual behavior\n\nWhen a user calls `gh project item-edit` and `--number 0` is explicitly set, then we allow the item field value to be set to zero.\n\n### Logs\n\n```shell\n$ GH_DEBUG=api ./bin/gh project item-edit --project-id PVT_kwDOBWmBn84Al2QA --id PVTI_lADOBWmBn84Al2QAzgXCZ4c --field-id PVTF_lADOBWmBn84Al2QAzgnpmgo --number 0                    \nerror: no changes to make\n```\n</BODY>"
+  - name: 'not spam, #10378 (https://github.com/cli/cli/issues/10378)'
+    expected: PASS
+    input: "<TITLE>\ngh api call to add sub-issue fails with HTTP/2.0 500 Internal Server Error\n</TITLE>\n\n<BODY>\n### Describe the bug\nWhen I attempt to add an issue as a sub_issue using the gh api --verbose call [(see ref)](https://docs.github.com/en/rest/issues/sub-issues?apiVersion=2022-11-28#add-sub-issue) the response contains HTTP/2.0 500 Internal Server Error and the sub issue is not set.\n\nI can create the parent and sub issue; therefore, the need for \"Issues\" repository permissions (write) is met.  I've tried this with both the issue number and issue id. \n\n### Affected version\ngh version 2.65.0 (2025-01-06)\nhttps://github.com/cli/cli/releases/tag/v2.65.0\n\n### Steps to reproduce the behavior\n\n1. Set Org and Repo environment variables. \n```\n    export OWNER=YOUR_ORG; export REPO=TEST_REPO\n```\n2. Create two issues and save the response data\nParent:\n```\n      gh api --method POST \\\n     -H \"Accept: application/vnd.github+json\" \\\n     -H \"X-GitHub-Api-Version: 2022-11-28\" \\\n     \"/repos/$OWNER/$REPO/issues\" \\\n     -F \"title=Issue Parent\" \\\n     -F \"body=Issue description\"\n```\nSub Issue:\n```\n      gh api --method POST \\\n     -H \"Accept: application/vnd.github+json\" \\\n     -H \"X-GitHub-Api-Version: 2022-11-28\" \\\n     \"/repos/$OWNER/$REPO/issues\" \\\n     -F \"title=Sub Issue\" \\\n     -F \"body=Issue description\"\n```\n\n4. Set the issue environment variables\n```\n  export ISSUE_NUMBER=[ISSUE NUMBER FROM PARENT ISSUE RESPONSE DATA]\n  export SUB_ISSUE_ID=[ISSUE NUMBER FROM SUB ISSUE RESPONSE DATA]\n````\n5. Attempt to set the sub issue per\n```\n  gh api --verbose \\\n  --method POST \\\n  -H \"Accept: application/vnd.github+json\" \\\n  -H \"X-GitHub-Api-Version: 2022-11-28\" \\\n  /repos/$OWNER/$REPO/issues/$ISSUE_NUMBER/sub_issues \\\n   -F \"sub_issue_id=$SUB_ISSUE_ID\"\n```\n6. See HTTP/2.0 500 Internal Server Error in the response\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n```\n* Request at 2025-02-06 08:21:08.098032 -0500 EST m=+0.141797293\n* Request to https://api.github.com/repos/[REDACTED]/[REDACTED]/issues/[REDACTED]/sub_issues\n> POST /repos/[REDACTED]/[REDACTED]/issues/[REDACTED]/sub_issues HTTP/1.1\n> Host: api.github.com\n> Accept: application/vnd.github+json\n> Authorization: token [REDACTED]\n> Content-Length: 21\n> Content-Type: application/json; charset=utf-8\n> Time-Zone: America/New_York\n> User-Agent: GitHub CLI 2.65.0\n> X-Github-Api-Version: 2022-11-28\n\n{\n  \"sub_issue_id\": [REDACTED]\n}\n\n< HTTP/2.0 500 Internal Server Error\n< Access-Control-Allow-Origin: *\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\n< Content-Length: 0\n< Content-Security-Policy: default-src 'none'\n< Content-Type: application/json; charset=utf-8\n< Date: Thu, 06 Feb 2025 13:21:08 GMT\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\n< Server: github.com\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\n< Vary: Accept-Encoding, Accept, X-Requested-With\n< X-Accepted-Oauth-Scopes: repo\n< X-Content-Type-Options: nosniff\n< X-Frame-Options: deny\n< X-Github-Api-Version-Selected: 2022-11-28\n< X-Github-Media-Type: github.v3; format=json\n< X-Github-Request-Id: [REDACTED]\n< X-Oauth-Client-Id: [REDACTED]\n< X-Oauth-Scopes: gist, project, read:org, repo, workflow\n< X-Ratelimit-Limit: 5000\n< X-Ratelimit-Remaining: 4989\n< X-Ratelimit-Reset: 1738850113\n< X-Ratelimit-Resource: core\n< X-Ratelimit-Used: 11\n< X-Xss-Protection: 0\n\n* Request took 343.284416ms\n```\n</BODY>"
+  - name: 'not spam, #10377 (https://github.com/cli/cli/issues/10377)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      [feature] Create PR review suggestion
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      There was a [discussion](https://github.com/cli/cli/discussions/5904) but I couldn't find an issue so I'm opening one.
+
+      This is a feature request for an equivalent of the "Add a suggestion" button when reviewing PRs (in a web browser).
+
+      ### Proposed solution
+
+      a new subcommand
+
+      ```
+      gh pr suggest [pr_number|url|branch]
+      ```
+
+      which creates a review suggestion from the changes in git index (or a commit if it makes more sense)
+
+      ### Additional context
+
+      -
+      </BODY>
+  - name: 'not spam, #10370 (https://github.com/cli/cli/issues/10370)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh pr comment --edit-last` does not proceed if no comment already exists for the user
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      As the title suggests, using the `--edit-last` flag for `gh pr comment` will return `no comments found for the current user` and fail
+
+      One way to circumvent this is to check for existing comments and either comment if no comment already exists or `--edit-last` if one comment exists
+
+      But to me it'd make more sense for the flag to have the logic inside
+
+      ### Proposed solution
+
+      While this makes sense, what would possibly make more sense is to comment anyway if no comment is found, as this would be the first comment for the user, and then indeed it'll get edited in the future using the flag
+      </BODY>
+  - name: 'not spam, #10366 (https://github.com/cli/cli/issues/10366)'
+    expected: PASS
+    input: "<TITLE>\nAdd the ability to delete the \"last\" comment, similar to `--edit-last`\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\n\nI'd love to see a way to delete PR and issue comments with the CLI. \n\n[This previous issue](https://github.com/cli/cli/issues/3613) highlighted some questions/friction around a potential `delete --id 1234` type command, which I think are valid concerns.\n\nI'd like to propose an ability to delete comments by building off of the existing behavior of `--edit-last`\n\n### Proposed solution\n\n`gh [issue|pr] comment --edit-last --delete` or `gh [issue|pr] comment --delete-last`\n\nThis command would remove the last comment made by the CLI user, similar to how `--edit-last` works.\n\n- This would benefit users by offering _some_ type of comment delete functionality in the CLI, while avoiding the complexity/uncertainty of having to discover a comment ID to supply to the delete command.\n- This would align with existing behavior (`--edit-last` flag)\n\n### Additional context\n\nI don't think this would totally solve _all_ the requests for a \"delete comment\" type command. It may solve a portion of them (e.g. use cases that leverage CI bots to leave comments) - maybe that is an acceptable compromise.\n</BODY>"
+  - name: 'not spam, #10358 (https://github.com/cli/cli/issues/10358)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Security issue - Release 2.66.1 install blocked by Microsoft Defender Antivirus
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      Upgrading from v2.66.0 to v2.66.1 fails because of virus detection by Microsoft Defender Antivirus (Windows 11, version 24H2; Security Intelligence version 1.421.1648.0). The detected threat is [Trojan:Script/Wacatac.B!ml](https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Trojan%3AScript%2FWacatac.B!ml&threatid=2147735503).
+
+      I'm not sure of the cause(s) behind the issue but the issue appears to be specific to release v2.66.1 of `gh`.
+
+      ### Affected version
+
+      Release 2.66.1 is affected.
+      (Release 2.66.0 is **not** affected.)
+
+      ### Steps to reproduce the behavior
+
+      If the GitHub CLI is not installed:
+      1. Run `winget install --id GitHub.cli` (which will use the current latest release which is 2.66.1).
+      2. The console will report `An anti-virus product reports an infection in the installer` and Windows will display a notification window.
+      3. Run `winget install --id GitHub.cli --version 2.66.0`. (v2.66.0 is the most recent release prior to v2.66.1.)
+      4. The console will report `Successfully installed`.
+
+      If the GitHub CLI is already installed:
+      1. Run `winget upgrade --id GitHub.cli` (which will use the current latest release which is 2.66.1).
+      2. The console will report `An anti-virus product reports an infection in the installer` and Windows will display a notification window.
+
+      ### Expected vs actual behavior
+
+      The expectation is the release package will be free of viruses.
+
+      ### Logs
+      ```
+      C:\Users\jrdodds>winget upgrade --id GitHub.cli
+      Found GitHub CLI [GitHub.cli] Version 2.66.1
+      This application is licensed to you by its owner.
+      Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
+      Downloading https://github.com/cli/cli/releases/download/v2.66.1/gh_2.66.1_windows_amd64.msi
+        13.0 MB / 13.0 MB
+      Successfully verified installer hash
+      An anti-virus product reports an infection in the installer
+
+      C:\Users\jrdodds>
+      ```
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+      </BODY>
+  - name: 'not spam, #10348 (https://github.com/cli/cli/issues/10348)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      [gh config] Inconsistent formatting of GitHub CLI manual entry
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      Apparently, when there's pipe sign `|` in the test, the formatting in the manual becomes inconsistent.
+      Looks like it's being rendered as a Markdown table.
+
+      See the screenshot for [`gh config`](https://cli.github.com/manual/gh_config) below:
+
+      ![Image](https://github.com/user-attachments/assets/4accdc4c-6a16-4a11-b681-3e04f42d6898)
+
+      The relevant output of `gh config --help` command:
+
+      ```shell
+      $ gh config --help
+      Display or change configuration settings for gh.
+
+      Current respected settings:
+      - `git_protocol`: the protocol to use for git clone and push operations {https|ssh} (default https)
+      - `editor`: the text editor program to use for authoring text
+      - `prompt`: toggle interactive prompting in the terminal {enabled|disabled} (default enabled)
+      - `prefer_editor_prompt`: toggle preference for editor-based interactive prompting in the terminal {enabled|disabled} (default disabled)
+      - `pager`: the terminal pager program to send standard output to
+      - `http_unix_socket`: the path to a Unix socket through which to make an HTTP connection
+      - `browser`: the web browser to use for opening URLs
+      ...
+      ```
+
+      Affected settings are:
+
+      - `git_protocol`
+      - `prompt`
+      - `prefer_editor_prompt`
+
+      Relevant code line where the allowed values are joined with `|`:
+
+      https://github.com/cli/cli/blob/42c0cb038be4df1da392f544af5de9ef8b9c01fd/pkg/cmd/config/config.go#L23
+
+      ### Affected version
+
+      ```shell
+      $ gh version
+      gh version 2.66.0 (2025-01-30)
+      https://github.com/cli/cli/releases/tag/v2.66.0
+      ```
+
+      ### Steps to reproduce the behavior
+
+      See https://cli.github.com/manual/gh_config.
+
+      ### Expected vs actual behavior
+
+      The formatting in the manual should be consistent.
+
+      ### Logs
+
+      N/A
+      </BODY>
+  - name: 'not spam, #10342 (https://github.com/cli/cli/issues/10342)'
+    expected: PASS
+    input: "<TITLE>\ngh project item-edit command fails with value for --number is floating point\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nI'm trying to issue the gh project item-edit command to set the value of an item field to a floating point value. The command looks like this:\n\n```\ngh project item-edit --project-id $projectId --id $itemId --field-id $fieldId --number 69.84 \n```\n\nThe command fails with this error:\n> GraphQL: Number values cannot exceed 8 decimal places (updateProjectV2ItemFieldValue)\n\nwhich would be helpful if the value I passed had more than 8 decimal places, but it doesn't.\n\n### Affected version\n\nPlease run `gh version` and paste the output below.\n\ngh version 2.65.0 (2025-01-06)\n\n### Steps to reproduce the behavior\n\n- Create a project a define a number field in it.\n- Add an item to the project\n- Figure out the project ID, item ID, and field ID (no small feat).\n- Issue the command above.\n\n### Expected vs actual behavior\n\nThe update should succeed when the value provided is valid.\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\n\n[mikekistler@macbookpro] ~>export GH_DEBUG=true                                                                        \n[mikekistler@macbookpro] ~>gh project item-edit --project-id $projectId --id $itemId --field-id $fieldId --number 69.84\n* Request at 2025-01-30 21:57:28.393059 -0600 CST m=+0.122595376\n* Request to https://api.github.com/graphql\n* Request took 379.058041ms\nGraphQL: Number values cannot exceed 8 decimal places (updateProjectV2ItemFieldValue)\n[mikekistler@macbookpro] ~>\n</BODY>"
+  - name: 'not spam, #10330 (https://github.com/cli/cli/issues/10330)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Remove v1 project logic from PR Automation workflow
+      </TITLE>
+
+      <BODY>
+      ### Overview
+
+      In #10324, the PR Automation job was failing because of a race condition around adding a pull request to a v1 project board which @cli/code-reviewers no longer use:
+
+      ```shell
+      Run commentPR () {
+      https://github.com/cli/cli/pull/10324
+      gh: Project already has the associated issue
+      Error: Process completed with exit code 1.
+      ```
+
+      This issue is to remove that logic from the workflow in light of [GitHub deprecating v1 project support](https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/) until the maintainers revisit how we internally want to review and manage the state of OSS pull requests.
+      </BODY>
+  - name: 'not spam, #10316 (https://github.com/cli/cli/issues/10316)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      gh search code `--exclude-archived`
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      A clear and concise description of what the feature or problem is.
+
+      I am trying to search using gh search code similar to web search but I am not seeing option to exclude archived repos
+
+      ### Proposed solution
+
+      I propose to have --exclude-archive flag included
+
+      How will it benefit CLI and its users?
+
+      It will be in sync with capabilities what we can perform through Github Web search
+      ### Additional context
+
+      Add any other context like screenshots or mockups are helpful, if applicable.
+      </BODY>
+  - name: 'not spam, #10312 (https://github.com/cli/cli/issues/10312)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh pr merge --squash` does not allow editing the commit message
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      Unlike the web interface, and unlike other `gh` commands (e.g. `pr create`), running `gh pr merge --squash` on a PR does not prompt/ask if I'd like to edit the commit message before committing (instead it just implicitly goes with the default generated message). This behavior is somewhat unexpected, and also cannot be undone. For these reasons, I am listing this as a bug.
+
+      ### Affected version
+
+      `2.64.0`
+
+      ### Steps to reproduce the behavior
+
+      Run `gh pr merge --squash #XXX` on an open PR.
+
+      ### Expected behavior
+
+      Prompt/ask if I'd like to edit the commit message (using my editor) prior to committing.
+
+      The same should probably apply for regular merges as well (if that's not already the current behavior).
+
+      Further (not totally necessary but would be nice), if for some reason it can't let me edit the message or access my editor, it should at least print out the message that it will generate and use and then allow me to confirm/deny just before merging.
+      </BODY>
+  - name: 'not spam, #10301 (https://github.com/cli/cli/issues/10301)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      How to get iteration-id
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      I want to set the iteration via github cli through the usage of `gh project item-edit` - for this to work i need th `iteration-id` - however i am not able to find any source where i get the ids of iterations via gh cli.
+      When calling `gh project item-list` no iteration id is returned either:
+
+      ![Image](https://github.com/user-attachments/assets/3ad8b53a-9455-4f79-9d87-32da323f4447)
+
+      ### Proposed solution
+
+      either this should be returned with the field-list (Single select fields return their options there aswell) or another command should be introduced (e.g. iteration-list) to get the iterations. Also it would be great if `item-list` would also return its iteration
+
+      ### Additional context
+
+      `gh copilot suggest` suggested `gh api projects/{project-id}/iterations --jq '.[0].iterationId'` however i get a 404 back when trying to execute this.
+      </BODY>
+  - name: 'not spam, #10277 (https://github.com/cli/cli/issues/10277)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Set default repo when creating fork during pr creation
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When creating a fork during PR creation the default repository should be set
+
+      ### Affected version
+
+      2.49.2
+
+      ### Steps to reproduce the behavior
+
+      1. `gh repo clone ...` a 3rd party repository you do not have forked
+      2. `gh pr create`
+
+      ### Expected vs actual behavior
+
+      After this the PR is created, but if I want to send another PR, I get a complaint that the default repository needs to be set manually using `set-default` first.
+      If so, it would be nice if not an error but directly a selection would be shown.
+      But actually after creating that fork, I'd expect the upstream to automatically be set as default repository.
+      </BODY>
+  - name: 'not spam, #10266 (https://github.com/cli/cli/issues/10266)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Open wiki repositories with gh repo view
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      Command `gh repo view` does not open wiki repositories
+
+      ### Proposed solution
+
+      open repo in the wiki tab
+
+      ### Additional context
+
+      ![Image](https://github.com/user-attachments/assets/8ffc6b52-e0d2-4b7a-a250-c5bdcb47398d)
+      </BODY>
+  - name: 'not spam, #10261 (https://github.com/cli/cli/issues/10261)'
+    expected: PASS
+    input: "<TITLE>\nAllow `--jq` and `--template` to be used together in `gh api`\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\n\nWhen using `gh api`, I would like to be able to use the expressive power of `--jq` to manipulate/filter the JSON response data, and then `--template` to render it, but currently that doesn't seem to be allowed:\n\n- https://github.com/cli/cli/issues/10260\n  - > Looking closer at that code, we can see there is an error case below this that I would have expected to be shown instead:\n    > \n    > > only one of `--template`, `--jq`, `--silent`, or `--verbose` may be used\n    > \n    > https://github.com/cli/cli/blob/60f8417d4ba30505bf396832a29539f696adbfec/pkg/cmd/api/api.go#L255-L263\n    > \n    > _Originally posted by @0xdevalias in https://github.com/cli/cli/issues/10260_\n\n### Proposed solution\n\nIf it were possible to pass both `--jq` and `--template` together, then users would have more expressive ability to manipulate API response data through `gh api` without having to resort to moving to external tools/processing.\n\nIn particular, this would allow users to use `--jq`'s deeper functionality for manipulation, while leveraging `--template`'s simple/clean syntax for rendering the output.\n\n### Additional context\n\nSee also:\n\n- https://github.com/cli/cli/issues/10260\n- https://github.com/cli/cli/issues/10262\n</BODY>"
+  - name: 'not spam, #10260 (https://github.com/cli/cli/issues/10260)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Incorrect error shown (the `--slurp` option is not supported with `--jq` or `--template`) when passing `--jq` + `--template` without `--slurp`
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When running the following:
+
+      ```
+      ⇒ gh api notifications -F participating=true --jq '.' --template '{{range .}}{{tablerow .repository.full_name (truncate 100 .subject.title) .subject.type .reason (timeago .updated_at)}}{{end}}'
+      ```
+
+      I get the following error:
+
+      ```
+      the `--slurp` option is not supported with `--jq` or `--template`
+      ```
+
+      Even though my command doesn't include `--slurp`, and it only attempts to use `--jq` and `--template` together.
+
+      This was seemingly introduced in this PR:
+
+      - https://github.com/cli/cli/pull/8620
+
+      https://github.com/cli/cli/blob/60f8417d4ba30505bf396832a29539f696adbfec/pkg/cmd/api/api.go#L246-L253
+
+      Looking closer at that code, we can see there is an error case below this that I would have expected to be shown instead:
+
+      > only one of `--template`, `--jq`, `--silent`, or `--verbose` may be used
+
+      https://github.com/cli/cli/blob/60f8417d4ba30505bf396832a29539f696adbfec/pkg/cmd/api/api.go#L255-L263
+
+      ### Steps to reproduce the behavior
+
+      See above.
+
+      ### Expected vs actual behavior
+
+      Ideally I would expect `--jq` to allow me to process the JSON, and then `--template` to allow me to render that processed json. I have raised a feature request for that aspect here:
+
+      - https://github.com/cli/cli/issues/10261
+
+      If for some reason there is an actual technical limitation as to why that isn't possible, then I would at least expect the error message to accurately describe the error in what I am trying to do, and not mention a seemingly not used argument.
+
+      ### Logs
+
+      Paste the activity from your command line. Redact if needed.
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+
+      ```
+      the `--slurp` option is not supported with `--jq` or `--template`
+
+      Usage:  gh api <endpoint> [flags]
+
+      Flags:
+            --cache duration        Cache the response, e.g. "3600s", "60m", "1h"
+        -F, --field key=value       Add a typed parameter in key=value format
+        -H, --header key:value      Add a HTTP request header in key:value format
+            --hostname string       The GitHub hostname for the request (default "github.com")
+        -i, --include               Include HTTP response status line and headers in the output
+            --input file            The file to use as body for the HTTP request (use "-" to read from standard input)
+        -q, --jq string             Query to select values from the response using jq syntax
+        -X, --method string         The HTTP method for the request (default "GET")
+            --paginate              Make additional HTTP requests to fetch all pages of results
+        -p, --preview names         GitHub API preview names to request (without the "-preview" suffix)
+        -f, --raw-field key=value   Add a string parameter in key=value format
+            --silent                Do not print the response body
+            --slurp                 Use with "--paginate" to return an array of all pages of either JSON arrays or objects
+        -t, --template string       Format JSON output using a Go template; see "gh help formatting"
+            --verbose               Include full HTTP request and response in the output
+      ```
+      </BODY>
+  - name: 'not spam, #10254 (https://github.com/cli/cli/issues/10254)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh pr checkout` defies negative refspec in `remote.*.<name>`
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      We have some release Actions that push artefacts to `v123-deploy` when `v123` tag is created. I never need the `*-deploy` tags, so to avoid fetching them, in my `.git/config`:
+
+      ```gitconfig
+      [remote "origin"]
+      	url = git@github.com:org/repo.git
+      	fetch = +refs/heads/*:refs/remotes/origin/*
+              fetch = ^refs/heads/*-deploy
+              fetch = ^refs/tags/*-deploy
+      ```
+
+      However if I do a `gh pr checkout 123456`, it'll fetch all those `*-deploy` tags.
+
+      ```sh
+      $ gh --version
+      gh version 2.65.0-11-g0006091d7 (2025-01-07)
+      https://github.com/cli/cli/releases/latest
+      ```
+
+      ### Steps to reproduce the behavior
+
+      1. Set up negative fetch refspecs (doc: https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt-ltrefspecgt)
+      2. Run `gh pr checkout 123456`
+      3. It'll start fetching all the ignored tags
+
+      ### Expected vs actual behavior
+
+      `gh` respects my `remote.*.<name>` configs.
+
+      ### Logs
+
+      Paste the activity from your command line. Redact if needed.
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+      ```sh
+      $ GH_DEBUG=true gh pr checkout 123456
+      [git remote -v]
+      [git config --get-regexp ^remote\..*\.gh-resolved$]
+      * Request at 2025-01-16 15:24:11.714671 +1100 AEDT m=+0.135416674
+      * Request to https://api.github.com/graphql
+      * Request took 611.486474ms
+      ⣾* Request at 2025-01-16 15:24:12.327912 +1100 AEDT m=+0.748639651
+      * Request to https://api.github.com/graphql
+      ⢿* Request took 382.392664ms
+      [git remote -v]
+      [git config --get-regexp ^remote\..*\.gh-resolved$]
+      [git show-ref --verify -- refs/heads/feat-branch]
+      [git -c credential.helper= -c credential.helper=!"/usr/local/bin/gh" auth git-credential fetch origin +refs/heads/feat-branch:refs/remotes/origin/feat-branch]
+      From github.com:org/repo
+       * [new tag]             v782-deploy -> v782-deploy
+       * [new tag]             v783-deploy -> v783-deploy
+       * [new tag]             v784-deploy -> v784-deploy
+       * [new tag]             v785-deploy -> v785-deploy
+       * [new tag]             v786-deploy -> v786-deploy
+       * [new tag]             v787-deploy -> v787-deploy
+       * [new tag]             v788-deploy -> v788-deploy
+       * [new tag]             v789-deploy -> v789-deploy
+       * [new tag]             v790-deploy -> v790-deploy
+       * [new tag]             v791-deploy -> v791-deploy
+      [git checkout -b feat-branch --track origin/feat-branch]
+      branch 'feat-branch' set up to track 'origin/feat-branch'.
+      Switched to a new branch 'feat-branch'
+
+      # delete all *-deploy tags
+      $ git tag -l | rg -- '-deploy$' | xargs -I{} -- git tag -d {}
+      # the command I use to fetch
+      # perhaps we just need to add --tags into gh too?
+      $ git fetch --all --prune --tags --jobs=10
+      ```
+      </BODY>
+  - name: 'not spam, #10249 (https://github.com/cli/cli/issues/10249)'
+    expected: PASS
+    input: "<TITLE>\ngh repo fork --default-branch-only still includes all branches\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nThe `--default-branch-only` for `gh repo fork` has no effect.\n\n### Steps to reproduce the behavior\n\n1. `gh repo fork kubernetes/website --default-branch-only --fork-name kubernetes-website --clone`\n\n2. But, all branches are included ![Image](https://github.com/user-attachments/assets/64aae8f3-3ce3-466b-af29-9e8e2fbd0e50)\n### Expected vs actual behavior\n\nMy fork of the kubernetes/website repository contains all branches, whereas I expected this \n\n![Image](https://github.com/user-attachments/assets/4e7fbfda-1914-441e-8ba5-e2980c728605)\n\n### Logs\n\nN/A\n\n```bash\ngh version 2.65.0 (2025-01-06)\nhttps://github.com/cli/cli/releases/tag/v2.65.0\n```\n</BODY>"
+  - name: 'not spam, #10242 (https://github.com/cli/cli/issues/10242)'
+    expected: PASS
+    input: "<TITLE>\nCore GitHub CLI update checker disabled due to relocation of package build variable\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nThe core update checking logic has not reported updates to users since [`v2.59.0` release](https://github.com/cli/cli/releases/tag/v2.59.0) because the `updaterEnabled` package variable was relocated.  This package variable is set in [our Homebrew formula](https://github.com/Homebrew/homebrew-core/blob/cb52280c48f1a5aacd6e3a0afa635857846918c4/Formula/g/gh.rb#L34-L40), however the `main` import path no longer applies, requiring setting the new, fully qualified Go package instead:\n\n```ruby\n    with_env(\n      \"GH_VERSION\" => gh_version,\n      \"GO_LDFLAGS\" => \"-s -w -X main.updaterEnabled=cli/cli\",\n    ) do\n      system \"make\", \"bin/gh\", \"manpages\"\n    end\n    bin.install \"bin/gh\"\n```\n\nwhereas now this would be:\n\n```ruby\n    with_env(\n      \"GH_VERSION\" => gh_version,\n      \"GO_LDFLAGS\" => \"-s -w -X github.com/cli/cli/v2/internal/ghcmd.updaterEnabled=cli/cli\",\n    ) do\n      system \"make\", \"bin/gh\", \"manpages\"\n    end\n    bin.install \"bin/gh\"\n```\n\nThe `main` package appears to be special from what I can gather in the [depths of Go `cmd/link` source code](https://github.com/golang/go/blob/bd80d8956f3062d2b2bff2d7da6b879dfa909f12/src/cmd/link/internal/ld/data.go#L1209-L1218), however this behavior isn't well documented.\n\nRelates #9745 \n\n### Steps to reproduce the behavior\n\n1. Clone Homebrew formula repository\n\n   ```shell\n   gh repo clone homebrew/homebrew-core\n   ```\n\n1. Install `2.58.0` version via Homebrew\n\n   ```shell\n   brew remove gh\n   git -C homebrew-core checkout 06ce7bd256e44f9382de1b02e2a12662be994d61\n   brew install ./homebrew-core/Formula/g/gh.rb\n   gh version\n   ```\n\n   confirming:\n\n   ```\n   gh version 2.58.0 (2024-10-01)\n   https://github.com/cli/cli/releases/tag/v2.58.0\n   ```\n\n1. Clean up older state file and run `gh` command to generate update notice\n\n   ```shell\n   rm ~/.local/state/gh/state.yml\n   gh pr list --state all --limit 1000 --repo cli/cli\n   ```\n    \n   confirming:\n    \n   ```\n   A new release of gh is available: 2.58.0 → 2.65.0\n   To upgrade, run: brew upgrade gh\n   https://github.com/cli/cli/releases/tag/v2.65.0\n   ```\n\n1. Install `2.59.0` version via Homebrew\n\n   ```shell\n   brew remove gh\n   git -C homebrew-core checkout 628e97421ed16b9502409891c38175167c066b6a\n   brew install ./homebrew-core/Formula/g/gh.rb\n   gh version\n   ```\n\n   confirming:\n\n   ```\n   gh version 2.59.0 (2024-10-15)\n   https://github.com/cli/cli/releases/tag/v2.59.0\n   ```\n\n1. Clean up older state file and run `gh` command but no update notice\n\n   ```shell\n   rm ~/.local/state/gh/state.yml\n   gh pr list --state all --limit 1000 --repo cli/cli\n   ```\n\n### Expected vs actual behavior\n\n`brew` based builds should notify the user on stderr if a new release is present.\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\n</BODY>"
+  - name: 'not spam, #10235 (https://github.com/cli/cli/issues/10235)'
+    expected: PASS
+    input: "<TITLE>\nExtension update notices should be non-blocking\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nAfter #9934 was merged, @williammartin called out a problem where the logic handling extension updates is blocking, which will cause the user to wait an indeterminate amount of time for `gh` to check if a new version is available: \n\nhttps://github.com/cli/cli/blob/112552fec126813b2d290f034612e0ec6937485f/pkg/cmd/root/extension.go#L53-L70\n\nThis was a mistake on the author's part as the update checking logic should be non-blocking like it is with core `gh` update checking:\n\nhttps://github.com/cli/cli/blob/112552fec126813b2d290f034612e0ec6937485f/internal/ghcmd/cmd.go#L174-L191\n\n### Steps to reproduce the behavior\n\n1. Create simple extension for testing\n\n   ```shell\n   gh ext create gh-sleep\n   cd gh-sleep\n   gh repo create --push --private --source .\n   gh ext install andyfeller/gh-sleep\n   ```\n\n1. Artificially extend extension update check behavior\n\n   ```\n   diff --git a/pkg/cmd/root/extension.go b/pkg/cmd/root/extension.go\n   index 7f2325e1..95d4669d 100644\n   --- a/pkg/cmd/root/extension.go\n   +++ b/pkg/cmd/root/extension.go\n   @@ -32,6 +32,9 @@ func NewCmdExtension(io *iostreams.IOStreams, em extensions.ExtensionManager, ex\n                   // PreRun handles looking up whether extension has a latest version only when the command is ran.\n                   PreRun: func(c *cobra.Command, args []string) {\n                           go func() {\n   +                               fmt.Fprintf(io.ErrOut, \"Artifically delaying update check logic, sleeping for 3 minutes\")\n   +                               time.Sleep(3 * time.Minute)\n   +                               fmt.Fprintf(io.ErrOut, \"Artifically delay up!\")\n                                   releaseInfo, err := checkExtensionReleaseInfo(em, ext)\n                                   if err != nil && hasDebug {\n                                           fmt.Fprintf(io.ErrOut, \"warning: checking for update failed: %v\", err)\n   ```\n\n1. Build and run extension, confirming blocking behavior\n\n   ```shell\n   make\n   time ./bin/gh sleep\n   ```\n  \n   resulting in:\n  \n   ```\n   Artifically delaying update check logic, sleeping for 3 minutes\n   Hello gh-sleep!\n   Artifically delay up!\n   ./bin/gh sleep  0.05s user 0.02s system 0% cpu 3:00.06 total\n   ```\n\n### Expected vs actual behavior\n\nAgain, extension update checking logic should be non-blocking.\n\n### Logs\n\nPaste the activity from your command line. Redact if needed.\n\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\n</BODY>"
+  - name: 'not spam, #10228 (https://github.com/cli/cli/issues/10228)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `GitKind` extensions are not treated as pinned correctly
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      ```
+      ➜ gh ext install --pin 81a4ce86e027f31d306883c25a71b5d05b007e2e andyfeller/gh-sonar
+      ⣷Cloning into '/Users/williammartin/.local/share/gh/extensions/gh-sonar'...
+      ⢿remote: Enumerating objects: 10, done.
+      remote: Counting objects: 100% (10/10), done.
+      remote: Compressing objects: 100% (8/8), done.
+      ⡿remote: Total 10 (delta 1), reused 7 (delta 1), pack-reused 0 (from 0)
+      Receiving objects: 100% (10/10), 6.64 KiB | 6.64 MiB/s, done.
+      Resolving deltas: 100% (1/1), done.
+      ✓ Installed extension andyfeller/gh-sonar
+      ✓ Pinned extension at 81a4ce86e027f31d306883c25a71b5d05b007e2e
+      ```
+
+      This looks like it is pinned correctly. However...running `gh ext list` doesn't show it in blue (indicating pinned), and...
+
+      ```
+      ➜  gh ext upgrade gh-sonar --dry-run
+      [sonar]: would have upgraded from 81a4ce86 to 9977d8e5
+      ✓ Successfully checked extension upgrades
+      ```
+
+      Whereas a pinned extension would say:
+
+      ```
+      ➜  gh ext upgrade gh-sarif --dry-run
+      [sarif]: pinned extensions can not be upgraded
+      ✓ Successfully checked extension upgrades
+      ```
+
+      Separately, upgrading doesn't work at all, but that's another issue (to be created)
+
+      ### Acceptance Criteria
+
+      **Given** I installed a pinned, script-based GitHub CLI extension using `gh ext install --pin SHA`
+      **When** I execute `gh ext upgrade <EXT> --dry-run`
+      **Then** `gh` states `pinned extensions can not be upgraded`
+
+      ---
+
+      **Given** I installed a pinned, script-based GitHub CLI extension using `gh ext install --pin SHA`
+      **When** I execute `gh ext list`
+      **Then** I see the extension sha is coloured cyan
+
+      In the following example, the version for `gh-eco` is colored cyan because it is a pinned extension:
+
+      <img width="520" alt="Screenshot of terminal displaying GitHub CLI extensions with gh-eco version being cyan" src="https://github.com/user-attachments/assets/e6064e6c-e086-4f74-8a60-8cdbf62720d4" />
+      </BODY>
+  - name: 'not spam, #10218 (https://github.com/cli/cli/issues/10218)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Codespace state tracking has a bug which leads to infinite polling
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      There's some faulty logic in `waitUntilCodespaceConnectionReady` where it [initially checks if the codespace is not ready and attempts to start it once if it's not](https://github.com/cli/cli/blob/a6ea8fe4ed22e48227a66ef4843b3be6888e98b1/internal/codespaces/codespaces.go#L70-L76).
+
+      The problem is: if the codespace is currently shutting down, rebuilding, or some other non-shutdown state, this start call will silently no-op and we won't try it again later - so the CLI will just poll until it eventually times out.
+
+      ### Steps to reproduce the behavior
+
+      1. Create a codespace
+      2. `gh cs stop -c <name>`
+      3. Immediately `gh cs ssh -c <name>`
+      4. Observe CLI waits for the codespace to become ready
+      5. `gh cs ls` in another terminal
+      6. Observe that codespace eventually becomes `Shutdown`
+      9. The original `gh cs ssh` is still polling, but does not attempt to start the codespace and the codespace remains `Shutdown`
+
+      ### Expected vs actual behavior
+
+      The state polling should properly handle waiting for the Shutdown state before attempting to restart
+      </BODY>
+  - name: 'not spam, #10200 (https://github.com/cli/cli/issues/10200)'
+    expected: PASS
+    input: "<TITLE>\nAdd support for `gh repo autolink view`\n</TITLE>\n\n<BODY>\nThis issue is to implement the command necessary to view a repository autolinks as discussed within #9420 underneath `gh repo autolink`.\n\nThis should follow similar form as existing GitHub CLI commands as well as necessary tests.\n\n### Acceptance Criteria\n\n> [!NOTE]  \n> Successful commands should return `0` exit code whereas errors should return `1` unless otherwise stated.\n\n**When** I run `gh repo autolink view --help`\n**Then** I see an informative help usage containing descriptive command information:\n\n1. Long description explaining command purpose.\n\n2. Usage: `gh repo autolink view <id> [flags]`\n\n3. Flags:\n```\n     -q, --jq expression     Filter JSON output using a jq expression\n         --json fields       Output JSON with the specified fields\n     -t, --template string   Format JSON output using a Go template; see \"gh help formatting\"\n```\n\n4. Inherited flags:\n```\nINHERITED FLAGS\n         --help                     Show help for command\n     -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format\n```\n \n5. JSON fields:  \n```\n JSON FIELDS\n     id, isAlphanumeric, keyPrefix, urlTemplate\n```\n\n_The web UI does not provide a route representing a single autolink, so we don't provide a `--web` flag here._\n\n---\n\n**Given** I don't have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink view <id>`\n**Then** I see an informative error\n\n```\nerror getting autolink: HTTP 404: Either no autolink with this ID exists for this repository or you are missing admin rights to the repository. (https://api.github.com/repos/{owner}/{repo}/autolinks)\n```\n\n_The REST API provides identical 404 responses for (1) repo doesn't exist, (2) repo exists but autolink doesn't, and (3) both exists but user lacks admin rights._\n\n---\n\n**When** I run `gh repo autolink view` without an argument\n**Then** I see an informative error\n\n```\naccepts 1 arg(s), received 0\n```\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink view <id>` where `<id>` is the ID of an autolink in the repository.\n**Then** I see a message of the following form:\n\n```\nAutolink in <owner>/<repo>\n\nID: <id>\nKey Prefix: <keyPrefix>\nURL Template: <urlTemplate>\nAlphanumeric: <isAlphanumeric>\n```\n\n---\n\n**Given** I have a repository with an autolink\n**When** I run `gh repo autolink view --json`\n**Then** I see a list of repository autolink fields that can be outputted in JSON format:\n\n```\nSpecify one or more comma-separated fields for `--json`:\n  id\n  isAlphanumeric\n  keyPrefix\n  urlTemplate\n```\n\n---\n\n**Given** I have a repository with an autolink\n**When** I run `gh repo autolink view <id> --json <field>[,<field>...]` with one or more relevant fields\n**Then** I see a JSON representation of the autolink only containing the specified fields:\n\n```\n{\n  \"id\": 1,\n  \"isAlphanumeric\": false,\n  \"keyPrefix\": \"DISCORD-\",\n  \"urlTemplate\": \"https://discord.com/channels/<num>\"\n}\n```\n\n---\n\n**Given** I have a repository with an autolink\n**When** I run `gh repo autolink view <id> --json <field>[,<field>...] --jq '...'` with a valid [`jq` filter](https://jqlang.github.io/jq/manual/)\n**Then** I see the JSON result from applying the `jq` filter to the standard `gh repo autolink --json <field>[,<field>...]` result:\n\n```\ngh repo autolink list --json keyPrefix --jq '.keyPrefix'\n```\n\nresulting in:\n\n```\nTICKET-\n```\n\n---\n\n**Given** I have a repository with an autolink\n**When** I run `gh repo autolink view <id> --json <field>[,<field>...] --template '...'` with a Go template\n**Then** I see the formatted JSON result from applying the `template` Go template filter to the standard `gh repo autolink view <id> --json <field>[,<field>...]` result\n</BODY>"
+  - name: 'not spam, #10199 (https://github.com/cli/cli/issues/10199)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      MSI installer support for Windows on ARM
+      </TITLE>
+
+      <BODY>
+      Currently the GitHub releases includes binaries for Windows on ARM. As a zipped artifact. Originally tracked by #2545 / #5715.
+
+      I'm creating this issue to track MSI installer support for the ARM binaries.
+
+      As of January 2025 the artifacts are
+
+      <img width="977" alt="Image" src="https://github.com/user-attachments/assets/d1adb1f9-f583-43bc-b1ca-d7d5fa9c8168" />
+
+      CI refers to a blocking issue with WiX Toolset that now seems to be resolved. Please see https://github.com/wixtoolset/issues/issues/6141
+
+      https://github.com/cli/cli/blob/713346c7369f2e29963d04fd7c71cc1236a56bd9/.github/workflows/deployment.yml#L205-L210
+      </BODY>
+  - name: 'not spam, #10188 (https://github.com/cli/cli/issues/10188)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh pr create` fails in `v2.64.0` if the current branch doesn't have the upstream configured
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      There appears to be a regression in `v2.64.0` where `gh pr create` will now fail to create the PR unless the upstream is available via `git config` (basically requiring the `-u` option of `git push`). The error is `aborted: you must first push the current branch to a remote, or use the --head flag` from [here](https://github.com/cli/cli/blob/106d5d11442660e7aa3c287d8876e452c99447ab/pkg/cmd/pr/create/create.go#L718C32-L718C115).
+
+      Note I've already started a PR to fix this here: https://github.com/cli/cli/pull/10177
+
+      Internal tracking issue: https://github.com/github/cli/issues/730
+
+      ### Steps to reproduce the behavior
+
+      1. `git checkout -B my-branch`
+      2. Make some edit and `git commit` it
+      3. `git push origin my-branch`
+      4. `gh pr create ...`
+
+      ### Expected vs actual behavior
+
+      Up to and including `v2.63.2` these commands succeed. In `v2.64.0` it will fail with the above error.
+      </BODY>
+  - name: 'not spam, #10182 (https://github.com/cli/cli/issues/10182)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      HTTP 422: Validation Failed when uploading GitHub Actions
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      A clear and concise description of what the bug is. Include version by typing `gh --version`.
+
+      Latest version on Arch Linux
+
+      ### Steps to reproduce the behavior
+
+      Use [build.yml](https://github.com/s0urce-c0de/autorecotossd/blob/main/.github/workflows/build.yml) from that repository and see it fail.
+
+      ### Expected vs actual behavior
+
+      Expected: it uploads. Actual
+      ![Image](https://github.com/user-attachments/assets/f2ec2936-0955-49e4-a6dd-fd22b6965c29)
+
+
+      ### Logs
+
+      Paste the activity from your command line. Redact if needed.
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+
+      https://github.com/s0urce-c0de/autorecotossd/actions/runs/12625070135/job/35176193890
+      </BODY>
+  - name: 'not spam, #10155 (https://github.com/cli/cli/issues/10155)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      gh reporting write permission denied, cannot set ignorecase for dir with correct perms
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      gh version 2.64.0 (2024-12-20)
+      Debian 12 in WSL
+
+      gh will not write to a directory I have permissions on (in fact, which has perms 777)
+
+      ### Steps to reproduce the behavior
+
+      git repo clone $repo
+
+      ### Expected vs actual behavior
+
+      expected repo to clone locally
+
+      ### Logs
+
+      ```
+      Cloning into 'z88-flash-mod'...
+      error: could not write config file $HOME/$REPO/.git/config: Permission denied
+      fatal: could not set 'core.ignorecase' to 'true'
+      failed to run git: exit status 128
+
+      ```
+      ls -al $repo reports:
+      ```
+      drwxrwxrwx 1 mark mark 4096 Dec 31 09:48 .
+      drwxrwxrwx 1 mark mark 4096 Dec 31 09:48 ..
+      drwxrwxrwx 1 mark mark 4096 Dec 31 09:48 .git
+      ```
+      </BODY>
+  - name: 'not spam, #10136 (https://github.com/cli/cli/issues/10136)'
+    expected: PASS
+    input: "<TITLE>\nAccount incorrectly reported active in `gh auth status`\n</TITLE>\n\n<BODY>\n### Describe the bug\nRunning `gh auth status` reports account as active, but API calls use another account.\n\n```sh\n> gh --version\ngh version 2.63.0 (1980-01-01)\nhttps://github.com/cli/cli/releases/tag/v2.63.0\n```\n### Steps to reproduce the behavior\n\n1. You have two users on same hostname `github.com`, last active account is  `user1`.\n2. Switch to another folder with custom `GH_CONFIG_DIR` (via direnv), with a custom config which has one user `user2`\n4. Run `gh auth status`\n```sh\n> gh auth status\ngithub.com\n  ✓ Logged in to github.com account user2 (keyring)\n  - Active account: true\n  - Git operations protocol: ssh\n  - Token: gho_************************************\n  - Token scopes: 'gist', 'read:org', 'repo', 'workflow'\n```\n6. Run `gh api /user | jq .name`  => prints `user1`, contradicting `auth status` output \n\nThe expected behavior is to use the token for the given `host+user` of current repository without needing to `gh auth switch`, and report active account correctly.\n\n### Context\n\nActive token is fetched from keyring using only hostname\nhttps://github.com/cli/cli/blob/5402e207ee89f2f3dc52779c3edde632485074cd/internal/config/config.go#L202-L218\n\nRelated to https://github.com/cli/cli/issues/9111#issuecomment-2558645932)\n</BODY>"
+  - name: 'not spam, #10132 (https://github.com/cli/cli/issues/10132)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Disable release discussion posts
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      As discussed [here](https://github.com/cli/cli/discussions/9585#discussioncomment-10631557) and voted on [here](https://github.com/cli/cli/discussions/9690#discussion-7265434), release discussions are not bringing value, and really are just a vehicle for spam that maintainers end up having to keep deleting.
+
+      If people miss them, they can create an issue and we can consider bringing them back.
+
+      ### Expected Output
+
+      The expected output for this work is that:
+       * Future CLI releases do not create discussion posts
+
+      ### Notes
+
+      I believe this comes from here: https://github.com/cli/cli/blob/5402e207ee89f2f3dc52779c3edde632485074cd/.github/workflows/deployment.yml#L355
+      </BODY>
+  - name: 'not spam, #10131 (https://github.com/cli/cli/issues/10131)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      PAT scopes - unclear correspondence between short names and long names
+      </TITLE>
+
+      <BODY>
+      When using PAT to perform `gh auth login`, `gh` says that "The minimum required scopes are 'repo', 'read:org', 'admin:public_key'.". It is not clear which options these short names correspond to in the list of permissions shown when generating a PAT. See attached image.
+
+      Because the correspondence is not clear, it's furthermore not clear how to create a PAT with the minimum scopes - instead, I have to use all scopes.
+
+      ![Image](https://github.com/user-attachments/assets/68e9542e-e368-4a6a-89cc-08654a8d5bbe)
+      </BODY>
+  - name: 'not spam, #10120 (https://github.com/cli/cli/issues/10120)'
+    expected: PASS
+    input: "<TITLE>\nAdd support for `gh repo autolink delete`\n</TITLE>\n\n<BODY>\nThis issue is to implement the command necessary to delete repository autolinks as discussed within #9420 underneath `gh repo autolink`.\n\nThis should follow similar form as existing GitHub CLI commands as well as necessary tests.\n\ncc: @hoffm @nitrocode\n\n### Acceptance Criteria\n\n> [!NOTE]\n> Successful commands should return `0` exit code whereas errors should return `1` unless otherwise stated.\n\n**When** I run `gh repo autolink delete --help`\n**Then** I see an informative help usage containing descriptive command information:\n\n1. Long description explaining command purpose\n1. Usage: `gh repo autolink delete <keyPrefix> [flags]`\n1. Flags:\n\n   ```shell\n   FLAGS\n     --yes   Confirm deletion without prompting\n   ```\n1. Inherited flags:\n\n   ```shell\n   INHERITED FLAGS\n         --help                     Show help for command\n     -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format\n   ```\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink delete <keyPrefix>` in interactive mode\n**Then** I see a prompt asking for confirmation of deleting autolink by typing keyPrefix\n\n```shell\n? Type this-is-provided-keyPrefix to confirm deletion: \n```\n\n**When** I mistype the autolink keyPrefix\n**Then** I see an informative error and prompted to try again to enter the autolink keyPrefix\n\n```shell\nX Sorry, your reply was invalid: You entered lkjalskdjfasdf\n? Type this-is-provided-keyPrefix to confirm deletion: \n```\n\n**When** I correctly type the autolink keyPrefix\n**Then** I see an informational message confirming the repository autolink was deleted\n\n```shell\n✓ Autolink \"<keyPrefix>\" deleted from <owner>/<repo>\n```\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink delete <keyPrefix>` in non-interactive mode\n**Then** I see an informational message stating `--yes` flag is required to delete autolink in non-interactive mode followed by the usage statement\n\n```shell\n--yes required when not running interactively\n\nUsage:  ...\n```\n\n> [!NOTE]\n> For examples, see [`gh label delete` behavior](https://github.com/cli/cli/blob/5402e207ee89f2f3dc52779c3edde632485074cd/pkg/cmd/label/delete.go#L44-L46)\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink delete <keyPrefix>` in interactive mode\n**Then** I see a prompt asking for confirmation of deleting autolink by typing keyPrefix\n\n---\n\n**Given** I don't have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink delete <keyPrefix>`\n**Then** I see an informative error after confirming prompt\n\n```shell\n? Type this-is-provided-keyPrefix to confirm deletion: \nerror deleting autolink: HTTP 404: Must have admin rights to Repository. (https://api.github.com/repos/{owner}/{repo}/autolinks)\n```\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a remote repository with autolinks\n**When** I run `gh repo autolink delete <keyPrefix> --repo <owner>/<repo>` in interactive mode\n**Then** I see a prompt asking for confirmation of deleting autolink by typing keyPrefix as when I have a local repository\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink delete <keyPrefix> --yes`\n**Then** I see an informational message confirming the repository autolink was deleted without prompt asking for confirmation\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink delete <keyPrefix>` with a non-existent keyPrefix\n**Then** I see an informative error after confirming prompt\n\n```shell\n? Type this-is-provided-keyPrefix to confirm deletion: \nHTTP 404: Not Found (https://api.github.com/repos/{owner}/{repo}/autolinks/this-is-provided-keyPrefix)\n```\n</BODY>"
+  - name: 'not spam, #10119 (https://github.com/cli/cli/issues/10119)'
+    expected: PASS
+    input: "<TITLE>\nAdd support for `gh repo autolink create`\n</TITLE>\n\n<BODY>\nThis issue is to implement the command necessary to create repository autolinks as discussed within #9420 underneath `gh repo autolink`.\n\nThis should follow similar form as existing GitHub CLI commands as well as necessary tests.\n\ncc: @hoffm @nitrocode\n\n### Acceptance Criteria\n\n> [!NOTE]\n> Successful commands should return `0` exit code whereas errors should return `1` unless otherwise stated.\n\n**When** I run `gh repo autolink create --help`\n**Then** I see an informative help usage containing descriptive command information:\n\n1. Long description explaining command purpose\n1. Usage: `gh repo autolink create <keyPrefix> <urlTemplate> [flags]`\n1. Aliases: `create` commands typically allow `new` alias\n1. Flags:\n\n   ```shell\n     -n, --numeric                  Mark autolink as non-alphanumeric\n   ```\n1. Inherited flags:\n\n   ```shell\n   INHERITED FLAGS\n         --help                     Show help for command\n     -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format\n   ```\n1. Examples\n\n   ```shell\n   # Create alphanumeric autolink\n   gh repo autolink create \"TICKET-\" \"https://example.com/TICKET?query=<num>\"\n\n   # Create numeric autolink\n   gh repo autolink create \"DISCORD-\" \"https://discord.com/channels/<num>\" --numeric\n   ```\n\n---\n\n**Given** I don't have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink create <keyPrefix> <urlTemplate>`\n**Then** I see an informative error\n\n```shell\nerror creating autolink: HTTP 404: Must have admin rights to Repository. (https://api.github.com/repos/{owner}/{repo}/autolinks)\n```\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink create <keyPrefix> <urlTemplate>`\n**Then** I see an informational message confirming the repository autolink was created\n\n```shell\n✓ Autolink \"<keyPrefix>\" created in <owner>/<repo>\n```\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a remote repository\n**When** I run `gh repo autolink create <keyPrefix> <urlTemplate> --repo <owner>/<repo>`\n**Then** I see an informational message confirming the repository autolink was created the same as when I have a local repository\n\n---\n\n**Given** I have the `admin` role on the repository\n**And Given** I have a local repository cloned from GitHub\n**When** I run `gh repo autolink create <keyPrefix> <urlTemplate>`\n**And When** `<urlTemplate>` does not contain literal `<num>`\n**Then** I see an informative error explaining `<urlTemplate>` must contain `<num>` \n</BODY>"
+  - name: 'not spam, #10118 (https://github.com/cli/cli/issues/10118)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Add support for `gh repo autolink list`
+      </TITLE>
+
+      <BODY>
+      This issue is to implement the command necessary to list repository autolinks as discussed within #9420 underneath `gh repo autolink`.
+
+      This should follow similar form as existing GitHub CLI commands as well as necessary tests.
+
+      cc: @hoffm @nitrocode
+
+      ### Acceptance Criteria
+
+      > [!NOTE]
+      > Successful commands should return `0` exit code whereas errors should return `1` unless otherwise stated.
+
+      **When** I run `gh repo autolink list --help`
+      **Then** I see an informative help usage containing descriptive command information:
+
+      1. Long description explaining command purpose
+      1. Usage: `gh repo autolink list [flags]`
+      1. Aliases: `list` commands typically allow `ls` alias
+      1. Flags:
+
+         ```shell
+           -q, --jq expression     Filter JSON output using a jq expression
+               --json fields       Output JSON with the specified fields
+           -t, --template string   Format JSON output using a Go template; see "gh help formatting"
+           -w, --web               List autolinks in the web browser
+         ```
+      1. Inherited flags:
+
+         ```shell
+         INHERITED FLAGS
+               --help                     Show help for command
+           -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format
+         ```
+      1. JSON fields:
+
+         ```shell
+         JSON FIELDS
+           id, isAlphanumeric, keyPrefix, urlTemplate
+         ```
+
+      ---
+
+      **Given** I don't have the `admin` role on the repository
+      **And Given** I have a local repository cloned from GitHub
+      **When** I run `gh repo autolink list`
+      **Then** I see an informative error
+
+      ```shell
+      error getting autolinks: HTTP 404: Must have admin rights to Repository. (https://api.github.com/repos/{owner}/{repo}/autolinks)
+      ```
+
+      ---
+
+      **Given** I have the `admin` role on the repository
+      **And Given** I have a local repository cloned from GitHub
+      **When** I run `gh repo autolink list`
+      **Then** I see a message and table of repository autolinks including:
+
+      1. Message about autolinks found
+
+         - If autolinks are not found:
+
+           ```
+           no autolinks found
+           ```
+
+         - If autolinks are found:
+
+           ```
+           Showing X autolinks in <owner>/<repo>
+           ```
+
+           _REST API for retrieving autolinks does not support pagination_
+
+      1. Table containing information if autolinks are found containing:
+
+         - `ID`
+         - `Key Prefix`
+         - `URL Template`
+         - `Alphanumeric`: either `true` or `false`
+
+      ---
+
+      **Given** I have the `admin` role on the repository
+      **And Given** I have a local repository cloned from GitHub
+      **And Given** There are no autolinks on the repository
+      **When** I run `gh repo autolink list` non-interactively
+      **Then** No message is displayed
+
+      > [!NOTE]
+      > For examples, see [`gh variable list` behavior](https://github.com/cli/cli/blob/5402e207ee89f2f3dc52779c3edde632485074cd/pkg/cmd/variable/list/list.go#L135-L137) using `cmdutil.NewNoResultsError()`
+
+      ---
+
+      **Given** I have the `admin` role on the repository
+      **And Given** I have a remote repository with autolinks
+      **When** I run `gh repo autolink list --repo <owner>/<repo>`
+      **Then** I see a table of repository autolinks the same as when I have a local repository
+
+      ---
+
+      **Given** I have the `admin` role on the repository
+      **And Given** I have a remote repository with autolinks
+      **When** I run `GH_REPO=<owner>/<repo> gh repo autolink list`
+      **Then** I see a table of repository autolinks the same as when I have a local repository
+
+      ---
+
+      **Given** I have a repository with autolinks
+      **When** I run `gh repo autolink list --json`
+      **Then** I see a list of repository autolink fields that can be outputted in JSON format:
+
+      ```shell
+      Specify one or more comma-separated fields for `--json`:
+        id
+        isAlphanumeric
+        keyPrefix
+        urlTemplate
+      ```
+
+      ---
+
+      **Given** I have a repository with autolinks
+      **When** I run `gh repo autolink list --json <field>[,<field>...]` with one or more relevant fields
+      **Then** I see a JSON list of repository autolinks only containing the specified fields:
+
+      ```json
+      [
+        {
+          "id": 1,
+          "isAlphanumeric": false,
+          "keyPrefix": "DISCORD-",
+          "urlTemplate": "https://discord.com/channels/<num>",
+        },
+        {
+          "id": 2,
+          "isAlphanumeric": true
+          "keyPrefix": "TICKET-",
+          "urlTemplate": "https://example.com/TICKET?query=<num>",
+        }
+      ]
+      ```
+
+      ---
+
+      **Given** I have a repository with autolinks
+      **When** I run `gh repo autolink list --json <field>[,<field>...] --jq '...'` with a valid [`jq` filter](https://jqlang.github.io/jq/manual/)
+      **Then** I see the JSON result from applying the `jq` filter to the standard `gh repo autolink --json <field>[,<field>...]` result:
+
+      ```shell
+      gh repo autolink list --json id,is_alphanumeric,--jq '[ .[] | select(.is_alphanumeric == true) ]'
+      ```
+
+      resulting in:
+
+      ```json
+      [
+        {
+          "id": 2,
+          "isAlphanumeric": true
+          "keyPrefix": "TICKET-",
+          "urlTemplate": "https://example.com/TICKET?query=<num>",
+        }
+      ]
+      ```
+
+      ---
+
+      **Given** I have a repository with autolinks
+      **When** I run `gh repo autolink list --json <field>[,<field>...] --template '...'` with a Go template
+      **Then** I see the formatted JSON result from applying the `template` Go template filter to the standard `gh repo autolink --json <field>[,<field>...]` result
+
+      ---
+
+      **Given** I have the `admin` role on the repository
+      **And Given** I have a local repository cloned from GitHub
+      **When** I run `gh repo autolink list --web`
+      **Then** I have a web browser opened to Autolinks references section of the repository settings page
+
+      ![Screenshot of `cli/cli` autolink references settings page](https://github.com/user-attachments/assets/f9cf0f6b-10b9-4f73-83e2-20e6b41fa5dd)
+      </BODY>
+  - name: 'not spam, #10114 (https://github.com/cli/cli/issues/10114)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      gh attestation verify JSON output includes incorrectly-formatted in-toto attestation
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      The output of `gh attestation verify` with the `--format json` flag produces a result structure with an incorrectly-formatted in-toto attestation.
+
+      For example, the field `predicateType` is called `predicate_type` in the output, which isn't correct [according to the spec.](https://github.com/in-toto/attestation/blob/main/spec/v1/predicate.md)
+
+      This can be observed using this command:
+
+      ```shell
+      gh attestation verify oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies:v0.6.2 --owner github --format json --jq .[0].verificationResult.statement
+      ```
+
+      gh version:
+
+      ```
+       ▶ gh --version
+      gh version 2.59.0 (2024-10-15)
+      https://github.com/cli/cli/releases/tag/v2.59.0
+      ```
+
+      The root cause is a problem with JSON encoding described in this issue: https://github.com/in-toto/attestation/issues/363
+
+      Related issue in sigstore-go: https://github.com/sigstore/sigstore-go/issues/365
+
+      This should be fixed by https://github.com/sigstore/sigstore-go/pull/366. After it is merged, a release will be cut, and `gh` may update to that version of sigstore-go.
+
+      ### Steps to reproduce the behavior
+
+      1. Type this '...'
+      2. View the output '....'
+      3. See error
+
+      ### Expected vs actual behavior
+
+      A clear and concise description of what you expected to happen and what actually happened.
+
+      ### Logs
+
+      Paste the activity from your command line. Redact if needed.
+
+      <!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->
+      </BODY>
+  - name: 'not spam, #10109 (https://github.com/cli/cli/issues/10109)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Document the Base Repo resolution functions
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      I've been looking at the way commands resolve the repo that they choose to issue API requests against and there's quite a lot to it, and some interesting edge cases. It seems worth a comment in the code to explain the behaviour of these things.
+
+      ### Expected Output
+
+      The expected output for this issue is:
+       * The base repo resolution functions are commented
+      </BODY>
+  - name: 'not spam, #10103 (https://github.com/cli/cli/issues/10103)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `remoteResolver` does not cache remotes
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      While I was reading the [code](https://github.com/cli/cli/blob/5402e207ee89f2f3dc52779c3edde632485074cd/pkg/cmd/factory/remote_resolver.go) for the `remoteResolver`, which is intended to call `git` to get the list of `remotes`, and then do some filtering and sorting, I noticed this line:
+
+      https://github.com/cli/cli/blob/5402e207ee89f2f3dc52779c3edde632485074cd/pkg/cmd/factory/remote_resolver.go#L72
+
+      I don't believe this works as intended, because the walrus operator results in `cachedRemotes` being shadowed since it is in an inner scope. See https://go.dev/play/p/YIENXfxFfbP for an example of shadowing.
+
+      I do believe on first read that errors are cached correctly:
+
+      https://github.com/cli/cli/blob/5402e207ee89f2f3dc52779c3edde632485074cd/pkg/cmd/factory/remote_resolver.go#L41
+
+      I also believe the code before this was caching correctly:
+
+      https://github.com/cli/cli/pull/1517/files#diff-cd947847f830f7a9e26366e15f74794df6937388a36f41146a1ba7d987d0efd7L96
+
+      ---
+
+      Here's a minimal test to demonstrate that the cache branch isn't being hit in the happy path. If made into a real test, it should probably check that the correct remotes are returned as well.
+
+      ```go
+      func TestRemoteResolverCachesRemotes(t *testing.T) {
+      	var readRemotesCalled bool
+
+      	rr := &remoteResolver{
+      		readRemotes: func() (git.RemoteSet, error) {
+      			if readRemotesCalled {
+      				return git.RemoteSet{}, errors.New("readRemotes should only be called once")
+      			}
+
+      			readRemotesCalled = true
+      			return git.RemoteSet{
+      				git.NewRemote("origin", "https://github.com/owner/repo.git"),
+      			}, nil
+      		},
+      		getConfig: func() (gh.Config, error) {
+      			cfg := &ghmock.ConfigMock{}
+      			cfg.AuthenticationFunc = func() gh.AuthConfig {
+      				authCfg := &config.AuthConfig{}
+      				authCfg.SetHosts([]string{"github.com"})
+      				authCfg.SetDefaultHost("github.com", "default")
+      				return authCfg
+      			}
+      			return cfg, nil
+      		},
+      		urlTranslator: identityTranslator{},
+      	}
+
+      	resolver := rr.Resolver()
+      	_, err := resolver()
+      	require.NoError(t, err)
+      	_, err = resolver()
+      	require.NoError(t, err)
+      }
+      ```
+
+      ### Expected Output
+
+      The expected output for this issue is that:
+       * A comment is left confirming or refuting my statements above
+       * A comment that indicates the author has confirmed that caching is in fact **safe** (this code has been this way for 4 years)
+       * The code is fixed, if necessary
+       * There are tests
+      </BODY>
+  - name: 'not spam, #10091 (https://github.com/cli/cli/issues/10091)'
+    expected: PASS
+    input: "<TITLE>\nAllow setting security_and_analysis settings in gh repo edit\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\n[`gh repo edit`](https://cli.github.com/manual/gh_repo_edit) allows setting most properties of [`octokit.rest.repos.update`](https://octokit.github.io/rest.js/v21/#repos-update). But, it doesn't seem to have an option for `security_and_analysis` properties that I can find.\r\n\r\nFrom the docs and the OpenAPI types, that's:\r\n\r\n* `advanced_security`\r\n* `secret_scanning`\r\n* `secret_scanning_push_protection`\r\n\r\n### Proposed solution\r\n\r\nCould we be able to set those properties in `gh repo edit` too, please? I.e.:\r\n\r\n```shell\r\ngh repo edit --enable-advanced-security true --enable-secret-scanning true --enable-secret-scanning-push-protection true\r\n```\r\n\r\n### Additional context\r\n\r\nIs there precedent for what does or doesn't get implemented in `gh repo edit`? And if so, is that influenced at all by which settings are within nested objects like `security_and_analysis`?\r\n\r\nSibling issue to: #10092\n</BODY>"
+  - name: 'not spam, #10089 (https://github.com/cli/cli/issues/10089)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `issue develop --base` should result in `pr create` using that branch as the base later
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      This is split off from https://github.com/cli/cli/issues/8979 to indicate a slice of already delivered work.
+
+      The motivation for this work is that typically, when running `issue develop --base`, we are working against a long lived branch that isn't the default branch of the repo. When work is complete, we want it to be delivered back into this base branch.
+
+      ### Acceptance Criteria
+
+      **Given** I have begun developing an issue with `gh issue develop --base long-lived`
+      **When** I run `gh pr create`
+      **Then** the PR should be created with `long-lived` as the base
+      </BODY>
+  - name: 'not spam, #10088 (https://github.com/cli/cli/issues/10088)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `pr create` should use `gh-merge-base` git branch config when determining base branch
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      This work is split off from https://github.com/cli/cli/issues/8979 in order to track already delivered work.
+
+      The motivation for this work is to provide a better experience for working against long lived branches. Currently, when running `gh pr create`, one must remember to provide the `--base` flag. It is preferable to have some persistent configuration that can be set when the branch is created, that `pr create` can use.
+
+      ### Acceptance Criteria
+
+      **Given** I have branch `feature` checked out
+      **And Given** that branch has a git config `gh-merge-base = long-lived`
+      **When** I run `gh pr create`
+      **Then** the base branch for the PR is `long-lived`
+      </BODY>
+  - name: 'not spam, #10084 (https://github.com/cli/cli/issues/10084)'
+    expected: PASS
+    input: "<TITLE>\nNewly created Go extensions using standard workflow template fail due to older `cli/gh-extension-precompile` action and Android builds\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nWith the `v2` major release of `cli/gh-extension-precompile` addressing build issues with more recent Go releases on Android in https://github.com/cli/gh-extension-precompile/pull/56, the release workflow templates used by `gh ext create` should be updated as the `v1` version causes Go extensions to break.\n\n```shell\n$ gh --version\ngh version 2.62.0 (2024-11-14)\nhttps://github.com/cli/cli/releases/tag/v2.62.0\n```\n\nhttps://github.com/cli/cli/blob/a50fc7079e574a68284e19ea7eaee2f8303e79f0/pkg/cmd/extension/ext_tmpls/goBinWorkflow.yml#L11-L19\n\nhttps://github.com/cli/cli/blob/a50fc7079e574a68284e19ea7eaee2f8303e79f0/pkg/cmd/extension/ext_tmpls/otherBinWorkflow.yml#L9-L16\n\n### Steps to reproduce the behavior\n\n1. Create standard Go extension\n\n   ```shell\n   gh ext create --precompiled=go foobar\n   ```\n\n1. Create repository based on local repository\n\n   ```shell\n   cd gh-foobar\n   gh repo create gh-acceptance-testing/gh-foorbar --private --push --source .\n   ```\n\n1. Create release\n\n   ```shell\n   gh release create v0.0.1 --title v0.0.1 --generate-notes\n   ```\n\n1. Confirm release workflow fails due to Android CGO\n\n   ```shell\n   gh run view \"$(gh run list --json databaseId --jq '.[0].databaseId')\" --log-failed\n   ```\n\n   resulting in:\n    \n   ```shell\n   android/amd64 requires external (cgo) linking, but cgo is not enabled\n   Error: Process completed with exit code 1.\n   ```\n    \n### Expected vs actual behavior\n\nI expect newly created extensions to be releasable from an unmodified standard release workflow with current Go releases.\n</BODY>"
+  - name: 'not spam, #10079 (https://github.com/cli/cli/issues/10079)'
+    expected: PASS
+    input: "<TITLE>\nWhen `gh repo fork` results in a newly created fork, there is no output to non-TTY terminal\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nWhile writing a GitHub workflow that forks a repo I found that `gh repo fork` only outputs success text if the fork previously existed, not when the fork is newly created. **This issue only appears if running the command from a non-TTY terminal.**\r\n\r\n<details>\r\n<summary>GitHub Workflow Step</summary>\r\n\r\nWhat I currently have to do to get the forked repo name:\r\n\r\n```yaml\r\n- name: Create Fork\r\n  # no-op if the repository is already forked\r\n  shell: bash\r\n  # since this runs from a non-TTY shell, `gh repo fork` doesn't output anything if the\r\n  # fork is newly created, but outputs \"owner/repo already exists\" for existing forks\r\n  run: |\r\n    FORK=$(gh repo fork --clone=false --remote=false --default-branch-only 2>&1)\r\n    if [ -z \"${FORK}\" ]; then\r\n      sleep 60  # it takes a minute before a newly created repo is considered \"existing\"\r\n      FORK=$(gh repo fork --clone=false --remote=false --default-branch-only 2>&1)\r\n    fi\r\n    echo FORK=$(echo \"${FORK}\" | grep -o '[^ ]*/[^ ]*' | head -n1 \\) >> $GITHUB_ENV\r\n  env:\r\n    GH_TOKEN: ${{ inputs.fork-token }}\r\n```\r\n\r\nWhat I'd like to do instead:\r\n\r\n```yaml\r\n- name: Create Fork\r\n  # no-op if the repository is already forked\r\n  shell: bash\r\n  run: echo FORK=$(\r\n    gh repo fork --clone=false --remote=false --default-branch-only |\r\n    grep -o '[^ ]*/[^ ]*' |\r\n    head -n1) >> $GITHUB_ENV\r\n  env:\r\n    GH_TOKEN: ${{ inputs.fork-token }}\r\n```\r\n\r\n</details>\r\n\r\n\r\n\r\n```bash\r\n$ gh --version\r\ngh version 2.63.2 (2024-12-05)\r\nhttps://github.com/cli/cli/releases/tag/v2.63.2\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\nCall this from a repo that has not been forked before:\r\n\r\n```bash\r\n$ bash <<HERE\r\ngh repo fork --clone=false --default-branch-only --remote=false\r\nHERE\r\n# <-- no output\r\n```\r\n\r\nCalling this a second time (after ~60 seconds):\r\n\r\n```bash\r\n$ bash <<HERE\r\ngh repo fork --clone=false --default-branch-only --remote=false\r\nHERE\r\nkenodegard/releases already exists  # <-- exists output\r\n```\r\n\r\nScreenshot:\r\n\r\n<img width=\"512\" alt=\"Screenshot 2024-12-13 at 09 54 11\" src=\"https://github.com/user-attachments/assets/9079bdec-90e3-4849-87db-280d90c33b60\" />\r\n\r\n### Expected vs actual behavior\r\n\r\nI would expect the command to output the fork name in either scenarios whether or not an interactive terminal (TTY vs non-TTY).\r\n\r\nLooking at the source code this is where the issue lies:\r\n\r\nhttps://github.com/cli/cli/blob/c789b56da44a52429feccc98606f03c61a967667/pkg/cmd/repo/fork/fork.go#L212-L225\r\n\r\nAs I understand this, we would want the following:\r\n\r\n```go\r\nif createdAgo > time.Minute {\r\n\tif connectedToTerminal {\r\n\t\tfmt.Fprintf(stderr, \"%s %s %s\\n\",\r\n\t\t\tcs.Yellow(\"!\"),\r\n\t\t\tcs.Bold(ghrepo.FullName(forkedRepo)),\r\n\t\t\t\"already exists\")\r\n\t} else {\r\n\t\tfmt.Fprintf(stderr, \"%s already exists\\n\", ghrepo.FullName(forkedRepo))\r\n\t}\r\n} else {\r\n\tif connectedToTerminal {\r\n\t\tfmt.Fprintf(stderr, \"%s Created fork %s\\n\",\r\n\t\t\tcs.SuccessIconWithColor(cs.Green),\r\n\t\t\tcs.Bold(ghrepo.FullName(forkedRepo)))\r\n\t} else {\r\n\t\tfmt.Fprintf(stderr, \"Created fork %s\\n\", ghrepo.FullName(forkedRepo))\r\n\t}\r\n}\r\n```\r\n\r\n### Logs\r\n\r\nn/a\n</BODY>"
+  - name: 'not spam, #10077 (https://github.com/cli/cli/issues/10077)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh pr view` cannot find PR from branch when fork is in the same org as upstream
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When there is a PR from a fork in the same org as the upstream, `pr view` will fail to find it, when determining the PR via the branch.
+
+      Testscript to demonstrate the issue. Note that we have to use `gh api` to create the PR because `pr create` cannot handle fork in the same org as the upstream for different reasons.
+
+      ```
+      # Setup environment variables used for testscript
+      env REPO=${SCRIPT_NAME}-${RANDOM_STRING}
+      env FORK=${REPO}-fork
+
+      # Use gh as a credential helper
+      exec gh auth setup-git
+
+      # Create a repository to act as upstream with a file so it has a default branch
+      exec gh repo create ${ORG}/${REPO} --add-readme --private
+
+      # Defer repo cleanup of upstream
+      defer gh repo delete --yes ${ORG}/${REPO}
+      exec gh repo view ${ORG}/${REPO} --json id --jq '.id'
+      stdout2env REPO_ID
+
+      # Create a fork in the same org
+      exec gh repo fork ${ORG}/${REPO} --org ${ORG} --fork-name ${FORK}
+
+      # Defer repo cleanup of fork
+      defer gh repo delete --yes ${ORG}/${FORK}
+      sleep 1
+      exec gh repo view ${ORG}/${FORK} --json id --jq '.id'
+      stdout2env FORK_ID
+
+      # Clone the fork
+      exec gh repo clone ${ORG}/${FORK}
+      cd ${FORK}
+
+      # Prepare a branch
+      exec git checkout -b feature-branch
+      exec git commit --allow-empty -m 'Empty Commit'
+      exec git push -u origin feature-branch
+
+      # Create the PR spanning upstream and fork repositories, gh pr create does not support headRepositoryId needed for private forks
+      exec gh api graphql -F repositoryId="${REPO_ID}" -F headRepositoryId="${FORK_ID}" -F query='mutation CreatePullRequest($headRepositoryId: ID!, $repositoryId: ID!) { createPullRequest(input:{ baseRefName: "main", body: "Feature Body", draft: false, headRefName: "feature-branch", headRepositoryId: $headRepositoryId, repositoryId: $repositoryId, title:"Feature Title" }){ pullRequest{ id url } } }'
+
+      # View the PR
+      exec gh pr view
+      stdout 'Feature Title'
+      ```
+
+      ### Implementation Details
+
+      When using the PR Finder, `gh` will resolve the current branch name from `git`. It then uses the git remote for that branch, and determines whether it should be prepended with `<owner>:`
+
+      https://github.com/cli/cli/blob/c35d725b0b89ef090aab17171d091f4630eed5ca/pkg/cmd/pr/shared/finder.go#L268-L270
+
+      Later, it does another string concatenation based on whether a fetched PR `isCrossRepository`, inside the `pr.HeadLabel()` method, which is then compared to the aforementioned branch:
+
+      https://github.com/cli/cli/blob/c35d725b0b89ef090aab17171d091f4630eed5ca/pkg/cmd/pr/shared/finder.go#L358
+
+      However, the original decision to prepend with owner only makes sense if the fork is in a different org.
+
+      ### Acceptance Criteria
+
+      **Given** I have a PR between a fork and upstream in the same org
+      **And Given** I have the fork PR branch checked out locally
+      **When** I run `gh pr view`
+      **Then** I should see the PR
+      </BODY>
+  - name: 'not spam, #10076 (https://github.com/cli/cli/issues/10076)'
+    expected: PASS
+    input: "<TITLE>\n`gh run list` does not work with organization ruleset required workflows\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nSimilar bug mentioned https://github.com/cli/cli/issues/3437, but gh run view or list all return a 404. The URL returned seems right based on REST api docs but not getting any response. When comparing the ID `gh run list` doesn't seem to be correct based on the ids from `gh workflow list`\r\n\r\n**gh cli version:** `gh version 2.63.2 (2024-12-05)`\r\n**ghe version:** `3.13.4`\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Complete login to the enterprise server with Github CLI\r\n2. Go to a repository directory that uses that server as a remote\r\n3. Run gh run list returns 404\r\n\r\n### Expected vs actual behavior\r\n\r\nThe gh run list prints out list of workflow runs for the repo to choose from\r\n\r\n### Logs\r\n\r\n```bash\r\n[git remote -v]\r\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\r\n* Request at 2024-12-13 00:23:19.723417 -0600 CST m=+0.101249251\r\n* Request to https://{SERVER_URL}/api/graphql\r\n* Request took 281.385ms\r\n⣾* Request at 2024-12-13 00:23:20.040818 -0600 CST m=+0.418510918\r\n* Request to https://{SERVER_URL}/api/v3/repos/{ORG}/{REPO}/actions/runs?per_page=20&exclude_pull_requests=true\r\n⢿* Request took 421.362291ms\r\n⡿* Request at 2024-12-13 00:23:20.534045 -0600 CST m=+0.911535293\r\n* Request to https://{SERVER_URL}/api/v3/repos/{ORG}/{REPO}/actions/workflows?per_page=100&page=1\r\n⣟* Request took 105.218541ms\r\n* Request at 2024-12-13 00:23:20.700194 -0600 CST m=+1.077616418\r\n* Request to https://{SERVER_URL}/api/v3/repos/{ORG}/{REPO}/actions/workflows/63737\r\n⣯* Request took 121.476458ms\r\nfailed to get runs: HTTP 404: Not Found (https://{SERVER_URL}/api/v3/repos/{ORG}/{REPO}/actions/workflows/63737)\r\n```\r\n</BODY>"
+  - name: 'not spam, #10075 (https://github.com/cli/cli/issues/10075)'
+    expected: PASS
+    input: "<TITLE>\nRHEL 9 installation update\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nsteps to install on RHEL9 \r\n\r\n### Steps to reproduce the behavior\r\n\r\n\r\n### Expected vs actual behavior\r\n\r\n```\r\nsudo dnf install dnf-plugins-core.noarch\r\nsudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo\r\nsudo dnf install gh --repo gh-cli\r\n```\n</BODY>"
+  - name: 'not spam, #10073 (https://github.com/cli/cli/issues/10073)'
+    expected: PASS
+    input: "<TITLE>\n`gh gist delete` does not prompt for a gist to delete or prompt for confirmation before deletion\n</TITLE>\n\n<BODY>\n### Describe the bug\n\n- `gh gist delete` doesn't prompt for a gist to delete. This seems like it might be an oversight when compared to the behavior of other `gh gist` and `gh <some-command> delete` operations.\n- `gh gist delete` should prompt for a gist to delete and confirm the selection to delete.\n- `gh gist delete` also does not currently support `--yes` for non-interactive confirmation - perhaps it should? \n\n### Steps to reproduce the behavior\n\n```\ngh gist delete\n```\n### Expected vs actual behavior\n\n**Expected**\n\n```\n❯ gh gist delete\n? Select a gist to delete [Use arrows to move, type to filter]\n> test.md test gist about 4 days ago\n  draft.md  about 2 months ago\n? Are you sure you want to delete gist test.md (Y/n)\n```\n\n**Actual**\n```\ngh gist delete\n❯ gh gist delete\ncannot delete: gist argument required\n\nUsage:  gh gist delete {<id> | <url>} [flags]\n```\n\n### Notes\n\nDiscovered in #10042 \n</BODY>"
+  - name: 'not spam, #10065 (https://github.com/cli/cli/issues/10065)'
+    expected: PASS
+    input: "<TITLE>\nUbuntu cannot retrieve the file `https://cli.github.com/packages/githubcli-archive-keyring.gpg` if it is preferencing IPV6\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nTry and retrieve `https://cli.github.com/packages/githubcli-archive-keyring.gpg` using wget on a system that preferences IPV6, in my case `Pop!_OS 22.04 LTS` based off Ubuntu Jammy.\r\n\r\n\r\n### Steps to reproduce the behavior\r\n\r\n```bash\r\nwget https://cli.github.com/packages/githubcli-archive-keyring.gpg\r\n```\r\nThis will hang.\r\n\r\n\r\n### Expected vs actual behavior\r\n\r\nExpected: Retrieve the keyring\r\nActual: Nothing\r\n### Logs\r\n\r\nPaste the activity from your command line. Redact if needed.\r\n\r\n```bash\r\n wget https://cli.github.com/packages/githubcli-archive-keyring.gpg\r\n--2024-12-11 13:30:54--  https://cli.github.com/packages/githubcli-archive-keyring.gpg\r\nResolving cli.github.com (cli.github.com)... 2606:50c0:8003::153, 2606:50c0:8000::153, 2606:50c0:8002::153, ...\r\nConnecting to cli.github.com (cli.github.com)|2606:50c0:8003::153|:443...\r\n```\r\n</BODY>"
+  - name: 'not spam, #10064 (https://github.com/cli/cli/issues/10064)'
+    expected: PASS
+    input: "<TITLE>\ngh list run does not support the 'Pending' status\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nThe `gh list run -R <owner>/<repo> --status=pending` is not supported. It is by the corresponding API query (`gh api /repos/<owner>/<repo>/actions/runs?status=pending`, though. Shouldn't this status filtering also be available in the `gh list run` command?\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Type `gh list run -R <owner>/<repo> --status=pending`\r\n2. Command fails with 'invalid argument \"pending\" for \"-s, --status\" flag: valid values are {queued|completed|in_progress|requested|waiting|action_required|cancelled|failure|neutral|skipped|stale|startup_failure|success|timed_out}'\r\n\r\n### Expected vs actual behavior\r\n\r\nExpected that the command should be able to list only workflows in the 'Pending' status (in addition to the other statuses).\n</BODY>"
+  - name: 'not spam, #10062 (https://github.com/cli/cli/issues/10062)'
+    expected: PASS
+    input: "<TITLE>\n`gh pr reopen` is not working\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nA clear and concise description of what the bug is. Include version by typing `gh --version`.\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Type this 'gh pr reopen {pr_number}'\r\n2. View the output 'API call failed: GraphQL: Could not open the pull request. (reopenPullRequest)'\r\n3. See error : - `API call failed: GraphQL: Could not open the pull request. (reopenPullRequest)`\r\n\r\n### Expected vs actual behavior\r\n\r\n>A clear and concise description of what you expected to happen and what actually happened.\r\n- i want to reopen a closed pr by this command `gh pr reopen {pr_number}`\r\n\r\n### Logs\r\n\r\n>Paste the activity from your command line. Redact if needed.\r\n\r\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\r\n</BODY>"
+  - name: 'not spam, #10059 (https://github.com/cli/cli/issues/10059)'
+    expected: PASS
+    input: "<TITLE>\nVerifying attestations offline using --bundle fails\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nVerifying attestations offline using `--bundle` fail verification using the GitHub CLI.\r\n\r\n```\r\ngh version 2.60.1 (2024-10-25)\r\nhttps://github.com/cli/cli/releases/tag/v2.60.1\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. In a workflow use the `attest-build-provenance` action to attest binary\r\n2. Save the `attestation.jsonl` bundle file generated from the `attest-build-provenance` action\r\n3. Download the trusted roots using the command `gh attestation trusted-root > trusted_root.jsonl` and save the file\r\n4. Download said binary produced from workflow\r\n5. Run GitHub CLI command below to verify attestations offline\r\n\r\n#### GH_DEBUG=false\r\n```\r\ngh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME --bundle attestation.jsonl --custom-trusted-root trusted_root.jsonl\r\nLoaded digest sha256:XYZ for file://ARTIFACT-BINARY\r\nLoaded 16 attestations from attestation.jsonl\r\n✗ Verification failed\r\n\r\nError: verifying with issuer \"GitHub, Inc.\"\r\n```\r\n\r\n#### GH_DEBUG=true\r\n```\r\nGH_DEBUG=true gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME --bundle attestation.jsonl --custom-trusted-root trusted_root.jsonl\r\nLoaded digest sha256:XYZ for file://ARTIFACT-BINARY\r\nLoaded 16 attestations from attestation.jsonl\r\nVerifying attestation 1/16 against the configured Sigstore trust roots\r\nAttempting verification against issuer \"GitHub, Inc.\"\r\nSUCCESS - attestation signature verified with \"GitHub, Inc.\"\r\n\r\nVerifying attestation 2/16 against the configured Sigstore trust roots\r\nAttempting verification against issuer \"GitHub, Inc.\"\r\nFailed to verify against issuer \"GitHub, Inc.\"\r\n\r\n✗ Verification failed\r\n\r\nError: verifying with issuer \"GitHub, Inc.\"\r\n```\r\n\r\n### Expected vs actual behavior\r\n\r\n#### Expected\r\nWhen running the command with `GH_DEBUG=true` you can see in the output that the actual verification was successful for the `<file-path>` parameter that was passed by the command, i.e. -> `PATH/TO/YOUR/BUILD/ARTIFACT-BINARY`. However the verification fails as the GitHub CLI is looping the bundle files and trying to validate all of them when only a single files is specified on the command. This would make sense if the GitHub CLI allowed a glob pattern to be passed to verify multiple binary artifacts given the bundle but I do not think this is supported.\r\n\r\n#### Actual\r\nVerification fails with error `Error: verifying with issuer \"GitHub, Inc.\"`\r\n\r\n#### Observations\r\nIt seems the CLI command `gh at verify` should support a glob pattern to verify multiple files when using the `--bundle` parameter or only try to verify the single file that was passed in the `<file-path>` parameter.\r\n</BODY>"
+  - name: 'not spam, #10058 (https://github.com/cli/cli/issues/10058)'
+    expected: PASS
+    input: "<TITLE>\ngh login does not change config when switching from github.com to github enterprise\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n\r\nAfter using `gh login` between github.com and then github enterprise, the gh config still holds reference to github.com.\r\n\r\n⚠️ `gh config clear-cache` does not work.\r\n✅  `rm -rf ~/.config/gh` does allow this flow to work.\r\n\r\n#### versions\r\ngh version 2.52.0 (2024-06-24)\r\nhttps://github.com/cli/cli/releases/tag/v2.52.0\r\n\r\ngh version 2.63.2 (2024-12-05)\r\nhttps://github.com/cli/cli/releases/tag/v2.63.2\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. `gh auth login` ( > choose github.com > go through the ssh auth flow in the browser > title for ssh key: <default GitHub CLI>)\r\n2. `gh status` (should show github.com PRs and references)\r\n3. `gh auth login` (> choose github enterprise or your own domain, go through ssh auth flow in the browser > title for ssh key: <default GitHub CLI>)\r\n4. `gh status` (this still shows references to github.com, not github.<enterprisedomain>.com)\r\n\r\n### Expected vs actual behavior\r\n\r\nEvery time `gh login` is used to switch between github and github enterprise, then `gh status` should show the correct references to the current auth'd login\r\n\r\n### Logs\r\n\r\nPaste the activity from your command line. Redact if needed.\r\n\r\n```\r\n~/company/ops develop\r\nops-GbyGZ3Xx-py3.12 ❯ gh auth login\r\n? Where do you use GitHub? Other\r\n? Hostname: github.company.com\r\n? What is your preferred protocol for Git operations on this host? SSH\r\n? Upload your SSH public key to your GitHub account? /Users/me/.ssh/mykey.pub\r\n? Title for your SSH key: GitHub CLI\r\n? How would you like to authenticate GitHub CLI? Login with a web browser\r\n\r\n* Request at 2024-12-10 10:15:07.178167 -0600 CST m=+10.469423584\r\n* Request to https://github.company.com/login/device/code\r\n* Request took 146.468709ms\r\n! First copy your one-time code: 95F5-A7A1\r\nPress Enter to open https://github.company.com/login/device in your browser...\r\n* Request at 2024-12-10 10:15:14.928528 -0600 CST m=+18.219902918\r\n* Request to https://github.company.com/login/oauth/access_token\r\n* Request took 64.418625ms\r\n* Request at 2024-12-10 10:15:15.001704 -0600 CST m=+18.293080043\r\n* Request to https://github.company.com/api/graphql\r\n* Request took 65.449041ms\r\n✓ Authentication complete.\r\n- gh config set -h github.company.com git_protocol ssh\r\n✓ Configured git protocol\r\n* Request at 2024-12-10 10:15:15.271046 -0600 CST m=+18.562426334\r\n* Request to https://github.company.com/api/v3/user/keys?per_page=100\r\n* Request took 43.423375ms\r\n✓ SSH key already existed on your GitHub account: /Users/me/.ssh/mykey.pub\r\n✓ Logged in as me-company\r\n! You were already logged in to this account\r\n\r\n~/company/ops develop 19s\r\nops-GbyGZ3Xx-py3.12 ❯ gh status\r\n⣾* Request at 2024-12-10 10:15:21.227174 -0600 CST m=+0.049918459\r\n* Request at 2024-12-10 10:15:21.227577 -0600 CST m=+0.050321376\r\n* Request to https://api.github.com/graphql     #### NOTE: github.com not github.company.com\r\n* Request to https://api.github.com/graphql\r\n* Request at 2024-12-10 10:15:21.227619 -0600 CST m=+0.050363501\r\n* Request to https://api.github.com/notifications?all=true&participating=true&per_page=100\r\n* Request took 1.03025ms\r\n* Request at 2024-12-10 10:15:21.228275 -0600 CST m=+0.051019084\r\n* Request to https://api.github.com/users/me-company/received_events?per_page=100\r\n⣽* Request took 189.093417ms\r\n⣻* Request took 311.053417ms\r\n⢿* Request took 1.41835925s\r\nAssigned Issues                           │ Assigned Pull Requests\r\nNothing here ^_^                          │ non-enterprise-repo#14879   ticket-423...\r\n                                          │ non-enterprise-repo#14789  Bump strip...\r\n                                            non-enterprise-repo#14825  implementi...\r\n                                            non-enterprise-repo#14839  Release 20...\r\n                                            non-enterprise-repo#14407  script to ...\r\n\r\nReview Requests                           │ Mentions\r\nnon-enterprise-repo#14803  Bump depen...│ Nothing here ^_^\r\nnon-enterprise-repo#14789  Bump strip...│\r\nnon-enterprise-repo#14832  Remove `an...│\r\nnon-enterprise-repo#14286  Update mig...│\r\n                                          │\r\nRepository Activity\r\nNothing here ^_^\r\n\r\n\r\n~/company/ops develop\r\nops-GbyGZ3Xx-py3.12 ❯\r\n\r\n```\r\n</BODY>"
+  - name: 'not spam, #10052 (https://github.com/cli/cli/issues/10052)'
+    expected: PASS
+    input: "<TITLE>\nunknown command `set default` for `gh repo`\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nA clear and concise description of what the bug is. Include version by typing `gh --version`.\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Type this `gh repo set-default`\r\n2. View the output \r\n```\r\nunknown command \"set-default\" for \"gh repo\"\r\n\r\nUsage:  gh repo <command> [flags]\r\n\r\nAvailable commands:\r\n  archive\r\n  clone\r\n  create\r\n  delete\r\n  edit\r\n  fork\r\n  list\r\n  rename\r\n  sync\r\n  view\r\n  ```\r\n3. See error\r\n\r\n### Expected vs actual behavior\r\n\r\nExpected to load the given repository, but giving an error\r\n\r\nVersion- `gh version 2.4.0+dfsg1 (2022-03-23 Ubuntu 2.4.0+dfsg1-2)`\r\nOS- WSL2 on windows 11\r\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\r\n</BODY>"
+  - name: 'not spam, #10047 (https://github.com/cli/cli/issues/10047)'
+    expected: PASS
+    input: "<TITLE>\nDifferences in response for `gh attestation verify` between CLI and CI/GH Actions ?\n</TITLE>\n\n<BODY>\n_Okay, so I'm not sure whether it is me doing something wrong or if this is an issue with the GH CLI tooling, but figured it would be worth finding out via an issue._\r\n\r\n\r\n### Describe the feature or problem you’d like to solve\r\n\r\nWhen running `gh attestation verify` via a local command line, I see a response along the lines of\r\n```\r\n$ gh attestation verify ./phpcs.phar -o PHPCSStandards\r\nLoaded digest sha256:cd9efa1a815148918be948ae1113f0a84dd484a1a39c2f5533929af83da9fdb1 for file://phpcs.phar\r\nLoaded 1 attestation from GitHub API\r\n✓ Verification succeeded!\r\n\r\nsha256:cd9efa1a815148918be948ae1113f0a84dd484a1a39c2f5533929af83da9fdb1 was attested by:\r\nREPO                            PREDICATE_TYPE                  WORKFLOW\r\nPHPCSStandards/PHP_CodeSniffer  https://slsa.dev/provenance/v1  .github/workflows/test.yml@refs/tags/3.11.1\r\n```\r\n\r\nHowever, when I run the same command from within a GH Actions workflow, I see no output whatsoever when the attestation succeeds.\r\n\r\n```\r\nRun gh attestation verify phpcs.phar -o PHPCSStandards\r\n  gh attestation verify phpcs.phar -o PHPCSStandards\r\n  shell: /usr/bin/bash -e {0}\r\n  env:\r\n    GH_TOKEN: ***\r\n```\r\n\r\nExample:\r\n* Workflow: https://github.com/PHPCSStandards/PHP_CodeSniffer/blob/7b274761885e85f44232e7f3d72a576cfa1122a4/.github/workflows/verify-release.yml#L88-L91\r\n* Logs: https://github.com/PHPCSStandards/PHP_CodeSniffer/actions/runs/12224958207/job/34098361462#step:10:1\r\n\r\n\r\nThe problem with this is that, without output, it makes it really hard to verify whether the workflow is working correctly.\r\n\r\n\r\n### Proposed solution\r\n\r\nDo not differentiate between environments when determining whether or not to display output.\r\n\r\nOr if this is behaviour which was requested by others for some reason, add a `-q` (quiet) option to opt-in to the \"silence output\" behaviour instead of defaulting to not displaying output.\r\n\r\n\r\n### Additional info\r\n\r\nI looked through the `-h` help output to see if there was maybe a `verbose` option of something which I could turn on, but I couldn't find anything, so I'm not sure what I can do to change this counter-intuitive behaviour.\r\n\r\n</BODY>"
+  - name: 'not spam, #10042 (https://github.com/cli/cli/issues/10042)'
+    expected: PASS
+    input: "<TITLE>\n`gh gist view` and `gh gist edit` prompts with no TTY\n</TITLE>\n\n<BODY>\n### Describe the bug\n\n`gh gist view` and `gh gist edit` attempt to prompt when no TTY is available, but it should not.\n\nIt should behave more like `gh run view`, for example:\n\n<details><summary>Example `gh run view` behavior with no TTY</summary>\n<p>\n\n```\n❯ gh run view | cat  \nrun or job ID required when not running interactively\n\nUsage:  gh run view [<run-id>] [flags]\n\nFlags:\n  -a, --attempt uint      The attempt number of the workflow run\n      --exit-status       Exit with non-zero status if run failed\n  -j, --job string        View a specific job ID from a run\n  -q, --jq expression     Filter JSON output using a jq expression\n      --json fields       Output JSON with the specified fields\n      --log               View full log for either a run or specific job\n      --log-failed        View the log for any failed steps in a run or specific job\n  -t, --template string   Format JSON output using a Go template; see \"gh help formatting\"\n  -v, --verbose           Show job steps\n  -w, --web               Open run in the browser\n  \n```\n\n</p>\n</details> \n\n### Steps to reproduce the behavior\n\n`gh gist view | cat`\n\n### Expected vs actual behavior\n\nExpected: `gh gist view` and `gh gist edit` should return an error & \"help\" output if no TTY is available when it would otherwise prompt.\nActual: `gh gist view` and `gh gist edit` attempts to prompt the user\n\n### Logs\n\n```\n❯ gh gist view | cat\n? Select a gist  [Use arrows to move, type to filter]\n> test.md test gist about 19 hours ago\n  draft.md  about 2 months ago\n```\n</BODY>"
+  - name: 'not spam, #10038 (https://github.com/cli/cli/issues/10038)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh run` and `gh codespace` subcommands should list branches in square brackets
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      For example, `gh run view` lists branches in parenthesis, but I think it should list them in square brackets to align with [Primer guidelines](https://primer.style/native/cli/components#branches):
+
+      > Display branch names in brackets and/or cyan
+
+
+      ### Steps to reproduce the behavior
+
+      `gh run view`
+
+      ### Expected vs actual behavior
+
+      `gh run` and `gh codespace` subcommands with prompts should display branches within square brackets.
+
+      ### Logs
+
+      ```
+      ❯ gh run view
+      ? Select a workflow run  [Use arrows to move, type to filter]
+      > - Verifying attestations offline fails, Discussion Triage (trunk) 4h55m1s ago
+        - Decoding, Discussion Triage (patch-1) 4h59m32s ago
+        ✓ Decoding, PR Automation (patch-1) 4h59m43s ago
+        ✓ Issue Automation, Issue Automation (trunk) 5h20m31s ago
+        - `gh repo rename myorg/newname` results in `myorg/myorg-newname`, Discussion Triage (trunk) 10h13m50s ago
+        - 401 Error at every turn, Discussion Triage (trunk) 10h15m20s ago
+        - 401 Error at every turn, Discussion Triage (trunk) 10h15m20s ago
+      ```
+      </BODY>
+  - name: 'not spam, #10034 (https://github.com/cli/cli/issues/10034)'
+    expected: PASS
+    input: "<TITLE>\n`gh repo rename myorg/newname` results in `myorg/myorg-newname`\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\ngh version 2.63.0 (2024-11-27)\r\nhttps://github.com/cli/cli/releases/tag/v2.63.0\r\n\r\nI renamed my repo using `gh repo rename polyseam/frappe-containers`, this resulted in the preview being correct:\r\n```\r\n? Rename polyseam/containers to polyseam/frappe-containers? Yes\r\n```\r\nbut the result being wrong:\r\n```\r\n✓ Renamed repository polyseam/polyseam-frappe-containers\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. `gh repo create org/foo-repo --private --clone`\r\n2. cd `foo-repo`\r\n3. `gh repo rename org/bar-repo`\r\n4. note the confirm prompt is correct\r\n5. enter `Yes`\r\n6. note the incorrect result: \"✓ Renamed repository org/org-bar-repo\"\r\n\r\n### Expected vs actual behavior\r\n\r\nThe resulting repo name should not be prefixed with `orgname-` and should instead match the preview in step 4.\r\n\r\n### Logs\r\n\r\nPaste the activity from your command line. Redact if needed.\r\n\r\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\r\n</BODY>"
+  - name: 'not spam, #10029 (https://github.com/cli/cli/issues/10029)'
+    expected: PASS
+    input: "<TITLE>\ngh attestation download on windows os writes a alternative data stream file\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n`gh attestation download` command on windows os creates an alternative data stream file.\r\n\r\n```bash\r\ngh version 2.60.1 (2024-10-25)\r\nhttps://github.com/cli/cli/releases/tag/v2.60.1\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Attest a file in your repo\r\n2. run `gh atestation download MY_FILE --repo myorg/myrepo`\r\n3. See the below output\r\n4. A file named `sha256` is saved to disk with hidden alternative data stream data (ADS)\r\n\r\n```\r\nFetching attestations for artifact digest sha256:XYZ\r\nWrote attestations to file sha256:XYZ.jsonl.\r\nAny previous content has been overwritten\r\nThe trusted metadata is now available at sha256:XYZ.jsonl\r\n```\r\n\r\n### Expected vs actual behavior\r\n\r\n#### Expected\r\nI would expect to see a `.jsonl` file written to the file system on a windows os.\r\n\r\n#### Actual\r\nAn NTFS Alternate Data Stream file is written to the file system on windows os because of the `:` in the file name.\r\n\r\n### Logs\r\n\r\n#### GitHub CLI\r\n```\r\n$ GH_DEBUG=true gh attestation download MY_FILE --repo myorg/myrepo\r\nDownloading trusted metadata for artifact MY_FILE\r\n\r\nFetching attestations for artifact digest sha256:XYZ\r\n\r\n* Request at 2024-12-06 10:47:31.0459537 -0800 PST m=+0.098551801\r\n* Request to https://api.github.com/repos/myorg/myrepo/attestations/sha256:XYZ?per_page=30\r\n* Request took 446.9907ms\r\nWrote attestations to file sha256:XYZ.jsonl.\r\nAny previous content has been overwritten\r\n\r\nThe trusted metadata is now available at sha256:XYZ.jsonl\r\n```\r\n\r\n#### Powershell Examine ADS data\r\n```pwsh\r\nPS C:\\> Get-Item sha256 -stream *\r\n\r\nPSPath        : Microsoft.PowerShell.Core\\FileSystem::C:\\sha256::$DATA\r\nPSParentPath  : Microsoft.PowerShell.Core\\FileSystem::C:\\\r\nPSChildName   : sha256::$DATA\r\nPSDrive       : C\r\nPSProvider    : Microsoft.PowerShell.Core\\FileSystem\r\nPSIsContainer : False\r\nFileName      : C:\\sha256\r\nStream        : :$DATA\r\nLength        : 0\r\n\r\nPSPath        : Microsoft.PowerShell.Core\\FileSystem::C:\\sha256:XYZ.jsonl\r\nPSParentPath  : Microsoft.PowerShell.Core\\FileSystem::C:\\\r\nPSChildName   : sha256:XYZ.jsonl\r\nPSDrive       : C\r\nPSProvider    : Microsoft.PowerShell.Core\\FileSystem\r\nPSIsContainer : False\r\nFileName      : C:\\sha256\r\nStream        : XYZ.jsonl\r\nLength        : 5309\r\n```\r\n</BODY>"
+  - name: 'not spam, #10017 (https://github.com/cli/cli/issues/10017)'
+    expected: PASS
+    input: "<TITLE>\nv2.63.0 seems to have broken `attestation verify` `--bundle-from-oci` flag\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n\U0001F44B I suspect that https://github.com/cli/cli/pull/9892 or https://github.com/cli/cli/pull/9937 (leaning towards the former) has broken the `gh attestation verify` command when used with the `--bundle-from-oci` flag. This is not fixed in `v2.63.1`.\r\n\r\n### Steps to reproduce the behavior\r\n\r\nThis matrix job checks the same behavior with various versions. Full workflow is here: https://github.com/falcorocks/lab/blob/artifact-attestation-example/.github/workflows/github-artifact-attestation.yaml. Example run: [here](https://github.com/falcorocks/lab/actions/runs/12183077649/job/33983649115). You can see that the command works for `v2.62.0` but not for `v2.63.0` or `v2.63.1`\r\n\r\n```yaml\r\n  verify:\r\n    needs: attest\r\n    strategy:\r\n      matrix:\r\n        version: [2.62.0, 2.63.0, 2.63.1]\r\n    runs-on: ubuntu-24.04\r\n    steps:\r\n    - run: wget https://github.com/cli/cli/releases/download/v${{ matrix.version }}/gh_${{ matrix.version }}_linux_amd64.tar.gz\r\n    - run: tar -xvzf gh_${{ matrix.version }}_linux_amd64.tar.gz\r\n    - run: sudo mv gh_*/bin/gh /usr/local/bin/\r\n    - run: gh --version\r\n    - run: gh attestation verify --bundle-from-oci --owner falcorocks oci://${{ env.REGISTRY }}/${{ env.IMAGE }}:${{ env.TAG }}\r\n      env:\r\n        GH_TOKEN: ${{ github.token }}\r\n```\r\n\r\n### Expected vs actual behavior\r\n\r\nv2.62.0 is the correct behaviour: the bundle is discovered and verified\r\n\r\n### Logs\r\n\r\nshould not be necessary but happy to add them if necessary \U0001F4AA \r\n\r\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\r\n</BODY>"
+  - name: 'not spam, #10013 (https://github.com/cli/cli/issues/10013)'
+    expected: PASS
+    input: "<TITLE>\nRespect `--watch` when given `--json` in `gh pr checks`\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nCurrently, `gh pr checks 42 --repo foo/bar --required --watch --json name,status` exits immediately even if there are pending required checks.\r\n\r\n### Steps to reproduce the behavior\r\n\r\nNot available.\r\n\r\n### Expected vs actual behavior\r\n\r\nIt should either raise an exception that `--watch` cannot be combined with `--json` or preferably support the combination.\r\n\r\n### Logs\r\n\r\nNot available.\n</BODY>"
+  - name: 'not spam, #10005 (https://github.com/cli/cli/issues/10005)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Fix flaky run download test
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      https://github.com/cli/cli/commit/1136764c369aaf0cae4ec2ee09dc35d871076932 introduced a test utility for `run download` tests. It is flaky because it relies on [map](https://github.com/cli/cli/commit/1136764c369aaf0cae4ec2ee09dc35d871076932#diff-a7d7e24630ffb9a8d416a1523599965291932189d4d17c9db7d96ee633670951R154) ordering being consistent.
+
+      ```
+      ➜  go test -count=1 ./pkg/cmd/run/download/...
+
+      --- FAIL: Test_runDownload (0.05s)
+
+              mock.go:227:
+                      Error Trace:    /Users/williammartin/go/pkg/mod/github.com/cli/go-gh/v2@v2.11.1/pkg/prompter/mock.go:227
+                                                              /Users/williammartin/go/pkg/mod/github.com/cli/go-gh/v2@v2.11.1/pkg/prompter/mock.go:122
+                                                              /Users/williammartin/workspace/cli/pkg/cmd/run/download/download.go:139
+                                                              /Users/williammartin/workspace/cli/pkg/cmd/run/download/download_test.go:686
+                      Error:          Not equal:
+                                      expected: []string{"artifact-1", "artifact-2"}
+                                      actual  : []string{"artifact-2", "artifact-1"}
+
+                                      Diff:
+                                      --- Expected
+                                      +++ Actual
+                                      @@ -1,4 +1,4 @@
+                                       ([]string) (len=2) {
+                                      - (string) (len=10) "artifact-1",
+                                      - (string) (len=10) "artifact-2"
+                                      + (string) (len=10) "artifact-2",
+                                      + (string) (len=10) "artifact-1"
+
+                      Test:           Test_runDownload/prompt_to_select_artifact
+      FAIL
+      FAIL    github.com/cli/cli/v2/pkg/cmd/run/download      0.336s
+      FAIL
+      ```
+
+      Evidence: https://github.com/cli/cli/actions/runs/12158754328/job/33907377186#step:5:224
+
+      ### Expected Output
+
+      The test is not flaky.
+      </BODY>
+  - name: 'not spam, #10000 (https://github.com/cli/cli/issues/10000)'
+    expected: PASS
+    input: "<TITLE>\n`--allow-forking=false` not interpreted correctly if forking disabled at organization level\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n```\r\ngh version 2.62.0 (2024-11-14)\r\nhttps://github.com/cli/cli/releases/tag/v2.62.0\r\n```\r\n\r\nI have a pipeline that migrates repositories from Azure DevOps to GitHub. One of the steps includes setting some of the repository's settings, such as whether to allow squash merges, and whether to allow forking of the repository.\r\n\r\n(I'm assuming) At our organization level forking is disabled, since if I want to enable it using `gh repo edit --alow-forking` I get this error message:\r\n\r\n```\r\ngh repo edit --allow-forking\r\nHTTP 422: This organization does not allow private repository forking (https://api.github.com/repos/<my-org>/<my-repo>)\r\n```\r\n\r\nwhich is perfectly fine. However, even if I specify false, I also get this error:\r\n\r\n```\r\ngh repo edit --allow-forking=false\r\nHTTP 422: This organization does not allow private repository forking (https://api.github.com/repos/<my-org>/<my-repo>)\r\n```\r\n\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Create a repository in an organization where forking is not allowed\r\n2. Try to run `gh repo edit --allow-forking`. Fails as expected\r\n3. Try to run `gh repo edit --allow-forking=false`. Fails unexpectedly.\r\n\r\n### Expected vs actual behavior\r\n\r\nI would expect that, although forking is disabled at the organization level, setting `--allow-forking=false` shouldn't make the command fail (especially if used in conjunction with other settings, which also don't get applied).\r\n\r\n### Logs\r\n\r\n```\r\ngh repo edit --allow-forking=false\r\n\r\n[git remote -v]\r\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\r\n* Request at 2024-12-03 22:58:28.332895136 +0000 GMT m=+0.042281372\r\n* Request to https://api.github.com/graphql\r\n> POST /graphql HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\r\n> Authorization: token xxx\r\n> Content-Length: 413\r\n> Content-Type: application/json; charset=utf-8\r\n> Graphql-Features: merge_queue\r\n> Time-Zone: Europe/London\r\n> User-Agent: GitHub CLI 2.62.0\r\n\r\nGraphQL query:\r\nfragment repo on Repository {\r\n    id\r\n    name\r\n    owner { login }\r\n    viewerPermission\r\n    defaultBranchRef {\r\n      name\r\n    }\r\n    isPrivate\r\n  }\r\n  query RepositoryNetwork {\r\n    viewer { login }\r\n\r\n    repo_000: repository(owner: \"<my-org>\", name: \"<my-repo>\") {\r\n      ...repo\r\n      parent {\r\n        ...repo\r\n      }\r\n    }\r\n\r\n  }\r\nGraphQL variables: null\r\n\r\n< HTTP/2.0 200 OK\r\n< Access-Control-Allow-Origin: *\r\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\r\n< Content-Security-Policy: default-src 'none'\r\n< Content-Type: application/json; charset=utf-8\r\n< Date: Tue, 03 Dec 2024 22:58:30 GMT\r\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\r\n< Server: github.com\r\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\r\n< Vary: Accept-Encoding, Accept, X-Requested-With\r\n< X-Accepted-Oauth-Scopes: repo\r\n< X-Content-Type-Options: nosniff\r\n< X-Frame-Options: deny\r\n< X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json\r\n< X-Github-Request-Id: xxx\r\n< X-Oauth-Client-Id: xxx\r\n< X-Oauth-Scopes: gist, read:org, repo, workflow\r\n< X-Ratelimit-Limit: 5000\r\n< X-Ratelimit-Remaining: 4962\r\n< X-Ratelimit-Reset: 1733268982\r\n< X-Ratelimit-Resource: graphql\r\n< X-Ratelimit-Used: 38\r\n< X-Xss-Protection: 0\r\n\r\n{\r\n  \"data\": {\r\n    \"viewer\": {\r\n      \"login\": \"celloza\"\r\n    },\r\n    \"repo_000\": {\r\n      \"id\": \"xxx\",\r\n      \"name\": \"<my-repo>\",\r\n      \"owner\": {\r\n        \"login\": \"<my-org>\"\r\n      },\r\n      \"viewerPermission\": \"ADMIN\",\r\n      \"defaultBranchRef\": {\r\n        \"name\": \"develop\"\r\n      },\r\n      \"isPrivate\": true,\r\n      \"parent\": null\r\n    }\r\n  }\r\n}\r\n\r\n* Request took 441.821494ms\r\n* Request at 2024-12-03 22:58:28.775718889 +0000 GMT m=+0.485105152\r\n* Request to https://api.github.com/repos/<my-org>/<my-repo>\r\n> PATCH /repos/<my-org>/<my-repo> HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\r\n> Authorization: token xxx\r\n> Content-Length: 24\r\n> Content-Type: application/json; charset=utf-8\r\n> Time-Zone: Europe/London\r\n> User-Agent: GitHub CLI 2.62.0\r\n\r\n{\r\n  \"allow_forking\": false\r\n}\r\n\r\n< HTTP/2.0 422 Unprocessable Entity\r\n< Access-Control-Allow-Origin: *\r\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\r\n< Content-Length: 171\r\n< Content-Security-Policy: default-src 'none'\r\n< Content-Type: application/json; charset=utf-8\r\n< Date: Tue, 03 Dec 2024 22:58:30 GMT\r\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\r\n< Server: github.com\r\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\r\n< Vary: Accept-Encoding, Accept, X-Requested-With\r\n< X-Accepted-Oauth-Scopes:\r\n< X-Content-Type-Options: nosniff\r\n< X-Frame-Options: deny\r\n< X-Github-Api-Version-Selected: 2022-11-28\r\n< X-Github-Media-Type: github.v3; param=merge-info-preview.nebula-preview; format=json\r\n< X-Github-Request-Id: xxx\r\n< X-Oauth-Client-Id: xxx\r\n< X-Oauth-Scopes: gist, read:org, repo, workflow\r\n< X-Ratelimit-Limit: 5000\r\n< X-Ratelimit-Remaining: 4976\r\n< X-Ratelimit-Reset: 1733268876\r\n< X-Ratelimit-Resource: core\r\n< X-Ratelimit-Used: 24\r\n< X-Xss-Protection: 0\r\n\r\n{\r\n  \"message\": \"This organization does not allow private repository forking\",\r\n  \"documentation_url\": \"https://docs.github.com/rest/repos/repos#update-a-repository\",\r\n  \"status\": \"422\"\r\n}\r\n\r\n* Request took 224.970533ms\r\nHTTP 422: This organization does not allow private repository forking (https://api.github.com/repos/<my-org>/<my-repo>)\r\n```\r\n</BODY>"
+  - name: 'not spam, #9990 (https://github.com/cli/cli/issues/9990)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `pr checkout` panics when targeting a PR in a repo not in remotes
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      A feature I had no idea about is that you can checkout PRs from repositories that are not in your list of git remotes e.g.
+
+      ```
+      gh pr checkout <PR_URL_ON_A_FORK>
+      ```
+
+      With recent [changes](https://github.com/cli/cli/blob/5a74934d192ddce979ca64377be6e10af8680467/pkg/cmd/pr/checkout/checkout.go#L136) that went in to tighten up credential patterns used for git credential helpers, there is a panic when there is no remote matching the base repo used for the PR.
+
+      This was really a bit of an oversight because there is an obvious case when the `baseRemote` is `nil`: https://github.com/cli/cli/blob/5a74934d192ddce979ca64377be6e10af8680467/pkg/cmd/pr/checkout/checkout.go#L93-L97
+
+      There are probably other [cases](https://github.com/cli/cli/issues/9988) where this is an issue too, but I don't have a clear mental model of them yet. I suspect this probably fixes most of them though.
+
+      ### Steps to reproduce the behavior
+
+      The following Acceptance Test demonstrates this behaviour:
+
+      ```
+      # Set up env vars
+      env REPO=${SCRIPT_NAME}-${RANDOM_STRING}
+
+      # Use gh as a credential helper
+      exec gh auth setup-git
+
+      # Create a repository with a file so it has a default branch
+      exec gh repo create ${ORG}/${REPO} --add-readme --private
+
+      # Defer upstream cleanup
+      defer gh repo delete --yes ${ORG}/${REPO}
+
+      # Create a fork
+      exec gh repo fork ${ORG}/${REPO} --org ${ORG} --fork-name ${REPO}-fork
+
+      # Defer fork cleanup
+      defer gh repo delete --yes ${ORG}/${REPO}-fork
+
+      # Clone both repos
+      exec gh repo clone ${ORG}/${REPO}
+      exec gh repo clone ${ORG}/${REPO}-fork
+
+      # Prepare a branch to PR in the fork itself
+      cd ${REPO}-fork
+      exec git checkout -b feature-branch
+      exec git commit --allow-empty -m 'Empty Commit'
+      exec git push -u origin feature-branch
+
+      # Create the PR inside the fork
+      exec gh repo set-default ${ORG}/${REPO}-fork
+      exec gh pr create --title 'Feature Title' --body 'Feature Body'
+      stdout2env PR_URL
+
+      # Checkout the PR by full URL in the upstream repo
+      cd ${WORK}/${REPO}
+      exec gh pr checkout ${PR_URL}
+      stderr 'Switched to branch ''feature-branch'''
+      ```
+
+      And fails on the checkout with:
+
+      ```
+      ...
+       > exec gh pr checkout ${PR_URL}
+              [stderr]
+              panic: runtime error: invalid memory address or nil pointer dereference
+              [signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x10125637c]
+
+              goroutine 1 gp=0x140000021c0 m=10 mp=0x14000500808 [running]:
+              panic({0x101ff91c0?, 0x102c5e010?})
+                      /opt/homebrew/Cellar/go/1.23.1/libexec/src/runtime/panic.go:804 +0x154 fp=0x14000937480 sp=0x140009373d0 pc=0x10046f5a4
+              runtime.panicmem(...)
+                      /opt/homebrew/Cellar/go/1.23.1/libexec/src/runtime/panic.go:262
+              runtime.sigpanic()
+                      /opt/homebrew/Cellar/go/1.23.1/libexec/src/runtime/signal_unix.go:900 +0x300 fp=0x140009374e0 sp=0x14000937480 pc=0x100471aa0
+              github.com/cli/cli/v2/pkg/cmd/pr/checkout.checkoutRun(0x140005e9810)
+                      /Users/williammartin/workspace/cli/pkg/cmd/pr/checkout/checkout.go:136 +0x65c fp=0x14000937690 sp=0x140009374f0 pc=0x10125637c
+              github.com/cli/cli/v2/pkg/cmd/pr/checkout.NewCmdCheckout.func1(0x140005bd508?, {0x140009880b0, 0x1, 0x101344044?})
+                      /Users/williammartin/workspace/cli/pkg/cmd/pr/checkout/checkout.go:61 +0x27c fp=0x140009376f0 sp=0x14000937690 pc=0x101255b2c
+              github.com/spf13/cobra.(*Command).execute(0x140005bd508, {0x14000988090, 0x1, 0x1})
+      ```
+
+      ### Acceptance Criteria
+
+      **Given** I have a PR where the base is a fork
+      **And Given** my cwd is a clone of the upstream repo
+      **When** I run `gh pr checkout <PR_URL_ON_FORK>`
+      **Then** It succeeds
+      </BODY>
+  - name: 'not spam, #9989 (https://github.com/cli/cli/issues/9989)'
+    expected: PASS
+    input: "<TITLE>\nrun cannot be rerun; its workflow file may be broken\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nWe have [a workflow](https://github.com/brave/brave-core/blob/89750d5fa13b40f52f71173bc0d246ab00a3b0c9/.github/workflows/rerun-compare-chromium-versions.yml) that's meant to trigger reruns of [another workflow](https://github.com/brave/brave-core/blob/89750d5fa13b40f52f71173bc0d246ab00a3b0c9/.github/workflows/compare-chromium-versions.yml).\r\n\r\nIn the most recent [run](https://github.com/brave/brave-core/actions/runs/12119360613/job/33785767099), we hit the following failure:\r\n```\r\nRerunning 11620789306 for https://github.com/brave/brave-core/pull/26329\r\nrun 11620789306 cannot be rerun; its workflow file may be broken\r\nError: Process completed with exit code 1.\r\n```\r\n\r\nThe workflow file [appears to be fine](https://github.com/brave/brave-core/blob/kuchikiki-0.8.6/.github/workflows/compare-chromium-versions.yml). The workflow [ran successfully 2 months ago](https://github.com/brave/brave-core/actions/runs/11620789306?pr=26329), but can no longer be rerun automatically, or manually (there's no button to rerun in the web UI).\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Try to rerun workflow run 11620789306\r\n\r\n### Expected vs actual behavior\r\n\r\nSuccessful execution vs failed execution\r\n\r\n### Logs\r\n\r\nSee: above\n</BODY>"
+  - name: 'not spam, #9988 (https://github.com/cli/cli/issues/9988)'
+    expected: PASS
+    input: "<TITLE>\nPanic when checking out a PR with gh 2.63.0\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nPanic when checking out a PR.\r\n\r\n```plain\r\n$ gh --version\r\ngh version 2.63.0 (2024-11-28)\r\nhttps://github.com/cli/cli/releases/tag/v2.63.0\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Execute `gh pr checkout 12`\r\n2. See error\r\n\r\n### Expected vs actual behavior\r\n\r\nExpected the PR to be checkout. Instead, `gh` panicked due to an invalid memory address or nil pointer dereference.\r\n\r\n### Logs\r\n\r\n```\r\n$ GH_DEBUG=true gh pr checkout 12\r\n[git remote -v]\r\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\r\n* Request at 2024-12-02 11:45:38.358245568 -0300 -03 m=+0.056264973\r\n* Request to https://api.github.com/graphql\r\n* Request took 448.848156ms\r\n⣾* Request at 2024-12-02 11:45:38.821097725 -0300 -03 m=+0.519117214\r\n* Request to https://api.github.com/graphql\r\n⣻* Request took 315.197572ms\r\n[git remote -v]\r\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\r\n[git symbolic-ref --quiet HEAD]\r\n[git config branch.not-so-empty-cashflow-trial.merge]\r\npanic: runtime error: invalid memory address or nil pointer dereference\r\n[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x5eeab356860b]\r\n\r\ngoroutine 1 [running]:\r\ngithub.com/cli/cli/v2/pkg/cmd/pr/checkout.checkoutRun(0xc0006c93b0)\r\n\tgithub.com/cli/cli/v2/pkg/cmd/pr/checkout/checkout.go:136 +0x76b\r\ngithub.com/cli/cli/v2/pkg/cmd/pr/checkout.NewCmdCheckout.func1(0xc00055d208?, {0xc0008d0ce0, 0x1, 0x5eeab365d9a4?})\r\n\tgithub.com/cli/cli/v2/pkg/cmd/pr/checkout/checkout.go:61 +0x274\r\ngithub.com/spf13/cobra.(*Command).execute(0xc00055d208, {0xc0008d0cc0, 0x1, 0x1})\r\n\tgithub.com/spf13/cobra@v1.8.1/command.go:985 +0xaaa\r\ngithub.com/spf13/cobra.(*Command).ExecuteC(0xc00067a608)\r\n\tgithub.com/spf13/cobra@v1.8.1/command.go:1117 +0x3ff\r\ngithub.com/spf13/cobra.(*Command).ExecuteContextC(...)\r\n\tgithub.com/spf13/cobra@v1.8.1/command.go:1050\r\ngithub.com/cli/cli/v2/internal/ghcmd.Main()\r\n\tgithub.com/cli/cli/v2/internal/ghcmd/cmd.go:114 +0x53b\r\nmain.main()\r\n\tgithub.com/cli/cli/v2/cmd/gh/main.go:10 +0x13\r\n```\r\n\r\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\r\n</BODY>"
+  - name: 'not spam, #9975 (https://github.com/cli/cli/issues/9975)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Improve `dnf` installation instructions to clarify which version to use
+      </TITLE>
+
+      <BODY>
+      We have received some issues and PRs regarding [the `dnf` installation instructions](https://github.com/cli/cli/blob/trunk/docs/install_linux.md) not working. The cause is users not following the installation instructions corresponding to the version of `dnf` they have installed:
+
+      - https://github.com/cli/cli/issues/9974
+      - https://github.com/cli/cli/pull/9965
+      - https://github.com/cli/cli/pull/9943
+
+      We should improve the installation instructions to encourage users to understand which `dnf` version they have installed and clearly describe which installation commands to use for that version.
+
+      Some improvement thoughts:
+
+      - The note about which version of `dnf` to use comes after the commands to run (people do not read that far since they just want a command to copy/paste)
+      - The `dnf4` instructions are collapsed. Perhaps they should be un-collapsed for now since most people will still be using dn4 until the majority upgrade to OS versions with `dnf5` by default.
+      - Both instructions should be under subheadings that clearly indicate the `dnf` versions
+
+      ## Expected output
+
+      The [the `dnf` installation instructions](https://github.com/cli/cli/blob/trunk/docs/install_linux.md) are improved to prevent users from running the wrong installation command for their `dnf` version.
+      </BODY>
+  - name: 'not spam, #9960 (https://github.com/cli/cli/issues/9960)'
+    expected: PASS
+    input: "<TITLE>\ngh-cli rpm repo file missing gpgcheck\n</TITLE>\n\n<BODY>\nNot sure if this behavior is intended as result of https://github.com/cli/cli/issues/9569 but after adding the repo to dnf it is missing the `gpgcheck=1` resulting in not checking the key. \r\n\r\n`Warning: skipped PGP checks for 1 package from repository: gh-cli`\r\n\r\nAfter manually adding `gpgcheck=1` to the repo file it works without problems and succesfully imported the key.\r\n\r\n```\r\nImporting PGP key 0x75716059:\r\n UserID     : \"GitHub CLI <opensource+cli@github.com>\"\r\n Fingerprint: 2C6106201985B60E6C7AC87323F3D4EA75716059\r\n From       : https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x23F3D4EA75716059\r\nThe key was successfully imported.\r\n```\n</BODY>"
+  - name: 'not spam, #9947 (https://github.com/cli/cli/issues/9947)'
+    expected: PASS
+    input: "<TITLE>\n--no-archived gives no results\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n`$ gh --version\r\ngh version 2.62.0-19-g9177b22a (2024-11-18)\r\nhttps://github.com/cli/cli/releases/latest`\r\n\r\nAfter this very recent update to github-cli the following command no longer returns any results:\r\n\r\n`gh repo list ololabs -L 9999 --no-archived`\r\n\r\nBut removing `--no-archived` returns lots of things, most of which are not archived. The `--no-archived` flag is filtering out EVERYTHING.\r\n\r\n### Logs\r\n\r\n`$ gh repo list ololabs -L 9999 --no-archived\r\nNo results`\n</BODY>"
+  - name: 'not spam, #9941 (https://github.com/cli/cli/issues/9941)'
+    expected: PASS
+    input: "<TITLE>\n`baseRefOid` not returned by `gh pr view`\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nCurrently only `baseRefName` is returned by `gh pr view`. `baseRefOid` is more useful and should be returned as well IMHO. \r\n\r\n### Proposed solution\r\n\r\nE.g. I have gh plugin in neovim that would show correct diff using Diffview.nvim if `baseRefOid` were available. Example code here: https://github.com/daliusd/ghlite.nvim/pull/8\r\n</BODY>"
+  - name: 'not spam, #9927 (https://github.com/cli/cli/issues/9927)'
+    expected: PASS
+    input: "<TITLE>\nunexpected end of JSON input when sending a HEAD request with gh api\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nWhen using `gh api` to request the headers(`-X HEAD`) of a non-existent release, the command exits with an exit code of 1 and prints `unexpected end of JSON input` to stderr. The issue seems to only affect non-existent releases, as requesting a release that exists does not have the same issue.\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Run `gh api -X HEAD \"repos/cli/cli/releases/tags/nonexistent\" ; echo $?`\r\n1. See exit code of 1\r\n1. Run `gh api -X HEAD \"repos/cli/cli/releases/tags/v2.62.0\" ; echo $?`\r\n1. See exit code of 0\r\n\r\n### Expected vs actual behavior\r\n\r\nBoth commands should exit with a code of 0.\r\n\r\n### Logs\r\n\r\n```\r\n$ gh api -X HEAD \"repos/cli/cli/releases/tags/nonexistent\" ; echo $?\r\n* Request at 2024-11-16 08:50:11.4016835 +0000 CST m=+0.077060401\r\n* Request to https://api.github.com/repos/cli/cli/releases/tags/nonexistent\r\n> HEAD /repos/cli/cli/releases/tags/nonexistent HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: */*\r\n> Authorization: token ████████████████████\r\n> Content-Type: application/json; charset=utf-8\r\n> Time-Zone: UTC\r\n> User-Agent: GitHub CLI 2.61.0\r\n\r\n< HTTP/2.0 404 Not Found\r\n< Access-Control-Allow-Origin: *\r\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\r\n< Content-Length: 133\r\n< Content-Security-Policy: default-src 'none'\r\n< Content-Type: application/json; charset=utf-8\r\n< Date: Sat, 16 Nov 2024 08:50:12 GMT\r\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\r\n< Server: github.com\r\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\r\n< Vary: Accept-Encoding, Accept, X-Requested-With\r\n< X-Accepted-Oauth-Scopes: repo\r\n< X-Content-Type-Options: nosniff\r\n< X-Frame-Options: deny\r\n< X-Github-Api-Version-Selected: 2022-11-28\r\n< X-Github-Media-Type: github.v3; format=json\r\n< X-Github-Request-Id: C84C:36F44B:1BC8637:1D38C20:67385CC4\r\n< X-Oauth-Client-Id: ████████████████████\r\n< X-Oauth-Scopes: gist, read:org, repo, workflow\r\n< X-Ratelimit-Limit: 5000\r\n< X-Ratelimit-Remaining: 4998\r\n< X-Ratelimit-Reset: 1731750391\r\n< X-Ratelimit-Resource: core\r\n< X-Ratelimit-Used: 2\r\n< X-Xss-Protection: 0\r\n\r\n* Request took 545.7425ms\r\nunexpected end of JSON input\r\n1\r\n\r\n$ gh api -X HEAD \"repos/cli/cli/releases/tags/v2.62.0\" ; echo $?\r\n* Request at 2024-11-16 08:50:15.5118526 +0000 CST m=+0.067254201\r\n* Request to https://api.github.com/repos/cli/cli/releases/tags/v2.62.0\r\n> HEAD /repos/cli/cli/releases/tags/v2.62.0 HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: */*\r\n> Authorization: token ████████████████████\r\n> Content-Type: application/json; charset=utf-8\r\n> Time-Zone: UTC\r\n> User-Agent: GitHub CLI 2.61.0\r\n\r\n< HTTP/2.0 200 OK\r\n< Access-Control-Allow-Origin: *\r\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\r\n< Cache-Control: private, max-age=60, s-maxage=60\r\n< Content-Length: 37358\r\n< Content-Security-Policy: default-src 'none'\r\n< Content-Type: application/json; charset=utf-8\r\n< Date: Sat, 16 Nov 2024 08:50:16 GMT\r\n< Etag: \"3ee4cd9b98ceb34bcc6d030cac0282e4367b29115cfa1e9a055661b2c29c1a7c\"\r\n< Last-Modified: Thu, 14 Nov 2024 16:12:31 GMT\r\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\r\n< Server: github.com\r\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\r\n< Vary: Accept, Authorization, Cookie, X-GitHub-OTP,Accept-Encoding, Accept, X-Requested-With\r\n< X-Accepted-Oauth-Scopes: repo\r\n< X-Content-Type-Options: nosniff\r\n< X-Frame-Options: deny\r\n< X-Github-Api-Version-Selected: 2022-11-28\r\n< X-Github-Media-Type: github.v3; format=json\r\n< X-Github-Request-Id: C84D:35C4BD:1B9215D:1D027A6:67385CC8\r\n< X-Oauth-Client-Id: ████████████████████\r\n< X-Oauth-Scopes: gist, read:org, repo, workflow\r\n< X-Ratelimit-Limit: 5000\r\n< X-Ratelimit-Remaining: 4997\r\n< X-Ratelimit-Reset: 1731750391\r\n< X-Ratelimit-Resource: core\r\n< X-Ratelimit-Used: 3\r\n< X-Xss-Protection: 0\r\n\r\n* Request took 536.3801ms\r\n0\r\n```\r\n</BODY>"
+  - name: 'not spam, #9925 (https://github.com/cli/cli/issues/9925)'
+    expected: PASS
+    input: "<TITLE>\nAdd Environment Variable to Skip Latest Extension Version Check\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nIn version `2.62.0`, the ability to check the extension for the latest version was added.\r\n\r\n- #9866\r\n\r\nUsing a modified local version of an extension shows updates on every run, which I consider false positives since I don't want to upgrade. Also, a small delay of about one second has been added, which is unwanted after exiting an extension.\r\n\r\n\r\n### Proposed solution\r\n\r\nAbility to skip checking for the latest extension version.\r\n\r\nExtend `GH_NO_UPDATE_NOTIFIER` to silence extension update messages, or introduce a new variable specifically for extensions.\r\n\r\n### Additional context\r\n\r\nThis request is related to issue #743, where an environment variable was added to silence update messages.\r\n\r\nhttps://github.com/cli/cli/blob/cd3f2ad064fbeca17d330e321fef0591eaa0fea5/pkg/cmd/root/help_topic.go#L88-L92\r\n\r\n\r\n<details>\r\n\r\n<summary><b>More Context</b></summary>\r\n\r\n---\r\n\r\n\r\nI am using this extension:\r\n- https://github.com/meiji163/gh-notify\r\n\r\nHowever, my local version is not using the 'main' branch but a pull request I created.\r\n- https://github.com/meiji163/gh-notify/pull/95\r\n\r\nWhen I run the extension, I see the following message, which I don't want to see:\r\n\r\n```bash\r\ngh notify -an 1\r\n\r\nA new release of notify is available: b39386a96a4e105dc3e5f34a447bdc011c9e8098 → 556df2eecdc0f838244a012759da0b76bcfeb2e7\r\nTo upgrade, run: gh extension upgrade notify\r\ngit@github.com:meiji163/gh-notify.git\r\n```\r\n\r\n\r\n\r\n---\r\n\r\n</details>\r\n</BODY>"
+  - name: 'not spam, #9904 (https://github.com/cli/cli/issues/9904)'
+    expected: PASS
+    input: "<TITLE>\n`gh repo create` to work on bare repos\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nWhen I use `gh repo create` and specify `\"Push an existing local repository to Github\"` on my bare repository, it says [`\"current directory is not a git repository. Run git init to initialize it\"`](https://github.com/cli/cli/blob/9b9e654c767d58b666063715169cb24c92551f06/pkg/cmd/repo/create/create.go#L565C23-L565C98). To resolve this, I go to the web interface and manually create a new repo. I'd like to request for `gh repo create` to recognize bare repositories as repositories.\r\n\r\n### Proposed solution\r\n\r\n#6880 was a merged PR that migrated to git rev-parse's `--git-dir` flag to correctly recognize bare and non-bare repos for another part of the github cli for a similar issue. Although this is what the `gh repo create` command [also does](https://github.com/cli/cli/blob/9b9e654c767d58b666063715169cb24c92551f06/git/client.go#L446), it only [checks](https://github.com/cli/cli/blob/9b9e654c767d58b666063715169cb24c92551f06/pkg/cmd/repo/create/create.go#L740C1-L755C2) if the result is `.git`, instead of also checking if it's also `.` in the case of a bare repo. We can check for a `.` case.\r\n\r\n### Additional context\r\n\r\nThis will make the CLI's functionality more streamlined and consistent with user expectations\r\n</BODY>"
+  - name: 'not spam, #9897 (https://github.com/cli/cli/issues/9897)'
+    expected: PASS
+    input: "<TITLE>\nAdd additional exit codes for `gh cache delete --all`\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nI use `gh cache delete --all` to purge all cache related to a workflow that stores ephemeral items in cache.\r\n\r\n* When cache items are present and they are successfully removed, the command returns an exit code of 0.\r\n* When no cache items are present, the command returns an exit code of 1.\r\n\r\nUnless I parse standard error to read the message for the first case, I can't disambiguate it between an invocation that did not find any cache to remove, and one that did but failed to successfully remove it.\r\n\r\n### Proposed solution\r\n\r\nI propose a unique exit code for the specific case where no cache items were found. This would allow callers to treat this use case as a success and disambiguate it from any genuine errors.\r\n\r\nThis would simplify its usage for this use case significantly.\r\n\r\n### Additional context\r\n\r\nAccording to the [manual](https://cli.github.com/manual/gh_help_exit-codes), it appears this would not fall outside of the cli's existing behavior.\r\n</BODY>"
+  - name: 'not spam, #9882 (https://github.com/cli/cli/issues/9882)'
+    expected: PASS
+    input: "<TITLE>\n`gh cache list --json` should output `[]` when no caches exist\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nWhen using `gh cache list --json <fields>` in a repository without workflow caches, the command outputs a error message instead of JSON.\r\n\r\n```sh\r\n$ gh cache list --json id\r\nNo caches found in <repository name>\r\n```\r\n\r\nThis behavior breaks JSON parsing in automated scripts since they expect valid JSON output and they need extra error handling.\r\nFor consistent JSON output format, the output should be `[]`.\r\n\r\n### Proposed solution\r\n\r\nWhen the `--json` option is used, `gh cache list` should retuan an empty JSON array (`[]`) to indicate no caches exist.\r\n\r\n```sh\r\n$ gh cache list --json id\r\n[]\r\n```\r\n\r\nThe text message should still be shown when running without the `--json` flag.\r\n\r\n### Additional context\r\n\r\n- `gh version`: `gh version 2.60.1 (2024-10-25)`\r\n</BODY>"
+  - name: 'not spam, #9860 (https://github.com/cli/cli/issues/9860)'
+    expected: PASS
+    input: "<TITLE>\n MacPorts installation fails with `dyld: Symbol not found: _SecTrustEvaluateWithError` on older macOS versions\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nGitHub CLI (`gh`) fails to install through MacPorts. Related to sethmlarson/truststore#119.\r\n\r\n### Steps to reproduce the behavior\r\n\r\nhttps://asciinema.org/a/I8VkOazbwn1ON5QRt477K2HK4\r\n\r\n### Expected vs actual behavior\r\n\r\nSupposed to install.\r\nFails with `dyld: Symbol not found: _SecTrustEvaluateWithError`\r\n\r\n### Logs\r\n\r\n[![asciicast](https://asciinema.org/a/I8VkOazbwn1ON5QRt477K2HK4.svg)](https://asciinema.org/a/I8VkOazbwn1ON5QRt477K2HK4)\r\n\r\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\r\n\r\n### Additional information\r\n\r\nmacOS Version: `10.12.6 (Sierra)`\r\nGitHub CLI (`gh`) version: None\n</BODY>"
+  - name: 'not spam, #9850 (https://github.com/cli/cli/issues/9850)'
+    expected: PASS
+    input: "<TITLE>\n`gh at verify` evaluates policy transparently and monotonically\n</TITLE>\n\n<BODY>\n## summary\n\nWe've been thinking about how `gh at verify` works. We've realized that `gh at verify` is in effect used to evaluate policy – and that therefore we have to improve its user experience.\n\nAs a result, we've decided that the tool ought to:\n1. be more explicit/transparent about what criteria, exactly, are being used to make pass/fail decisions\n2. provide meaningful defaults (& that we will begin enforcing provenance predicates unless otherwise specified)\n3. evaluate policy monotonically\n\nthis issue is our public facing description of these changes. hello!\n\n## context\n\nwhen we originally set out to create `gh at verify` and the underlying `sigstore-go` library, we had many conversations about the nature of \"policy\" and \"verification\". to wit, where does \"verifying crypto materials\" end, and \"enforcing organization-specific rules and procedures\" (aka policy) start?\n\nwe wanted to avoid guessing what our users wanted to enforce as a rule or procedure, and as a result `gh at verify` erred on the \"we're verifying the crypto materials\" side of things. we imagined that our users would plug the tool's output into a \"real\" policy evaluation tool.\n\neventually, we realized that despite this initial intention, `gh at verify` can and ought to be used to \"enforce organization-specific rules\" and is actually the first point of entry the vast majority of users will use for dealing with the organization-specific rules and procedures.\n\n## outcomes\n\nas a consequence, the tool needs to be able to spell out exactly what is being verified. the tool needs to have a meaningful default for predicate types: it doesn't make sense for an artifact to be \"verified\" just because there is an SBOM attached when you _probably_ meant to check for its provenance. and finally, the tool should not give up as soon as it encounters a single attestation that fails to verify according to our criteria.\n\n### monotonic policy evaluation\n\nthis last step we call \"monotonicity\", as in the [monotonicity of entailment](https://en.wikipedia.org/wiki/Monotonicity_of_entailment).\n\nAdopting the language of formal systems, a command like:\n\n`gh at verify -R github/foo artifact.bin` \n\nexpresses a sentence (“`github/foo` originated `artifact.bin`”) that is either true or false, and whose truth value can be deduced from the attestations (i.e. a set of independent propositions) that are associated with the artifact.\n\nIn this view, the truth value of the policy statement is monotonic because, once `gh at verify` evaluates a policy statement to be **true**, it is not be possible for that statement to become invalid by adding new attestations.\n</BODY>"
+  - name: 'not spam, #9849 (https://github.com/cli/cli/issues/9849)'
+    expected: PASS
+    input: "<TITLE>\n`gh repo set-default` claims \"none of the git remotes correspond [sic!] to a valid remote repository\"\n</TITLE>\n\n<BODY>\n``` \r\n$ gh repo set-default\r\nnone of the git remotes correspond to a valid remote repository\r\n\r\n$ git remote -v\r\ngithub\tgit@github.com:teach-plt/lab-sources.git (fetch)\r\ngithub\tgit@github.com:teach-plt/lab-sources.git (push)\r\norigin\tgit@git.chalmers.se:courses/dat151/lab-sources.git (fetch)\r\norigin\tgit@git.chalmers.se:courses/dat151/lab-sources.git (push)\r\n\r\n$ gh --version\r\ngh version 2.60.1 (2024-10-25)\r\nhttps://github.com/cli/cli/releases/tag/v2.60.1\r\n``` \r\n\r\nIt is unclear to me why `git@github.com:teach-plt/lab-sources.git` should not be a valid remote.  After all, I pasted it from github after creating this repo.\r\n\r\nNote also the grammatical error in the error message:\r\n> none of the git remotes correspond to a valid remote repository\r\n\r\n\"none of\" should be followed by a singular form \"corresponds\".\r\n\r\nHere the debug output:\r\n``` \r\n$ GH_DEBUG=true gh repo set-default\r\n[git rev-parse --git-dir]\r\n[git remote -v]\r\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\r\n* Request at 2024-10-30 20:36:45.529983 +0100 CET m=+0.262239998\r\n* Request to https://api.github.com/graphql\r\n* Request took 352.603691ms\r\nnone of the git remotes correspond to a valid remote repository\r\n```\r\n</BODY>"
+  - name: 'not spam, #9822 (https://github.com/cli/cli/issues/9822)'
+    expected: PASS
+    input: "<TITLE>\nuse brew install gh in macos but it failed\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nA clear and concise description of what the bug is. Include version by typing `gh --version`.\r\n\r\n### Steps to reproduce the behavior\r\n\r\n```bash\r\n➜  kubernetes git:(fix/leaderelection/patch) brew install gh\r\n==> Fetching dependencies for gh: go\r\n==> Fetching go\r\n==> Downloading https://raw.githubusercontent.com/Homebrew/homebrew-core/34bcc7f18b057c38e95b816853bebe3964879daf/Formula/g/go.rb\r\nAlready downloaded: /Users/zhenyu.jiang/Library/Caches/Homebrew/downloads/89ebce7fa5b7e05dd5e520a1f24a4823c86d6ee7493c13247db0e18cafb36270--go.rb\r\n==> Downloading https://storage.googleapis.com/golang/go1.20.14.darwin-arm64.tar.gz\r\nAlready downloaded: /Users/zhenyu.jiang/Library/Caches/Homebrew/downloads/cc9ffcf31947b98e85668e951f01d7185ebdc5fb764bca871a34444045978b2e--go1.20.14.darwin-arm64.tar.gz\r\n==> Downloading https://go.dev/dl/go1.23.2.src.tar.gz\r\nAlready downloaded: /Users/zhenyu.jiang/Library/Caches/Homebrew/downloads/f0baedeec690754c0c558c7588fa12ba1c0d8c4a8b3a00167133f45856a596f6--go1.23.2.src.tar.gz\r\n==> Fetching gh\r\n==> Downloading https://raw.githubusercontent.com/Homebrew/homebrew-core/34bcc7f18b057c38e95b816853bebe3964879daf/Formula/g/gh.rb\r\nAlready downloaded: /Users/zhenyu.jiang/Library/Caches/Homebrew/downloads/b80ed34149b1beb1b766c3f4742b3b6d4b191b246da491b48bb8a2b0a977395f--gh.rb\r\nError: gh: undefined method `deny_network_access!' for Formulary::FormulaNamespaceb545aee98f0aabcc21b82e7e001eb539::Gh:Class\r\n\r\n```\r\n\r\n1. Type this '...'\r\n2. View the output '....'\r\n3. See error\r\n\r\n### Expected vs actual behavior\r\n\r\nA clear and concise description of what you expected to happen and what actually happened.\r\n\r\n### Logs\r\n\r\nPaste the activity from your command line. Redact if needed.\r\n\r\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\r\n</BODY>"
+  - name: 'not spam, #9808 (https://github.com/cli/cli/issues/9808)'
+    expected: PASS
+    input: "<TITLE>\n\"gh secret set\" using selected visibility requires a list of repositories, its optional in the API/browser\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nCreating an Organization Secret via github.com allows you to specify the \"selected repositories\" visibility setting, and initially specify zero repos (you can update the list later).\r\n\r\nhttps://docs.github.com/en/rest/actions/secrets?apiVersion=2022-11-28#create-or-update-an-organization-secret confirms the `selected_repository_ids` parameter is optional / not required.\r\n\r\nWhereas using `gh secret set somesecret -b somevalue -o orgname -v selected` will error out.\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Create an Organization secret, specify Selected Repositories for Visbiility, but don't specify any repositories.\r\n2. Confirm the secret is created.\r\n3. Create a Personal Access Token with Organization Secret level permissions (read/write)\r\n4. Then try `gh secret set somesecret -b somevalue -o orgname -v selected` using the Personal Access Token - error.\r\n\r\n### Expected vs actual behavior\r\n\r\nExpected: secret gets created, with \"selected\" visibility and no repositories specified.\r\n\r\nActual:\r\n\r\n```\r\n> gh secret set somesecret -b somevalue -o orgname -v selected\r\n`--repos` list required with `--visibility=selected`\r\n\r\nUsage:  gh secret set <secret-name> [flags]\r\n\r\n...\r\n```\r\n\r\n### Logs\r\n\r\nN/A\r\n</BODY>"
+  - name: 'not spam, #9807 (https://github.com/cli/cli/issues/9807)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Add confirmation flag to `gh repo edit --visibility` command
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      Changing the visibility of a repository is one of the most impactful, potentially dangerous actions because of the consequences when going from public to private or internal or vice versa:
+
+      > - If you decide to make this repository public in the future, it will not be possible to restore these stars and watchers and this will affect its repository rankings.
+      > - Dependency graph and Dependabot alerts will remain enabled with permission to perform read-only analysis on this repository. Any custom Dependabot alert rules will be disabled unless GitHub Advanced Security is enabled for this repository.
+      > - Code scanning will become unavailable.
+      > - Current forks will remain public and will be detached from this repository.
+
+      ![Screenshot of GitHub repository settings danger zone](https://github.com/user-attachments/assets/4ebb49f2-fa57-433f-b79f-af47c2b7e940)
+      ![Screenshot of GitHub repository visibility changing from private to public](https://github.com/user-attachments/assets/a96fd66e-e764-45b6-8162-0c0939e6346b)
+
+      Users are interactively prompted when using `gh repo edit` command to change visibility, however there are no safeguards when used non-interactively:
+
+      ```shell
+      ➜ gh repo edit
+      ? What do you want to edit? Visibility
+      ? Visibility private
+      ! Changing the repository visibility to private will cause permanent loss of stars and watchers.
+      ? Do you want to change visibility to private? (y/N)
+      ```
+
+      This issue is to implement an experience similar to various `gh <primitive> delete` commands requiring a boolean flag to confirm changing visibility when used non-interactively.
+
+      ### Acceptance Criteria
+
+      - [ ] When `gh repo edit --visibility` is called non-interactively, it requires the `--accept-visibility-change-consequences` flag to be included or the command fails
+      </BODY>
+  - name: 'not spam, #9801 (https://github.com/cli/cli/issues/9801)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Document the dangers of changing repo visibility in the CLI
+      </TITLE>
+
+      <BODY>
+      ### Describe the feature or problem you’d like to solve
+
+      Changing the visibility of a repository is one of the most impactful, potentially dangerous actions because of the consequences when going from public to private or internal or vice versa:
+
+      > - If you decide to make this repository public in the future, it will not be possible to restore these stars and watchers and this will affect its repository rankings.
+      > - Dependency graph and Dependabot alerts will remain enabled with permission to perform read-only analysis on this repository. Any custom Dependabot alert rules will be disabled unless GitHub Advanced Security is enabled for this repository.
+      > - Code scanning will become unavailable.
+      > - Current forks will remain public and will be detached from this repository.
+
+      ![Screenshot of GitHub repository settings danger zone](https://github.com/user-attachments/assets/4ebb49f2-fa57-433f-b79f-af47c2b7e940)
+      ![Screenshot of GitHub repository visibility changing from private to public](https://github.com/user-attachments/assets/a96fd66e-e764-45b6-8162-0c0939e6346b)
+
+      Currently, the consequences of changing between any of these visibilities isn't well documented in the CLI, leaving users unaware of the impact they may have while running this command.
+
+      The impacts can be found in the comments below.
+
+      ### Acceptance Criteria
+
+      - [ ] Document the dangers associated with changing the visibility of a repo within the CLI tool
+      </BODY>
+  - name: 'not spam, #9781 (https://github.com/cli/cli/issues/9781)'
+    expected: PASS
+    input: "<TITLE>\n`gh workflow run --ref [ref]` ignoring `ref`\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n```bash\r\n$ gh --version\r\ngh version 2.59.0 (2024-10-16)\r\nhttps://github.com/cli/cli/releases/tag/v2.59.0\r\n```\r\n\r\nUsing the `ref` parameter does not seem to have any impact. A random-string `ref` gives no errors. A `ref` for an existing branch that has not yet been merged into the default branch reports 404 when trying to run a workflow that is new to that branch.\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Create a new branch `foo`\r\n2. Create a new workflow file `bar.yml` with `workflow_dispatch` and no other triggers\r\n3. commit/push branch\r\n4. `gh workflow run bar.yml --ref foo`\r\n\r\n### Expected vs actual behavior\r\n\r\nExpected: workflow `bar.yml` runs.\r\nActual: 404: Not found.\r\n\r\n### Logs\r\n\r\nPaste the activity from your command line. Redact if needed.\r\n\r\n```bash\r\n$ GH_DEBUG=true gh workflow run bar.yml --ref foo\r\n[git remote -v]\r\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\r\n* Request at 2024-10-17 10:33:53.601824859 -0400 EDT m=+0.076128339\r\n* Request to https://api.github.com/graphql\r\n* Request took 309.171144ms\r\n* Request at 2024-10-17 10:33:53.914645102 -0400 EDT m=+0.388948592\r\n* Request to https://api.github.com/repos/[ORG]/[REPO]/actions/workflows/bar.yml\r\n* Request took 134.922376ms\r\nHTTP 404: Not Found (https://api.github.com/repos/.../bar.yml)\r\n```\n</BODY>"
+  - name: 'not spam, #9773 (https://github.com/cli/cli/issues/9773)'
+    expected: PASS
+    input: "<TITLE>\n`gh release create` works for some commit hashes but gets weird 404 for others\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n`gh release create` command works for some commit hashes but not for other. For the ones it doesn't work, it complains about getting 404 when accessing the `https://api.github.com/repos/<owner>/<repo>/releases` API endpoint..\r\n\r\n### Steps to reproduce the behavior\r\n\r\nSince I don't know what causes it to break for some commits but not for others, I can't replicate it from a fresh repository. You'll have to use one of my repositories.\r\n\r\n1. Fork my repository https://github.com/idanarye/bevy-yoetz\r\n2. `git clone` your fork and `cd` into the worktree.\r\n3. Set the default repository for the workdir with `gh repo set-default `\r\n4. Run the following command to create a release from commit `8ed44f70782e8cd733acd3d33812d4b771c1bd9b`:\r\n    ```bash\r\n    gh release create v0.1.0 --target a602187ebae72cc0e8101cc46fc116a51c9e9e39 --title foo --notes bar\r\n    ```\r\n5. Run the same command but with a different commit - `8ed44f70782e8cd733acd3d33812d4b771c1bd9b`:\r\n    ```bash\r\n    gh release create v0.1.0 --target 8ed44f70782e8cd733acd3d33812d4b771c1bd9b --title foo --notes bar \r\n    ```\r\n\r\n### Expected vs actual behavior\r\n\r\nI expected the first `gh release create` command to succeed and create a release. Instead it complained about getting 404 when trying to access https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/releases - a URL that I'm able to access myself and that it was able to access just fine when I tried with a different commit.\r\n\r\n### Logs\r\n\r\nPaste the activity from your command line. Redact if needed.\r\n\r\n```\r\n$ # Uploading a version with a commit hash that doesn't work\r\n$ GH_DEBUG=api gh release create v0.1.0 --target a602187ebae72cc0e8101cc46fc116a51c9e9e39 --title foo --notes bar\r\n[git remote -v]\r\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\r\n[git tag --list v0.1.0 --format=%(contents)]\r\n[git tag --list v0.1.0 --format=%(contents:signature)]\r\n* Request at 2024-10-17 01:33:46.735208987 +0300 IDT m=+0.055297086\r\n* Request to https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/releases\r\n> POST /repos/aeon-felis/test-with-bevy-yoetz/releases HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\r\n> Authorization: token ████████████████████\r\n> Content-Length: 142\r\n> Content-Type: application/json; charset=utf-8\r\n> Time-Zone: Israel\r\n> User-Agent: GitHub CLI v2.59.0\r\n\r\n{\r\n  \"body\": \"bar\",\r\n  \"draft\": false,\r\n  \"name\": \"foo\",\r\n  \"prerelease\": false,\r\n  \"tag_name\": \"v0.1.0\",\r\n  \"target_commitish\": \"a602187ebae72cc0e8101cc46fc116a51c9e9e39\"\r\n}\r\n\r\n< HTTP/2.0 404 Not Found\r\n< Access-Control-Allow-Origin: *\r\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\r\n< Content-Security-Policy: default-src 'none'\r\n< Content-Type: application/json; charset=utf-8\r\n< Date: Wed, 16 Oct 2024 22:36:00 GMT\r\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\r\n< Server: github.com\r\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\r\n< Vary: Accept-Encoding, Accept, X-Requested-With\r\n< X-Accepted-Oauth-Scopes: repo\r\n< X-Content-Type-Options: nosniff\r\n< X-Frame-Options: deny\r\n< X-Github-Api-Version-Selected: 2022-11-28\r\n< X-Github-Media-Type: github.v3; param=merge-info-preview.nebula-preview; format=json\r\n< X-Github-Request-Id: D8FE:3E6E91:207FC:2E39B:67103FD0\r\n< X-Oauth-Client-Id: 178c6fc778ccc68e1d6a\r\n< X-Oauth-Scopes: admin:public_key, gist, read:org, repo\r\n< X-Ratelimit-Limit: 5000\r\n< X-Ratelimit-Remaining: 4930\r\n< X-Ratelimit-Reset: 1729118813\r\n< X-Ratelimit-Resource: core\r\n< X-Ratelimit-Used: 70\r\n< X-Xss-Protection: 0\r\n\r\n{\r\n  \"message\": \"Not Found\",\r\n  \"documentation_url\": \"https://docs.github.com/rest/releases/releases#create-a-release\",\r\n  \"status\": \"404\"\r\n}\r\n\r\n* Request took 361.999146ms\r\nHTTP 404: Not Found (https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/releases)\r\n$ \r\n$ # Verifying that that commit hash exists\r\n$ git branch --all --contains a602187ebae72cc0e8101cc46fc116a51c9e9e39\r\n* main\r\n  remotes/origin/HEAD -> origin/main\r\n  remotes/origin/main\r\n$ \r\n$ # Running the same command using a different commit hash\r\n$ GH_DEBUG=api gh release create v0.1.0 --target 8ed44f70782e8cd733acd3d33812d4b771c1bd9b --title foo --notes bar\r\n[git remote -v]\r\n[git config --get-regexp ^remote\\..*\\.gh-resolved$]\r\n[git tag --list v0.1.0 --format=%(contents)]\r\n[git tag --list v0.1.0 --format=%(contents:signature)]\r\n* Request at 2024-10-17 01:34:15.778241751 +0300 IDT m=+0.055598163\r\n* Request to https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/releases\r\n> POST /repos/aeon-felis/test-with-bevy-yoetz/releases HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\r\n> Authorization: token ████████████████████\r\n> Content-Length: 142\r\n> Content-Type: application/json; charset=utf-8\r\n> Time-Zone: Israel\r\n> User-Agent: GitHub CLI v2.59.0\r\n\r\n{\r\n  \"body\": \"bar\",\r\n  \"draft\": false,\r\n  \"name\": \"foo\",\r\n  \"prerelease\": false,\r\n  \"tag_name\": \"v0.1.0\",\r\n  \"target_commitish\": \"8ed44f70782e8cd733acd3d33812d4b771c1bd9b\"\r\n}\r\n\r\n< HTTP/2.0 201 Created\r\n< Access-Control-Allow-Origin: *\r\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\r\n< Cache-Control: private, max-age=60, s-maxage=60\r\n< Content-Length: 1767\r\n< Content-Security-Policy: default-src 'none'\r\n< Content-Type: application/json; charset=utf-8\r\n< Date: Wed, 16 Oct 2024 22:36:29 GMT\r\n< Etag: \"757f457333dcfd9b3006fa1643a24754c8426a81f90aba76f87857d6c424a3f8\"\r\n< Location: https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/releases/180334381\r\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\r\n< Server: github.com\r\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\r\n< Vary: Accept, Authorization, Cookie, X-GitHub-OTP,Accept-Encoding, Accept, X-Requested-With\r\n< X-Accepted-Oauth-Scopes: repo\r\n< X-Content-Type-Options: nosniff\r\n< X-Frame-Options: deny\r\n< X-Github-Api-Version-Selected: 2022-11-28\r\n< X-Github-Media-Type: github.v3; param=merge-info-preview.nebula-preview; format=json\r\n< X-Github-Request-Id: B4D8:3A3B84:20275:2DEC0:67103FED\r\n< X-Oauth-Client-Id: 178c6fc778ccc68e1d6a\r\n< X-Oauth-Scopes: admin:public_key, gist, read:org, repo\r\n< X-Ratelimit-Limit: 5000\r\n< X-Ratelimit-Remaining: 4929\r\n< X-Ratelimit-Reset: 1729118813\r\n< X-Ratelimit-Resource: core\r\n< X-Ratelimit-Used: 71\r\n< X-Xss-Protection: 0\r\n\r\n{\r\n  \"url\": \"https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/releases/180334381\",\r\n  \"assets_url\": \"https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/releases/180334381/assets\",\r\n  \"upload_url\": \"https://uploads.github.com/repos/aeon-felis/test-with-bevy-yoetz/releases/180334381/assets{?name,label}\",\r\n  \"html_url\": \"https://github.com/aeon-felis/test-with-bevy-yoetz/releases/tag/v0.1.0\",\r\n  \"id\": 180334381,\r\n  \"author\": {\r\n    \"login\": \"idanarye\",\r\n    \"id\": 1149255,\r\n    \"node_id\": \"MDQ6VXNlcjExNDkyNTU=\",\r\n    \"avatar_url\": \"https://avatars.githubusercontent.com/u/1149255?v=4\",\r\n    \"gravatar_id\": \"\",\r\n    \"url\": \"https://api.github.com/users/idanarye\",\r\n    \"html_url\": \"https://github.com/idanarye\",\r\n    \"followers_url\": \"https://api.github.com/users/idanarye/followers\",\r\n    \"following_url\": \"https://api.github.com/users/idanarye/following{/other_user}\",\r\n    \"gists_url\": \"https://api.github.com/users/idanarye/gists{/gist_id}\",\r\n    \"starred_url\": \"https://api.github.com/users/idanarye/starred{/owner}{/repo}\",\r\n    \"subscriptions_url\": \"https://api.github.com/users/idanarye/subscriptions\",\r\n    \"organizations_url\": \"https://api.github.com/users/idanarye/orgs\",\r\n    \"repos_url\": \"https://api.github.com/users/idanarye/repos\",\r\n    \"events_url\": \"https://api.github.com/users/idanarye/events{/privacy}\",\r\n    \"received_events_url\": \"https://api.github.com/users/idanarye/received_events\",\r\n    \"type\": \"User\",\r\n    \"site_admin\": false\r\n  },\r\n  \"node_id\": \"RE_kwDONBZL8M4Kv68t\",\r\n  \"tag_name\": \"v0.1.0\",\r\n  \"target_commitish\": \"8ed44f70782e8cd733acd3d33812d4b771c1bd9b\",\r\n  \"name\": \"foo\",\r\n  \"draft\": false,\r\n  \"prerelease\": false,\r\n  \"created_at\": \"2024-07-04T21:33:58Z\",\r\n  \"published_at\": \"2024-10-16T22:36:29Z\",\r\n  \"assets\": [],\r\n  \"tarball_url\": \"https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/tarball/v0.1.0\",\r\n  \"zipball_url\": \"https://api.github.com/repos/aeon-felis/test-with-bevy-yoetz/zipball/v0.1.0\",\r\n  \"body\": \"bar\"\r\n}\r\n\r\n* Request took 708.189761ms\r\nhttps://github.com/aeon-felis/test-with-bevy-yoetz/releases/tag/v0.1.0\r\n```\n</BODY>"
+  - name: 'not spam, #9769 (https://github.com/cli/cli/issues/9769)'
+    expected: PASS
+    input: "<TITLE>\nInclude `startedAt` and `completedAt` fields when exporting workflow run job steps information\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\n\nI would like to analyze performance characteristics of GitHub Actions workflows within repositories in order to identify expensive areas within automation.  One of said areas is workflows with steps that take a long time, which are arguably expensive.  However, `gh run view --json jobs` command only lists name, conclusion, step number, and status of each step.\n\n**Example:** `gh run view 11365476998 --json jobs --repo cli/cli`\n\nresults in:\n\n```json\n{\n  \"jobs\": [\n    {\n      \"completedAt\": \"2024-10-16T12:23:29Z\",\n      \"conclusion\": \"success\",\n      \"databaseId\": 31613745137,\n      \"name\": \"linux\",\n      \"startedAt\": \"2024-10-16T12:19:46Z\",\n      \"status\": \"completed\",\n      \"steps\": [\n        {\n          \"conclusion\": \"success\",\n          \"name\": \"Set up job\",\n          \"number\": 1,\n          \"status\": \"completed\"\n        },\n        {\n          \"conclusion\": \"success\",\n          \"name\": \"Checkout\",\n          \"number\": 2,\n          \"status\": \"completed\"\n        },\n        {\n          \"conclusion\": \"success\",\n          \"name\": \"Set up Go\",\n          \"number\": 3,\n          \"status\": \"completed\"\n        },\n        ...\n```\n\n### Proposed solution\n\nMy suggestion is to enhance the `Step` struct used for retrieving data from GitHub API to include `completedAt` and `startedAt` fields defined within [List jobs for a workflow run attempt](https://docs.github.com/en/rest/actions/workflow-jobs?apiVersion=2022-11-28#list-jobs-for-a-workflow-run-attempt) endpoint.\n\nThis information is already being provided by GitHub API calls which can be seen via `GH_DEBUG=api gh run view 11365476998 --json jobs --repo cli/cli`:\n\n```shell\n* Request to https://api.github.com/repos/cli/cli/actions/runs/11365476998/jobs?per_page=100\n> GET /repos/cli/cli/actions/runs/11365476998/jobs?per_page=100 HTTP/1.1\n> Host: api.github.com\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\n> Authorization: token ████████████████████\n> Content-Type: application/json; charset=utf-8\n> Time-Zone: America/New_York\n> User-Agent: GitHub CLI 2.58.0\n\n⣻< HTTP/2.0 200 OK\n< Access-Control-Allow-Origin: *\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\n< Cache-Control: private, max-age=60, s-maxage=60\n< Content-Security-Policy: default-src 'none'\n< Content-Type: application/json; charset=utf-8\n< Date: Wed, 16 Oct 2024 12:39:06 GMT\n< Etag: W/\"ce75646c66c3ae20c538110930f5d0562067629a033f7e17c53c134ffebc1f4f\"\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\n< Server: github.com\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\n< Vary: Accept, Authorization, Cookie, X-GitHub-OTP,Accept-Encoding, Accept, X-Requested-With\n< X-Accepted-Oauth-Scopes: \n< X-Content-Type-Options: nosniff\n< X-Frame-Options: deny\n< X-Github-Api-Version-Selected: 2022-11-28\n< X-Github-Media-Type: github.v3; param=merge-info-preview.nebula-preview; format=json\n< X-Github-Request-Id: F3F2:3641A8:11BF99A:22CE595:670FB3EA\n< X-Oauth-Client-Id: 178c6fc778ccc68e1d6a\n< X-Oauth-Scopes: gist, read:org, repo, workflow\n< X-Ratelimit-Limit: 15000\n< X-Ratelimit-Remaining: 14973\n< X-Ratelimit-Reset: 1729083896\n< X-Ratelimit-Resource: core\n< X-Ratelimit-Used: 27\n< X-Xss-Protection: 0\n\n{\n  \"total_count\": 4,\n  \"jobs\": [\n    {\n      \"id\": 31613745137,\n      \"run_id\": 11365476998,\n      \"workflow_name\": \"v2.59.0 / production\",\n      \"head_branch\": \"trunk\",\n      \"run_url\": \"https://api.github.com/repos/cli/cli/actions/runs/11365476998\",\n      \"run_attempt\": 1,\n      \"node_id\": \"CR_kwDODKw3uc8AAAAHXFN38Q\",\n      \"head_sha\": \"7aef6ec39137adb601d31d13fce8b6f26b4903fa\",\n      \"url\": \"https://api.github.com/repos/cli/cli/actions/jobs/31613745137\",\n      \"html_url\": \"https://github.com/cli/cli/actions/runs/11365476998/job/31613745137\",\n      \"status\": \"completed\",\n      \"conclusion\": \"success\",\n      \"created_at\": \"2024-10-16T12:19:01Z\",\n      \"started_at\": \"2024-10-16T12:19:46Z\",\n      \"completed_at\": \"2024-10-16T12:23:29Z\",\n      \"name\": \"linux\",\n      \"steps\": [\n        {\n          \"name\": \"Set up job\",\n          \"status\": \"completed\",\n          \"conclusion\": \"success\",\n          \"number\": 1,\n          \"started_at\": \"2024-10-16T12:19:45Z\",\n          \"completed_at\": \"2024-10-16T12:19:47Z\"\n        },\n        {\n          \"name\": \"Checkout\",\n          \"status\": \"completed\",\n          \"conclusion\": \"success\",\n          \"number\": 2,\n          \"started_at\": \"2024-10-16T12:19:47Z\",\n          \"completed_at\": \"2024-10-16T12:19:48Z\"\n        },\n        {\n          \"name\": \"Set up Go\",\n          \"status\": \"completed\",\n          \"conclusion\": \"success\",\n          \"number\": 3,\n          \"started_at\": \"2024-10-16T12:19:48Z\",\n          \"completed_at\": \"2024-10-16T12:20:05Z\"\n        },\n        {\n          \"name\": \"Install GoReleaser\",\n          \"status\": \"completed\",\n          \"conclusion\": \"success\",\n          \"number\": 4,\n          \"started_at\": \"2024-10-16T12:20:05Z\",\n          \"completed_at\": \"2024-10-16T12:20:06Z\"\n        },\n        {\n          \"name\": \"Build release binaries\",\n          \"status\": \"completed\",\n          \"conclusion\": \"success\",\n          \"number\": 5,\n          \"started_at\": \"2024-10-16T12:20:06Z\",\n          \"completed_at\": \"2024-10-16T12:23:13Z\"\n        },\n```\n\n### Additional context\n\nI imagine exporting step datetimes has the same conditional requirement as job datetimes of dealing with missing / empty / zero `completedAt` information:\n\nhttps://github.com/cli/cli/blob/7aef6ec39137adb601d31d13fce8b6f26b4903fa/pkg/cmd/run/shared/shared.go#L178-L233\n</BODY>"
+  - name: 'not spam, #9760 (https://github.com/cli/cli/issues/9760)'
+    expected: PASS
+    input: "<TITLE>\nBroken installation of extension in development\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nI tried installing extension in development from a local folder and while extension appears installed according to the `list` command, it is not executable. \r\n\r\n### Steps to reproduce the behavior\r\n\r\n0. Checkout https://github.com/IvanRibakov/gh-workflow-stats and navigate to the repo root\r\n1. Install extension from local folder: `gh extensions install .`\r\n2. Check that extension appears installed: `gh ext list`\r\n3. Invoke installed extension: `gh workflow-stats -h`\r\n\r\n### Expected vs actual behavior\r\n\r\nExpecting extension in development installed from a local folder to be usable as if it was installed from Github repo tagged release, instead getting a broken installation that is unusable.\r\n\r\n### Logs\r\n\r\n```\r\n$ pwd\r\n<some-path>/gh-workflow-stats\r\n\r\n$ git status\r\nOn branch feature/filter_multiple_statuses\r\nYour branch is up to date with 'origin/feature/filter_multiple_statuses'.\r\n\r\nnothing to commit, working tree clean\r\n\r\n$ gh ext list\r\nno installed extensions found\r\n\r\n$ GH_DEBUG=true gh extensions install .\r\n\r\n$ gh ext list\r\nNAME               REPO  VERSION\r\ngh workflow-stats        \r\n\r\n$ gh workflow-stats -h\r\nfailed to run extension: fork/exec /home/ivan/.local/share/gh/extensions/gh-workflow-stats/gh-workflow-stats: no such file or directory\r\n\r\n$ ls -la /home/ivan/.local/share/gh/extensions/gh-workflow-stats\r\nlrwxrwxrwx 1 ivan ivan 47 Oct 15 13:26 /home/ivan/.local/share/gh/extensions/gh-workflow-stats -> <some-path>/gh-workflow-stats\r\n```\r\n</BODY>"
+  - name: 'not spam, #9759 (https://github.com/cli/cli/issues/9759)'
+    expected: PASS
+    input: "<TITLE>\nCan't install forked extension\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nI have forked an [extension](https://github.com/IvanRibakov/gh-workflow-stats) and made some improvements. While waiting for the PR to the upstream repo to be reviewed/merged I'd like to share my progress with my colleagues, however I'm unable to install the extension from my fork.\r\n\r\n```\r\ngh version 2.54.0 (2024-08-01)\r\nhttps://github.com/cli/cli/releases/tag/v2.54.0\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\nI have tried following commands:\r\n\r\n```\r\n$ gh extensions install IvanRibakov/gh-workflow-stats\r\n$ gh extensions install IvanRibakov/gh-workflow-stats --force\r\n$ gh extensions install IvanRibakov/gh-workflow-stats --force --pin f2286ac\r\n```\r\n\r\nbut all of them return the same cryptic error message:\r\n```\r\nextension is not installable: missing executable\r\n```\r\n\r\n### Expected vs actual behavior\r\n\r\nExpecting to be able to install an extension from a public fork of a public repo while being able to install the extension from the upstream without issues, instead getting a non-descriptive error.\r\n\r\n### Logs\r\n\r\n<details><summary>Logs</summary>\r\n<p>\r\n\r\n```\r\n$ GH_DEBUG=api gh extensions install https://github.com/IvanRibakov/gh-workflow-stats --pin f2286ac --force\r\n* Request at 2024-10-15 13:12:09.106395563 +0200 CEST m=+0.050985944\r\n* Request to https://api.github.com/repos/IvanRibakov/gh-workflow-stats/releases/latest\r\n> GET /repos/IvanRibakov/gh-workflow-stats/releases/latest HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\r\n> Authorization: token ████████████████████\r\n> Content-Type: application/json; charset=utf-8\r\n> Time-Zone: Europe/Madrid\r\n> User-Agent: GitHub CLI 2.54.0\r\n> X-Gh-Cache-Ttl: 30s\r\n\r\n⢿< HTTP/2.0 404 Not Found\r\n< Access-Control-Allow-Origin: *\r\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\r\n< Content-Security-Policy: default-src 'none'\r\n< Content-Type: application/json; charset=utf-8\r\n< Date: Tue, 15 Oct 2024 11:12:14 GMT\r\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\r\n< Server: github.com\r\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\r\n< Vary: Accept-Encoding, Accept, X-Requested-With\r\n< X-Accepted-Oauth-Scopes: repo\r\n< X-Content-Type-Options: nosniff\r\n< X-Frame-Options: deny\r\n< X-Github-Api-Version-Selected: 2022-11-28\r\n< X-Github-Media-Type: github.v3; param=merge-info-preview.nebula-preview; format=json\r\n< X-Github-Request-Id: 9D5A:37C4BC:D9552DD:DCC2930:670E4E0E\r\n< X-Oauth-Scopes: delete:packages, read:org, repo, workflow, write:packages\r\n< X-Ratelimit-Limit: 5000\r\n< X-Ratelimit-Remaining: 4955\r\n< X-Ratelimit-Reset: 1728991844\r\n< X-Ratelimit-Resource: core\r\n< X-Ratelimit-Used: 45\r\n< X-Xss-Protection: 0\r\n\r\n\r\n{\r\n  \"message\": \"Not Found\",\r\n  \"documentation_url\": \"https://docs.github.com/rest/releases/releases#get-the-latest-release\",\r\n  \"status\": \"404\"\r\n}\r\n\r\n* Request took 5.302112651s\r\n* Request at 2024-10-15 13:12:14.408536288 +0200 CEST m=+5.353126669\r\n* Request to https://api.github.com/repos/IvanRibakov/gh-workflow-stats\r\n> GET /repos/IvanRibakov/gh-workflow-stats HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\r\n> Authorization: token ████████████████████\r\n> Content-Type: application/json; charset=utf-8\r\n> Time-Zone: Europe/Madrid\r\n> User-Agent: GitHub CLI 2.54.0\r\n> X-Gh-Cache-Ttl: 30s\r\n\r\n...\r\n\r\n{\r\n  ...\r\n  \"name\": \"gh-workflow-stats\",\r\n  \"full_name\": \"IvanRibakov/gh-workflow-stats\",\r\n  \"private\": false,\r\n  ...\r\n}\r\n\r\n* Request took 254.775396ms\r\n* Request at 2024-10-15 13:12:14.663345618 +0200 CEST m=+5.607935989\r\n* Request to https://api.github.com/repos/IvanRibakov/gh-workflow-stats/contents/gh-workflow-stats\r\n> GET /repos/IvanRibakov/gh-workflow-stats/contents/gh-workflow-stats HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\r\n> Authorization: token ████████████████████\r\n> Content-Type: application/json; charset=utf-8\r\n> Time-Zone: Europe/Madrid\r\n> User-Agent: GitHub CLI 2.54.0\r\n> X-Gh-Cache-Ttl: 30s\r\n\r\n⣾< HTTP/2.0 404 Not Found\r\n< Access-Control-Allow-Origin: *\r\n< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset\r\n< Content-Security-Policy: default-src 'none'\r\n< Content-Type: application/json; charset=utf-8\r\n< Date: Tue, 15 Oct 2024 11:12:14 GMT\r\n< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin\r\n< Server: github.com\r\n< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload\r\n< Vary: Accept-Encoding, Accept, X-Requested-With\r\n< X-Accepted-Oauth-Scopes: \r\n< X-Content-Type-Options: nosniff\r\n< X-Frame-Options: deny\r\n< X-Github-Api-Version-Selected: 2022-11-28\r\n< X-Github-Media-Type: github.v3; param=merge-info-preview.nebula-preview; format=json\r\n< X-Github-Request-Id: 9D5A:37C4BC:D95549D:DCC2AE7:670E4E0E\r\n< X-Oauth-Scopes: delete:packages, read:org, repo, workflow, write:packages\r\n< X-Ratelimit-Limit: 5000\r\n< X-Ratelimit-Remaining: 4953\r\n< X-Ratelimit-Reset: 1728991844\r\n< X-Ratelimit-Resource: core\r\n< X-Ratelimit-Used: 47\r\n< X-Xss-Protection: 0\r\n\r\n{\r\n  \"message\": \"Not Found\",\r\n  \"documentation_url\": \"https://docs.github.com/rest/repos/contents#get-repository-content\",\r\n  \"status\": \"404\"\r\n}\r\n\r\n* Request took 282.202949ms\r\nextension is not installable: missing executable\r\n```\r\n\r\n</p>\r\n</details> \n</BODY>"
+  - name: 'not spam, #9758 (https://github.com/cli/cli/issues/9758)'
+    expected: PASS
+    input: "<TITLE>\n`gh secret set` intermittently returning 503 errors\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nInside a GitHub workflow running on `ubuntu-latest` ([currently pointing at 24.04](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md), GitHub CLI version 2.58.0), `gh secret set` is intermittently returning `HTTP 503: Secrets service unavailable`\r\n\r\nThis behaviour began on October 1st 2024, the same workflow was previously always completing successfully (and has intermittently completed successfully since).\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Set up a GitHub workflow that loops through a number of repos running `gh secret set <SECRET_NAME> --body <SECRET_VALUE> --repo <REPO_NAME>` on each\r\n2. View the intermittent output `failed to set secret \"<SECRET_NAME>\": HTTP 503: Secrets service unavailable`\r\n\r\n### Expected vs actual behavior\r\n\r\nThe workflow should complete successfully. Intermittently, it does, but regularly it fails with the above error, but not at the same point each time.\r\n</BODY>"
+  - name: 'not spam, #9749 (https://github.com/cli/cli/issues/9749)'
+    expected: PASS
+    input: "<TITLE>\n`gh search` commands returns duplicate data when `--limit` greater than 100 but not a multiple of 100\n</TITLE>\n\n<BODY>\n```console\r\n% gh --version   \r\ngh version 2.58.0 (2024-10-01)\r\nhttps://github.com/cli/cli/releases/tag/v2.58.0\r\n% gh -R brave/brave-core search prs --limit 256 --merged --merged-at \">$(date -I -d '1 month ago')\" --base=master --json number -q '.[].number'|wc -l\r\n256\r\n% gh -R brave/brave-core search prs --limit 256 --merged --merged-at \">$(date -I -d '1 month ago')\" --base=master --json number -q '.[].number'|sort -u|wc -l\r\n200\r\n% gh -R brave/brave-core search prs --limit 275 --merged --merged-at \">$(date -I -d '1 month ago')\" --base=master --json number -q '.[].number'|wc -l\r\n275\r\n% gh -R brave/brave-core search prs --limit 275 --merged --merged-at \">$(date -I -d '1 month ago')\" --base=master --json number -q '.[].number'|sort -u|wc -l\r\n225\r\n% gh -R brave/brave-core search prs --limit 300 --merged --merged-at \">$(date -I -d '1 month ago')\" --base=master --json number -q '.[].number'|wc -l        \r\n241\r\n% gh -R brave/brave-core search prs --limit 300 --merged --merged-at \">$(date -I -d '1 month ago')\" --base=master --json number -q '.[].number'|sort -u|wc -l\r\n241\r\n%\r\n```\n</BODY>"
+  - name: 'not spam, #9746 (https://github.com/cli/cli/issues/9746)'
+    expected: PASS
+    input: "<TITLE>\nThe ability to retrieve a repo's archived timestamp.\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nOur technical oversight committee (TOC) would like to better identify, notify and make requests to our user community when one of our third party artifacts has been archived by its maintainer.  An artifact is tied to a repo.  Knowing that an artifact has been archived is insufficient since it does not mean the artifact is useless  The user community should know when it was archived so they can make their own decision if some other person wants to start maintaining the artifact for the general community, stop using the artifact or make their own fork for the artifact.  The TOC also want to display and sort by the archive timestamp when displaying the various artifacts on web pages.\r\n\r\nAs an artifact ages, the TOC can make requests to the community if they believe the artifact should continue being maintained or even dropped.\r\n\r\nThe GH command has most of of the information we need to automate this process, but it was missing the archived timestamp.\r\n\r\n### Proposed solution\r\n\r\nWhen you go to the home page of an archived repo, the date is displayed when the repo was archived.   We would like to retrieve that same date through the GH command.  The same useful information displayed on the repo's main page would also be available through the GH command.\r\n\r\nCurrently we can retrieve the archive status using the json variable isArchived.   \r\n\r\n`gh repo view --json isArchived <repo>`\r\n\r\nThe proposed solution would be to add a new variable for the archive timestamp.\r\n\r\n`gh repo view --json isArchived,archivedAt <repo>`\r\n</BODY>"
+  - name: 'not spam, #9741 (https://github.com/cli/cli/issues/9741)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh at verify` should retry requests after getting a `5xx`
+      </TITLE>
+
+      <BODY>
+      A user recently reached out and made us aware of the following scenario:
+
+      While performing a call to `gh at verify`, which reaches out to GitHub's API, we had a blip of availability. A single request failed, for whatever reason, and returned a 500. `gh at verify` then immediately error'ed out within a few milliseconds, seemingly without any attempts at retrying the request.
+
+      As far as we can tell, given our monitoring of our services, had `gh at verify` retried the request then the command would have succeeded. Consequently,
+
+      - `gh at verify` should retry requests that return with a 500
+      - probably with some jittery backoff
+      - up to a certain threshold (10s? 30s?)
+
+      If this were a server component, I'd confidently say "exponential backoff for up to 5 minutes". But given that `gh` is more human oriented, as I write this I'm unsure of whether we should make the retry exponential/last that long. 30s is a long time to hang without feedback to the user.
+
+      I assume there is ample prior art within `gh`, and I will next go looking for it.
+      </BODY>
+  - name: 'not spam, #9734 (https://github.com/cli/cli/issues/9734)'
+    expected: PASS
+    input: "<TITLE>\nSupport paginating `gh search code`\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nRight now there is a max limit of 1000 results upon using `gh search code` can we add a way to paginate/offset to get more results after the initial batch?\r\n\r\n### Proposed solution\r\n\r\nAdd a --page flag to allow setting the page field in https://docs.github.com/en/rest/search/search?apiVersion=2022-11-28#constructing-a-search-query. That way I could run a search, get the first 1000, then run it with page=2 to get the next page of results.\r\n\r\nHow will it benefit CLI and its users?\r\n\r\nWithout this, there isn't an easy way to directly paginate code search results.\r\n\r\n### Additional context\r\n\r\nAdd any other context like screenshots or mockups are helpful, if applicable.\r\n\r\nAn alternative solution is to allow the limit to be larger than 1000 and internally to the command, move along the pages to return a valid combined output.\r\n</BODY>"
+  - name: 'not spam, #9704 (https://github.com/cli/cli/issues/9704)'
+    expected: PASS
+    input: "<TITLE>\nSupport searching gists\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nI use gists for a lot of one-offs: showing people examples of something, storing my own https://play.rust-lang.org gists (so you can edit them), and so much more. The number is untenable, but GitHub offers no way to search them while limiting to some scope e.g., user. I would like a way to search them, and I think others might as well (hence not going straight to an extension).\r\n\r\n### Proposed solution\r\n\r\nAdd `gh gist search` with options to search all (default), `--public`, or `--secret` (mirroring `gh gist list`), and to \"grep\" just the description, file names, or file contents. A GraphQL query will be built to pull only what is needed, but search will page through all gists.\r\n\r\nExamples:\r\n\r\n```bash\r\ngh gist search 'foo' # find all gists with \"foo\" in the description\r\ngh gist search 'foo?' --public --filename # find all public gists with \"fo\" or \"foo\" in the description or filenames\r\ngh gist search 'foo|bar' --secret --filename --code # find all secret gists with \"foo\" or \"bar\" in the description, filenames, or file content\r\n```\r\n\r\nHere I use `--filename` and `--code` to mirror some other command parameters in `gh` already. I think we should support regex from the start using Go's package (not great - no look-arounds, IIRC - but decent) so people aren't hampered when searching for code and don't request it later, creating a possible compatibility issue down the road.\r\n\r\nBecause the web site already has a search, I'm initially thinking this is scoped to a user. By default, it's effectively `@me` but you could pass `--author {name}` to scope to a different author's gists. IMO, we shouldn't error if `--secret` is specified since we tightly couple the code but could. The service won't return any results.\r\n\r\nAs for rendered output, this gets trickier. Ideally, `gist search` would show highlights of the search pattern; however, with the current table format of `gist list` we can't show multiple file names and certainly not content. Showing multiple file/names for possibly multiple gists would be hard to read. We could mimic the output of `gh search code` but add another level like:\r\n\r\n```\r\n{gist ID}  {gist description}\r\n  {filename}\r\n    {first or all found search pattern with a line or two above and below for context}\r\n```\r\n\r\nOf course, we'd have to handle highlighting the matches and context lines. Not hard, but starts to bloat the CLI even more.\r\n\r\nInstead, we could just list the gists that contain the pattern found in whatever options they specify. They could use existing `gist` commands to view more. At least in my use cases, I generally know what I'm looking for - and always put a decent description in to help find things - to showing the gist ID and description would satisfy my use case. Curious about others'.\r\n\r\n#### Alternative\r\n\r\nAlternatively, we could add a `gist` subcommand to `gh search` but I know from experience in the code that all the plumbing for `search` is very different from what this command would do, so it may not be worth it. At the very least, it would completely bifurcate the code path.\r\n\r\n### Additional context\r\n\r\nCurrently, `gh gist list | grep 'something'` is about as close as you can get and that will only search the view fields you return including the ID (repo name, which is a GUID; and useless to search), the description, and other fields that are useless to search.\r\n</BODY>"
+  - name: 'not spam, #9699 (https://github.com/cli/cli/issues/9699)'
+    expected: PASS
+    input: "<TITLE>\nLocal extensions can override core commands\n</TITLE>\n\n<BODY>\n### Describe the bug\n\n1. Local extensions (`gh ext install .`) with the same name as core commands can be installed.\n2. Once installed, if the evaluation order of commands and alias happens to result in the selection of the extension, the extension overrides the core commands.\n\nExtensions installed from a remote GitHub repository do not exhibit this same behavior and are properly validated.\n\n### Steps to reproduce the behavior\n\nThis reproduces better from a clean installation with no aliases or extensions installed.\n\nThis can be reproduced in a `cli/cli` codespace to avoid mucking with your local `gh` installation:\n\n```shell\n# build the CLI or install it from elsewhere\nmake\n# For convenience:\ngh_path=\"/workspaces/cli/bin/gh\"\n# We need to delete any default aliases to reproduce core command overriding \n$gh_path alias delete co\n# Create an extension, install it, then run it to demonstrate command overriding\n$gh_path ext create pr && cd gh-pr && $gh_path ext install . && $gh_path pr\n```\n\n### Expected vs actual behavior\n\n**Current behavior:**\n\n- Extension that overrides a core command or alias can be installed\n- Extension can then be executed instead of a core command in certain conditions\n\n```shell\n\n$gh_path ext create pr && cd gh-pr && $gh_path ext install . && $gh_path pr\n✓ Created directory gh-pr\n✓ Initialized git repository\n✓ Made initial commit\n✓ Set up extension scaffolding\n\ngh-pr is ready for development!\n\nNext Steps\n- run 'cd gh-pr; gh extension install .; gh pr' to see your new extension in action\n- run 'gh repo create' to share your extension with others\n\nFor more information on writing extensions:\nhttps://docs.github.com/github-cli/github-cli/creating-github-cli-extensions\n                         # < --------- No complaints from installation command\nHello gh-pr!             # < --------- Core command has been overridden\n```\n\n**Expected behavior:**\n\n- Fail to install extension that overrides a core command or alias.\n\n```                   \n\"pr\" matches the name of a built-in command or alias\n```\n</BODY>"
+  - name: 'not spam, #9698 (https://github.com/cli/cli/issues/9698)'
+    expected: PASS
+    input: "<TITLE>\nCreating an issue with a blank title should be validated locally before sending\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nI accidentally selected a blank title for an issue I was writing. I spent a while working on the body of the issue in another editor before attempting to submit it. Once done, the submission failed. This is frustrating since I lost about 5 mins of effort writing my bug report.\r\n\r\n```sh\r\n❯  gh issue new\r\n\r\nCreating issue in NicksPatties/sweet\r\n\r\n? Title\r\n? Choose a template Bug report\r\n? Body <Received>\r\n? What's next? Submit\r\n\r\nX operation failed. To restore: gh issue create --recover /tmp/gh3317933051.json\r\n\r\nGraphQL: Title can't be blank (createIssue)\r\n\r\n```\r\n\r\n### Proposed solution\r\n\r\nIf the text of the title is blank, have the cli present an error, and ask the user to try again.\r\n\r\n```sh\r\n? Title # <presses Enter>\r\nX Title cannot be blank. \r\n? Title # <user types in a title>\r\n# ...\r\n```\r\n\r\nAdditionally, make it clear that the title is required in some way.\r\n\r\n```sh\r\n? Title (required) # user types the title here\r\n# ...\r\n</BODY>"
+  - name: 'not spam, #9694 (https://github.com/cli/cli/issues/9694)'
+    expected: PASS
+    input: "<TITLE>\ngh api: reports incorrect default branch for a repository\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n`gh api` command may report incorrect default branch for the repository [standardebooks/charles-dickens_the-pickwick-papers](https://github.com/standardebooks/charles-dickens_the-pickwick-papers).\r\n\r\n```\r\n> gh --version\r\ngh version 2.58.0 (2024-10-01)\r\nhttps://github.com/cli/cli/releases/tag/v2.58.0\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Type this:\r\n\r\n```\r\n> gh api repos/standardebooks/charles-dickens_the-pickwick-papers --jq \".default_branch\"\r\n```\r\n\r\n2. View the output:\r\n\r\nThe output is either `master` or `main`.\r\n\r\n### Expected vs actual behavior\r\n\r\nThe output should always be `master` only, as seen from the [repository branch list](https://github.com/standardebooks/charles-dickens_the-pickwick-papers/branches/all).\r\n\r\nThe problem is not always immediately reproducible, and may require to run the `gh api` command several times from different geographic locations (e.g. several times from the USA IP, then several times from the Netherlands IP, and so on).\r\n</BODY>"
+  - name: 'not spam, #9668 (https://github.com/cli/cli/issues/9668)'
+    expected: PASS
+    input: "<TITLE>\ngh pr merge <number> -d -m does not appear to prune remote references\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nThe pr merge command of the gh cli does not appear to prune the remote references with `--delete-branch` option.\r\nHad to `git remote prune origin` explicitly.\r\n\r\n```\r\n% gh --version\r\ngh version 2.57.0 (2024-09-16)\r\nhttps://github.com/cli/cli/releases/tag/v2.57.0\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Type this 'gh pr merge 11 -d -m'\r\n2. View the output 'Deleted remote branch <branch-name>'\r\n3. See error 'git log still shows the remote reference'\r\n\r\n### Expected vs actual behavior\r\n\r\nDeleted local and remote branch as was expected, but does not remove the remote references.  Can be worked around using explicit invocation `git remote prune origin`.\r\n\r\n### Logs\r\n\r\n```\r\n% git log\r\n...\r\ncommit <commit-sha> (origin/<branch-name>)\r\n...\r\n```\r\n\r\n<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->\r\n</BODY>"
+  - name: 'not spam, #9665 (https://github.com/cli/cli/issues/9665)'
+    expected: PASS
+    input: "<TITLE>\nAllow specifying that you don't want `gh auth login` to open a browser with web login\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nWhen using `gh` on WSL, previously `gh auth login` would fail to resolve a browser, and print out the URL (github.com/login/device) as a fallback for me to manually enter. I actually didn't mind this behavior. But now I see that it's resolving to `www-browser`, which, for me (perhaps it's a WSL default) resolves to `w3m`. I'm sure some people are very happy to log in with `w3m`, but I am *not* one of those people :laughing: I'd rather just copy+paste a URL from my WSL terminal to my browser running in Windows.\r\n\r\n### Proposed solution\r\n\r\nA new flag, like `--no-browser` (or a `--no-web` counterpart to `--web`?), should be sufficient. Or the series of prompts could somehow allow the user to specify between \"Login with a web browser (open)\" vs \"Login with a browser (manual)\". This would allow users who would rather *not* have a browser automatically open to copy+paste the URL.\r\n\r\n### Additional context\r\n\r\nAs a current workaround I'm running `BROWSER=none gh auth login` to force an error when opening the URL, to get it to print the URL to the console.\r\n\r\nFor WSL, I could add `chrome.exe` to `PATH` and set `[GH_]BROWSER` to that, but I think it would still be nice to be able to tell the CLI to just print out the URL and let me decide what to do with it.\r\n\r\nEdit: Or I could've just installed `wslview`, which I've somehow been completely unaware of for years :sweat_smile:\n</BODY>"
+  - name: 'not spam, #9641 (https://github.com/cli/cli/issues/9641)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Replace "GitHub Enterprise Server" option with "other" in `gh auth login` prompting
+      </TITLE>
+
+      <BODY>
+      ## Description
+
+      Currently, when proceeding through an interactive `gh auth login` flow, the user is presented with two options:
+
+      ```
+      ➜  gh auth login
+      ? What account do you want to log into?  [Use arrows to move, type to filter]
+      > GitHub.com
+        GitHub Enterprise Server
+      ```
+
+      However, the login flow offered by the "GitHub Enterprise Server" selection works for any hostname - not just GitHub Enterprise Server customers. We think it would be better to work with users by the domain names they know:
+
+      ```
+      ➜  gh auth login
+      ? Where do you use GitHub? [Use arrows to move, type to filter]
+        github.com
+      > other
+
+      ? Hostname:
+      ```
+
+      ## Acceptance Criteria
+
+      **Given** I am in an interactive terminal environment
+      **When** I run `gh auth login`
+      **Then** I am presented with:
+
+      ```
+      ➜  gh auth login
+      ? Where do you use GitHub? [Use arrows to move, type to filter]
+        github.com
+      > other
+
+      ? Hostname:
+      ```
+
+      This change should be reflected in our docs
+      </BODY>
+  - name: 'not spam, #9637 (https://github.com/cli/cli/issues/9637)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      `gh attestation trusted-root` not tenant-aware when `--tuf-url` flag supplied
+      </TITLE>
+
+      <BODY>
+      ### Describe the bug
+
+      When invoking the `gh attestation trusted-root` command, the `--hostname` and `--tuf-url` flag cannot be used together.
+
+      The `--hostname` flag is supposed to ensure that the tenant-specific trusted-root is returned. This works as-expected when the `--tuf-url` flag is omitted (defaulting to the default TUF repository), but doesn't NOT work when a `--tuf-url` value is supplied that points to a non-default TUF repository.
+
+      The following code should be replicated for the case where the `--tuf-url` flag is supplied:
+      https://github.com/cli/cli/blob/trunk/pkg/cmd/attestation/trustedroot/trustedroot.go#L141-L144
+      </BODY>
+  - name: 'not spam, #9614 (https://github.com/cli/cli/issues/9614)'
+    expected: PASS
+    input: "<TITLE>\n`gh attestation trusted-root` requires  auth\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nThe `gh attestation trusted-root` command does an auth check despite the fact that it doesn't interact with an GH APIs.\n\n### Steps to reproduce the behavior\n\nRun `gh attestation trusted-root` from a GH Actions workflow without providing an auth token. \n\n### Expected vs actual behavior\n\nWhen running in GH Actions, you may see an error like the following:\n\n```\ngh: To use GitHub CLI in a GitHub Actions workflow, set the GH_TOKEN environment variable. Example:\n  env:\n    GH_TOKEN: ${{ github.token }}\nError: Process completed with exit code 4.\n```\n\nSince this command doesn't actually interact with any GH APIs, there is no reason to force a token to be present.\n</BODY>"
+  - name: 'not spam, #9613 (https://github.com/cli/cli/issues/9613)'
+    expected: PASS
+    input: "<TITLE>\n`gh attestation verify` partially suppresses output when no TTY present\n</TITLE>\n\n<BODY>\n### Describe the bug\n\nThe `gh attestation verify` command displays partial output when running in an environment with no TTY.\n\n### Steps to reproduce the behavior\n\nRun `gh attestation verify` in a GH Actions workflow\n\n### Expected vs actual behavior\n\nThe output will looking something like the following:\n\n```\nactions/attest-build-provenance\thttps://slsa.dev/provenance/v1\t.github/workflows/prober.yml@refs/heads/main\n```\n\nThis is just a portion of the normal output when a TTY is present:\n\n```\nLoaded digest sha256:d4b1e5cbc005e80684a73826a62ee81ea63a81f26c2df4d5a1a64d89cf386d06 for file:///Users/bdehamer/Downloads/artifact\nLoaded 1 attestation from /Users/bdehamer/Downloads/actions-attest-build-provenance-attestation-2032782.sigstore.json\n✓ Verification succeeded!\n\nsha256:d4b1e5cbc005e80684a73826a62ee81ea63a81f26c2df4d5a1a64d89cf386d06 was attested by:\nREPO                             PREDICATE_TYPE                  WORKFLOW                                    \nactions/attest-build-provenance  https://slsa.dev/provenance/v1  .github/workflows/prober.yml@refs/heads/main\n```\n\nIf some of the output is going to be suppressed in a no-TTY environment, ALL of the output should be suppressed.\n</BODY>"
+  - name: 'not spam, #9602 (https://github.com/cli/cli/issues/9602)'
+    expected: PASS
+    input: "<TITLE>\nadd `gh attestation verify` options `--ref` and `--commit`\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\n`gh attestations verify ...` allows the user to verify various properties in the attestation, such as the source repo with `--repo` and the signing workflow with `--signer-repo`. You can also verify the signing workflow's ref with `--cert-identity`.\r\n\r\nThe problem is that there may be many artifacts that come from a source repo, so I can't easily be sure if the artifact came from approved changes, in the case of protected mainline branches or tags. Furthermore, verifying the source commit sha will allow me to pinpoint the exact code that produced the artifact.\r\n\r\n### Proposed solution\r\n\r\nI would like for be able to verify the source repo's ref, and also the source repo's commit sha, so I can easily be more sure about my received artifacts:\r\n\r\n* `--ref`\r\n* `--commit`\r\n\r\nWhile we are making these changes, we may also add:\r\n\r\n* `signer-ref`\r\n* `signer-commit`\r\n\r\n### Additional context\r\n\r\nMy current solution is cumbersome, involving `--jq` and piping to `grep`:\r\n\r\n```shell\r\nSOURCE_REPO=\"ramonpetgrave/github-build-attestations-rw\"\r\nSOURCE_REF=\"refs/heads/main\"\r\nSIGNER_WORKFLOW_CERT_IDENTITY=\"https://github.com/ramonpetgrave/github-build-attestations-rw/.github/workflows/attest-build-provenance-slsa3-rw.yml@refs/heads/dev\"\r\ngh attestation verify $ARTIFACT_PATH \\\r\n    --deny-self-hosted-runners \\\r\n    --repo \"$SOURCE_REPO\"  \\\r\n    --cert-identity \"$SIGNER_WORKFLOW_CERT_IDENTITY\" \r\n    --format json --jq '.[].verificationResult.signature.certificate.sourceRepositoryRef' \\\r\n| grep \"^$SOURCE_REF$\"\r\n```\r\n</BODY>"
+  - name: 'not spam, #9592 (https://github.com/cli/cli/issues/9592)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Extension installation on macOS machines with Apple Silicon does not make it clear when extension installation fails because Rosetta is not installed
+      </TITLE>
+
+      <BODY>
+      When installing an extension, the CLI must to select the correct binary to download for the machine (see the [`installBin` function](https://github.com/cli/cli/blob/78c1d00eccac1b2ae82ac0bfeea3e2292c98056a/pkg/cmd/extension/manager.go#L240)).
+
+      By default, the CLI will download a binary matching the current machine's architecture.
+
+      However, to provide better support for Macs running on Apple Silicon, it will [fall back](https://github.com/cli/cli/blob/78c1d00eccac1b2ae82ac0bfeea3e2292c98056a/pkg/cmd/extension/manager.go#L267-L274) from `darwin-arm64` to `darwin-amd64` if [Rosetta](https://support.apple.com/en-gb/102527) (Apple's compatibility layer) is installed.
+
+      If Rosetta isn't installed, this fallback doesn't happen, which can lead to surprising and confusing results when one Mac has Rosetta and another doesn't, because the extension will install on one machine but not another.
+
+      I would propose that we **return a specific error message suggesting that the user installs Rosetta** where:
+
+      * a `darwin-arm64` binary is not available
+      * a `darwin-amd64` binary is available
+      * Rosetta is not installed
+
+      ### Steps to reproduce the behavior
+
+      1. Try to install an extension without a `darwin-arm64` binary on a Mac with Apple Silicon which doesn't have Rosetta installed:
+
+      ```bash
+      gh extension install github/gh-gei
+      ```
+
+      2. Installation fails with an error
+
+      ```
+      gh-gei unsupported for darwin-arm64. Open an issue: `gh issue create -R github/gh-gei -t'Support darwin-arm64'`
+      ```
+
+      3. Try the same thing on an Apple Silicon Mac with Rosetta installed, and installation succeeds
+      </BODY>
+  - name: 'not spam, #9590 (https://github.com/cli/cli/issues/9590)'
+    expected: PASS
+    input: |-
+      <TITLE>
+      Improve `gh attestation verify` output to include commit SHA for full artifact verification
+      </TITLE>
+
+      <BODY>
+      The `gh attestation verify` subcommand currently only displays the workflow ref, which includes the tag name. This approach does not ensure full traceability because a tag can be forcibly moved to a different commit after artifact generation. For improved verification of build authority for attested artifacts, the output table should also include the commit SHA. This addition would allow users to confirm that the artifact was produced by the workflow run tied to a specific commit, addressing the potential issue of tag manipulation.
+      </BODY>
+  - name: 'not spam, #9588 (https://github.com/cli/cli/issues/9588)'
+    expected: PASS
+    input: "<TITLE>\nThe `--json` flag should have no arguments and instead print all columns\n</TITLE>\n\n<BODY>\n# CLI Feedback\r\n\r\nThe usage of the `--json` is bad. I don't have the columns memorized. I don't want to type in the names of the columns. I just want to pipe the output into `jq` on my own. It is not helpful for `gh` to embed `jq` into `gh`. I know how to use pipes.\r\n\r\nBetter yet, I just need to filter the output of a command based on the value of a column. But I want to see all of the fields. Why do I have to specify all of the fields manually on each invocation?\r\n\r\n## What have you loved?\r\n\r\n`gh` exists.\r\n\r\n## What was confusing or gave you pause?\r\n\r\nThe `--json` flag is unintuitive and requires that I manually enter all the fields I need. This is backwards. It should output all of the fields and then I can use `jq` locally on my own.\r\n\r\nIn the command `❯ gh pr checks 1234` I can't filter easily by the bucket. I just want to see the checks that failed. How do I do that?\r\n\r\n`❯ gh pr checks 1234 -R myorg/myrepo --json bucket -q '.[] | select( .bucket == \"fail\" )'`?\r\n\r\nNo. That doesn't tell me anything except the number of failures. Even then, I'd have to count them with my human eyeballs.\r\n\r\nI just want to see the output in table form but just the ones that failed. I don't want to go in and find the column names that I need. I don't want to type them out to select them and then type them out AGAIN to filter for them. I don't find it useful that `gh` has embeded support for `jq`. I am using the GitHub cli, is that not proof enough that I'm comfortable with the command line that I will know how to pipe the output into `jq` myself?\r\n\r\n## Are there features you'd like to see added?\r\n\r\n`--json` should be a flag, not an option. In other words, it should just work without adding column names. Just dump the JSON and let me handle it the way I normally handle JSON.\r\n\r\n## Anything else?\r\n\r\nI appreciate that you listen to feedback.\r\n</BODY>"
+  - name: 'not spam, #9586 (https://github.com/cli/cli/issues/9586)'
+    expected: PASS
+    input: "<TITLE>\nadd a option for gh release create to resovle secondary rate limit\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nI have a GitHub Actions https://github.com/fpliu1214/uppm-package-repository-android-31-aarch64/actions/runs/10763510085/job/29870722353#step:5:838\r\n\r\nIt releases a large number of tarball files, It report me:\r\n\r\n```\r\nHTTP 403: You have exceeded a secondary rate limit. Please wait a few minutes before you try again. If you reach out to GitHub Support for help, please include the request ID E941:23D214:C4C22B:DC7B0C:66DEDF90. (https://uploads.github.com/repos/fpliu1214/uppm-package-repository-android-31-aarch64/releases/174109892/assets?label=&name=libcares-1.31.0-android-31-arm64-v8a.tar.xz)\r\n```\r\n\r\nI read the docs from https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#pause-between-mutative-requests\r\n\r\nThe document say:\r\n\r\n```\r\n[Pause between mutative requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#pause-between-mutative-requests)\r\nIf you are making a large number of POST, PATCH, PUT, or DELETE requests, wait at least one second between each request. This will help you avoid secondary rate limits.\r\n```\r\n\r\nBut I didn't find a option to archive this.  https://cli.github.com/manual/gh_release_create \r\n\r\nCould you add a option to archive this?\r\n</BODY>"
+  - name: 'not spam, #9583 (https://github.com/cli/cli/issues/9583)'
+    expected: PASS
+    input: "<TITLE>\nOutput of `gh pr view PR --json mergeable` incorrect\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nThe value of the `mergeable` JSON field returned from `gh pr view PR --json mergeable` is incorrect and does not match the `.mergeable_state` returned by the `/repos/:owner/:repo/pulls/:pr` API.\r\n\r\n```\r\n$ gh pr view 634 --json mergeable\r\n{\r\n  \"mergeable\": \"MERGEABLE\"\r\n}\r\n$ gh api /repos/euc-eng/entitlement-service/pulls/634 | jq .mergeable_state\r\n\"blocked\"\r\n$\r\n```\r\n\r\nVersion used\r\n```\r\n$ gh --version\r\ngh version 2.54.0 (2024-07-31)\r\nhttps://github.com/cli/cli/releases/tag/v2.54.0\r\n$\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. Grab the PR number of a PR with failing rules check(s)\r\n2. Type `gh pr view $PR --json mergeable` (replace $PR with the PR number)\r\n3. Type `gh api /repos/:owner/:repo/pulls/:pr | jq .mergeable_state` (replacing `:owner`, `:repo`, and `:pr` with valid values)\r\n4. Compare the output of the two previous commands\r\n5. (optional) View the PR on github.com, checking if Merge button is green/enabled.\r\n\r\n### Expected vs actual behavior\r\n\r\nThe output of `gh pr view $PR --json mergeable` and `gh api /repos/:owner/:repo/pulls/:pr | jq .mergeable_state` should match and should align with state of the Merge button for PR on github.com.\r\n\r\n### Logs\r\n\r\nN/A\r\n</BODY>"
+  - name: 'not spam, #9562 (https://github.com/cli/cli/issues/9562)'
+    expected: PASS
+    input: "<TITLE>\nUpdate GPG key used to sign Debian and RPM packages before Sept 6, 2024 expiration\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nThe GPG key used for signing Debian packages is expiring on September 6th (2 days from now):\r\n\r\n```\r\nwget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg | gpg --show-keys\r\npub   rsa4096 2022-09-06 [SC] [expires: 2024-09-06]\r\n      2C6106201985B60E6C7AC87323F3D4EA75716059\r\nuid                      GitHub CLI <opensource+cli@github.com>\r\nsub   rsa4096 2022-09-06 [E] [expires: 2024-09-06]\r\n```\r\n\r\nThe last time it was resolved after it expired in https://github.com/cli/cli/issues/6175\r\n\r\n### Proposed solution\r\n\r\nUpdate the signing key to avoid issues installing `gh` from Ubuntu/Debian.\n</BODY>"
+  - name: 'not spam, #9499 (https://github.com/cli/cli/issues/9499)'
+    expected: PASS
+    input: "<TITLE>\nMore consistent `gh repo sync` stdout\n</TITLE>\n\n<BODY>\nIn `gh` v2.55.0 (2024-08-20), the stdout given by `gh repo sync` ([manual page](https://cli.github.com/manual/gh_repo_sync)) are formed differently, when used to syncing remote fork from its parent and syncing local repository from remote parent.\r\n\r\n```shell\r\n$ cd /path/to/my/fork/of/cli\r\n\r\n# sync remote fork from its parent\r\n$ gh repo sync muzimuzhi/cli\r\n✓ Synced the \"muzimuzhi:trunk\" branch from \"cli:trunk\"\r\n\r\n# sync local from remote\r\ngh repo sync\r\n✓ Synced the \"trunk\" branch from cli/cli to local repository\r\n```\r\n\r\nThe first observation is, in the output of `gh repo sync`, the name of repo (here `cli/cli`) is not double-quoted.\r\n```diff\r\n ✓ Synced the \"muzimuzhi:trunk\" branch from \"cli:trunk\"\r\n-✓ Synced the \"trunk\" branch from cli/cli to local repository\r\n+✓ Synced the \"trunk\" branch from \"cli/cli\" to local repository\r\n```\r\n\r\nTo make the two messages more aligned, the output of `gh repo sync` can be further reworded to be\r\n```diff\r\n ✓ Synced the \"muzimuzhi:trunk\" branch from \"cli:trunk\"\r\n-✓ Synced the \"trunk\" branch from cli/cli to local repository\r\n+✓ Synced the \"trunk\" local branch from \"cli/cli:trunk\"\r\n```\r\n</BODY>"
+  - name: 'not spam, #9492 (https://github.com/cli/cli/issues/9492)'
+    expected: PASS
+    input: "<TITLE>\nXDG_CACHE_HOME doesn't work on sigstore cache path\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\ngh ignore `XDG_CACHE_HOME`, force create `~/.cache/gh/.sigstore/root`\r\n\r\n- `gh version 2.55.0 (2024-08-20)`\r\n- `macos 14.6.1`\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. set `XDG_CACHE_HOME=\"~/Library/Caches\"`\r\n2. run `gh at verify xx` \r\n3. `~/.cache/gh/.sigstore/root` was created\n</BODY>"
+  - name: 'not spam, #9470 (https://github.com/cli/cli/issues/9470)'
+    expected: PASS
+    input: "<TITLE>\n`gh pr create -w` doesn't print absolute URI to stdout\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nWhen you run `gh pr create -w` it prints a URI without the scheme:\r\n\r\n```text\r\nTo https://github.com/owner/repo.git\r\n * [new branch]          HEAD -> branch\r\nbranch 'branch' set up to track 'origin/branch'.\r\nOpening github.com/owner/repo/compare/main...branch in your browser.\r\n```\r\n\r\nIf the browser isn't opened automatically - as is the case by default in WSL without something like wslview installed - you can't `Ctrl+Click` the URI because it doesn't have a scheme.\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. In WSL without wslview, or without wslview set the old hack `export BROWSER=explorer.exe`.\r\n2. Run `gh pr create -w`\r\n3. Windows Explorer opens - not the browser - and the URI in the stdout message above isn't clickabke, at least in VSCode's integrated terminal (which is conpty that Windows Terminal uses as well).\r\n\r\n### Expected vs actual behavior\r\n\r\nLike many (most?) other commands, the scheme should be prefaced before the URI.\r\n</BODY>"
+  - name: 'not spam, #9469 (https://github.com/cli/cli/issues/9469)'
+    expected: PASS
+    input: "<TITLE>\nConfusing behavior when `BRANCH` is a non-existent branch in `gh issue develop -b BRANCH ISSUE`\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n```console\r\n$ gh --version\r\ngh version 2.54.0 (2024-08-01)\r\nhttps://github.com/cli/cli/releases/tag/v2.54.0\r\n```\r\n\r\nI mistakenly used `-b` instead of `-n` to specify the name of the branch to create. Naturally, the branch doesn't exist, so the argument passed for `-b` is invalid. However, the command completes successfully, seemingly using the primary branch as the base. While my confusion was mixing up `-b` and `-n`, the deeper issue is that `-b` accepts branches that don't exist.\r\n\r\n### Steps to reproduce the behavior\r\n\r\n`gh issue develop -b does-not-exist-on-remote 1`\r\n\r\n### Expected vs actual behavior\r\n\r\nInstead of falling back to using the primary branch as the base for the development branch, I would expect to get an error saying something like \"branch `does-no-exist-on-remote` does not exist on the remote\".\r\n</BODY>"
+  - name: 'not spam, #9464 (https://github.com/cli/cli/issues/9464)'
+    expected: PASS
+    input: "<TITLE>\n`gh repo create` asks if I want to create an `Internal` repository for an owner that doesn't support such things\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n```\r\ngh --version\r\ngh version 2.54.0 (2024-07-31)\r\nhttps://github.com/cli/cli/releases/tag/v2.54.0\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\n```\r\n% gh repo create\r\n? What would you like to do? Create a new repository on GitHub from scratch\r\n? Repository name test-internal\r\n? Repository owner jsoref\r\n? Description test creating an internal repository when gh knows this is not allowed\r\n```\r\n\r\n```\r\n? Visibility  [Use arrows to move, type to filter]\r\n  Public\r\n  Private\r\n> Internal\r\n```\r\n\r\n```\r\n? Visibility Internal\r\n? Would you like to add a README file? No\r\n? Would you like to add a .gitignore? No\r\n? Would you like to add a license? No\r\n? This will create \"test-internal\" as a internal repository on GitHub. Continue? Yes\r\nGraphQL: Only organization-owned repositories can have internal visibility (createRepository)\r\n```\r\n### Expected vs actual behavior\r\n\r\nDon't show `Internal` as an option if the owner doesn't support it\r\n\r\n### Logs\r\n\r\n```\r\n> POST /graphql HTTP/1.1\r\n> Host: api.github.com\r\n> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview\r\n> Authorization: token ████████████████████\r\n> Content-Length: 85\r\n> Content-Type: application/json\r\n> Graphql-Features: merge_queue\r\n> Time-Zone: America/Toronto\r\n> User-Agent: GitHub CLI 2.54.0\r\n\r\n{\r\n  \"query\": \"query UserCurrent{viewer{login,organizations(first: 100){nodes{login}}}}\"\r\n}\r\n\r\n< HTTP/2.0 200 OK\r\n...\r\n{\r\n  \"data\": {\r\n    \"viewer\": {\r\n      \"login\": \"jsoref\",\r\n      \"organizations\": {\r\n        [\r\n...\r\n        ]\r\n      }\r\n    }\r\n  }\r\n}\r\n```\r\n\r\n</BODY>"
+  - name: 'not spam, #9450 (https://github.com/cli/cli/issues/9450)'
+    expected: PASS
+    input: "<TITLE>\n`gh config` manual: lines with `|` rendered as tables\n</TITLE>\n\n<BODY>\nSee https://cli.github.com/manual/gh_config\r\n\r\nThe line is supposed to be:\r\n\r\n- `git_protocol`: the protocol to use for git clone and push operations {https|ssh} (default https)\r\n\r\nBut instead rendered as:\r\n\r\n- <table><tbody><tr><td><code>git_protocol</code>: the protocol to use for git clone and push operations {https</td><td>ssh} (default https)</td></tr></tbody></table>\r\n\r\nI didn't thoroughly check every command so there might be other pages with this issue.\r\n</BODY>"
+  - name: 'not spam, #9449 (https://github.com/cli/cli/issues/9449)'
+    expected: PASS
+    input: "<TITLE>\n\"Download for Mac\" button on https://cli.github.com/ downloads wrong binary\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n### Steps to reproduce the behavior\r\n\r\nGo to https://cli.github.com/ , click \"Download for Mac\" on macOS in Chrome on an Apple Silicon machine.\r\n\r\n### Expected vs actual behavior\r\n\r\nExpected: Downloads a binary I can run on Apple Silicon without having Rosetta installed.\r\n\r\nActual: Downloads the amd64 binary, which can't run.\r\n\r\nhttps://github.com/cli/cli/releases/tag/v2.54.0 does have both arm64 and universal binaries which work, it's just that the homepage doesn't link to them.\r\n\r\nBrowsers on macOS (at least Safari and Chrome) always claim in the user agent that the machine is x86_64, even on Apple Silicon, for privacy reasons. Maybe you're looking at the arch in the user agent and link to the matching thin binary. That doesn't work on mac – maybe just link to the universal binary from the home page instead of to the amd64 one?\n</BODY>"
+  - name: 'not spam, #9440 (https://github.com/cli/cli/issues/9440)'
+    expected: PASS
+    input: "<TITLE>\nFeature request: Add a gh command to set the default owner\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nRe-opening #5213 as it was closed but the feature does not exist.\r\n\r\nI'd like to be able to set the default owner or user that some commands assume, so that I can easily do:\r\n\r\n```\r\ngh repo clone blah\r\n```\r\n\r\nwithout having to do \r\n\r\n```\r\ngh repo clone org/blah\r\n```\r\n\r\n...when 99% of the time on this device I'm working in the org.\r\n\r\n### Proposed solution\r\n\r\nThis will save typing!\r\n\r\n### Additional context\r\n\r\n#5213 was closed based on a linked proposal that was closed by a PR, but the PR was to add `gh status` - which doesn't support setting the default organisation or owner. So it was closed incorrectly. I've commented there but comments on closed PRs are hard to see \U0001F601 \n</BODY>"
+  - name: 'not spam, #9434 (https://github.com/cli/cli/issues/9434)'
+    expected: PASS
+    input: "<TITLE>\nAllow passing an `--active` flag to `gh auth status`\n</TITLE>\n\n<BODY>\nRight now, when you do `gh auth status`, it can output multiple accounts, only one of which is active:\r\n\r\n```\r\n% gh auth status\r\ngithub.com\r\n  ✓ Logged in to github.com account tjschuck (GITHUB_TOKEN)\r\n  - Active account: true\r\n  - Git operations protocol: https\r\n  - Token: ghp_************************************\r\n  - Token scopes: 'notifications', 'read:org', 'repo', 'workflow'\r\n\r\n  ✓ Logged in to github.com account tjschuck (keyring)\r\n  - Active account: false\r\n  - Git operations protocol: https\r\n  - Token: gho_************************************\r\n  - Token scopes: 'gist', 'read:org', 'read:packages', 'repo', 'workflow'\r\n```\r\n\r\nIdeally, you'd be able to do something like `gh auth status --active` to get _only_ the active account listing.  This is useful if you want to, for example, check the current scopes available for the active token.\n</BODY>"
+  - name: 'not spam, #9420 (https://github.com/cli/cli/issues/9420)'
+    expected: PASS
+    input: "<TITLE>\nView and edit repo autolink references \n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nGitHub repos provide an [autolink feature](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources) to reference external resources from PR descriptions and other markdown fields. Autolink configuration is [exposed](https://docs.github.com/en/rest/repos/autolinks) via the GitHub REST API, but not via this CLI.\r\n\r\n### Proposed solution\r\n\r\nI propose adding repo autolink reference CRUD features to the `gh repo` command.\r\n\r\n### Additional context\r\n\r\nI'd be happy to attempt the implementation of this feature myself. I'm posting it as an issue to understand whether such a feature is desired and if so whether there might be some non-obvious challenges to its implementation. \n</BODY>"
+  - name: 'not spam, #9398 (https://github.com/cli/cli/issues/9398)'
+    expected: PASS
+    input: "<TITLE>\n`gh repo set-default --view` breaks Unix standards - returns exit code 0 upon failure and prints error to stdout instead of stderr\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\nGitHub CLI command `gh repo set-default --view` returns exit code 0 and prints error to stdout instead of stderr when the default repo isn't set.\r\n\r\nThis breaks Unix command line standard behaviour and makes it hard to detect and script around error handling and recovery.\r\n\r\n```\r\n$ gh --version\r\ngh version 2.42.1 (2024-01-15)\r\nhttps://github.com/cli/cli/releases/tag/v2.42.1\r\n```\r\n\r\nI've tried with the newer version too, same result:\r\n\r\n```shell\r\n$ gh --version\r\ngh version 2.53.0 (2024-07-17)\r\nhttps://github.com/cli/cli/releases/tag/v2.53.0\r\n\r\n```\r\n\r\n### Steps to reproduce the behavior\r\n\r\nIn a repo clone, especially a forked repo:\r\n\r\n```shell\r\ngh repo set-default --view\r\necho $?\r\n```\r\n\r\noutputs:\r\n\r\n```\r\nno default repository has been set; use `gh repo set-default` to select one\r\n0\r\n```\r\n\r\nYou can see it outputs to stdout in place where the repo name would be expected. This will easily break the scripts of people expecting standard unix command line behaviour:\r\n\r\n```shell\r\ngh repo set-default --view 2>/dev/null\r\n```\r\n\r\noutputs to stdout instead of stderr:\r\n\r\n```\r\nno default repository has been set; use `gh repo set-default` to select one\r\n```\r\n\r\nalthough in a pipe this actually returns no output which is slightly easier to catch in script than testing for an error message which might change:\r\n\r\n```shell\r\ngh repo set-default --view | cat\r\n```\r\n\r\nreturns no output:\r\n\r\n### Expected vs actual behavior\r\n\r\nExpected it to exit code 1 if throwing an error such as `no default repository has been set`\r\n\r\nExpected it to print the error to stderr instead of stdout.\n</BODY>"
+  - name: 'not spam, #9397 (https://github.com/cli/cli/issues/9397)'
+    expected: PASS
+    input: "<TITLE>\nAdd instructions to install gh with Flox\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nI'd like to be able to install `gh` through Flox, and manage its version together with that of other packages in my development environment.\r\n\r\n### Proposed solution\r\n\r\n`flox install gh`\r\nThis would allow me to add the `.flox` directory in my git repo, and share it with my colleagues, to ensure we're all using the same version of `gh` and accompanying packages.\r\n\r\n</BODY>"
+  - name: 'not spam, #9390 (https://github.com/cli/cli/issues/9390)'
+    expected: PASS
+    input: "<TITLE>\npr checks returns failure code if there are no checks\n</TITLE>\n\n<BODY>\n### Describe the bug\r\n\r\n\r\nThe help describes `pr checks` as\r\n> Show CI status for a single pull request.\r\n\r\nFrom that description, I expect that it returns an error code if there are failed checks, maybe an error code if there are pending checks, and 0 for all checks successful.\r\n\r\nI do not expect it to fail when there are no checks, because there is no negative CI status\r\n\r\ngh version 2.53.0 (2024-07-17)\r\n\r\n### Steps to reproduce the behavior\r\n\r\n1. On a PR with no checks, run `gh pr checks`\r\n2. return code is 1\r\n\r\n### Expected vs actual behavior\r\nreturn code of 0\r\n\r\n### Proposed solution\r\nDocument return codes in the help\r\nLooks like\r\n* 8: pending checks\r\n* 0: all checks passed\r\n* 1: no checks\r\n* 1: failed check\r\n\r\nSeparate return code for no checks and failed check\r\n\r\nIt would be cool if no checks returned 0, but as long as I can separate it from failed checks without grep I'm okay\r\n\r\n### workaround\r\n```\r\nif (gh pr checks 2>&1 || true) | grep -qE \"^All checks were successful|^no checks reported\" ; then\r\n    ...\r\nfi\r\n```\n</BODY>"
+  - name: 'not spam, #9383 (https://github.com/cli/cli/issues/9383)'
+    expected: PASS
+    input: "<TITLE>\nMake `gh secret` set selected repositories without re-defining the value\n</TITLE>\n\n<BODY>\n### Describe the feature or problem you’d like to solve\r\n\r\nI need to manage my organization secrets and I want to update the selected repositories.\r\n\r\nKind of how it's done with the dedicated REST API:\r\nhttps://docs.github.com/en/rest/actions/secrets?apiVersion=2022-11-28#set-selected-repositories-for-an-organization-secret (but with repository names instead of IDs)\r\n\r\nAt the moment when skipping  `--body`\r\n\r\n```sh\r\ngh secret set MY_SECRET --org my-org --visibility selected --repos repo1,repo2\r\n```\r\n\r\nit read from reads from standard input:\r\n\r\n```txt\r\n? Paste your secret:\r\n```\r\n\r\n### Proposed solution\r\n\r\nHow will it benefit CLI and its users?\r\n\r\nWe can add an extra tag that tells the CLI not to touch the previous secret value at all:\r\n\r\n```sh\r\ngh secret set MY_SECRET --org my-org --keep-previous-body --visibility selected --repos repo1,repo2\r\n```\r\n\r\nNot sure about the `-keep-previous-body` tag name.\r\n\r\nBut for sure I think it will be cumbersome to add an extra `gh secret` command for that.\r\n\r\n### Additional context\r\n\r\nMay be related to:\r\n- https://github.com/cli/cli/issues/6327\r\n\r\n</BODY>"

From 43e163481640812190b46fe0d6b8d510897dfd6c Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 21:01:34 +0100
Subject: [PATCH 02/14] ci: add spam issue detection workflow

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .github/workflows/detect-spam.yml | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 .github/workflows/detect-spam.yml

diff --git a/.github/workflows/detect-spam.yml b/.github/workflows/detect-spam.yml
new file mode 100644
index 000000000..9559e3e0e
--- /dev/null
+++ b/.github/workflows/detect-spam.yml
@@ -0,0 +1,28 @@
+name: Spam Issue Detection
+on:
+  issues:
+    types: [opened]
+
+permissions:
+  contents: none
+  issues: write
+
+jobs:
+  issue-spam:
+    runs-on: ubuntu-latest
+    environment: cli-automation
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+      - name: Run spam detection
+        env:
+          GH_REPO: ${{ github.repository }}
+          GH_TOKEN: ${{ secrets.AUTOMATION_TOKEN }}
+          ISSUE_URL: ${{ github.event.issue.url }}
+          ISSUE_AUTHOR: ${{ github.event.issue.user.login }}
+        run: |
+          ./.github/workflows/scripts/spam-detection/process-issue.sh "$ISSUE_URL"
+          if [[ $? -ne 0 ]]; then
+            echo "error processing issue"
+            exit 1
+          fi

From e90336a33143d51c6215a4a7f9834face082b566 Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 21:20:12 +0100
Subject: [PATCH 03/14] ci: remove unused env vars

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .github/workflows/detect-spam.yml | 2 --
 1 file changed, 2 deletions(-)

diff --git a/.github/workflows/detect-spam.yml b/.github/workflows/detect-spam.yml
index 9559e3e0e..f622580dd 100644
--- a/.github/workflows/detect-spam.yml
+++ b/.github/workflows/detect-spam.yml
@@ -16,10 +16,8 @@ jobs:
         uses: actions/checkout@v4
       - name: Run spam detection
         env:
-          GH_REPO: ${{ github.repository }}
           GH_TOKEN: ${{ secrets.AUTOMATION_TOKEN }}
           ISSUE_URL: ${{ github.event.issue.url }}
-          ISSUE_AUTHOR: ${{ github.event.issue.user.login }}
         run: |
           ./.github/workflows/scripts/spam-detection/process-issue.sh "$ISSUE_URL"
           if [[ $? -ne 0 ]]; then

From 1447400c0afbd347f98d7e98f529b727d7fb75f4 Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 21:46:36 +0100
Subject: [PATCH 04/14] ci: use `issue.html_url` instead of `issue.url`

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .github/workflows/detect-spam.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/detect-spam.yml b/.github/workflows/detect-spam.yml
index f622580dd..91835f008 100644
--- a/.github/workflows/detect-spam.yml
+++ b/.github/workflows/detect-spam.yml
@@ -17,7 +17,7 @@ jobs:
       - name: Run spam detection
         env:
           GH_TOKEN: ${{ secrets.AUTOMATION_TOKEN }}
-          ISSUE_URL: ${{ github.event.issue.url }}
+          ISSUE_URL: ${{ github.event.issue.html_url }}
         run: |
           ./.github/workflows/scripts/spam-detection/process-issue.sh "$ISSUE_URL"
           if [[ $? -ne 0 ]]; then

From 7996a6cdb93208280e25b70e89170b7054fb623f Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 21:53:44 +0100
Subject: [PATCH 05/14] ci: fix potentially confusing typo in system prompt

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .github/workflows/scripts/spam-detection/generate-sys-prompt.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh b/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
index 76c104946..99c994c3d 100755
--- a/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
+++ b/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
@@ -67,7 +67,7 @@ Here are the common patterns of spam issues:
 - Promotional content, advertisements, or unrelated marketing material.
 - Content in languages that seem inappropriate for the project context.
 - Issues that don''t relate to the project''s purpose (e.g. personal messages, off-topic discussions).
-- Content that seems like to be taken from, or quoting, another discussion or issue which does not not establish a sensible
+- Content that seems like to be taken from, or quoting, another discussion or issue which does not establish a sensible
   context, or problem statement, or feedback.
 
 '

From 9aae4a525d947f320405fe7c8ec04454bde02ea7 Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 21:54:02 +0100
Subject: [PATCH 06/14] docs: fix typo in script docs

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .github/workflows/scripts/spam-detection/process-issue.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/scripts/spam-detection/process-issue.sh b/.github/workflows/scripts/spam-detection/process-issue.sh
index f64aee31c..a83e329cc 100755
--- a/.github/workflows/scripts/spam-detection/process-issue.sh
+++ b/.github/workflows/scripts/spam-detection/process-issue.sh
@@ -1,6 +1,6 @@
 #!/bin/bash
 
-# Performs spam detection on an issue and labels if if it's spam.
+# Performs spam detection on an issue and labels it if it's spam.
 #
 # Regardless of the spam detection result, the script always exits with a zero
 # exit code, unless there's a runtime error.

From 1779103a04ab165443e75eb94f07bfb3e59ca566 Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 21:57:33 +0100
Subject: [PATCH 07/14] ci: correct `sed` usage to remove Markdown front matter

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .github/workflows/scripts/spam-detection/generate-sys-prompt.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh b/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
index 99c994c3d..a85f2d6f4 100755
--- a/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
+++ b/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
@@ -107,7 +107,7 @@ for template_file in .github/ISSUE_TEMPLATE/*.md; do
     _template_content="$(cat "$template_file")"
 
     # Remove YAML front matter (everything between the first two --- lines)
-    _template_content="$(echo "$_template_content" | sed '1,/^---$/d; /^---$/,$d')"
+    _template_content="$(echo "$_template_content" | sed '/^---$/,/^---$/d')"
     _escaped_template="$(sed -e 's/^```/\\```/g' <<< "$_template_content" )"
 
     _system_prompt="${_system_prompt}

From 6a5fbdd44ffcd6945bd750558e9ac1423dc83853 Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 22:31:31 +0100
Subject: [PATCH 08/14] ci: add `models: read` permission

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .github/workflows/detect-spam.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.github/workflows/detect-spam.yml b/.github/workflows/detect-spam.yml
index 91835f008..3e8c4a618 100644
--- a/.github/workflows/detect-spam.yml
+++ b/.github/workflows/detect-spam.yml
@@ -6,6 +6,7 @@ on:
 permissions:
   contents: none
   issues: write
+  models: read
 
 jobs:
   issue-spam:

From 8a235ecbef090f0bc9810c77f931afb87e695afc Mon Sep 17 00:00:00 2001
From: "Babak K. Shandiz" <babakks@github.com>
Date: Wed, 16 Jul 2025 22:41:26 +0100
Subject: [PATCH 09/14] ci: echo spam detection result

Signed-off-by: Babak K. Shandiz <babakks@github.com>
---
 .github/workflows/scripts/spam-detection/process-issue.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/scripts/spam-detection/process-issue.sh b/.github/workflows/scripts/spam-detection/process-issue.sh
index a83e329cc..f65cb47e8 100755
--- a/.github/workflows/scripts/spam-detection/process-issue.sh
+++ b/.github/workflows/scripts/spam-detection/process-issue.sh
@@ -21,10 +21,11 @@ _check_issue_script=".github/workflows/scripts/spam-detection/check-issue.sh"
 _result="$($_check_issue_script "$_issue_url")"
 
 if [[ "$_result" == "PASS" ]]; then
+    echo "detected as not-spam: $_issue_url"
     exit 0
 fi
 
-echo "spam issue detected: $_issue_url"
+echo "detected as spam: $_issue_url"
 
 gh issue edit --add-label "$_suspected_spam_label" "$_issue_url"
 

From 8610d8ba8acf261143029969a9001b1d1396a29b Mon Sep 17 00:00:00 2001
From: Andy Feller <andyfeller@github.com>
Date: Mon, 21 Jul 2025 15:01:22 -0400
Subject: [PATCH 10/14] First pass to optimize and improve

---
 .../spam-detection/check-issue-prompts.yml    |  7 +++++
 .../scripts/spam-detection/check-issue.sh     | 29 ++++++++++---------
 .../{prompt.yml => eval-prompts.yml}          | 26 ++++++++---------
 .../workflows/scripts/spam-detection/eval.sh  | 14 +++++----
 4 files changed, 44 insertions(+), 32 deletions(-)
 create mode 100644 .github/workflows/scripts/spam-detection/check-issue-prompts.yml
 rename .github/workflows/scripts/spam-detection/{prompt.yml => eval-prompts.yml} (99%)

diff --git a/.github/workflows/scripts/spam-detection/check-issue-prompts.yml b/.github/workflows/scripts/spam-detection/check-issue-prompts.yml
new file mode 100644
index 000000000..b6728c7c1
--- /dev/null
+++ b/.github/workflows/scripts/spam-detection/check-issue-prompts.yml
@@ -0,0 +1,7 @@
+name: Detect spam
+model: openai/gpt-4o-mini
+messages:
+  - role: system
+    content: "" # Since it's not a fix value, it should be generated and replaced at runtime
+  - role: user
+    content: "" # This will be replaced at runtime
diff --git a/.github/workflows/scripts/spam-detection/check-issue.sh b/.github/workflows/scripts/spam-detection/check-issue.sh
index d2c60d8fe..9f3ca1a54 100755
--- a/.github/workflows/scripts/spam-detection/check-issue.sh
+++ b/.github/workflows/scripts/spam-detection/check-issue.sh
@@ -9,10 +9,11 @@
 
 set -euo pipefail
 
-_prompt_file=".github/workflows/scripts/spam-detection/prompt.yml"
-_generate_sys_prompt_script=".github/workflows/scripts/spam-detection/generate-sys-prompt.sh"
-_generate_prompt_script=".github/workflows/scripts/spam-detection/generate-prompt.sh"
+# Determine absolute path to script directory based on where it is called from.
+# This allows the script to be run from any directory.
+SPAM_DIR="$(dirname "$(realpath "$0")")"
 
+# Retrieve and prepare information about issue for detection
 _issue_url="$1"
 if [[ -z "$_issue_url" ]]; then
     echo "error: issue URL is empty" >&2
@@ -21,21 +22,23 @@ fi
 
 _issue="$(gh issue view --json title,body "$_issue_url")"
 
-_issue_body="$(jq -r ".body" <<< "$_issue")"
-_issue_title="$(jq -r ".title" <<< "$_issue")"
+cat << EOF | _user_prompt
+<TITLE>
+$(jq -r ".title" <<< "$_issue")
+</TITLE>
 
-_system_prompt="$($_generate_sys_prompt_script)"
-_input_prompt="$($_generate_prompt_script "$_issue_title" "$_issue_body")"
+<BODY>
+$(jq -r ".body" <<< "$_issue")
+</BODY>
+EOF
 
-_updated_prompt_file_content="$(
-    cat "$_prompt_file" |
-    yq eval 'del(.testData, .evaluators)' | # drop test data
-    _system="$_system_prompt" _input="$_input_prompt" yq eval ".messages[0].content = strenv(_system) | .messages[1].content = strenv(_input)"
-)"
+# Generate dynamic prompts for inference
+_system_prompt="$($SPAM_DIR/generate-sys-prompt.sh)"
+_final_prompt="$(_system="$_system_prompt" _user="$_user_prompt" yq eval ".messages[0].content = strenv(_system) | .messages[1].content = strenv(_user)" "$SPAM_DIR/check-issue-prompts.yml")"
 
 gh extension install github/gh-models 2>/dev/null
 
-_result="$(gh models run --file <(echo "$_updated_prompt_file_content") | cat)"
+_result="$(gh models run --file <(echo "$_final_prompt") | cat)"
 
 if [[ "$_result" != "PASS" && "$_result" != "FAIL" ]]; then
     echo "error: expected PASS or FAIL but got an unexpected result: $_result" >&2
diff --git a/.github/workflows/scripts/spam-detection/prompt.yml b/.github/workflows/scripts/spam-detection/eval-prompts.yml
similarity index 99%
rename from .github/workflows/scripts/spam-detection/prompt.yml
rename to .github/workflows/scripts/spam-detection/eval-prompts.yml
index 2b6f0c738..be7efddfc 100644
--- a/.github/workflows/scripts/spam-detection/prompt.yml
+++ b/.github/workflows/scripts/spam-detection/eval-prompts.yml
@@ -4,7 +4,7 @@ messages:
   - role: system
     content: "" # Since it's not a fix value, it should be generated and replaced at runtime
   - role: user
-    content: "{{input}}"
+    content: "{{input}}" # This will be replaced by `gh models eval` from `testData` below
 evaluators:
   - name: assert response
     string:
@@ -27,11 +27,11 @@ testData:
       > ```yaml
       > name: Dependabot fetch metadata
       > on: pull_request
-      > 
+      >
       > permissions:
       >   pull-requests: write
       >   issues: write
-      > 
+      >
       > jobs:
       >   dependabot:
       >     runs-on: ubuntu-latest
@@ -160,7 +160,7 @@ testData:
       <BODY>
       ### Describe the bug
 
-      A clear and concise description of what the bug is. 
+      A clear and concise description of what the bug is.
 
       ### Affected version
 
@@ -193,7 +193,7 @@ testData:
       <BODY>
       ### Describe the bug
 
-      A clear and concise description of what the bug is. 
+      A clear and concise description of what the bug is.
 
       ### Affected version
 
@@ -224,10 +224,10 @@ testData:
       </TITLE>
 
       <BODY>
-      > Thanks for submitting this, @brettdh! 🙏 
-      > 
+      > Thanks for submitting this, @brettdh! 🙏
+      >
       > Currently, this is similar to the GraphQL API request that `gh` uses to fetch the list of releases:
-      > 
+      >
       > ```gql
       > query {
       >   repository(owner:"cli", name:"cli") {
@@ -246,12 +246,12 @@ testData:
       >   }
       > }
       > ```
-      > 
+      >
       > You can simply try it on [GraphQL Explorer](https://docs.github.com/en/graphql/overview/explorer).
-      > 
+      >
       > There's a bit of terminology difference here, but I think what you're referring to as *notes* is actually the `description` field on a `Release` type. Can you please confirm that's what you're asking for? You can try adding `description` to the list of fields in the above query and see if that fits your purpose.
-      > 
-      >  
+      >
+      >
 
       _Originally posted by @babakks in [#11241](https://github.com/cli/cli/issues/11241#issuecomment-3049268353)_
       </BODY>
@@ -263,7 +263,7 @@ testData:
       </TITLE>
 
       <BODY>
-      ###I believe there might be a bug or just looking for work jobid 
+      ###I believe there might be a bug or just looking for work jobid
 
       Maybe theirs problem in the with log fails
 
diff --git a/.github/workflows/scripts/spam-detection/eval.sh b/.github/workflows/scripts/spam-detection/eval.sh
index f4a5dc0f7..21dd26db8 100755
--- a/.github/workflows/scripts/spam-detection/eval.sh
+++ b/.github/workflows/scripts/spam-detection/eval.sh
@@ -6,16 +6,18 @@
 
 set -euo pipefail
 
-_prompt_file=".github/workflows/scripts/spam-detection/prompt.yml"
-_generate_sys_prompt_script=".github/workflows/scripts/spam-detection/generate-sys-prompt.sh"
+# Determine absolute path to script directory based on where it is called from.
+# This allows the script to be run from any directory.
+SPAM_DIR="$(dirname "$(realpath "$0")")"
 
-_system_prompt="$($_generate_sys_prompt_script)"
-_updated_prompt_file="$(_value="$_system_prompt" yq eval '.messages[0].content = strenv(_value)' "$_prompt_file")"
+# Generate dynamic prompts for inference
+_system_prompt="$($SPAM_DIR/generate-sys-prompt.sh)"
+_final_prompt="$(_value="$_system_prompt" yq eval '.messages[0].content = strenv(_value)' $SPAM_DIR/eval-prompts.yml)"
 
 # We should be able to just run the following command:
 #
 # ```
-# gh models eval <(echo "$_updated_prompt_file")
+# gh models eval <(echo "$_final_prompt")
 # ```
 #
 # But since `gh-models` does not throttle the rate of API requests, we need to
@@ -23,4 +25,4 @@ _updated_prompt_file="$(_value="$_system_prompt" yq eval '.messages[0].content =
 # Here, we assume a binary of the `gh-models` extension (with appropriate
 # throttling) is available in the root directory of the repository and we're
 # calling it directly (not though `gh`).
-./gh-models eval <(echo "$_updated_prompt_file")
+gh models eval <(echo "$_final_prompt")

From 03cc1d83113922aa5cd7632ad8a15ccb1d51f858 Mon Sep 17 00:00:00 2001
From: Andy Feller <andyfeller@github.com>
Date: Mon, 21 Jul 2025 15:21:01 -0400
Subject: [PATCH 11/14] Remove unnecessary file for heredoc

---
 .../scripts/spam-detection/generate-prompt.sh | 23 -------------------
 1 file changed, 23 deletions(-)
 delete mode 100755 .github/workflows/scripts/spam-detection/generate-prompt.sh

diff --git a/.github/workflows/scripts/spam-detection/generate-prompt.sh b/.github/workflows/scripts/spam-detection/generate-prompt.sh
deleted file mode 100755
index 9437bf751..000000000
--- a/.github/workflows/scripts/spam-detection/generate-prompt.sh
+++ /dev/null
@@ -1,23 +0,0 @@
-#!/bin/bash
-
-# Generate the prompt for the spam detection AI model. The issue title and body
-# should be provided as arguments.
-#
-# This script must be run from the root directory of the repository.
-
-set -euo pipefail
-
-_issue_title="$1"
-_issue_body="$2"
-
-_prompt="
-<TITLE>
-$_issue_title
-</TITLE>
-
-<BODY>
-$_issue_body
-</BODY>
-"
-
-echo "$_prompt"

From f7448c10e69fc8bae05f1d00abd578d1f128a792 Mon Sep 17 00:00:00 2001
From: Andy Feller <andyfeller@github.com>
Date: Mon, 21 Jul 2025 15:26:35 -0400
Subject: [PATCH 12/14] Update eval script comments

---
 .github/workflows/scripts/spam-detection/eval.sh | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/.github/workflows/scripts/spam-detection/eval.sh b/.github/workflows/scripts/spam-detection/eval.sh
index 21dd26db8..4bf8b08fe 100755
--- a/.github/workflows/scripts/spam-detection/eval.sh
+++ b/.github/workflows/scripts/spam-detection/eval.sh
@@ -14,15 +14,8 @@ SPAM_DIR="$(dirname "$(realpath "$0")")"
 _system_prompt="$($SPAM_DIR/generate-sys-prompt.sh)"
 _final_prompt="$(_value="$_system_prompt" yq eval '.messages[0].content = strenv(_value)' $SPAM_DIR/eval-prompts.yml)"
 
-# We should be able to just run the following command:
+# The following `gh models eval` command will fail after 20 requests due to rate limits.
+# We are going to open up an issue in `github/gh-models` to address this.
 #
-# ```
-# gh models eval <(echo "$_final_prompt")
-# ```
-#
-# But since `gh-models` does not throttle the rate of API requests, we need to
-# modify the extension code and introduce a deliberate delay between the runs.
-# Here, we assume a binary of the `gh-models` extension (with appropriate
-# throttling) is available in the root directory of the repository and we're
-# calling it directly (not though `gh`).
+# TODO: break up `eval-prompts.yml` file into smaller batches to avoid hitting the rate limit.
 gh models eval <(echo "$_final_prompt")

From 0c105aff8a70e6beeba9d4d4302edea117bad2c6 Mon Sep 17 00:00:00 2001
From: Andy Feller <andyfeller@github.com>
Date: Mon, 21 Jul 2025 15:51:48 -0400
Subject: [PATCH 13/14] Use gh go templating for user prompt

`gh` has Go templating support built in, so let's use it.
---
 .../workflows/scripts/spam-detection/check-issue.sh  | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/scripts/spam-detection/check-issue.sh b/.github/workflows/scripts/spam-detection/check-issue.sh
index 9f3ca1a54..2f82eb4ea 100755
--- a/.github/workflows/scripts/spam-detection/check-issue.sh
+++ b/.github/workflows/scripts/spam-detection/check-issue.sh
@@ -20,17 +20,17 @@ if [[ -z "$_issue_url" ]]; then
     exit 1
 fi
 
-_issue="$(gh issue view --json title,body "$_issue_url")"
-
-cat << EOF | _user_prompt
+_user_prompt_template='
 <TITLE>
-$(jq -r ".title" <<< "$_issue")
+{{ .title }}
 </TITLE>
 
 <BODY>
-$(jq -r ".body" <<< "$_issue")
+{{ .body }}
 </BODY>
-EOF
+'
+
+_user_prompt="$(gh issue view --json title,body --template "$_user_prompt_template" "$_issue_url")"
 
 # Generate dynamic prompts for inference
 _system_prompt="$($SPAM_DIR/generate-sys-prompt.sh)"

From aa955e1fe6bd5419b8510e59c8933aa448e149e6 Mon Sep 17 00:00:00 2001
From: Andy Feller <andyfeller@github.com>
Date: Mon, 21 Jul 2025 15:56:11 -0400
Subject: [PATCH 14/14] Update
 .github/workflows/scripts/spam-detection/generate-sys-prompt.sh

---
 .github/workflows/scripts/spam-detection/generate-sys-prompt.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh b/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
index a85f2d6f4..ca4eb480d 100755
--- a/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
+++ b/.github/workflows/scripts/spam-detection/generate-sys-prompt.sh
@@ -38,7 +38,7 @@ Your response must be single word `FAIL` if the issue looks like a spam, and `PA
 The GitHub CLI (also known as `gh`) project is a command-line tool for GitHub. It provides many commands to interact
 with various GitHub features.
 
-You can find a the general docs of the GitHub CLI tool in section "GitHub CLI docs" below, which helps you understand
+You can find the GitHub CLI tool documentation in the "GitHub CLI docs" section below, which helps you understand
 the available commands and their usages.
 
 ## Legitimate content indicators