You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing Board selector is the entry point for accessory management. Show separate Boards and Accessories sections, preserve the current Board selection/add flow, and add an Add accessory action. Accessory rows show connection status and open their configuration screen. Accessories are not nested under individual Boards and continue to target the currently connected Board. Replace the spike's Settings → Sensors entry with this flow.
Build an end-to-end protocol handshake from firmware advertisement through Android/iOS native parsing to an accessory discovery screen showing identity, capabilities, and compatibility. Adapt PR #441 as needed without merging it wholesale by assumption. Include bounded NDJSON framing and firmware manifest, but no automatic Board control. Ship protocol documentation and shared fixtures with the implementation.
docs/accessory-protocol.md — proposed contract to implement and validate.
Implementation hints
Compose the Board and accessory domains at screen level. Do not add hardware-domain imports to Board components; extract composition if needed and update the selector showcase.
The parent PRD includes the complete protocol and product-design snapshots. Local docs may not yet exist on the implementation branch; materialize them from the parent when needed.
Paths prefixed vescape-accessories: belong to vescape-app/vescape-accessories. Coordinate both repositories for firmware/app protocol changes.
Keep native Android/iOS contracts aligned with parity links. Reuse native lifecycle and storage contracts; JS renders state and sends intents.
Acceptance criteria
The existing Board selector is the entry point for accessory management. Show separate Boards and Accessories sections, preserve the current Board selection/add flow, and add an Add accessory action. Accessory rows show connection status and open their configuration screen. Accessories are not nested under individual Boards and continue to target the currently connected Board. Replace the spike's Settings → Sensors entry with this flow.
custom service discovery works independent of name.
supported/unsupported versions and capability types are distinguished.
Parent
#475
What to build
The existing Board selector is the entry point for accessory management. Show separate Boards and Accessories sections, preserve the current Board selection/add flow, and add an Add accessory action. Accessory rows show connection status and open their configuration screen. Accessories are not nested under individual Boards and continue to target the currently connected Board. Replace the spike's Settings → Sensors entry with this flow.
Build an end-to-end protocol handshake from firmware advertisement through Android/iOS native parsing to an accessory discovery screen showing identity, capabilities, and compatibility. Adapt PR #441 as needed without merging it wholesale by assumption. Include bounded NDJSON framing and firmware manifest, but no automatic Board control. Ship protocol documentation and shared fixtures with the implementation.
Type: AFK. Complexity: high. Blocked by: none. Stories: 1, 6, 26–28.
Likely files
src/modules/board/components/BoardSelectorSheet.tsx— existing selector content and sheet; preserve Board behavior.src/screens/main/overlays/TopBar.tsx— current selector caller and cross-domain composition starting point.src/screens/showcase/board/BoardSelectorSheetShowcase.tsx— update the selector preview for the new section and state.vescape-accessories: src/main.cpp— existing BLE service and firmware entrypoint.modules/vescape-core/android/src/main/java/expo/modules/vescapecore/hardware/HardwareLink.kt— PR Vescape Sensors: BLE link to the ESP32 sensor module #441 transport starting point.modules/vescape-core/android/src/main/java/expo/modules/vescapecore/VescapeCoreModule.kt— Android bridge.modules/vescape-core/ios/VescapeCoreModule.swift— iOS bridge.modules/vescape-core/src/index.ts— native contract types.src/app/settings/sensors.tsx— PR Vescape Sensors: BLE link to the ESP32 sensor module #441 route; keep resulting route thin and domain UI in its module.docs/accessory-protocol.md— proposed contract to implement and validate.Implementation hints
Compose the Board and accessory domains at screen level. Do not add hardware-domain imports to Board components; extract composition if needed and update the selector showcase.
The parent PRD includes the complete protocol and product-design snapshots. Local docs may not yet exist on the implementation branch; materialize them from the parent when needed.
PR Vescape Sensors: BLE link to the ESP32 sensor module #441 is prior art at commit
91ebeaf0fdf3daa8a8151314048de9e663b9149c; paths marked PR Vescape Sensors: BLE link to the ESP32 sensor module #441 are absent from the planning checkout.Paths prefixed
vescape-accessories:belong tovescape-app/vescape-accessories. Coordinate both repositories for firmware/app protocol changes.Keep native Android/iOS contracts aligned with parity links. Reuse native lifecycle and storage contracts; JS renders state and sends intents.
Acceptance criteria
The existing Board selector is the entry point for accessory management. Show separate Boards and Accessories sections, preserve the current Board selection/add flow, and add an Add accessory action. Accessory rows show connection status and open their configuration screen. Accessories are not nested under individual Boards and continue to target the currently connected Board. Replace the spike's Settings → Sensors entry with this flow.
custom service discovery works independent of name.
supported/unsupported versions and capability types are distinguished.
fragmented manifests work.
malformed/oversized input is bounded.
Kotlin/Swift and firmware agree on fixtures.
no control activates from discovery.
Blocked by
None - can start immediately.
Related