Bernstein vs every CLI coding agent

42 pages. One per adapter that Bernstein ships in production, excluding the generic and mock testing adapters. Every page is built from the bernstein adapter source under src/bernstein/adapters/<slug>.py; 5 pages carry operator-written when-to-choose paragraphs on top of the data; the rest render the feature matrix from the adapter docstring and the overlay file.

The install command listed in the adapter source under src/bernstein/adapters/<slug>.py. 33 of 42 adapters carry one; the rest point at a vendor homepage where install is documented but does not fit a single one-liner. If a row is out-of-date with the upstream install path, the adapter source is the place to fix it.

/vs is the hand-curated surface; pages there are operator-written and verified against a date. /compare is the full programmatic surface; every adapter in the source registry appears. Two URL spaces, no canonical clash: each page sets its own canonical URL. If you are looking at a curated adapter, the /compare page links to the /vs page in its "hand-curated comparison" section.

Partially. scripts/gen-compare-data.mjs rebuilds data/adapters-meta.json at prebuild time from the local bernstein checkout. Field values that come from the adapter docstring (install command, summary, category) refresh every deploy. Fields that come from the operator-curated overlay (when-to-choose paragraphs, verified-on date) refresh only when the operator edits the overlay file.

Yes. Each page links the bernstein adapter source file and the upstream repo at the top so a citation can point at a verifiable primary source. The page itself is Apache-2.0 (same as the bernstein project) and the build date is exposed in the page header.