Coverage
Every vendor, how complete its twin is, and why it is built in that order.
The full table is generated: generated/INDEX.md, one row per
vendor, rebuilt by bun scripts/index.ts and drift-checked in the gate. This page says how to
read it.
Where the list comes from
The catalog grows off a survey of the top 100 Node and top 100 Python application repositories on GitHub: every external vendor any of them talks to, found from their dependencies, their env names and their source. A vendor's demand is how many of those repositories need it. Twins are built most-demanded first, so the order of the table is the build order, and the queue of what to build next is derived from it, never hand-listed.
The columns
| column | meaning |
|---|---|
| vendor | the vendor, and the twin package @volter/twin-<vendor> when one exists |
| repos needing it | demand: how many surveyed repositories need it, split Node / Python |
| consumers | products in this organization that use the twin today |
| status | the package's support status: Supported, Maintained, Odd Fixes, Orphan, Obsolete, or none when there is no twin yet |
| completion | the fraction of the vendor's own spec operations the twin serves, from the twin's census against the vendor's published spec. A twin without a spec source shows its operation count instead |
| protocol | the twin protocol major the package targets, and whether the platform serves it |
| verified | when the twin's census was last checked against a fresh copy of the vendor's spec |
| what closes it | what stands between the twin and a complete census: no spec source, grandfathered operations, never verified |
Reading a percentage
Completion counts operations, not importance. A twin at 44% may serve every operation your app uses; one at 90% may miss the one you need. Before relying on a twin, read its README: it lists what it serves, what it does not serve yet, and what it models of the vendor's behavior beyond the wire. An operation a twin does not serve fails the way the vendor would fail it, never silently, so a gap is loud at the first call.
Two kinds of complete
Completeness is the number above: how much of the vendor a twin covers. Fidelity is whether what it covers is right, and is held by conformance against the vendor's spec and recordings of the real vendor. A twin can be small and faithful. The percentage is the honest answer to "how done", and a passing conformance suite is the honest answer to "how right"; neither stands in for the other. How fidelity is held is a contributor concern: conformance.