Подход к управлению знаниями

Знания про BloodGPT — стратегия, конкуренты, pricing, roadmap, lessons плюс знания о функционале и технические нюансы — постоянно обновляются. Нужна среда, в которой это эффективно поддерживать и делиться с командой. Эта страница фиксирует где и как мы это делаем на Apr 2026 и историю предыдущих попыток.

Текущее решение: markdown wiki

/home/i/vault/wiki/bloodgpt/ — primary место для знаний. Karpathy-style LLM wiki с co-authorship: LLM пишет / обновляет, человек читает, правит через CriticMarkup.

Что работает хорошо:

• Markdown нативен для LLM — нет MCP-проблем со вставкой / редактированием.
• Локальные файлы → синхронизация Obsidian → доступ с телефона через Syncthing.
• Git-история всех изменений в одном месте, авторитетный источник правды.
• Wikilinks между страницами через [[X]], плотно cross-linked.
• CriticMarkup {++ ++} / {-- --} / {>> <<} для co-authorship — работает в Obsidian-плагине, не требует отдельной среды. Практика уже расширяется на коллег — например, Макс тоже работает с CriticMarkup в Obsidian.

История попыток зафиксировать систему документации

Это четвёртая итерация. Каждая предыдущая упёрлась в свою стенку.

Итерация 1: docs при NestJS-портировании (лето 2025)

Контекст. Летом 2025 шёл переезд бэкенда с .NET на NestJS — аналог ASP.NET в TS-мире, c теми же абстракциями (DI, модули, ORM, сервисы). Аргумент за NestJS как стек: корпоративный фреймворк с принятыми решениями за пользователя, удобный для онбординга разрабов. Обсуждалось с коллегами на созвонах (несколько раундов проработки architecture / migration plan), параллельно прорабатывался Strangler Fig pattern — application-level proxy с stub-методами на новом бэкенде, постепенно заменяющиеся реальной логикой.

Реализация с Gemini CLI в директории /home/i/JOBS/BloodGPT/dotnet-to-nest-migration/ — самое интересное было в том, как организована сама документация:

• GEMINI.md — config для Gemini CLI (аналог CLAUDE.md для Claude Code). Описывает структуру проекта, six-step migration algorithm и принципы.
• Документация в /docs/: PRD, tech-stack, migration-plan, новая архитектура с Mermaid sequence diagrams, reflection-log для уроков, repomix-output старого бэкенда для AI-context, drawio-диаграмма миграции.
• 8 фаз миграции с детальными tasks-файлами и чекбоксами:
  • Phase 0: Фундамент — завершено
  • Phase 1: Аутентификация — завершено
  • Phase 2: Управление профилем — завершено
  • Phase 3: Создание Анализа — в процессе (загрузка теста)
  • Phase 4–7: запланировано
• /nest/ — реальный Nest.js проект с registration / auth / загрузкой теста; Phase 0–2 работают.

Six-step algorithm для каждой функциональной единицы:

1. Understand — изучить .NET-исходники и Prisma-схему.
2. Design — Mermaid sequence diagram в docs/architecture.md.
3. Plan — атомарные задачи с чекбоксами в docs/phase-N-tasks.md.
4. Implement — DTO, сервис, контроллер.
5. Verify — Unit / Integration / E2E тесты.
6. Document — отметить чекбоксы, добавить запись в reflection-log.md.

Чем закончилось. До production не дошло. Реализованные 3 фазы и документация остались как самодостаточный артефакт в dotnet-to-nest-migration/. Стиль («GEMINI.md + numbered phases + tasks с чекбоксами + reflection-log + Mermaid-диаграммы») оказался удачным шаблоном — он проступает в последующих CLAUDE.md-конфигах (включая текущий wiki) и в формате RFC-папки specs/RFC/. Дополнительно — сама модель «фазы + чекбоксы + reflection» позже стала нативной в Claude Code (TaskCreate / TodoWrite), то есть инструмент догнал паттерн.

Итерация 2: Cascade Plugin — spec-driven development (Jan 2026)

Параллельная попытка — формализовать поток изменений через plugin для Claude Code, реализующий spec-driven development: три уровня (бизнес-спека → техническая спека → код), команды /down и /up для каскадирования. Та же задача, что NestJS-документация — превращение спецификации в код и обратно — но через формализованный плагин.

Плагин работающий (v0.5.0), но широкого внедрения в команду не получило: синхронизация Google Docs ↔ repo через MCP даёт нюансы, и слой технических спек требует дисциплины которую не удалось закрепить.

Подробности и canonical-методология: cascade-plugin.

Итерация 3: Google Docs для шаринга планов (Jan–Mar 2026)

После Cascade — отдельная практика для шаринга LLM-планов с командой. Параллельно Cascade-плагину, но не привязанная к спецификациям: Клод (через Claude Code) создаёт план в Google Doc → коллеги оставляют комментарии прямо в Doc → план дорабатывается.

Конкретный пример (Jan 27 2026):

«продолжаю экспериментировать. хочешь фидбек дать по плану? комментами просто оставь.»

