Project Control · /workflow_global_plan

Система план — факт

Слой планирования и контроля над дев-проектами. Сначала строит оценённый и расписанный по календарю план, выгружает его в собственный реестр задач (timechecker) и заводит GitHub-репозиторий. Дальше непрерывно сводит план (обещанные часы и даты) с фактом (что реально случилось в разработке) и рапортует управленцу дельту.

ПЛАН · часы → даты ФАКТ · событийные статусы timechecker · GitHub · cron 3×/день

↓ листай — план встречается с фактом

00 / Карта

Две стороны: план и факт

Слева — план: что обещано (часы, даты, иерархия). Справа — факт: что произошло (статусы из событий разработки). Между ними — непрерывное сведение и рапорт.

plan-vs-fact канон 02-plan.json · событийные статусы

ПЛАН — что обещано

ФАКТ — что случилось

ИерархияGlobal → Эпохи → Спринты → Задачи

Оценка часовИИ: realistic + pessimistic → среднее → estimate_h; буфер — задача «Прочие работы» 30 % спринта

Расписание8 ч/день, пн–пт минус праздники РФ; спринты встык → плановые даты, global_end_date

Канонplan/02-plan.json — единственный источник правды; реестр задач и md-таблицы производны

In Progressразработчик пишет «беру TASK-ID в работу» (чат, не коммиты)

Doneкоординатор сам мержит ветку в master через merge-гейт после зелёной проверки

Реальные датыкогда задачи реально закрылись → done_h, фактический прогресс

Источник фактаGitHub (ветки/merge) + статусы канона; БД timechecker — статусы и переходы

ПЛАН (total_h, плановые даты) → сведение → ФАКТ (done_h, статусы) ⇒ рапорт: % готовности · просрочка · прогнозная дата · дельта

План живёт в каноне 02-plan.json; факт приходит событиями (чат «беру в работу» и merge координатора). Синк постоянно пересчитывает одно относительно другого.

Простыми словами. Это надстройка для управленца, а не для разработчика. Она не пишет код — она планирует проект и следит за ходом. Сначала система раскладывает проект на эпохи, спринты и задачи, оценивает каждую задачу в часах и раскидывает их по календарю — получается план: сколько часов и к какой дате. Потом по ходу работы она ловит факт и показывает, где реальность расходится с обещанием.

Главный приём — один источник правды: машинно-читаемый файл plan/02-plan.json (его зовут «канон»). Всё остальное — таблицы для человека и задачи в реестре timechecker — лишь производно от него, поэтому копии не разъезжаются. БД timechecker — источник правды по статусам, GitHub — источник факта.

Сторона плана

Часы берутся не «из воздуха»: ИИ даёт по задаче реалистичную и пессимистичную оценку, берёт их среднее — без скрытых накруток; непредвиденное покрывает задача «Прочие работы» (30 % часов спринта), которую система сама добавляет в каждый спринт и сразу закрывает. Базис — «разработчик + Claude Code» (AI-ассистированный темп), а если дорабатываем существующий код — сперва читаем исходники, потом оцениваем. Календарь считается последовательно и пессимистично: рабочий день 8 ч, выходные и праздники РФ пропускаются, спринты укладываются встык. Часы поднимаются роллапом: задача → sprint_h → epoch_h → global_h.

Сторона факта

Статусы событийные, а не «угаданные из коммитов». Разработчик пишет «беру задачу в работу» — она становится In Progress. Когда готово, он просит merge; координатор (ИИ) в изолированном клоне прогоняет проверочную лестницу (конфликты, тесты, сборка, линт, смоук) и, если всё зелёное, сам мержит ветку в master с номером задачи — это и есть авторитетный сигнал Done. За то, что merge ничего не ломает, отвечает координатор; на master стоит branch-protection, чтобы мимо гейта никто не прошёл.

progress% = done_h / total_h — насколько проект готов по часам.
Просрочка — спринт, у которого дата прошла, а задачи не все в Done.
Прогнозная дата (projected_finish) — пересчёт от «сегодня»; рапорт показывает её дельту к плановой.
Рапорт уходит файлом plan/reports/<дата>.md.

01 / План · структура

Иерархия плана и публикация в реестр задач

План — это дерево из четырёх уровней; всё дерево живёт в каноне. В реестр задач (timechecker) публикуются проект и задачи с readable-ID; даты спринтов остаются в каноне.

hierarchy-mapping 4 уровня в каноне · задачи → timechecker

На фазе publish канон публикуется в собственный реестр (timechecker): проект регистрируется (register-project), задачи уезжают пачкой (task import) и получают readable-ID {PREFIX}-N. Эпохи и спринты с датами живут в каноне; роллапы считаются из канона.

02 / План · часы

Как задача превращается в часы

Оценка детерминирована формулой. Жёлтые пакеты — часы в расчёте: от двух оценок ИИ к цифре задачи и роллапам наверх; буфер живёт отдельной задачей спринта.

