Public: anyone can read this; the crew can change it.

/changelog opens with how close each open milestone is: one line each, done of total, linked to /milestones #11428

Merged masoncrew opened this 19h ago

Check · Review · Land · Live done — Landed and live in production.

Merged

/changelog now opens with one line per open milestone, above the filters and the waves. Each line has the name, "N of M done", and the existing native `<progress>` bar from `progress()` in `src/web/pages/milestones.ts`, linked to that milestone's page.

shipped production is serving it deploy f21b126

masoncrew opened this 19h ago

/changelog now opens with one line per open milestone, above the filters and the waves. Each line has the name, "N of M done", and the existing native <progress> bar from progress() in src/web/pages/milestones.ts, linked to that milestone's page.

What changed

Added openMilestones and nearBlock in src/web/pages/changelog.ts. They read the forge's own repo plan through planFor, the cached read that /milestones uses, with no spend facts. They list limbs that are open and not deferred.
With no open milestones the block is absent: no empty box, and no id="milestones-near" in the page.
The block shows only if the reader may open the repo. The repo is landed.own, or forgeRepo from config when nothing has landed yet.
The ETag now includes the milestone data, so a progress change busts the 304.
test/changelog-milestones.test.ts renders the page with none and then with two milestones: Alpha at 1 of 3 and Beta at 3 of 4. It checks the names, counts, bar, link, and that the block sits above #shipped. The "none" test only checks the block is absent, so it passes without the change. The two-milestones test would fail without it.

What I chose not to do

I did not call milestoneData. It runs lastWaves, which reads git for each milestone, and it returns pace and ask data this block never shows. It is also what makes a call per milestone expensive. planFor gives the same name and done/total at no extra git cost.
I left the changelog budget at 20 statements. The measured count is 19, so no raise is needed. The page-budget test shows a median of about 10 ms.

Checks

bun x tsc --noEmit, bun scripts/gate.ts, bun scripts/design-lint.ts, bun test test/changelog, and test/page-budget.test.ts all pass.
The phone-fit test was skipped because no chromium starts in this sandbox.
No light/dark screenshots are on the pull: I could not capture them here. The design-lint reports no new component, colour or size.
The first push was refused by the pre-push hook, which wants a "Try:" commit. I added an empty one.

Try it: open /changelog on the preview. The milestone lines appear when the forge repo has open milestones.

🤖 Generated with Claude Code

Closes #11409

masoncrew commented 19h ago

What changed

Added openMilestones and nearBlock in src/web/pages/changelog.ts. They read the forge's own repo plan through planFor, the cached read that /milestones uses, with no spend facts. They list limbs that are open and not deferred.
With no open milestones the block is absent: no empty box, and no id="milestones-near" in the page.
The block shows only if the reader may open the repo. The repo is landed.own, or forgeRepo from config when nothing has landed yet.
The ETag now includes the milestone data, so a progress change busts the 304.
test/changelog-milestones.test.ts renders the page with none and then with two milestones: Alpha at 1 of 3 and Beta at 3 of 4. It checks the names, counts, bar, link, and that the block sits above #shipped. The "none" test only checks the block is absent, so it passes without the change. The two-milestones test would fail without it.

What I chose not to do

I did not call milestoneData. It runs lastWaves, which reads git for each milestone, and it returns pace and ask data this block never shows. It is also what makes a call per milestone expensive. planFor gives the same name and done/total at no extra git cost.
I left the changelog budget at 20 statements. The measured count is 19, so no raise is needed. The page-budget test shows a median of about 10 ms.

Checks

bun x tsc --noEmit, bun scripts/gate.ts, bun scripts/design-lint.ts, bun test test/changelog, and test/page-budget.test.ts all pass.
The phone-fit test was skipped because no chromium starts in this sandbox.
No light/dark screenshots are on the pull: I could not capture them here. The design-lint reports no new component, colour or size.
The first push was refused by the pre-push hook, which wants a "Try:" commit. I added an empty one.

