Your Delivery × CVision × DANI · Пълна имплементация на tracker/telematics software · MOVO операционен краен срок 1 септември 2026
Архитектурно решение: MOVO vs Logistics OS
Hanan + Dr. Adnan срещата разделя проекта на MOVO (standalone tracking/route/dispatch продукт) и Logistics OS (по-широката DANI intelligence инфраструктура). Заложен твърд срок: система, операционна до 1 септември 2026. Успоредно — 29 юни capacity одит показва Codinext капацитет ~90–110ч срещу нужни ~300ч за критичния път (3x дефицит).
Резултат: писмено архитектурно решение + заложен hard deadline. Не е build резултат.
Фазиране на MVP + Product Owner governance
Веселин дава устна оценка от 8 седмици за пълен dashboard — Тодор разделя на 3 фази (Velocity parity → route/driver/fuel intelligence → пълна DOI). Независим CTO re-estimate за tracker програмата: 630–1,385ч (реалистично ~920ч, 16–18 седмици) — над 2x спрямо устната цифра. Паралелно, стратегическата среща на 12 юли премества Your Delivery към активно Product Owner управление и позиционира Your Delivery = operational lab, MOVVO = commercial intelligence platform.
Резултат: писмени планове (Phased MVP Plan, Zeus + Tracker execution programs), governance решение. Нула software delivery тази седмица.
Address / Manifest / Trip — три основни дефекта открити
Пощенски код/Eircode не обновява автоматично пина на картата; промяна в Cork manifest схемата чупи парсинга и адресното съвпадение; workflow "Create Trip" липсва изцяло от "Create Order". Препоръка: канонична Manifest Ingestion + Address Intelligence + Order-to-Trip оркестрация, преизползваема между MOVVO, Your Delivery, CVision и DANI.
Очакван резултат: възпроизведен Cork бъг, разделен parser/geocoding root cause, PRD за Create Trip.
Admin панел за GPS/SIM + начална IMEI/ICCID регистрация
Добавени интеграции за SIM карти и GPS тракери в admin панела (реално видяно на срещата). 10 устройства регистрирани в TrackCar, само 1 синхронизирано — IMEI задължителен за TrackCar API. Live-update механизъм (HTTP polling / SSE / WebSockets) обсъден, но не заключен — работен избор: HTTP polling на 5 сек. Флот +14 нови вана; Velocity residue тракери все още активни; CERT горивни карти — среща насрочена за 27.07.
Резултат: частичен — admin UI реален, но само 10% от устройствата синхронизирани и 4 архитектурни въпроса остават отворени.
Live Tracking доказан — но открит P0 риск с изчезващи адреси
Първото реално потвърждение: системата получава почти моментални updates от Traccar, прилага company-based достъп и визуализира устройства в реално време — работещо демо. Trip History в начална версия (raw GPS + snap-to-road прототип). Но екипът открива, че адреси/доставки изчезват или не се намират след създаване на следващ маршрут — обявено за P0: компрометира route planning, audit trail, customer history и бъдещото обучение на DANI. Дефинирани 6 gate-а за изпълнение (Data Integrity → Canonical Model → Route Workflow → Operational UI → Dynamic ETA → Intelligence).
Резултат: доказан live tracking + access control; блокиращ P0 дефект спира всяко разширяване на функционалност, докато не се затвори.
Gate 1 — Data Integrity (критична точка)
Root-cause анализ и фикс на изчезващите адреси (Веселин + backend екип, Виктор като reporter); persistence, audit log, versioning и regression тестове. Никакви нови route функции не влизат в production, докато този gate не е затворен. Паралелно: среща с Иван Богоев за интеграционния план (заявена за "следващата работна седмица" на 29 юли срещата).
Очакван резултат: документиран defect + fix + regression test; съгласувани API/data flow с Богоев.
Gate 2 + Gate 3 — Canonical Data Model & Route Workflow
Единни идентификатори и връзки между manifest, delivery, address, route, stop, trip и device (system of record дефиниция). Документирани status transitions за planning → creation → execution → optimization.
Очакван резултат: одобрена schema + документиран route lifecycle.
Gate 4 — Operational UI
Интегриране на live map и Trip History в реален UI (Крис + frontend екип), Single View на устройство, role-based достъп. Добавяне на telemetry точки (speed, timestamp, course) към Trip History след стабилизиране на trip storage.
Очакван резултат: production UI за live map + Trip History с role-based видимост.
Gate 5 — Dynamic ETA
Проектиране на stop-event detection (geofence / ignition / speed=0 / driver action), service-time baseline модел, recalculation engine — ETA се преизчислява за всички оставащи стопове след всяко реално достигнато спиране, с confidence диапазон вместо подвеждащо единично време.
Очакван резултат: работещ ETA recalculation с измерим median/P90 error по stop.
Gate 6 — Intelligence + MOVO Go-Live
Address matching с confidence scoring, route anomaly detection, DANI препоръки. Това е и заложеният от 30 юни решението твърд краен срок за операционна MOVO система.
Очакван резултат: DANI first agents (ETA confidence, address match, route anomaly, service-time calibration) + операционна MOVO система.
| Въпрос | Тип | Защо има значение |
|---|---|---|
| P0 — root cause на изчезващи адреси | Технически / критичен | Не е ясно дали е data loss, UI filtering дефект или липсваща persistence. Блокира Gate 2–6 и всяко ново route feature. |
| HTTP Polling vs SSE vs WebSockets | Архитектурен | Работният избор (HTTP polling) не е формално заключен; при растеж на флота/клиентите трябва решение преди мащабиране. |
| Route data ownership / system of record | Архитектурен | Кой компонент е source of truth за manifest, delivery, address, route, stop, trip — неизяснено, директно свързано с Gate 2. |
| Data сегрегация между компании (topics модел) | Архитектурен / security | Обсъдено, но не потвърдено — риск от клиент, виждащ чужди устройства при мащабиране към SaaS. |
| Fuel event detection | Технически | 40-минутен престой на бензиностанция без промяна в горивото — хардуерен или конфигурационен проблем, недиагностициран. |
| Velocity residue тракери | Данни / интеграция | Устройства от старата система продължават да отчитат — брой варира при refresh, застрашава коректността на демо и производствени данни. |
| Codinext капацитет: Zeus vs Tracker | Ресурсен | И двете програми се борят за същия Веселин/backend капацитет; без явно приоритизиране, и двете забавят. |
| CERT горивни карти — резултат от срещата на 27.07 | Оперативен | Среща е била насрочена; изходът не е документиран в наличните материали към момента на този календар. |
| Име | Роля / зона на отговорност |
|---|---|
| Веселин (Codinext) | Backend lead, GPS/TrackCar интеграции, P0 root-cause fix, canonical schema дизайн. |
| Веско | Backend, GPS интеграции, регистрация на първите устройства. |
| Виктор | Регистрация на устройства (IMEI/ICCID), reporter на P0 дефекта. |
| Крис | UI/UX, интеграция на live map и Trip History в интерфейса (след завръщане). |
| Иван (Богоев) | Данни, Excel шаблони, интеграционен план с CVision/DANI. |
| Тодор | Продуктова стратегия, canonical entities решение, Zeus/роботизация проучване, priority calls. |