Shota Yamazaki

Thanks, good point. Sending SIBD once without reading first isn't a resend. The result no longer depends on the read being right, and the read is only there to confirm. It also fixes a weak spot in my current code. If port 23 doesn't answer, the sequence trusts the HTTP value, so a stale value can still end up as already in the log. One thing I've seen on my receiver (AVC-X6700H). In standby, SI[code] turns the main zone on but doesn't change the input. So I still need to check the power first. Once the zone is on, I can send SIBD every time. For power, I send ZMON (main zone only), which also sets the state directly. I like your idea of sorting devices by whether their command sets the state or toggles it. It's clearer than the "read first" rule I wrote. Changing the plugin that way is one option, and I'd like to think it over a bit.

Agreed, the first question is the harder one, because it needs the change behind the incident. The second is easier to start with. A team can ask whether the volume of change put pressure on review, testing, rollout, or observability without pinning the incident on one change.

Thank you. It is cheap, and it works best when two people write it separately and compare.

Thank you for reading it so closely. One clarification on your question. The owner and refresh trigger fields are a general recommendation for teams, not something from LY's talk, so I can't speak for how LY assigns owners. The next article I plan for this series goes further into verification. Your point about writing down the problem and its finish line before anything is generated is close to where it starts, because verification needs something written to check against.

Thank you, really encourages me.