Сканує всі git-репозиторії під заданим коренем (типово ~/Projects) і одним викликом повертає, які з них "потребують уваги": незакомічені зміни, неопубліковані коміти, або невдалий/ще не завершений останній CI-запуск. Заміняє ручний цикл git status + gh run list по кожному репо окремо. Репо розкидані між кількома коренями (напр. частина в ~/Projects, частина деінде)? Передай roots замість root - скановуються всі разом, одним викликом.

Перевіряє актуальність ~/Projects/Architecture/.txt кожного git-репозиторія: "missing" (документації нема взагалі), "stale" (репо мав нові зміни після документа), "current" (актуально), "no-commits" (репо ще без жодного коміту). Для документів, записаних через write_doc, рахує ТОЧНУ кількість комітів з моменту запису (trackingMethod: "commit"); для решти - грубший запасний варіант за mtime файлу (trackingMethod: "mtime"). НЕ генерує/переписує документацію сам - лише каже, куди дивитись, щоб AI-асистент (чи людина) писав/оновлював цілеспрямовано, а не перечитував усе підряд щосесії. Документація розкидана між кількома незалежними парами корінь+Architecture-тека (напр. репо, винесене з ~/Projects, з документом прямо поруч на новому місці)? Передай points замість projectsRoot/docsRoot.

Для явних пар (репо з вихідним кодом, репо, що з нього тегує релізи) рахує, скільки комітів з'явилось у джерелі відколи реліз востаннє тегувався, і наскільки давно найстарший із них. Зв'язок джерело->реліз не вгадується автоматично зі структури тек - передавай пари явно (напр. {source:"NyxilumLang", release:"NyxilumNode"}).

Записує ~/Projects/Architecture/.txt і поруч фіксує commit-хеш репозиторія на момент запису. Після цього check_docs може рахувати РЕАЛЬНУ кількість комітів з моменту запису (git rev-list --count) замість грубого порівняння за mtime файлу. Текст документації інструмент не генерує - лише зберігає вже готовий текст (розуміння коду для документування лишається завданням AI/людини).