From 46053cebefbe5d23bbbf8471ffd0c83f6af38e90 Mon Sep 17 00:00:00 2001 From: Devin Michael Date: Tue, 8 Sep 2026 10:38:58 +0700 Subject: [PATCH] Document the GitHub release body convention The changelog's releasing paragraph covers the three version markers and the tag, but never said what goes in the release body. Each release session guessed: 1.1.2 and 1.3.0/1.4.0 pasted the changelog section verbatim, 1.1.3 reworded it under its own heading, and 1.2.0 wrote a summary. `make release` and the ship flow do not touch `gh release`, so there is no template to fall back on. Changelog entries have also grown denser, so the paste that was tolerable at 1.1.2 made 1.3.0 and 1.4.0 unreadable. Record the summary format the 1.2.0 release used. Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index b4ac5fc..52cb8c4 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,8 @@ All notable public Spark changes should be recorded here. Spark follows human-readable release notes rather than a package-manager version contract. The release version is stored in `manifest.json` and mirrored in [README.md](README.md) and `CLAUDE.md`. When releasing, update all three version markers, add a dated changelog section, and publish a Git tag or GitHub release when the repo is ready for external consumers to pin versions. +The GitHub release body is a summary, not a copy of the changelog section. Write one sentence framing the release, then a `### Highlights` list of at most five bullets, then a link to `CHANGELOG.md` at the release tag for the full record. A changelog entry stays as long as the change needs it to be, but the release page is scanned rather than read, so pasting a long entry into it produces notes nobody can follow. That is what happened to 1.3.0 and 1.4.0, both since rewritten. Use the 1.2.0 release as the reference format. + ## 1.4.0 - 2026-09-08 - Theme Settings > Style gained nine token-shaped settings: Layout holds `body_bg_color`, `border_color`, `radius_control`, `radius_card`, `section_padding`, `content_gap` and `container_max_width`; Type Scale holds `heading_scale` and `body_size`. `layouts/base.html` bridges them into `:root` with the same guarded pattern the font and colour settings use (noun-first properties such as `--control-radius` and `--section-padding-y`), and `css/input.css` registers namespace-first `@theme` keys that read them with today's values as fallbacks (`--radius-control: var(--control-radius, 4px)`); the names differ on purpose, because a key that reads a property of its own name is a self-reference and the bridge disconnects. The default option of `section_padding`, `content_gap`, `heading_scale` and `body_size` emits nothing. Component rules now read the bridge directly: body background and font-size, `.btn` radius, `.btn-secondary` and `.product-card-bordered` border colour, `.container` max-width, `.product-card` radius (with `overflow: hidden` so a rounded card clips its image), and the `.product-grid` / `.category-grid` gaps. In the six homepage sections the live branches swap design-decision literals for token utilities: `py-section-y md:py-section-y-md` on the four standard sections and `py-band-y md:py-band-y-md` on the promo band, `gap-content-md md:gap-content-lg` on the featured product columns, `text-display md:text-display-md` on the hero heading, `text-h1 md:text-h1-md` / `text-h2` / `text-h3` on the section headings, promo heading and featured product title, and `rounded-card` on the featured image and category tiles. Every `--text-*` key carries Tailwind's own line-height ratio, so the swap changes neither size nor leading. Placeholder and empty-state chrome stays literal because it signals missing configuration rather than the merchant-facing design language. A fixture render of the homepage before and after, at default settings, shows 0 computed-style differences and 0 differing pixels at 1280 and 375, for both a populated homepage and a fresh store rendering only `settings_data.json`. `tests/test_style_tokens.py` pins the fallbacks, the bridge conditions, the live-versus-placeholder split and the nine setting ids. `assets/main.css` grew from 48219 to 50298 bytes (#56).