Параллельно велись бизнес-спеки в /home/i/JOBS/BloodGPT/specs/business/ (нумерованные 00-overview.md до 15-superadmin.md — 16 файлов overview / recognition / normalization / interpretation / reports-delivery / api-integration / portals / superadmin). Структура и конвенции этих спек родились в session d036fad8 (Jan 6–9 2026, 3 дня). Ключевые конвенции — до сих пор живут в business/CLAUDE.md:

• Герундии для именования фич (отглагольные существительные — «Просмотр списка пациентов», не «Дашборд»).
• Pyramid формат: «Что получает пользователь» + пример с шагами в callout-style.
• Capability vs Product дихотомия — terminology заимствована из SAFe. Сам термин Capability на момент фиксации вызывал дискомфорт автора («мне не нравится что мы пишем Capability, может какой-то аналог»). Аналог не нашли — оставили. Это ключевой carry-over для Apr 2026 формализации product/ vs technical/.

Параллельно завелась specs/decisions/ с нумерованными RFC.

Workflow Google Docs зафиксирован в Mar 2 V-N-J digest [С1] «Nice-to-have фичи vs фокус на деньгах» — компромисс с Васей: «делиться идеями асинхронно через Google Docs, команда даёт фидбэк».

Чем закончилось. Не сработало:

• Google Docs через MCP ненадёжен — постоянные нюансы со вставкой / редактированием кусков. Каждое автообновление превращалось в ручную настройку.
• План в Google Doc застревал между итерациями: Клод создал → коллеги покомментировали → внести правки в Doc через MCP сложно → план либо переезжал в новый Doc, либо терял интегральность. Цикл не замыкался.
• Sharing давал возможность комментариев, но синхронизация LLM ↔ Doc убивала практику. Окей, комментарии можно было удалять — но оказалось что это не во-первых, и неудобно во-вторых.

Итерация 4: markdown-wiki + CriticMarkup (Apr 2026 →)

Текущая. Karpathy-style LLM-wiki. CriticMarkup как осознанная замена комментариям в Google Docs — основная ценность Google Docs была именно в возможности оставлять комментарии, и CriticMarkup воспроизводит её прямо в markdown-файлах. Sync через Obsidian, git как single source of truth. См. начало этой страницы.

От чего отказываемся явно

• /home/i/JOBS/BloodGPT/specs/business/*.md — legacy reference, можно использовать как source-материал при ingest в wiki, не вести как canonical и не обновлять при каждом изменении.
• Google Docs как зеркало wiki — пока нет; не вернёмся без явного решения.
• /home/i/JOBS/BloodGPT/specs/decisions/*.md — аналогичный legacy. RFC-формат можно интегрировать в wiki напрямую — упростит жизнь, не нужно будет поддерживать второе место.

Открытые вопросы

Что в wiki — спецификация vs обсуждение vs реализованное-но-обсуждаемое

В одной wiki-странице могут жить несколько слоёв:

• Спецификация — фиксация того, что реализовано (как сейчас в продукте).
• Обсуждение — открытые вопросы, варианты, неутверждённые предложения.
• Реализовано-но-обсуждаемое — что-то уже сделано, но команда хочет это пере-обсудить.

Сейчас они смешаны. Как разделять структурно — frontmatter-флагом, отдельными разделами на странице, отдельными файлами — не выбрано. Carry-over.

Sharing с коллегами с возможностью комментариев

Локальные markdown файлы → коллегам нужен какой-то shared layer чтобы читать и оставлять комментарии. Варианты:

• Notion как зеркало — синхронизировать wiki с Notion через интеграцию. Существенный риск — синхронизация двух source-of-truth, которая убила Итерацию 3.
• CriticMarkup напрямую в markdown — крайний случай, требует чтобы коллеги работали с git / markdown / Obsidian.
• GitHub-репо с PR-комментариями — для technical-уровня коллег.
• Сервис-обёртка над git-репо с UI для комментариев — что-то типа GitDoc / Gitiles / WikiJS поверх markdown в git. Не выбран конкретный кандидат.

Carry-over для следующей итерации обсуждения.

Сегментация по уровням доступа

Не всё в wiki стоит показывать всем. industry/* про конкурентов — sales-relevant, можно делиться шире. team-dynamics.md — внутреннее, сюда нужен ограниченный круг. Структура access-levels не оформлена.

Связано

• cascade-plugin — Cascade Plugin v0.5.0, отдельная страница про spec-driven development tooling
• team-dynamics — командные паттерны (sharing / collaboration smежны)
• CLAUDE.md — wiki conventions (schema, типы страниц, lint policy)
• уроки — methodology lessons
• вопросы — открытые вопросы про развитие wiki

Источники

Источники: ^{1 2}.

Сноски

1. Сессия ildar/d036fad8, 2026-01-25 — ` (Jan 6–9 2026. ↩

2. 2026-03-02 V-N-J digest [С1] (компромисс «делиться идеями через Google Docs, команда фидбэчит»), accessed 2026-05-17, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/03/2026-03-02T14%3A00%3A00.000Z_BloodGPT_heads_sync_01KJFB07HG082YPZ0S8J6Z76JP.md. ↩