Both repairability modules are correct, tested, and unreachable from any passport
this build can represent. They are the clearest case of the crate having been
aimed at a sector that was never modelled.
repairability — the resolver keys on categories nothing produces
ruleset_registry::resolve_repairability dispatches on
"smartphone-tablet" | "laptop" | "displays" | "washing-machine".
The only sector carrying a device category is electronics, whose
product_category is a DeviceType: Smartphone | OtherMobilePhone | CordlessPhone | Tablet. Nothing maps those to "smartphone-tablet", and
laptops, displays and washing machines have no sector in the catalog at all —
three of the four rulesets address products no passport can describe.
repairability_index — no input source exists
RepairabilityIndexInputs needs the ten Annex IV priority parts scored 1–5
across three part-level parameters, plus three product-level scores: 33 values.
ElectronicsData carries a single declared repairability_score.
The module implements Reg. (EU) 2023/1669 Annex IV point 5 faithfully. Nothing
can call it.
The decision
These are not bugs to fix; they are scope questions:
- Model the inputs. Add the Annex IV parameter block to the electronics
sector data and map DeviceType onto the resolver key. That makes the enacted
index real for smartphones and slate tablets — the products the regulation
actually covers — and is the only option that produces a lawful index.
- Add the missing sectors. Laptops, displays and washing machines would need
catalog entries and schemas before their rulesets mean anything.
- Retire the heuristic.
repairability is explicitly non-regulatory, on a
scale that is not comparable to the enacted index, for categories we do not
model. It predates the index. If nothing is going to call it, saying so is
better than leaving a calculator that looks available.
The first is the one that produces something an operator can put in a passport.
Both repairability modules are correct, tested, and unreachable from any passport
this build can represent. They are the clearest case of the crate having been
aimed at a sector that was never modelled.
repairability— the resolver keys on categories nothing producesruleset_registry::resolve_repairabilitydispatches on"smartphone-tablet" | "laptop" | "displays" | "washing-machine".The only sector carrying a device category is electronics, whose
product_categoryis aDeviceType:Smartphone | OtherMobilePhone | CordlessPhone | Tablet. Nothing maps those to"smartphone-tablet", andlaptops, displays and washing machines have no sector in the catalog at all —
three of the four rulesets address products no passport can describe.
repairability_index— no input source existsRepairabilityIndexInputsneeds the ten Annex IV priority parts scored 1–5across three part-level parameters, plus three product-level scores: 33 values.
ElectronicsDatacarries a single declaredrepairability_score.The module implements Reg. (EU) 2023/1669 Annex IV point 5 faithfully. Nothing
can call it.
The decision
These are not bugs to fix; they are scope questions:
sector data and map
DeviceTypeonto the resolver key. That makes the enactedindex real for smartphones and slate tablets — the products the regulation
actually covers — and is the only option that produces a lawful index.
catalog entries and schemas before their rulesets mean anything.
repairabilityis explicitly non-regulatory, on ascale that is not comparable to the enacted index, for categories we do not
model. It predates the index. If nothing is going to call it, saying so is
better than leaving a calculator that looks available.
The first is the one that produces something an operator can put in a passport.