1. Весь девелопмент зроблений не з _docs/01_solution/solution.md, а з всіх документів в `docs/01_solution/`
Тобто треба подивитись наскільки вся імплементація відповідає саме цьому солюшену: _docs/01_solution/solution.md
Наприклад, VO треба зробити по cuVSLAM (якщо звісно не буде явних перепон повязаних з ним)

Тому що: SP+LG (SuperPoint + LightGlue) rejection rationale: 15-33x slower than cuVSLAM. No built-in IMU fusion, loop closure, or tracking failure detection. Building these features around SP+LG would take significant development time and still be slower. XFeat at ~30-50ms is a better fallback for VO if cuVSLAM fails on nadir camera.

2. Весь код не мусить лежати в src/gps_denied/, весь проект цей про gps_denied. Треба покласти його в src/

3. Автодевелопмент engine. Всі проекти в azaion або розроблються, або приводяться до механізму девелопменту, що описана в .cursor/skills/autopilot.
 /flows/greenfield для нового проекта
 flows/existing-code для існуючого кода.
 
 Відповідно треба існуючий codebase до цього engine. 
Алгоритм autopilot existing code описаний в flows/existin-code. Коротко це - питаємо про необхідні дані для e2e тестів та вимоги для яким мусить відповідати рішення, рефакторимо проект для можливості покриття e2e тестами, покриваємо e2e тестами, тобто пишемо підсистему окрему що запускає наш весь продукт як black box, дивимось що воно працює, і тоді лише рефакторимо та ітераційна розробка йде.
Те саме в greenfield, тільки оскільки там нема початкового коду, то e2e тести пишуться після коду.  
Можливо для початку взяти IMU дані з SITL... щоб рухатись далі. Але так чи інакше imu реальні дані треба. 

4. Збір даних (IMU + video feed synchronized) для проведення реальних e2e тестів. В Дениса Попова кажись був mavic, я його попросив щоб він познімав з камерою опущеною вниз та дав логи. Також можливо що наші мавікісти зможуть помогти, але тут невідомо, бо треба їх переконати зробити пару дивних дуже вильотів з великої висоти і опущеною вниз камерою замість того щоб вишукувати цілі..