Unified Agent Rules

Прежде всего

Перед любой работой с базой знаний лаборатории прочитай ЗАЧЕМ.md в корне этого репозитория. Там записано, что мы строим и почему, словами владельца. Без этого агент чинит форму вместо сути и повторяет то, что уже было сказано много раз.

Core

• The user is an LLM researcher who mostly works in existing repos, research code, and third-party libraries. Do not assume greenfield work.
• Be concise. No filler. If uncertain, say so. If a task is ambiguous, ask one focused question.
• Respond in the user's language unless asked otherwise. Use English for code, commands, file names, formulas, comments, and technical terms unless the user explicitly asks otherwise. Academic prose defaults to English.

Memory And Tools

• On the first substantial turn, load context with project_context or MemPalace search.
• Before answering about past decisions, experiments, bugs, prior work, or project history, search MemPalace first.
• Prefer project_context, memory_search, memory_save, and memory_diary when available.
• For web search or URLs, use web-search-prime_web_search_prime and/or web-reader_webReader, not model memory.
• Save important findings, quotes, decisions, and durable code context to project memory. Write a diary entry after meaningful tasks.
• Load and use a matching skill whenever one clearly applies.
• Prefer a project wing when available. The legacy archive wing is conversations.

Changes

• Витрина lab-atlas удалена 15-10-2026 вместе со своей службой; её план выпуска лежит в архиве на машине владельца. Работы по ней нет.
• Lab Atlas item 7 (c84ded2) means a team of people for testing, not a CLI command. The owner explicitly deferred it on 2026-09-08: no agent may take it until the owner resumes it. scripts/lab_check.py, created for it from a misunderstanding, was removed 19-10-2026 at the owner's word.
• Read and understand relevant code first. Explain your understanding in 2 to 3 sentences before changing it.
• If a change touches more than 3 files or has architectural impact, outline the plan and wait for confirmation.
• Use focused checks that establish the requested behavior. Local tests with disposable fixtures and no production access may be run and repaired within scope without repeated approval. Broaden testing when a failure, changed dependency, or unresolved risk warrants it.
• Do not refactor outside scope or add new dependencies without asking.
• Match surrounding style exactly and preserve the existing architecture.
• After changes, say exactly what changed and why. State uncertainty explicitly.

Writing

• Write formulas in LaTeX, using inline $x$ and display $$\mathcal{L} = \ldots$$ when appropriate.
• When the user asks to write, rewrite, edit, polish, or humanize prose, use writing-anti-ai when available. Apply the same constraints automatically to .tex writing.
• In new academic prose: no em dashes, no semicolons, no \emph{}, \textbf{}, or \textit{} unless requested, no promotional phrasing, and avoid AI filler, inflated AI vocabulary, and formulaic discourse linkers unless they are genuinely needed.
• When reading a paper or article, first look for local .tex sources before using PDFs or external extraction.

Obsidian And Local Workflow

