docs(blotter): keep release highlights user-facing

.claude/skills/release/SKILL.md

@@ -56,7 +56,7 @@ Rules:
 - End with a period
 
 Good examples:
-- "This version adds backlinks for quoted posts, a copy user ID menu item, and several bug fixes."
+- "This version adds backlinks for quoted posts, a copy user ID menu item, and clearer reply previews."
 - "This release adds pseudonymity mode support per-reply and fixes timezone display issues."
 
 ### Step 3 — Write the blotter message
@@ -66,11 +66,12 @@ This is a **separate, shorter** summary used for the in-app blotter banner. **Th
 Format rules:
 - Comma-separated key highlights, each a short plain-English phrase (not a full sentence)
 - Omit "This version..." prefix — the blotter script prepends `vX.Y.Z: ` automatically
-- Aim for ~60–80 characters after the version prefix
+- Aim for ~45–70 characters after the version prefix
 - **Only genuinely novel or noteworthy items** — things a user would find interesting or exciting
-- Skip regression fixes (restoring something that previously worked), routine bug fixes, minor z-index/modal/layout tweaks, test improvements, CI changes, and anything that isn't a new capability or a significant user-facing improvement
+- Skip regression fixes (restoring something that previously worked), routine bug fixes, invisible security/stability work, minor z-index/modal/layout tweaks, test improvements, CI changes, and anything that isn't a new capability or a significant user-facing improvement
 - If something was already a known feature and just got fixed/restored, it does not belong in the blotter
-- Fewer strong items beat many weak items; 2–4 highlights is ideal
+- Fewer strong items beat many weak items; 1–3 highlights is ideal
+- If there are no genuinely interesting user-facing changes, do not invent filler highlights
 - Lead with the most impressive item
 
 Plain-English rules (apply always, no matter what):
@@ -80,20 +81,21 @@ Plain-English rules (apply always, no matter what):
 - No codebase-only identifiers, file paths, component names, or PR numbers.
 - Prefer the user-visible *outcome* over the mechanism. Example: "compact account history" (describes the code) → "performant account history" (describes what the user gets).
 - Phrases must read as natural plain English. If a highlight needs a developer to explain it, rewrite it.
-- Broad, general wording is fine when the change is broad or not easy to summarize (e.g. "security fix", "bug fixes", "stability fixes") — that's better than leaking jargon.
+- Avoid broad maintenance labels like "security fixes", "bug fixes", or "stability fixes"; they are usually invisible, redundant, and dull. Only mention security or stability work when the user can perceive the outcome, and phrase it as that outcome.
 - Okay to name concrete user-visible features/areas: "Board pagination", "Video auto-unmute setting", "File upload improvements", "Archive page", "Spoiler tags", "Catalog search".
 
 Good examples (the part **you** write, without the `vX.Y.Z:` prefix):
 - "Board pagination, file upload improvements, mod queue redesign, catalog sorting"
 - "Video auto-unmute setting, platform info on homepage, faster board previews"
 - "In-app desktop updates, opt-in thread auto-refresh, performant account history"
-- "Quote references in replies, post backlinks, security fix"
+- "Quote references in replies, post backlinks"
 
 Bad examples (and why):
 - "Pretext feed sizing" — names an internal library; user has no idea what this is.
 - "Mobile scroll perf" — "perf" is dev shorthand; say "smoother mobile scrolling".
 - "Compact account history" — describes the implementation; "performant account history" describes what the user gets.
 - "Refactor subplebbit selectors" — three dev terms in a row; rewrite or drop.
+- "Security fixes" — generic maintenance label; invisible to regular users and not interesting to read.
 
 Save this string — you will pass it to the blotter script in Step 6.
 

.codex/skills/release/SKILL.md

@@ -56,7 +56,7 @@ Rules:
 - End with a period
 
 Good examples:
-- "This version adds backlinks for quoted posts, a copy user ID menu item, and several bug fixes."
+- "This version adds backlinks for quoted posts, a copy user ID menu item, and clearer reply previews."
 - "This release adds pseudonymity mode support per-reply and fixes timezone display issues."
 
 ### Step 3 — Write the blotter message
@@ -66,11 +66,12 @@ This is a **separate, shorter** summary used for the in-app blotter banner. **Th
 Format rules:
 - Comma-separated key highlights, each a short plain-English phrase (not a full sentence)
 - Omit "This version..." prefix — the blotter script prepends `vX.Y.Z: ` automatically
-- Aim for ~60–80 characters after the version prefix
+- Aim for ~45–70 characters after the version prefix
 - **Only genuinely novel or noteworthy items** — things a user would find interesting or exciting
-- Skip regression fixes (restoring something that previously worked), routine bug fixes, minor z-index/modal/layout tweaks, test improvements, CI changes, and anything that isn't a new capability or a significant user-facing improvement
+- Skip regression fixes (restoring something that previously worked), routine bug fixes, invisible security/stability work, minor z-index/modal/layout tweaks, test improvements, CI changes, and anything that isn't a new capability or a significant user-facing improvement
 - If something was already a known feature and just got fixed/restored, it does not belong in the blotter
