Rules for Verifying CHANGELOG.md in Framework

• Always update CHANGELOG.md when there are changes to the package from the perspective of framework users
  • Basically, updates are required when there are changes to non-private classes or methods under src/
  • Note that if the implementation involves a breaking change, you must address it by updating the minor or major version in accordance with SemVer
  • However, changes made to fix internal bugs (bug fixes) that are breaking changes with low impact are allowed to be addressed with a patch version update

Important Formatting and Content Rules

• The format is based on Keep a Changelog
• The CHANGELOG should only describe changes visible from the user's perspective
• Instead of writing implementation details, briefly describe what features were added, changed, or fixed from the viewpoint of the service user
• Describe changes to the external parts that serve as the interface of this framework from the user's perspective
• Focus on the impact on users when they use the framework, rather than the changes within the framework itself
• PR and Issue numbers should be written in link format like

  [#123](github.com/your-repo/issues/123)

• Use systems, code, or classes as the subject
• Briefly describe changes and additions
• For bug fixes, describe the phenomenon or problem that occurred
• If there are alternative methods, include them
• Write class names using their FQCN even if it is somewhat verbose