Nectenda/nectenda

Watch

Fork 0

NEC-120: Fold 0.2.0 into 0.2.1 in the changelog — nobody was ever offered 0.2.0 #179

Merged

nectenda-agent merged 1 commit from worktree-nec-120-fold-020-into-021-in-the-changelog into main

2026-09-25 23:23:59 +01:00

nectenda-agent commented

2026-09-25 23:17:54 +01:00

Collaborator

Task: NEC-120 — https://projectron.nerchure.com/tasks/120

The ledger carried two sections a day apart: 0.2.1 saying "nothing a user can see
— everything that matters is in 0.2.0's notes below", and 0.2.0 carrying the
content.

The directory rejected 0.2.0 and never listed it. The listing still shows
0.1.5 and all 159 downloads predate it, so a reader on 0.1.5 was being pointed at
a release they could not have installed, to read about the changes they are
actually getting.

One ## 0.2.1 section now carries everything, closed by a blockquote recording
that 0.2.0 was published and withdrawn before it was listed. Recorded rather than
deleted — the tag and its release exist, and someone will find them.

The split was our paperwork, not a user's history, and this file already settled
that question: the 0.1.5 entry explains that 0.1.0–0.1.5 are listed together
"because separately they would be five entries about our own paperwork". Same
situation, same shape of answer.

All three generated pages checked rather than assumed, because they are built
three different ways:

Artefact	How	Result
GitHub release body	`sectionMarkdown(ledger, '0.2.1')` at publish time	full content + note, no 0.2.0 heading
Mirror `CHANGELOG.md`	`publishedMarkdown()` via `build-mirror.mjs`	read from the staged tree, not re-derived: one 0.2.1 section
Site `/changelog`	`site/content/changelog.mjs`	entries `0.2.1`, `0.1.5`; the note renders as the top entry's `footnote`, the field 0.1.5's note already uses

Done before the tag on purpose. The release body is generated at publish time
from the section matching the tag, and a tag is not reusable — a changelog
corrected afterwards would leave the wrong text in the release users read.

On the local gate

It failed once, at e2e, on NEC-114's known flake — commands.test.ts,
"offers the right folder-menu items", a 5 s timeout waiting for the menu item.
This commit changes one markdown file and can reach no folder menu, which makes
it a cleaner exhibit than NEC-114's first sighting. The full multi-vault suite
was re-run on the same commit immediately after and passed: 18 files, 91 tests.
Second sighting recorded on NEC-114.

Changelog

NONE

Task: NEC-120 — https://projectron.nerchure.com/tasks/120 The ledger carried two sections a day apart: 0.2.1 saying "nothing a user can see — everything that matters is in 0.2.0's notes below", and 0.2.0 carrying the content. **The directory rejected 0.2.0 and never listed it.** The listing still shows 0.1.5 and all 159 downloads predate it, so a reader on 0.1.5 was being pointed at a release they could not have installed, to read about the changes they are actually getting. One `## 0.2.1` section now carries everything, closed by a blockquote recording that 0.2.0 was published and withdrawn before it was listed. Recorded rather than deleted — the tag and its release exist, and someone will find them. The split was our paperwork, not a user's history, and this file already settled that question: the 0.1.5 entry explains that 0.1.0–0.1.5 are listed together "because separately they would be five entries about our own paperwork". Same situation, same shape of answer. **All three generated pages checked rather than assumed**, because they are built three different ways: | Artefact | How | Result | |---|---|---| | GitHub release body | `sectionMarkdown(ledger, '0.2.1')` at publish time | full content + note, no 0.2.0 heading | | Mirror `CHANGELOG.md` | `publishedMarkdown()` via `build-mirror.mjs` | read from the **staged** tree, not re-derived: one 0.2.1 section | | Site `/changelog` | `site/content/changelog.mjs` | entries `0.2.1`, `0.1.5`; the note renders as the top entry's `footnote`, the field 0.1.5's note already uses | **Done before the tag on purpose.** The release body is generated at publish time from the section matching the tag, and a tag is not reusable — a changelog corrected afterwards would leave the wrong text in the release users read. ### On the local gate It failed once, at `e2e`, on **NEC-114's known flake** — `commands.test.ts`, "offers the right folder-menu items", a 5 s timeout waiting for the menu item. This commit changes one markdown file and can reach no folder menu, which makes it a cleaner exhibit than NEC-114's first sighting. The full multi-vault suite was re-run on the same commit immediately after and passed: 18 files, 91 tests. Second sighting recorded on NEC-114. ## Changelog NONE

nectenda-agent added the

area:plugin

label

2026-09-25 23:17:54 +01:00

nectenda-agent added 1 commit

2026-09-25 23:17:54 +01:00

Fold 0.2.0 into 0.2.1: nobody was ever offered 0.2.0

Release note / release-note (pull_request) Successful in 14s

Details

CI / build (pull_request) Successful in 4m39s

Details

CI / e2e (pull_request) Successful in 5m18s

Details

CI / promote (pull_request) Has been skipped

Details

Deploy site / deploy (push) Successful in 48s

Details

CI / build (push) Successful in 5m2s

Details

CI / e2e (push) Successful in 5m16s

Details

CI / promote (push) Successful in 31s

Details

e45490f934

The ledger carried two sections a day apart. 0.2.1 said "nothing a user can see
— everything that matters is in 0.2.0's notes below", and 0.2.0 carried the
content. But the community directory rejected 0.2.0 and never listed it: the
listing still shows 0.1.5, and all 159 downloads predate it. So a reader on
0.1.5 was being pointed at a release they could not have installed, to read
about the changes they are actually getting.

One section now, carrying everything, under the version people will receive.

The split was our paperwork rather than a user's history, and this file already
settled that question once — the 0.1.5 entry ends by explaining that 0.1.0
through 0.1.5 are listed together "because separately they would be five entries
about our own paperwork". Same situation, same answer, same shape: a closing
blockquote recording that 0.2.0 was published and withdrawn before it was
listed. Recorded rather than deleted, because the tag and its release exist and
someone will find them.

All three generated pages checked rather than assumed, since they are built
three different ways: the release body `publish-plugin.mjs` will generate for
the tag (`sectionMarkdown`), the mirror's `CHANGELOG.md` (`publishedMarkdown`,
read from the staged tree rather than re-derived), and the site's `/changelog`,
which now renders two entries and picks the note up as the top entry's footnote
— the same field 0.1.5's note uses.

Done before the tag on purpose. The release body is generated at publish time
from the section matching the tag, and a tag is not reusable, so a changelog
corrected afterwards would leave the wrong text in the release users read.

Task: NEC-120

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P5JXvAgQ27c4dMFDB2Wu5B

nectenda-agent merged commit e45490f934 into main

2026-09-25 23:23:59 +01:00

No reviewers

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Nectenda/nectenda!179

No description provided.

Rows
Columns