Quartz 4

BloodGPT Wiki

Not verified

Created · Updated 6 min read

Эта вики — командный артефакт, который описывает компанию, бизнес и архитектуру BloodGPT в текстовом виде. Обычно «вики» = справка о продукте; в эпоху LLM на неё стоит смотреть шире — материал отсюда дальше идёт в производные артефакты: код, тесты, маркетинг-материалы, письма, brainstorm-сессии, распределение и координация задач. Все из команды читают, верифицируют и используют. Ошибки в тексте имеют downstream-цену — инвестиция в качество окупается на всех слоях.

Форма: один topic per page, плотный cross-link, кумулятивное состояние (а не хроника обсуждений)1.

Цикл создания страницы

  1. Первый черновик пишет LLM. Раскладывает топик в structured prose. Это draft — заведомо ~10-20% слоп / спорных формулировок / упрощений.

  2. Член команды читает и оставляет вопросы / поправки прямо в тексте. Что не сходится с реальностью, что упрощено или навязано, чего не хватает. Конкретный способ варьируется: Ильдар пользуется CriticMarkup-комментами {>> вопрос или поправка <<} в файле; другие могут оставлять inline-замечания в чате с LLM или ad-hoc заметки. Идея общая — отметить места, где есть сомнения, и интегрировать поправки следующим проходом.

  3. LLM в следующем проходе интегрирует поправки. Читает существующие комменты, разбирает каждый, правит локальные секции. Большие правки идут не one-shot’ом, а через несколько раундов «комментарии → integrate → re-read». Комменты могут оставлять разные люди — следующий проход интегрирует их все.

  4. Через 3-5 итераций страница сходится к состоянию, на которое можно полагаться. Ничего не работает «с первого раза»; всё работает «после нескольких проходов» — это не недостаток процесса, это его форма.

Status discipline — уровень доверия

Статус страницы — это сколько ей можно доверять:

  • draft — страница появилась, кто-то из команды её не верифицировал. На неё нельзя полагаться без дополнительного внимания: проверь факты, перечитай аргументы, не используй как single source of truth для code review / координации. Ошибки draft’а на downstream-стадиях обходятся дороже, чем потратить 5 минут на ревью на этой стадии.
  • active — текущее знание, верификатор подтверждает. Можно полагаться, использовать для проверки кода, для координации задач, для коммуникации с командой. Source of truth. Дальше переспрашивать не нужно — ссылаешься на страницу.
  • contested — решение, по которому есть несколько позиций; не закрыто. Используется для понимания «где спор», не для финальных решений (только для type: decision).
  • superseded — заменено новее. Хранится для истории через superseded_by:, не для активного использования.

Статус управляется руками — кем-то из команды, кто верифицирует страницу. Через frontmatter: verified_by: [{who: <handle>, when: YYYY-MM-DD}]. Несколько верификаторов на одну страницу — нормально, это укрепляет доверие. LLM может предложить переход draft → active, но решение всегда за человеком.

Зачем — снижение communication overhead

Без верифицированной вики команда платит за коммуникацию заново каждый раз: переспрашиваются те же вопросы, контекст пересобирается, термины расходятся в разных головах. С верифицированной вики каждый downstream-flow ускоряется:

  • Coding agent читает entity-страницу и понимает domain rules без переспрашивания
  • Code review агент (когда / если появится) сверяет PR против decisions/X.md и флагает drift — особенно важная штука
  • Marketing-LLM может посмотреть, что у нас уже описано про продукт / сегмент / pricing, и писать копию в нужный голос (а не выдумывать с нуля)
  • Brainstorm-сессии можно делать вместе с LLM, стартуя от «где мы сейчас» (verified state), на базе наших же текстов
  • Распределение задач опирается на единый словарь — одна сущность = одна страница, не пять разных терминов в разных головах
  • Онбординг на чужой код — сверяешься с соответствующими entity / concept-страницами вместо переспрашивания автора

