Repo sync

content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-security-and-analysis-for-your-enterprise.md

@@ -28,15 +28,19 @@ category:
 
 You can enforce policies to manage the use of security features within organizations owned by your enterprise. You can allow or disallow people with admin access to a repository to enable or disable the security and analysis features.
 
-Additionally, you can enforce policies for the use of {% data variables.product.prodname_GH_sp_cs_and_cq_or_as %} in your enterprise's organizations and repositories.
+Additionally, you can enforce policies for the use of {% data variables.product.prodname_GHAS_cs_or_sp %} in your enterprise's organizations and repositories.
+
+{% ifversion code-quality %}
+Policies for {% data variables.product.prodname_AS %} do not control access to {% data variables.product.prodname_code_quality %}. To manage access, see [AUTOTITLE](/code-security/how-tos/secure-at-scale/configure-enterprise-security/configure-specific-tools/allow-github-code-quality-in-enterprise).
+{% endif %}
 
 ## Enforcing a policy for the availability of {% data variables.product.prodname_AS %} in your enterprise's organizations
 
 You are billed for {% data variables.product.prodname_GHAS_cs_and_sp %} products on a per-committer basis. See [AUTOTITLE](/billing/concepts/product-billing/github-advanced-security#managing-committers-and-costs).
 
 You can enforce a policy that controls whether repository administrators are allowed to enable features for {% data variables.product.prodname_AS %} in an organization's repositories. You can configure a policy for all organizations owned by your enterprise account, or for individual organizations that you choose.
 
-Disallowing {% data variables.product.prodname_GH_sp_cs_and_cq_or_as %} for an organization prevents repository administrators from enabling these features for additional repositories, but does not disable the features for repositories where the features are already enabled.
+Disallowing {% data variables.product.prodname_GHAS_cs_or_sp %} for an organization prevents repository administrators from enabling these features for additional repositories, but does not disable the features for repositories where the features are already enabled.
 
 {% data reusables.enterprise.role-permission-hierarchy %}
 
@@ -47,7 +51,7 @@ Disallowing {% data variables.product.prodname_GH_sp_cs_and_cq_or_as %} for an o
 {% data reusables.enterprise-accounts.advanced-security-individual-organization-policy-drop-down %}
 
 > [!NOTE]
-> If {% data variables.product.prodname_actions %} is not available for an organization, {% data variables.product.prodname_code_scanning %} and {% data variables.product.prodname_code_quality %} will be unable to run even if they are made available with this policy. See [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#policies).
+> If {% data variables.product.prodname_actions %} is not available for an organization, {% data variables.product.prodname_code_scanning %} will be unable to run even if it is made available with this policy.{% ifversion code-quality %} Similarly, {% data variables.product.prodname_code_quality %} will be unable to run even if it is made available with its own policy.{% endif %} See [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#policies).
 
 {% ifversion ghec %}
 
@@ -88,7 +92,7 @@ Across all of your enterprise's organizations, you can allow or disallow people
 {% data reusables.enterprise-accounts.access-enterprise %}
 {% data reusables.enterprise-accounts.policies-tab %}
 {% data reusables.enterprise-accounts.code-security-and-analysis-policies %}
-1. In the "Policies" section, under "Repository administrators can enable or disable `PRODUCT`", use the dropdown menu to define whether repository administrators can change the enablement of {% data variables.product.prodname_GH_sp_cs_and_cq_or_as %}.
+1. In the "Policies" section, under "Repository administrators can enable or disable `PRODUCT`", use the dropdown menu to define whether repository administrators can change the enablement of {% data variables.product.prodname_GHAS_cs_or_sp %}.
 
 <!--This option is included automatically by the "Repository Admins can Enable or Disable Secret Protection" option, which is why this section is omitted for `ghas-products` versions.-->
 

content/admin/upgrading-your-instance/troubleshooting-upgrades/rotating-the-signing-key-for-upgrade-packages.md

@@ -58,13 +58,13 @@ For help determining the correct upgrade path, use the [{% data variables.enterp
 For instances configured with high availability or clustering, the key must be rotated on every node.
 
 1. Connect to any node in your HA or cluster installation via SSH.
-1. Download the rotation script provided by {% data variables.product.company_short %}.
+1. Download the rotation script provided by {% data variables.product.company_short %} on every node.
 
    ```shell
-   curl -fsSL https://enterprise.github.com/security/2026-05-24/rotate-gpg.sh -o rotate-gpg.sh
+   ghe-cluster-each -- "curl -fsSL https://enterprise.github.com/security/2026-05-24/rotate-gpg.sh -o rotate-gpg.sh"
    ```
 
-1. Run the following commands. The `ghe-cluster-each` command copies the script to all nodes and runs it on all nodes.
+1. Run the script twice on every node, once as the `admin` user and once with `sudo`.
 
    ```shell
    ghe-cluster-each -- chmod ug+x ./rotate-gpg.sh

content/code-security/concepts/code-quality/enablement-at-scale.md

@@ -39,12 +39,12 @@ You can apply one of the following options at a time.
 | **No repositories** | Disables {% data variables.product.prodname_code_quality_short %} for all current and future repositories in the organization. |
 | **Let repositories decide** | The organization neither enables nor disables {% data variables.product.prodname_code_quality_short %}. Repository administrators choose whether to enable it for their own repositories. This option cannot be enforced. |
 | **All repositories** | Enables {% data variables.product.prodname_code_quality_short %} for all current and future repositories. |
-| **Selected repositories** | Enables {% data variables.product.prodname_code_quality_short %} for a specific list of repositories that you choose. Repositories you do not select are disabled, and new repositories are not enabled automatically. Best for pilots or exceptions. |
-| **Matching a filter** | Enables {% data variables.product.prodname_code_quality_short %} for repositories that match a filter you define, now and in the future. Repositories that do not match are disabled. See [Filtering repositories](#filtering-repositories). |
+| **Selected repositories...** | Enables {% data variables.product.prodname_code_quality_short %} for a specific list of repositories that you choose. Repositories you do not select are disabled, and new repositories are not enabled automatically. Best for pilots or exceptions. |
+| **Matching a filter...** | Enables {% data variables.product.prodname_code_quality_short %} for repositories that match a filter you define, now and in the future. Repositories that do not match are disabled. See [Filtering repositories](#filtering-repositories). |
 
 ### Filtering repositories
 
-When you choose **Matching a filter**, you create a dynamic filter that automatically enables {% data variables.product.prodname_code_quality_short %} for existing and future repositories that match your criteria. This is useful for ongoing governance at scale.
+When you choose **Matching a filter...**, you create a dynamic filter that automatically enables {% data variables.product.prodname_code_quality_short %} for existing and future repositories that match your criteria. This is useful for ongoing governance at scale.
 
 You can filter on any combination of the following criteria:
 

content/code-security/responsible-use/security-and-quality-ai-features.md

@@ -244,7 +244,6 @@ GitHub Code Quality's LLM-powered analysis shares the evaluation framework of Co
 * **Dry-run validation for generated patterns**: Generated regular expressions from the custom pattern regex generator must go through a dry-run validation step before deployment. Users explicitly import a result into the custom pattern form and test it across their repository or organization, ensuring patterns perform as expected before they are used in production.
 * **Explicit user action required**: The regex generator does not automatically deploy patterns. Users must click **Use result** to copy a generated expression into the custom pattern form, then manually save and enable the pattern.
 * **Feedback mechanism for Code Quality**: Users can provide feedback on Code Quality suggestions using the thumbs up and thumbs down buttons on the `github-code-quality` bot's comments, helping GitHub improve suggestion quality.
-* **Preview-gated availability**: GitHub Code Quality is available as a preview, allowing organizations to evaluate the feature before broader adoption.
 
 ## 10. Best practices for deploying and adopting GitHub Code Security AI features
 

content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md

@@ -121,15 +121,17 @@ Users are grouped into the following phases:
 
 | Phase | What it represents |
 |:--|:--|
-| Passive users | The user has not met the engagement threshold for a phase during the period. In the underlying data, this phase is labeled `No Cohort`. |
-| Phase 1: Code first | The user engaged with code completions and/or IDE agent mode. |
-| Phase 2: Agent first | The user engaged with a single {% data variables.product.github %}-based agent surface, such as {% data variables.copilot.copilot_cloud_agent %}, {% data variables.copilot.copilot_code-review_short %}, or {% data variables.copilot.copilot_cli_short %}. Only active engagement with {% data variables.copilot.copilot_code-review_short %} counts here; having it automatically assigned to review a pull request without further engagement does not. |
+| Passive users | The user has not met the engagement threshold for a phase during the period. A passive user may still be using {% data variables.product.prodname_copilot_short %} regularly, for example by asking questions in {% data variables.copilot.copilot_chat_short %} or agent mode without applying any code edits. In the API, this phase is labeled `No Cohort`. |
+| Phase 1: Code first | The user engaged with code completions and/or agent edits, where {% data variables.product.prodname_copilot_short %} writes changes directly into files in the IDE. Using {% data variables.copilot.copilot_chat_short %} or agent mode without producing code completion or agent edit activity does not qualify on its own. |
+| Phase 2: Agent first | The user engaged with a single {% data variables.product.github %}-based agent surface, such as {% data variables.copilot.copilot_cloud_agent %}, {% data variables.copilot.copilot_code-review_short %}, or {% data variables.copilot.copilot_cli_short %}. Both active engagement with {% data variables.copilot.copilot_code-review_short %} and having it automatically assigned to review a pull request count as the same surface. |
 | Phase 3: Multi-agent | The user engaged with two or more {% data variables.product.github %}-based agent surfaces, or with the {% data variables.copilot.github_copilot_app %}. |
 
 To be grouped into a phase, a user must meet an engagement threshold of at least two active days out of the trailing 28-day window, using the surfaces associated with that phase. A user only needs two qualifying days on a higher phase's surfaces to progress to that phase. Agent usage alone can qualify a user, without separate days of plain completions.
 
 Phase assignment is recalculated daily from the trailing 28-day window, so a user's phase can shift from one day to the next as their activity within that window changes. This is expected behavior, not a data error.
 
+The impact dashboard counts every user who was active during the trailing 28-day window and groups each user by their current phase. The phase classification rules are the same, but the dashboard population is broader than the `totals_by_ai_adoption_phase.total_engaged_users` field in API and NDJSON reports, which counts users who were active on a specific day.
+
 Users who haven't met any phase's threshold are grouped into **Passive users**, which is not a measure of inactivity, but a signal that a user's engagement hasn't yet reached the level needed to reliably classify their adoption depth. For example, a user with fewer than two active days in the trailing 28-day window, or one who only lightly uses a surface like {% data variables.copilot.copilot_chat_short %} on {% data variables.product.prodname_dotcom_the_website %}, shows as a passive user.
 
 Because phase assignment is based on **which surfaces a user engages with**, not simply how many actions they take, a user with high completion volume but no agent usage stays in Phase 1, while a user with lighter but broader usage across agent surfaces progresses to Phase 2 or Phase 3.
@@ -142,6 +144,14 @@ This shows the relative impact of deeper adoption, independent of how many users
 
 For example, if users in the engaged cohorts averaged 20 pull requests/user/month and the passive cohort averaged 10, then the equation is 20 / 10 = 2x multiplier.
 
+### Estimating potential return on investment
+
+The impact dashboard's **Potential return on investment** section provides a comparison of cost and pull request output between **Phase 0-1 Passive and Code First Users** and **Phase 2-3 Agent First Users**.
+
+For each phase group, the dashboard shows the monthly {% data variables.product.prodname_copilot_short %} cost per developer, based on actual {% data variables.product.prodname_ai_credits_short %} consumption, and that cost as a percentage of developer compensation. It also shows average pull requests per developer per month.
+
+You can select a compensation band to update estimates that depend on developer compensation. These figures are estimates rather than exact financial results, so interpret them alongside the adoption multiplier's code-shipped and time-to-merge comparisons. The return-on-investment estimates are available only in the dashboard and are not included in the {% data variables.product.prodname_copilot_short %} usage metrics API or NDJSON exports.
+
 ### Interpreting pull request lifecycle metrics across scopes
 
 Pull request lifecycle metrics are available at both the organization and enterprise level. When comparing reports, keep the following in mind:

content/copilot/how-tos/administer-copilot/view-impact-dashboard.md

@@ -15,7 +15,7 @@ category:
 
 Instead of a flat active-user count, the impact dashboard groups users into adoption cohorts based on how they engage with {% data variables.product.prodname_copilot_short %}, and connects that engagement to pull request throughput. This gives you a more meaningful signal of adoption depth than daily or weekly active user counts alone.
 
-For a detailed explanation of what the dashboard shows, including adoption cohorts, engagement trends, and recommendations, see [AUTOTITLE](/copilot/concepts/copilot-usage-metrics/copilot-metrics).
+For a detailed explanation of what the dashboard shows, including adoption cohorts, engagement trends, potential return on investment, and recommendations, see [AUTOTITLE](/copilot/concepts/copilot-usage-metrics/copilot-metrics).
 
 ## Prerequisite
 
@@ -25,3 +25,12 @@ For a detailed explanation of what the dashboard shows, including adoption cohor
 
 {% data reusables.copilot.access-copilot-metrics-dashboard %}
 1. In the left sidebar, click **{% data variables.product.prodname_copilot_short %} impact**.
+
+## Estimating potential return on investment
+
+The "Potential return on investment" section provides a directional comparison of cost and pull request output across adoption phases.
+
+1. Under "Average developer cost in your organization", select a compensation band.
+1. In the "Transition your developers to be agent-first" card, compare the cost, payroll, and pull request estimates for "Phase 0-1 Passive and Code First Users" and "Phase 2-3 Agent First Users".
+
+Treat the figures as directional estimates rather than exact financial results. Use them with the adoption multiplier metrics for code shipped and time to merge pull requests.

content/copilot/reference/copilot-cli-reference/cli-command-reference.md

@@ -394,6 +394,8 @@ These are the slash commands you can use from within an interactive CLI session.
 
 For a complete list of available slash commands enter `/help` in the CLI's interactive interface.
 
+In the schedule manager opened by a bare `/every` or `/after`, use <kbd>↑</kbd>/<kbd>↓</kbd> to select an entry and `x` to remove it. Schedules can only be added from the prompt input using `/every` or `/after` with arguments—the dialog itself is read-and-remove only.
+
 ## Command-line options
 
 | Option                             | Purpose                                  |
@@ -518,6 +520,7 @@ Use `--model=MODEL` or the `COPILOT_MODEL` environment variable to select the AI
 | `gemini-3.1-pro-preview` | Google Gemini reasoning |
 | `gemini-3.5-flash` | Fast Google Gemini responses |
 | `gemini-3.6-flash` | Fast Google Gemini responses |
+| `gemini-3.7-flash` | Fast Google Gemini responses |
 | `mai-code-1-flash` | Fast, adaptive coding tasks |
 
 You can also switch models during an interactive session using the `/model` slash command.
@@ -1031,8 +1034,11 @@ Custom agents are specialized AI agents defined in Markdown files. The filename
 | `mcp-servers` | object | No | MCP servers to connect. Uses the same schema as `~/.copilot/mcp-config.json`. |
 | `model` | string | No | AI model for this agent. When unset, inherits the outer agent's model. When the session model is set to `Auto` (server-selected), subagents always inherit the resolved session model regardless of this field. |
 | `name` | string | No | Display name. Defaults to the filename. |
+| `reasoningEffort` | string | No | Default reasoning effort for this agent (for example, `"low"`, `"medium"`, or `"high"`). When unset, inherits the outer agent's effort. |
 | `tools` | string[] | No | Tools available to the agent. Default: `["*"]` (all tools). |
 
+`model` and `reasoningEffort` apply whether the agent is dispatched through the `task` tool or started directly—for example, through the SDK's `session.startSubagent`. They're resolved with this precedence, highest first: an explicit per-call value, the `subagents` override in `~/.copilot/settings.json`, the agent definition's `model`/`reasoningEffort` field, then the parent session's value. A declared model or effort that can't be honored falls back to the session's value instead of failing the dispatch.
+
 ### Custom agent locations
 
 | Scope | Location |