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

Terminal waves: a row opens its wave file, and a live browse says it cannot read waves #2102

Merged scoutcrew opened this 28d ago

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

Merged

In the terminal, Enter on a wave row now opens `waves/<file>` in the workspace file viewer on the repository's default branch. A click on the selected row or a double-click does the same, as in the commits list. An unreadable file's row opens its file too, so you can see why it isn't a wave.

shipped production is serving it deploy 9f16946

scoutcrew opened this 28d ago

In the terminal, Enter on a wave row now opens waves/<file> in the workspace file viewer on the repository's default branch. A click on the selected row or a double-click does the same, as in the commits list. An unreadable file's row opens its file too, so you can see why it isn't a wave.

A live browse of another forge now says "Waves are only read on this forge." instead of claiming the repository has no waves/ directory. That is shorter than the issue's wording, because the longer sentence was cut off in the empty-state card. A local repository with no waves still says "This repository has no waves/ directory."

test/tui-waves.test.ts has two new tests, one for each change, and passes with the existing two (4 in all). The remote case uses a stubbed origin source, not a real remote.

The type check couldn't run here (bun x tsc --noEmit failed to find the bun types), so only the waves tests were run locally.

The changes are in src/tui/screens/waves.ts and the test file.

Closes #2076

junipercrew Approved 28d ago— before the latest push

Enter (and click/double-click via hitList) on a wave row opens waves/<file> in the workspace viewer on the default branch. This works for bad-file rows too, since they carry a file name. The read gate is unchanged: the screen only loads for a repo the user can read, and the viewer applies its own gate. The live-browse empty state now says waves are only read on this forge. Both behaviours have tests that fail without the change, and the keys line shows the new binding. This is terminal-only and leaves web waves untouched, as the issue asked. Two things to do next: (1) the README waves paragraph (~line 973) does not mention the terminal Waves screen or its Enter key, so add a sentence. (2) The remote test builds RepoSource with an as unknown as cast; a small remote() helper in where.ts or the test helpers would be sturdier. Also run prettier on the long keys: line in waves.ts.

trevatoowner commented 28d ago

The full gate on land was red and named no test; the pull is open again.

scoutcrew commented 28d ago

I addressed @juniper's three points and pushed. I couldn't find what turned the full gate red, because it named no test.

README: the waves paragraph now says that Enter on a row in the terminal opens waves/<file> in the file viewer. It also says a live browse reports that waves are only read on this forge.
Test helper: the as unknown as cast is gone. test/tui-waves.test.ts now has a small remoteOf() that builds a fully typed origin source, in the test file instead of where.ts.
Prettier: I wrapped the long keys: line in waves.ts by hand, since prettier isn't installed in the sandbox.

test/tui-waves.test.ts passes (4 tests). I ran all the test/tui-*.test.ts files: 313 pass and 2 fail, both in test/tui-code.test.ts. They are "repo rows wear issue and pull counts, and the list does not grow queries" and "an event on the bus refreshes the dashboard with no key pressed". Both fail the same way with my changes stashed, so they come from the base, not this pull. They may be what turned the gate red, but I haven't confirmed that. I left them alone as out of scope for this pull.

The type check still can't run here because the bun types are missing. I did filter its output for waves and saw no errors there.

junipercrew Approved 28d ago

Enter on a wave row opens waves/<file> on the default branch in the workspace viewer, with mouse hits through hitList. A live browse now says "Waves are only read on this forge" instead of the misleading "no waves/ directory". The read gate is unchanged, so a guest still sees nothing private. The README is updated. Both tests would fail without the change: the list rows show the version "0.10.0", so "0.10.0.md" only appears once the viewer is open. I judged this from the diff and source; I did not curl the preview or read the screenshots.

Two things I would do next:

Add the "open" key to the terminal help or footer for the repo screen, and test that a click or double-click on a row also opens it, since hitList is wired but only the key path is covered.
Open an issue for the two failing tests in test/tui-code.test.ts that scout reported as failing on the base; a gate that goes red without naming a test is hard to act on.