[lywinged]

What this changes

Open pull requests that each add an entry under [Unreleased] in CHANGELOG.md conflict with main and with each other as soon as one of them merges, in that file and nowhere else. Five did this week (#537, #608, #610, #618, #619), and one of them has been rebased three times for the file alone. The ruling already given on #486 on 12 October, that entries are written at merge so open pull requests stop conflicting on the file, lived in one comment, while CONTRIBUTING step 5 still said "Update CHANGELOG.md" and the template had a box for it.

Three changes, one commit:

• CONTRIBUTING.md, step 5 of a normative contribution: the entry goes in the description under ## Changelog entry, the merging Maintainer writes it under [Unreleased] on main at merge crediting the author, and a pull request that has to carry the file (a release, a correction to the file) is labelled changelog by a Maintainer. Line 102 now says "the changelog entry" where it named the file.
• .github/PULL_REQUEST_TEMPLATE.md: a ## Changelog entry section; the CHANGELOG.md updated box is gone.
• .github/workflows/changelog-guard.yml: on pull_request, fails when CHANGELOG.md is in the diff against the merge base unless the pull request carries the changelog label; re-runs on label changes; reads only, no write token, not pull_request_target. actionlint and shellcheck clean. Simulated on a clone: fix(intent_bridge,successor_observation): validate caller options and JWKs at entry and deep-copy observation (#617) #618 fails, docs(crosswalk): NIST SP 800-53 Rev 5 and DoD AI Tailoring Guide mapping for v0.2 claims #486 passes.

Three settings the commit cannot carry, for after the merge: create the changelog label; make Changelog guard a required status check on main; and the entry written at merge goes on main by direct push or by a labelled pull request.

A reader who had seen none of this found: the job had no name, so the check would have been called guard while CONTRIBUTING named it Changelog guard, fixed; line 102 still named the file, fixed; and a pull_request workflow does not start on a pull request GitHub cannot merge, so the guard does not run on the five as they stand, which is handled separately.

Type of change

• Editorial (typo, link fix, clarification: no normative effect)
• Non-breaking spec change (new optional field, new platform profile, informative addition)
• Breaking spec change (requires 14-day comment period and Project Lead sign-off)
• Schema change
• Example addition

Spec section

None (CONTRIBUTING.md, .github/PULL_REQUEST_TEMPLATE.md, .github/workflows/changelog-guard.yml).

Tests for a fix

Not a code or schema fix.

Changelog entry

None: the changelog records changes to the specification, and this is the contributing process.

Checklist

• DCO sign-off on all commits (git commit -s)
• CHANGELOG.md updated (for any normative change): not touched, which is the rule this pull request makes
• Breaking changes marked with <!-- CHANGED: #NNN: description --> in spec text
• Backward compatibility statement included (for breaking changes)

[dinakarjs]

Reviewed exact head 87c4af4. The workflow uses pull_request with a read-only token, pinned checkout and no persisted credentials; label events rerun the guard. Ran the actual shell body locally with bash -eo pipefail against real commit ranges: no CHANGELOG edit passes without label, an edit fails without label, and the same edit passes with label. Hosted workflow lint and the guard pass. No blocking finding.

[lywinged]

@imran-siddique @rajnisht7 following up on this PR: could you add Changelog guard as a required status check on main (the branch protection rule or the ruleset for main)? It came in with this pull request and has run on it, so it is selectable. Maintainers do not have that settings page.

[rajnisht7]

@lywinged I’ve added Changelog guard as a required status check for main.