History

Orkuncakilkaya 7e07573026 All checks were successful bootstrap / cfree-fixpoint (push) Successful in 21s Details ci / build-and-test (push) Successful in 2m51s Details commit-lint / conventional-commits (push) Successful in 2s Details docs / build-and-deploy (push) Successful in 32s Details fix(docs): restore the token cards on the generated site Clicking a keyword, type, builtin or namespace method in a code sample is supposed to open a summary card for it. The script that builds those cards never went away; its stylesheet did. The site redesign split item.css into base.css and docs.css and filed the card chrome — .hovercard, .hc-, .tok, .kind-badge — under docs.css. Only the four reference page kinds link that file. The landing page links base.css and site.css, so a click there appended an unstyled, position:static div to the end of the document: built, filled with the right text, and invisible. The card chrome now sits in base.css beside the .t- token colours it belongs with, which every page links. It is also position:fixed rather than absolute, matching the viewport coordinates positionCard() reads out of getBoundingClientRect() — absolute put the card an entire scroll offset away from its token on any reference page read past the fold. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-09-05 14:41:10 +03:00
..
ci-runner-dns.md	docs(ci): document the runner network a self-hosted CI needs	2026-09-05 02:57:09 +03:00
commit-lint-force-push.md	docs: rewrite the README for someone meeting the language	2026-09-05 14:25:07 +03:00
docs-deploy-concurrency.md	ci(docs): serialise the pages deploy	2026-09-05 03:37:33 +03:00
docs-token-cards.md	fix(docs): restore the token cards on the generated site	2026-09-05 14:41:10 +03:00
per-artifact-checksums.md	fix(release): per-artifact checksums so a release can span hosts	2026-09-05 14:14:00 +03:00
readme-rewrite.md	docs: rewrite the README for someone meeting the language	2026-09-05 14:25:07 +03:00
README.md	fix(release): keep a changeset's markdown in the changelog	2026-09-05 01:47:49 +03:00

README.md

Changesets

A changeset is one small Markdown file describing a single user-facing change, dropped in this directory. x release consumes every changeset here into a new CHANGELOG.md section, bumps VERSION, and deletes the consumed files.

Format

bump: minor
type: feat
One or more lines describing the change, in the past-agnostic imperative used in
the changelog. Markdown is fine.

bump: — major, minor, or patch (SemVer). The release version is bumped by the highest level among the pending changesets (unless x release <level> overrides it).
type: — the Conventional Commit type (feat, fix, perf, docs, …). It decides which group the change lands in: feat → Features, fix → Fixes, perf → Performance, and so on, in that order. A type with no known heading gets one named after itself.

Writing the body

The body is markdown and reaches the changelog as markdown: it becomes one list item, with continuation lines indented to stay inside it. Nested bullets, blank lines between paragraphs and inline code all survive.

bump: minor
type: feat
**Tiled map support** — load and draw Tiled maps.

- **TMX/TSX** — the XML formats, decoded to the same intermediate as JSON.
- **Collision** — the `collision` layer projects onto the engine tilemap.

Lead with the thing that changed, not with the mechanism. A reader scanning the release should be able to stop after your first clause.

Adding one

Create a file with a short, unique name, e.g. changes/regex-namespace.md. Any filename works except this README.md, which the release step always skips.

Preview how the next release will read before cutting it — this writes nothing:

x release --dry-run