• Obsidian vault root: ~/brainlab — это и есть дерево лаборатории.
• When the user says "create/make/write an md file" or "md файл", ALWAYS write it to Obsidian (correct vault path), not to the local filesystem — unless the user explicitly says otherwise.
• Treat .md files as Obsidian project files by default unless the user explicitly says otherwise.
• Prefer filesystem-first workflows. Do not require Obsidian MCP when direct file work is enough.
• Maintain durable notes only when the task materially changes research state. Заметка лежит в самом проекте (<работа>/notes/), сопоставления путей больше нет.
• In human-facing Obsidian notes, use DD-MM-YYYY for dates by default.
• Check ~/brainlab/servers/README.md before choosing remote GPU indices; server changes go there (brainlab/servers).
• Route tasks by scope. Personal reminders and private self-management use Operon file-tasks (personal/operon/Tasks/<title>.md) with a flat project tag, never parentTask. Shared project work, assignees, deadlines and milestones are issues in the work's own GitLab repository — the session-start hook reads them back. Never mirror one writable task in both places and never create ad-hoc Задачи.md files. Use call-notes to classify meeting actions before writing.
• Route hypotheses by visibility. Private and unfinished hypotheses stay in the work's notes/. Shared hypotheses, experiments, evidence, and proposed decisions go into the work's repository as a pull request: the pull request IS the preview, and the human merging it IS the confirmation. Do not ask for permission before proposing and do not print a preview in chat instead. A completed task is not evidence that a hypothesis is confirmed.
• Ask Lab is a local-agent workflow. Read research context from the local clone of the work (grep, git log), not from a server. Task state comes from the work's GitLab issues. Do not implement or assume a website chat. Read-only questions must not cause writes; include shared IDs and links, never local filesystem paths.
• База знания — это дерево git-клонов ~/brainlab, и работай с ним как с любым репозиторием. Это GitHub для идей: вся лаборатория лежит у каждого локально ровно так, как в GitLab — работа в ~/brainlab/<направление>/<тема>/<работа>, внутри claims/<H-код>/ страницы утверждения, прогонов, серий и выкладок. Собирает и обновляет дерево lab sync, одну работу кладёт на место lab here <работа>. Начало сессии само делает git pull и печатает, что изменилось и какие pull request открыты. Дальше обычный порядок: ветка (claim/<H-код> для правки одного утверждения), правка файлов, git commit -F -, git push — клон из дерева настроен так, что push сам открывает предложение и назначает его ведущему работы из строки «Ведут» её README. lab checks — что сказали проверки. Форму страницы выбираешь сам, смотри соседние файлы. Слить может только человек, и слияние — это и есть запись в базу. Второй клон «куда-нибудь себе» не заводи: клон в <папка проекта>/lab-base (lab here <работа> --рядом) — только для машины без дерева. Знание живёт только в git; служб, баз и порталов поверх него нет. Единственная надстройка — поиск lab search "запрос" (он же страница /-/lab-search в GitLab): индекс по смыслу и по словам, собранный из тех же файлов, своей записи у него нет, и показывает он только то, что человеку открыто в GitLab. Если агент заговорил про create_hypothesis, record_evidence, define_term или адрес 127.0.0.1:8001 — он читает мёртвый файл, и этот файл надо удалить.
• Куда писать — решаешь ты, и клон адреса уже лежит в дереве. Адрес выбираешь по таблице в ~/.claude/rules/lab.md и пишешь в его клон в ~/brainlab: brainlab/journal — это ~/brainlab/journal, ops/grants/a2-pro — ~/brainlab/ops/grants/a2-pro. Нет его в дереве — lab sync. Сделал — скажи одной строкой, куда положил, и не спрашивай разрешения заранее. Спрашивать стоит в одном случае: ни одно место не подходит. Тогда назови, что получилось, и предложи, куда это положить, вплоть до отдельного репозитория. Подсказка хука это совет: следовать ей буквально ты не обязан. Два соседних провала показывают оба края: 07-10-2026 агент сутки отвечал «записывать нечего», потому что его инженерная работа не подходила ни под один научный адрес, а 08-10-2026 владелец сказал «пусть он сделает и сообщит мне об этом, заебало им отвечать». Ненаписанное не существует, но и записанное не туда ищут потом месяцами.
• Разрешения спрашивай в трёх случаях, и только в них: запись про чужой проект; она публикует то, что пользователь назвал приватным; она меняет вывод, сделанный другим человеком. Тогда покажи проект, объект, владельца и источник и дождись явного согласия. Прежнее правило требовало согласия на каждую запись, и 10-09-2026 живая проверка показала, чем это кончилось: агент разобрал результаты, сформулировал три проверяемых утверждения и не записал ни одного.
• Сначала имя, потом запись. Если в записи есть внутреннее имя — имя прогона, метода, метрики, внутреннее сокращение, всё, что человек со стороны не расшифрует, — сначала запиши его в словарь темы (literature/glossary/ клона литературы темы), а потом пиши запись. Жаргон работы остаётся у работы. Запись без определения нечитаема уже через месяц, и поправить её будет некому.
• Никогда не выгружай локальный путь Obsidian, путь репозитория или сырую приватную заметку. Никогда не расширяй права после отказа и не показывай ключи.
• Соглашения по хранилищу лежат в самом хранилище. Перед созданием статьи, проекта или папки, а также перед правкой иконок, цветов, досок Operon и стартовой раскладки читать handbook/tools/obsidian.md. Там же правила про смайлики и цвета папок. Держать эти правила в контексте не нужно: они меняются редко, читать по факту работы.

