discord-changelog

name	discord-changelog
description	Style and hard constraints for Plans~/DISCORD_CHANGELOG.md entries (the Discord release-notes posts). Use whenever adding or editing an entry there — hard 2000-char-per-entry cap, ASCII-only, prepend-only.

Discord changelog

Rules for editing Plans~/DISCORD_CHANGELOG.md. The file is the source for what gets pasted into the project's Discord release-notes channel.

Hard constraints

• Each release entry must be <= 2000 characters (Discord per-message limit). Count from the release header up to - but not including - the next entry's header or the trailing --- separator. If the entry is too long, cut prose, not facts.
• Always prepend. New entries go at the top of the file. Never reorder or delete prior entries.
• ASCII-only. No emojis, no bullet glyphs (*, x, >, etc.), and no non-ASCII characters at all - including em-dash, en-dash, arrows, smart quotes, ellipsis, middot, or any decorative typography. Use plain ASCII alternatives:
  • em-dash / en-dash -> - (hyphen with spaces) or --
  • right arrow -> ->
  • left/right arrow -> <->
  • middot separator -> | or * or .
  • ellipsis -> ...
  • curly quotes -> straight ' and " This rule has no exceptions. Windows/PowerShell pipelines and Discord syntax highlighting can mangle non-ASCII bytes silently, leaving replacement chars (? or U+FFFD) in production posts. (Known drift: the 0.8.0-0.8.2 entries were written before this rule was discoverable by the assistant and contain em-dashes/arrows; already-posted entries stay as-is - apply the rule strictly to NEW entries.)
• Backticks for diagnostic IDs and code identifiers (UITKX0026, CS0019, FindLhsStartForLogicalAnd).
• No // C# line comments inside fenced code blocks unless they carry meaning a reader needs (most lines should be self-explanatory). Use plain prose lines instead.

Entry shape

## [x.y.z] - YYYY-MM-DD

### Subject - short descriptor

**Bold lead-in.** One paragraph describing the user-facing impact and why
it mattered.

```jsx
// optional minimal repro fenced block, only when the syntax change benefits
<Box>{flag && <Label text="hi"/>}</Box>

Follow-up paragraph(s) describing implementation strategy at a high level (walker, splicer, parity), diagnostic IDs, and any deferred work tracked in Plans~/REMAINING_WORK.md.

Fix - short headline. Paragraph for any secondary fix shipping in the same release.

Tests. One line summarising the test delta and the SG suite total (1198/1198 SG passing).

VS Code a.b.c -> a.b.d | VS 2022 a.b.c -> a.b.d.

---

## Style notes

- The `---` separator at the bottom of each entry is **not** counted toward
  the 2000-char budget but must be present.
- Reference the previous release closest to the new entry as the
  authoritative style template - match its register and density.
- Don't restate boilerplate facts (`React idiom`, `walker is precedence-aware`)
  more than once per entry.
- If a fix and a feature ship together, lead with the feature, then a
  `**Fix -**` paragraph for the fix.
- Verify size after writing: count chars from `## [x.y.z]` up to (not
  including) the trailing `---`.