| name | changelog |
| description | Draft and update the judgesroom.com changelog page from git history between released versions. Use when writing, updating, or reviewing changelog notes, release notes, or web/src/routes/changelog/+page.svelte. |
Changelog
Write operator-facing notes for Judge Advisors and Event Partners. Put them on the changelog page, not in a repo CHANGELOG.md.
Source of truth
- Page:
web/src/routes/changelog/+page.svelte
- Layout and type: match
web/src/routes/privacy/+page.svelte (slate background, centered title, white card, h2 / h3, disc lists, last-updated footer)
- App version:
web/src/lib/app.svelte.ts (App.version). bun run tag-release tags whatever that field says. Bump it before tagging; do not bump it as part of drafting notes unless asked.
What a version section is
Each version is the delta from the previous released tag, not a commit log of the unreleased branch.
Fixed is for things that were wrong in the previous released version. Intra-release development fixes that never shipped do not belong there.
Example: 2.1.0 had no standalone zip. The zip was added during unreleased 2.2.0 work, then LICENSE was added in a follow-up before any 2.2.0 tag. Users never used a zip without the license. That is not a 2.2.0 Fixed item. Fold it into Added if it matters, or omit it.
Same for restoring README screenshots that a 2.2.0 commit briefly removed: net vs 2.1.0 is “README now documents standalone hosting”; do not list the restore.
Omit empty sections. Skip internal-only commits (types, formatting, test-only lock-ins) unless they change operator-visible behavior.
Categories
Use Keep a Changelog names, newest version first:
- Added — new capabilities vs the previous release
- Changed — behavior or docs that already existed
- Deprecated / Removed — only if applicable
- Fixed — bugs in the previous released version
- Security — hardening and vulnerability fixes that shipped vs the previous release
A new feature’s supporting files (license in a new zip, start-script copy) stay under Added.
Voice
- Write for people running an event, not for git history.
- Prefer “Judges can…” / “When access control is on…” over commit subjects.
- Keep English only (privacy page is English-only).
- Dates:
17 August 2026 style under the version heading.
Workflow
- Confirm the previous released tag (
git tag -l 'v*' --sort=-v:refname) and the version being drafted (often App.version or an assumed next tag).
git log <previous-tag>..HEAD --pretty=format:'%h%n%s%n%b%n---'- Group by category using the rules above. Drop intra-release noise.
- Insert a new version block at the top of the card in
web/src/routes/changelog/+page.svelte (after the intro paragraph). Do not rewrite older versions unless asked.
- Update the footer
Last updated: <Month YYYY>.
- Validate the Svelte page (Svelte MCP
svelte-autofixer) before finishing.
Page markup
Reuse the privacy-page shell. Version blocks:
<div>
<h2 class="mb-1 text-2xl font-semibold">2.2.0</h2>
<p class="mb-4 text-sm text-gray-500">17 August 2026</p>
<!-- optional intro paragraph: mb-4 leading-relaxed text-gray-700 -->
<div class="mb-6">
<h3 class="mb-3 text-xl font-semibold">Added</h3>
<ul class="ml-4 list-inside list-disc space-y-2 text-gray-700">
<li>…</li>
</ul>
</div>
<!-- last category in a version: omit mb-6 on the wrapper -->
</div>
<code> for zip names, commands, headers, package names (page CSS already styles code).<strong> for feature names and important limits.- Nested
ul for zip variants under a parent item.
- Intro line stays
All notable changes to judgesroom.com.
- Title:
Changelog | Judges' Room
Do not add i18n. Do not add footer/home links unless asked.
