Existing coverage (partial)
content/project-rules/general.md §"Record reader-facing changes in the changelog" already requires:
When a change is something a docs reader would want to know about — a new page or section, a renamed concept, removed or relocated content, or a correction to documented behavior — add a short entry to changelog/index.mdx as part of the same change.
Examples are docs-centric. Interface surfaces (API, SDK, CLI, config keys, env vars) are arguably "reader-facing" but the rule doesn't call them out explicitly, so authors may either skip them or treat their existence as something to suppress.
Gap
Two things to make explicit:
- Interface changes belong in the changelog. A new API endpoint, a renamed SDK method, a removed CLI flag, a changed config key — each is a separate changelog entry, even during 0.x.
- Interface changes are allowed. No hidden deprecation cycle, no avoidance of the topic in the PR description. State the change; note breakage if any; let the changelog do its job.
Ask
Extend the existing general.md §"Record reader-facing changes" rule. Add interface surfaces to the example list, and add a one-line affirmation that these changes are allowed and expected during 0.x. Do not introduce a new rule section — fold into the existing one.
Existing coverage (partial)
content/project-rules/general.md§"Record reader-facing changes in the changelog" already requires:Examples are docs-centric. Interface surfaces (API, SDK, CLI, config keys, env vars) are arguably "reader-facing" but the rule doesn't call them out explicitly, so authors may either skip them or treat their existence as something to suppress.
Gap
Two things to make explicit:
Ask
Extend the existing
general.md§"Record reader-facing changes" rule. Add interface surfaces to the example list, and add a one-line affirmation that these changes are allowed and expected during 0.x. Do not introduce a new rule section — fold into the existing one.