Proposal: a simple decision-making process for the maintainer team

[xtimmy86x]

Hi everyone! Now that we have a shared maintainer team, I’d suggest agreeing on a simple way to make and record decisions, so they don’t get lost in this growing thread.

My proposal:

• Routine fixes, tests and documentation: go straight through a PR with another maintainer’s review.
• Major features, broad refactoring or breaking changes: open a focused Discussion first to agree on the approach.
• Repository permissions, branch rules, publishing and project direction: discuss and explicitly agree before making changes.
• Urgent security or privacy issues: take the minimum necessary action, notify the team promptly and review the follow-up together.

For proposals, a short explanation of the problem, suggested solution and impact should be enough. Let’s normally allow at least 72 hours for feedback, and longer for major decisions, while allowing people to explicitly abstain when they don’t have the time or expertise. Silence shouldn’t count as approval.

Once we agree, we can update the opening post with the decision, its reasoning and links to the implementation issues or PRs. If we can’t reach agreement, we should clarify the remaining concerns before proceeding and agree on a fallback voting rule for organisational decisions.

If this approach works for everyone, we could create a “Proposals & Decisions” category and capture the agreed process in a short GOVERNANCE.md.

@anotherjulien @GreenGrassBlueOcean @Interstellar0verdrive @fedem95 — what do you think? I’d like to keep this lightweight and practical for everyone.

[anotherjulien]

I agree with this approach, but I must also emphasize ability/expertise.
I suppose the brunt of the work around this decision making will be PR review, but some less technically accomplished people (like me) might not be able to review a PR in a satisfactory manner.

And on the other hand, 4 or 5 people with various schedules and availability will be a bottleneck for sure.
So, is there a point to be made for adding a bigger pool of non-owner people to the organization who could sporadically provide code review?

Also, once the project (hopefully) reaches HA Core, what happens to this structure? A couple of people would remain code-owners of the "myhome" domain in HA, but OWNd would remain in its own repo (here), right?
Is there also a point to be made for (reasonably) rushing feature development to reach this goal and then benefit from the larger project's team for routine maintenance changes? (Like changes that would be required across all built-in integrations)

[xtimmy86x]

I agree with this approach, but I must also emphasize ability/expertise. I suppose the brunt of the work around this decision making will be PR review, but some less technically accomplished people (like me) might not be able to review a PR in a satisfactory manner.

And on the other hand, 4 or 5 people with various schedules and availability will be a bottleneck for sure. So, is there a point to be made for adding a bigger pool of non-owner people to the organization who could sporadically provide code review?

Also, once the project (hopefully) reaches HA Core, what happens to this structure? A couple of people would remain code-owners of the "myhome" domain in HA, but OWNd would remain in its own repo (here), right? Is there also a point to be made for (reasonably) rushing feature development to reach this goal and then benefit from the larger project's team for routine maintenance changes? (Like changes that would be required across all built-in integrations)

This is exactly the concern I wanted to raise. The review requirement introduced by @Interstellar0verdrive makes sense in principle, but in practice it is already blocking progress in the repository.

It works well when another qualified reviewer is consistently available. However, if only one or two maintainers are regularly active, development ends up depending on the availability of people who understandably have other commitments.

I support code review, but we need a process that reflects the team's actual capacity. A broader pool of trusted reviewers could help, alongside an agreed way to handle routine fixes when no reviewer is available. Larger architectural changes should still receive proper discussion and review.

We need to protect code quality while allowing the people who are available to keep the project moving.

[Interstellar0verdrive]

Works for me as written, 72 hours and "silence is not approval" included. Two small additions, then Julien's questions.

First, the one approval that branch protection asks for should come from whoever knows that part of the code, so maybe each of us says where we feel at home. For me that's the covers: timing, calibration, what the bus really does. Second: what I did today (fixtures out, the four branches protected) I did under the "urgent privacy" clause before it existed; happy to adjust any of it here.

