mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-09-09 11:19:10 +02:00
948a2722f3
* fix(ai): let the fix step own config.yaml, and require the patch-counter bump The premise that the fix step cannot touch config.yaml turned out to be wrong, and the real problem was the opposite of what it looked like. config.yaml was already in scope — issue-fix.md lists it among the files the sweep reads and owns, and all three merged ai-fix PRs edited it. What they edited, though, was the one thing hard limit 2 forbade outright: PR #2970 qbittorrent version: "5.2.3.2" -> "5.2.3.3" PR #2912 bazarr version: "1.6.0.1" -> "1.6.0.2" Both bumped only the LOCAL PATCH COUNTER, leaving the upstream X.Y.Z alone — i.e. exactly the right thing, in direct violation of the written rule. Nothing enforces that rule (ai_guard_paths.sh only covers .github/ and .templates/), so it has been quietly contradicted by practice, and it also contradicts CLAUDE.md's own PR requirement to bump version. It matters because Supervisor will not offer a rebuild without the bump: a fix merged without one ships inert while the issue looks closed. That is the worst outcome available — worse than not fixing it. So the carve-out is narrowed to what addons_updater actually owns (the `upstream` field and the upstream X.Y.Z), and bumping the trailing .N is now required rather than forbidden, with the dot-not-hyphen trap called out (X.Y.Z-N reads as a semver pre-release and Supervisor treats it as older). Exotic version shapes — LSIO tags, dates, nightlies — are explicitly left alone rather than guessed at. Applied to all four places the rule is stated so they cannot drift: issue-fix.md, issue-execute-plan.md, CLAUDE.md, and pr-coderabbit.md — the last keeps the restriction, since it amends a PR whose single bump already covers it, but now says why instead of reading as a contradiction. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ai): derive the patch counter from updater.json, not from version's shape Six review findings, all reproduced against the repo before accepting. Codex (P1) — the rule "increment the trailing .N" is wrong for most of this repo, because you cannot tell a local counter from an upstream component by looking at `version`. Checked all 134 add-ons: version == upstream_version (no counter, must APPEND .1): 82 version == upstream_version + .N (counter, INCREMENT): 8 version drifted from upstream (LEAVE ALONE): 36 no usable updater.json (LEAVE ALONE): 8 So the previous wording would have mutated updater-owned data on 82 add-ons: sonarr's 4.0.19.3001 IS the upstream version, and incrementing it to 4.0.19.3002 burns the identifier of a future real release; linkwarden's 2.16.0 would have become 2.16.1, indistinguishable from an upstream minor bump. updater.json's upstream_version is now the authority: append .1 when version equals it, increment only the digits that follow it, otherwise leave version alone. Validated by running the rule as written over every add-on — 0 violations of the invariant that a bumped version must still start with upstream_version. Copilot — there is no `upstream:` key in any config.yaml (0 of 134); upstream tracking lives in updater.json as upstream_repo / upstream_version. That was inherited text naming a field that does not exist, in all four places. Replaced with the real constraint: never edit updater.json. Copilot — the "a workflow step enforces them" headers over-claimed. Only limit 1 is machine-enforced (ai_guard_paths.sh); the rest ship silently if broken, which is worth saying plainly given limit 2 has been quietly contradicted by practice for months. Copilot — Outcome B produces a plan and no PR, so "say so in the pull request body" had no place to land. Now covers both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>