H-6402: Add preflight workflow

[TimDiekmann]

Summary

• Adds preflight.yml calling reusable workflows from the .github org repo
• Stale approvals: dismisses PR approvals when the diff changes
• Dependencies: reviews dependency changes for known vulnerabilities
• TODO comments: scans for TODO comments referencing Linear tickets from the PR title

Related

• H-6402: Add preflight reusable workflows .github#35

[cursor]

PR Summary

Medium Risk
Introduces new PR/merge-group automation that can dismiss approvals and write PR comments/statuses; misconfiguration or upstream workflow changes could affect review/merge behavior.

Overview
Adds a new GitHub Actions workflow, preflight.yml, triggered on pull_request_target and merge_group events.

The workflow runs three reusable org-level jobs: dismiss stale PR approvals when diffs change, review dependency changes (with PR write access), and scan for TODO comments.

^{Written by Cursor Bugbot for commit faa7e47. This will update automatically on new commits. Configure here.}

[augmentcode]

🤖 Augment PR Summary

Summary: Adds a new GitHub Actions “Preflight” workflow to run standardized PR checks via reusable workflows from hashintel/.github.

Changes:

• Introduces .github/workflows/preflight.yml as a central entrypoint for PR/merge-queue checks
• Runs a stale-approval dismissal workflow when PR diffs change
• Runs GitHub’s dependency review to flag known-vulnerable dependency updates
• Runs a TODO/Linear-ticket scanner based on IDs extracted from the PR title

Technical Notes: Reusable workflows are pinned to a specific commit SHA in hashintel/.github for supply-chain safety.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 2 suggestions posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

Because this workflow runs on pull_request when preflight.yml itself changes, the workflow definition from the PR branch can be executed; please double-check that this can’t be used to run newly-added steps with elevated job permissions (notably id-token: write / pull-requests: write). If this is intended only as a self-test trigger, consider ensuring the pull_request path is effectively non-privileged for untrusted changes.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[augmentcode]

The called reusable workflow todo-comments.yml (in hashintel/.github) checks out github.event.pull_request.head.sha even when invoked via pull_request_target; since pull_request_target runs with a more privileged token, it’s worth confirming this job can’t be abused by a fork PR (e.g., by executing untrusted code from the checkout). If forks are in scope, consider restricting when this job runs or ensuring the reusable workflow never executes repository-provided code.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Stale approvals job triggers unnecessarily on PR edits

Medium Severity

The edited activity type on pull_request_target fires when the PR title, body, or base branch changes. This is needed for the todo-comments job (which scans for Linear tickets from the PR title), but the stale-approvals and dependencies jobs also run on every title/body edit despite not needing to. The stale-approvals job holds pull-requests: write and id-token: write permissions and may dismiss approvals unnecessarily, while dependencies runs a pointless review. These two jobs lack an if condition (e.g., filtering on github.event.action != 'edited') to skip edited events.

Additional Locations (2)

• .github/workflows/preflight.yml#L11-L24
• .github/workflows/preflight.yml#L25-L31