When it comes to reviewers: I agree, a wider circle of collaborators with review rights and no admin rights would help a lot, and a few people in here have been reading the code carefully, without anyone asking them to.

On Core and on pace: I understand the temptation, after months of a quiet repo, to just let the one person who is moving fast keep moving. I'd resist it, and not for reasons of process. This integration switches lights, drives shutter motors and sets heating in people's homes. A change that looks fine and isn't can leave a shutter running against its end stop, or a boiler on; that is a different kind of "we'll fix it later" than a broken card. So my preference is small, well-explained PRs that one of us has actually read before they land, even if that means the branch moves slower for a while. Core reviewers will ask for exactly that anyway... so slowing down now is also the shortest road there IMHO.

[xtimmy86x]

I understand the concern, and I agree that changes affecting physical devices deserve careful review.

However, I think we should distinguish between knowing a particular part of the codebase deeply and having more hands-on experience with certain features or devices. Both are valuable, but they are not necessarily the same thing, and assigning review responsibilities purely by feature area may be harder than it sounds.

AI-assisted development and review are also part of how many of us work. That does not invalidate anyone’s expertise, but using those tools—whether to write a change or review it—does not by itself establish that the result has been understood and verified. We should be clear about what each person has actually checked: the implementation, the protocol assumptions, or the behaviour on real hardware.

My concern is that we are approaching a standstill. I believe we need to move as quickly as reasonably possible towards a solid, clearly scoped 2.0 baseline, with known limitations documented and critical issues addressed. We should not wait for v2 to be perfect in every area before releasing it.

Broader testing on real installations will help us discover combinations and behaviours that our own setups cannot cover. From that baseline, we can fix reported problems and add further functionality incrementally.

I support meaningful review. I would also like us to agree on what genuinely blocks the initial 2.0 release, what can follow afterwards, and who is available to review the remaining changes. That would give us a practical path forward while respecting everyone’s time.

[Interstellar0verdrive]

That's a fair point on "what each person has actually checked", and it applies to me first, so let me be open about how I work. I can't read code at this level line by line. What I can do is compare a change with the same thing implemented on my fork, which has been running on my twelve shutters for a week, and with what I measured on the bus with a tape measure; Claude does the line-by-line comparison for me. The result is a short list of concrete findings, each with a file and a line, that anyone can check in a few minutes. The review I'm posting on #318 is an example. Some of those points may turn out to be wrong, and I'd genuinely like to know when they are; the ones that hold would otherwise have reached people's shutters. That's the contribution I can make, no more than that.

On the review rule "already blocking progress": it has been in place for a few hours, one PR is waiting on two small change requests, and five others were merged in the meantime, so I'd give it a little time before drawing conclusions.

