@@ -19,7 +19,7 @@ jobs:
       }}
     runs-on: ubuntu-latest
     steps:
-      - name: Close the pull request if a linked issue lacks the help wanted label
+      - name: Close the pull request if a linked issue opened by someone else lacks the help wanted label
         uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
         with:
           script: |
@@ -31,8 +31,14 @@ jobs:
                 repository(owner: $owner, name: $repo) {
                   pullRequest(number: $number) {
                     state
+                    author {
+                      login
+                    }
                     closingIssuesReferences(first: 100) {
                       nodes {
+                        author {
+                          login
+                        }
                         labels(first: 100) {
                           nodes {
                             name
@@ -61,11 +67,13 @@ jobs:
               return
             }
 
+            const pullRequestAuthor = pullRequest.author?.login?.toLowerCase()
             const issuesWithoutHelpWanted = closingIssues.filter(issue =>
-              !issue.labels.nodes.some(label => label.name.toLowerCase() === 'help wanted'),
+              !issue.labels.nodes.some(label => label.name.toLowerCase() === 'help wanted') &&
+              (!pullRequestAuthor || issue.author?.login?.toLowerCase() !== pullRequestAuthor),
             )
             if (!issuesWithoutHelpWanted.length) {
-              console.log('Every linked issue has the help wanted label')
+              console.log('Every linked issue has the help wanted label or was opened by the pull request author')
               return
             }
 
 
@@ -3,7 +3,7 @@ apiVersion: v1
 kind: Service
 metadata:
   annotations:
-    moda.github.net/allowed-ips: 23.235.32.0/20,43.249.72.0/22,103.244.50.0/24,103.245.222.0/23,103.245.224.0/24,104.156.80.0/20,140.248.64.0/18,140.248.128.0/17,146.75.0.0/17,151.101.0.0/16,157.52.64.0/18,167.82.0.0/17,167.82.128.0/20,167.82.160.0/20,167.82.224.0/20,172.111.64.0/18,185.31.16.0/22,199.27.72.0/21,199.232.0.0/16
+    moda.github.net/allowed-ips: 23.235.32.0/20,43.249.72.0/22,90.98.0.0/17,90.98.128.0/18,103.244.50.0/24,103.245.222.0/23,103.245.224.0/24,104.156.80.0/20,140.248.64.0/18,140.248.128.0/17,146.75.0.0/17,151.101.0.0/16,157.52.64.0/18,167.82.0.0/17,167.82.128.0/20,167.82.160.0/20,167.82.224.0/20,172.111.64.0/18,185.31.16.0/22,199.27.72.0/21,199.232.0.0/16
     moda.github.net/dns-registration-enabled: 'false'
     moda.github.net/domain-name: docs-internal.github.com
     moda.github.net/load-balancer-type: public-external-http
 
@@ -9,4 +9,4 @@ metadata:
     # Public load balancer. allowed-ips limits it to Fastly IP ranges.
     moda.github.net/load-balancer-type: public-external-http
     # .github/workflows/moda-allowed-ips.yml updates this list weekly.
-    moda.github.net/allowed-ips: 23.235.32.0/20,43.249.72.0/22,103.244.50.0/24,103.245.222.0/23,103.245.224.0/24,104.156.80.0/20,140.248.64.0/18,140.248.128.0/17,146.75.0.0/17,151.101.0.0/16,157.52.64.0/18,167.82.0.0/17,167.82.128.0/20,167.82.160.0/20,167.82.224.0/20,172.111.64.0/18,185.31.16.0/22,199.27.72.0/21,199.232.0.0/16
+    moda.github.net/allowed-ips: 23.235.32.0/20,43.249.72.0/22,90.98.0.0/17,90.98.128.0/18,103.244.50.0/24,103.245.222.0/23,103.245.224.0/24,104.156.80.0/20,140.248.64.0/18,140.248.128.0/17,146.75.0.0/17,151.101.0.0/16,157.52.64.0/18,167.82.0.0/17,167.82.128.0/20,167.82.160.0/20,167.82.224.0/20,172.111.64.0/18,185.31.16.0/22,199.27.72.0/21,199.232.0.0/16
@@ -68,3 +68,32 @@ You can then perform offline verification with the following command:
 ```bash copy
 gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME --bundle sha256:ae57936def59bc4c75edd3a837d89bcefc6d3a5e31d55a6fa7a71624f92c3c3b.jsonl --custom-trusted-root trusted_root.jsonl
 ```
+
+### Confirming the repository in an offline environment
+
+When you verify offline, `gh attestation verify` compares the `-R` value only with the repository and owner names recorded in the attestation's signing certificate. These are the names that the repository and owner had when the attestation was created. The command can't detect whether the repository or owner has since been renamed, or whether a different repository or owner now uses that name.
+
+To make sure an attestation comes from the repository that currently has the name, download its bundle from the attestation API, as described in Step 1. The attestation API returns only attestations from that repository.
+
+The signing certificate also records the repository's ID. A repository keeps its ID when it's renamed, and a new repository that takes the old name gets a different ID. If you verify a bundle from another source, such as a bundle published alongside the artifact, compare this ID with the ID of the repository you expect.
+
+1. On a machine that is online, get the ID of the repository that you expect the artifact to come from.
+
+   ```bash copy
+   gh api repos/ORGANIZATION_NAME/REPOSITORY_NAME --jq .id
+   ```
+
+1. In your offline environment, add the `--format json` and `--jq` flags to the verification command to print the repository ID from each verified attestation.
+
+   For `-R`, replace `ORGANIZATION_NAME/REPOSITORY_NAME` with the owner and repository names recorded in the signing certificate. If the repository or owner has been renamed, these differ from the current names used for the API lookup.
+
+   ```bash copy
+   gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \
+     -R ORGANIZATION_NAME/REPOSITORY_NAME \
+     --bundle PATH/TO/YOUR/BUNDLE.jsonl \
+     --custom-trusted-root trusted_root.jsonl \
+     --format json \
+     --jq '.[].verificationResult.signature.certificate.sourceRepositoryIdentifier'
+   ```
+
+1. Check that each ID in the output matches the ID from the first step. Don't trust an attestation whose ID doesn't match, because another repository that used the same name created it.
@@ -14,12 +14,23 @@ category:
 
 When you create an enterprise, you choose a "slug" for the enterprise, which is a string used in the URL for your enterprise. For example, if you chose `octo-enterprise` as the slug, the URL for your enterprise on {% data variables.product.prodname_dotcom_the_website %} would be `https://github.com/enterprises/octo-enterprise`.
 
-If your company pays for {% data variables.product.prodname_ghe_cloud %} by credit card or PayPal, you can change the slug in the settings for your enterprise. When you change the slug, {% data variables.product.company_short %} does not set up any redirects from the old URL. Your old enterprise slug will immediately become available for another customer to use.
-
 > [!NOTE]
-> If you pay for {% data variables.product.prodname_ghe_cloud %} via invoice, or if your enterprise uses {% data variables.product.prodname_emus %}, you must contact {% data variables.contact.contact_enterprise_sales %} to change your enterprise slug.
 > For enterprises hosted on {% data variables.enterprise.data_residency_site %}, changing the enterprise slug is not currently supported.
 
+For enterprises hosted on {% data variables.product.prodname_dotcom_the_website %}, how you change your enterprise slug depends on your billing type and whether your enterprise uses {% data variables.product.prodname_emus %}.
+
+{% rowheaders %}
+
+| Enterprise configuration | How to change the slug |
+| --- | --- |
+| Self-serve billing without {% data variables.product.prodname_emus %} | Change the slug in your enterprise settings. See [Changing the enterprise slug](#changing-the-enterprise-slug). |
+| Self-serve billing with {% data variables.product.prodname_emus %} | Create a ticket through the {% data variables.contact.contact_enterprise_portal %} to request a slug change. |
+| Invoiced billing with or without {% data variables.product.prodname_emus %} | Contact {% data variables.contact.contact_enterprise_sales %} to request a slug change. |
+
+{% endrowheaders %}
+
+When you change the slug, {% data variables.product.company_short %} does not set up any redirects from the old URL. Your old enterprise slug will immediately become available for another enterprise to use.
+
 ## Considerations when changing your enterprise slug
 
 Before changing the slug for an enterprise, ensure you have considered any parts of your enterprise's configuration, automations, or processes that may depend on the old enterprise slug. To minimize disruption, you should address these points either immediately before or immediately after changing the slug.
 
@@ -0,0 +1,35 @@
+---
+title: Troubleshooting authorization holds
+intro: If an authorization hold appears on your payment method, you can check what it means and what to do if the funds are not released.
+versions:
+  fpt: '*'
+  ghec: '*'
+shortTitle: Authorization holds
+contentType: how-tos
+category:
+  - Set up payment
+---
+
+An authorization hold verifies your payment method. No funds are taken from your account as it is not a charge.
+
+## When you may see an authorization hold
+
+We may place a temporary hold on your payment method when you start a subscription, update your payment method, or accrue significant usage of metered services. The amount usually ranges from $1 to the cost of the service you are purchasing.
+
+## Where authorization holds appear
+
+An authorization hold may appear on your bank statement as `Card Verify`. 
+
+There may be more than one `Card Verify` entry if your payment method is verified multiple times, such as after repeated payment attempts or separate checks for metered usage.
+
+## When the funds are available again
+
+{% data variables.product.company_short %} does not hold the funds. {% data variables.product.company_short %} initiates the release immediately, but your bank or card issuer may take a few days to make the funds available again.
+
+### Contacting your bank or card issuer
+
+If the funds remain unavailable after 10 business days, contact your bank or card issuer and ask about the status of the `Card Verify` authorization. Your bank or card issuer can tell you when the funds will be available again.
+
+## What happens if the hold fails
+
+If your payment method can't be verified, you may not be able to complete the purchase. You can contact your bank or card issuer for details or try a different payment method. For more information, see [AUTOTITLE](/billing/how-tos/troubleshooting/locked-account#unlocking-an-accounts-features-due-to-a-failed-authorization-hold).
@@ -8,6 +8,7 @@ versions:
   ghes: '*'
 children:
   - /declined-card
+  - /authorization-holds
   - /locked-account
   - /azure-sub-connection
   - /enterprise-license-usage
 
@@ -32,8 +32,6 @@ For information on resolving {% data variables.code-quality.recent_suggestions %
 
 You can resolve findings individually or assign multiple findings to {% data variables.product.prodname_copilot_short %}.
 
-{% data reusables.code-quality.agentic-autofix-preview-note %}
-
 ### Resolving a single finding
 
 {% data reusables.code-quality.dashboard-navigation-repo %}
 
@@ -19,8 +19,6 @@ category:
 > [!NOTE]
 > {% data variables.product.prodname_code_quality_short %} has its own standalone enterprise policies. Access was previously controlled by your {% data variables.product.prodname_AS %} policies, and those existing settings are automatically applied to the new {% data variables.product.prodname_code_quality_short %} policies.
 
-{% data reusables.code-quality.agentic-autofix-preview-note %}
-
 When you allow {% data variables.product.prodname_code_quality_short %} for an organization and set the repository admin policy to **Allowed**, repository administrators can enable {% data variables.product.prodname_code_quality_short %} scans and all associated capabilities, including bulk agentic remediation with {% data variables.product.prodname_copilot_short %}. There is no separate policy for agentic remediation.
 
 If you restrict {% data variables.product.prodname_code_quality_short %}, repository administrators cannot enable scans or use {% data variables.product.prodname_copilot_short %}-powered autofixes for code quality findings.
 
@@ -68,8 +68,6 @@ Once you've picked a rule, decide how to handle each finding:
 | Multiple findings for the same rule are legitimate. | Select up to 25 findings on a page, then click **Assign to {% data variables.product.prodname_copilot_short %}**. | {% data variables.product.prodname_copilot_short %} opens a pull request containing fixes for the selected findings. Assigning to {% data variables.product.prodname_copilot_short %} consumes {% data variables.product.prodname_ai_credits_short %}|
 | A finding doesn't apply. For example, it's in legacy code, an intentional pattern, or a false positive. | Click **Dismiss**. | The finding is considered resolved and removed from the list of open findings. |
 
-{% data reusables.code-quality.agentic-autofix-preview-note %}
-
 In our example, we assign the 40 "Overwritten property" findings to {% data variables.product.prodname_copilot_short %} in batches of up to 25. We review the resulting pull requests and merge them once the CI checks pass.
 
 ## Step 4: Communicate impact