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 сшитых роадмапов. Подтверди с мейнтейнером, какие репо в продукте, до моделирования.
• Читай-и-освежай, никогда не пересевай (контракт повторного прогона). В существующий граф ориентируются и освежают его на месте — прежде каждой записи найди, что уже стоит: обнови существующее, добавь только подлинно новое, закрой отгруженное. Отсутствующий граф предлагается, не создаётся молча. Выход — снимок настоящего, не межпрогонный журнал.
• Честно прежде эффектно. Пустой или тощий бэклог констатируется, не надувается; срезы объявляются; превосходные степени — только над множествами, которые ты реально вычислил; каждый процитированный примитив проверен. Полный список стражей — 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_*; граф — по контракту повторного прогона выше.
• Модель продукта, решения в графе и сборку ведёшь сам (дверь iskron, «Ремесло графа»); объёмное — субагентам, делом: шаги без графа (сбор issues и PR, чтение кода, рендер) и правка многих узлов по готовому решению — роли weaver на своём мосту-спутнике, итог сверяешь ты; дело прогона заводится до первого запуска (open_room одной строкой у записи фокус-контура, справка двери iskron leading.md), бриф каждого субагента начинается строкой запуска start <граф> <роль> <дело №N>, итог он говорит словом в деле; результаты между шагами передавай файлами на диске, возвращай короткие подтверждения + пути — большие возвраты роняют соединение. Проверяй шаг субагента по произведённому артефакту, не по его отчёту.

ステップ 1 — スコープとブートストラップ

• 目標を定めます — 1 つの owner/repo、または複数（org またはメインテナーが指定したリスト） — そして製品の境界を 1 行で示します。複数のリポジトリの場合は、それらが 1 つの製品であることと、スコープに含まれるものを確認します。
• まずグラフとフォーカス輪郭を探します（iskron_realm list；iskron_orient / iskron_semantic_search）。存在する場合は、その内容に沿ってインクリメンタルな更新として実行します。存在しない場合は作成を提案し、メインテナーの同意がある場合にのみ作成します。
• フォーカス輪郭はちょうど 1 つとし、製品名を付けます。ルートからの contains は、リポジトリがいくつあっても輪郭を 1 つだけにし、リポジトリごとに輪郭を作ることは決してありません。
• iskronify 風の読み取りはグラフ／輪郭の設定に使いますが、所有権を演じているだけのリポジトリに AGENTS.md を書き込んではいけません。

ステップ 2 — 現在の製品をモデル化する（vartamana の土台）

これを省くと、グラフ全体が shabda になり、ロードマップが宙に浮いたバックログのトリアージとして読まれてしまいます。

存在するものを読み取ります： README とドキュメント（製品自身による説明）；CHANGELOG とリリース（gh release list — 実際にリリースされた内容、現在のバージョン）；コードベースの構造（トップレベルのディレクトリ／パッケージ — 実際のサブシステム境界、エントリーポイント、ルートテーブル）；設定の範囲（フラグ、環境変数）；API の範囲（エンドポイント、CLI コマンド）。

土台をまきます：anumita · vartamana · upeksha — 読み取りによって導かれた、機能している、受け入れられているものです。バックログとは厳密に分けます。README、CHANGELOG、コードを読んで分かるのは内容であり、実行ではありません。読み取りから得た土台の認識論的確度は anumita を超えません。pratyakshita は実行で観測した場合（呼び出し、実行）のみ、pramanita は現実監査（writing、「決定 3：モード」）に基づく場合のみ付与します。

読み取ったもの	ノード	given_as	モード
サブシステム（crawler、indexer、auth、storage）	holon	—	（境界）
既存の能力（「全文検索」）	phenomenon	vollzug / sachverhalt	An/Va/Up
ドメインエンティティ（Bookmark、Library、User）	phenomenon	bildung / sinn	An/Va/Up
製品が現在実行する主要なフロー	kriya	—	An/Va/Up
リリースによって確認されたリリース済みの事実	phenomenon	sachverhalt	An/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 — Взвесь по роли автора

authorAssociation	вес	заметка
OWNER / MEMBER / COLLABORATOR	высокий	голос мейнтейнера
CONTRIBUTOR	высокий	есть смерженная работа — реален
FIRST_TIME_CONTRIBUTOR / FIRST_TIMER	средний	суди по содержанию + вовлечённости
NONE (issue)	средний	пользовательская нужда — держи, если содержательна
NONE (PR без связанного issue)	низкий	случайный; впускай только при реальной вовлечённости

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

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

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

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

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

GitHub-PR-формы, которых таблица intake не называет. PR — не крия: в граф идёт изменение, номер PR и SHA — в attrs или истории.

Элемент источника	Узел
смерженный контрибьюторский PR	произведённый им феномен или введённая им крия (повторяемый переход)
открытый контрибьюторский PR	феномен или крия, которые он вводит, в модусах замысла (anagata) — работа в полёте
маловесный случайный PR	пропустить — или низкоприоритетный феномен с пометкой

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

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

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

Прогони скилл assembly над засеянным графом: ориентация поля → триаж свободных вимарш → различение превращений → имя + телос → anga драйверов → порядок anantara. Имена и телосы направлений агент предлагает (chanda), принимает владелец (writing, «Имя и телос»): отыгрыш мейнтейнера акта принятия не даёт, adhimoksha — только по его слову. Имя, телос и запрет превращения на одну вимаршу — по assembly, шаг 5; риски остаются рисками.

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

Шаг 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 пройдены.