Transferable rules про процесс ведения wiki / ingest / apply. Не про BloodGPT-domain (это по соответствующим pages).
Не дублирует:
- Architectural patterns BloodGPT — в
decisions/ - Mastra/FHIR/etc gotchas — в их vendor/entity pages
- Concrete decisions — в
decisions/ - Open вопросы про развитие wiki — в
meta/вопросы.md - Открытые вопросы по доменам — inline в
decisions/*.md(statusopen/contested)
Здесь — только how we work с wiki (применимо к любому проекту с такой методологией).
Scope discipline
Digest = session, Wiki = current state
Digest — снимок что произошло в той сессии: proposals, решения, эволюция мысли. Не править digest когда меняется текущая реальность артефактов.
Wiki — текущее состояние. Status frontmatter фиксирует “сейчас vs когда-то”.
Не путать: добавлять “не deployed” disclaimer в digest header — wrong scope; правильно — wiki page получает status: exploratory|research|... или явное упоминание текущего state.
Status taxonomy для page
Разные роли контента требуют разных status (расширение базового active|draft|superseded|deprecated):
active— deployed / committed / используется. Сейчас актуально.draft— в процессе написания, формируется.exploratory— design proposal: знаем что хотим (есть план, есть builder, есть rationale), но не deployed. Pending cutover. Например —fhir-clinical-impression,fhir-service-request(BG-1323 plan).research— exploration без convergence: ищем что вообще делать, может не получилось убедительно понять, может вернёмся, может нет. Не план, а поиск. Например —health-snapshot-vision(paradigm exploration),fhir-document-reference(carry-over note “хочется когда-то”).superseded/deprecated— заменено / больше не используется.
Различать exploratory (design ready, не deployed) от research (поиск без явного готового ответа) важно для honest read — что у нас есть план vs где мы ищем.
Lesson (Ильдар, 2026-04-26): «часть сессий — это такое research. когда мы что-то ищем, может что-то находим, может даже и нет. не получилось достаточно убедительно понять ситуацию, возможно вернёмся. это ещё не реализация, не ответ. бывает такое. надо относиться соответственно».
Wiki concept-centric, не session-centric
Один файл = один концепт (entity / decision / process). Сессия может contribute в N файлов; файл может accumulate findings из M сессий.
Anti-pattern: создавать “container.md для всего из сессии X”. Если в одной сессии обсуждались разные concepts — разные wiki-pages.
Создавать decision-страницу при первом сомнении, не ждать резолюшна
Триггер для нового файла в decisions/ — не «у меня есть финальный ответ». Триггер — «эта вещь цепляет / не уверен / какой-то вариант уже кажется менее привлекательным». Записывать сразу со status: draft. Текст обновляется по мере того как позиции уточняются → contested → active. Файл может неделями жить в draft — это валидно.
Lesson (Ильдар, 2026-05-08): «иногда сложно принять решение, но иногда чувствую, что какие-то вещи сомнительные — хорошая идея сразу создавать файлы под это и записывать туда. Какие-то варианты только кажутся менее привлекательными — уже этот факт озвучивать и записывать».
Почему важно: «сомнения» всегда конкретны в момент когда возникли, и легко записываются. «Решения» требуют converged thinking и часто откладываются. Если ждать решения — теряется именно то, что было самой живой частью обсуждения: какие альтернативы рассматривали, что в них оттолкнуло, какие именно сигналы пока недоступны. К моменту когда decision созревает, эта information уже выветрилась.
Concrete fallout (без этой практики): retro двух v2-5-fhir цепочек (1021e0fe + 6bfe41d1) показал что вопрос «4 enum-значения для edge-role хватит ли на baseline/preanalytical?» проговаривался 6+ раз за 9 дней, никогда не был записан, каждый раз дискуссия открывалась заново. Page создан только 2026-05-08 в retro-режиме, со ссылками на msg-номера в чейнах — это работает, но ст1оит дороже чем «записать когда впервые цепляет».
Pattern:
- Сомнение озвучено в чате → создаётся файл
decisions/<topic>.mdсоstatus: draftсразу - В файле —
## Контекст(что цепляет) +## Позиции(какие варианты и что в них уже не нравится, даже если не финально) +## Открытые вопросы(что нужно чтобы converge) - Не ждать convergence для записи. Convergence — это переход
draft→contested→active, не предусловие для существования файла.
Apply detail → commit messages, не log
Log — thin chronology (1-3 строки + pointers). “Что именно изменилось” — git log. Если в log entry повторяется содержимое commit message — это redundancy.
Verification
Quote-as-instruction vs quote-as-assertion
«не гадай, посмотри кто» — это императив (command Claude’у проверить код), не подтверждение архитектурной гипотезы. Не digest’ить такие quotes как findings.
Concrete случай: я зафиксировал “BloodTest.overallStatus выставляется отдельным overview-LLM” из quote где Ильдар command’ил проверить код. Реально поле — legacy unused.
Verify через source, не infer из mentions
Имя snake_case в коде проекта не обязательно = тип/enum определённого вида. Может быть prompt name, field в schema, path. Не presupposить.
Concrete случай: распространил выдуманную taxonomy через несколько digests как “DB enum”. Pull актуальной prompt schema из external system дал correct meaning.
Pattern: при упоминании имени из кода — verified через grep / Read actual file (или external system API) перед asserting.
Production reference output для validation portage
При portage из A в B parity на benchmark numbers ≠ parity на content. Nuances промптов / behavior видны только при side-by-side comparison generated output на одном concrete case (e.g., production reference output для valid тестового пациента).
worktree ≠ production
Builder в feature-worktree — не deployed. Verify через main worktree или actual API endpoint behaviour. Если внешняя API/schema не отражает изменения — design не deployed.
Claude/LLM не видит code drift между Python и TS — output testing обязателен
При портаже A→B parity на анализе кода через LLM ненадёжна. Claude может сказать «branches идентичны, разница только в промптах» — а реально различаются behavior на edge cases.
Concrete случай (FHIR-pipeline digest 2026-04-16, [Н6] Ильдар): «потратил несколько дней на то, чтобы как-то разницу уменьшить, потому что каждый раз он [Claude] говорит, что её нет. И только когда я запускал тест и смотрел, что в output, я дампил output и смотрел, в чём разница».
Pattern: при portage не доверять “diff says identical” от LLM. Запускать обе версии, дампить outputs, side-by-side сравнивать.
LLM-generated tests не покрывают unspecified scenarios
Если в постановке задачи для LLM что-то не упомянуть — LLM не будет знать про этот сценарий, напишет тест который проходит успешно, проблема останется незамеченной до ручной проверки.
Concrete случай (FDA digest 2026-04-23, [Н4] Влад): «если ты сам не проверишь и сам досконально все не опишешь и про что-то забудешь, то LLM не будет знать про то, что ты это забудешь. И будет думать и проверять, и говорить, что все хорошо, пока ты сам глазами не посмотришь».
Pattern: спецификация для LLM-test-generation должна явно перечислять edge cases. Проверка output руками — обязательна для critical flows. Confidence score / coverage analysis — кандидат на снижение risk (но не заменяет ручную verification на критических ветках).
Workflow
Перед me:session-digest — grep existing digests
Проверить ls digests/*${session_id}* перед запуском skill — может уже есть. Skill не делает этой проверки. Сэкономило бы duplicate work.
Не закрывать [О] слишком быстро
Tactical filter mechanism ≠ closure of architectural theme. Открывать обратно когда поняли что fix был частичным.
Concrete случай: Det/AI separation через meta.tag filter — caller-side mechanism, тема шире (pipeline / storage / API surfaces / governance). Поправил после Ильдара’s уточнения.
Background agent — изолированный tmux + branch
Параллельные tasks через background agent — новое окно tmux (не та же сессия) + isolated git branch. В той же session = chaos. Coordination через git/PR.
Memory updates
Memory — для cross-session knowledge, не одной задачи
В ~/.claude/projects/.../memory/ записывать только то что:
- Воспроизводится в будущих сессиях (preferences, проектные факты, feedback)
- Стабильно (не in-progress task state)
- Не выводится из current code state (не дублирует CLAUDE.md или git log)
Не записывать:
- Текущее состояние работы (это task tracking)
- Code patterns (читаются из current code)
- Recent commits (git log authoritative)
Память может стать stale
Перед действием на основе памяти — verify против current code / files. Если memory говорит “X exists at Y”, grep Y перед рекомендацией. “Memory says X” ≠ “X exists now”.
Calibration через диалог
Wiki самокорректируется через user feedback. Calibration commits — часть compounding: ошибки находятся, исправляются с явным record (lesson записан), не silent revert.
Pattern: когда user корректирует — fix + сохранить причину ошибки (не только результат). Causes drive future avoidance больше чем corrections.