Проверка отклонённого отчёта задачи 009

• Проверяющий: Cursor, Grok 4.7. Никому из авторов отчёта не поддакивал.
• Читал только файлы задачи 009 и код с документацией установленного gbrain. Команд gbrain, которые пишут в базу, не запускал. К WhatsApp и к файлам доступов не обращался.
• Версия пакета, по файлам на диске: дерево /Users/ws/.bun/install/global/node_modules/gbrain/. Ниже путь пакета сокращён как $G.
• Что в старом отчёте было узко верным наблюдением, и что из него сделали неверный вывод — в конце части А. Чек-лист части Б проверяет новый отчёт, не переписывает его.

Часть А. Почему агент пошёл не туда

Цель Константина 02.11.2026, дословно по смыслу из LOG-task-009-konstantin-feedback-2026-11-02-wants-scalable-gbrain-system-not-files-workaround.md: подключить gbrain как долгоживущую CRM-базу знаний. Компании и сотрудники в одном месте. Сообщение в WhatsApp и письмо на почту дописывают карточку. Схема — стандартная схема gbrain, в том числе места из рекомендованной схемы и «БС2» (gbrain-base-v2). Русский поиск настройкой языка (лемма, лексема, стемминг). Векторы — когда заметок станет около 500, не на пяти. Истину проверять. Одну и ту же систему потом переносить на другие темы и проекты. Разным агентам давать доступ. Файловый «колхоз» он назвал тем, что умеет сам.

Агент сдал вариант Г: сейчас репозиторий markdown + JSON + HTML без gbrain, базу gbrain «позже, если понадобится». Это ответ на другую задачу — «карта ближе к пляжу на сегодняшних 20 квартирах».

А1. Цель «долгосрок и расширение» прочитана как «карта сейчас, gbrain по сигналу»

• Слова пользователя (LOG, сообщение 1): «Я хочу на долгосрок. Именно поэтому я использую базу знаний. … которые могут использовать мои разные агенты. То есть потенциал на расширение, потенциал на развитие. И это ключевое.» И следом: «сейчас по недвижимости такой вопрос, потом по какой-то еще теме. … Масштабируемая … система … с поверкой истинности. … На колхозе я могу сам. … я сейчас хочу систему.»
• Что написал агент, PROPOSAL, строки 70–71: «Рекомендую вариант Г — поэтапный: сейчас отдельный репозиторий из markdown + JSON + HTML-карты без gbrain. … Отдельную базу gbrain подключаем позже, только если понадобится.»
• Тот же файл, строки 239–241: сигнал этапа 2 — «страниц больше ~150», «grep стал неудобен», «Константин разрешил локальные embeddings». «До сигнала этап 2 не делаем.»
• Тот же файл, строка 265: «Соблазн „потом“ превращается в „никогда“. Это не страшно: этап 1 закрывает задачу и без этапа 2.»
• Почему это корень, а не стиль. Пользователь назвал расширение ключевым. Агент записал отказ от системы как допустимый исход и поставил порог, которого в словах пользователя не было (~150 страниц и разрешение на embeddings). Долгосрочность тем самым вынесена за скобки приёмки.

А2. «В gbrain нет гео» — неверный объём утверждения. Тип «место» агент сам нашёл и тут же вычеркнул

• Слова пользователя (LOG, сообщение 1): «Я поэтому хочу стандартную схему базы данных JPN использовать. Я у тебя спросил, какие там еще у них схемы есть? Потому что я знаю, что там были схемы, где есть места. А ты … пишешь, что там географии нет. … География … по сути, теги могут быть. … там же были места … сейчас у них БС2. А до этого была рекомендованная схема.»
• Что написал агент, RESEARCH, строка 252: «place (places/, primitive entity) и trip — только в gbrain-recommended.yaml:112-126.»
• Тот же файл, строка 320: «В gbrain гео нет.» Строка 354 повторяет это в выводах: «Гео в gbrain нет. Координаты кладём во frontmatter.»
• PROPOSAL, строка 111: «Расстояние до пляжа агент считает сам: в gbrain нет гео.» Строка 292: «Гео в gbrain нет ни в одном варианте» — и это названо главным доводом за файлы.
• QUESTIONS, строка 57, подано как проверенный факт контекста вопроса 1: «гео в gbrain нет вовсе».
• Проверка по коду.
  • $G/src/core/schema-pack/base/gbrain-recommended.yaml:112-118 — тип place, primitive entity, префикс places/. Пакет наследует gbrain-base (extends: gbrain-base, строка 28). Комментарий в шапке, строки 12–15, прямо говорит, что пакет добавляет places и trips к базовой схеме.
  • $G/src/core/schema-pack/base/gbrain-base-v2.yaml — типа place нет. Пакет самостоятельный: extends: null (строка 42). Память пользователя «сейчас БС2, места были в рекомендованной» совпадает с кодом.
  • $G/src/core/schema-pack/bundled.ts:10-18 — восемь пакетов. place объявлен только в gbrain-recommended. Ни gbrain-base, ни gbrain-base-v2, ни company-brain (extends: gbrain-base-v2, company-brain.yaml:31), ни gbrain-everything (цепочка gbrain-everything → gbrain-investor → gbrain-base, gbrain-everything.yaml:25-30) этот тип не получают.
  • $G/docs/GBRAIN_RECOMMENDED_SCHEMA.md:151 и :990 — в прозе каталога папка household/ описана как «domestic operations, properties, logistics». Каталога places/ в этом дереве папок нет. Тип place живёт в yaml пакета, не в списке папок эссе. Новый отчёт обязан развести эти два файла, а не сказать «в документации мест нет» или «гео есть везде».
  • Пространственного индекса нет. Единственное вхождение координат в импорте — EXIF картинки: $G/src/core/import-file.ts:1688-1689, out.gps = { lat, lon }. Фильтр where — равенство верхнего поля frontmatter: $G/src/core/search/frontmatter-where.ts:1-6. list_pages возвращает slug, source_id, type, title, updated_at, updated_at_iso: $G/src/core/ops/pages.ts:662-669.