-- Fewer strong items beat many weak items; 2–4 highlights is ideal
+- Fewer strong items beat many weak items; 1–3 highlights is ideal
+- If there are no genuinely interesting user-facing changes, do not invent filler highlights
 - Lead with the most impressive item
 
 Plain-English rules (apply always, no matter what):
@@ -80,20 +81,21 @@ Plain-English rules (apply always, no matter what):
 - No codebase-only identifiers, file paths, component names, or PR numbers.
 - Prefer the user-visible *outcome* over the mechanism. Example: "compact account history" (describes the code) → "performant account history" (describes what the user gets).
 - Phrases must read as natural plain English. If a highlight needs a developer to explain it, rewrite it.
-- Broad, general wording is fine when the change is broad or not easy to summarize (e.g. "security fix", "bug fixes", "stability fixes") — that's better than leaking jargon.
+- Avoid broad maintenance labels like "security fixes", "bug fixes", or "stability fixes"; they are usually invisible, redundant, and dull. Only mention security or stability work when the user can perceive the outcome, and phrase it as that outcome.
 - Okay to name concrete user-visible features/areas: "Board pagination", "Video auto-unmute setting", "File upload improvements", "Archive page", "Spoiler tags", "Catalog search".
 
 Good examples (the part **you** write, without the `vX.Y.Z:` prefix):
 - "Board pagination, file upload improvements, mod queue redesign, catalog sorting"
 - "Video auto-unmute setting, platform info on homepage, faster board previews"
 - "In-app desktop updates, opt-in thread auto-refresh, performant account history"
-- "Quote references in replies, post backlinks, security fix"
+- "Quote references in replies, post backlinks"
 
 Bad examples (and why):
 - "Pretext feed sizing" — names an internal library; user has no idea what this is.
 - "Mobile scroll perf" — "perf" is dev shorthand; say "smoother mobile scrolling".
 - "Compact account history" — describes the implementation; "performant account history" describes what the user gets.
 - "Refactor subplebbit selectors" — three dev terms in a row; rewrite or drop.
+- "Security fixes" — generic maintenance label; invisible to regular users and not interesting to read.
 
 Save this string — you will pass it to the blotter script in Step 6.
 

.cursor/skills/release/SKILL.md

@@ -56,7 +56,7 @@ Rules:
 - End with a period
 
 Good examples:
-- "This version adds backlinks for quoted posts, a copy user ID menu item, and several bug fixes."
+- "This version adds backlinks for quoted posts, a copy user ID menu item, and clearer reply previews."
 - "This release adds pseudonymity mode support per-reply and fixes timezone display issues."
 
 ### Step 3 — Write the blotter message
@@ -66,11 +66,12 @@ This is a **separate, shorter** summary used for the in-app blotter banner. **Th
 Format rules:
 - Comma-separated key highlights, each a short plain-English phrase (not a full sentence)
 - Omit "This version..." prefix — the blotter script prepends `vX.Y.Z: ` automatically
-- Aim for ~60–80 characters after the version prefix
+- Aim for ~45–70 characters after the version prefix
 - **Only genuinely novel or noteworthy items** — things a user would find interesting or exciting
-- Skip regression fixes (restoring something that previously worked), routine bug fixes, minor z-index/modal/layout tweaks, test improvements, CI changes, and anything that isn't a new capability or a significant user-facing improvement
+- Skip regression fixes (restoring something that previously worked), routine bug fixes, invisible security/stability work, minor z-index/modal/layout tweaks, test improvements, CI changes, and anything that isn't a new capability or a significant user-facing improvement
 - If something was already a known feature and just got fixed/restored, it does not belong in the blotter
-- Fewer strong items beat many weak items; 2–4 highlights is ideal
+- Fewer strong items beat many weak items; 1–3 highlights is ideal
+- If there are no genuinely interesting user-facing changes, do not invent filler highlights
 - Lead with the most impressive item
 
 Plain-English rules (apply always, no matter what):
@@ -80,20 +81,21 @@ Plain-English rules (apply always, no matter what):
 - No codebase-only identifiers, file paths, component names, or PR numbers.
 - Prefer the user-visible *outcome* over the mechanism. Example: "compact account history" (describes the code) → "performant account history" (describes what the user gets).
 - Phrases must read as natural plain English. If a highlight needs a developer to explain it, rewrite it.
-- Broad, general wording is fine when the change is broad or not easy to summarize (e.g. "security fix", "bug fixes", "stability fixes") — that's better than leaking jargon.
+- Avoid broad maintenance labels like "security fixes", "bug fixes", or "stability fixes"; they are usually invisible, redundant, and dull. Only mention security or stability work when the user can perceive the outcome, and phrase it as that outcome.
 - Okay to name concrete user-visible features/areas: "Board pagination", "Video auto-unmute setting", "File upload improvements", "Archive page", "Spoiler tags", "Catalog search".
 
 Good examples (the part **you** write, without the `vX.Y.Z:` prefix):
 - "Board pagination, file upload improvements, mod queue redesign, catalog sorting"
 - "Video auto-unmute setting, platform info on homepage, faster board previews"
 - "In-app desktop updates, opt-in thread auto-refresh, performant account history"