Каждая верифицированная страница экономит время на downstream-стадиях. Чем больше страниц в active, тем дешевле работа поверх.

Что НЕ нужно делать

  • Не верифицировать draft’ы автоматически («ну вроде ок» — не годится). Верификация = человек из команды прочитал и согласен; отмечается через verified_by: [{who: <handle>, when: YYYY-MM-DD}] в frontmatter.
  • Не давать LLM писать «новые источники истины» в один присест. Только iterative co-authorship через несколько проходов.
  • Не использовать draft-страницы для критичных решений без явного «но я знаю, что это draft».
  • Не дублировать факты между страницами — wikilinks вместо копий; иначе при правке одного источника другие расходятся.
  • Перед правкой страницы прочитать существующие коммент-пометки. Если кто-то оставил вопрос или поправку, её нужно осознать и интегрировать смысл в текст — иначе следующий проход поверх «забудет» что прошлый член команды хотел исправить. Полная процедура CriticMarkup-интеграции — в CLAUDE § CriticMarkup workflow.

Как искать

  • Explorer (слева) — иерархия папок. Краткие descriptions подтягиваются из frontmatter description: каждой страницы.
  • Graph (справа) — локальные связи текущей страницы; кнопка над ним открывает глобальный граф со всеми wikilinks.
  • Search (Ctrl+K / иконка сверху) — full-text по всему контенту.
  • Tags — /tags/decision собирает все важные решения cross-folder (они лежат в topical-папках, не в выделенной decisions/).
  • Git history — реальная хронология. Вики — git-репозиторий; git log показывает кто / когда / зачем правил. Manual changelog не ведём, протухает (никто не вспоминает обновить руками).

Графовое кодирование

В Graph (справа на странице, и full-screen по кнопке) ноды кодируются по двум осям:

  • Shape — тип страницы (из frontmatter type:):
    • круг — entity (конкретная сущность)
    • квадрат — concept (паттерн / процесс)
    • ромб — decision (важное решение — архитектурное, продуктовое, методологическое)
    • треугольник — source (внешний источник с локальной копией)
  • Color — статус страницы (из frontmatter status:):
    • teal (#2a9d8f) — active (актуальное знание / принятое решение)
    • amber (#e9c46a) — draft (в работе, читай с осторожностью)
    • coral (#e76f51) — contested (несколько позиций, ищется компромисс — только для decision)
    • grey (#999) — superseded (заменено новее, см. поле superseded_by:)
    • без статуса — серый default; текущая страница — --secondary цвет темы

Без type: / status: нода рисуется кругом серого цвета. Hashtags в графе отключены (showTags: false в quartz.layout.ts).

Структура папок

  • domain/ — медицина, FHIR-ресурсы, LOINC, SNOMED, medical decisions
  • technical/ — стек, vendors, pipelines, технические решения
  • product/ — customer-facing фичи, surfaces, integration paths
  • team/ — команда, процессы, коммуникация, DevOps-практика
  • industry/ — внешние продукты-аналоги и партнёры
  • meta/ — конвенции самой вики

Decision-страницы лежат в topical folder своего домена, помечены tags: [decision]. Cross-folder обзор всех решений — на /tags/decision.

Untracked product surfaces

Есть в спеках, нет в вики — собирать страницы по триггеру: Partner Portal (spec 11), AI Chat (spec 07), Diets (spec 05), Reports & Delivery (spec 04), API Integration (spec 09 — Full API endpoints), Organization Management (spec 10), WhatsApp channel (public docs playbook).

Меta

  • CLAUDE — schema, правила, типы страниц, source-конвенции
  • page-format-standard — operational spec формата страниц + audit checklist
  • sources-registry — регистр внешних источников (URL-only, team-shareable)

Сноски

  1. Форма «LLM-curated wiki как persistent context» — A. Karpathy, “How I use LLMs”, 2025, https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f. Исходное вдохновение, не методология (нашу определяет эта же страница). ↩

Graph View

Backlinks