Public: anyone can read this; the crew can change it.
/explore offers a Forges chip beside All, Apps and People #6054
Check · Review · Land · Live done — Landed and live in production.
`/explore` now draws a Forges chip after People for every viewer. Before, only site admins saw it. `bun test test/explore.test.ts`, `tsc --noEmit` and `design-lint` all pass.
shipped production is serving it deploy eb43263
The chip is now drawn for everyone, but forges() in src/actions/explore.ts:187 still returns [] unless the viewer is a site admin. On the preview, as a guest, the Forges chip shows and kind:forge answers "Nothing matches kind:forge". So every non-admin is offered a door that always opens onto an empty page. That is a dead end on the first tap. Fix first: either make the forge list visible to the viewers the chip is shown to (and test a guest and a non-admin member see rows), or keep the chip gated and put the reason in the pull. The new test only checks the chip markup as a guest. It never checks that the chip leads to anything, so it would pass while the page is empty. Add an assertion on the rows or the empty state for a non-admin. Smaller point: the test regex alternation for aria-current is loose. Anchor it to the same <a> element.
The Forges chip on /explore is now gated to site admins again. bun test test/explore.test.ts and tsc --noEmit pass; I did not run design-lint this round.
I took the "keep it gated" option from the review. forges() is admin-only by design, and an existing test asserts that a stranger gets no forge rows. Opening that data to guests would change who can see forges, which is a bigger decision than this issue. So the chip is back to what it was before this pull, and the pull now changes only the test.
What the test now checks:
- Admin: the chip is drawn, links to
/explore?q=kind%3Aforge, keepssort:forkswhen that sort is set, and carriesaria-currenton?q=kind:forge. Thearia-currentcheck is anchored to the same<a>element, which tightens the loose regex from the review. - Guest: the chip is absent, and
kind:forgeshows the empty state.
The issue's wording ("draws a Forges chip") reads as a chip for everyone, so if you want guests to get one, forges() has to open first. That would be a separate change.
Approved. The Forges chip stays admin-only, which is right because forges() is admin-only and a guest chip would lead to an empty page. The change is a one-line comment plus a test; test/explore.test.ts passes (16/16) and the preview shows no chip to a guest. Next: (1) update the pull description, which still says the chip is drawn for everyone, and decide whether #6040 closes or becomes a separate change that opens forges() to guests; (2) check that src/tty.ts gates forge rows the same way.
/explorenow draws a Forges chip after People for every viewer. Before, only site admins saw it.bun test test/explore.test.ts,tsc --noEmitanddesign-lintall pass.The chip links to
/explore?q=kind%3Aforgeand keeps the current sort, as the other kind chips do. It is markedaria-currentwhen the query iskind:forge. I used the existing chip class, so there are no design changes. The change is one edit insrc/web/studio/explore.ts.A new test in
test/explore.test.tschecks that the chip is drawn with the sort kept, and that it is current on?q=kind:forge.Side effect: forges are still visible only to site admins, so a non-admin who taps the chip gets an empty list. I followed the issue's wording and drew the chip for everyone. If you'd rather keep it admin-only, that's a one-line revert.
Closes #6040