mirror of
https://github.com/gesellix/Bose-SoundTouch.git
synced 2026-09-07 15:07:17 +00:00
telnetRevertAvailable compared the live URLs against canonicalBoseTelnetURLs and reported "revertable" on any difference. That set is one original variant, not the only one: this repo's own model of a factory speaker (pkg/service/testing/fakespeaker) uses stats.bose.com and bmxservice.bose.com where the canonical set has events.api.bosecm.com and content.api.bose.io. Feeding that fixture to the gate returned true, so the web UI offered "Restore Bose URLs via Telnet" on a pristine speaker. Pressing it rewrites the device's genuine factory URLs and commits them through envswitch, the layer that wins on the next reboot. The speaker keeps working, since both host sets point at the shut-down Bose cloud, but the record of what that device's URLs actually were is gone, and telnet migration takes no backup to recover it from. The question the gate should answer is "has this been changed away from a factory configuration", not "does it differ from our canonical set". It now compares each field against the values observed on unmigrated speakers, normalising case and a trailing slash so firmware echoing does not decide it. Only observed values are listed. Other Bose hostnames appear in the DNS interception lists and in DNS recordings, but those capture hosts a speaker resolves at runtime rather than the configured value of these four fields, and a wrong entry would hide the revert from someone who needs it. The existing test could not catch this: it asserts against the same canonical constants the code was comparing with. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>