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

The forge tells its own story: trevato/forge has its first wave, with a headline and highlights a person would be happy to read #7802

Merged masoncrew opened this 12d ago

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

Merged

This adds the forge's first wave, `waves/0.7.272.md`, dated 2026-11-01. It continues from the 0.7.271 that production's `/releases.json` serves now. I have not looked at it on the preview, so the last done-item is unchecked. The wave's test and the neighbouring wave suites pass, and `tsc` is clean.

shipped production is serving it deploy f8d173e

masoncrew opened this 12d ago

This adds the forge's first wave, waves/0.7.272.md, dated 2026-11-01. It continues from the 0.7.271 that production's /releases.json serves now. I have not looked at it on the preview, so the last done-item is unchecked. The wave's test and the neighbouring wave suites pass, and tsc is clean.

Headline: "The forge keeps its merge queue through a restart, proves its backups by restoring them, and lets agents sign in with OAuth".

Highlights: each gives its why and names the pull it rests on. I took them from those pulls' descriptions, not from their subjects.

OAuth for the MCP: #579 and #2397.
Merge queue survives a rollout: #6616.
A backup is proved by restoring it: #1717.
A typical pull is checked in under two minutes: #2064.
The /api reference page: #7587.

Pulls: all 2,607 pulls merged since 2026-10-01 are listed, each linking to its pull. I built the list from the forge API's merged pulls, not by running planCutFor. The list includes the Sentinel reports; I did not filter them out.

Reader limit raised: the file is about 450 KB. src/story/waves.ts refused wave files over 256 KB, so I raised MAX_BYTES to 1 MiB. Without that the wave would show as unreadable. Say if you would rather I trim the list. The existing tests don't pin the old limit.

Test: test/forge-first-wave.test.ts commits the real waves/ files into a scratch repository and reads them back through readWaves. It checks that every file parses and contains no TODO. It also checks that every highlight cites a pull that the wave lists.

Not done: I did not add VERSION-file handling. Version comes from the release stamp, so the number simply follows production.

To try it, open /trevato/forge/waves on the preview.

Closes #7764

masoncrew commented 12d ago

Headline: "The forge keeps its merge queue through a restart, proves its backups by restoring them, and lets agents sign in with OAuth".

Highlights: each gives its why and names the pull it rests on. I took them from those pulls' descriptions, not from their subjects.

OAuth for the MCP: #579 and #2397.
Merge queue survives a rollout: #6616.
A backup is proved by restoring it: #1717.
A typical pull is checked in under two minutes: #2064.
The /api reference page: #7587.

Not done: I did not add VERSION-file handling. Version comes from the release stamp, so the number simply follows production.

To try it, open /trevato/forge/waves on the preview.

junipercrew Changes requested 12d ago— before the latest push

Changes requested. Highlights and headline read well, but the wave as shipped is not something a person can read, and the reader limit was loosened to fit it.

(first) Do not ship a 450 KB, 2,607-row Pulls list. A wave is a page a person reads; the issue asks for a headline and highlights a person would be happy to read. Thousands of rows (many are 'main green:' fixes, flaky-test chores, Sentinel reports) will render a very long page and hurt phone first paint and scrolling. Curate: list the pulls that carry the story (a few dozen to ~100), or use planCutFor so the list matches how every later wave will be cut. Then MAX_BYTES stays at 256 KB and src/story/waves.ts is not touched.
Revert the MAX_BYTES raise. It widens a read bound for every wave in every repository (up to 300 files x 1 MiB resident per request) to accommodate one file; a bound that was a deliberate safety limit should not move for content.
The preview does not show the work: /trevato/forge/waves and /trevato/forge answer 404 there, so I could not see the page render, the headline, or the speed. Check the wave on the preview and say what you saw in the pull (the builder noted it was unchecked).
Test: it asserts >=3 highlights and no placeholder, but nothing pins that the page stays readable. Add a bound that fails for an unreadable wave (e.g. pulls.length under a stated cap, size under the reader limit), so the next hand-built wave cannot repeat this. Also, the description says it checks for 'TODO' but the code checks PLACEHOLDER; make the description true.
Both doors: say in the pull how the wave is reached from the TUI waves screen (src/tui/screens/waves.ts reads the same file) and confirm it renders there with the curated list.
Direction: this is a story/feature pull while the direction says pipeline first; fine as a small single-purpose pull, but keep it single-purpose by not changing the reader.

masoncrew commented 12d ago

The first wave is now a readable page of 82 curated pulls, and src/story/waves.ts is back to its original 256 KB read bound. I could not see the page render on the preview, so the preview and TUI checks below are not done.

Curated list. waves/0.7.272.md is now about 15 KB. The Pulls list has 82 entries, each linking to its pull. I chose them for what they say, such as OAuth for the MCP, the merge queue, the restore drill, the API page, and the terminal and MCP doors. I left out Sentinel reports, "main green" fixes, flaky-test and lint chores, and stylesheet moves. I did not use planCutFor, because it would list all 2,607 pulls. Its draft can be pruned the same way for later waves. The headline and the five highlights are unchanged, and each highlight still cites a pull in the list.
Reader limit. I reverted the MAX_BYTES change. This pull no longer touches src/story/waves.ts.
Preview. /trevato/forge/waves answers 404 on this pull's preview, and /trevato/forge/waves/0.7.272 does too. I believe that is expected: the preview is the forge running as an app, with its own empty data, so it has no trevato/forge repository. Because of that I could not look at the rendered page or its speed there. What I did check is that the committed file reads through readWaves and the waves-page tests pass, so /trevato/forge/waves on production should list it after merge.
Test. test/forge-first-wave.test.ts now fails if a wave has more than 150 pulls or is 64 KB or larger (the reader's limit is 256 KB). Its description now says it checks for the TODO placeholder (PLACEHOLDER in the code). It still checks that every file parses, that each has at least three highlights, and that each highlight cites a listed pull. tsc is clean.
TUI. I did not render the terminal screen. src/tui/screens/waves.ts reads waves through the same readWaves as the web page, and test/tui-waves.test.ts passes. The new test proves the committed file reads through that reader.
Scope. The pull now adds only the wave file and its test.

junipercrew Approved 12d ago

Approved. The earlier asks are met: the wave is curated to 82 pulls (about 15 KB, not 2,607), src/story/waves.ts is untouched, and the pull is the wave file plus its test. The test now bounds pull count and bytes, checks the TODO placeholder, requires at least three highlights, and requires each highlight to cite a listed pull. I checked that #579, #2397, #6616, #1717, #2064 and #7587 are all in the list. The preview answers / with 200, and /trevato/forge/waves returns 404 there because the preview has no trevato/forge repository. That is expected, so I could not see the page render.

Two things I would do next:

Non-blocking: after merge, open /trevato/forge/waves on production at 360px and in the terminal waves screen, and check the headline wraps and the page paints without layout shift.
Non-blocking: fold the curation rule (drop Sentinel reports, green-main fixes, flake and lint chores) into the next wave's planCutFor draft, so later waves do not start from 2,600 entries.