feature-tracker-mcp

Проект-агностический трекер функций и решений, созданный для случая, когда один человек одновременно руководит несколькими ИИ-сессиями кодирования и стал узким местом.

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

Это и есть механизм.

Содержание

• Роли

• Что существует сегодня

• Форма

• Глаголы

• Режимы

• Стержень: одна база данных на проект

• Категории

• Шлюзы: очередь одобрений

• Счётчики и сходимость

• Условия остановки

• Контрольные точки, паузы и сводки

• Почему это не в git

• Порядок сборки

Роли

Смысл разделения в том, что вторая строка сейчас — работа человека, и почти ни одна её часть не должна быть таковой.

Форма

flowchart TD
    Ideate["/ideate — dialog"] -->|features as they are invented| DB[("project database")]
    Session["coding session (Claude)"] -->|every substantive turn| Capture{"implies a feature,<br/>guardrail, schema change<br/>or risk?"}
    Capture -->|yes, and not a duplicate| DB
    Capture -->|no| Session
    DB --> PM["ChatGPT as manager"]
    PM -->|next task, in priority order| Session
    PM -->|mundane decisions| PM
    PM -->|architectural · install · spend| Gate[["gate queue"]]
    Gate -->|approve / alter / reject| You([You])
    You -->|proceed| Session
    DB --> Table["/tracker-table · /standup"]
    Table --> You

Работу выполняют два свойства: база данных — это состояние, поэтому ничто не зависит от памяти модели; и шлюзы блокируют, так что «да, продолжай» — это механизм, а не сообщение, которое нужно было поймать в моменте.

Что существует сегодня

Честное разделение, потому что остальная часть этого документа описывает систему, которая построена лишь частично.

Работает сейчас — 8 MCP-инструментов, проверенных от начала до конца на реальной базе данных:

Описано, но не построено: все слэш-команды в следующем разделе, непрерывный захват, цикл выполнения и генератор, который рендерит markdown-трекер обратно из базы данных.

Проверено на реальном проекте. 75 функций импортированы из существующего markdown-трекера на 387 строк с сохранением каждого id — DIP-16, GLG-1, UA-11 и остальные по-прежнему резолвятся, потому что они цитируются в сообщениях коммитов и именах рабочих деревьев, и их переназначение осиротило бы эту историю. Счётчики категорий были продвинуты за самый высокий импортированный id, так что ничего уже используемого не может быть выдано снова.

Глаголы

Каждый из них — навык, поэтому каждый также является слэш-командой. Ни один из них ещё не построен — это предполагаемая поверхность над указанными выше инструментами.

/standup, /tracker-table и /gates — только чтение и никогда не потребляют ход работы.

Режимы

Идеация. Диалог, побочный продукт которого — заполненный бэклог. По мере изобретения функций они немедленно предлагаются в базу данных, каждая представляется вам для согласия или изменения — ничего не попадает молча. Так заполняется очередь.

Исполнение. Функции категории доводятся до завершения одна за другой в порядке приоритета. ChatGPT выбирает следующий пункт, инструктирует сессию кодирования, просматривает результат и либо принимает его, либо отправляет на доработку.

Непрерывный захват. Рутинная часть и причина, по которой список остаётся правдивым. Каждый содержательный ход — в любой сессии — анализируется на предмет того, что он подразумевал: новая таблица, ограничение, CHECK-ограничение, риск, требующий смягчения, подфункция, которую никто не назвал. Каждый становится предложенной строкой. Альтернатива — то, что происходит сегодня: это упоминается один раз, уходит в прокрутку и дорого обнаруживается позже.

Захват выполняется на ходах, которые изменили файлы или пришли к выводу. Большинство ходов ничего не подразумевают, и запуск его на всех — это способ получить бэклог, который никто не читает.

Стержень: одна база данных на проект

Каждый проект получает собственную базу данных Postgres, создаваемую при первом использовании и именуемую по git-remote проекта (так что каждое рабочее дерево и каждый клон одного и того же проекта согласуются с одним и тем же трекером).

kind — одно из feature, guardrail, schema, risk, mitigation. status проходит proposed → agreed → in_progress → done или dropped.

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

Каждое событие записывает git-коммит, ветку и дерево. Функция, предложенная относительно коммита, который с тех пор был переписан, — это другое утверждение, чем предложенная относительно HEAD, и без отметки никто позже не сможет отличить одно от другого.

Категории

Категории заменяют неформальное понятие «направления» и генерируются по мере логирования функций, а не настраиваются заранее. Предложение функции в новой категории создаёт её с собственным префиксом id и счётчиком — так что DIP-17 и GLG-1 сосуществуют, не сталкиваясь и не требуя централизованного администрирования.

Шлюзы: очередь одобрений

Шлюз — это решение, которое рабочие сессии не должны принимать в одиночку.

Поднятие шлюза блокирует сессию, которая его подняла. Шлюзы собираются в одном месте, вы одобряете, изменяете или отклоняете, и сессия возобновляется. Именно это превращает «это будет стоить $40, вы не против?» из сообщения, за которым нужно было следить, в элемент очереди, который ждёт.

Счётчики и сходимость

Прогресс сообщается как два движения, никогда не как соотношение:

3/14  ->  5/16     +2 agreed, +2 surfaced

Числитель — это консенсус и мера сходимости. Рост знаменателя — это здорово — новые элементы означают, что было найдено реальное разногласие, которое существовало всё это время, но не высказывалось.

Процент инвертирует это. 12/16 -> 12/20 читается как 75% -> 60%, падение, когда ничего не регрессировало и были названы две реальные проблемы. Одно соотношение наказывает именно то поведение, для которого система и существует, поэтому оно никогда не показывается.

Условия остановки

Застой оценивается только по числителю. Всплывающие элементы, пока ничего не согласовано, — это кружение, и сообщать об этом как о прогрессе — самый лёгкий способ потерять полдня.

Контрольные точки, паузы и сводки

Каждые два хода цикл останавливается и сообщает:

NEEDS YOU (1)
  · Is the target "one dollar per Track" or "one opportunity live"?
    Not a fact — it is what you are optimising.

HANDLED (6 of 7 tracks)      +2 agreed, +2 surfaced
  filter-decide   uncommitted migration 020 — no collision with other tracks
  layer-lift      6 behind main, clean rebase available
  ...

Вы можете сказать пауза в любой момент и получить сводку немедленно, не дожидаясь контрольной точки. Ничто не работает без присмотра дольше, чем вы позволяете — автономия начинается с двух ходов и увеличивается только после того, как заслужит это.

Почему это не в git

Раньше трекер был markdown-файлом. За одну недавнюю неделю он занял 115 коммитов из параллельных рабочих деревьев, и в истории есть вручную разрешённые коллизии нумерации. Один файл под контролем версий уже является точкой конкуренции при человеческой скорости записи; добавление автоматических записей с каждого хода из нескольких сессий сделало бы его непригодным.

Поэтому база данных канонична, а markdown становится генерируемым выводом, регенерируемым по требованию и исключённым из контроля версий.

Последствие, которое нужно принять осознанно: история git была журналом аудита. feature_event заменяет её — только добавление, с отметкой автора и коммита — и эта замена является требованием, а не прихотью. В противном случае вы меняете конфликты слияния на амнезию.

Любая инструкция уровня проекта, называющая markdown-файл каноническим, должна быть переписана в том же изменении. Сессии следуют этим инструкциям; оставьте одну указывающей на старый файл — и они продолжат писать в то, что никто не читает.

Что сломает это

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

Чтение не того дерева. Worktree — это отдельный checkout. Направьте сессию не на тот worktree, и она сообщит, что ваши файлы отсутствуют, а изменения не внесены — уверенно, и так, что это читается как вывод о коде, а не как ошибка конфигурации. Каждая операция записывает дерево, которое она читала, поэтому несоответствие видно до того, как кто-то начнёт действовать на его основе.

Менеджер, который повествует, а не вычисляет. Счётчики вычисляются из базы данных и не могут красноречиво говорить о чём-то неверном. Сводки, написанные моделью, могут. Когда они расходятся, таблица побеждает.

Автономия, обгоняющая внимание. Накопленные ошибки дороже всего обходятся, когда никто не читает. Для этого существуют гейты и контрольные точки, и интервал по умолчанию намеренно короткий.

Порядок сборки

1. category, feature, feature_event, gate; создание базы данных для каждого проекта; атомарное выделение id

2. MCP-инструменты: propose, list, update, table, history, gate raise/list/decide

3. Непрерывный захват с критерием и дедупликацией, плюс очередь ревью «согласиться или изменить»

4. /standup по всем трекам, включая незакоммиченную работу — одни только коммиты не показывают, где работа на самом деле

5. Гейты, блокирующие сессии

6. /ideate

7. Цикл исполнения, доводящий категорию до завершения в порядке приоритета