Problem
The Supported Providers table uses human-readable display labels in its Models column, while configuration requires exact provider/model route refs. Exact refs appear elsewhere for only part of the table, making the setup surface difficult to use and easy to let drift.
Evidence
README.md:77 — The table labels the column as Models without indicating whether entries are display labels or configuration-ready route refs.README.md:79 — The first provider row uses display labels rather than exact provider/model refs.README.md:80 — Subsequent provider rows follow the same display-label pattern, so the table cannot be copied into configuration as written.README.md:86 — The eligibility disclaimer distinguishes namespaces from subscription access, but it does not clarify the difference between display labels and canonical route refs.README.md:88 — Exact route refs are documented later for only one provider rather than consistently in the table.
Why it matters
Users can mistake display labels for accepted configuration values, causing avoidable onboarding errors. Canonical refs also make documentation drift easier to detect without weakening the existing subscription-eligibility disclaimer.
Proposed fix
Add canonical provider/model route refs alongside display labels in every table row, or link each row to one authoritative route-ref mapping. Cross-check the documented refs against starter configurations and both runtime adapters without changing routing data or eligibility policy.
Acceptance criteria
- Every advertised table entry has an exact canonical route ref or a direct link to an authoritative mapping.
- Display labels and configuration-ready route refs are visually distinguishable.
- Documented refs match the relevant starter configurations and accepted runtime identifiers.
- The existing warning that route namespaces do not establish subscription eligibility remains intact.
- No benchmark, catalog, eligibility, or routing behavior is changed as part of this documentation fix.
Suggested verification
Manually compare the updated table with examples/full-stack.json and the provider-specific examples.- Manually compare documented refs with plugin/onboarding.ts, plugin/router.ts, and integrations/hermes/router.py.
Run the repository documentation and full test checks to confirm no unrelated drift.
Expected scope
README.mdexamples/full-stack.jsonexamples/openai-glm-kimi.jsonplugin/onboarding.tsplugin/router.tsintegrations/hermes/router.pypackage-lock.jsonpackage.jsonplugin/package.jsonplugin/__tests__/version-sync.test.tsscripts/__tests__/release-preflight.test.mjsscripts/release_preflight.mjsplugin/__tests__/config.test.tsplugin/__tests__/onboarding.test.tsplugin/__tests__/router.test.tsplugin/config.ts
Required checks
- manual documentation-to-config consistency check
- full test suite
- Run the repository's focused and full test suites
- Verify every manifest and lockfile invariant field together
- Run the repository release check or dry-run without publishing
Release impact
Run the repository's release applicability check after merge; do not publish as part of this issue.
Risk
low
Problem
The Supported Providers table uses human-readable display labels in its Models column, while configuration requires exact provider/model route refs. Exact refs appear elsewhere for only part of the table, making the setup surface difficult to use and easy to let drift.
Evidence
README.md:77— The table labels the column as Models without indicating whether entries are display labels or configuration-ready route refs.README.md:79— The first provider row uses display labels rather than exact provider/model refs.README.md:80— Subsequent provider rows follow the same display-label pattern, so the table cannot be copied into configuration as written.README.md:86— The eligibility disclaimer distinguishes namespaces from subscription access, but it does not clarify the difference between display labels and canonical route refs.README.md:88— Exact route refs are documented later for only one provider rather than consistently in the table.Why it matters
Users can mistake display labels for accepted configuration values, causing avoidable onboarding errors. Canonical refs also make documentation drift easier to detect without weakening the existing subscription-eligibility disclaimer.
Proposed fix
Add canonical provider/model route refs alongside display labels in every table row, or link each row to one authoritative route-ref mapping. Cross-check the documented refs against starter configurations and both runtime adapters without changing routing data or eligibility policy.
Acceptance criteria
Suggested verification
Manually compare the updated table with examples/full-stack.json and the provider-specific examples.Run the repository documentation and full test checks to confirm no unrelated drift.Expected scope
README.mdexamples/full-stack.jsonexamples/openai-glm-kimi.jsonplugin/onboarding.tsplugin/router.tsintegrations/hermes/router.pypackage-lock.jsonpackage.jsonplugin/package.jsonplugin/__tests__/version-sync.test.tsscripts/__tests__/release-preflight.test.mjsscripts/release_preflight.mjsplugin/__tests__/config.test.tsplugin/__tests__/onboarding.test.tsplugin/__tests__/router.test.tsplugin/config.tsRequired checks
Release impact
Run the repository's release applicability check after merge; do not publish as part of this issue.
Risk
low