docs(workflow): document when the review action actually posts

src/content/docs/workflow/actions/merge.mdx

@@ -43,10 +43,14 @@ known incompatibilities, and how to configure bypass actors, see
 
 ## Pull Request Dependencies
 
-You can specify dependencies between pull requests from the same repository,
-or from other repositories with Mergify installed within your organization.
-Mergify waits for the linked pull requests to be merged before merging any pull
-request with a `Depends-On:` header.
+You can specify dependencies between pull requests from the same repository, or
+from another repository that has Mergify installed and belongs to the same
+repository owner, whether that owner is a user or an organization. Mergify waits
+for the linked pull requests to be merged before merging any pull request with a
+`Depends-On:` header. A reference Mergify cannot resolve blocks the merge rather
+than waiting on it, and it stays blocked until you fix the reference. That
+includes a reference pointing at another owner's repository, at a repository
+without Mergify, or at a pull request that does not exist.
 
 To use this feature, add the `Depends-On:` header to the body of your pull
 request:

src/content/docs/workflow/actions/rebase.mdx

@@ -17,10 +17,12 @@ up-to-date with the latest changes from the base branch.
 :::
 
 :::caution
-  Support for the `rebase` action with `bot_account` on fork pull requests is
-  **deprecated** and will be removed in a future release. If you use this
-  configuration on
-  repositories that receive PRs from forks, switch to the
+  Support for rebasing pull requests that come from a fork is **deprecated**
+  and will be removed in a future release. This is not limited to
+  configurations that set `bot_account`: rebasing always impersonates a GitHub
+  user, and when `bot_account` is unset Mergify falls back to the sender of the
+  `rebase` command, or to the pull request author when a rule triggered the
+  rebase. If your repository receives pull requests from forks, switch to the
   [`update` action](/workflow/actions/update) instead.
 :::
 
@@ -40,22 +42,15 @@ commit (`#commits > 1`) is a third way to satisfy that either/or requirement.
 
 ## Examples
 
-### Autosquash Fixup Commits
+### Rebase on Label
 
-:::caution
-  The `autosquash` option is **deprecated** and will be removed in a future
-  release. Avoid relying on it in new configurations.
-:::
-
-Rebase a pull request and fold in any `fixup!`, `squash!`, or `amend!` commits
-once it is ready to merge.
+Rebase a pull request when it gets the `ready-to-merge` label.
 
 ```yaml
 pull_request_rules:
-  - name: autosquash fixup commits
+  - name: rebase when ready to merge
     conditions:
       - label = ready-to-merge
     actions:
       rebase:
-        autosquash: true
 ```

src/content/docs/workflow/actions/review.mdx

@@ -10,6 +10,25 @@ This can be particularly useful in situations where you want to automatically
 approve pull requests that meet certain criteria, or to request changes on a
 pull request when a particular check fails.
 
+## How Reviews Are Posted
+
+Mergify applies these rules when it posts a review:
+
+- Mergify skips a review whose type and body already match one it posted on the
+  pull request. It posts the review again if it has posted the opposite type
+  since: an `APPROVE` after a `REQUEST_CHANGES`, or the reverse.
+
+- That comparison only covers reviews posted under the same account, so
+  changing `bot_account` makes Mergify post an otherwise identical review again
+  under the new one.
+
+- On a merged pull request, only `COMMENT` is posted. `APPROVE` and
+  `REQUEST_CHANGES` are ignored, and the action still reports a success — a
+  green check there is not proof that a review was posted.
+
+- A `REQUEST_CHANGES` or `COMMENT` review with no `message` is posted with a
+  default body. Set `message` to choose the wording yourself.
+
 ## Parameters
 
 <ActionOptionsTable def="ReviewActionModel" />