diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 14601b058..24e11bd4d 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -4,11 +4,11 @@ This document provides context and guidelines for AI assistants working with the
 
 ## Project Overview
 
-Meshtastic is an open-source LoRa mesh networking project for long-range, low-power communication without relying on internet or cellular infrastructure. The firmware enables text messaging, location sharing, and telemetry over a decentralized mesh network.
+Meshtastic is an open-source LoRa mesh networking project for long-range, low-power communication without relying on internet or cellular infrastructure. The firmware enables text messaging, location sharing, and telemetry over a decentralized mesh network. The project uses **C++17** as its language standard across all platforms.
 
 ### Supported Hardware Platforms
 
-- **ESP32** (ESP32, ESP32-S3, ESP32-C3) - Most common platform
+- **ESP32** (ESP32, ESP32-S3, ESP32-C3, ESP32-C6) - Most common platform
 - **nRF52** (nRF52840, nRF52833) - Low power Nordic chips
 - **RP2040/RP2350** - Raspberry Pi Pico variants
 - **STM32WL** - STM32 with integrated LoRa
@@ -80,21 +80,46 @@ firmware/
 │   │   ├── NodeDB.*       # Node database management
 │   │   ├── Router.*       # Packet routing
 │   │   ├── Channels.*     # Channel management
+│   │   ├── CryptoEngine.* # AES-CCM encryption
 │   │   ├── *Interface.*   # Radio interface implementations
+│   │   ├── api/           # WiFi/Ethernet server APIs (ServerAPI, PacketAPI)
+│   │   ├── http/          # HTTP server (WebServer, ContentHandler)
+│   │   ├── wifi/          # WiFi support (WiFiAPClient)
+│   │   ├── eth/           # Ethernet support (ethClient)
+│   │   ├── udp/           # UDP multicast
+│   │   ├── compression/   # Message compression (unishox2)
 │   │   └── generated/     # Protobuf generated code
 │   ├── modules/           # Feature modules (Position, Telemetry, etc.)
+│   │   └── Telemetry/     # Telemetry subsystem
+│   │       └── Sensor/    # 50+ I2C sensor drivers
 │   ├── gps/               # GPS handling
 │   ├── graphics/          # Display drivers and UI
-│   ├── platform/          # Platform-specific code
-│   ├── input/             # Input device handling
-│   └── concurrency/       # Threading utilities
+│   │   └── niche/         # Specialized UIs (InkHUD e-ink framework)
+│   ├── platform/          # Platform-specific code (esp32, nrf52, rp2xx0, stm32wl, portduino)
+│   ├── input/             # Input device handling (InputBroker, keyboards, buttons)
+│   ├── detect/            # I2C hardware auto-detection (80+ device types)
+│   ├── motion/            # Accelerometer drivers (BMA423, BMI270, MPU6050, etc.)
+│   ├── mqtt/              # MQTT bridge client
+│   ├── power/             # Power HAL
+│   ├── nimble/            # BLE via NimBLE
+│   ├── buzz/              # Audio/notification (buzzer, RTTTL)
+│   ├── serialization/     # JSON serialization, COBS encoding
+│   ├── watchdog/          # Hardware watchdog thread
+│   ├── concurrency/       # Threading utilities (OSThread, Lock)
+│   ├── PowerFSM.*         # Power finite state machine
+│   └── Observer.h         # Observer/Observable event pattern
 ├── variants/              # Hardware variant definitions
 │   ├── esp32/            # ESP32 variants
 │   ├── esp32s3/          # ESP32-S3 variants
-│   ├── nrf52/            # nRF52 variants
-│   └── rp2xxx/           # RP2040/RP2350 variants
+│   ├── esp32c3/          # ESP32-C3 variants
+│   ├── esp32c6/          # ESP32-C6 variants
+│   ├── nrf52840/         # nRF52 variants
+│   ├── rp2040/           # RP2040/RP2350 variants
+│   ├── stm32/            # STM32WL variants
+│   └── native/           # Linux/Portduino variants
 ├── protobufs/            # Protocol buffer definitions
 ├── boards/               # Custom PlatformIO board definitions
