[jacekradko]

Landing an intentional break meant either adding the symbol to acknowledgedChanges, a commit plus a prune after merge, or merging over red. The second is one click, so red became the routine outcome for any PR touching the API and stopped carrying information. Applying the breaking-change label now turns the check green: nothing to commit, nothing to prune, and the label records who decided.

The line worth checking is the trigger, not the condition:

pull_request:
  types: [opened, synchronize, reopened, labeled, unlabeled]

labeled and unlabeled are not in the default activity set, so without them applying the label would leave the check red until the next push, and "one click" would quietly be "one click plus an empty commit". unlabeled is there so removing the label puts red back.

This only means something once break-check is a required check on protect-main, which it is not yet. I will add it after this merges, so the required context exists in the form the ruleset expects.

Known gap, deliberately not closed here: policy-mode stays off, so a PR can still acknowledge its own break by editing break-check.config.json in the same PR. The action's own docs recommend turning it on precisely when the check is a required gate. Filed rather than folded in.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

API Changes Report

Generated by Break Check on 2026-09-10T12:26:22.303Z

Summary

Metric	Count
Packages analyzed	1
Packages with changes	0
🔴 Breaking changes	0
🟡 Non-breaking changes	0
🟢 Additions	0

No API Changes Detected

All packages have stable APIs with no detected changes.

---

Report generated by Break Check

_{Last ran on 7187677.}