Explore a `pmndrs-docs browse` terminal reader

Question

Should the generator grow a browse mode — land in a menu of pmndrs libraries, then navigate one library's documentation without leaving the terminal?

Verdict: viable, shape undecided

Prototyped in three shapes on prototype/cli-browse (off npm-cli, #574). Throwaway by construction — do not merge. pnpm browse runs it; < and > cycle the variants. Every run is against the real published corpus: 196 pages across react-three-fiber, drei and zustand.

Commits: 6cf61b3 the OpenTUI cut, c394edc the Ink port.

What the prototype settled

• OpenTUI is bun-only. @opentui/core@0.5.4 ships an index.node.js and per-platform native packages, and still throws OpenTUI native FFI is not available for this runtime yet outside bun. It cannot ship inside npx @pmndrs/docs without a bun build --compile standalone binary per platform. B and C were ported to Ink, which runs on plain node.
• The data layer is nearly free. One GET of llms-full.txt per library returns everything — 200 KB for drei — as <page path title><![CDATA[…]]></page>. Parsing is three lines, and it caches to disk.
• The registry cannot leave Next. Blocks any implementation — #580.
• Sandpack collapses to a marker. The live r3f demos have no terminal form; they render as ▶ live demo — <folder> [o] open in browser, and o hands the page to the browser. Same answer in all three shapes, and it reads better than expected.
• Ink gives you a renderer, not widgets. Box, Text, useInput, flexbox — no select, no text input, no scroll container. browse.prototype.list.tsx is a hand-written windowed list, and each pane slices its own lines; about sixty lines in total. Third-party components exist (ink-select-input, ink-text-input) but sit outside the package and are peered to ink >=5, with no statement about 7.

Reusable vs throwaway

Two modules are validated and independent of whichever shape wins — these are the ones that would move into real code:

• src/cli/browse.prototype.corpus.ts — fetch, parse, disk cache
• src/cli/browse.prototype.markdown.ts — MDX → styled lines

Everything else (the three UIs, the switcher, the --snapshot / --query / --open capture flags) is decision material, not product.

Open before any implementation

1. Which shape. A is the only one shippable today with no further work. B and C both need Ink and a hand-written list and scroll pane (~60 lines, already written).
2. Ranking in C. Subsequence matching is noisy — scroll still surfaces subscribeWithSelector. Real ranking is the work that shape adds. Note that the matching itself is ~15 lines of plain JS over 196 in-memory entries; it needs no toolkit and no full screen, so a search verb can be built on A's mechanics.

Start with src/cli/browse.prototype.corpus.ts and src/cli/browse.prototype.markdown.ts, then review the prototype shapes on prototype/cli-browse and the Ink constraints described here. The work is not ready for implementation until a browse shape and, for the palette option, ranking approach are decided; completion would require those decisions and a defined product implementation.