docs: close gaps found by docs-gap-analysis

src/content/docs/ci-insights/auto-retry.mdx

@@ -56,16 +56,20 @@ re-running all failed jobs while preserving successful ones.
 
 Auto-Retry uses a rule-based system to determine which workflow runs should be
 retried. Rules are evaluated against individual jobs, but retries occur at the
-workflow level.
+workflow level. Each rule belongs to a single repository, chosen from the
+repository selector at the top of the Auto-Retry page.
 
 ### Basic Setup
 
-To enable Auto-Retry for your repositories:
+To set up Auto-Retry for a repository:
 
 1. Navigate to your Mergify dashboard
 2. Go to **CI Insights** → **Auto-Retry**
-3. Select the repositories you want to enable Auto-Retry for
-4. Configure your retry rules
+3. Pick a repository from the selector at the top of the page
+4. Configure your retry rules for that repository
+
+You can view, create, edit, or delete rules scoped to the selected repository.
+Switch repositories from the selector to manage another one.
 
 <Image src={ruleConfig} alt="CI Insights retry rule configuration" />
 
@@ -96,8 +100,6 @@ The following condition attributes are available:
 - **Pipeline name**: Match against the name of the workflow (pipeline) that
   contains the failed job.
 
-- **Repository**: Restrict the rule to specific repositories.
-
 - **Branch**: Restrict the rule to specific branches. You can also enter custom
   branch names that are not yet in the list.
 
@@ -113,4 +115,6 @@ The following condition attributes are available:
   evaluated against individual log lines. You can specify multiple
   patterns — a retry is triggered if any of the patterns match. For
   example, `timeout|connection refused` would match any log line
-  containing either "timeout" or "connection refused".
+  containing either "timeout" or "connection refused". The rule builder
+  includes a **Test your log patterns** panel to check your log-pattern
+  regex against sample log text before saving.

src/content/docs/configuration/conditions.mdx

@@ -26,6 +26,9 @@ The grammar for a condition is:
 Attributes represent properties of a pull request: number of approvals, labels,
 status of CI checks, and so on.
 
+The `scope` attribute holds the list of [scopes](/merge-queue/scopes) associated
+with the pull request, so you can match conditions against them.
+
 ### Operators
 
 When the attribute is a list, comparison operators behave as if "any" is used on
@@ -60,6 +63,19 @@ Boolean attributes are used on their own or negated with `-`:
 - -closed
 ```
 
+### Matching the Pull Request Author
+
+Use `{{ author }}` as a value to match an attribute against the pull request's
+author. It's resolved as a native, built-in value and is accepted everywhere a
+value can appear, so existing configurations keep working unchanged.
+
+```yaml
+# True if the event sender is the pull request author
+- sender = {{ author }}
+# True if a commit is authored by the pull request author
+- commits[*].author = {{ author }}
+```
+
 ## Attributes List
 
 <PullRequestAttributesTable />
@@ -260,6 +276,21 @@ rejected at configuration validation time. Branch-protection-synthesised
 conditions and legacy GitHub commit statuses carry no GitHub App identity
 and remain reachable only via the bare form.
 
+## Matching Cancelled Checks
+
+The `check-cancelled` attribute matches checks that report a `cancelled`
+conclusion, such as a GitHub Actions job stopped by
+`concurrency: cancel-in-progress`. Cancelled checks are also matched by
+`check-failure` for backward compatibility. To keep a cancellation from
+triggering rules meant for genuine failures, pair `check-failure` with a
+negated `check-cancelled`:
+
+```yaml
+# Match a genuine failure but ignore a cancellation
+- check-failure = test
+- -check-cancelled = test
+```
+
 ## Combining Conditions Using Logical Operators
 
 Combine conditions with `and`, `or`, and `not`.

src/content/docs/merge-queue/github-rulesets.mdx

@@ -87,6 +87,14 @@ queue_rules:
   being silently skipped. Fix the ruleset to remove the stale reviewer.
 :::
 
+### Require Approval of the Most Recent Push
+
+When your branch protection enables GitHub's *Require approval of the most
+recent push* option (`require_last_push_approval`), Mergify injects a matching
+condition into your Merge Protections. A pull request is not merged until its
+latest push has been approved by someone other than the author, so Mergify
+stays aligned with GitHub's own enforcement.
+
 ## Ruleset Rule Compatibility
 
 Mergify handles each GitHub ruleset rule type as follows.

src/content/docs/merge-queue/scopes.mdx

@@ -139,7 +139,7 @@ queue_rules:
 
 - `scopes.capacities`: optional map of scope name to the number of speculative checks that scope may
   run at the same time, used to limit per-scope concurrency in parallel mode. See [Limiting
-  concurrency per scope](/merge-queue/parallel-scopes#limiting-concurrency-per-scope).
+  concurrency per scope](/merge-queue/queue-modes#limiting-concurrency-per-scope).
 
 ### Manual source example