jochen
daa9f171ae
The import of slice 3 (ADR 0275) was checked against every folder: no report changed since the commit it read, and the tracker holds each report's status, owner, fix, design amendment, replay and closing day. The keys are removed from all 361 reports, cycle.py refuses them in any report, and the playbooks, skills and READMEs that still pointed at them name the tracker instead.
1.1 KiB
opened
| opened |
|---|
| 2026-09-30 |
167 — Code several modules share has no home
What was observed
The download-stack write-in step (register download clients and torznab indexers through the Servarr
API) is identical for sonarr, radarr, lidarr and bookshelf. Because a module builds from its own
directory, it now exists as four byte-identical copies under modules/<m>/downloads/, kept honest by a
test that fails when one differs. The same shape repeats: an MQTT probe copied into two modules, and a
"write the provider into the app through its API, idempotently, refuse a minted value" step in ombi,
home-assistant, nodered, tautulli and the four downloaders.
What would be right
A home for shared module code the builder can use — an sdk helper (a write-in step harness: read bindings and pair credentials, probe the provider, diff, write, report) or a shared package the catalogue builds once — so a fix lands in one place.
Re-checked 2026-10-08: still holds. The media catalogue still carries the download-stack write-in step
as four copies, one under each of the four downloaders' downloads/.