Plugin API changelog maintained

When plugin API changes are buried in general commit history or a changelog that does not distinguish plugin-API-affecting changes from UI tweaks and bug fixes, plugin authors have no reliable way to know what changed between host versions. They discover breaking changes when their plugin crashes in production after a host upgrade. ISO 25010 maintainability.modifiability requires that the impact of modifications be traceable; a plugin API changelog is the traceability artifact that makes API evolution navigable for the plugin ecosystem.

Create a dedicated docs/plugin-api-changelog.md or a clearly marked section in CHANGELOG.md. Every release that adds, modifies, or deprecates a hook or plugin context method must include an entry.

## v2.1.0
- Added `onBeforeRender` hook — fires before each page render with `{ url, context }`
- Deprecated `onRender` — use `onAfterRender` instead; `onRender` removed in v3.0.0

## v2.0.0 (breaking)
- Renamed `beforeRequest` payload field `req` to `request`
- Removed `onLoad` hook — migrate to `init()` lifecycle method

• ID: plugin-extension-architecture.discovery-docs.api-changelog

• Severity: low

• What to look for: Check whether changes to the plugin API are tracked in a changelog that is separate from (or clearly distinguished within) the general application changelog. Plugin authors need to know when hooks are added, modified, or deprecated — not every UI change or bug fix in the host. Look for:

  1. A dedicated PLUGIN_API_CHANGELOG.md or API_CHANGELOG.md
  2. A "Plugin API Changes" section in the main CHANGELOG.md
  3. Release notes that tag or label plugin-API-affecting changes
  4. A migration guide for each major plugin API version bump

• Pass criteria: Count all API changelog entries. Plugin API changes are tracked in a changelog (dedicated or clearly marked section). At minimum, the changelog covers: new hooks added, hooks deprecated or removed, payload type changes, and breaking changes. Plugin authors can review the changelog to understand what changed between versions. At least 1 changelog entry must exist documenting API changes.

• Fail criteria: No plugin API changelog. Changes to hooks, payloads, and the plugin context are buried in general commit history or not documented at all. Plugin authors discover breaking changes by their plugins crashing.

• Skip (N/A) when: The plugin API has never changed (version 1.0.0 with no updates since launch). Also skip if the project is pre-release with an explicit "unstable API" warning.

• Detail on fail: "No plugin API changelog exists. The general CHANGELOG.md does not distinguish plugin-API-affecting changes from other changes. A plugin author looking to update their plugin for the latest host version has no way to find what changed in the plugin API without reading every commit."

• Remediation: Create a plugin API changelog in docs/plugin-api-changelog.md or src/plugins/CHANGELOG.md:

  ## v2.1.0
  - Added `onBeforeRender` hook
  - Deprecated `onRender` (use `onAfterRender` instead)