+├── test/                 # Unit tests (12 test suites)
 └── bin/                  # Build and utility scripts
 ```
 
@@ -105,6 +130,7 @@ firmware/
 - Follow existing code style - run `trunk fmt` before commits
 - Prefer `LOG_DEBUG`, `LOG_INFO`, `LOG_WARN`, `LOG_ERROR` for logging
 - Use `assert()` for invariants that should never fail
+- C++17 features are available (`std::optional`, structured bindings, `if constexpr`, etc.)
 
 ### Naming Conventions
 
@@ -118,70 +144,151 @@ firmware/
 
 #### Module System
 
-Modules inherit from `MeshModule` or `ProtobufModule<T>` and implement:
+Modules use a three-tier class hierarchy:
 
-- `handleReceivedProtobuf()` - Process incoming packets
-- `allocReply()` - Generate response packets
-- `runOnce()` - Periodic task execution (returns next run interval in ms)
+1. **`MeshModule`** - Base class. Implement `wantPacket()` and `handleReceived()`. Returns `ProcessMessage::STOP` or `ProcessMessage::CONTINUE`.
+2. **`SinglePortModule`** - Handles a single portnum. Simplified `wantPacket()` that checks `decoded.portnum`.
+3. **`ProtobufModule<T>`** - Template for protobuf-based modules. Handles encoding/decoding automatically.
+
+Most modules also inherit from **`OSThread`** for periodic tasks (the "mixin" pattern):
 
 ```cpp
-class MyModule : public ProtobufModule<meshtastic_MyMessage>
+class MyModule : public ProtobufModule<meshtastic_MyMessage>, private concurrency::OSThread
 {
+  public:
+    MyModule();
+
   protected:
     virtual bool handleReceivedProtobuf(const meshtastic_MeshPacket &mp, meshtastic_MyMessage *msg) override;
-    virtual int32_t runOnce() override;
+    virtual meshtastic_MeshPacket *allocReply() override;       // Generate response packets
+    virtual int32_t runOnce() override;                         // Periodic task (returns next interval in ms)
+    virtual bool alterReceivedProtobuf(meshtastic_MeshPacket &mp, meshtastic_MyMessage *msg); // Modify in-flight
+    virtual bool wantUIFrame();                                 // Request a UI display frame
 };
 ```
 
+Modules are registered in `src/modules/Modules.cpp` guarded by `MESHTASTIC_EXCLUDE_*` flags.
+
+#### Observer/Observable Pattern
+
+Event-driven communication between subsystems uses `src/Observer.h`:
+
+```cpp
+// Observable emits events
+Observable<const meshtastic::Status *> newStatus;
+newStatus.notifyObservers(&status);
+
+// Observer receives events via callback
+CallbackObserver<MyClass, const meshtastic::Status *> statusObserver =
+    CallbackObserver<MyClass, const meshtastic::Status *>(this, &MyClass::handleStatusUpdate);
+```
+
 #### Configuration Access
 
 - `config.*` - Device configuration (LoRa, position, power, etc.)
 - `moduleConfig.*` - Module-specific configuration
 - `channels.*` - Channel configuration and management
+- `owner` - Device owner info
+- `myNodeInfo` - Local node info
 
 #### Default Values
 
 Use the `Default` class helpers in `src/mesh/Default.h`:
 
 - `Default::getConfiguredOrDefaultMs(configured, default)` - Returns ms, using default if configured is 0
+- `Default::getConfiguredOrDefault(configured, default)` - Generic configured/default getter
 - `Default::getConfiguredOrMinimumValue(configured, min)` - Enforces minimum values
 - `Default::getConfiguredOrDefaultMsScaled(configured, default, numNodes)` - Scales based on network size
 
 #### Thread Safety
 
-- Use `concurrency::Lock` for mutex protection
+- Use `concurrency::Lock` and `concurrency::LockGuard` for mutex protection
 - Radio SPI access uses `SPILock`
 - Prefer `OSThread` for background tasks
 
+### Hardware Detection
+
+`src/detect/ScanI2C` automatically enumerates 80+ I2C device types at boot including displays, sensors, RTCs, keyboards, PMUs, and touch controllers. This drives automatic initialization of the correct drivers.
+
+### Graphics/UI System
+
+Multiple display driver families in `src/graphics/`:
+
+- **OLED**: SSD1306, SH1106, ST7567
+- **TFT**: TFTDisplay (LovyanGFX-based)
+- **E-Ink**: EInkDisplay2, EInkDynamicDisplay, EInkParallelDisplay
+
+**InkHUD** (`src/graphics/niche/InkHUD/`) is an event-driven e-ink UI framework:
+
+- Applet-based architecture — modular display tiles
+- Read-only, static display optimized for minimal refreshes and low power
+- Configured per-variant via `nicheGraphics.h`
+- Separate PlatformIO config: `src/graphics/niche/InkHUD/PlatformioConfig.ini`
+
+### Input System
+
+`src/input/InputBroker` is the centralized input event dispatcher. Supports multiple input sources: buttons, keyboards (BBQ10, Cardputer, TCA8418), touch screens, rotary encoders, and matrix keyboards.
+
+### Power Management
+
+`src/PowerFSM.*` implements a finite state machine with states: `stateON`, `statePOWER`, `stateSERIAL`, `stateDARK`. Key events: `EVENT_PRESS`, `EVENT_WAKE_TIMER`, `EVENT_LOW_BATTERY`, `EVENT_RECEIVED_MSG`, `EVENT_SHUTDOWN`. Conditionally excluded with `MESHTASTIC_EXCLUDE_POWER_FSM` (falls back to `FakeFsm`).
+
+### Motion Sensors
+
+`src/motion/AccelerometerThread` provides background motion monitoring with automatic screen wake and double-tap button press detection. Supports 10+ accelerometer/gyroscope chips (BMA423, BMI270, MPU6050, LIS3DH, LSM6DS3, STK8XXX, QMA6100P, ICM20948, BMX160).
+
+### Telemetry Sensor Library
+
+`src/modules/Telemetry/Sensor/` contains 50+ I2C sensor drivers organized by category:
+
+- **Power monitoring**: INA219/226/260/3221, MAX17048
+- **Environmental**: BME280/680, SCD4X (CO₂), SEN5X (particulate)
+- **Humidity/Temperature**: SHT3X/4X, AHT10, MCP9808, MLX90614
+- **Light**: BH1750, TSL2561/2591, VEML7700, LTR390UV, OPT3001
+- **Air quality**: PMSA003I, SFA30
+- **Specialized**: CGRadSens (radiation), NAU7802 (weight scale)
+
+### API/Networking
+
+`src/mesh/api/` provides a template-based `ServerAPI` for client communication over WiFi (`WiFiServerAPI`) and Ethernet (`ethServerAPI`). Default port: **4403**. HTTP server in `src/mesh/http/`. JSON serialization in `src/serialization/MeshPacketSerializer`.
+
 ### Hardware Variants
 
 Each hardware variant has:
 
 - `variant.h` - Pin definitions and hardware capabilities
 - `platformio.ini` - Build configuration
-- Optional: `pins_arduino.h`, `rfswitch.h`
+- Optional: `pins_arduino.h`, `rfswitch.h`, `nicheGraphics.h` (for InkHUD variants)
 
 Key defines in variant.h:
 
 ```cpp
 #define USE_SX1262          // Radio chip selection
 #define HAS_GPS 1           // Hardware capabilities
