20260910-0724-air-key-product-specifications Define the Air and Key product specifications

• status: completed
• priority: P1
• owner: product-spec/session-20260910-0724
• createdAt: 2026-09-10 07:24

Description

Review the existing Air Switch, Air Hub and Key definitions with the user and establish a reviewable product specification proposal. Distinguish existing draft targets, proposed launch scope and unresolved engineering choices. Coordinate interface dependencies with the separately owned distributed Core proposal.

Acceptance (updated by the authorized supplier-document request): deliver a coherent Air/Key/Gateway requirements package, six specifications/design appendices, sourced component recommendations, explicit engineering gates, manufacturing and acceptance requirements; reconcile governing summaries and validate links, consistency and the site build. Documentation completion does not mean hardware or transport qualification is complete.

ActiveForm

Delivered supplier requirements and coherent product documentation; engineering freeze and physical qualification are explicitly tracked in the product supplier guides.

Dependencies

• blocked by: (none; documentation implementation was authorized)
• blocks: (none for documentation delivery; hardware release is governed by the product supplier guides D0-D4)

Notes

• 2026-09-10 08:23: User authorized specification and chip-selection documentation plus a supplier requirements guide. Implementation is authorized for documentation; unvalidated radio, component and production decisions remain explicitly gated. Deliver Chinese product documents per the established repository convention, with English tracking.

• Full-tier cross-product investigation; file-based tracking only. No delegated work.

• Existing uncommitted Core task, plan and tracking changes are preserved. Their ownership and product decisions remain separate.

• User requested collaborative specification definition, not automatic adoption of every existing component or SKU candidate.

• 2026-09-10 07:27: Investigation recorded in the draft proposal. First decision requested: standalone third-party launch support. Product specifications remain unchanged.

• 2026-09-10 07:32: User requested evaluating an open multi-protocol gateway with BLE, Matter, 433.92 MHz and a second frequency written as "818". Revised the proposal with a device-intake matrix, distinct Matter roles, radio concurrency and per-profile capability boundaries. Clarification of 818/868 and initial sales geography is pending; standalone output compatibility remains a separate decision.

• 2026-09-10 07:36: User requested Europe, China and North America coverage and asked about the common 868 MHz option. Added a sourced regional proposal: Europe 433.92/868 MHz, China 433.92 MHz with a bounded 868-868.6 MHz remote-control option, and North America 902-928 MHz. Shared platform and destination-specific RF profiles remain proposed; exact channels, hardware and device compatibility are open.

• 2026-09-10 07:42: User prioritized two-way encryption, anti-copy protection and a small switch lineup, asking for BLE versus Europe/China 433.92 MHz and North America 915 MHz and proposing no 868 MHz variant. Added a BLE-first recommendation, a coverage-driven regional alternative, an authenticated command/result contract and replay/retry/reboot verification criteria. Transport choice remains under discussion; gateway third-party 868 MHz coverage is a separate decision.

• 2026-09-10 07:47: User clarified Gateway primarily pairs with owned Air and requested battery-maintenance and four-conductor CAN options. Refocused the proposal on Key for wired installations, Air for cable-free positions and a focused Air-to-CAN bridge. Added explicit three-year/five-year battery design goals, illustrative 400 mAh current budgets and the existing X01 confidentiality/readback-authentication gap. No additional wired family or protocol implementation was introduced.

• 2026-09-10 08:19: User explicitly excluded CAN encryption and clarified that the security objective is preventing malicious control through Air. Updated the proposal to terminate wireless security at Gateway, retain existing CAN behavior, and require authorized enrollment, action-level authorization, bidirectional wireless authenticated encryption and replay rejection before CAN command generation. The earlier proposed CAN security extension is superseded; transport selection and controlled-document implementation remain open.

• complete: Supplier documentation delivered. Requirement coverage, document links/tables, VitePress build, 179 rendered pages and 5730 internal links passed; physical qualification remains gated in X03.

• Follow-up: user requested product-directory placement. Split the supplier handoff into air-switch/P05-air-supplier-guide.md and key/P06-key-supplier-guide.md, with product-specific inventories and corrected links; all 29 original requirement IDs remain covered.