BloodGPT Wiki

Компанная память BloodGPT. Паттерн — Karpathy LLM Wiki. Читатель — Ильдар. Пишет LLM, правит и читает Ильдар.

Перед началом сессии

Точка входа — index (философия, цикл создания страниц, status discipline, навигация по разделам). Дальше — конкретные страницы по нужде. Хронологию правок смотрят в git log (вики — git-репозиторий, см. ниже «Версионирование»); manual changelog не ведём — протухает. Не ищи decisions/ как отдельную папку: решения теперь живут в topical folders (product/, technical/, domain/, team/, meta/) рядом с entity- и concept-страницами того же домена.

Правила одним абзацем

Karpathy-style LLM wiki: персистентный compounding артефакт. Маленькие focused страницы, плотно cross-linked. Один topic per page. Source raw отдельно — wiki синтезирует. LLM пишет, Ильдар curates источники. Страница перечитывается; если не перечитывается месяц — помечается lint-ом как slop-кандидат.

Compounding behavior (важно): новый source про существующую entity → UPDATE entity-page (добавить факт, обновить Status, добавить cross-ref). Не создаём новую страницу про ту же сущность. Decision-страницы append-only — новые insights появляются как новые позиции / следствия / open вопросы.

Стиль страницы — cumulative state, не digest-пересказ. Страница описывает где мы сейчас в понимании topic-а. Это не chronology обсуждений, не retelling митинга. Факты-описания + ссылки на decision-страницы для всего что является “вопросом”. Verbatim quotes — только когда язык source-а критичен (precise wording того, что было сказано). Иначе — synthesize.

Источники (три класса)

• Транскрипты митингов. Structured digest-ы ([Н]/[Р]/[О]/[С]/[Э]) — публичный GitHub repo Realai-plus/meeting-digests (URL — см. ниже «Какие URL’ы»). Локальные пути на машине автора — в sources-personal.local.md.
• Claude sessions. Транскрипты jsonl-сессий — intra-team artifact, формат referencing см. ниже «Какие URL’ы». Локальные пути (~/.claude/projects/...) и chain archives — в sources-personal.local.md.
• Код. Публичные GitHub URLs (Realai-plus/<repo>/blob/<branch>/<path>). Локальные пути и worktree-папки — в sources-personal.local.md.
• Внешние исследования. Academic papers, regulatory docs, медицинские гайдлайны — регистрируются в sources-registry.md (публичные URL primary). Локальные копии (Zotero / PDF) — личное дело автора, в wiki не упоминаются.

