Issues 164-168: found provisioning every dependency on ace

164 a credential that must be accepted is minted anyway 165 one accepted value must be accepted once per consumer 166 a requirement cannot be optional 167 code several modules share has no home 168 a setting reaches every file and every contribution
2026-09-30 13:28:53 +02:00
parent a841e2c173
commit 49b1136ded
5 changed files with 135 additions and 0 deletions
@@ -0,0 +1,26 @@
+---
+status: open
+opened: 2026-09-30
+located-in:
+  - mesh-catalog (each module builds from its own directory, ADR 0069)
+  - mesh-sdk
+fixed-by:
+amended-design:
+---
+
+# 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.