estimate-formula avg(realistic, pessimistic) + задача «Прочие работы» 30 %

База — среднее между реализмом и пессимизмом, округление до 0.25 ч — без скрытого буфера. Непредвиденное покрывает авто-задача «Прочие работы»: 30 % от часов обычных задач спринта, создаётся сразу закрытой — на неё списывают внеплановое. Базис часов — «разработчик + Claude Code» (а при доработке кода — после чтения исходников). Человеко-часы estimate_h — драйвер календаря; справочный ai_estimate_h ведётся отдельно.

03 / План · календарь

Часы превращаются в даты

Расписание — последовательное и пессимистичное: спринты идут встык, выходные и праздники РФ пропускаются. Параллельность не закладывается — это бонус.

calendar-pack 8 ч/день · sprint_days = ceil(h / 8)

Длина спринта — ceil(sprint_h / 8) рабочих дней; блоки укладываются встык от start_date, пропуская сб/вс и праздники РФ. Конец последнего спринта эпохи — её дата; конец последней эпохи — global_end_date. При replan даты ползут вперёд — это норма для пессимистичной модели.

04 / Контур

Фазы и петля контроля

Команда — оркестратор с перезапускаемыми фазами. После publish включается живая петля: sync (по расписанию), gate (по событию) и replan (при изменениях) крутятся вокруг канона.

phase-pipeline + control-loop init → … → publish → {sync · gate · replan}

Каждую фазу можно перезапустить с чекпоинта. sync пересчитывает прогресс/просрочку/даты и шлёт рапорт; gate по событию мержит и ставит Done; replan подхватывает новые задачи и перепаковывает оставшиеся спринты. Всё крутится вокруг канона.

05 / Факт · статусы

Событийная модель статусов

Статус задачи двигают явные события, а не угадывание по коммитам: сообщение разработчика и merge координатора.

status-machine Todo → In Progress → Done

СигналКтоКакЭффект

«беру TASK-ID в работу» разработчик сообщение в чате → In Progress

«готово к merge: TASK-ID» координатор зелёный гейт → merge в master → Done

коммиты в фиче-ветку разработчик статус НЕ двигают (только метрика гигиены) без изменений

До merge-гейта статусы выводились из опроса коммитов; теперь — событийные. Это снимает риск «дисциплины коммитов»: сигнал Done гарантирует координатор своим merge.

06 / Факт · гейт

Merge-гейт — проверочная лестница

Запрос на merge проходит лестницу проверок в изолированном клоне. Зелёный путь ведёт к merge и Done; любой красный — стоп и список ошибок разработчику.

merge-gate конфликты → тесты/сборка/линт/смоук → merge

За то, что merge не ломает master, отвечает координатор. На master — branch protection (мимо гейта не пройти). Если проверять нечего — гейт не молчит, а помечает «проверка ограничена». Реальная транзакция — скрипт gate-merge.mjs (есть сухой прогон --check); боевой merge — только после явного ОК человека.

07 / Сердце

Сведение план-факт → рапорт

Здесь система живёт: канон даёт план (часы, даты), статусы дают факт (что закрыто), а синк постоянно считает их разницу и рапортует.

reconciliation progress · просрочка · projected_finish · дельта

Рапорт показывает общий план, плановую и прогнозную дату с дельтой, текущий этап, % сделанного, отставание (schedule variance) и что просрочено. Доставка — файлом-артефактом (reports/); разбивка «кто не успевает» включится с распределением задач между людьми.

08 / Хранилища

Артефакты и источники правды

Один канон, всё остальное производно. Состояние проекта — в репозитории, реестр и секреты — вне его (чтобы фоновый cron ходил по REST).

state-files plan/ · ~/.wgp/ · timechecker · GitHub

plan/ ← в репозитории проекта ├─ config.json параметры · ветка разработчика · cron ├─ 01-spec.md структурированная спека ├─ 02-plan.json★ КАНОН единственный источник правды ├─ 02-plan.md витрина-таблицы (производн.) ├─ sync-state.json SHA по веткам · снимок прогресса └─ reports/<дата>.md рапорты синка (производн.) ~/.wgp/ ← вне репозиториев ├─ projects.json реестр всех проектов (cron --all) └─ secrets.json🔒 gitignore токен GitHub timecheckerстатусы БД реестра: задачи {PREFIX}-N, переходы, время GitHubфакт ветки + merge · branch protection на master

Канон 02-plan.json — источник правды; реестр и таблицы производны от него, поэтому копии не разъезжаются. Фоновый синк ходит в GitHub по REST/PAT из секрет-файла, в реестр — через CLI timechecker.

— / Легенда

Как читать схемы

Сторона

ПЛАН — что обещано

ФАКТ — что случилось

Статус задачи

Todo

In Progress

Done

Просрочено

Поток данных

пакет в движении

часы / структура плана

Хранилище

★ канон (источник правды)

зеркало / факт

🔒 секрет (gitignore)

← Все кейсы