OpenMeld Changelog

Keep changelog/entries/*.md as the human- and agent-authored source of truth. Treat CHANGELOG.md, changelog/index.json, and changelog/releases/*.md as generated projections. Read developing/engineering/changelog.md before editing either source or projections.

Choose the job

• Record a change: inspect the implementation and add one concise draft entry when users or contributors gain, lose, or materially experience a capability.
• Publish a change: add publishedAt, optional release, and concrete evidence only after the delivery claim is proven.
• Backfill history: reconstruct an omitted entry from tags, commits, pull requests, tests, deployment records, or other durable evidence. Use the original availability date, not today's date.
• Prepare release notes: publish the applicable entries, rebuild the projections, and hand the generated release file to the authorized release workflow. A notes file is not release authorization.

Gather evidence

Use the coding agent's native file, Git, GitHub, test, and search tools. No custom Changelog command is required for investigation or writing.

Establish these facts separately:

1. what behavior changed;
2. who can notice or use it;
3. which code, pull request, or commit contains it;
4. whether it was merged;
5. whether the relevant component was delivered; and
6. whether any required real-user smoke produced the visible outcome.

Merge, tag, deployment, and smoke are different claims. Keep an entry draft when the evidence proves only an earlier claim.

Decide whether to record it

Record changes that affect users, operators, integrators, or contributors:

• new or removed capabilities;
• material workflow or behavior improvements;
• user-visible fixes and security changes;
• breaking behavior and deprecations; or
• developer-facing changes that alter supported integration or contribution work.