vvzvlad/gitmost
1
0
Fork 0
Code Issues 34 Pull Requests 9 Packages Projects Releases Activity

meta(tools): roadmap #407–#417 — порядок работ и состав breaking-релиза #416

New Issue
Open
opened 2026-07-07 21:03:28 +03:00 by agent_vscode · 0 comments
agent_vscode commented 2026-07-07 21:03:28 +03:00
Collaborator
Copy Link
Copy Source

Зачем

Десять ишью (#407–#415, #417) трогают одну и ту же поверхность агентских тулов и частично одни и те же файлы. Без зафиксированного порядка получим: двойную работу в node-ops (три ишью добавляют туда код), перекрёстные конфликты в tool-specs.ts/SERVER_INSTRUCTIONS, и несколько breaking-ломок внешних MCP-клиентов вместо одной. Это ишью — трекинг порядка; сами работы идут отдельными PR в develop по своим ишью.

Точки пересечения (почему порядок важен)

Файл/зона Кто трогает
packages/mcp/src/lib/node-ops.ts #414 (объединение форка), #409 (findInvalidNode), #413 (сплайс-хелперы)
tool-specs.ts + SERVER_INSTRUCTIONS + server-instructions.test.mjs #410, #411, #412, #413, #415
ai-chat-tools.service.ts + tool-tiers.ts #410, #411, #412, #413
Choke point результатов тулов (index.ts:118-125 + in-app execute-wrapper, зона метрик #402) #417
Внешние MCP-клиенты (breaking) #411 (−import_page_markdown), #412 (camelCase), #413 (дефолт getNode)
Метрики per-tool (#402/#403 лейблы) #412 (переименование рядов)

Порядок

Фаза 0 — наблюдаемость и независимые фиксы (можно параллельно, хоть сейчас)

  • #407 — персистить tool-error'ы в историю. Идёт первым по смыслу: даёт честную статистику ошибок, по которой меряется эффект всего остального (до/после для #408/#409/#413).
  • #408 — corrective-подсказки в createComment. Независим от всех; с #414 не пересекается (вынос hint-хелпера из json-edit — вне скоупа дедупа).
  • #417 — пассивный сигнал «new comments: N» в результатах tool-вызовов. Независим (живёт в choke point результатов, не в контестируемых tool-specs); текст сигнала пишется сразу в camelCase-именах (#412).

Фаза 1 — фундамент, non-breaking

  • #414 — дедупликация: node-ops → единая копия в prosemirror-markdown. Строго до #409 и #413: оба добавляют функции в node-ops — добавлять надо в единственную копию, а не в форк, который потом переезжает.
  • #409 — pre-validate JSON-нод + findInvalidNode (в уже единую копию node-ops).
  • #410 — insertFootnote/insertImage/replaceImage агенту + промпт исследователя. До #412: перенос inline-регистраций в SHARED_TOOL_SPECS означает, что camelCase-переименование приедет к ним автоматически.

Фаза 2 — breaking-окно: один релиз, одна миграция

Порядок внутри окна:

  • #411 — updatePageMarkdown (+MCP), import_page_markdown −MCP. Перед #412: таблица переименования в #412 уже учитывает это удаление.
  • #412 — camelCase всех имён MCP-тулов. Перед #413/#415: новые описания и SERVER_INSTRUCTIONS пишутся сразу в целевых именах, а не переписываются дважды.
  • #413 PR 1 — getNode: markdown по умолчанию (breaking-часть #413).
  • #413 PR 2 — markdown в patchNode/insertNode (аддитивно, но логично в том же окне: роутинг-инструкции пишутся один раз под финальную поверхность).
  • #415 — точные описания getPage/exportPageMarkdown. Последним: финальный wording-sweep по уже переименованной и расширенной поверхности (правит ту же строку SERVER_INSTRUCTIONS, что #411/#413).

Релизный артефакт фазы 2 — единая BREAKING-секция CHANGELOG: таблица имён (#412) + import_page_markdown → updatePageMarkdown (#411) + смена дефолта getNode (#413), с миграционной заметкой. Внешние конфиги (.mcp.json, permission-allowlists mcp__gitmost-*__*, сохранённые промпты/скиллы, дашборды метрик #402/#403) мигрируют один раз.

Definition of done

  • Все чекбоксы закрыты, каждое ишью — своим PR (или парой PR для #413).
  • Внешние клиенты ломались ровно один раз (одним релизом фазы 2).
  • После фазы 2 статистика #407 показывает снижение ошибок patchNode/insertNode (эффект #409+#413) и createComment (#408); петля «человек комментирует → агент реагирует» замыкается без ручного check_new_comments (#417).

Связано: #407 #408 #409 #410 #411 #412 #413 #414 #415 #417.

## Зачем Десять ишью (#407–#415, #417) трогают одну и ту же поверхность агентских тулов и частично одни и те же файлы. Без зафиксированного порядка получим: двойную работу в node-ops (три ишью добавляют туда код), перекрёстные конфликты в `tool-specs.ts`/`SERVER_INSTRUCTIONS`, и **несколько** breaking-ломок внешних MCP-клиентов вместо одной. Это ишью — трекинг порядка; сами работы идут отдельными PR в develop по своим ишью. ## Точки пересечения (почему порядок важен) | Файл/зона | Кто трогает | |---|---| | `packages/mcp/src/lib/node-ops.ts` | #414 (объединение форка), #409 (`findInvalidNode`), #413 (сплайс-хелперы) | | `tool-specs.ts` + `SERVER_INSTRUCTIONS` + `server-instructions.test.mjs` | #410, #411, #412, #413, #415 | | `ai-chat-tools.service.ts` + `tool-tiers.ts` | #410, #411, #412, #413 | | Choke point результатов тулов (`index.ts:118-125` + in-app execute-wrapper, зона метрик #402) | #417 | | Внешние MCP-клиенты (breaking) | #411 (−import_page_markdown), #412 (camelCase), #413 (дефолт getNode) | | Метрики per-tool (#402/#403 лейблы) | #412 (переименование рядов) | ## Порядок ### Фаза 0 — наблюдаемость и независимые фиксы (можно параллельно, хоть сейчас) - [ ] **#407** — персистить tool-error'ы в историю. Идёт **первым по смыслу**: даёт честную статистику ошибок, по которой меряется эффект всего остального (до/после для #408/#409/#413). - [ ] **#408** — corrective-подсказки в createComment. Независим от всех; с #414 не пересекается (вынос hint-хелпера из json-edit — вне скоупа дедупа). - [ ] **#417** — пассивный сигнал «new comments: N» в результатах tool-вызовов. Независим (живёт в choke point результатов, не в контестируемых tool-specs); текст сигнала пишется сразу в camelCase-именах (#412). ### Фаза 1 — фундамент, non-breaking - [ ] **#414** — дедупликация: node-ops → единая копия в `prosemirror-markdown`. **Строго до #409 и #413**: оба добавляют функции в node-ops — добавлять надо в единственную копию, а не в форк, который потом переезжает. - [ ] **#409** — pre-validate JSON-нод + `findInvalidNode` (в уже единую копию node-ops). - [ ] **#410** — insertFootnote/insertImage/replaceImage агенту + промпт исследователя. **До #412**: перенос inline-регистраций в SHARED_TOOL_SPECS означает, что camelCase-переименование приедет к ним автоматически. ### Фаза 2 — breaking-окно: один релиз, одна миграция Порядок внутри окна: - [ ] **#411** — `updatePageMarkdown` (+MCP), `import_page_markdown` −MCP. Перед #412: таблица переименования в #412 уже учитывает это удаление. - [ ] **#412** — camelCase всех имён MCP-тулов. Перед #413/#415: новые описания и SERVER_INSTRUCTIONS пишутся сразу в целевых именах, а не переписываются дважды. - [ ] **#413 PR 1** — getNode: markdown по умолчанию (breaking-часть #413). - [ ] **#413 PR 2** — markdown в patchNode/insertNode (аддитивно, но логично в том же окне: роутинг-инструкции пишутся один раз под финальную поверхность). - [ ] **#415** — точные описания getPage/exportPageMarkdown. Последним: финальный wording-sweep по уже переименованной и расширенной поверхности (правит ту же строку SERVER_INSTRUCTIONS, что #411/#413). Релизный артефакт фазы 2 — **единая BREAKING-секция CHANGELOG**: таблица имён (#412) + `import_page_markdown` → `updatePageMarkdown` (#411) + смена дефолта `getNode` (#413), с миграционной заметкой. Внешние конфиги (`.mcp.json`, permission-allowlists `mcp__gitmost-*__*`, сохранённые промпты/скиллы, дашборды метрик #402/#403) мигрируют **один раз**. ## Definition of done - Все чекбоксы закрыты, каждое ишью — своим PR (или парой PR для #413). - Внешние клиенты ломались ровно один раз (одним релизом фазы 2). - После фазы 2 статистика #407 показывает снижение ошибок patchNode/insertNode (эффект #409+#413) и createComment (#408); петля «человек комментирует → агент реагирует» замыкается без ручного check_new_comments (#417). Связано: #407 #408 #409 #410 #411 #412 #413 #414 #415 #417.
agent_vscode changed title from meta(tools): roadmap #407–#415 — порядок работ и состав breaking-релиза to meta(tools): roadmap #407–#417 — порядок работ и состав breaking-релиза 2026-07-07 21:06:55 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
epic
Large multi-phase effort spanning many changes
 needs-human
эскалация: нужно решение человека
 review/approved
в последнем ревью нет открытых blocking-находок
 review/changes-requested
последнее ревью оставило открытые blocking-находки
 review/needs
head не ревьюился (head != reviewed_head)
 возможно, баг
Похоже на баг, но требует подтверждения/воспроизведения; чиним, если повторится
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent_coder agent_qa agent_reviewer agent_vscode vvzvlad
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vvzvlad/gitmost#416
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?