20260912-0906-air-key-line-consolidation Consolidate Air and Key into one switch product line

• status: completed
• createdAt: 2026-09-12 09:06
• approvedAt: 2026-09-12 09:20
• relatedTask: 20260912-0903-air-key-line-consolidation

Context

• Today the family is three records under two IDs. product/switch/ (P05, T1, five files) is the battery BLE wall switch Air 2 / Air 4; product/switch/ (P06, T0, four files) is the four-wire CAN backlit keypad Key 4 / Key 8; product/switch/ (also P05, T1, four files) is the Linux receiver that Air needs and Key does not. The catalogue in product/index.md therefore shows two P05 rows and one P06 row for what the user reads as one line.
• The two switches are already treated as one thing everywhere else. research/air-key-vendors/ is a single catalogue with switch/, keypad/ and gateway/ sections; research/air-key-vendor-landscape.md is one report; both supplier guides declare that their sections 1, 2, 7, 8, 10, 11 and 12 are common clauses that must move together; both bind to the same X01@2026-09-10 / X02@2026-09-10 baseline and the same SYS-0n system requirements.
• What genuinely differs between the halves and must survive the merge. Tier (Key T0 release-critical, Air T1 differentiator); power (bus-powered ≤5 mA@12 V quiescent versus two AAA primary cells with a three-year maintenance target); path (Key → CAN → Core directly, Air → Air Hub → CAN → Core); security (no new CAN encryption for Key, authenticated bidirectional encryption for Air); compliance route (Key rides the non-wireless Sense/Key row, Air carries RED plus the EU battery regulation); prices ($149 versus $59, Air Hub $249); milestones (Key EVT at M4–5, Air EVT at M6–7, Air DVT/PVT at M13–14).
• Requirement namespaces do not collide. AIR-nn, KEY-nn, GW-nn, SYS-nn and the open items AIR-O-nn, KEY-O-nn are already disjoint, so this merge needs no renaming equivalent to the SFR-nn pass in 20260911-2016.
• Key can attach to the Air Hub too (user, 2026-09-12). The Air Hub already carries one YBO CAN port (Classical CAN 500 kbit/s + TJA1463, GW-05 four-wire branch), so a Key panel can sit on that branch exactly as it sits on the boat's bus. This makes the Air Hub the hub of both halves — BLE for Air, CAN for Key — and it is the strongest argument that all three records are one line. It also contradicts two sentences that must be restated rather than deleted: P05-air-hub.md §1 "Air Hub 只针对无线" and "仅使用 Key 的有线安装不需要 Air Hub", and the P06-key.md §1 / PRODUCT-PLAN §P6 path row "无需 Air Hub". No Key or Air Hub hardware changes; what changes is the declared topology.
• Sizing. 24 live documents reference the air-switch/ or key/ paths or the P06 ID; 10 more reference the air-hub/ path or P05-air-hub. Historical task and plan records are not rewritten.

Proposal

One product line, P05 · YBO Switch, in bizplan/product/switch/, with the wireless half and the wired half as two Level 1 records under one product entry — the structure 20260911-2016 established for Mate.

A. Recommended: one line covering Air, Key and the Air Hub

Item	Proposed
Product ID	P05 for the whole line; P06 retired as a product ID, not reused
Line name	YBO Switch — 船内控制面板产品线；型号名 Air 2 / Air 4、Key 4 / Key 8 与 Air Hub 不变
Directory	bizplan/product/switch/; air-switch/, key/ and air-hub/ are removed after their files move
Product entry	New P05-switch.md: the two switch forms, why they are one line (same control surface, same ICD baseline, same Core 回读 doctrine, same hub), what differs per half (tier, power, path, security, price, milestone), and the Air Hub's role as the hub of both halves — BLE for Air, CAN for Key
Level 1	P05-air-switch.md (unchanged name), P05-key.md (from P06-key.md), P05-air-hub.md (unchanged name)
Level 2	P05-air-switch-design.md, P05-air-switch-platform-options.md, P05-air-switch-esp32h2-evaluation.md, P05-key-design.md (from P06-key-design.md), P05-air-hub-design.md, P05-air-hub-platform-options.md
Supplier guides	Stay two — P05-air-supplier-guide.md (Air + Air Hub) and P05-key-supplier-guide.md (from P06-key-supplier-guide.md) — because they are quoted by different manufacturing scopes. Extracting their common clauses into one shared annex is recorded as a follow-up task, not done here
Index	One switch/index.md listing all ten files by level and half
Catalogue	product/index.md drops three rows for one: P05 · YBO Switch — 无线 Air 与有线 Key 开关，及两者共用的中枢 Air Hub
Product plan	PRODUCT-PLAN.md §P5 and §P6 become one §P5 with an Air subsection, a Key subsection and an Air Hub subsection; every row, target and figure moves verbatim. Tier table, price table, milestone table and §6 items keep their per-model entries and are relabelled, not rewritten
Open questions	OPEN-QUESTIONS.md P5 and P6 merge into one P5 section with the same subsections; AIR-O-nn and KEY-O-nn keys unchanged
Compliance	COMPLIANCE-MATRIX.md keeps its two rows, since the routes differ; the wireless row is relabelled Switch · Air 开关 + Air Hub and the Sense/Key row Sense / Switch · Key
Requirement IDs	Unchanged — no collision exists
Cross-references	Path and ID rewrite across the 34 live documents; historical docs/task/ and docs/plan/ records keep the old names as history

A2. Carried by the same change: the Key–Air Hub path