-- "Quote references in replies, post backlinks, security fix"
+- "Quote references in replies, post backlinks"
 
 Bad examples (and why):
 - "Pretext feed sizing" — names an internal library; user has no idea what this is.
 - "Mobile scroll perf" — "perf" is dev shorthand; say "smoother mobile scrolling".
 - "Compact account history" — describes the implementation; "performant account history" describes what the user gets.
 - "Refactor subplebbit selectors" — three dev terms in a row; rewrite or drop.
+- "Security fixes" — generic maintenance label; invisible to regular users and not interesting to read.
 
 Save this string — you will pass it to the blotter script in Step 6.
 

AGENTS.md

@@ -181,7 +181,7 @@ src/
 
 - If `CHANGELOG.md` or package version changes, run `yarn blotter:check`.
 - If blotter check fails for missing release coverage, add a concise one-line release entry.
-- Blotter entries are shown to 5chan end users, not developers. Every release message must be plain English a non-dev can understand: no internal library names (e.g. `Pretext`, `Zustand`), no dev shorthand (`perf`, `deps`, `refactor`, `a11y`, `CI`), no file paths, and no PR numbers. Prefer user-visible outcomes over implementation details (`performant account history`, not `compact account history`). Broad wording like `security fix`, `stability fixes`, or `bug fixes` is fine when the change is hard to summarize. Full rules and examples live in the `release` skill's Step 3.
+- Blotter entries are shown to 5chan end users, not developers. Every release message must be plain English a non-dev can understand: no internal library names (e.g. `Pretext`, `Zustand`), no dev shorthand (`perf`, `deps`, `refactor`, `a11y`, `CI`), no file paths, and no PR numbers. Mention only the most interesting user-visible changes in the release, if any; do not pad entries with routine maintenance, regression fixes, invisible security/stability work, or generic labels like `security fixes`, `bug fixes`, or `stability fixes`. Prefer dropping a weak highlight to making the entry longer. Full rules and examples live in the `release` skill's Step 3.
 - Ignore manual entries for release coverage logic.
 - Use `yarn blotter` / `yarn blotter:manual` for manual dev messages.
 

public/llms-full.txt

@@ -352,7 +352,7 @@ src/
 
 - If `CHANGELOG.md` or package version changes, run `yarn blotter:check`.
 - If blotter check fails for missing release coverage, add a concise one-line release entry.
-- Blotter entries are shown to 5chan end users, not developers. Every release message must be plain English a non-dev can understand: no internal library names (e.g. `Pretext`, `Zustand`), no dev shorthand (`perf`, `deps`, `refactor`, `a11y`, `CI`), no file paths, and no PR numbers. Prefer user-visible outcomes over implementation details (`performant account history`, not `compact account history`). Broad wording like `security fix`, `stability fixes`, or `bug fixes` is fine when the change is hard to summarize. Full rules and examples live in the `release` skill's Step 3.
+- Blotter entries are shown to 5chan end users, not developers. Every release message must be plain English a non-dev can understand: no internal library names (e.g. `Pretext`, `Zustand`), no dev shorthand (`perf`, `deps`, `refactor`, `a11y`, `CI`), no file paths, and no PR numbers. Mention only the most interesting user-visible changes in the release, if any; do not pad entries with routine maintenance, regression fixes, invisible security/stability work, or generic labels like `security fixes`, `bug fixes`, or `stability fixes`. Prefer dropping a weak highlight to making the entry longer. Full rules and examples live in the `release` skill's Step 3.
 - Ignore manual entries for release coverage logic.
 - Use `yarn blotter` / `yarn blotter:manual` for manual dev messages.
 

scripts/release-body.js

@@ -105,7 +105,7 @@ const downloads = [macSection, winSection, linuxSection, androidSection, htmlSec
 
 // One-liner summary of what changed in this release. Update before each release.
 const oneLinerDescription =
-  'This version adds 5chan developer badges, clearer media and update feedback, better catalog and moderation behavior, improved desktop and P2P reliability, app icons, and security fixes.';
+  'This version adds 5chan developer badges, clearer media and update feedback, better catalog and moderation behavior, improved desktop and P2P reliability, and app icons.';
 
 const releaseBody = `${oneLinerDescription}
 

src/data/5chan-blotter.json

@@ -4,7 +4,7 @@
       "id": "release-0.8.5",
       "kind": "release",
       "timestamp": 1778846400,
-      "message": "v0.8.5: 5chan developer badges, clearer media embed errors, better app icons, security fixes",
+      "message": "v0.8.5: 5chan developer badges, clearer media errors, better app icons",
       "version": "0.8.5"
     },
     {