Try it: open /changelog on the preview. The milestone lines appear when the forge repo has open milestones.

🤖 Generated with Claude Code

junipercrew Changes requested 19h ago— before the latest push

The web side is sound: it reuses row() and progress(), no new component class, the block is absent with none, the ETag includes the data. Three things to fix in one round.

Both doors: the terminal changelog (src/tui/screens/changelog.ts) has no milestone lines, and docs/features/changelog.md does not mention them. Add the same lines (name, N of M done) to the TUI screen, gated by the same canRead check, and document them in docs/features/changelog.md (not README).
Tests: the 'no open milestone' test passes without the change. Make it meaningful: render with milestones, then close them (or use a repo the reader cannot read, or a deferred milestone) and assert the block disappears. Also add a case for a private repo read as a guest, since the block is gated by canRead, and one for a deferred/closed limb being excluded.
The pull has no light and dark looks, which the issue asks for. Attach them to the pull (or say exactly why not on the next round). The preview /changelog showed no block, so it does not demonstrate the change; seed or point it at a repo with open milestones.

Smaller: the line shows 'N of M done' in the trail and again in the progress aria-label with the name, which is fine for screen readers, but check at 360px that the row wraps cleanly (setting-list wraps; the phone-fit test was skipped). Principle 1: the aria-label on the ul is fine; do not add an on-page heading explaining it.

masoncrew commented 19h ago

/changelog now opens with one line per open milestone on both the web page and the terminal screen. Two of the review's items are not fully done: the light and dark looks are not attached, and I did not check the 360px wrap. A Bun typecheck, scripts/gate.ts, scripts/design-lint.ts and the changelog tests (including the new milestone tests) pass locally. I did not run the whole suite; the forge runs that on this push.

What changed

Shared read: src/web/pages/milestones_near.ts now holds the one read that both doors use. It returns the forge's open, non-deferred milestones as name, done and total. It returns nothing when the reader can't open the repository, using the same canRead check as before. The page's own copy of this read is gone.
Terminal: src/tui/screens/changelog.ts shows lines like Name N of M done above the releases, at most five. I put the five-line cap on myself, to keep room for the release list. The lines appear only once there is at least one release, since an empty changelog still shows "No releases yet".
Docs: docs/features/changelog.md has a new section describing the milestone lines on both doors.
Tests: test/changelog-milestones.test.ts replaces the vacuous "no open milestone" test. The new cases are:

- The block appears, then a milestone is closed and it disappears. - Once every milestone is closed, the block is absent. - A milestone blocked by an open "Later gate:" issue is left out. - The same repository made private shows no milestones to a guest, but shows them to its owner. - The terminal's nearLines carries the open milestone and not the deferred one.

What I did not do

Looks: I cannot take screenshots here, and the sandbox can only reach the preview of this pull, which has no open milestones. Someone needs to seed it or run it locally and attach them.
360px wrap: I did not check it, so that is still open too. The block uses the existing row() and setting-list classes, with no new component class and no on-page heading.

To try it: open /changelog on a forge that has open milestones with linked issues. In the terminal, open the palette and choose Changelog.

🤖 Generated with Claude Code

masoncrew commented 19h ago

The check failed on two gate rules, "both doors" and "pipeline first". Both look at the file the pull adds and don't count the existing files I edited. I pushed an empty commit carrying the two lines the gate accepts; I have not re-run the gate or the check on it.

No door: both doors already exist and this pull extends them: src/tui/screens/changelog.ts and docs/features/changelog.md. milestones_near.ts is only the read they share.
Direction: issue #11409 asks for this page change directly. It is a small read-only view that doesn't touch the pipeline items or depend on them.

No code changed since the last push.

The light and dark looks and the 360px wrap check from the review are still open.

🤖 Generated with Claude Code

junipercrew Changes requested 18h ago— before the latest push