HARD ROUTING RULE (applies to ALL agents, ALL sessions)

• Хранилище Obsidian — это само дерево лаборатории ~/brainlab. Отдельных корней ~/Papers, ~/Projects и ~/Staff больше нет: 16-10-2026 всё перенесено, и писать по этим путям нельзя — сторож no-old-paths.py отказывает на запись в них.

• Заметка проекта лежит В САМОМ ПРОЕКТЕ, а не в параллельном дереве:

  где работаешь	куда заметка
  ~/brainlab/<направление>/<тема>/<работа>	<работа>/notes/ (дневник — daily/, логи — runs/)
  ~/brainlab/agents/<репозиторий>	<репозиторий>/notes/
  операционка, личное, рецензии	своя же папка

• notes/, daily/, runs/ закрыты от git в каждом клоне, поэтому заметка остаётся на машине; в GitLab едут claims/, paper/, code/, socials/, calls/.
• Файла сопоставления ~/.claude/obsidian-projects.json БОЛЬШЕ НЕТ. Путь виден из самого пути, и угадывать тему не надо.

Shell And Completion

• If a command needs brew and Homebrew is not on PATH, use export PATH=/opt/homebrew/bin:$PATH first.
• End meaningful tasks with a short operational summary: what changed, which files changed, current status, and natural next steps.

Literature & Citation Rules

Finding citations (applies to all agents, all sessions)

Before citing any paper in Related Work, background, or inline references:

1. Search the lab literature (~/brainlab/<направление>/<тема>/literature/, файл назван статьёй) and the work's README.
2. The lab base is the same tree: each theme's literature folder in ~/brainlab is a clone of its GitLab repository, one page per paper named by the paper's title (not by citation_key). A theme missing from the tree is brought by lab sync. (lab_pull.py and search_lab are gone since 19-10-2026.)
3. If found: copy the exact citation_key from that paper's ## BibTeX block, append the bibtex entry to the project's references.bib, then write the \cite{key}.
4. If not found → follow When the paper is not in the library below. A full ingest is not the default.

Library structure

Literature lives in the lab GitLab, one repository per theme: brainlab/<direction>/<theme>/literature, cloned into ~/brainlab/<direction>/<theme>/literature/. One page per paper, named by the paper's title; the citation key is in its ## BibTeX block.

When the paper is not in the library: verified citation, no ingest

Владелец 02-11-2026: «не надо прям все статьи разбирать… достаточно описания и уверенности что агент ставит нужный бибтех и по смыслу это то». A full ingest per \cite costs a page, figures and a push for a paper the work mentions once.

For an ordinary \cite (related work, background, a dataset, a tool), do this instead:

1. Take the BibTeX from a primary source: the venue's proceedings page (PMLR, NeurIPS, ICLR, ACL Anthology, CVF), dblp, Crossref by DOI, or arXiv. If the paper is published, cite the published version, not the arXiv one.
2. Check title, every author, year and venue against that source. The real failures are mixed entries: 02-11-2026 one entry carried the authors of Gilmer et al. with the title and arXiv id of a different paper, and two more had a wrong author. Model memory is not a source.
3. Read the abstract (and the relevant section if the claim is specific) and confirm the paper supports the sentence it is attached to.
4. Key in the lab format below; keep a url field pointing to the source.
5. Report each new citation in one line: what the paper is, what it supports in the text, where the BibTeX came from.

When to run a full paper-ingest

Only in three cases: the owner asks for it; the paper is central to the work (the method it builds on, the main baseline, a candidate for the key-papers list in the work's README); or the paper comes from the reading queue (want-2-read). Run it into the literature of the work's own theme, on Sonnet (~/.claude/rules/agents.md). If no theme fits the paper, say so and propose one; a theme is a GitLab group and is created by the owner.

Citation key format

Always take citation_key from the paper's .md BibTeX block. Never invent keys. Format: {lastname}{year}{firstword} (generated by bibtex_fetch.py).