FM 1-0 (US Army, 2021) визначає 3 компетенції та 20 функцій J-1. Slugba.org покриває 70% — 11 повних, 8 часткових, 1 не реалізовано.
Загалом: 20 функцій, ~70% покриття
Комплектування та готовність: забезпечити підрозділ потрібною кількістю потрібних людей в потрібному місці.
Проблема: Командир формально знає скільки людей в підрозділі, але не має оперативного доступу до деталей. Хто хворий — знає черговий, але не передає при зміні. Новий боєць прибув — тиждень ходить «нічий», поки його внесуть у всі списки.
Правильний стан: Один екран → повний список підрозділу з актуальними статусами, званнями, посадами, обмеженнями. Новий боєць з'являється в системі в момент приєднання. Інформація не залежить від того, хто сьогодні черговий.
Шлях у Slugba.org: members з повними даними + онбординг через invite code + soft-delete + ієрархія 4 рівні. Командир відкриває structure_screen і бачить все.
Проблема: На запитання «скільки людей боєготові?» командир відповідає «приблизно 25–30». Для точної відповіді потрібно обдзвонити чергових, звірити списки. Вищий штаб запитує PERSTAT — командир витрачає годину на ручне зведення, яке містить вчорашні дані.
Правильний стан: Командир відкриває один екран і миттєво бачить: 28 на службі, 4 хворих, 3 у відпустці, 5 вихідних. Fill rate: 82%. Тренд: минулого графіку було 31 на службі. При запиті PERSTAT — кнопка «Експорт» → готовий звіт.
Шлях у Slugba.org: readiness_dashboard_screen агрегує schedule_members по статусах. Тренд по останніх 5 графіках.
Проблема: Боєць стоїть 8-му добу поспіль. Ніхто не відстежує, бо «ну він же не скаржиться». На 9-ту добу він засинає на посту або потрапляє в ДТП. В NATO це порушення Duty of Care з юридичними наслідками для командира.
Правильний стан: Система автоматично рахує безперервні доби служби. На 5-ту — оранжеве попередження, на 7-му — червоне «КРИТИЧНО». Якщо інцидент таки стався — система показує що попередження було видане. Захист і для бійця, і для командира.
Шлях у Slugba.org: schedule_members.duty_days + Fatigue Alerts у readiness_dashboard_screen (пороги ≥5 та ≥7 діб).
Проблема: На пості «Яма» потрібно 2 людини на зміну. Доступні 8, з них 2 хворих, 1 у відпустці. Залишилось 4 на 3 групи по 2 = потрібно 6. Дефіцит. Але командир дізнається про це коли сідає складати графік — пізно.
Правильний стан: Per-post manning видно в будь-який момент: «Яма: 4 доступних / 6 потрібних = 67% — дефіцит». Заздалегідь. Командир може допустити ще бійців, перерозподілити, запросити підкріплення.
Шлях у Slugba.org: posts.people_required × кількість груп = потреба. post_access ∩ schedule_members (onDuty) = доступні. UI в розробці.
Проблема: Новий графік — командир не пам'ятає хто був минулого разу. Черговий офіцер з'ясовує «а де Мороз? він же минулого разу був». Відповідь: «захворів позавчора».
Правильний стан: При створенні нового графіку система автоматично показує: «Порівняно з минулим: +2 (Мороз, Зварич повернулись), -1 (Позняков захворів)». Командир бачить зміни одразу.
Шлях у Slugba.org: schedule_detail_screen порівнює schedule_members поточного графіку з попереднім через getSchedulesBefore.
Проблема: Боєць захворів → «sick», одужав → «onDuty». Через місяць ніхто не пам'ятає що він хворів, скільки днів. Якщо хворіє третій раз за квартал — це pattern, якого ніхто не бачить.
Правильний стан: Журнал інцидентів: дата, тип (хвороба/травма/госпіталізація), тривалість, опис. Командир бачить: «Коваленко: 3 лікарняних за 2 місяці, загалом 14 днів». Це не контроль — це турбота.
Шлях у Slugba.org: Нова таблиця incident_records: member_id, type, date, end_date, description. Інтеграція з schedule_members.
Адміністративні функції S-1/J-1 для бійців та командування.
Проблема: Старший солдат складає графік «по своїм принципам». Друзі на легких постах, ті хто не може опиратися — в ніч. Командир не контролює, бо «графік же є». Статистики немає, порівняти нема з чим.
Правильний стан: Алгоритм розподіляє: побажання 50% + справедливість 40% + випадковість 10%. Кожне призначення має assignment_source. Статистика публічна. Графік можна оскаржити — бо є дані.
Шлях у Slugba.org: scheduler_service з fairness score + schedule_slots.assignment_source + workload_stats + stats_screen.
Проблема: Бузурний має 37.5 балів навантаження, Чернюк — 8. Розрив 4.7 рази. Але ніхто цього не бачить, бо статистика не ведеться. Бузурний відчуває несправедливість, але без цифр це просто скарга.
Правильний стан: Публічна статистика по кожному бійцю: години, нічні, вихідні, fairness score. Дані говорять самі за себе. Не потрібно скаржитись — достатньо показати екран.
Шлях у Slugba.org: workload_stats + stats_screen з публічним доступом для всіх бійців.
Проблема: Боєць Зварич має досвід роботи електриком — записано в особовій справі. Командир не знає. Коли ламається електрика — шукають цивільного спеціаліста. Зварич стоїть поруч і мовчить, бо ніхто не питав.
Правильний стан: В профілі бійця — теги навичок, оцінки знань, допуски до постів. Командир шукає «хто має тег 'електрика'». Алгоритм автоматично враховує: без допуску не поставить.
Шлях у Slugba.org: member_tags + member_knowledge (category, score 1-10) + post_access + post_requirements.
Проблема: Боєць має медичне обмеження — не може в ніч. Графік складає інша людина, яка «забуває». Боєць стоїть в ніч, стан погіршується. Формально обмеження «враховане» — записане десь. Фактично система не заважає його порушити.
Правильний стан: Обмеження в системі. Алгоритм фізично не може поставити бійця з noNightShifts на нічну зміну — hard block. При ручному редагуванні — warning. Обмеження створені конкретною особою — аудит.
Шлях у Slugba.org: member_constraints з 5 типами + blocked_post_id + автоматична перевірка в scheduler_service.
Проблема: «Бійці не скаржаться — значить все добре». Насправді: немає механізму, страх конфлікту, «все одно нічого не зміниться». Результат — passive aggression, мовчазна демотивація.
Правильний стан: Кожен боєць ранжує зміни та пости через drag & drop. Алгоритм враховує з вагою 50%. Навіть якщо не отримав ідеальну зміну — бачить що система намагалась.
Шлях у Slugba.org: member_preferences (shiftRanking, postRanking, unavailableDates) + preference_screen (drag & drop).
Проблема: Ротація кожні 3 доби — день → вечір → ніч. Дослідження NATO: швидка ротація не дає організму адаптуватись. USS Fitzgerald + USS McCain (2017): 17 загиблих моряків через хронічну втому.
Правильний стан: Алгоритм перевіряє gap між змінами (мін. 8 годин). Якщо боєць закінчив о 02:00 і наступна о 06:00 — 4 години, система блокує. Між графіками — те саме.
Шлях у Slugba.org: checkRestCompliance() в scheduler_service + інтеграція в генерацію (block), ручне редагування (warning), новий графік (check).
Проблема: Боєць каже «потрібна відпустка». Командир: «добре, йди». Через місяць ніхто не пам'ятає: коли пішов? скільки використав? скільки залишилось? Планування неможливе.
Правильний стан: Журнал відпусток: тип (щорічна / сімейні / навчальна), дати, наказ, залишок. «Коваленко: 12 з 30 днів, наступна 15–25 травня». Можна планувати manning заздалегідь.
Шлях у Slugba.org: Нова таблиця leave_records. Інтеграція з schedule_members: автоматичне status=vacation при активній відпустці.
Проблема: Боєць отримав подяку від командира усно — забуто через тиждень. При атестації: «нічого особливого не було». Або: усне зауваження раз, вдруге — pattern, якого ніхто не бачить.
Правильний стан: Кожне заохочення та стягнення зафіксоване: тип, опис, severity (1–10), дата. При атестації — повна історія. При призначенні — видно динаміку.
Шлях у Slugba.org: member_records (record_type, description, severity) + відображення в member_detail_screen.
Проблема: «Чому Коваленко стояв 3 ночі поспіль?» — через місяць відповіді немає. Графік на папері, папір загублено. «Хто вирішив поставити Мороза на Яму?» — невідомо.
Правильний стан: Кожне призначення має assignment_source: algorithm / manual / swap. Графік має timestamps: створено, згенеровано, опубліковано, ким. Можна відкрити будь-який минулий графік і побачити повну картину.
Шлях у Slugba.org: schedule_slots.assignment_source + schedules (timestamps + created_by) + повна історія (archived status).
Проблема: В підрозділі 40 бійців. Дані в різних місцях: ПІБ — в журналі, звання — в іншому, обмеження — в третьому. Черговий не має доступу до медичних обмежень. Боєць не бачить свій графік поки не прийде на розвід.
Правильний стан: Одна система, різні рівні доступу. Адмін бачить все. Боєць — свій графік і публічну статистику. Доступ контролюється автоматично, не «домовленістю».
Шлях у Slugba.org: Supabase Auth + RLS з SECURITY DEFINER + 3 ролі + рекурсивні CTE для ієрархії.
Проблема: Графік опубліковано. Командир кидає в чат. Хтось прочитав, хтось ні. Новий боєць взагалі не в курсі. «А я не бачив» — стандартна відповідь, яку неможливо перевірити.
Правильний стан: Публікація графіку → автоматичне сповіщення в додатку. Є підрахунок непрочитаних. Є список: хто отримав, хто прочитав. «Не бачив» перестає працювати.
Шлях у Slugba.org: notifications + notification_service + notification_list_screen. Push через FCM — в плані.
Взаємодія з іншими рівнями командування та штабними секціями.
Проблема: Комбат має 4 роти. Кожна веде свою статистику (якщо веде). Запитує ротних «як у вас зі станом людей?» — кожен відповідає по-своєму, в різних форматах. Порівняти неможливо.
Правильний стан: Комбат відкриває structure_screen: «1 Рота: readiness 78%, fill rate 85%. 2 Рота: 62%, 71% — проблема». Drill-down в кожну роту. Стандартизований формат на кожному рівні.
Шлях у Slugba.org: Ієрархія 4 рівні є. Агрегація readiness та manning по дочірніх організаціях — в розробці.
Проблема: J-1 працює окремо від J-3 (операції) та J-4 (логістика). J-3 планує операцію, запитує J-1 «скільки людей?» — J-1 рахує вручну, відповідає через годину. За цю годину 2 бійці захворіли.
Правильний стан: J-3 має API-доступ до readiness data в реальному часі. Не «запитай кадровика» — автоматичний feed: «зараз 28 доступних, з них 12 з допуском до Ями».
Шлях у Slugba.org: REST API endpoint для readiness/manning. Інтеграція з Army+ / Impulse / DELTA — при масштабуванні.
Проблема: Вищий штаб запитує звіт. Командир збирає дані з різних джерел, вручну заповнює табличку. Кожен підрозділ робить по-своєму. Штаб витрачає час на уніфікацію. Дані вже застарілі.
Правильний стан: Кнопка «Експорт» → стандартизований звіт (PDF/Excel) з полями STANAG 2034. Однаковий формат від кожного підрозділу. Згенерований за секунди з актуальних даних.
Шлях у Slugba.org: Export module на readiness_dashboard. Дані вже є — потрібен генератор у стандартному форматі.
Відповідність NATO FM 7-0 (Training). Плановий обсяг — 8 функцій, у Фазах 2–4.
Проблема: бійці в тилу мають час, але нема структурованого навчання. Відео на YouTube — розрізнені. Накази на папері. Немає прогресу.
Правильний стан: курси з відео, матеріалами, перевіркою. Прогрес фіксується, видно командиру. Бійці бачать свою траєкторію розвитку.
Шлях: нові таблиці training_courses, course_modules, member_course_progress. Інтеграція з існуючим member_knowledge.
Проблема: боєць не знає що саме йому вчити. Командир не знає де у бійця прогалини. Розвиток — хаотичний.
Правильний стан: система бачить поточний рівень (score 1-10 по кожній категорії) і рекомендує курси для заповнення прогалин. Командир бачить траєкторію кожного.
Шлях: recommender на основі member_knowledge + course requirements. У Phase 4 — AI-рекомендації.
Проблема: допуск до зброї / техніки / роботи з матеріалами має термін дії. Про це забувають — аж поки не відбувається інцидент.
Правильний стан: кожна кваліфікація — з assessed_at і valid_until. Alerts: «Коваленко — протерміновано допуск 3 тижні тому». На readiness dashboard.
Шлях: розширення member_knowledge: додати поля термінів + alert engine.
Проблема: організація внутрішніх занять — усно. Хто прийшов, хто ні — не фіксується. Ефективність — невідома.
Правильний стан: планування тренінгів через ту саму scheduling-архітектуру: ресурс (час інструктора) + учасники + облік відвідування + оцінка.
Шлях: training_sessions як особливий тип «чергувань», з тими самими конфліктами, fairness, audit.
Проблема: в батальйоні є досвідчені бійці (медики, дронопілоти, саперы), які могли б навчати. Але їх ніхто не знає, до них не звертаються.
Правильний стан: система показує командиру: «у вас 3 бійці зі score ≥8 в тактичній медицині — можна організувати навчання силами підрозділу». Без бюджету і зовнішніх інструкторів.
Шлях: на основі Talent Discovery (уже є) + система призначення ролі «інструктор» з фіксацією в member_records.
Проблема: методички, статути, накази — розкидані по Google Drive, Telegram-чатах, паперових папках. Нового бійця треба тиждень «вводити в курс».
Правильний стан: єдине сховище. Доступ за ролями. Поєднано з курсами (матеріал → курс → тест).
Шлях: resources таблиця + Supabase Storage для файлів + RLS за ролями.
Проблема: оцінка знань — «командир запитав, командир оцінив». Суб'єктивно, без документації, без стандарту.
Правильний стан: автоматичне оцінювання (multiple choice, short answer). Результати → оновлюють member_knowledge.score. Аудит знань всього підрозділу — в один клік.
Шлях: assessments, assessment_questions, member_assessment_attempts. Зв'язок з курсами.
Проблема: боєць пройшов 5 курсів, отримав 3 допуски, здав 2 іспити — це ніде не видно разом. При переведенні на фронт — доказувати все з нуля.
Правильний стан: цифровий portfolio: всі сертифікати, досягнення, курси, оцінки — на одній сторінці. Видимі при пошуку талантів, враховуються при переведенні.
Шлях: агрегація з course_progress + assessment_attempts + member_records → member_portfolio view.
AI для людей, а не лише для зброї
Що потрібно фронту — що є в тилу → рекомендації про переведення
NLP-аналіз анкет і коментарів → приховані навички
Recommender: курс → роль → переведення через N місяців
Відповідність базується на: