Product Roadmap

Продуктовый роадмап

Преврати GitHub-репо, которое ты сопровождаешь, — или мультирепо-продукт — в роадмап, из которого можно действовать. Ценность (обещание solo-разработчику): овладеть контекстом, рассыпанным по кодовой базе и бэклогу issues/PR, и дать графу поднять направления, под которыми проект действительно находится, — а не плоский список тикетов.

Ты отыгрываешь мейнтейнера. Конвейер:

рамка + бутстрап графа  →  моделирование текущего продукта (vartamana-почва)  →
сбор milestones + issues + PR  →  взвешивание по автору  →  запись в граф (шабда-интейк)  →
сборка (превращения: фигура-на-почве)  →  рендер (граф + markdown + HTML)  →  проверка

Скилл композирует три других: iskronify (понимание кодовой базы, граф/контур), intake (источник-независимая дисциплина шабда-интейка — хребет Шага 5) и assembly (различение превращений — сердце Шага 6). Сам он добавляет GitHub-адаптер (Шаги 3–4) и рендер роадмапа (Шаг 7). references/self-checks.md — полный проверочный гейт: Шаг 8 его прогоняет; без него не публикуй.

Обязательства — держи их через все шаги

• Фигура на почве. Issues/PR — это дельта: что люди хотят изменить; сами по себе они читаются как триаж тикетов. Сначала смоделируй существующий продукт — проверенной vartamana-почвой, зримо отделённой от kalpita/shabda-бэклога. Тогда каждое направление преобразует нечто реальное.
• Рычаг графа, не только его текст. Акторы — роли с реальными рёбрами; фигура-на-почве — граф-легальная связь; ключевые потоки — эстафета ahara/utpatti; структурные риски — из собственных натяжений графа. Роадмап, который мог быть плоским markdown-списком, графом не воспользовался — а всякий рычаг, заявленный прозой, должны нести рёбра (проверка — режим claim-аудита скилла integrity).
• Один продукт, даже через много репо. ОДИН фокус-контур; каждый репо — top-level-подсистема; кросс-репо-поток — заголовок. Никогда N сшитых роадмапов. Подтверди с мейнтейнером, какие репо в продукте, до моделирования.
• Читай-и-освежай, никогда не пересевай (контракт повторного прогона). В существующий граф ориентируются и освежают его на месте — locate-before-write на каждой записи: обнови существующее, добавь только подлинно новое, закрой отгруженное. Отсутствующий граф предлагается, не создаётся молча. Выход — снимок настоящего, не межпрогонный журнал.
• Честно прежде эффектно. Пустой или тощий бэклог констатируется, не надувается; срезы объявляются; превосходные степени — только над множествами, которые ты реально вычислил; каждый процитированный примитив проверен. Полный список стражей — references/self-checks.md.
• Дисциплина ссылок. #N зарезервирован за реальными номерами GitHub issue/PR. Мультирепо: каждая ссылка репо-квалифицирована полным ключом (backend#1) — без самодельных сокращений, группировок и диапазонов, без голых #N. Внутренние seq графа — с не-репо-префиксом (ISKRON#1120). Направления — D1/D2 или по имени.

Предпосылки

• gh CLI аутентифицирован (gh auth status); целевые репо доступны.
• Локальный чекаут каждого репо в объёме (git clone --depth 1; приватные: gh repo clone). Шаг 2 читает реальную структуру кода — моделирование по одним gh-метаданным недослуживает продукту.
• Тулы iskron_*; граф — по контракту повторного прогона выше.
• Тяжёлые шаги (модель продукта, сбор, записи в граф, сборка, рендер) гоняй сабагентами; результаты между шагами передавай файлами на диске, возвращай короткие подтверждения + пути — большие возвраты роняют соединение. Проверяй шаг сабагента по произведённому артефакту (файлы, узлы графа), не по его отчёту; и никогда не пускай двух пишущих в граф сабагентов над одним графом параллельно — одноимённые создания сталкиваются или дедупятся поперёк дорожек.

Шаг 1 — Рамка и бутстрап

• Определи цель — один owner/repo или набор (org или названный мейнтейнером список) — и границу продукта одной строкой. Несколько репо: подтверди, что это один продукт, и что в объёме.
• Сначала найди граф + фокус-контур (iskron_realm list; iskron_orient / iskron_semantic_search). Существует → ориентируйся и веди прогон как инкрементальное освежение. Отсутствует → предложи создание, создавай только по отмашке мейнтейнера.
• Ровно один фокус-контур, названный по продукту, contains от корня — один контур даже через много репо, никогда по контуру на репо.
• Чтение в духе iskronify настраивает граф/контур, но никогда не пиши AGENTS.md в репо, владение которым только отыгрываешь.

Шаг 2 — Смоделируй текущий продукт (vartamana-почва)

Пропустишь — и весь граф будет shabda: роадмап прочтётся как триаж бэклога, висящего в вакууме.

Читай то, что ЕСТЬ: README + доки (собственная заявка продукта); CHANGELOG + релизы (gh release list — что реально отгружено, текущая версия); структура кодовой базы (top-level директории/пакеты — реальные границы подсистем, точки входа, таблицы роутов); поверхность конфигурации (флаги, env); поверхность API (endpoint'ы, CLI-команды).

Засей почву в модусе наблюдения (Pt/Va/Up) — засвидетельствовано, действует, принято — строго отдельно от бэклога:

• Вкладывай подсистемы под фокус-контур (contains); способности/сущности живут в своей подсистеме. Мультирепо: репозитории И ЕСТЬ top-level-подсистемы (attrs.repo на каждой); внутри репо может делиться дальше.
• Правила заземления — каждый узел почвы: цитируй реальный примитив в attrs.source_ref (путь модуля, конфиг-флаг, endpoint, релиз-тег; репо-квалифицированно для мультирепо). Цитируй точный примитив — названный символ существует по этому пути; цитируй, где поведение реализовано, не где читается; предпочитай исполняемые примитивы прозе доков; версии читай из манифеста, никогда из дока. vartamana-заявка без цитируемого примитива — догадка: понизь или выброси. Не выводи способность из feature-request'а (это бэклог, не почва).
• Объём: подсистемы, главные доменные сущности, горстка ключевых потоков — карта, которую мейнтейнер узнаёт как «да, это мой продукт», не полный реверс-инжиниринг.
• Смоделируй акторов — сначала роль-тест (скилл writing): ролью становится только адресуемый делатель. Два слоя, из двух разных источников, никогда не схлопнутых:
  • Операторы рантайма — кто действует на живую систему / кого она обслуживает. Внешний потребитель → agantuka 客; внутренний оператор (админ, модератор, онбординг-стафф) → adhikarin 能 — активный делатель, который отвечает и действует, никогда не пассивно-«обслуживаемая» сторона. Парк воркеров / CI / cron — не роль: это ⚙️ феномен (upadhi); повысить его, чтобы заглушить no-actor-натяжение, — ровно тот антипаттерн, о котором натяжение предупреждает. Моделируется из почвы (роли, которым служит код): эти люди почти никогда не пишут issues.
  • Драйверы разработки — кто авторствует бэклог. Мейнтейнер → svatantra 主 (делегированный dev-scope → adhikarin); залётный контрибьютор → agantuka. Только этот слой виден сбору. Чем уже круг контрибьюторов (solo-проект = один 主), тем сильнее реальный акторный сигнал прячется в слое рантайма. Карта с нулём рёбер — театр: прошей её к деяниям, которые она двигает, или выброси; каждая роль несёт manifested_as.
• Прошей ключевые потоки эстафетой: каждая крия ключевого потока потребляет (ahara) феномены, которые читает-и-съедает, и производит (utpatti) те, что пишет, в последовательности next — хребет продукта как реальная эстафета (трассируется в Шаге 7) и причина, по которой структурные риски становятся вычислимыми. Мультирепо: кросс-репо-хребет — заголовок: крия в репо A производит шарнирный феномен (общая таблица БД, API-контракт, публикуемый артефакт), который потребляет крия в репо B; шарнирные феномены — граф-доказательство единого продукта.

Шаг 3 — Собери milestones + issues + PR

gh, JSON. Три источника — обязательный план мейнтейнера живёт в milestones / Projects-доске и есть сильнейший одиночный сигнал.

• Мультирепо: собирай каждый репо в объёме, помечай элемент его репо, координированную работу поперёк репо веди одной кросс-репо-темой.
• Сначала milestones: gh api repos/<owner>/<repo>/milestones?state=open, затем issues каждого не-«Backlog»-майлстоуна. Читай прозу описания самого майлстоуна — мейнтейнеры называют там цели, у которых нет issue. Проверь и Projects-доски, и закреплённые «roadmap»-issues.
• Issues: gh issue list --state open --limit <N> --json number,title,body,author,authorAssociation,labels,reactionGroups,comments,milestone,createdAt,updatedAt
• PR (открытые + недавно смерженные): gh pr list --state all --limit <N> --json number,title,body,author,authorAssociation,labels,state,milestone,additions,deletions,createdAt,mergedAt
• Отбор = ОБЪЕДИНЕНИЕ, срез объявлен, никогда молча: (a) каждый issue с майлстоуном, (b) каждый с меткой accepted/approved/roadmap, (c) топ-N по реакциям / комментариям, (d) недавно активные N, (e) контрибьюторские PR. Одни реакции роняют уже решённую малореакционную работу — ровно то, что на роадмапе и должно быть. Не оконь PR до новейших N: долго открытый мейнтейнерский PR — высокий сигнал. Залогируй срез и что исключено.
• Пустой/тощий бэклог честен, не провал: элементы НЕ выдумываются. Почва плюс траектория смерженных PR (gh pr list --state merged — что недавно строилось, в каком направлении) несут роадмап; так и скажи в рендере.
• Фиксируй по элементу: номер, заголовок, обрезанное тело, проверенный логин автора + authorAssociation (из API, никогда не выведенный), метки, майлстоун, вовлечённость, связанные issues, состояние.

Шаг 4 — Взвесь по роли автора

Повышай за вовлечённость и метки accepted/roadmap; понижай дубликаты, wontfix, ботов, чистые dependency-бампы.

• Членство в майлстоуне перевешивает реакции — issue следующего релиза есть обязательная работа независимо от счёта реакций.
• Авторство проверяй из API, никогда не выводи — приписать общинный вклад мейнтейнеру значит испортить само взвешивание, ради которого шаг существует.

Шаг 5 — Запиши бэклог (шабда-интейк + роадмап-надстройки)

Прогони скилл intake над собранным — Шаги 3–4 суть его GitHub-адаптер (они дают каждому элементу содержание / форму / провенанс / авторитет). Хребет у intake — не пересказывай: форма → тип узла; эпистемика по виду (kalpita для непроверенной просьбы — собственная обязательная воля мейнтейнера не kalpita-на-проверку); source_kind=shabda; семантический дедуп, locate-before-write; якорь arose_from к источнику; сверка и градация модуса; срез селективности (из Шага 3).

Одно сознательное расхождение с таблицей intake: feature-request ложится здесь феноменом (желаемая способность, sinn/bildung) или семенной крией (anagata/chanda) — не intake-овским превращением. Направления различаются позже сборкой; Шаг 5 сеет желаемую способность, не превращение.

GitHub-PR-формы, которых таблица intake не называет:

Роадмап-надстройки, которых intake не несёт:

• Якори каждый элемент к его подсистеме (context / vimarsha_of к контуру подсистемы из Шага 2 или к способности, которую он расширяет) — бэклог кластеризуется по подсистемам. Элемент без дома — сигнал: недомоделированная почва (вернись в Шаг 2) или подлинно новая почва — скажи, что именно. Кросс-репо-тема якорится к фокус-контуру и линкует каждую задетую подсистему.
• Дедуплицируй против ПОЧВЫ, не только бэклога: просьба, совпадающая с отгруженной способностью, — дельта: формулируй «улучшить X», никогда «добавить X»; если базовая форма уже отгружена — переформулируй в реальный оставшийся зазор. Назвать уже отгруженное как to-build — подорвать мастерство продукта. Неси GitHub-реф (номер, автор, вес) в attrs для трассируемости рендера.
• Ставь модус момента честно: закоммичено майлстоуном → adhimoksha; спекулятивная просьба → chanda; проектируемая работа → anagata; почва остаётся vartamana/pramanita. Моделируй поле, как оно стоит сейчас; никогда не пере-переходи заранее.
• Дай каждой бэклог-крие её ведущую роль как actor — dev-драйверскую роль проверенного автора, никогда рантайм-актора. Именно это делает «кто владеет направлением» ребром графа, а не прозаическим ярлыком.

Шаг 6 — Сборка (различи направления)

Прогони скилл assembly над засеянным графом: ориентация поля → триаж свободных вимарш → различение превращений → имя + телос → anga драйверов → порядок anantara. Играя владельца, принимай имена/телосы inline, но держи дисциплину: имя читается человеком-владельцем; телос — качество назначения; никогда превращение на одну вимаршу; риски остаются рисками.

• Освежающие прогоны сверяют, не переразличают с нуля: обнови телос / anga / порядок направлений, которые держатся; направление добавляй только для подлинно новой темы; закрой (visarjana) те, чья работа отгружена. Никогда — направление-близнец.
• Фигура-на-почве как реальная стрелка: ведущая крия направления достигает способности почвы через upadhi/context — никогда буквальным ahara от превращения (граф запрещает). Направление, чьи ведущие крии не касаются никакой способности почвы, плавает: либо подлинно новая почва (скажи явно), либо знак недомоделированного Шага 2 (иди досей способность).
• Подними структурные риски из собственных натяжений графа (iskron_orient(lens="tensions")): способность без производящего потока, relay-gap эстафеты, деяние без роли — самодиагноз графа, отличный от рисков из бэклога; плоский список тикетов структурно не может их произвести. Мультирепо: кросс-репо dead-recipe или relay-gap — находка высшей ценности. Чистые артефакты моделирования чини на месте, а не рапортуй.
• Атрибутируй каждое направление по двум осям: его драйвер (ведёт мейнтейнер и закоммичено / ведёт контрибьютор и ждёт ревью / просит сообщество и без владельца — из ролей сбора) и его рантайм-цель (кому служит изменённая система: внешний потребитель 客 или внутренний оператор 能 — из почвы). Не схлопывай вторую в первую — жди операторских направлений (админка, онбординг стаффа) рядом с потребительскими; на solo-продукте ось драйвера плоская, и направления реально различаются рантайм-целью. Владение — факт графа: anga-крии направления несут actor → роль-драйвера, иначе ярлык понижается до «выведено».
• Когерентная высокосигнальная тема сообщества заслуживает направления даже без закоммиченной работы — топ-реакционные issues есть роадмап-сигнал; сознательная отсрочка помечается «отложено, но реально», никогда не роняется молча.
• Майлстоуны целиком: закоммиченный ближний майлстоун — собственное направление, перечисляющее каждый открытый issue майлстоуна; топ-N ранжируй как гейтящие, но назови общее число и что остальное остаётся; никогда телос, заявляющий завершение по частичному списку. Перечисли каждый ОТКРЫТЫЙ майлстоун; catch-all «Backlog» — целиком или явно «сэмплировано». Закоммиченный мейнтейнерский issue из майлстоуна никогда не уступает место менее сигнальному по той же теме.
• Каждому ребру anantara — свидетельство: issue/PR или заявление мейнтейнера, его устанавливающее; собственный архитектурный вывод помечай эвристикой (kalpita) и хеджируй в рендере. Не пере-называй «blocked»: направление со своей работой в полёте — sequenced-after, не заблокировано.
• Именуй направления на языке аудитории репо — они станут заголовками роадмапа, которые читает владелец.

Шаг 7 — Рендер (веди собранной картиной)

Роадмап ведёт собранной кросс-репо-картиной и тем, что нашёл граф, — дифференцирующая ценность на первом экране, не закопана. Три артефакта:

1. Граф — iskron_orient(lens="bianhua"); HTML рендерит его визуальным граф-видом (хребет + направления в порядке зависимостей + флаги структурных рисков).
2. roadmap.md, в этом порядке:
   • «Продукт, собранный» — подсистемы (по одной на репо) + кросс-репо-хребет, одно-два предложения; реальная картина из ВСЕХ источников.
   • «Что нашёл граф» — структурные риски из натяжений, каждый с помеченным швом. Веди ими.
   • «Следующие 3 хода» — список действий на 3–5 строк.
   • «Что этот продукт сегодня» — почва, каждая строка процитирована к примитиву; доказывает мастерство продукта.
   • «Как это работает сегодня» — одна ключевая эстафета, протрассированная насквозь (lens="trace"): хребет одним проходом.
   • Направления в порядке anantara; по направлению: расширяемая способность, телос, ведущие элементы (дословные заголовки + рефы + вес автора), роль-драйвер и рантайм-цель (客/能), anga (ведущий вопрос), открытые риски, что разблокирует.
   • «Чтение поля» — роли-драйверы (+ рантайм-цели), структурные риски, карта фигура-на-почве. Написано для мейнтейнера, не методолога: глоссируй каждый термин графа по-простому при первом употреблении.
   • «Аудит сигнала» — топ по реакциям и комментариям среди ОТКРЫТЫХ issues (числа + основание запроса), каждый помечен included / deferred / out-of-scope, с названным порогом вовлечённости. Тощий бэклог → таблица траектории (счётчики смерженных PR по репо + темы). Точные числа, никогда оценки.
3. roadmap.html — страницу НЕ пиши руками. Скопируй references/roadmap-template.html и замени ТОЛЬКО его data-объект ROADMAP (схема задокументирована в начале <script> шаблона); шаблон рендерит дизайн, реф-ссылки, чипы авторов, статус-бейджи, фильтры, темы. Весь текст авто-экранируется — вставляй дословные заголовки. Мультирепо: заполни URL-карту repos, ставь repo:'<key>' на каждый реф драйвера/сигнала и directions[].repos; свободные рефы пиши <key>#N; внутренние seq — ISKRON#…. Один репо: опусти repos (шаблон линкует через repoUrl).

Рендерь на языке аудитории репо. Цитируемые заголовки — дословно. Точность состояний: различай review / rebase / merge по draft-состоянию + mergeability + CI + ревью; докладывай разбор готовности по каждому PR и рекомендуй действие, снимающее связывающее ограничение. mergeable=null → пере-опроси один раз, затем «mergeability pending», никогда «clean»; mergeable=true ≠ готов; mergeable-PR — не «конфликтующий». Никогда не сваливай PR разных состояний в одну строку; ОТКРЫТЫЙ PR никогда не «отгружен». Никаких невычисленных превосходных степеней — скоуп-заявка или сырое число, никогда глобальное «#1» по срезанному подмножеству. Покрытие — то, что делает путь данных/кода, не то, что перечисляет конфиг или UI.

Шаг 8 — Чекпойнт и проверка (падай громко)

Ненаписанный роадмап не стоит ничего; прогон, умерший молча и не отдавший ничего, — худший исход.

• Чекпойнть по ходу: пиши сырой выход каждой стадии (milestones.json, issues.json, prs.json, собранный скелет) в --out-директорию по мере сбора — поздний провал оставит восстановимое состояние.
• Проверь запись: перечитай артефакты; убедись — непустые, обязательные секции на месте; нет → скажи громко и почини; никогда не рапортуй успех без проверенного артефакта.
• Прогони references/self-checks.md — каждую проверку. Каждый PASS зарабатывается над полным названным множеством; расхождения исправь, перерендери, перепроверь.
• Возвраты держи маленькими: файлы на диске + короткое подтверждение с путями.

Быстрый режим — тизер

Триггеры: --quick, «quick roadmap», «дай суть», первое знакомство. Не гони полный конвейер (десятки минут); выдай одноэкранный тизер за пару минут — «он действительно понимает мой продукт» — и предложи полный прогон. Та же механика, вширь и мелко:

1. Рамка (Шаг 1) — граница продукта; репо в объёме.
2. Лёгкая почва — подсистемы и кросс-репо-хребет (достаточно для граф-вида) + горстка ключевых способностей и сущностей; реальные примитивы процитированы, объём — хребет; засей графа ровно на хребет + одно заголовочное натяжение.
3. Взгляд на траекторию — темы смерженных PR / закоммиченный майлстоун; без полного сбора и глубины взвешивания.
4. Топ-3 направления + один заголовочный структурный риск; без полного леса.
5. Рендер только лида — граф-вид + резюме на 3–5 строк (что это за продукт · что нашёл граф · следующий ход) + явный указатель: «это тизер — прогони полный роадмап для полной картины».

Дисциплина держится: честное разделение shabda/vartamana, без фабрикаций, каждый процитированный примитив реален, рефы репо-квалифицированы, честность пустого бэклога. Мельче — да, небрежнее — нет.

Контракт выхода

• Проверенный vartamana-подграф почвы (подсистемы + способности + ключевые потоки), процитированный к реальным примитивам, отдельный от shabda-бэклога.
• Граф засеян трассируемыми феноменами/рисками — шабда-честно, дедуплицировано, со срезом.
• Карта превращений = роадмап, секвенированная, каждое направление заякорено в почву.
• Рычаг графа видим: роли-акторы, связи фигура-на-почве, структурные риски из натяжений — собраны в «Чтении поля».
• roadmap.md + roadmap.html записаны локально; список «следующие 3 хода».
• Все self-checks пройдены.