🔀 Merge chore/prune-backlog-and-changelog-rule into main

A merged branch must carry a final commit adding a short summary of the
work under [Unreleased] in CHANGELOG.md. create:release derives the bump
heuristic from that body, so notes have to exist before release day;
rationale in development/workflow.md.

CHANGELOG.md

@@ -7,6 +7,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+- require a short summary under `[Unreleased]` in the changelog before a branch is finished
+
 ## [0.1.6] - 2026-09-15
 
 - restructure the documentation: README.md for users, CONTRIBUTING.md for contributors, and development/ for the decisions, rejected alternatives and known issues

CONTRIBUTING.md

@@ -164,6 +164,10 @@ reaches for by default:
 - **There is no local `npm run publish`, and `publish:publint` / `publish:attw`
   don't go in `check`.** (why:
   [development/publishing.md](./development/publishing.md#ci-only-publishing))
+- **A branch ends with a changelog note:** before `npm run create:finish`,
+  summarize the work under `[Unreleased]` in [CHANGELOG.md](./CHANGELOG.md).
+  (why:
+  [development/workflow.md](./development/workflow.md#changelog-notes))
 - **A decision or its rationale belongs in `development/`, not here.** This file
   holds the actionable rule; `development/<category>.md` holds why, the rejected
   alternatives and the known issues. When you change a rule, update its category
@@ -204,9 +208,11 @@ as a branch that is merged locally:
 1. `npm run create:branch -- <prefix>/<desc>`.
 2. Commit your work (one or more commits, per the tests and style rules above).
 3. `npm run verify` — the definition of done.
-4. `npm run create:finish` to merge the branch into `main` and verify the
+4. Add a changelog note under `[Unreleased]` (see
+   [Rules the tools don't enforce](#rules-the-tools-dont-enforce)).
+5. `npm run create:finish` to merge the branch into `main` and verify the
    result.
-5. Present a handover for review. Once there are no further objections, the
+6. Present a handover for review. Once there are no further objections, the
    maintainer pushes.
 
 When the project is promoted to GitHub, this step becomes a normal pull request

backlog.tasks

@@ -5,8 +5,6 @@ Backlog and tracking for tiny-pattern-ts. Managed in vscode-todotasks format.
 ---
 
 Setup:
-✔ Add gitea release page in CI @high @done
-✔ Manually verify the Gitea release page on a real tag push (needs main) @high @done (9/15/2026, 1:18:15 PM)
 ☐ Split off template into separate package => pi --session 01a07dde-7050-7054-bb36-1606d7eb2bc3 @high
 
 v1.0:
@@ -24,35 +22,6 @@ Bugs:
 Enhancements:
 
 Documentation:
-✔ Clean up CONTRIBUTING.md and README.md, create docs @done
-    ✔ Review existing documentation for accuracy and completeness @done
-    ✔ README.md should be the main entry point for users, and CONTRIBUTING.md should be the main entry point for contributors @done
-    ✔ Move the decisions, shortcomings and known issues out of README.md and CONTRIBUTING.md @done
-        ✔ Decided: category files under development/ (one per area), not ADRs. Each decision is a block with #### Decision (YYYY-MM) / #### Why / #### Rejected / #### Known issue; rationale in development/README.md @done
-        ✔ have a look at other well known repositories for inspiration on how to structure the docs @done
-        ✔ often times a docs folder is used, but this usually contains further user of the library documentation, that is deployed to a website. Deployment is out of scope for now @done
-        ✔ make sure to preserve that information in the new docs @done
-        ✔ development/README.md - index and decision-block convention @done
-        ✔ development/workflow.md - branching, script prefixes, feedback tiers, commits @done
-        ✔ development/tooling.md - toolchain decisions and editor setup @done
-        ✔ development/testing.md - type-driven testing @done
-        ✔ development/ci.md - pipeline, runner image, coverage serving @done
-        ✔ development/publishing.md - release and npm publishing @done
-        ✔ development/library.md - public API design and its limitations @done
-    ✔ README.md @done
-        ✔ I really like the order perl documentation does it: name with a single line description, version, Synopsis, Description, examples, API reference, license @done
-            (example: https://metacpan.org/pod/Scalar::Util)
-        ✔ should include a clear description of the library, its purpose, and how to use it @done
-        ✔ Add usage examples to README.md @done
-        ✔ version needs to be kept in sync with package.json in release.sh @done
-        ✔ Not every section in current README fits in the above order, so put them in another file @done
-    ✔ CONTRIBUTING.md @done
-        ✔ should include instructions for how to contribute to the project, including how to set up a development environment, run tests, and submit pull requests @done
-        ✔ should include guidelines for code style and formatting and a hint, that vscode extensions are suggested from .vscode/extensions.json @done
-        ✔ Not every section in current CONTRIBUTING.md fits in, so put them in another file @done
-
-
-
 ☐ Create `examples/` directory with runnable snippets
 ☐ Add comparison section vs. other TS pattern-matching libs in Readme.md
 ☐ Write migration guide for users coming from discriminated unions
@@ -64,10 +33,7 @@ Workflow:
 
 Maintenance:
 ☐ Serve CI coverage over a tiny self-hosted webserver (replace the zip artifact) @low
-    ✔ Add a minimal dir-listing webserver to the gitea docker setup (e.g. caddy `file_server browse` reusing the existing reverse proxy, or any single-binary static server, lipanski/docker-static-website) @done (9/13/2026, 9:02:37 PM)
-    ✔ drop the `actions/upload-artifact` coverage step in favour of the shared-dir layout @done (9/13/2026, 10:37:22 PM)
     ☐ Explore serving coverage for non-tag pushes (e.g. `main/coverage`, PR previews) @low
-    ✔ Manually verify the coverage was created on a real tag push (needs main) @low @done (9/14/2026, 1:55:03 PM)
     → design: no deploy step in CI; the webserver just exposes the shared directory (decided over Gitea Pages / Codecov — neither confirmed available/ wanted)
 ☐ serve docs over self hosted server @low
     ☐ Add a minimal dir-listing webserver to the gitea docker setup for serving docs (reuse existing reverse proxy)
@@ -77,19 +43,3 @@ Maintenance:
     ☐ Add a minimal dir-listing webserver to the gitea docker setup for serving landing page (reuse existing reverse proxy)
     ☐ CI writes landing page to a shared volume keyed by project + tag (e.g. `/landing/tiny-pattern-ts/<tag>/`)
     ☐ Browse to `…/tiny-pattern-ts/index.html` in the browser
-✔ Stop Gitea CI re-downloading Node on every job @done
-    ✔ Share the warm npm cache with the publish job @done
-    ✔ Bake Node into the CI job image (docker/Dockerfile, container.image in ci.yml) @done
-    ✔ Build/push gitea.e1nsnull.de/tmu/act-ci:26.8.2 and confirm setup-node skips the download @done
-    ✔ Write the `<version>/x64.complete` marker — actions/tool-cache ignores a bare directory, so the probe missed and the download continued @done
-    ✔ Log tool-cache state from the job container to find it (temporary, removed once understood) @done
-    ✔ Guard the invariant in CI (`Assert the baked tool cache is present`) @done
-✘ Enable force-pull for the runner so a changed act-ci image is never missed @low @cancelled
-    → decided against: it is acceptable to miss a runner-side image change, and the image is only rebuilt on a Node bump, which changes the tag anyway. A Dockerfile-only change re-pushed under an unchanged tag is a known issue with a manual `docker rmi` workaround (see development/ci.md).
-✔ Improve CI publish @done
-    ✔ Check whether publish job is only run on tags, if not, guard it @done
-    ✔ Gate only single steps @done
-        ✔ Do not publish to npm, if NPM_TOKEN is not set (e.g. PRs from forks) @done
-        ✔ Do not publish to Gitea — uses the run's automatic `github.token`, so no secret gate is needed @done
-        ✔ Otherwise run the steps @done
-        ✔ Fail the job unless both the Gitea release and npm publish succeeded @done

development/workflow.md

@@ -49,6 +49,36 @@ plus hand-written `git`.
   merge and the next push. `create:branch` requires `main` to match its upstream
   and refuses until it is pushed; push `main` before starting the next branch.
 
+## Changelog notes
+
+The rule is in
+[CONTRIBUTING.md § Rules the tools don't enforce](../CONTRIBUTING.md#rules-the-tools-dont-enforce).
+
+#### Decision (2026-09)
+
+A merged branch carries its own summary under `[Unreleased]` in
+[CHANGELOG.md](../CHANGELOG.md), added before `create:finish`;
+`create:release` graduates it into the tagged section (see
+[publishing.md](./publishing.md)).
+
+#### Why
+
+- `create:release` derives the bump heuristic from the `[Unreleased]` body, so
+  the notes must exist before release day.
+- The contributor has fresh context; at release day the intent of a branch is
+  only its diff.
+- Gitmoji subjects are signposts, not semantic keys, so notes cannot be derived
+  from the history.
+
+#### Rejected
+
+- Generating notes from subjects at release time: subjects carry no parseable
+  type/scope (see § Commit messages).
+- The maintainer writing one summary during `create:release`: reconstruction
+  after the fact.
+- Enforcing it in `create:finish`: the front doors assert git state, not
+  content — and _notable_ is exactly the judgment a tool cannot make.
+
 ## Script prefix convention
 
 The prefix taxonomy is the rule, and it lives in