diff --git a/AGENT.md b/AGENT.md
new file mode 100644
index 00000000000..50a15dc0af8
--- /dev/null
+++ b/AGENT.md
@@ -0,0 +1,461 @@
+# AGENT.md - Guide for AI Agents Working with INAV
+
+## Project Overview
+
+**INAV** is a navigation-capable flight controller firmware for multirotor, fixed-wing, and other RC vehicles. It is a community-driven project written primarily in C (C99/C11 standard) with support for STM32 F4, F7, H7, and AT32 microcontrollers.
+
+### Key Characteristics
+- **Type**: Embedded firmware for flight controllers
+- **Language**: C (C99/C11), with some C++ for unit tests
+- **Build System**: CMake (version 3.13+)
+- **License**: GNU GPL v3
+- **Version**: 9.0.1 (as of this writing)
+- **Codebase History**: Evolved from Cleanflight/Baseflight
+
+## Architecture and Structure
+
+### Core Components
+
+The INAV codebase is organized into the following major subsystems:
+
+1. **Flight Control (`fc/`)**: Core flight controller logic, initialization, MSP protocol handling
+2. **Sensors (`sensors/`)**: Gyro, accelerometer, compass, barometer, GPS, rangefinder, pitot tube
+3. **Flight (`flight/`)**: PID controllers, mixers, altitude hold, position hold, navigation
+4. **Navigation (`navigation/`)**: Waypoint missions, RTH (Return to Home), position hold
+5. **Drivers (`drivers/`)**: Hardware abstraction layer for MCU peripherals (SPI, I2C, UART, timers, etc.)
+6. **IO (`io/`)**: Serial communication, OSD, LED strips, telemetry
+7. **RX (`rx/`)**: Radio receiver protocols (CRSF, SBUS, IBUS, etc.)
+8. **Scheduler (`scheduler/`)**: Real-time task scheduling
+9. **Configuration (`config/`)**: Parameter groups, EEPROM storage, settings management
+10. **MSP (`msp/`)**: MultiWii Serial Protocol implementation
+11. **Telemetry (`telemetry/`)**: SmartPort, FPort, MAVLink, LTM, CRSF telemetry
+12. **Blackbox (`blackbox/`)**: Flight data recorder
+13. **Programming (`programming/`)**: Logic conditions and global functions for in-flight programming
+
+### Directory Structure
+
+```
+/src/main/              - Main source code
+  ├── build/            - Build configuration and macros
+  ├── common/           - Common utilities (math, filters, utils)
+  ├── config/           - Configuration system (parameter groups)
+  ├── drivers/          - Hardware drivers (MCU-specific)
+  ├── fc/               - Flight controller core
+  ├── flight/           - Flight control algorithms
+  ├── io/               - Input/output (serial, OSD, LED)
+  ├── msp/              - MSP protocol
+  ├── navigation/       - Navigation and autopilot
+  ├── rx/               - Radio receiver protocols
+  ├── sensors/          - Sensor drivers and processing
+  ├── scheduler/        - Task scheduler
+  ├── telemetry/        - Telemetry protocols
+  └── target/           - Board-specific configurations
+
+/docs/                  - Documentation
+  └── development/      - Developer documentation
+
+/cmake/                 - CMake build scripts
+/lib/                   - External libraries
+/tools/                 - Build and utility tools
+```
+
+## Coding Conventions
+
+### Naming Conventions
+
+1. **Types**: Use `_t` suffix for typedef'd types: `gyroConfig_t`, `pidController_t`
+2. **Enums**: Use `_e` suffix for enum types: `portMode_e`, `cfTaskPriority_e`
+3. **Functions**: Use camelCase with verb-phrase names: `gyroInit()`, `deleteAllPages()`
+4. **Variables**: Use camelCase nouns, avoid noise words like "data" or "info"
+5. **Booleans**: Question format: `isOkToArm()`, `canNavigate()`
+6. **Constants**: Upper case with underscores: `MAX_GYRO_COUNT`
+7. **Macros**: Upper case with underscores: `FASTRAM`, `STATIC_UNIT_TESTED`
+
+### Code Style
+
+- **Indentation**: 4 spaces (no tabs)
+- **Braces**: K&R style (opening brace on same line, except for functions)
+- **Line Length**: Keep reasonable (typically under 120 characters)
+- **Comments**: Explain WHY, not WHAT. Document variables at declaration, not at extern usage
+- **Header Guards**: Use `#pragma once` (modern convention used throughout codebase)
+
+### Memory Attributes
+
+INAV uses special memory attributes for performance-critical code on resource-constrained MCUs:
+
+```c
+FASTRAM                     // Fast RAM section (aligned)
+EXTENDED_FASTRAM            // Extended fast RAM (STM32F4/F7 only)
+DMA_RAM                     // DMA-accessible RAM (STM32H7, AT32F43x)
+SLOW_RAM                    // Slower external RAM - deprecated, o not use
+STATIC_FASTRAM              // Static variable in fast RAM
+STATIC_FASTRAM_UNIT_TESTED  // Static fast RAM variable visible in unit tests
+```
+
+### Test Visibility Macros
+
+```c
+STATIC_UNIT_TESTED         // static in production, visible in unit tests
+STATIC_INLINE_UNIT_TESTED  // static inline in production, visible in tests
+INLINE_UNIT_TESTED         // inline in production, visible in tests
+UNIT_TESTED                // Always visible (no storage class)
+```
+
+## Build System
+
+### CMake Build Process
+
+INAV uses CMake with custom target definition functions:
+
+1. **Target Definition**: Each board has a `target.h` and optionally `CMakeLists.txt`
+2. **Hardware Function**: `target_stm32f405xg(NAME optional_params)`
+3. **Build Directory**: Always use out-of-source builds in `/build` directory
+
+### Building a Target
+
+```bash
+# From workspace root
+cd build
+cmake ..
+make MATEKF722SE     # Build specific target
+make                 # Build all targets
+```
+
+### Target Configuration
+
+Targets are defined in `/src/main/target/TARGETNAME/`:
+- `target.h`: Hardware pin definitions, feature enables, MCU configuration
+- `target.c`: Board-specific initialization code
+- `CMakeLists.txt`: Build configuration (optional)
+
+Example target definition:
+```c
+#define TARGET_BOARD_IDENTIFIER "MF7S"
+#define LED0 PA14
+#define BEEPER PC13
+#define USE_SPI
+#define USE_SPI_DEVICE_1
+#define SPI1_SCK_PIN PA5
+```
+
+### Conditional Compilation
+
+Feature flags control code inclusion:
+```c
+#ifdef USE_GPS
+    // GPS code
+#endif
+
+#if defined(STM32F4)
+    // F4-specific code
+#elif defined(STM32F7)
+    // F7-specific code
+#endif
+```
+
+## Key Concepts
+
+### Parameter Groups (PG)
+
+INAV uses a sophisticated configuration system called "Parameter Groups" for persistent storage:
+
+```c
+// Define a configuration structure
+typedef struct {
+    uint8_t gyro_lpf_hz;
+    uint16_t gyro_kalman_q;
+    // ...
+} gyroConfig_t;
+
+// Register with reset template
+PG_REGISTER_WITH_RESET_TEMPLATE(gyroConfig_t, gyroConfig, PG_GYRO_CONFIG, 12);
+
+// Define default values
+PG_RESET_TEMPLATE(gyroConfig_t, gyroConfig,
+    .gyro_lpf_hz = 60,
+    .gyro_kalman_q = 200,
+    // ...
+);
+
+// Access in code
+gyroConfig()->gyro_lpf_hz
+```
+
+**Key Functions:**
+- `PG_REGISTER_WITH_RESET_TEMPLATE()`: Register with static defaults
+- `PG_REGISTER_WITH_RESET_FN()`: Register with function-based initialization
+- `PG_REGISTER_ARRAY()`: For arrays of configuration items
+- Parameter group IDs are in `config/parameter_group_ids.h`
+
+### Scheduler
+
+INAV uses a priority-based cooperative task scheduler:
+
+```c
+typedef enum {
+    TASK_PRIORITY_IDLE = 0,
+    TASK_PRIORITY_LOW = 1,
+    TASK_PRIORITY_MEDIUM = 3,
+    TASK_PRIORITY_HIGH = 5,
+    TASK_PRIORITY_REALTIME = 18,
+} cfTaskPriority_e;
+```
+
+Tasks are defined in `fc/fc_tasks.c` with priority and desired execution period.
+
+### Sensors and Calibration
+
+Sensors use a common pattern:
+1. **Detection**: Auto-detect hardware at boot (`gyroDetect()`, `baroDetect()`)
+2. **Initialization**: Configure sensor parameters
+3. **Calibration**: Zero-offset calibration (gyro, accelerometer)
+4. **Data Processing**: Apply calibration, alignment, and filtering
+
+### Flight Control Loop
+
+The main control loop follows this pattern:
+1. **Gyro Task** (highest priority): Read gyro, apply filters
+2. **PID Task**: Calculate PID corrections
+3. **RX Task**: Process radio input
+4. **Other Tasks**: Sensors, telemetry, OSD, etc. (lower priority)
+
+### MSP Protocol
+
+MultiWii Serial Protocol is used for configuration and telemetry:
+- Request/response model
+- Message types defined in `msp/msp_protocol.h`
+- Handlers in `fc/fc_msp.c`
+
+## Common Patterns
+
+### Hardware Abstraction
+
+INAV abstracts hardware through resource allocation:
+
+```c
+// IO pins
+IO_t pin = IOGetByTag(IO_TAG(PA5));
+IOInit(pin, OWNER_SPI, RESOURCE_SPI_SCK, 1);
+
+// Timers
+const timerHardware_t *timer = timerGetByTag(IO_TAG(PA8), TIM_USE_ANY);
+
+// DMA
+dmaIdentifier_e dma = dmaGetIdentifier(DMA1_Stream0);
+```
+
+### Error Handling
+
+INAV uses several approaches:
+1. **Return codes**: Boolean success/failure or error enums
+2. **Diagnostics**: `sensors/diagnostics.c` for sensor health
+3. **Status indicators**: Beeper codes, LED patterns for user feedback
+4. **Logging**: CLI-based logging system
+
+### Filter Chains
+
+Sensor data typically goes through multiple filtering stages:
+
+```c
+// Low-pass filters
+gyroLpfApplyFn = lowpassFilterGetApplyFn(filterType);
+gyroLpfApplyFn(&gyroLpfState[axis], sample);
+
+// Notch filters (for dynamic filtering)
+for (int i = 0; i < dynamicNotchCount; i++) {
+    sample = biquadFilterApply(&notchFilter[i], sample);
+}
+```
+
+### Board Alignment
+
+All sensors go through board alignment transforms to correct for mounting orientation:
+
+```c
+// Apply board alignment rotation matrix
+applySensorAlignment(gyroData, gyroData, gyroAlign);
+```
+
+### SITL (Software In The Loop)
+
+INAV can be compiled for host system simulation:
+```bash
+cmake -DSITL=ON ..
+make
+```
+
+## Development Workflow
+
+### Branching Strategy
+
+- **`maintenance-X.x`**: Current version development (e.g., `maintenance-9.x`)
+- **`maintenance-Y.x`**: Next major version (e.g., `maintenance-10.x`)
+- **`master`**: Tracks current version, receives merges from maintenance branches
+
+### Pull Request Guidelines
+
+1. **Target Branch**: 
+   - Bug fixes and backward-compatible features → current maintenance branch
+   - Breaking changes → next major version maintenance branch
+   - **Never** target `master` directly
+
+2. **Keep PRs Focused**: One feature/fix per PR
+
+3. **Code Quality**:
+   - Follow existing code style
+   - Add unit tests where possible
+   - Update documentation in `/docs`
+   - Test on real hardware when possible
+
+4. **Commit Messages**: Clear, descriptive messages
+
+### Important Files to Check
+
+Before making changes, review:
+- `docs/development/Development.md` - Development principles
+- `docs/development/Contributing.md` - Contribution guidelines
+- Target-specific files in `/src/main/target/`
+
+## Important Files and Directories
+
+### Configuration Files
+
+- `platform.h`: Platform-specific includes and defines
+- `target.h`: Board-specific hardware configuration
+- `config/parameter_group.h`: Parameter group system
+- `config/parameter_group_ids.h`: PG ID definitions
+- `fc/settings.yaml`: CLI settings definitions
+
+### Core Flight Control
+
+- `fc/fc_core.c`: Main flight control loop
+- `fc/fc_init.c`: System initialization
+- `fc/fc_tasks.c`: Task scheduler configuration
+- `flight/pid.c`: PID controller implementation
+- `flight/mixer.c`: Motor mixing
+
+### Key Headers
+
+- `build/build_config.h`: Build-time configuration macros
+- `common/axis.h`: Axis definitions (X, Y, Z, ROLL, PITCH, YAW)
+- `common/maths.h`: Math utilities and constants
+- `common/filter.h`: Digital filter implementations
+- `drivers/accgyro/accgyro.h`: Gyro/accelerometer interface
+
+## AI Agent Guidelines
+
+### When Adding Features
+
+1. **Understand the Module**: Read related files in the same directory
+2. **Check for Similar Code**: Search for similar features to maintain consistency
+3. **Follow Parameter Group Pattern**: New settings should use PG system
+4. **Add to Scheduler**: New periodic tasks go in `fc/fc_tasks.c`
+5. **Update Documentation**: Add/update files in `/docs` 
+6. **Consider Target Support**: Use `#ifdef USE_FEATURE` for optional features
+7. **Generate CLI setting docs**: Remember to inform user to run `python src/utils/update_cli_docs.py`
+8. **Follow conding standard**: Follow MISRA C rules
+9. **Increase Paremeterer Group Version**: When changing PG structure, increase version corresponding in `PG_REGISTER`, `PG_REGISTER_WITH_RESET_FN`, `PG_REGISTER_WITH_RESET_TEMPLATE`, `PG_REGISTER_ARRAY` or `PG_REGISTER_ARRAY_WITH_RESET_FN`
+
+### When Fixing Bugs
+
+1. **Review Recent Changes**: Check git history for related modifications
+2. **Test Signal Path**: For sensor issues, trace from hardware through filters to consumer
+3. **Consider All Platforms**: STM32F4, F7, H7, and AT32 may behave differently
+4. **Check Memory Usage**: Embedded system has limited RAM/flash
+
+### When Refactoring
+
+1. **Maintain API Compatibility**: Unless targeting next major version
+2. **Preserve Unit Tests**: Update tests to match refactored code
+3. **Update Documentation**: Keep docs synchronized with code changes
+4. **Consider Performance**: Profile on target hardware, not just host compilation
+5. **Check All Callers**: Use grep/search to find all usage sites
+
+### Common Pitfalls to Avoid
+
+1. **Don't Ignore Memory Attributes**: FASTRAM placement affects real-time performance
+2. **Don't Break Parameter Groups**: Changing PG structure requires version bump
+3. **Don't Assume Hardware**: Always check feature flags (`#ifdef USE_GPS`)
+4. **Don't Break MSP**: Changes to MSP protocol affect configurator compatibility
+5. **Don't Commit Wrong Branch**: Target maintenance branch, not master
+6. **Don't Skip Documentation**: Code without docs increases support burden
+7. **Don't Hardcode Values**: Use parameter groups for configurable values
+
+### Searching the Codebase
+
+**Find definitions:**
+```bash
+grep -r "typedef.*_t" src/main/  # Find all type definitions
+grep -r "PG_REGISTER" src/main/  # Find parameter groups
+grep -r "TASK_" src/main/        # Find scheduled tasks
+```
+
+**Find usage:**
+```bash
+grep -r "functionName" src/main/
+grep -r "USE_GPS" src/main/target/  # Feature support by target
+```
+
+**Find similar code:**
+- Look in the same directory first
+- Check for similar sensor/peripheral implementations
+- Review git history: `git log --all --oneline --grep="keyword"`
+
+### Understanding Control Flow
+
+1. **Startup**: `main.c` → `fc_init.c:init()` → `fc_tasks.c:tasksInit()`
+2. **Main Loop**: `scheduler.c:scheduler()` executes tasks by priority
+3. **Critical Path**: Gyro → PID → Mixer → Motors (highest priority)
+4. **Configuration**: CLI/MSP → Parameter Groups → EEPROM
+
+### Cross-Platform Considerations
+
+Different MCU families have different characteristics:
+
+- **STM32F4**: Most common, 84-168 MHz, FPU, no cache
+- **STM32F7**: Faster, 216 MHz, FPU, I/D cache, requires cache management
+- **STM32H7**: Fastest, 480 MHz, more RAM, complex memory architecture (DTCM, SRAM)
+- **AT32F43x**: Chinese MCU, STM32F4-compatible, different peripherals
+
+Always test on target or use `#if defined()` guards for MCU-specific code.
+
+## Quick Reference
+
+### File Naming Patterns
+
+- `*_config.h`: Configuration structures (usually with PG)
+- `*_impl.h`: Implementation headers (MCU-specific)
+- `*_hal.h`: Hardware abstraction layer
+- `accgyro_*.c`: Gyro/accelerometer drivers
+- `bus_*.c`: Communication bus drivers (SPI, I2C)
+
+### Common Abbreviations
+
+- **FC**: Flight Controller
+- **PG**: Parameter Group
+- **MSP**: MultiWii Serial Protocol
+- **CLI**: Command Line Interface
+- **OSD**: On-Screen Display
+- **RTH**: Return to Home
+- **PID**: Proportional-Integral-Derivative (controller)
+- **IMU**: Inertial Measurement Unit (gyro + accel)
+- **AHRS**: Attitude and Heading Reference System
+- **ESC**: Electronic Speed Controller
+- **SITL**: Software In The Loop
+- **HITL**: Hardware In The Loop
+
+## Resources
+
+- **Main Repository**: https://github.com/iNavFlight/inav
+- **Configurator**: https://github.com/iNavFlight/inav-configurator
+- **Discord**: https://discord.gg/peg2hhbYwN
+- **Documentation**: https://github.com/iNavFlight/inav/wiki
+- **Release Notes**: https://github.com/iNavFlight/inav/releases
+
+## Version Information
+
+This document is accurate for INAV 9.0.1. As the project evolves, some details may change. Always refer to the latest documentation and code for authoritative information.
+
+---
+
+**Remember**: INAV flies aircraft that people build and fly. Code quality, safety, and reliability are paramount. When in doubt, ask the community or maintainers for guidance.