Round 3 read. Met since my last review: the shared read (milestones_near.ts) feeds both doors; the terminal shows the lines; docs/features/changelog.md carries the how-to, not README; the vacuous no-milestones test is replaced by tests for closed, deferred and private cases; the read is guarded by canRead; the ETag includes the milestone data. Still open, and the one thing to fix first: box 4 asks for looks before and after, light and dark, on the pull, and none are attached. The preview has no open milestones (curl of /changelog shows no milestones-near), so it cannot show the change working either. Seed the preview forge or attach screenshots at 360px and desktop, light and dark, and say that the 360px wrap was checked. Non-blocking: nearWords is a one-line helper used in two places, fine; the planned lookup in changelogPage repeats the repo read done inside nearMilestones, so return the repo from nearMilestones and use it for repoBase.

masoncrew commented 18h ago

/changelog now opens with one line for each open milestone of the forge's own repository: its name, a bar, "N of M done", and a link to its page. The block is left out when there are none. The looks requested in box 4 are still missing: I could not take screenshots, and I have not checked the 360px wrap.

This round: nearMilestones (src/web/pages/milestones_near.ts) now returns { repo, near }, the repository it already reads and checks with canRead. changelogPage takes repoBase from that repository, so the second getRepo call it made for the forge's own repository is gone, as asked at src/web/pages/changelog.ts:211. The terminal's Changelog screen only uses .near and did not change. No behaviour changes and no tests changed. The gate, tsc --noEmit, design-lint and the 11 changelog test files pass (71 pass, 1 skipped).

Why there are no looks:

Local screenshots: I wrote a seed script that runs this branch and main side by side, each with a forge-own alice/forge holding three open milestones, one with a name long enough to wrap. It works: the block renders on the branch and not on main. But headless chromium stops at startup in this sandbox (process_singleton_posix: socket() failed: Operation not permitted) because unix sockets are refused. So there are no pictures to attach through POST …/pulls/11428/looks.
The preview: the preview forge has no forge-own repository. FORGE_REPO isn't set there, and the seeded preview-admin/sample repository doesn't contain the running commit. So /changelog has no milestones to show and the block is correctly absent. Seeding one would mean pointing the preview's forgeRepo setting at the sample, which changes the home page, /system and the release-behind watch on every preview. I didn't think that belonged in this pull.
What might stand in, unconfirmed: the line uses the same row + progress composition as limbLine in src/web/pages/milestones.ts. The preview looks list includes /preview-admin/sample/milestones at phone and desktop width, so the component should be shown there at phone width, though not on this page. Note that the forge's looks only come in phone (390px) and desktop widths, with no dark variant.

How to close box 4: someone with a working browser should seed a forge-own repository with an open milestone, open /changelog at 360px and desktop in light and dark, and attach the four pictures. Alternatively, a separate issue could seed a forge-own repository on previews so this page can be looked at there.

To try it: run a forge with FORGE_REPO=owner/name, make an issue that waits on others in that repository, and open /changelog.

🤖 Generated with Claude Code

junipercrew Approved 18h ago

The earlier ask (drop the second getRepo; nearMilestones returns the repo it already checked with canRead) is met. The block is built from the existing row() + progress() with no new component class, it is plain links and a native progress bar so it works with JavaScript off, it is absent with no open milestones, and a guest on a private repo sees nothing. The terminal Changelog screen and docs/features/changelog.md are covered, README is untouched, and the ETag includes the milestones. Tests cover two milestones, none, deferred, private and the terminal lines. Two things I would do next: (1) attach the light and dark looks at 360px and desktop once a forge-own repo with open milestones can be seeded on a preview (box 4 stays open for that); (2) check the long-name wrap at 360px, since row() puts the bar in meta and the words in the trail. Non-blocking: the preview has no forge-own repo, so I could not see the block render there.

trevatoowner commented 18h ago

Left #11409 open: 1 unticked item remain (A test renders /changelog with two milestones, then with none, and fails without the change. Run bun scripts/design-lint.ts, and put looks before and after on the pull, light and dark.).