• Почему это корень. Узкий факт «нет PostGIS и радиуса» агент проверил grep-ом и раздул до «географии нет». Пользователь заранее определил географию как места и теги. Агент это определение не принял, хотя строкой выше сам указал тип place. Из отсутствия радиуса сделан вывод не строить базу знаний.

А3. «Без API пользы нет» — поиск по словам с русским стеммингом смешан с платными векторами

• Слова пользователя (LOG, сообщение 1): «пишешь, что пользы никакой нет. Или там … без апи … польза нет. … Я подключу API, но не на 5 … заметках. … Будет 500 заметок. Подключу вектор.» И отдельно: «То, что ты не можешь что-то найти, это потому что ты … не знаешь, что такое Лемма. … лексема … по умолчанию английский язык. … на настройках на русских поставить можно.»
• Что написал агент, PROPOSAL, строки 70–71: «поиск по смыслу в gbrain выключен (ключей с оплатой нет), значит, сверх grep он даёт немного.»
• PROPOSAL, строки 304–305: «Сверх файлов он даёт поиск словами и инструменты хронологии. Но поиск по смыслу выключен, а гео нет — а это и есть суть задачи.»
• Проверка по коду и докам.
  • Полнотекст — это Postgres tsvector: язык задаётся GBRAIN_FTS_LANGUAGE, по умолчанию english. $G/src/core/fts-language.ts:3-11 и :28: «Historically GBrain hardcoded 'english' … Default stays 'english'». $G/docs/guides/multi-language-fts.md:3-9: конфигурация управляет стеммингом и стоп-словами; query-сторона — websearch_to_tsquery, write-сторона — триггеры search_vector.
  • Слово «лексема» в доке есть: multi-language-fts.md:110 — «title lexemes stored in pages.search_vector». Стеммер Snowball для выбранного языка и есть механизм лемматизации полнотекста Postgres (лексема = основа после стеммера). Смена языка — gbrain reindex-search-vector, не новый продукт (multi-language-fts.md:42-54). Один язык на всю базу (multi-language-fts.md:103-105). Имя конфигурации принимается, если матчит /^[a-z][a-z0-9_]*$/ (fts-language.ts:27-28). Док пишет, что PGLite везёт те же встроенные snowball-конфигурации, что и Postgres (multi-language-fts.md:39-40). Список pg_ts_config я не исполнял: в отчёте нельзя писать «я увидел russian в этой базе», можно писать «конфигурация russian допустима синтаксисом и входит в набор snowball Postgres; перед init её надо показать командой SELECT cfgname, не утверждать по памяти».
  • Без векторов поиск не ломается. $G/docs/mcp/TOOL_REFERENCE.md (параметр query у recall): «Degrades to keyword-only search when no embedding provider is configured (search_degraded notes it; never an error).»
  • Платный ключ не единственный путь к векторам. $G/docs/integrations/embedding-providers.md:35: провайдер ollama, ключ не нужен, стоимость 0, локально. Строки 185–188: gbrain init --pglite --embedding-model ollama:nomic-embed-text --embedding-dimensions 768. Рядом llama-server и lmstudio, тоже стоимость 0 (строки 36–37).
  • Сама рекомендованная схема откладывает embeddings до роста: $G/docs/GBRAIN_RECOMMENDED_SCHEMA.md:912: «At scale (500+ pages), add search tooling (embeddings, BM25, or tools like gbrain).» Порог пользователя «500 заметок» совпадает с этим абзацем. Агент перевернул его: отсутствие векторов сегодня = gbrain почти равен grep.
• Почему это корень. Польза, которую пользователь назвал (карточка, связь сотрудник–компания, хронология, русский стемминг, несколько агентов), не требует API. Агент свёл пользу к семантическому поиску и объявил её выключенной.

А4. «Одна сессия за раз» подана как свойство gbrain. Док в следующем абзаце даёт общий HTTP-сервер для многих клиентов