Recorded as topology, not designed here. Restatements, all inside option A's file set:

Document	Change
P05-air-hub.md §1	"只针对无线" becomes: the Air Hub serves both halves of the line — Air over BLE, Key over its YBO CAN branch. The sentence that a Key-only wired install does not need an Air Hub stays true for the on-boat topology and is scoped to it
P05-air-hub.md §3	New GW-06: accept a Key panel on the CAN branch as a control source, apply the same binding/permission check as GW-01, and keep the source class distinct from wireless_key so X02 G-01 (no critical circuit bound solely to a wireless key) is not weakened by the shared hub
P05-key.md §1, PRODUCT-PLAN §P6 path row	"无需 Air Hub" becomes: on the boat Key talks to Core directly and needs no Air Hub; off the boat it can join the Air Hub's CAN branch. Key hardware, the four functional wires and the CAN security position are unchanged
P09-control-protocol-evaluation.md	Control gains a wired input form: an off-boat install can be Key → CAN → Air Hub → third-party actuator, with no Air and no Core. New requirement alongside CTL-14 (Air keys as Matter Generic Switch endpoints)

Three consequences are recorded as open items rather than answered, because each is a product decision:

1. State authority without a Core. KEY FR-02/FR-03 require Key to render Core read-back only. Off the boat there is no Core, so the Air Hub would have to be the read-back authority for Key — a functional addition to both records.
2. The fail-safe argument moves. The 2026-09-11 20:05 decision accepted "Air control dies when Air Hub Linux dies" because the always-works path for critical circuits was Key's wired CAN to Core. On an off-boat install that path does not exist and the Air Hub's Linux becomes a single point of failure for the wired switch as well. This must be stated in the product entry and in the sales/installation material, not left implicit.
3. Powering Key from the Air Hub branch. Key draws up to the per-key backlight budget on the branch; whether the Air Hub sources that (and for how many panels) or an external supply does is unbudgeted.

Choose one: record only — the four restatements plus three open items, no behaviour designed (recommended, keeps this a structural merge) — or specify now, which means deciding the no-Core state authority, the off-boat fail-safe doctrine and the branch power budget inside this task.

B. Alternative: merge the two switches only, Air Hub becomes its own line

Same switch/ directory and P05-switch.md entry for Air and Key, but air-hub/ stays a directory of its own and takes a new ID (P13), so P05-air-hub*.md becomes P13-air-hub*.md and the catalogue keeps two rows. Honest about the Air Hub being a gateway rather than a switch, and it is the P09 Control host off the boat; costs ten more file-level renames than A and puts the Air Hub's ID out of order relative to its M-schedule neighbours. Weakened on 2026-09-12: once the Air Hub is the hub of the wired half as well, keeping it outside the line splits the same topology across two records again.

C. Alternative: minimum diff

Merge Air and Key into switch/ under P05 and leave air-hub/ exactly as it is, still numbered P05. About eight fewer documents change, but two directories keep sharing one ID — the ambiguity that made the catalogue read as a split in the first place.

Naming alternatives, if Switch is not the wanted line name

YBO Panel (covers a keypad better, reads oddly for a two-key wireless rocker) or keeping YBO Air as the line name with Key as its wired model (rejected: Air is the wireless brand and would then mean both the line and one half, the exact ambiguity being removed).

Risks

• Renaming P06-key* and moving the Air files touches 34 documents; the cross-reference checker from 20260911-2016 must be re-run so no §n, FR-nn, AIR-*, KEY-* or GW-* pointer dangles.
• One line spanning T0 and T1 invites reading Air's M13–14 schedule as part of the T0 release commitment; the product entry must state the tier and milestone per half in its first table.
• Retiring P06 orphans §P6 pointers in historical changelog and plan text; they stay as history and are not rewritten.
• bizplan/index.md-level prose and the root index.md feature list enumerate product lines by name and will drift if not updated in the same pass.
• Restating "只针对无线" widens what the Air Hub must accept without widening its verification plan; GW-06 has to reach the Air 指南 verification matrix in the same pass or the requirement-to-test mapping stops being bidirectional.
• Deep links to bizplan/product/switch/ and bizplan/product/switch/ in anything published outside this repository break; the site has no redirect layer.

Scope

Option A: 34 live documents plus the catalogue, product plan, compliance matrix, open questions, root index, indexes and changelog. Option B: about 44. Option C: about 26. No content decision is made in any option — every target, price, requirement and open item moves verbatim.

Alternatives

• Leave the three records where they are and only state the line relationship in each index page. Rejected by the user's direction that they are one product line.
• Merge the two supplier guides into one document with a shared-clause section. Larger content rewrite than the structural merge and touches vendor-facing material mid-quotation; kept as a follow-up.

Annotations

• 2026-09-12: Raised after the user stated that Air and Key, being the wireless and the wired switch, belong to one product line. Awaiting proceed on option A, B or C and on the line name.
• 2026-09-12: The user added that Key can also attach to the Air Hub, since the Air Hub carries CAN. Recorded as section A2; it makes the Air Hub the shared hub of both halves, favours option A and weakens option B. Approved as option A with the recommended defaults: line name YBO Switch, record only for the three consequences.
• 2026-09-12: Implemented as option A. Twelve files under switch/, P06 retired, GW-06 and SW-O-01…03 recorded, CTL-16/CTL-O-16 added to P09. 32 documents changed; build, link/ID sweep and whitespace gate pass. Pre-existing Air figure drift in the governing documents was reported as task 20260912-0940 rather than fixed here.