Summary
The compatibility gate accepts an Evolution + Kupo-only selection (no Ogmios, no devnet) as valid, but that project has no way to submit or evaluate transactions — Kupo is index/query-only. The seam data treats bare kupo as an independently-sufficient provider for Evolution, which it isn't.
Where
registry/tools/evolution.toml: [compat] consumes = ["blockfrost", "kupo", "ogmios"]registry/tools/kupo.toml: [compat] serves = ["kupo"]src/registry/compat.rs implements the documented OR/union rule (TECH_SPEC §3.2.2): compatible when at least one selected provider serves a seam the tool consumes. The rule is correct; the data is wrong.
Failure scenario
cardano-init --off-chain evolution --infra kupo (no ogmios, no devnet):
compat::check computes served = {kupo}; since kupo ∈ evolution.consumes, it returns compatible.- The scaffolded project wires Evolution against Kupo alone. A real Evolution "Kupmios" provider needs both Kupo (queries) and Ogmios (submit + script evaluation), so Kupo alone can't run the mint→lock→redeem round-trip.
The authors already reasoned about exactly this class of gap for Dolos (dolos.toml declares only u5c, deliberately not blockfrost, because minibf lacks tx evaluation) — Evolution's bare kupo seam is the same trap left open.
Options
- Drop bare
kupo from Evolution's consumes, so only ogmios (query + submit capable) satisfies it. Simplest; Kupmios users would still select ogmios.
- Model a composite "kupmios" seam that requires Kupo and Ogmios together, and have Evolution consume that. More expressive but needs an AND-relationship the current seam model (single-seam OR) doesn't express.
This is a product/design call, hence filing rather than fixing directly. Worth a test that asserts evolution + kupo-only is flagged incompatible once the model is chosen.
Notes
No live duplicate today (the 7 infra tools currently in the registry don't otherwise collide), so this is a latent correctness gap in the seam data, not a regression.
Summary
The compatibility gate accepts an Evolution + Kupo-only selection (no Ogmios, no devnet) as valid, but that project has no way to submit or evaluate transactions — Kupo is index/query-only. The seam data treats bare
kupoas an independently-sufficient provider for Evolution, which it isn't.Where
registry/tools/evolution.toml:[compat] consumes = ["blockfrost", "kupo", "ogmios"]registry/tools/kupo.toml:[compat] serves = ["kupo"]src/registry/compat.rsimplements the documented OR/union rule (TECH_SPEC §3.2.2): compatible when at least one selected provider serves a seam the tool consumes. The rule is correct; the data is wrong.Failure scenario
cardano-init --off-chain evolution --infra kupo(no ogmios, no devnet):compat::checkcomputesserved = {kupo}; sincekupo ∈ evolution.consumes, it returns compatible.The authors already reasoned about exactly this class of gap for Dolos (
dolos.tomldeclares onlyu5c, deliberately notblockfrost, because minibf lacks tx evaluation) — Evolution's barekuposeam is the same trap left open.Options
kupofrom Evolution'sconsumes, so onlyogmios(query + submit capable) satisfies it. Simplest; Kupmios users would still select ogmios.This is a product/design call, hence filing rather than fixing directly. Worth a test that asserts
evolution + kupo-only is flagged incompatible once the model is chosen.Notes
No live duplicate today (the 7 infra tools currently in the registry don't otherwise collide), so this is a latent correctness gap in the seam data, not a regression.