Личные заметки Ильдара (journal, /vault/RealAI/*) — в эту wiki не копируются. Они живут отдельно.

Структура

bloodgpt/
├── CLAUDE.md
├── index.md
├── sources-registry.md
├── product/       customer-facing фичи, surfaces, integration paths, GTM-решения
├── team/          команда, процессы, коммуникация, DevOps-практика
├── technical/     stack, vendors, pipelines, internal architecture decisions
├── domain/        медицина, FHIR-сущности, LOINC, medical decisions
├── industry/      Abridge, Nabla, Ambience — внешние продукты-аналоги
└── meta/          конвенции самой вики (формат страниц, шаблоны)

Decision-страницы НЕ живут в отдельной decisions/ папке — каждая лежит в topical folder того домена, к которому относится (product / technical / domain / team / meta). Связь между ними — общий tags: [decision] в frontmatter (cross-folder агрегация на /tags/decision).

Новые папки создаются только когда появляется первая страница.

Версионирование (git)

Эта вики — git-репозиторий (/home/i/JOBS/BloodGPT/wiki/; в vault видна как симлинк /home/i/vault/bloodgpt/). История страниц коммитится здесь.

• После создания страницы или значимой правки — git commit. Один коммит = одна логическая единица (новая страница / переработка раздела / интеграция CriticMarkup-комментариев Ильдара). Сообщение коммита описывает что и зачем (примеры — в git log).
• Мелкие правки можно копить и закоммитить пачкой в конце сессии — но не оставлять uncommitted надолго.
• Перед тем как перезаписать живой файл из старого снапшота — сначала забэкапить текущее состояние. Иначе теряются правки (в т.ч. CriticMarkup-комменты — Ильдар редактирует параллельно в Emacs).
• .git синкается через Syncthing вместе с вики → не коммитить с двух машин одновременно. *.conflict / *.sync-conflict-* файлы (от синка при параллельном редактировании) — реконсилить: вытащить CriticMarkup-комменты в основной файл, удалить копию.
• .gitignore исключает .claude-fork-*.txt и .claude/ (транзиентные артефакты сессий).

product/ vs technical/ — разделение

Зеркалит «Capability vs Product» из /home/i/JOBS/BloodGPT/specs/business/CLAUDE.md:

	product/	technical/
Отвечает	Что клиент видит / выбирает / покупает	Как мы это строим (стек, vendors, pipelines)
Канонический источник	Public docs (Realai-plus/docs), бизнес-спеки (/specs/business/*-product*.md), pricing, sales positioning	Код, infra repos, RFC’s
Стабильность	Стабильнее (фича остаётся одной даже когда переписана)	Волатильнее
Аудитория страницы	Понять product surface — sales pitch, обсуждение приоритетов	Понять / изменить / отдеплоить кусок системы

Правило большого пальца: если у сущности есть публично-документированное название в playbook / pricing / sales — стартует в product/. Implementation-детали (стек, route’ы, role gates) — секция внутри той же страницы. Если технические детали разрастаются — мигрируют в technical/X.md с cross-link, product-страница остаётся «что и зачем», не «как».

Примеры применения:

• Doctor Validation → product/ (playbook есть, role в коде, продаваемая опция)
• WorkOS → technical/ (vendor; клиент покупает «SSO», не WorkOS)
• Patient Portal → product/ (white-label customer-facing с спекой 13)
• Multi-tenant FHIR storage → technical/ (внутренняя архитектура; клиенту видится через «white-label» / «data isolation», но это implementation)
• Custom domains → technical/ (механизм); продуктовая обёртка «white-label» может быть отдельной product/white-label.md

Не product: internal admin tools (DQD, superadmin), evaluation infrastructure, vendors, infra. Это всё в technical/ или team/ (если это процесс).

Типы страниц

type: entity — что-то конкретное и referenceable (FHIR Composition, WorkOS, Google Healthcare API, NOHARM study). Маленькие (50-150 строк), плотно cross-linked. Содержат: definition + наше использование + ключевые поля/возможности + gotchas + связанные entities/concepts.

type: concept — overview процесса или архитектурного pattern (multi-tenant FHIR, patient summary pipeline). Тонкие — линкуют на entity-страницы вместо переопределения. Содержат: проблему + ссылки на decision-страницы + следствия + связано.

type: decision — конкретный архитектурный вопрос. Может быть в разном статусе — не только resolved. Decision-страницы лежат в topical folder того домена, к которому относится решение (product / technical / domain / team / meta), не в отдельной decisions/ папке. Все они помечены tags: [decision] для cross-folder агрегации на /tags/decision. Status frontmatter указывает в каком состоянии (см. ниже).

type: source — внешний источник с локальной копией (NOHARM PDF и т.п.).

Формат страницы

Полный operational spec + audit checklist — в page-format-standard. Здесь — короткая выжимка для quick-reference.

---
type: concept | decision | entity | source
status: draft | active | contested | superseded
updated: YYYY-MM-DD                                      # когда страница последний раз пересматривалась; Quartz отображает это значение под title в FolderPage (built-in alias для `modified`)
created: YYYY-MM-DD                                      # опционально; когда страница впервые создана. Quartz alias `created` ← `date`. Не обязательно — backfill для существующих страниц не делали; добавляй для новых страниц, чтобы потом можно было переключить FolderPage на «created» semantic если понадобится
verified_by:                                             # опционально, см. meta/page-readership-model
  - { who: ildar, when: YYYY-MM-DD }
tags:                                                    # опционально; для decision-страниц всегда включать `decision`
  - decision
superseded_by: <wikilink>                                # обязательно если status: superseded
---

status: — author intent (где автор считает страницу в lifecycle). verified_by: — review history (кто прочитал и считает что текст ОК). Это ОРТОГОНАЛЬНЫЕ оси — обе значимы; полная модель в page-readership-model.

updated: — дата последнего пересмотра содержимого. Quartz Plugin.FrontMatter коалесцирует updated/lastmod/last-modified в один modified (см. quartz/plugins/transformers/frontmatter.ts:108), Plugin.CreatedModifiedDate берёт это значение с приоритетом frontmatter > git > filesystem — поэтому FolderPage / Explorer показывают именно updated: под title страницы. Старое имя last_updated: Quartz не понимает (fallback на git modified, который у нас выровнен датой description-migration). Если в файле осталось last_updated: — переименуй.

created: (опционально) — дата первого авторства страницы. Quartz коалесцирует created/date в created поле (frontmatter.ts:103). Сейчас defaultDateType: "modified" (в quartz.config.ts:21) — FolderPage показывает updated:, не created:. Backfill для 216 существующих страниц не делали (надёжной creation-date для них нет, git history начался 2026-05-11, оригинальные даты — только косвенно через updated: если страница ни разу не правилась). Для новых страниц записывай оба поля (created: = updated: в день создания) — если решим переключить отображение, данные уже будут.

Watch-mode gotcha: Quartz dev server кэширует file.data в памяти и при rename frontmatter-полей FolderPage HTML может строиться из stale state (individual page рендерится корректно, но в FolderPage всё ещё mtime). Если frontmatter convention изменилась — рестарт сервера обязателен: Ctrl-C в окне 0:📌quartz, потом npm_config_engine_strict=false npx quartz build --serve --port 8081 --wsPort 3003.

Для entity — короткое определение → “Где живёт в данных / Использование в BloodGPT” → разделы по аспектам (топиками) → “Failure modes” / “Открытые вопросы” (мелкие TBD bullet’ами) → “Связано” (единый bullet-список: entities + concepts + decisions; decision-страницы помечаются inline — **active** / — **draft** / — **contested**) → footnote defs (без heading «Источники»).

Для concept — Контекст → разделы по аспектам → “Открытые вопросы” → “Связано” (единый список, см. формат для entity).

Для decision — Заголовок-решение в одну фразу → “Status:” → “Контекст” → “Рассматривали” / “Позиции” (альтернативы) → “Выбрали” + “Почему” (если active) или “Что нужно для разрешения” (если contested) → “Следствия” → “Открытые вопросы” → “Связано”. Если superseded — status: superseded + поле superseded_by: с wikilink + первой строкой тела короткое объяснение замены. Оригинал НЕ переписывается, тело адаптируется под состояние «что предлагалось и почему отвергнуто».

Carry-over (sweep): на ~26 существующих страницах отдельная ## Связанные решения секция — при касании страницы merge в ## Связано (новые страницы сразу пишутся в едином формате). Источник convention — page-format-standard.

Status enum (4 значения, единый для всех типов)

• draft — работа над страницей идёт, читать с осторожностью. Покрывает: «черновик entity», «proposal decision’а одной стороной», «изучаем тему, пока не зафиксировано», «placeholder с pointer’ами куда копать», «вопрос задан, никто не двигает».
• active — текущее знание / принятое решение. Базовый статус для большинства страниц.
• contested — (только для type: decision) несколько позиций, ищется компромисс. Действие: искать компромисс, а не «начать работу».
• superseded — заменено новее. Обязательное поле superseded_by: с wikilink. Тело страницы адаптируется под «что предлагалось и почему».

Нюансы (legacy/staging/feature-flag/regional differences) не идут в status: — статус остаётся одним словом из enum. Нюанс пишется в первом абзаце тела или отдельным полем phase: если нужна machine-readability.

Где живут decisions — topical folders

Все “вопросы устройства X” живут в topical folder того домена, к которому относятся (product / technical / domain / team / meta), не в выделенной decisions/ папке. Cross-folder обзор всех решений — через /tags/decision (каждая decision-страница помечена tags: [decision]). На entity/concept-странице не пишем inline [Р]/[О]/[С] маркеры — это шум. Вместо этого:

• Малый TBD (например, “найти конкретный URL”, “verify номер”) → bullet в “Открытые вопросы” на самой странице
• Решение / большой open / contested topic → отдельная страница в соответствующем topical folder со статусом + tags: [decision]
• На entity/concept-странице — линк на decision в общем ## Связано со status-комментарием: [[../<folder>/X]] — короткое описание — **status**

Куда класть decision (правило большого пальца):

• product/ — customer-facing UX/positioning/GTM (unified-upload-flow, b2c-before-b2b-rollout, no-prescription-red-line)
• technical/ — pipeline, infra, vendor choice, internal architecture (phi-in-fhir-not-sql, bifrost-mock-strategy, health-facts-as-generation-substrate)
• domain/ — medical/FHIR semantics, LOINC, biology rules (biomarker-actuality-thresholds, zero-extensions-fhir, region-aware-ranges)
• team/ — process, communication, DevOps practice (manual-testing-red-flag, supply-chain-defense-stack)
• meta/ — wiki conventions, formats, templates (wiki-io-contract-format, page-readership-model)

Граница: что входит в decision, а что в concept

1. Decision описывает архитектурную сшивку, не код на ней. «Где в системе живёт ответственность за это поведение» — да; «как написан код в этом месте» — нет. Конкретные file paths, имена сервисов/функций, поля БД, langfuse prompt keys — это материал concept/entity, не decision.

2. Implementation-style вопросы переформулируй через сшивку. Не «как фильтруем patient контент», а «на каком этапе pipeline’а живёт ответственность за фильтрацию». Это превращает имплементационный вопрос в архитектурный, и тогда decision действительно отвечает.

3. Decision = source of truth для rationale; concept ссылается одной строкой. Не дублируй «почему» в обеих страницах — это создаёт drift. Concept содержит факт + ссылку: «Actuality: TTL per panel, anchor от newest biomarker — [[../domain/biomarker-actuality-thresholds]]».

4. Достаточность теста. Decision должен дать новому человеку: что заменяется (shape), какие были аргументы (rationale), на что завязано (consequences) — чтобы решить «пересматривать или нет». «Как написать новый код по этому решению» — не работа decision-страницы.

Carry-overs

Маленькие “сделать позже” пометки внутри текста — **Carry-over:** ... или > *Carry-over: ...* (blockquote). Используются для:

• Найти конкретный transcript / source
• Прочитать prompt и выписать его логику
• Verify статус implementation
• Заменить generic URL на specific

Carry-overs — НЕ замена decision-странице. Они для маленьких неразвёрнутых TBD.

Разделы entity/concept-страницы — включаем только те, для которых есть материал. Без [Н] / [Р] / [С] / [О] inline маркеров. Описание факта = заголовок секции + содержимое.

Co-authorship

LLM пишет черновик страницы. Ильдар читает, правит, валидирует. Человеческое суждение — primary, LLM — синтезатор.

CriticMarkup workflow (важно)

Ильдар оставляет комментарии в файле через CriticMarkup {++ ... ++} (insert), {-- ... --} (delete), {~~ старое ~> новое ~~} (replace), {>> ... <<} (note).

Перед любым редактированием страницы LLM ОБЯЗАН:

1. Прочитать все CriticMarkup-комментарии в файле.
2. Осознать каждый — что Ильдар хочет передать (фактическая поправка / nuance / рекомендация изменить структуру / pointer на отдельный topic).
3. Только потом править форму, интегрируя смысл комментариев.
4. Удалять {++ ++} маркер можно только после интеграции его содержания в текст.

Запрещено: массовый rewrite файла без предварительного чтения CriticMarkup. Это теряет nuance Ильдара. Если форма требует rewrite — копировать комментарии в working notes, потом интегрировать.

Если интеграция комментария требует отдельной страницы (например, “это отдельная тема”) — создать placeholder + carry-over reference, не закопать комментарий.

Источники — формат ссылок

Принцип

Wiki — отчуждаемый артефакт для команды. Любая ссылка в теле страницы / footnote / sources-registry должна разворачиваться через URL у любого члена команды (без доступа к машине Ильдара). Локальные пути (/home/i/..., ~/...) в публичный/командный слой не попадают.

Личная инфраструктура Ильдара (локальные дампы, Desktop scratch, Zotero, jsonl-сессии) живёт в gitignored sources-personal.local.md рядом с sources-registry.md. Claude на машине Ильдара читает оба файла — но в committed git попадает только первый.

Паттерн *.local.md для personal overrides

*.local.md в .gitignore — место для personal pointer-ов и локальных путей. Используем:

• sources-personal.local.md — местоположения внешних источников на машине автора, зеркало для sources-registry.
• CLAUDE.local.md — auto-loaded Claude Code расширение committed CLAUDE.md. Содержит directive «также прочитай sources-personal.local.md», pointer-ы на параллельные процессы (Emacs / Syncthing) и любые личные настройки работы с вики, которые не уместны в team-shared слое.

Любой новый клон вики начинает чистым (без *.local.md); локальные файлы создаёт сам автор по мере необходимости.

Какие URL’ы

Два инварианта footnote’а: (1) дата (YYYY-MM-DD) — обязательна для любого типа источника; (2) где смотреть — публичный URL для внешних артефактов (созвон / код / статья / Slack / Telegram), intra-team референс для Claude-сессий (публичного хранилища пока нет, jsonl живёт у оператора локально). Без даты footnote не валиден — её отсутствие == «факт без атрибуции по времени».

Семантика даты по типу источника:

• Event-based (созвон / сессия / Slack-сообщение / commit / paper publication) — дата события.

• Living docs (HL7-spec, regulations, vendor docs, API reference) — accessed YYYY-MM-DD (дата, когда автор последний раз сверил содержимое со ссылкой). Living-docs ссылки рискуют устаревать; маркер accessed фиксирует, на какое состояние страница опиралась.

• Fireflies digests — https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/YYYY/MM/...md. URL-encode special chars (: → %3A, кириллица → punycode/escape). Не локальный путь, не fireflies.ai.

• Slack — permalink на конкретное сообщение / thread. Содержимое не копируем — только референс.

• Telegram (публичные каналы с username) — https://t.me/<channel>/<msg_id> для отдельного сообщения; https://t.me/<channel> для канала в целом. Работает для каналов; в группах без username permalink-ов нет — такие источники не цитируются.

• Code / RFC / specs — GitHub URLs на Realai-plus/<repo>/blob/<branch>/<path>. Локальные пути и worktree-папки — только в personal.local.

• Claude sessions (jsonl) + session digests — intra-team референс, без локальных путей. Формат footnote: Сессия <owner>/<sid8>, <YYYY-MM-DD> — <comment>. где <owner> — handle оператора (ildar, arthur, nikita…), <sid8> — первые 8 символов session UUID, <comment> — одна строка о чём сессия (как «о чём созвон» у Fireflies-footnote): задача / тема / решение, которое автор хочет зафиксировать. Транскрипт jsonl лежит у оператора локально (~/.claude/projects/... — в personal.local), достаётся по запросу. Это отличается от ГОСТ-маркера «Цит. по сессии» (см. ниже «Эпистемическая атрибуция»): здесь сессия — primary источник (фиксируем «когда / где / у кого»); там маркер означает «не открывал оригинал, доверяю тому, что нашёл Claude через WebSearch».

• External (papers / docs) — публичный URL (arxiv / DOI / vendor site). Локальные копии (Zotero и т.п.) — личное дело автора, в вики не упоминаются.

Где ссылка живёт — footnotes, не inline

Все ссылки на внешние источники (созвон / Slack / paper / digest) — только через markdown-footnotes ([^name]). Inline-URL’ов на дайджесты / Slack / транскрипты в теле страницы быть не должно — это шум.

Рендеринг footnotes — отдаём Quartz:

• [^slug] маркер в теле — там, где факт цитируется (точка-anchor самой узкой фразы)
• [^slug]: текст definition — в конце файла, без обёртывающего heading
• НЕ писать ## Источники heading — Quartz сам генерирует Сноски-блок в конце страницы из footnote definitions
• НЕ писать «activator-line» вида Источники: [^s1] [^s2]... — была вынужденная мера, когда тело не содержит inline markers (orphan defs не рендерятся); правильный путь — inline markers в теле, не активатор

## Принцип
 
Мотивированные пользователи не справляются с разделённым интерфейсом[^digest-2026-04-23-fda] — типичный failure mode...
 
…тело страницы…
 
[^digest-2026-04-23-fda]: «Про FDA?», 2026-04-23, https://github.com/Realai-plus/meeting-digests/...md — Георгий не справился (Н1); переименование «тесты» → «my health» (Р1).
[^session-29362bdd]: Сессия `ildar/29362bdd`, 2026-05-17 — переход на стандартное `updated:` + backfill `created:` для 216 wiki-страниц.

Body — cumulative state, не digest-narrative

Дата митинга / сессии — в footnote definition, не в теле страницы. В теле описываем где мы сейчас в понимании topic-а, а не «что произошло на Apr 23». Маркер привязывается к claim-у (факту / решению / observation), не к дате-anchor’у.

Плохо (digest-style):

Apr 23: Жорж не справился с задачей. Конкретные поломки:
- Не понял разницу между «тесты» и «медконтекст»

Хорошо (cumulative-state):

Мотивированные пользователи не справляются с разделённым
интерфейсом[^digest-2026-04-23-fda] — типичный failure mode:
- Непонимание разницы между «тесты» и «медконтекст»

Verbatim quotes из сессий / митингов — только когда язык source-а критичен (precise wording того, что было сказано). Иначе synthesize. Атрибуция — footnote-маркером после quote:

> «Конкретная цитата эксперта.»[^arthur-2026-05-12]

Wikilinks ([[other-page]]) — наоборот, встраиваются в текст как часть предложения. Это внутренняя навигация, не цитирование.

Именованные footnotes ([^arthur-2026-05-12], [^slack-deploys-thread]) предпочтительнее цифровых ([^1]) — переживают перестановку и видны при просмотре исходника.

Эпистемическая атрибуция — прочитан vs «Цит. по сессии»

Любой footnote несёт claim: «вот источник для этого факта». Но у разных claims разная эпистемическая надёжность — Ильдар лично читал оригинал, или Claude нашёл через WebSearch/WebFetch и Ильдар лично источник не открывал? Это разные состояния, и читатель страницы (включая будущий Ильдар через год) имеет право знать какое.

Используем 2-state модель из ГОСТ 7.0.5-2008 §6.3 «Ссылки на источник цитат»:

Состояние	Что значит	Маркировка в footnote
прочитан (default)	Ильдар читал источник лично — оригинал, или собственный аннотированный конспект в vault/LIBRARY/. Это default, expected состояние для curator-driven wiki.	footnote на оригинал, без дополнительной метки
Цит. по сессии <owner>/<sid8>	Claude нашёл через WebSearch / WebFetch / external tool — оператор сессии лично источник не открывал, доверяет тому, что нашлось в сессии.	footnote → описание оригинала → Цит. по сессии <owner>/<sid8>. (handle оператора + первые 8 символов session UUID)

Сам маркер «Цит. по» — устоявшаяся академическая convention, означает «автор не работал с первоисточником». Дополнительные дисклеймеры типа «не верифицировано» — избыточны.

[^loinc-v282]: Regenstrief Institute, "LOINC version 2.82 concept release", Feb 24 2026. https://www.regenstrief.org/article/loinc-version-2-82-concept-release/. Цит. по сессии `ildar/29362bdd`.

Session id — id конкретной сессии (не агрегирующей сущности типа «цепочки»). Найти текущий sid — переменная окружения CLAUDE_CODE_SESSION_ID (в Claude Code), либо jsonl-файл в ~/.claude/projects/<project>/<sid>.jsonl. В footnote — первые 8 символов (abbreviation).

Owner handle — короткий ASCII-handle оператора Claude-сессии (например ildar, arthur, nikita); wiki team-shared, поэтому без явного owner’а не понять «к кому идти за transcript’ом». Привязка к session + оператору даёт retrospective audit: автор знает где живёт его archive, источник прослеживается до конкретной WebSearch-выборки.

Полная decision-страница с альтернативами и триггерами усложнения — в personal vault: vault/cabinet/SELF/pim/атрибуция-знаний.md. Здесь — minimal rule для team-shared wiki.

Когда меняется состояние: если Ильдар позже сам прочитал источник — маркер «Цит. по сессии» можно убрать (Прочитан 2026-NN-DD опционально как явное указание). Если факт устарел / wrong-concept — отдельная история (audit + правка).

Wikilinks — встраиваемая навигация, не сноски в конце

Wikilink должен быть частью прозы, а не «отдельным указанием рядом». Используй alias-форму [[page|видимый текст]] и встраивай в естественную фразу — так читается как обычный текст со ссылками.

• Плохо: «Гранулярность теряется. patient-health-summary-create-or-update решает похожую дилемму.» (две оторванные фразы)
• Хорошо: «Гранулярность теряется — та же дилемма уже решена для patient summary через PUT по identifier.» (фраза-предложение)

Якоря на секцию: [[page#заголовок|Заголовок]] или с alias’ом [[page#заголовок|короткая фраза]]. Заголовок должен буквально совпадать с ## Заголовок в целевом файле (в Obsidian — пробелы / регистр сохраняются).

• Хорошо: «Стратегия фильтрации служебных vs клинических ресурсов уже [[fhir-resource-origin-and-lifecycle#идея-a—metatag-с-origin-code|зафиксирована как meta.tag origin]].»

Когда уместно «См. также [[X]]» одной строкой — в секции «Связано» внизу страницы (там это и есть форма «список ссылок»), не в теле параграфа.

Запрещено

• Факт без цитаты из источника.
• Footnote без даты (YYYY-MM-DD) — независимо от типа источника. См. «Какие URL’ы» § «Два инварианта footnote’а».
• Footnote на WebSearch/WebFetch-найденный источник без маркера Цит. по сессии <owner>/<sid> — это implicit claim что автор читал источник лично, который ложен.
• Пересказывать source целиком — ссылка лучше.
• Inline [Р]/[О]/[С] маркеры на entity/concept-страницах. Решения и contested/open вопросы → отдельная страница в topical folder со tags: [decision].
• Rewrite страницы без чтения CriticMarkup (теряет nuance Ильдара).
• Страница, не перечитанная месяц после создания — помечается как slop-кандидат в lint-е.
• Эмодзи (✅ ❌ 🟢 и т.п.), чеклисты внутри текста, разделители --- как визуальный шум.
• Копирование данных из Linear / Slack / PostHog — только референс.

Что ещё стоит зафиксировать (carry-over для CLAUDE.md)

• Lint policy — какие checks автоматизировать (broken wikilinks, stale frontmatter, отсутствие “Связано” / “Источники”, placeholder без content >30 дней).
• Naming conventions — kebab-case для файлов; русский ОК для domain (loinc.md, медицинские термины), английский для technical / decisions; consistency.
• Когда переименовывать страницу vs создавать новую — порог: если scope значимо изменился (например, loinc-unification-direction → loinc-unification-direction после shift в направлении).
• Placeholder pages — status: draft; минимум контекст + carry-overs где взять content; не оставлять пустыми. В первом абзаце тела явно отметить «эта страница — placeholder / тема в исследовании».
• Связь с meta/вопросы.md index — после миграции decision-страниц в topical folders этот index должен либо превратиться в “decisions index by status” (агрегация через /tags/decision), либо быть deprecated.