+#define HAS_SCREEN 1        // Display present
 #define LORA_CS 36          // Pin assignments
 #define SX126X_DIO1 14      // Radio-specific pins
 ```
 
 ### Protobuf Messages
 
-- Defined in `protobufs/meshtastic/*.proto`
-- Generated code in `src/mesh/generated/`
+- Defined in `protobufs/meshtastic/*.proto` (~32 proto files)
+- Generated code in `src/mesh/generated/meshtastic/`
 - Regenerate with `bin/regen-protos.sh`
 - Message types prefixed with `meshtastic_`
+- Nanopb `.options` files control field sizes and encoding
 
 ### Conditional Compilation
 
 ```cpp
 #if !MESHTASTIC_EXCLUDE_GPS        // Feature exclusion
+#if !MESHTASTIC_EXCLUDE_WIFI       // Network feature exclusion
+#if !MESHTASTIC_EXCLUDE_BLUETOOTH  // BLE exclusion
+#if !MESHTASTIC_EXCLUDE_POWER_FSM  // Power FSM exclusion
 #ifdef ARCH_ESP32                   // Architecture-specific
+#ifdef ARCH_NRF52                   // Nordic platform
+#ifdef ARCH_RP2040                  // Raspberry Pi Pico
+#ifdef ARCH_PORTDUINO               // Linux native
 #if defined(USE_SX1262)            // Radio-specific
 #ifdef HAS_SCREEN                   // Hardware capability
 #if USERPREFS_EVENT_MODE           // User preferences
@@ -192,7 +299,7 @@ Key defines in variant.h:
 Uses **PlatformIO** with custom scripts:
 
 - `bin/platformio-pre.py` - Pre-build script
-- `bin/platformio-custom.py` - Custom build logic
+- `bin/platformio-custom.py` - Custom build logic, manifest generation
 
 Build commands:
 
@@ -202,21 +309,38 @@ pio run -e tbeam -t upload    # Build and upload
 pio run -e native             # Build native/Linux version
 ```
 
+### Build Manifest
+
+`bin/platformio-custom.py` emits a build manifest with metadata:
+
+- `hasMui`, `hasInkHud` - UI capability flags (overridable via `custom_meshtastic_has_mui`, `custom_meshtastic_has_ink_hud`)
+- Architecture normalization (e.g., `esp32s3` → `esp32-s3` for API compatibility)
+
 ## Common Tasks
 
 ### Adding a New Module
 
 1. Create `src/modules/MyModule.cpp` and `.h`
-2. Inherit from appropriate base class
-3. Register in `src/modules/Modules.cpp`
-4. Add protobuf messages if needed in `protobufs/`
+2. Inherit from appropriate base class (`MeshModule`, `SinglePortModule`, or `ProtobufModule<T>`)
+3. Mix in `concurrency::OSThread` if periodic work is needed
+4. Register in `src/modules/Modules.cpp` guarded by `#if !MESHTASTIC_EXCLUDE_MYMODULE`
+5. Add protobuf messages if needed in `protobufs/meshtastic/`
+6. Add test suite in `test/test_mymodule/` if applicable
 
 ### Adding a New Hardware Variant
 
 1. Create directory under `variants/<arch>/<name>/`
-2. Add `variant.h` with pin definitions
-3. Add `platformio.ini` with build config
-4. Reference common configs with `extends`
+2. Add `variant.h` with pin definitions and hardware capability defines
+3. Add `platformio.ini` with build config — use `extends` to reference common base (e.g., `esp32s3_base`)
+4. Set `custom_meshtastic_support_level = 1` (PR builds) or `2` (merge builds)
+5. For e-ink displays, add `nicheGraphics.h` for InkHUD configuration
+
+### Adding a New Telemetry Sensor
+
+1. Create driver in `src/modules/Telemetry/Sensor/` following existing sensor pattern
+2. Register I2C address in `src/detect/ScanI2C` for auto-detection
+3. Integrate with the appropriate telemetry module (Environment, Health, Power, AirQuality)
+4. Add proto fields in `protobufs/meshtastic/telemetry.proto` if new data types are needed
 
 ### Modifying Configuration Defaults
 
@@ -305,9 +429,22 @@ Most workflows can be triggered manually via `workflow_dispatch` for testing.
 
 ## Testing
 
-- Unit tests in `test/` directory
-- Run with `pio test -e native`
-- Use `bin/test-simulator.sh` for simulation testing
+Unit tests in `test/` directory with 12 test suites:
+
+- `test_crypto/` - Cryptography
+- `test_mqtt/` - MQTT integration
+- `test_radio/` - Radio interface
+- `test_mesh_module/` - Module framework
+- `test_meshpacket_serializer/` - Packet serialization
+- `test_transmit_history/` - Retransmission tracking
+- `test_atak/` - ATAK integration
+- `test_default/` - Default configuration
+- `test_http_content_handler/` - HTTP handling
+- `test_serial/` - Serial communication
+
+Run with: `pio test -e native`
+
+Simulation testing: `bin/test-simulator.sh`
 
 ## Resources
 
diff --git a/.github/prompts/new-module.prompt.md b/.github/prompts/new-module.prompt.md
new file mode 100644
index 000000000..8569a622c
--- /dev/null
+++ b/.github/prompts/new-module.prompt.md
@@ -0,0 +1,138 @@
+# New Meshtastic Module
+
+Guide for developing a new Meshtastic firmware module.
+
+## Module Hierarchy
+
+Choose the appropriate base class:
+
+1. **`MeshModule`** — Raw base class. Override `wantPacket()` and `handleReceived()`. Returns `ProcessMessage::STOP` or `ProcessMessage::CONTINUE`.
+2. **`SinglePortModule`** — Handles a single `meshtastic_PortNum`. Constructor takes `(name, portNum)`. Simplified `wantPacket()` checking `decoded.portnum`. Use `allocDataPacket()` to create outgoing packets.
+3. **`ProtobufModule<T>`** — Template for protobuf-encoded modules. Constructor takes `(name, portNum, fields)`. Override `handleReceivedProtobuf()`. Use `allocDataProtobuf(payload)` to create outgoing packets.
+
+Most modules also mix in `concurrency::OSThread` for periodic background tasks.
+
+## Implementation Pattern
+
+```cpp
+// src/modules/MyModule.h
+#pragma once
+#include "ProtobufModule.h"
+#include "concurrency/OSThread.h"
+
+class MyModule : public ProtobufModule<meshtastic_MyMessage>, private concurrency::OSThread
+{
+  public:
+    MyModule();
+
+  protected:
+    // Process incoming protobuf packet. Return true to stop further processing.
+    virtual bool handleReceivedProtobuf(const meshtastic_MeshPacket &mp, meshtastic_MyMessage *msg) override;
+
+    // Generate response packet (optional)
+    virtual meshtastic_MeshPacket *allocReply() override;
+
+    // Periodic task — return next run interval in ms, or disable()
+    virtual int32_t runOnce() override;
+
+    // Modify packet in-flight before delivery (optional)
+    virtual bool alterReceivedProtobuf(meshtastic_MeshPacket &mp, meshtastic_MyMessage *msg);
+
+    // Request a UI display frame (optional)
+    virtual bool wantUIFrame();
+};
+```
+
+## Registration
+
+Register in `src/modules/Modules.cpp` inside `setupModules()`:
+
+```cpp
+#if !MESHTASTIC_EXCLUDE_MYMODULE
+    new MyModule();
+#endif
+```
+
+If other code needs to reference the module instance:
+
+```cpp
+#if !MESHTASTIC_EXCLUDE_MYMODULE
+    myModule = new MyModule();
+#endif
+```
+
+And declare the global in the header:
+
+```cpp
+extern MyModule *myModule;
+```
+
+Some modules also conditionally instantiate based on `moduleConfig`:
+
+```cpp
+#if !MESHTASTIC_EXCLUDE_MYMODULE
+    if (moduleConfig.has_my_module && moduleConfig.my_module.enabled) {
+        new MyModule();
+    }
+#endif
+```
+
+## Conditional Compilation
+
+Add a `MESHTASTIC_EXCLUDE_MYMODULE` guard. This allows the module to be excluded from constrained builds. The flag name must follow the pattern: `MESHTASTIC_EXCLUDE_` + uppercase module name.
+
+## Protobuf Messages (if needed)
+
+1. Define messages in `protobufs/meshtastic/` (e.g., `mymodule.proto`)
+2. Add a `.options` file for nanopb field size constraints
+3. Regenerate with `bin/regen-protos.sh`
+4. Generated code appears in `src/mesh/generated/meshtastic/`
+5. Assign a `meshtastic_PortNum` if the module uses a new port number
+
+## Timing and Defaults
+
+Use `Default` class helpers for configurable intervals:
+
+```cpp
+int32_t MyModule::runOnce()
+{
+    uint32_t interval = Default::getConfiguredOrDefaultMs(moduleConfig.my_module.update_interval,
+                                                          default_my_module_interval);
+    // ... do work ...
+    return interval;
+}
+```
+
+On public/default channels, enforce minimums with `Default::getConfiguredOrMinimumValue()`.
+
+## Observer Pattern
+
+Subscribe to system events:
+
+```cpp
+CallbackObserver<MyModule, const meshtastic::Status *> statusObserver =
+    CallbackObserver<MyModule, const meshtastic::Status *>(this, &MyModule::handleStatusUpdate);
+```
+
+## Testing
+
+Add test suite in `test/test_mymodule/`:
+
+```
+test/
+└── test_mymodule/
+    └── test_main.cpp
+```
+
+Run with: `pio test -e native`
+
+## Checklist
+
+- [ ] Header and implementation files in `src/modules/`
+- [ ] Inherit from appropriate base class (MeshModule / SinglePortModule / ProtobufModule)
+- [ ] Mix in OSThread if periodic work is needed
+- [ ] Register in `src/modules/Modules.cpp` with `MESHTASTIC_EXCLUDE_` guard
+- [ ] Add protobuf definitions if needed (`protobufs/meshtastic/`)
+- [ ] Use `Default::getConfiguredOrDefaultMs()` for timing
+- [ ] Respect bandwidth limits on public channels
+- [ ] Add test suite in `test/`
diff --git a/.github/prompts/new-sensor.prompt.md b/.github/prompts/new-sensor.prompt.md
new file mode 100644
index 000000000..e02fc2462
--- /dev/null
+++ b/.github/prompts/new-sensor.prompt.md
@@ -0,0 +1,149 @@
+# New Telemetry Sensor
+
+Guide for adding a new I2C telemetry sensor driver to Meshtastic firmware.
+
+## Overview
+
+Telemetry sensors live in `src/modules/Telemetry/Sensor/`. There are 50+ existing drivers organized by measurement type. Each sensor integrates with one of the telemetry modules:
+
+- **EnvironmentTelemetryModule** — Temperature, humidity, pressure, gas, light
+- **AirQualityTelemetryModule** — Particulate matter, VOCs
+- **PowerTelemetryModule** — Voltage, current, power monitoring
+- **HealthTelemetryModule** — Heart rate, SpO2, body temperature
+
+## Sensor Driver Pattern
+
+Each sensor has a `.h` and `.cpp` file pair following this pattern:
+
+```cpp
+// src/modules/Telemetry/Sensor/MySensor.h
+#pragma once
+#include "TelemetrySensor.h"
+#include <MySensorLibrary.h>  // Arduino/PlatformIO library
+
+class MySensor : virtual public TelemetrySensor
+{
+  private:
+    MySensorLibrary sensor;
+
+  public:
+    MySensor() : TelemetrySensor(meshtastic_TelemetrySensorType_MY_SENSOR, "MySensor") {}
+
+    // Initialize sensor hardware. Return true on success.
+    virtual void setup() override;
+
+    // Read sensor data into the telemetry protobuf. Return true on success.
+    virtual bool getMetrics(meshtastic_Telemetry *measurement) override;
+};
+```
+
+```cpp
+// src/modules/Telemetry/Sensor/MySensor.cpp
+#include "MySensor.h"
+#include "TelemetrySensor.h"
+
+void MySensor::setup()
+{
+    sensor.begin();
+    // Configure sensor parameters...
+}
+
+bool MySensor::getMetrics(meshtastic_Telemetry *measurement)
+{
+    // Read from hardware
+    float value = sensor.readValue();
+
+    // Populate the appropriate protobuf variant
+    measurement->variant.environment_metrics.temperature = value;
+    // ... other fields ...
+
+    return true;
+}
+```
+
+## I2C Address Registration
+
+Register the sensor's I2C address(es) in `src/detect/ScanI2C` so it's auto-detected at boot:
+
+1. Add a `DeviceType` enum entry in `src/detect/ScanI2C.h`
+2. Add the I2C address mapping in `src/detect/ScanI2CTwoWire.cpp`
+
+The scan runs at boot and populates a device map that telemetry modules use to decide which sensors to initialize.
+
+## Protobuf Fields
+
+If the sensor provides data not covered by existing telemetry fields:
+
+1. Add fields to the appropriate message in `protobufs/meshtastic/telemetry.proto`:
+   - `EnvironmentMetrics` — Environmental measurements
+   - `AirQualityMetrics` — Air quality data
+   - `PowerMetrics` — Power/energy data
+   - `HealthMetrics` — Health/biometric data
+2. Add a `.options` constraint if needed (field sizes for nanopb)
+3. Regenerate: `bin/regen-protos.sh`
+
+## Sensor Type Enum
+
+Add the sensor to `meshtastic_TelemetrySensorType` enum in `protobufs/meshtastic/telemetry.proto`:
+
+```protobuf
+enum TelemetrySensorType {
+    // ... existing entries ...
+    MY_SENSOR = XX;
+}
+```
+
+## Integration with Telemetry Module
+
+Wire the sensor into the appropriate telemetry module. For environment sensors, this is typically in `src/modules/Telemetry/EnvironmentTelemetry.cpp`:
+
+1. Include the sensor header
+2. Add initialization in `setupSensor()` guarded by detection results
+3. Call `getMetrics()` in the measurement collection path
+
+Example pattern from existing sensors:
+
+```cpp
+#include "Sensor/MySensor.h"
+
+MySensor mySensor;
+
+// In setup:
+if (nodeTelemetrySensorsMap[meshtastic_TelemetrySensorType_MY_SENSOR].first > 0) {
+    mySensor.setup();
+}
+
+// In measurement collection:
+if (nodeTelemetrySensorsMap[meshtastic_TelemetrySensorType_MY_SENSOR].first > 0) {
+    mySensor.getMetrics(&measurement);
+}
+```
+
+## Library Dependencies
+
+If the sensor needs an external library, add it to the `lib_deps` in the relevant base platformio.ini configs:
+
+```ini
+lib_deps =
+    ${env.lib_deps}
+    mysensorlibrary@^1.0.0
+```
+
+Or use a conditional dependency if it's platform-specific.
+
+## Unit Conversions
+
+If the sensor reports values in non-standard units, use `src/modules/Telemetry/UnitConversions.h` for conversion helpers (e.g., Celsius ↔ Fahrenheit, hPa ↔ inHg).
+
+## Checklist
+
+- [ ] Create `src/modules/Telemetry/Sensor/MySensor.h` and `.cpp`
+- [ ] Inherit from `TelemetrySensor` base class
+- [ ] Implement `setup()` and `getMetrics()` methods
+- [ ] Add `meshtastic_TelemetrySensorType` enum entry in `telemetry.proto`
+- [ ] Add I2C address to `src/detect/ScanI2C` for auto-detection
+- [ ] Add protobuf fields in `telemetry.proto` if new data types needed
+- [ ] Regenerate protos: `bin/regen-protos.sh`
+- [ ] Wire into the appropriate telemetry module (Environment/AirQuality/Power/Health)
+- [ ] Add library dependency if external library required
+- [ ] Test on hardware or native build
diff --git a/.github/prompts/new-variant.prompt.md b/.github/prompts/new-variant.prompt.md
new file mode 100644
index 000000000..1a324cea9
--- /dev/null
+++ b/.github/prompts/new-variant.prompt.md
@@ -0,0 +1,178 @@
+# New Hardware Variant
+
+Guide for adding a new Meshtastic hardware variant to the firmware.
+
+## Directory Structure
+
+Create under `variants/<arch>/<name>/`:
+
+```
+variants/
+├── esp32/          # ESP32
+├── esp32s3/        # ESP32-S3
+├── esp32c3/        # ESP32-C3
+├── esp32c6/        # ESP32-C6
+├── nrf52840/       # nRF52840
+├── rp2040/         # RP2040/RP2350
+├── stm32/          # STM32WL
+└── native/         # Linux/Portduino
+```
+
+Each variant needs at minimum:
+
+- `variant.h` — Pin definitions and hardware capabilities
+- `platformio.ini` — Build configuration
+
+Optional files:
+
+- `pins_arduino.h` — Arduino pin mapping overrides
+- `rfswitch.h` — RF switch control for multi-band radios
+- `nicheGraphics.h` — InkHUD e-ink configuration
+
+## variant.h Template
+
+```cpp
+// Pin definitions
+#define I2C_SDA 21
+#define I2C_SCL 22
+
+// LoRa radio
+#define USE_SX1262              // Radio chip: USE_SX1262, USE_SX1268, USE_SX1280, USE_RF95, USE_LLCC68, USE_LR1110, USE_LR1120, USE_LR1121
+#define LORA_CS   18
+#define LORA_SCK  5
+#define LORA_MOSI 27
+#define LORA_MISO 19
+#define LORA_DIO1 33            // SX126x: DIO1, SX128x: DIO1, RF95: IRQ
+#define LORA_RESET 23
+#define LORA_BUSY 32            // SX126x/SX128x only
+#define SX126X_DIO2_AS_RF_SWITCH // Common for SX1262 boards
+
+// GPS
+#define HAS_GPS 1
+#define GPS_RX_PIN 34
+#define GPS_TX_PIN 12
+// #define PIN_GPS_EN 47         // Optional GPS enable pin
+// #define GPS_BAUDRATE 9600     // Override default 9600
+
+// Display
+#define HAS_SCREEN 1
+// #define USE_SSD1306            // OLED type
+// #define USE_SH1106             // Alternative OLED
+// #define USE_ST7789             // TFT type
+// #define SCREEN_WIDTH 128
+// #define SCREEN_HEIGHT 64
+
+// LEDs
+#define LED_PIN 2               // Status LED (optional)
+// #define HAS_NEOPIXEL 1        // WS2812 support
+
+// Buttons
+#define BUTTON_PIN 38
+// #define BUTTON_PIN_ALT 0      // Secondary button
+
+// Power management
+// #define HAS_AXP192 1          // AXP192 PMU (T-Beam v1.0)
+// #define HAS_AXP2101 1         // AXP2101 PMU (T-Beam v1.2+)
+// #define BATTERY_PIN 35        // ADC battery voltage pin
+// #define ADC_MULTIPLIER 2.0    // Voltage divider ratio
+
+// Optional I2C devices
+// #define HAS_RTC 1             // Real-time clock
+// #define HAS_TELEMETRY 1       // Enable telemetry sensor support
+// #define HAS_SENSOR 1          // I2C sensors present
+```
+
+## platformio.ini Template
+
+```ini
+[env:my_variant]
+extends = esp32s3_base            ; Use architecture-specific base
+board = esp32-s3-devkitc-1        ; PlatformIO board definition (or custom in boards/)
+board_level = extra               ; Build level: extra, or omit for default
+custom_meshtastic_support_level = 1  ; 1 = PR builds, 2 = merge builds only
+
+build_flags =
+    ${esp32s3_base.build_flags}
+    -D MY_VARIANT_SPECIFIC_FLAG=1
+    -I variants/esp32s3/my_variant  ; Include path for variant.h
+
+upload_speed = 921600
+```
+
+### Common Base Configs
+
+- `esp32_base` / `esp32-common.ini` — ESP32
+- `esp32s3_base` — ESP32-S3
+- `esp32c3_base` — ESP32-C3
+- `esp32c6_base` — ESP32-C6
+- `nrf52840_base` / `nrf52.ini` — nRF52840
+- `rp2040_base` — RP2040/RP2350
+
+### Support Levels
+
+- `custom_meshtastic_support_level = 1` — Built on every PR (actively supported)
+- `custom_meshtastic_support_level = 2` — Built only on merge to main branches
+- `board_level = extra` — Only built on full releases
+
+## Build Manifest Metadata
+
+`bin/platformio-custom.py` emits UI capability flags in the build manifest:
+
+- `custom_meshtastic_has_mui = true/false` — Override MUI detection
+- `custom_meshtastic_has_ink_hud = true/false` — Override InkHUD detection
+- Architecture names are normalized (e.g., `esp32s3` → `esp32-s3`)
+
+## InkHUD E-Ink Variants
+
+For e-ink display variants using the InkHUD framework, add `nicheGraphics.h`:
+
+```cpp
+// nicheGraphics.h — InkHUD configuration for this variant
+#define INKHUD                     // Enable InkHUD
+// Configure display, applets, and refresh behavior per device
+```
+
+InkHUD has its own PlatformIO config: `src/graphics/niche/InkHUD/PlatformioConfig.ini`
+
+## I2C Device Detection
+
+If the variant has I2C devices, ensure `src/detect/ScanI2C` will detect them. The auto-detection system handles 80+ device types including displays, sensors, RTCs, keyboards, PMUs, and touch controllers at boot.
+
+## Custom Board Definitions
+
+If the PlatformIO board doesn't exist, create a custom board JSON in `boards/`:
+
+```json
+{
+  "build": {
+    "arduino": { "ldscript": "esp32s3_out.ld" },
+    "core": "esp32",
+    "f_cpu": "240000000L",
+    "f_flash": "80000000L",
+    "flash_mode": "qio",
+    "mcu": "esp32s3",
+    "variant": "esp32s3"
+  },
+  "connectivity": ["wifi", "bluetooth"],
+  "frameworks": ["arduino", "espidf"],
+  "name": "My Custom Board",
+  "upload": {
+    "flash_size": "8MB",
+    "maximum_ram_size": 327680,
+    "maximum_size": 8388608
+  },
+  "url": "https://example.com",
+  "vendor": "MyVendor"
+}
+```
+
+## Checklist
+
+- [ ] Create `variants/<arch>/<name>/variant.h` with pin definitions
+- [ ] Create `variants/<arch>/<name>/platformio.ini` extending correct base
+- [ ] Set `custom_meshtastic_support_level` (1 or 2)
+- [ ] Verify radio chip define matches hardware (`USE_SX1262`, etc.)
+- [ ] Set hardware capability flags (`HAS_GPS`, `HAS_SCREEN`, etc.)
+- [ ] Add custom board JSON in `boards/` if needed
+- [ ] Test build: `pio run -e my_variant`
+- [ ] For e-ink: add `nicheGraphics.h` with InkHUD config