trigger-pr-labeler.yml

# This file is auto-generated by scripts/dogfood.sh. Do not edit directly.
# Edit gh-agent-workflows/pr-labeler/example.yml and run 'make compile' to regenerate.
name: Trigger PR Labeler
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

permissions:
  actions: read
  contents: read
  copilot-requests: write
  issues: write
  pull-requests: write

jobs:
  run:
    uses: ./.github/workflows/gh-aw-pr-labeler.lock.yml
    with:
      classification-labels: "small_boom,medium_boom,big_boom"
      additional-instructions: |
        Only use labels from `small_boom,medium_boom,big_boom`.
        Use this holistic risk model and pick the best-fit label:
        - Change scope: breadth/cross-cutting impact across modules and services.
        - Criticality: security/auth/permissions, CI/workflows, runtime-critical paths, schema/data integrity.
        - Reversibility: ease/safety of rollback (data/config/schema changes are harder to reverse).
        - Verification confidence: quality/coverage of tests and validation evidence.
        - Operational safeguards: feature flags, canaryability, staged rollout, and clear rollback path.
        Classify PR blast radius as:
        - `small_boom`: narrow scope, low risk, straightforward changes; usually low likelihood of human review.
        - `medium_boom`: moderate scope/risk, multi-file or non-trivial behavior impact; likely benefits from human review.
        - `big_boom`: broad/high-risk changes with concrete blast radius evidence (security/auth/workflow/runtime-critical impact, cross-cutting behavioral changes, or high operational risk); strong human review required.
        Apply an uncertainty tax: if evidence is ambiguous, move one level more conservative.
        Do not use `big_boom` solely because a PR is large or adds many new files.
        If a PR is mostly additive (new files/features) and does not significantly alter existing behavior, prefer `small_boom` or `medium_boom` based on real impact.