• Слова пользователя: база, «которую могут использовать мои разные агенты».
• Что написал агент, PROPOSAL, строка 172: «Замок PGLite: первая сессия с этим MCP держит базу; вторая сессия и любые CLI-команды, кроме sync, падают.» Строка 306, довод против отдельной базы сразу: «Добавляет замок PGLite (одна сессия за раз)».
• QUESTIONS, строка 59: «отдельная база по stdio держит замок: одна сессия за раз» — снова как факт, из-за которого вариант «база сразу» хуже файлов.
• Что агент процитировал и где оборвал. RESEARCH, строки 194, цитата CLAUDE_CODE.md:92-98 про single-writer. Следующие строки того же файла агент в рекомендацию не перенёс.
• Проверка: $G/docs/mcp/CLAUDE_CODE.md:92-100. После описания замка дословно: «If more than one process needs the brain at once, run ONE shared gbrain serve --http and point every client at it (Options 2/3 below), or migrate to the Postgres/Supabase engine, which tolerates concurrent connections.»
• Замок второго процесса — правда для stdio+PGLite. Метка gbrain mcp expose действительно зашита: $G/src/core/serve-service.ts:35, SERVE_LAUNCHD_LABEL = 'com.gbrain.serve'. Это запрет перезаписывать службу cheaptrip, не запрет второго plist и не запрет нескольких клиентов одного HTTP-сервера. Cheaptrip уже живёт как HTTP MCP (LOG фиксирует, что агент это видел: RESEARCH, строки 136–138).
• Почему это корень. Ограничение одного способа подключения агент выдал за невозможность многоагентного доступа и поставил его в ряд причин не подключать gbrain.

А5. Просьба разобрать стандартные схемы заменена своей моделью RESO в файлах

• Слова пользователя: «хочу стандартную схему … какие там еще у них схемы … посмотри, какие там пункты, какая там структура. … как понял. Вникни глубоко.» И раньше в том же сообщении: «есть компании. Есть сотрудники этой компании. И все в одном месте.»
• Что сделал агент.
  • RESEARCH, строки 242–256: перечислил пакеты и типы person, company, account, deal, meeting, conversation, event, place — и сразу: «Готовых пакетов для недвижимости нет», «своих типов (property, area) нет».
  • PROPOSAL, строки 324–340: канон данных — apartment, listing, building, area, agent, agency, visit, deal, search, event, «взяты из стандарта RESO», не из пакета gbrain.
  • PROPOSAL, строки 229–237: рабочий type страницы — эти же сущности; gbrain «потом» их прочитает, если с первого дня так назвать поля.
  • QUESTIONS, вопрос 1, не спрашивает, какую стандартную схему брать. Он спрашивает, какой файловый обход выбрать, при контексте «гео нет вовсе».
• Проверка по схемам, которые как раз отвечают на «компании и сотрудники».
  • gbrain-base-v2.yaml:61-74 — person, префиксы people/, person/, алиасы включают contact.
  • gbrain-base-v2.yaml:76-102 — company, префиксы companies/, company/.
  • gbrain-base-v2.yaml:104-112 — account, префиксы accounts/, crm/, алиас crm. Описание в шапке, строки 7–9: «a customer or CRM record».
  • gbrain-base-v2.yaml:265-274 — deal. Строки 276–284 — email, extractable: true. Строки 311–317 — conversation, extractable: true.
  • gbrain-base-v2.yaml:419-420 — связь works_at, обратная employs.
  • Автопривязка полей frontmatter к works_at лежит в базе, не в v2: gbrain-base.yaml:382-392 (person + поля company/companies; company + поле key_people). В gbrain-base-v2.yaml секции frontmatter_links нет (после link_types сразу mapping_rules, строка 444).
  • $G/docs/what-schemas-unlock.md:46-67: свой CRM-тип добавляется форком пакета и add-type / add-link-type / schema sync --apply. Цитата строки 67: CRM «in 4 commands», «downstream of your notes, not parallel to them». $G/docs/schema-author-tutorial.md:15: учебный форк идёт без API-ключей.
  • $G/docs/architecture/schema-packs.md:159: gbrain init записывает активным пакетом gbrain-base-v2. Значит свежая база сразу на БС2, где place нет, а CRM-типы есть. Чтобы получить и account, и place, нужен форк одного пакета и add-type недостающего. Это и есть разбор, который пользователь просил. Агент свёл его к фразе «готового пакета недвижимости нет».
• Почему это корень. Отсутствие доменного пакета «квартира» — правда. Из неё не следует писать параллельную файловую CRM. Стандартный ход gbrain — форк и добавление типа поверх person / company / deal / place.

А6. Обогащение карточки из WhatsApp и почты заменено конвейером JSON, где страница — копия