Where I fully agree with you: let's write down what blocks a 2.0 beta and what doesn't, so that nobody feels stuck behind a vague veto. My list would be short: the privacy fixtures (#316), the admin check on the raw bus command, and core 2026.9 compatibility. Everything else can flow as small PRs behind it. I'll look at the cover-related ones as they come, in my spare time and in the order of the stack; if someone else gets to one first, all the better.

About a wider circle of reviewers: I agree with both of you, it's the only realistic way to keep the rule without it becoming a bottleneck, and a few people in these threads have already shown they read the code carefully.

[GreenGrassBlueOcean]

Proposal: CI is the gate, review is risk-based, beta is where we learn

We are not building a rocket; we are building a bridge to a fragmented bus (F454, MH200N, MHS1, F422 routers, DALI, firmware quirks). However much we read, the code will contain bugs that only a real plant can find. So the process must be built to find bugs fast and undo them fast, not to keep them out by review alone.

1. Two branches, two rules

• v2-phase1-architecture (integration branch): CI is the merge gate. Green CI + 24 h lazy consensus → the author merges. Anyone may revert without discussion; a revert is never rude.
• master (stable): one approval from a domain owner + a soak period on beta. Nothing reaches stable installs without having run on real hardware.

2. Review by risk, not by size

• Class A — actuation: anything that moves a cover, sets a heating setpoint or arms an alarm. One domain-owner approval or, if none arrives within 72 h, merge to beta with the live-test evidence in the PR (trace/sweep export, HA log) and a kill switch back to the previous behaviour. Interstellar0verdrive owns covers; we name owners for heating, alarm, lighting.
• Class B — everything else: card, tests, docs, CI, refactors at 100 % coverage. CI + lazy consensus.

3. What "good CI" has to mean to earn this
100 % coverage on the core people run (2026.9 / Python 3.14) plus beta and dev cores; the anonymized hardware trace fixtures replayed on every PR — that is our fleet, and more fixtures from more plants is the most valuable contribution anyone can make; safety invariants as tests (a timed cover never runs past travel time + margin, no heating write without a user command, no frame sent while transmit is unarmed); the privacy check; the typing ratchet; the card's node suite. All of this exists or is in the open PRs. If something slips through, the fix is a new test, not a new review rule.

4. Beta cadence
A beta from the integration branch every week (HACS beta channel, opt-in), stable monthly from what survived the soak, every release with a rollback line (HACS version pin). Beta users know what they signed up for; stable users get what beta already proved.

5. Review etiquette — this one is not optional
Requesting changes is welcome. Requesting changes and then not following up is not. A review is a commitment: all requested changes in one pass, and when the author has addressed them, the reviewer re-reviews within 72 h — approves, or says precisely what is still missing. If nothing comes within 72 h, the PR proceeds on CI. Opening a "changes requested" on the next PR of a stack while the previous request sits unanswered stalls the whole chain and costs the author far more energy than the change did. A failure to follow up on a review request is the single most demotivating thing one can do, more than any bug. If a reviewer cannot commit to the follow-up, the honest move is to comment without blocking.

6. Decisions
xtimmy86x's proposal stands for organisational decisions (72 h, silence ≠ approval, GOVERNANCE.md). Code decisions follow 1–2 above.

---

The concrete state, so this is not abstract: the 12 open PRs are being re-stacked into 9 linear ones (fixtures+CI → issue batch → cover model → card+calibration → quality scale → naming → typing → skeleton → router), merged only ever from the bottom. Interstellar0verdrive's five points on #318 are real Class-A findings; they get one pass from me, and then — per point 5 — a re-review from the person who asked.

---

Meanwhile, at the top of the rebuilt stack: 1473 passed, but two leftovers from the reorder — 10 uncovered lines in __init__.py and one typing error over the ratchet baseline. Fixing those, then I switch the PRs over.

[xtimmy86x]

Thank you both. I think we are getting closer to a workable agreement.

@Interstellar0verdrive, I appreciate the explanation of what you actually verify and how. Your hardware experience and concrete findings are valuable. Fair point also that the review rule has only been in place for a few hours: my concern is about it becoming a bottleneck, rather than saying that this has already been conclusively demonstrated.

@GreenGrassBlueOcean, I support separating the beta integration branch from stable and using real-world feedback to improve an initial 2.0 baseline.

I would start by agreeing on the short list of beta blockers: privacy, admin protection for raw bus commands, and compatibility with the current supported Core. Any other proposed blocker should identify a concrete problem and explain why it must be resolved before beta. Features and improvements that are not essential to that baseline can follow incrementally.

On reviews, I agree that follow-up matters, but we should allow another available reviewer to take over when the original reviewer cannot respond. A known unresolved defect should not automatically become acceptable after 72 hours. Equally, once the concern has been addressed and verified, the PR should not depend indefinitely on one specific person's availability.

I would also classify refactors by their actual impact: changes to routing or lifecycle can affect actuation even with 100% coverage.

My preference is to agree on a simple process for this beta, use it, and adjust it based on experience. We need a solid starting point that we can test more widely and improve, without making every future enhancement a prerequisite for releasing 2.0.

[Interstellar0verdrive]

I'd sign @xtimmy86x 's version as it stands: the short list of beta blockers (privacy, the admin check on raw bus commands, current Core compatibility) as the starting point, and "another reviewer can take over" as the answer to availability.

Two things in the counter-proposal I can't get behind, said once and briefly:

• "Green CI + 24 h, the author merges" on the integration branch is self-merge. That's what yesterday's branch rules were set to prevent, and it's the branch the weekly beta would be cut from. Keep the one approval; widen who can give it (collaborators with review rights, no admin), and for Class B let any maintainer approve after a quick look. That's fast without being unread.
• "No re-review within 72 h, then merge on CI" turns a missing answer into an approval. For code that drives motors that's the wrong default, and fix(cover): anchor timed covers on the real write and motor start (#302) #318 showed why this morning: the re-review found that the fix for point 1 never fires against the pinned OWNd, while its own test is green, because the mock doesn't behave like the library. CI would have waved it through. If I'm the one holding a PR up, any other maintainer can take the re-review over and I'll say so in the PR rather than leave it hanging. What I won't promise is a clock: I do this in my spare time.

On "Interstellar0verdrive owns covers": glad to look at cover PRs when I can, and I'd rather not be the only gate on them . Weekly betas on an opt-in channel with a documented rollback sound right to me, once the blockers are in.

[xtimmy86x]

Thanks, this works for me too. My concern was always about availability becoming a bottleneck, and allowing another reviewer to take over addresses that without treating silence as approval.

I’m comfortable keeping one independent approval on both branches, with the depth of review proportional to the actual impact of the change. Areas of experience should help us find a reviewer, without making any one person the mandatory gatekeeper.

The example from #318 is a concrete reminder that green tests depend on how accurately they represent the real library and hardware behaviour. That is useful feedback to turn into a regression test.

I also understand that nobody can guarantee a fixed response time when contributing in their spare time. If someone cannot follow up, making that clear in the PR lets another maintainer pick it up.

From here, I would focus on agreeing on the short beta-blocker list, resolving those items, and getting a clearly scoped 2.0 beta into wider testing. Further features and architectural improvements can follow incrementally, without continually expanding what must be finished before that release.

[GreenGrassBlueOcean]

Hi everyone,

I’d like to take a step back from the specific PR mechanics and look at the bigger picture behind the sentiment raised over #318: "All tests were green, but the mock lied and the code had a bug—therefore we must slow down and rely on deeper manual reviews before anything merges."

First off: @Interstellar0verdrive’s catch on #318 regarding the OWNd 2.0.0b6 is_connected state was a brilliant, sharp observation. It prevented an idle-reconnect delay on live shutters. But the conclusion we draw from it about our development model is critical.

To explain why, let’s start with an analogy.

---

The 4 Golf Owners

Imagine the four of us all own a Volkswagen Golf 1.9 TDI. Three of us have fabric seats, one has leather seats, and the paint colors are different, but mechanically, they are the exact same car.

We get fed up with the factory ECU software and decide to build an open-source vehicle control system. We proudly proclaim on our repo: "The best control software for ALL Volkswagen Golfs."

We are rigorous engineers. We write clean code, maintain strict typing, demand 100% test coverage, and institute mandatory peer reviews. We review every pull request line by line and test it thoroughly on our own 1.9 TDIs. On our driveways, the cars purr like kittens. Everything is green, every review approved.

Then we release it to the world.

A week later:

• A Golf V6 (2.8L) owner installs it and crashes into a hedge because our braking routine was calibrated around the inertia of a light 4-cylinder diesel engine—the brake signal arrived far too late.
• A Golf Cabriolet owner writes an angry post because their convertible roof stops halfway—our state machine assumed a rigid metal roof.
• A Golf 4Motion owner complains their rear differential never engages because our torque model assumed front-wheel drive.

---

The Reality of OpenWebNet

In the MyHOME world, we are those 4 Golf diesel owners.

Between us, we have a tiny sliver of the actual hardware spectrum:

• One of us has 12 shutters on a MyHOMEServer1.
• Another has an MH200N test bench.
• We might have a couple of standard relay actuators and a basic lighting bus.

Meanwhile, the OpenWebNet universe out there is vast and fragmented:

• Gateways: MH200N, F454, MyHOMEServer1, F452, F453AV, 3477 serial gateways, USB interfaces—each with completely different TCP connection pooling, idle timeouts, and status echoing quirks (e.g. MyHOMEServer1 relays *2*0* before motion; older gateways do not).
• Topologies: Flat buses vs. multi-tier plants linked by F422 bus routers (WHERE = 18#4#02) traversing local buses and private risers with variable transit latency.
• Actuators: Timed covers, pulse-relay actuators, 4-pipe fancoil HVAC units, 99-zone central thermo units, CEN / CEN+ pushbuttons, energy totalizers, and burglar alarms.

No amount of manual code review by 4 people can mentally simulate how a 2008 F452 firmware behind an F422 router will behave.

In #318, the mock didn't lie because someone was careless; it lied because neither the author nor the test harness had telemetry on how OWNd 2.0.0b6 internally handled socket closures versus connection flags. Relying on manual review to catch those gaps is an illusion: human review only checks code against what the reviewer already knows from their own specific setup.

---

The Danger of Process Paralysis

If we convince ourselves that safety comes from heavy manual review gates and waiting days for approvals on every change:

1. We will design an architecture that only fits the 1.9 TDI. We will freeze assumptions based on our own hardware, and when the V6s and convertibles eventually show up, it will force a massive, painful refactoring across the entire codebase.
2. We kill the developer enthusiasm that keeps open source alive. Sprints run on energy and visible momentum. Ask kids to build a treehouse as fast as they can, and they will work with tireless enthusiasm. Force them to wait three days for an inspection before hammering each plank, and they abandon the project for video games.
3. Most dangerously: we cut off the flow of real-world traces.

---

The True Safety Net: The Community Trace Flywheel

Why did we build myhome.sweep_bus? Why did we build the Lovelace Bus Monitor Card with 1-click Sweep Bus and Export Trace? Why did we create the Golden Conformance Corpus (tests/golden/)?

Because real hardware telemetry and bus traces are the only way to map the unknown universe.

If we run fast, weekly opt-in betas from our integration branch:

• Yes, it will surface edge cases and bugs. That is not a failure of engineering; that is the explicit, intended purpose of a beta.
• Every time a beta user with an F454 or an F422 hits an unexpected behavior, they click Export Trace or Export Sweep on their bus card.
• We take that raw, anonymized JSON bus trace and add it directly to our test suite as a replay fixture.

Once a real bus trace becomes a CI fixture:

• It tests that physical scenario on every single commit and PR forever.
• It guards against regressions across hardware none of us physically own.
• Our CI transitions from testing naive mocks to replaying the collective telemetry of the entire community.

That was my primary motivation for building the trace and sweep infrastructure. It would be a huge pity if we end up with immaculate, heavily reviewed code that only runs on our own 4 setups, while drying up the pipeline of real community traces because releases take months to reach anyone.

---

What I Propose

1. Keep the integration/beta cadence moving fast. Use beta as our radar to harvest traces from all the Golf V6s and Cabriolets in the community.
2. Turn every real finding into a golden fixture. When a discrepancy is discovered (like the OWNd reconnect in fix(cover): anchor timed covers on the real write and motor start (#302) #318), don't just patch the line—add the exact trace or mock-behavior fixture to CI so that class of bug can never pass automated checks again.
3. Review for architectural sanity, but don't treat manual review as a substitute for fleet telemetry.

Let's embrace community bug reports and bus sweeps as the fastest, safest way to build an integration that truly works for the entire OpenWebNet ecosystem.

[xtimmy86x]

I agree with the value of frequent opt-in betas and turning community findings into regression tests. That is also why I want us to release a clearly scoped 2.0 baseline without waiting for every planned feature or quality improvement.

I think we already share that goal. The proposal to keep one independent approval also includes a short beta-blocker list, interchangeable reviewers and proportionate reviews. It does not require us to validate every possible installation before releasing a beta.

The #318 example shows how these approaches can complement each other: a review identified a gap in the tests, and that finding can now improve the automated checks. Community testing will expose other gaps that none of us could identify on our own.

Trace replay is valuable, but we should also be clear about what it reproduces. Parsing recorded frames is different from reproducing socket lifecycle, timing and physical behaviour; some findings will need dependency-level or timing tests alongside the trace.

Could we settle the remaining concrete question: are we keeping one independent approval on the integration branch, with any suitably informed reviewer able to take over? That is the approach I support, together with prompt handover when someone is unavailable.

Then we can focus on closing the agreed beta blockers and publishing the next beta. I would like us to put that practical agreement into GOVERNANCE.md and improve it through experience, while keeping development moving.

[anotherjulien]

Candid question: what are we trying to catch with systematic manual review? Bugs before they can manifest in the wild? Exotic edge-cases?
That seems unreasonable to achieve consistently in my opinion.

I agree that a better approach would be to clearly state: you're trying a BETA, from a project that has had a big development shift, there WILL be bugs (mostly setup specific ones), we need your help reporting them, here's how, and then here's how to roll-back to the last version that worked for you.
I mean, there was a shit-ton of BR for this project, I just lacked the bandwidth and motivation to act on them! (+ there was no structure to how those came in)

In that case, it might be better to do a periodic deeper dive to audit all or some aspects of the code and MAYBE catch something that went unnoticed the same way it MIGHT have been caught during a regular review.

Overall, I agree that given the few people able and willing to take this project in hands, it might be a long term net negative to discourage.

I understand that this disappearance over the week-end with no contact did make people tense up, and raise trust questions.
Are systematic reviews a round-about way to address this trust? If so, it might not be the most effective.
I trust we all share the same goal, and are willing to give the community the same end-product; with the same level of quality, not only in terms of arbitrary tests passed, but more importantly in terms of functionality and user experience!

[xtimmy86x]

I agree with @anotherjulien . This is the concern I raised from the beginning: I feel the restrictions introduced by @Interstellar0verdrive are disproportionate to the project's current stage and the number of people actively available to maintain it.

I appreciate the concrete issues that reviews have caught, including on #318. Those contributions are valuable. However, I do not think approval from another maintainer should be mandatory for merging every PR.

I was willing to support one independent approval with interchangeable reviewers as a compromise, but that still depends on someone being available. Allowing another reviewer to take over does not solve the problem when nobody has the time.

My preference is that maintainers can merge their own PRs when the required checks pass, the changes have been appropriately validated, and there are no known unresolved blocking issues. Passing CI alone does not prove correctness, and concrete problems raised during review must still be addressed.

For changes with significant impact, we should actively seek additional review and hardware testing. For the beta branch, I favour frequent opt-in releases with clear limitations, straightforward reporting instructions and a documented rollback path. Stable releases should require stronger validation and evidence from beta testing.

On trust, I agree that any concerns should be discussed directly. We all want a reliable integration and a good user experience, through a way of working that people can sustain in their spare time.

Let's agree on the essential beta blockers and move towards wider testing, with a process based on maintainer responsibility, evidence and collaboration.

[Interstellar0verdrive]

Read all three, and I'll take the point rather than dig in: with four people working in their spare time, one mandatory approval on the integration branch is more than the project can carry right now, and I'd rather relax a rule I set than be the reason work sits. So for v2-phase1-architecture I'm dropping the required approval today and keeping only "pull request required, no force-push, no deletion": the author merges on green CI.

Two things I'd ask to write into GOVERNANCE.md next to that, because they are what the rule was actually protecting:

• An open "changes requested" isn't overridden by a clock. It's closed by a fix, or by another maintainer dismissing it with a reason in the PR. That's the fix(cover): anchor timed covers on the real write and motor start (#302) #318 case: a finding gets answered by someone, not by a timeout.
• master keeps one approval and the beta soak, as both of you describe. Beta is where we learn; stable is where we don't.

On cover changes I'll keep posting what I find, as notes rather than as a gate.

[GreenGrassBlueOcean]

could not agree more with this!, and @Interstellar0verdrive I loved the feedback actually I opened a new issue in OWND already (https://github.com/OpenWebNet-HA/OWNd/issues). I hope to post a PR soon that @fedem95 can review.
And again if something is not right just like the privacy issue we will fix it to the best possible solution see also what we made together in #335 this we could have never made alone!

[GreenGrassBlueOcean]

Following up on the "small, well-explained PRs" point, and on Interstellar0verdrive dropping the required approval on the integration branch today: I've split the open work into PRs that each do one thing and can be read in minutes, and put them in one line so they merge from the bottom without anyone having to untangle a stack. Here is the order I'd suggest, and why.

0. Independent, tiny, unblocks a reporter

• fix(climate): an actuator status is not a second zone (#333) #336 — climate: an actuator status is not a second zone (Climate entity for Zone 1 incorrectly changes to heating when another zone is heating #333). 2 files. No dependencies; can go first.

1. The agreed beta blockers (privacy, admin check on raw bus commands, current Core — the third one landed as #334)

• fix: carry the #335 privacy commits into v2-phase1-architecture #337 — carry the fix: privacy at the source - exports and diagnostics carry no personal data, and tests cannot #335 privacy commits into v2-phase1-architecture (they were merged after fix: synthetic plant fixtures, privacy at the source, CI on the core users run (Python 3.14 / 2026.9) #316 had already landed, so v2 never got them). Cherry-picked, same patches.
• refactor(init): entry lifecycle on the HA quality scale; no runtime OWNd installer (#309) #338 — entry lifecycle on the HA quality scale; reauth instead of "failed to set up"; no runtime OWNd installer (Blocking filesystem operations in get_ownd_version() during integration setup #309). Big minus count, it's mostly deleting the installer.
• fix(websocket): resolve the gateway from entry.runtime_data; admin-gate bus injection #339 — WebSocket: gateway lookup from entry.runtime_data, and bus_monitor/send + /clear require admin (a kiosk token could inject alarm frames). Once these three are in, the blocker list from this thread is closed.

2. One issue per PR — each one small enough to check against the issue it closes

• fix(gateway): skip OWNd's None reconnect cycle (#304); via_device_id for CEN devices (#310) #340 — MH201: unexpected error logs with unclear reason #304 (OWNd's None reconnect cycle) and Deprecated via_device argument in gateway.py will stop working in Home Assistant 2027.8 #310 (via_device_id), gateway.py only
• fix(sensor): temperature probes are push-driven, poll only as a fallback (#308) #341 — [Bug] F454 + 3455/L4577: recurring NACKs from temperature polling; readings continue when the request is disabled #308 temperature probes are push-driven, poll only as a fallback
• fix(light): accumulate colour modes instead of toggling between HS and CT (#307) #342 — DALI DT8 Light Temperature and RGB Support #307 colour modes accumulate instead of toggling HS ↔ CT
• fix(frontend): render bus-monitor timestamps in the browser's local time (#305) #343 — timezone issue #305 bus-monitor timestamps in local time (card only, 1 file)

3. Docs and CI, then the gateway

• docs+ci+fix: runtime behaviour notes, quality-scale audit, gateway identification, timed covers (#302) #344 — runtime behaviour notes, install pitfalls, quality-scale audit + tier table. Sits here because the next two append to the docs it creates.
• fix(gateway): identify gateways by precedence; gate startup discovery on the profile #345 — gateways identified by precedence (ssdp > serial > manual > who13); startup discovery only polls what the profile supports (the MH200N *#16*0## boot error). Evidence exported in diagnostics and traces.

4. Covers (Class A — Interstellar0verdrive's ground)

• fix(cover): anchor timed covers on the real write and motor start; echo window (#302) #346 — timed covers anchored on the real write and motor start (RFC: timed covers, what I measured on a MyHOMEServer1 (latencies, frame order, non-linear position) #302). Exactly the commits reviewed on fix(cover): anchor timed covers on the real write and motor start (#302) #318, both rounds, re-opened at the top of the split so nothing lands twice.

5. The feature/quality stack on top of #346

• feat(frontend): bus-monitor trace/sweep workflow, self-describing exports, node test suite #319 — bus card trace/sweep workflow, self-describing exports, node tests. Card only now, on fix(cover): anchor timed covers on the real write and motor start; echo window (#302) #346; xtimmy86x's per-gateway scoping finding is answered and confirmed.
• feat(cover): travel-time calibration on the bus - calibrate_cover service, buttons, bus-measured runs (backend; card UI in #355) #349 — cover travel-time calibration, split out of feat(frontend): bus-monitor trace/sweep workflow, self-describing exports, node test suite #319 as asked there: calibrate_cover, the buttons, the stopwatch panel. On feat(frontend): bus-monitor trace/sweep workflow, self-describing exports, node test suite #319 (the panel code builds on the card workflow), so the chain stays one line. Interstellar0verdrive's three points (backend 60 s guard, the actuator as the authority, stopwatch measured on the bus) are each mapped to a commit in the PR body; "runs end on a press" and the move into the management panel ([RFC] Streamlined Device Onboarding: Active/Passive Bus Discovery with a "Pending Devices" Staging & Management View #270) are listed there as follow-ups.
• feat: quality-scale Bronze + Gold (runtime_data, exception translations, stale devices, entity audit, docs); min core 2026.3 #321 quality scale Bronze + Gold → feat: Home Assistant device/entity naming (quality-scale has-entity-name, entity-translations) #325 entity naming → chore: strict-typing ratchet, CI dry-run fixes; cover travel time copied_from #326 typing ratchet + card cover tools → refactor: one platform skeleton (restore / configure / discover / route) - all nine platforms #329 platform skeleton → refactor: frame router replaces the myhome_update dispatcher signals #331 frame router. Each one rebased on the one below, bases updated on GitHub.

Independent, external

• Added attributes for the thermostat (knob position) #313 (DinoMesina, thermostat knob attributes) — waits on the requested changes; best landed before refactor: one platform skeleton (restore / configure / discover / route) - all nine platforms #329, which rewrites the climate platform, so the author doesn't have to rebase over it.

Umbrella

• V2 phase1 architecture #232 (v2 → master) stays open until the beta has soaked, per what we agreed above: one approval + soak for master.

How to merge it: always the lowest open PR first, "delete branch" on merge — GitHub then retargets the next PR to the branch it merged into, so the chain never breaks. Every PR is green on its own CI (100 % coverage, privacy check, node suite) and can be reverted alone.

Where a second pair of eyes helps most: #346 and #349 (Interstellar0verdrive), #319 and #343 (xtimmy86x). The rest is routine: fixes, tests, docs — CI plus a quick look.

If the order looks wrong to anyone, say so here and I'll reshuffle; the split is cheap to rearrange now, expensive after the first merge.

Edited 15 Sep: step 5 updated after the #319 split — calibration is now #349.

[Interstellar0verdrive]

Order looks right to me, and thanks for the split. #346 approved (same diff as #318). I'll take the calibration PR once it's out of #319; the rest I'll leave to CI and whoever's around.

[GreenGrassBlueOcean]

Done — the calibration PR is #349, on top of #319 rather than directly on #346: the stopwatch panel builds on the card workflow #319 introduces, so putting it one step up keeps the chain a single line (#346 → #319 → #349 → #321 …) and nothing is duplicated. #319 is now the card and its node tests only, rebased onto #346 as promised; #321's base moved to #349. Step 5 in the order above is edited to match.

@Interstellar0verdrive the #349 body maps your three points to the commits that answer them, and lists "runs end on a press" and the move into the management panel (#270) as follow-ups, as agreed on #319. @xtimmy86x #319 is ready for the monitoring/export review on its own now.