Public: anyone can read this; the crew can change it.
/:owner/:name/waves lists a repository's waves newest first, each line linking to its file #1879
Check · Review · Land · Live done — Landed and live in production.
`/:owner/:name/waves` now lists a repository's waves newest first, each line linking to its file. `test/waves-page.test.ts`, `test/asks.test.ts` and `test/check-list.test.ts` all pass. I could not run the type check: `tsc` fails here with "Cannot find type definition file for 'bun'", because `bun install` did not put `@types/bun` in `node_modules`. The forge's check will type-check it.
shipped production is serving it deploy 7cfd21c
The page itself is sound. loadRepo gates it, so an outsider gets the same 404 as on /branches. Every value goes through html and is escaped, and the test proves a <script> headline comes out inert. Nothing is built from user text: the only rev is the default branch, and it passes assertBatchSafe. File size and file count are capped. Versions sort numerically. I ran test/waves-page.test.ts and test/asks.test.ts at e3243f2d: 11 pass, 0 fail. I found no security problem.
It misses two items on the review list, and those block it:
- Both doors (fix this first). The terminal can't show waves.
src/tui/screens/already has repository screens (repo.ts,refs.ts,commits.ts), so add a waves list there. PutreadWavesbehind a small module the page and the terminal both import, e.g.src/story/waves.ts, so the terminal doesn't import fromweb/pages. It should show the same rows in the same order, run the samecanReadgate, and come with a test. - README and reachability. The README doesn't mention
/:owner/:name/waves, and nothing links to it: the header puts it under the Code tab, but no tab or link leads there. Add a line under Cut a wave in the README. Add one link to the page, e.g. from the Cut a wave row in settings or the repository's Code view, so a person can find it without typing the URL.
The preview and the screenshots were blocked from my sandbox, so I couldn't judge this by eye. The tests stand in for that here.
Minor, no need to block on it: see the line comment on MAX_FILES.
/:owner/:name/waves now has a terminal door, a link a person can find, and a README line. The sort-before-truncate fix is in too. I ran test/tui-waves.test.ts, test/waves-page.test.ts and test/tui-code.test.ts. 19 passed and 1 failed. I did not get a clean type check: tsc here reported "Cannot find type definition file for 'bun'", so the forge's check will be the first real one.
The failure is "repo rows wear issue and pull counts, and the list does not grow queries" in test/tui-code.test.ts. It counts dashboard queries and this change doesn't touch the dashboard, but I couldn't confirm it fails on main too. My attempt to stash and compare did nothing.
What changed
- Shared module:
readWaves,byVersionDescandWaveEntrymoved tosrc/story/waves.ts. The page and the terminal both import it, so neither reaches intoweb/pages. - Terminal screen:
src/tui/screens/waves.tsaddswavesScreen, opened withVin a repository workspace and listed in the key help. It shows the same rows in the same order, with unparsable files last and their reason. It runscanRead(f.db, repo, f.user)before reading anything, and a live browse of another forge shows "No waves yet". - Reachability: the settings Cut a wave card now links to "See the waves so far". The README's Cut a wave entry now covers the page and the
Vkey. MAX_FILES(sentinel's line comment): files are now sorted by version before the cut at 300, so the newest waves are the ones kept.- Tests:
- test/tui-waves.test.ts checks the terminal shows the same order, with the bad file last.
- It also checks that a user who can't read a private repo sees no waves there.
- test/waves-page.test.ts gains a test for the settings link.
Left out
- No cache for the per-object reads. At about 120 waves it's fine, so I'm keeping it simple until timings say otherwise. If needed, key it on the
waves/tree oid. - No test for the 300-file cut. It would need over 300 committed fixtures.
- The link is only in settings, which only admins can reach. I didn't add one to the Code view.
Vopens the list but doesn't open a wave file.
Try it
- On the web, open
/<owner>/<repo>/settingsand follow the link under Cut a wave. - In the terminal, open a repository and press
V.
🤖 Generated with Claude Code
/:owner/:name/waves lists a repository's waves newest first, each linking to its file. The waves now also show in the terminal (a V screen) and on the settings page, through a shared story/waves.ts. The list is truncated after sorting.
The last check failed because test/tui-waves.test.ts wasn't listed in scripts/gate.ts. I added it to GATE in this push. bun scripts/gate.ts now passes, and so does that test file (2 tests). I didn't run the type check or the rest of the suite. The forge's check will run those on this push.
To try it, open /:owner/:name/waves on the preview.
🤖 Generated with Claude Code
The security side holds. The page gates through loadRepo (canRead on the verified identity) and a private repository gives an outsider the same 404 as /branches, which is tested. The terminal screen runs the same canRead before it reads anything. Headlines and reasons go through html and are escaped, which is tested. The route is GET-only, nothing is built from user text, and blob reads are capped by the tree's object size. I could not open the preview or the screenshots from this sandbox, so this verdict comes from the code and the tests.
One behaviour has no test, and it is buggy: the version order in byVersionDesc. That order decides which waves survive the 300-file cut, and it is what both doors show. Right now:
- Pre-releases are compared as strings, so
1.0.0-rc.2sorts as newer than1.0.0-rc.10. - A file whose name is not a version (
broken.md,notes.md) makesnumreturn[NaN], and the comparator returns NaN. That makes the sort before the cut inconsistent, so with enough files a stray name can push real waves out of the 300 kept.
Fix first: make byVersionDesc total. Names that are not versions go last. Compare pre-release identifiers dot by dot, numerically where both are numbers. Add a direct unit test of byVersionDesc covering 0.10.0 > 0.9.0, 1.0.0 > 1.0.0-rc.1, 1.0.0-rc.10 > 1.0.0-rc.2, and a non-version name sorting after every version. That also covers the cut without 300 fixtures: the cut is just sort(byVersionDesc).slice.
byVersionDesc in src/story/waves.ts is now a total order, and both doors use it for the 300-file cut and the display order. The new tests and the existing waves page and terminal tests pass, and the type check is clean. I did not run the full suite; the forge's check will.
- Non-versions last: a name that isn't a version, like
brokenornotes, sorts after every version, and those names sort among themselves by name. The comparator no longer returns NaN, so a stray file can't push real waves out of the 300 kept. - Pre-releases: identifiers compare dot by dot as in semver §11. Numeric identifiers compare by value and rank below text ones, and a longer identifier list beats a shorter one when the shared part is equal. So
1.0.0-rc.10now sorts ahead of1.0.0-rc.2. - Looser parse: a version may omit the minor or patch part (
1.0), which I treat as1.0.0, so a name like that is still ranked as a version.
The new test/waves-order.test.ts calls byVersionDesc directly. It covers 0.10.0 > 0.9.0, 1.0.0 > 1.0.0-rc.1, 1.0.0-rc.10 > 1.0.0-rc.2, and non-version names after every version. It also sorts a mixed list and slices it the way the cut does. I added the file to GATE in scripts/gate.ts.
🤖 Generated with Claude Code
Taken over by nobody; stopped @scout.
Parked by the crew: this issue started its day's share of runs without landing, so nothing more starts here until a person says what to try.
I merged main into this branch and pushed it. I didn't run the full check, and I haven't seen the forge's verdict on the merge yet.
Both conflicts came from main adding things next to the waves work, so I kept both sides:
scripts/gate.ts: the gate list now has the waves tests (waves-page,waves-order,tui-waves) and the testsmainadded (domain-drill,conflicts,lands-once,conflicts-tui,tui-deploys,tui-decider).src/tui/screens/workspace.ts: the workspace keeps both bindings.Vopens waves anddopens production deploys. The help list shows both.
I ran the type check, which is clean. The waves, deploys and gate tests also pass (26 tests across 5 files).
Approved. Both blockers from the last round are fixed, and so is the ordering bug.
- Security: the page gates through
loadRepo, which runscanReadon the verified identity. A private repository gives an outsider the same 404 as/branches, and a test covers it. The terminal screen runs the samecanReadonf.userbefore it reads anything, and a test shows a non-reader sees nothing. Headlines and reasons are escaped throughhtml, and the<script>test proves it. The route is GET-only. The only rev is the validated default branch, throughassertBatchSafe. File names in hrefs areencodeURIComponent-ed. File count and size are capped. Nothing is built from user text. - Order:
byVersionDescis now a total order (non-versions last, semver §11 pre-releases). It runs before the 300-file cut, andtest/waves-order.test.tscovers it. - Both doors:
Vin a repository opens the same rows in the same order through the sharedsrc/story/waves.ts, with a test. The README says how to use both doors. Settings links to the page from Cut a wave. - Tests: all three new files are in
GATE, and the pull is green.
I could not open the preview or the screenshots from this sandbox, so this verdict comes from the code and the tests.
Two small gaps in the terminal door are left; they don't block, and #2076 tracks them: a row does not open its wave file, and a live browse claims "no waves/ directory". See the line comment.
The full gate on land was red and named no test; the pull is open again.
The full gate on land was red; the pull is open again. Red tests:
- the crew, with a stand-in Claude Code: network errors > a wrap-up that lost its connection asks again and lands the work
- the crew, with a stand-in Claude Code: network errors > a wrap-up that lost its connection asks again and lands the work [4542.66ms] [shard 3]
/:owner/:name/wavesnow lists a repository's waves newest first, each line linking to its file.test/waves-page.test.ts,test/asks.test.tsandtest/check-list.test.tsall pass. I could not run the type check:tscfails here with "Cannot find type definition file for 'bun'", becausebun installdid not put@types/buninnode_modules. The forge's check will type-check it.waves/*.mdfrom the repository's default branch and parses each file withparseWave. Each line shows version, date and headline, server-rendered and escaped. Versions sort numerically, so 0.10.0 comes before 0.9.0, and a release comes before its own pre-release. Each line links to/:owner/:name/blob/<default branch>/waves/<file>.waves/: a file that doesn't parse is listed after the good ones, with its reason, and doesn't break the page. A repository with nowaves/gets a one-line "No waves yet".test/waves-page.test.ts, added toGATE): the order, a headline with<script>coming out inert, an unparsable file shown with its reason, the empty state, and a private repository refused to an outsider.test/asks.test.ts: it is green on this branch alongside the new test. This change touches nothing the asks page reads, so I found no cause for the two earlier red runs and did not look further.To try it, open
/<owner>/<repo>/waveson the preview.Closes #1855