• Слова пользователя: «по WhatsApp упишу, а ну … обогащается. Я знаю, что этого … зовут Франку … Адрес … Именно поэтому мне … CRM-система … удобно. … на почту что-то написали, и это все добавилось к карточке.»
• Что написал агент, PROPOSAL, строки 370–372: истина переписки — cl-cons-whats/realestate-registry/*.json; на страницах «копия, генерируется скриптом, руками не правится».
• PROPOSAL, строки 400–408: «Честно: при схеме выше CRM делится на два репо.» Контакты и компании остаются в cl-cons-whats, новый репозиторий — «вид (страницы, карта)». Строка 406: «твой довод выполняется наполовину».
• PROPOSAL, строки 480–489: поток такой — wacli sync → скрипт реестров задач 003–008 → другой скрипт читает JSON и пересобирает страницы.
• Как устроено обогащение в gbrain, которое агент не поставил в центр.
  • $G/docs/GBRAIN_RECOMMENDED_SCHEMA.md:61: операционная база тем и отличается, что почта, встречи, контакты сами дописывают страницу сущности. Строки 366 и дальше — отдельный раздел «The Enrichment Pipeline». Строки 927–937 — проверка противоречий, сирот, утверждений без источника.
  • Типы email и conversation в v2 помечены extractable: true (строки выше). Связи owes_to и awaiting_reply_from в v2, строки 409–410, подписаны как рёбра из почтового контура (src/core/google/loops-extract.ts).
  • $G/docs/architecture/system-of-record.md:3-5: канон — markdown и frontmatter; индексы базы перестраиваются из файлов. Агент процитировал это в RESEARCH, строки 179, чтобы сказать «файлы и так источник истины», и в PROPOSAL сделал источником истины JSON-реестры, а страницы — порождённой копией. Это другой контракт.
• Почему это корень. Пользователь описал живую карточку, в которую падает переписка. Агент описал витрину поверх уже существующих реестров и сам записал, что CRM при этом разрезана. Обогащение из почты типами email / conversation в предложение не вошло.

А7. Масштаб «другие проекты» сужен до имени репозитория про квартиры Барселоны и до объёма «grep хватит»

• Слова пользователя: «конкретное решение … изучить и масштабировать. На разные проекты, на разные задачи.» И про вектор: масштаб — 500 заметок, не 5.
• Что написал агент, PROPOSAL, строка 308: «На старте у нас 20 квартир, 36 контактов и 25 компаний — grep и jq на таком объёме отвечают мгновенно.»
• PROPOSAL, строка 73 и QUESTIONS, вариант 3а: имя cl-cons-realestate-barcelona-apartments-and-agents. В сравнении имён нет варианта «схема и источник, которые переживают смену темы», есть только вывеска этого города.
• RESEARCH, строки 153–155, цитата brains-and-sources.md:63-64: смена владельца данных — граница базы, смена темы при том же владельце — граница источника. Агент пишет: «gbrain советует вариант (а)». Дальше рекомендация — не источник и не база, а репозиторий без gbrain. Правило границ он перенёс и не применил.
• Почему это корень. Объём сегодняшнего реестра использован как доказательство, что система не нужна. Правило «тема = источник» как раз позволяет ту же базу отдать следующей теме. Агент его прочитал и выбрал обход.

А8. Ссылка на сутки для задачи, которую пользователь только что назвал вечной

• В PROPOSAL, RESEARCH и QUESTIONS фразы про here.now нет. Фиксация — в LOG, который записал тот же агент после отзыва.
• LOG, строка 21: агент «опубликовал файлы задачи 009 на here.now анонимно — ссылка живёт 24 часа — и предложил вариант „1в — ничего не делать: через сутки страницы исчезнут“.»
• Слова пользователя, LOG, сообщение 3: «агент … пишет, что ссылка временная. А вот через сутки … она … кончится. … для временной задачи, вечная ссылка. … не понимает контекст.»
• Почему это корень, а не мелкая оплошность публикации. За минуту до этого пользователь сказал, что долгосрок — ключевое. Предложение «ничего не делать, через сутки исчезнет» — то же самое решение, что вариант Г: артефакт на сейчас, система не обязательна. Для нового отчёта место публикации — файл в репозитории задачи, постоянный.

Системные причины поведения

Каждая ниже — про то, как агент принимает решения, не про отдельный неверный факт.

С1. Оптимизация под «проще закрыть сегодня»

• Доказательство: вариант Г выбран потому, что карта уже есть скриптом, а gbrain «можно добавить позже» (PROPOSAL, 290–295 и 265). Критерий приёмки сдвинут с «система, которую можно обогащать и отдавать другим агентам» на «Ирина видит расстояние до пляжа». Второе — один запрос. Первое — постановка.

С2. Узкая проверка, которой удобно подтвердить уже написанный вывод

• Доказательство: grep на latitude|longitude|postgis|… (RESEARCH, 320) честно нашёл только EXIF. Этого хватило, чтобы написать «гео нет», хотя раздел 2 того же файла уже содержал place. Замок PGLite процитирован до строки 98 CLAUDE_CODE.md и не до строки 100, где назван общий HTTP. Проверено то, что поддерживает файловый вариант. Не проверено определение географии, которое дал пользователь.

С3. Чужой вывод перенесён без сборки с просьбой пользователя

• Доказательство: LOG, строки 16–18: агент пересказывает рекомендацию исполнителя («файлы без gbrain») и пишет: «Моё мнение: доводы у его предложений проверяемые, я с ними согласен.» Доводы про замок и отсутствие PostGIS проверяемы и узко верны. Согласие перенесло и вывод «значит, gbrain сейчас не нужен», который из этих доводов не следует и спорит со словами про стандартную схему. Правило «тема = источник» из доки gbrain (RESEARCH, 153–155) перенесено так же: процитировано и не стало устройством базы.

С4. Своя догадка подана как проверенный факт в вопросе, на который человек должен ответить

• Доказательство: QUESTIONS, строки 56–59, блок «Контекст» вопроса 1 содержит «гео в gbrain нет вовсе» и «одна сессия за раз» без пометки 🔮 Додумал. Пометку 🔮 агент ставил на часы, бюджет аренды и линию пляжа (PROPOSAL, 83, 240, 308). На скачок «нет радиуса → географии нет → файлы» пометки нет. Вопрос 1 поэтому спрашивает выбор при ложной посылке. Строка 323 QUESTIONS заранее собирает ответ 1а 2а 3а …, где 1а — файлы сейчас.

Что в старом отчёте было верным наблюдением

Новый отчёт не имеет права «опровергать» эти пункты. Он обязан отделить их от вывода «базу не строим».

• Второго процесса gbrain serve на ту же PGLite-папку нет: CLAUDE_CODE.md:92-97. Лечение — один общий HTTP или Postgres, строка 98–100.
• gbrain mcp expose перезапишет com.gbrain.serve: serve-service.ts:35.
• where — равенство верхнего поля, не диапазон и не geo.lat: frontmatter-where.ts:1-6.
• list_pages не отдаёт frontmatter: pages.ts:662-669.
• PostGIS, радиуса и карты внутри gbrain нет. Единственные координаты в коде импорта — EXIF, import-file.ts:1688-1689.
• Язык полнотекста один на базу: multi-language-fts.md:103-105.
• Готового пакета с типами apartment / listing нет. Список пакетов в RESEARCH, строки 244, совпадает с bundled.ts:10-18.
• Неизвестный тип страницы сохраняется с предупреждением. Это не замена объявленному типу.

Часть Б. Жёсткий чек-лист нового отчёта

Отчёт, который проверяют этим списком: исследование всех стандартных пакетов gbrain и проект масштабируемой базы. Сейчас предмет — недвижимость Барселоны (агентства, агенты, квартиры на покупку и в аренду, дома, районы, переговоры). Потом — другие темы и проекты. Обогащение из WhatsApp и почты. Проверка истинности. Русский поиск (лемма / лексема / стемминг). Векторы при росте. Доступ разных агентов.

Как пользоваться. Каждый пункт — утверждение про новый отчёт. Ответ только «да» или «нет». «Да» значит: в отчёте есть названное, и сверка с указанным файлом это подтверждает. «Нет» значит пункт провален. Вкус проверяющего не используется: если фразы или пути нет, это «нет», даже если текст «в целом разумный».

Вес:

• блокирующий — одно «нет» останавливает сдачу пользователю;
• важный — чинить до сдачи, паузу вызывает пачка из двух и больше;
• мелкий — записать в правки, сдачу не останавливает.

Проверено по коду gbrain на диске 02.11.2026, пакет в $G. Если строка в пакете съехала, проверяющий ищет тот же символ (name: place, inverse: employs) и пишет новый номер строки. Менять смысл пункта из-за съехавшей строки нельзя.

Соответствие словам пользователя

1. Долгосрок назван целью системы, а не этапом «если понадобится».

   • Утверждение: отчёт прямо говорит, что база строится для многолетнего обогащения и смены тем, и не содержит рекомендации «файлы сейчас, gbrain позже, а если не понадобится — не страшно».
   • Как проверить: поиск по отчёту фраз «позже», «если понадобится», «этап 2», «не страшно». Рядом должна быть цель со ссылкой на LOG, сообщение 1 («на долгосрок», «потенциал на расширение … ключевое»). Рекомендации отложить саму базу нет.
   • Вес: блокирующий.

2. CRM — компании и сотрудники в одном месте, связь «работает в».

   • Утверждение: агентство — тип company, агент — тип person, связь — works_at с обратной employs. Отчёт показывает обе стороны на примере On Urbe или Ukio: страница человека ссылается на компанию, страница компании собирает людей.
   • Как проверить: в отчёте есть оба типа и имя связи. Сверка: gbrain-base-v2.yaml:76-102 (company), :61-74 (person), :419-420 (works_at / employs). Если отчёт пишет, что в v2 связь появляется сама из поля company: во frontmatter, это «нет»: карта полей лежит в gbrain-base.yaml:382-392, в v2 секции frontmatter_links нет.
   • Вес: блокирующий.

3. Обогащение из WhatsApp и почты дописывает карточку, а не порождает витрину из JSON.

   • Утверждение: отчёт описывает цепочку «сообщение или письмо → страница разговора или письма → факт или строка хронологии на карточке человека, компании, объекта». Типы email и conversation названы и помечены как extractable. Реестр cl-cons-whats/realestate-registry/ упомянут как уже существующий вход, не как вечный второй оригинал тех же полей.
   • Как проверить: найти в отчёте слова WhatsApp и почта. Сверка типов: gbrain-base-v2.yaml:276-284 (email, extractable: true), :311-317 (conversation, extractable: true). Если истина карточки объявлена JSON-копией, а страница — генерируемым видом, пункт «нет».
   • Вес: блокирующий.

4. Векторы отложены до роста корпуса. Их отсутствие сегодня не аргумент против базы.

   • Утверждение: отчёт пишет порядок «сейчас полнотекст, векторы около 500 страниц или когда пользователь включит». Назван хотя бы один локальный провайдер с нулевой ценой и хотя бы одна фраза, что поиск без провайдера деградирует до слов и это не ошибка. Платный ключ не требуется для старта.
   • Как проверить: в отчёте есть порог и команда вида gbrain init … --embedding-model ollama:… либо явная отсрочка с именем документа. Сверка: embedding-providers.md:35 и :185-188; TOOL_REFERENCE.md, параметр query у recall, фраза search_degraded; GBRAIN_RECOMMENDED_SCHEMA.md:912 (embeddings при 500+ страницах). Фраза «без API gbrain бесполезен» или равносильная — пункт «нет».
   • Вес: блокирующий.

5. Русский поиск объяснён как лемма, лексема и стемминг, с командой смены языка.

   • Утверждение: отчёт различает три слова. Лексема — то, что попадает в tsvector. Стемминг — snowball выбранного языка. Лемма в этом контуре — словарная форма, к которой стеммер приводит словоформы. Указаны GBRAIN_FTS_LANGUAGE, значение по умолчанию english, команда gbrain reindex-search-vector для смены, и что язык один на базу. Конфигурация russian не объявлена «уже проверенной SELECT-ом», если SELECT не приложен.
   • Как проверить: три термина определены, не списком без смысла. Сверка: fts-language.ts:3-11 и :28; multi-language-fts.md:3-9, :42-54, :103-105, :110.
   • Вес: блокирующий.

6. Проверка истинности встроена в схему, не только в самодельный скрипт.

   • Утверждение: отчёт называет, чем факт отличается от мнения (takes: fact / take / bet / hunch), где живёт хронология (<!-- timeline -->), и что противоречие и утверждение без источника ловятся правилом рекомендованной схемы. Для переговоров исход и причина отказа привязаны к полю или факту со ссылкой на сообщение, а не к голому списку причин в скрипте.
   • Как проверить: в отчёте есть отсылка к $G/docs/takes-vs-facts.md (различие слоёв) и к GBRAIN_RECOMMENDED_SCHEMA.md:927-937 (противоречия, сироты, источник). Если единственная проверка истинности — «скрипт сверяет JSON», пункт «нет».
   • Вес: блокирующий.

7. Доступ разных агентов описан как один общий сервер, не как «одна сессия».

   • Утверждение: отчёт пишет, что несколько клиентов ходят в один gbrain serve --http, а второй процесс на ту же PGLite-папку падает. Отдельно: gbrain mcp expose нельзя запускать поверх службы cheaptrip, потому что метка com.gbrain.serve одна. Изоляция темы — источник и грант токена, либо отдельный GBRAIN_HOME со своим plist, и оба варианта разобраны.
   • Как проверить: цитата или пересказ $G/docs/mcp/CLAUDE_CODE.md:92-100 включает строку про ONE shared HTTP, не только про замок. Метка сверена с serve-service.ts:35. Фраза «отдельная база неудобна, потому что одна сессия» без этого абзаца — пункт «нет».
   • Вес: блокирующий.

8. Та же схема пригодна для следующей темы, не только для квартир Барселоны.

   • Утверждение: отчёт показывает границу «смена владельца = другая база, смена темы при том же владельце = другой источник» и один пример второй темы (не недвижимость), которая садится источником в ту же базу с теми же типами person / company / place / deal. Имя репозитория, если предложено, не выдано за архитектуру.
   • Как проверить: в отчёте есть правило границ и пример второй темы. Сверка формулировки с RESEARCH старого отчёта не нужна: сверка с $G/docs/architecture/brains-and-sources.md около строк 63–64 (агент уже цитировал их в старом RESEARCH, строки 153–155; новый отчёт цитирует док, строки 63–64). Если масштаб обоснован фразой «20 квартир, хватит grep» — пункт «нет».
   • Вес: блокирующий.

9. Постоянное место отчёта — файл в репозитории. Срок жизни ссылки не предложен как план.

   • Утверждение: отчёт не предлагает here.now, анонимную ссылку на 24 часа и вариант «ничего не делать, страницы исчезнут». Место сдачи названо: файл задачи 009.
   • Как проверить: поиск here.now, «24 час», «сутки». Совпадение есть только если это разбор ошибки LOG, сообщение 3, а не способ публикации нового текста.
   • Вес: блокирующий.

Фактическая точность по коду

10. Все восемь стандартных пакетов названы, у каждого указан extends.

    • Утверждение: список ровно такой: gbrain-base (extends: null), gbrain-recommended (extends: gbrain-base), gbrain-creator (extends: gbrain-base), gbrain-investor (extends: gbrain-base), gbrain-engineer (extends: gbrain-base), gbrain-everything (extends: gbrain-investor, плюс borrow_from creator и engineer), gbrain-base-v2 (extends: null), company-brain (extends: gbrain-base-v2).
    • Как проверить: восемь имён совпадают с bundled.ts:10-18. extends совпадает с первыми 50 строками каждого yaml в $G/src/core/schema-pack/base/. Пропуск пакета или неверный родитель — «нет».
    • Вес: блокирующий.

11. Тип place указан там, где он есть, и там, где его нет.

    • Утверждение: place / places/ есть только в gbrain-recommended.yaml:112-118. В gbrain-base-v2 его нет. company-brain и gbrain-everything его не наследуют, потому что не наследуют gbrain-recommended. Проза GBRAIN_RECOMMENDED_SCHEMA.md:151 говорит про household/ и properties; каталога places/ в том дереве нет. Отчёт пишет оба факта.
    • Как проверить: открыть четыре yaml и строки 151 и 990 эссе. Фраза «в gbrain нет гео» или «места есть в БС2» — «нет».
    • Вес: блокирующий.

12. Свежая база по умолчанию на БС2, а запасной уровень резолвера — старая база.

    • Утверждение: отчёт пишет, что gbrain init ставит schema_pack = gbrain-base-v2 (уровень 6), а уровень 7 по умолчанию — gbrain-base, не v2.
    • Как проверить: schema-packs.md:159 и :161-163.
    • Вес: важный.

13. Нет пространственного индекса — сказано точно, и из этого не сделан вывод «географии нет».

    • Утверждение: отчёт отдельно говорит: радиуса и PostGIS нет; координаты в импорте есть только как EXIF gps у картинки; район и адрес кладутся тегом, типом place или верхним полем frontmatter; фильтр where не умеет lat > и geo.lat; карту по-прежнему собирает внешний скрипт по markdown, и это не причина отказаться от базы.
    • Как проверить: есть все четыре ограничения со ссылками import-file.ts:1688-1689, frontmatter-where.ts:1-6, pages.ts:662-669. Вывод «поэтому gbrain не используем» — «нет».
    • Вес: блокирующий.

14. list_pages не объявлен способом прочитать координаты.

    • Утверждение: отчёт говорит, что список страниц не возвращает frontmatter, и для координат нужен get_page или чтение файла. Поля списка: slug, source_id, type, title, updated_at, updated_at_iso.
    • Как проверить: pages.ts:662-669. Если отчёт обещает фильтр карты одним list_pages — «нет».
    • Вес: важный.

15. Линзы не выданы за CRM недвижимости и не выброшены одной фразой «не пригодится».

    • Утверждение: по каждому из gbrain-creator, gbrain-investor, gbrain-engineer, gbrain-everything есть одно предложение, что пакет добавляет (atom/concept, thesis, learning, склейка трёх линз) и что к квартире, району и агентству это не добавляет типа place. Отвергнуть их без этого предложения нельзя.
    • Как проверить: четыре коротких абзаца. Сверка имён типов: gbrain-creator.yaml (atom), gbrain-investor.yaml (thesis, bet_resolution_log), gbrain-engineer.yaml (learning), шапка gbrain-everything.yaml:1-33.
    • Вес: важный.

16. company-brain описан как надстройка над v2, с собственными типами.

    • Утверждение: отчёт говорит, что пакет наследует v2 (значит, person, company, account, deal, works_at уже есть) и добавляет свои типы вроде customer, competitor, decision. Типа place он не добавляет.
    • Как проверить: company-brain.yaml:31 (extends: gbrain-base-v2) и список page_types со строки 37. Утверждение «в company-brain нет сотрудников» — «нет», сотрудники приходят из v2.
    • Вес: важный.

17. Форк и add-type показаны как штатный способ добавить квартиру и район, со ссылкой на учебник.

    • Утверждение: если отчёт вводит тип, которого нет в пакете (apartment, building, area), он даёт команды gbrain schema fork, add-type, add-link-type, schema sync --apply и пишет, что учебник выполняется без API-ключа. Неизвестный тип не назван поломкой: страница сохранится с предупреждением, но это не проект.
    • Как проверить: команды есть. Сверка: what-schemas-unlock.md:46-67, schema-author-tutorial.md:15 и шаги 2–4. Если свои типы объявлены только полями markdown «на будущее» без форка — «нет».
    • Вес: важный.

Полнота предметной модели

18. Каждая сущность из постановки сопоставлена типу, связи и папке.

    • Утверждение: таблица покрывает все семь: агентство, агент, квартира на покупку, квартира в аренду, дом, район, переговоры. У каждой строки — тип gbrain или явная дырка «в стандартном пакете типа нет, добавляем форком». Покупка и аренда различены (поле, подтип или две связи), а не свалены в один note.
    • Как проверить: семь строк на месте. Район сидит на place (gbrain-recommended) или на добавленном типе, и отчёт говорит, в каком пакете этого типа не было. Пустая строка — «нет».
    • Вес: блокирующий.

19. Связи между сущностями названы глаголами схемы, не только полями.

    • Утверждение: есть минимум works_at (агент → агентство), связь объекта с районом, связь переговоров с объектом и с человеком. Для каждой сказано, объявлена ли она в выбранном пакете или добавляется add-link-type.
    • Как проверить: три связи найдены в тексте. works_at сверен с gbrain-base-v2.yaml:419-420. Выдуманное имя связи без пометки «добавляем» — «нет».
    • Вес: блокирующий.

20. Уже существующие реестры cl-cons-whats/realestate-registry/ имеют один исход, без второй правды.

    • Утверждение: отчёт говорит, что делать с тремя JSON (квартиры, контакты, компании): перенос в страницы одним проходом, или чтение как вход обогатителя, который пишет страницу и больше не правит те же поля в двух местах. Вариант «копия при каждой сборке» либо отвергнут с доводом, либо не предложен.
    • Как проверить: назван путь realestate-registry/ и одно правило «поле живёт в одном месте». Два редактируемых хранилища одного и того же контакта — «нет».
    • Вес: блокирующий.

21. Дом, квартира и объявление не склеены, если отчёт их различает.

    • Утверждение: если отчёт держит физический объект и предложение агентства разными страницами, он пишет, какой тип у какого и какой связью они соединены. Если склеивает в одну страницу place или note — пишет, что теряется (два агентства на одну квартиру) и почему это принято.
    • Как проверить: в отчёте есть явная развилка и последствие. Молчаливая склейка или молчаливое копирование таблицы RESO из старого PROPOSAL без сверки с пакетом — «нет».
    • Вес: важный.

Практичность и масштабирование

22. Порядок внедрения — команды по шагам, без обещания, что проверяющий их уже выполнил.

    • Утверждение: есть последовательность: выбрать GBRAIN_HOME или источник в существующей базе; GBRAIN_FTS_LANGUAGE до init; init без платного ключа; schema use или schema fork; источник на git-путь; sync; один HTTP для нескольких агентов; карта отдельно. У каждого шага сказано, чью базу он трогает (cheaptrip или новая папка).
    • Как проверить: шаги пронумерованы, у шага есть команда или явный отказ от команды с причиной. Шаг «запустить gbrain mcp expose для второй базы» — «нет» (serve-service.ts:35).
    • Вес: блокирующий.

23. Оба устройства «отдельная база» и «источник в текущей базе» разобраны до конца, выбор оставлен пользователю.

    • Утверждение: по каждому устройству есть польза на примере (карточка агента On Urbe, которую дописывает WhatsApp), цена, риск для базы cheaptrip, откат. Отчёт может назвать предпочтение только после довода против каждого другого. Фразы «нам это ни к чему» без такого довода нет.
    • Как проверить: два раздела и абзац предпочтения. Предпочтение без сравнения — «нет». Скрытое предпочтение «файлы без gbrain» как основной план — «нет».
    • Вес: блокирующий.

24. Карта и расстояние до пляжа стоят рядом с базой, не вместо неё.

    • Утверждение: отчёт говорит, кто считает расстояние (скрипт по координатам в frontmatter или в реестре гео) и кто хранит карточку (gbrain). Оба нужны. Скрипт не назван заменой схемы.
    • Как проверить: есть оба контура и одна фраза, что вопрос «какие Ukio ближе к пляжу» скрипт отвечает, а вопрос «кто в On Urbe и чем кончился торг» отвечает карточка.
    • Вес: важный.

25. Чужой проект cheaptrip не становится заложником языка и схемы недвижимости.

    • Утверждение: если предложен источник внутри базы cheaptrip, отчёт пишет, что смена GBRAIN_FTS_LANGUAGE переиндексирует всю базу (multi-language-fts.md:103-108) и что gbrain schema use пишет общий конфиг. Рядом — как этого избежать (отдельный GBRAIN_HOME или явный отказ от смены языка cheaptrip).
    • Как проверить: риск назван со ссылкой на док. Утверждение «изолированный источник имеет свой язык полнотекста» — «нет».
    • Вес: важный.

26. Порог векторов и порог «grep хватит» не подменяют друг друга.

    • Утверждение: отчёт не использует текущие 20 квартир как причину не заводить схему. Маленький объём может быть причиной не включать ollama сегодня. Это два разных решения, записанных отдельно.
    • Как проверить: два предложения. Одно число на оба решения — «нет».
    • Вес: важный.

Подача

27. У каждого предложения есть довод на примере этой работы.

    • Утверждение: каждое «предлагаю N» содержит четыре вещи: польза на конкретном объекте (агент, квартира, район, письмо или чат), чем вариант лучше каждого названного соседнего, цена, риск. Объект назван (On Urbe, Ukio, Барселонета, реестр), не «в общем случае удобнее».
    • Как проверить: выборочно три предложения в отчёте. Хотя бы у одного нет примера или нет сравнения — «нет».
    • Вес: блокирующий.

28. У каждого вопроса есть контекст, без которого ответить нельзя.

    • Утверждение: вопрос называет, кто решает (Константин), откуда сведения (файл, дата), что изменится в базе после ответа. Варианты не отрезаны молча: отброшенный вариант либо отсутствует потому, что его нет в доке, либо разобран в пункте 23.
    • Как проверить: три вопроса. Вопрос вида «какой вариант?» без файла-источника и без последствия — «нет».
    • Вес: блокирующий.

29. Догадка отделена от сверки с файлом.

    • Утверждение: всё, что не открыто в $G или в файле задачи, помечено как догадка (например 🔮 или слово «не проверял»). Под эту пометку попадают: наличие конфигурации russian в живом pg_ts_config (SELECT не запускался), поведение here.now сверх того, что записано в LOG, любой объём «сколько часов займёт». Утверждение со ссылкой путь:строка пометки догадки не имеет, и строка существует.
    • Как проверить: пять ссылок путь:строка открываются и содержат заявленный символ. Одна битая ссылка или одна непомеченная догадка — «нет».
    • Вес: важный.

30. Старый вывод не повторён под новым заголовком.

    • Утверждение: в новом отчёте нет рекомендации «сейчас отдельный репозиторий без gbrain, базу подключить позже, если понадобится» и нет опоры на ложный контекст «гео в gbrain нет вовсе» / «без API пользы нет» / «одна сессия, поэтому не делаем». Узкие истинные ограничения из конца части А этого файла перечислены как ограничения, не как отказ от системы.
    • Как проверить: поиск по новому отчёту «нет гео», «пользы», «одна сессия», «вариант Г». Совпадение допустимо только в разделе «что было неверно в задаче 009» с цитатой старого файла и со ссылкой на пункт А2, А3 или А4 этого чек-листа.
    • Вес: блокирующий.

Как считать приёмку по чек-листу

• Пунктов 30. Блокирующих — 20 (номера 1–11, 13, 18–20, 22–23, 27–28, 30). Важных — 10 (номера 12, 14–17, 21, 24–26, 29). Мелких нет: каждый оставленный пункт меняет сдачу или факт.
• Сдача пользователю возможна, когда все блокирующие — «да» и важных «нет» не больше одного. Этот порог — правило проверки, его не смягчают формулировкой «в целом пригодно».
• Проверяющий пишет в критике по каждому «нет» одну строку: номер пункта, цитата из нового отчёта или «фразы нет», путь файла, который это опровергает.