🏠 Отдельная база знаний по недвижимости — предложение

• Решения из этого файла принимает Константин — вопросы с моими предложениями: QUESTIONS-task-009-decisions-needed-before-building-realestate-knowledge-base.md.
• Прототип рядом, в этой же папке:
  • карта — EXAMPLE-task-009-realestate-map-ukio-rentals-and-barceloneta-purchase-candidates.html;
  • куда попадает каждый объект и факт — EXAMPLE-task-009-where-each-object-goes-routing-table.md;
  • пять страниц-примеров по модели данных из раздела 2:
    • квартира на покупку (apartment) — EXAMPLE-task-009-property-for-purchase-carrer-dels-pescadors-on-urbe.md;
    • объявление Ukio в аренду (listing) — EXAMPLE-task-009-rental-listing-ukio-anfa-907-born-spring-2027.md;
    • район (area) — EXAMPLE-task-009-area-la-barceloneta-barri-with-nearby-objects.md;
    • агентство On Urbe с агентами (agency) — EXAMPLE-task-009-agency-on-urbe-grup-barceloneta-with-agents-and-negotiation-preferences.md;
    • переговоры, четыре случая (deal) — EXAMPLE-task-009-negotiations-successful-and-unsuccessful-examples.md.
• Модель данных (разделы 2–4) — каноническая: таблица маршрутов, страницы-примеры и карта приведены к ней. При расхождении прав этот файл.
• Факты о gbrain — только из RESEARCH-task-009-gbrain-options-to-separate-realestate-base-page-types-and-geo.md (проверено по коду gbrain 0.60.545.0). Сам gbrain не запускался.
• Непроверенное помечено 🔮 Додумал:.

⚡ Коротко

• Рекомендую вариант Г — поэтапный: сейчас отдельный репозиторий из markdown + JSON + HTML-карты без gbrain. Страницы сразу пишутся в формате, который gbrain понимает. Отдельную базу gbrain подключаем позже, только если понадобится.
• Почему: главное требование — гео. Его gbrain не умеет вовсе, карту и фильтры в любом варианте строит наш скрипт по файлам. А поиск по смыслу в gbrain выключен (ключей с оплатой нет), значит, сверх grep он даёт немного.
• Истина одна: то, что сказано в переписке WhatsApp, остаётся в реестрах cl-cons-whats/realestate-registry/. Новый репозиторий их только читает. Свои реестры у него — для того, чего в переписке нет: координаты, дом, район, Ukio, решения, критерии поиска.
• Имя репозитория (предложение): cl-cons-realestate-barcelona-apartments-and-agents.

1️⃣ Варианты отделения

Общий пример для всех вариантов

• Ирина спрашивает: «Какие квартиры Ukio ближе к пляжу?»
• Данные одни и те же во всех вариантах — 5 квартир Ukio на весну 2027 и TAKSIM на Барселонете как ориентир (RESEARCH-task-009-ukio-barcelona-furnished-rentals-for-spring-2027-candidates.md).
• Правильный ответ. Расстояние — по прямой до линии пляжа Барселонеты, как на карте; 🔮 линия нарисована на глаз, пляжи Poblenou не учтены.

• Чем варианты отличаются — тем, как агент добирается до этого ответа и сколько это стоит в поддержке.

Вариант А — изолированный источник в существующей базе gbrain (cheaptrip)

Что это и как работает

• В базе cheaptrip (~/.gbrain/) заводится ещё один источник realestate с флагом federated=false.
• Такой источник не попадает в общий поиск. Его видно, только если назвать явно (multi-source-brains.md:110-111).
• Страницы — markdown в отдельном git-репозитории. База лишь индексирует их.
• Агенты недвижимости ходят через тот же сервер com.gbrain.serve, но со своим токеном: грант только на realestate.

Пример — вопрос Ирины

1. Агент в проекте недвижимости вызывает MCP gbrain (свой токен) — list_pages {type: listing, where: {agency: ukio}}.
   • where открыт только на полной поверхности, через request_tools.
   • where — только равенство. 🔮 По списку purposes ([rent_for_us]) такой фильтр, вероятно, не отберёт — отбор по назначению делает агент.
2. list_pages не отдаёт frontmatter (ops/pages.ts). Чтобы узнать координаты, агент вызывает get_page по каждой из 6 страниц.
3. Расстояние до пляжа агент считает сам: в gbrain нет гео.
4. Ответ — таблица в чате. Карту всё равно строит отдельный скрипт по файлам.

Польза

• Ноль новых процессов: работает уже запущенный сервер.
• Есть инструменты хронологии (add_timeline_entry, get_timeline) и фильтр where по равенству полей.

Что поставить и поддерживать

• Git-репозиторий недвижимости с закоммиченными файлами — обязательное условие для источника с --path.
• Регистрация источника — через живой сервер (sources_add, права sources_admin) или CLI. CLI, 🔮 вероятно, потребует короткой остановки службы cheaptrip (pglite_busy).
• Отдельный токен: первым в гранте должен стоять realestate, иначе агенты будут писать в default базы cheaptrip.
• Запись MCP в .mcp.json проекта недвижимости.
• После каждой правки файлов — gbrain sync --source realestate.

Риски

• База физически общая с cheaptrip. Ошибка в гранте или случайный federate — и страницы недвижимости видны агентам cheaptrip.
• Язык полнотекстового поиска один на всю базу. Сейчас он english: «Давид» и «Давида» не сводятся. Переключить на russian — значит переиндексировать и cheaptrip.
• Сервер gbrain записан в ~/.claude.json на уровне пользователя — его видят агенты всех проектов. Изоляция держится только на гранте токена.
• Данные, которые живут только в базе (remember, ревизии), попадают в общий бэкап cheaptrip — отдельно их не вынуть.
• Поиск по смыслу выключен: ключей с оплатой Константин не разрешает.
• Frontmatter поиском не ищется: что должно находиться словами, придётся дублировать в тексте.

Как откатить

• gbrain sources archive realestate (мягко) или sources remove.
• Отозвать токен, убрать запись MCP. Репозиторий с markdown остаётся целым.

Вариант Б — отдельная база gbrain (свой GBRAIN_HOME, MCP по stdio)

Что это и как работает

• Своя база PGLite в своей папке. GBRAIN_HOME — родительская папка, .gbrain gbrain дописывает сам (config.ts:1962-1974).
• MCP подключается только в .mcp.json проекта недвижимости. Claude Code сам запускает gbrain serve на время сессии — постоянного процесса нет.
• Агенты других проектов эту базу не видят: у MCP-операций нет параметра выбора базы.
• Подвариант «mount» (gbrain mounts add) — та же отдельная база плюс запись в ~/.gbrain/mounts.json cheaptrip. Даёт только удобство CLI. Часть команд (mounts sync, enable) ещё не выпущена. Не беру.

Пример — вопрос Ирины

• Шаги те же, что в А: list_pages с where → get_page по каждой странице за координатами → расстояние считает агент → таблица в чате.
• Отличие — поиск словами можно сразу настроить на русский язык (GBRAIN_FTS_LANGUAGE=russian при init).
• Если в это время открыть вторую сессию Claude с этим MCP, вторая упадёт на замке PGLite: базу держит тот gbrain serve, что запустился первым (docs/mcp/CLAUDE_CODE.md:92-102 в пакете gbrain).

Польза

• Полная отдельность: своя база, свой язык поиска, своя схема типов страниц.
• База cheaptrip и её сервер не затрагиваются.
• Хронология, факты, связи «объект → агент», get_backlinks по району.

Что поставить и поддерживать

• 🔮 Порядок собран из документации, сам не запускал: папка GBRAIN_HOME → gbrain init --pglite --no-embedding с GBRAIN_FTS_LANGUAGE=russian → sources add realestate --path <repo> → sync → запись MCP в проект.
• После каждой правки файлов — gbrain sync.
• Миграции базы при обновлении gbrain.
• Свой бэкап базы — gbrain backup create под этим GBRAIN_HOME. Markdown при этом в git.
• По желанию — свой тип страниц property/area: форк схемы, add-type, schema sync --apply. Без форка страница всё равно сохранится, но с предупреждением page_type_undeclared.

Риски

• Замок PGLite: первая сессия с этим MCP держит базу; вторая сессия и любые CLI-команды, кроме sync, падают.
• Две разные ловушки — не путать:
  • нельзя ставить второй HTTP-сервер командой gbrain mcp expose: метка службы com.gbrain.serve зашита в код (src/core/serve-service.ts:35), команда перезапишет службу cheaptrip. Для постоянного сервера — только свой plist вручную;
  • нельзя запускать скилл gstack setup-gbrain: он регистрирует MCP на уровне пользователя (claude mcp add --scope user … gbrain) под тем же именем gbrain, что уже занято сервером cheaptrip в ~/.claude.json. Службу он не трогает — конфликт в записи MCP.
• Гео нет и здесь: where — только равенство, без диапазонов и вложенных полей (geo.lat); list_pages не отдаёт frontmatter.
• Поиск по смыслу выключен — как в А.

Как откатить

• Удалить запись MCP из проекта и папку GBRAIN_HOME.
• База cheaptrip не затронута, репозиторий с markdown остаётся.

Вариант В — без gbrain: markdown + JSON в git + HTML-карта

Что это и как работает

• Отдельный git-репозиторий:
  • JSON-реестры — для фактов в полях: адрес, цена, координаты, статус;
  • markdown-страницы — для смысла: впечатления, торг, открытые вопросы;
  • скрипты на Python — геокодер с кэшем, расчёт района, сборка страниц и карты, проверка ссылок.
• Карта — один HTML-файл, Leaflet 1.9.4 и встроенные данные, как прототип координатора.
• Агент ищет grep / rg по страницам и jq / python3 по JSON.

Пример — вопрос Ирины

1. Агент запускает скрипт, 🔮 условное имя SCRIPT-realestate-list-listings-sorted-by-distance-to-beach.py --agency ukio --purposes rent_for_us. Или читает один JSON-реестр объявлений и считает сам.
2. Ответ — таблица выше плюс ссылка на карту с фильтром «Ukio / аренда для нас».
3. Ирина открывает карту, видит точки и пляж, сравнивает соседние квартиры.

Польза

• Гео работает полностью: координаты, район, расстояние, диапазон цены — всё в одном JSON, фильтры прямо на карте.
• Ни одного процесса, ни замков, ни токенов, ни миграций. Нечему сломаться между сессиями.
• Читается человеком без программ. Бэкап — git push.
• Тот же способ, которым уже живут realestate-registry/ и соседний репозиторий сабаренды.

Что поставить и поддерживать

• Python 3 (уже есть). Ничего ставить не нужно.
• 4–5 скриптов: геокодирование, район, страницы, карта, проверка. 🔮 Это 300–600 строк, один раз.
• Правило «один факт — одно место» и проверка в скрипте (раздел 2).

Риски

• Нет готовых инструментов хронологии и связей: их делаем сами — порядок строк, ссылки по ID, проверка ссылок.
• Поиск словами — только grep, без нормализации форм слов. 🔮 На десятках страниц это не мешает.
• Если страницы писать в произвольном формате, позже подключить gbrain будет дороже: придётся переписывать шапки. Главное место — поле type (подробно — в варианте Г).

Как откатить

• Удалить репозиторий. cl-cons-whats и cheaptrip не затронуты.

Вариант Г — поэтапный: В сейчас, Б потом, если понадобится (✅ рекомендую)

Что это и как работает

• Этап 1 — сейчас: всё как в варианте В. Но страницы сразу пишутся в формате, который gbrain прочтёт без переделки:
  • OKF-поле type = тип сущности (apartment, listing, building, area, agent, agency, deal, search). Почему это важно:
    • gbrain берёт тип страницы сначала из type во frontmatter, и только если его нет — из схемы или из папки (src/core/markdown.ts:457: explicitType || inferred?.type || inferType(filePath));
    • OKF тоже требует поле type, но значения не регистрирует — допускает любое описательное. Значит, type: apartment годится обоим, конфликта нет;
    • отдельное поле entity_type в рабочей базе не нужно.
  • у страниц-примеров EXAMPLE-task-009-*.md сейчас type: Example Page и отдельное entity_type — только потому, что это примеры. В рабочей базе так писать нельзя: gbrain принял бы «Example Page» за тип страницы.
  • доменные поля во frontmatter: entity_id, purposes (список), lat/lon, geo_precision, ссылки по ID;
  • разделы «Сводка», «Факты» со ссылкой на источник, ручная зона с ## Open Threads (разметка — раздел 2);
  • хронология ниже <!-- timeline --> строками - **YYYY-MM-DD** | Источник — Суть;
  • папки страниц совпадают с префиксами gbrain: people/, companies/, deals/ и свои apartments/, buildings/, areas/;
  • всё, что должно находиться поиском, дублируется в тексте: frontmatter gbrain не ищет.
• Этап 2 — только по сигналу: отдельная база gbrain по варианту Б поверх тех же файлов. Страницы не переписываются, если с первого дня соблюдено правило про type.
  • 🔮 Сигналы: страниц больше ~150, и grep стал неудобен; нужен общий поиск по хронологии всех переговоров; Константин разрешил локальные embeddings (Ollama).
  • До сигнала этап 2 не делаем.

Пример — вопрос Ирины

• На этапе 1 — как в варианте В.
• На этапе 2 агент получает ещё get_timeline и get_backlinks areas/la-barceloneta. Карта и расстояния по-прежнему из скрипта.

Польза

• Всё, что даёт В: гео, ноль процессов, простота.
• Дверь в gbrain открыта. Честная цена перехода:
  • init и sources add по готовым файлам;
  • объявить свои типы (apartment, area…) в схеме — add-type, schema sync --apply; без этого страницы сохранятся, но с предупреждением page_type_undeclared;
  • страницы не переписываются — при условии, что в type с первого дня стоит тип сущности.

Что поставить и поддерживать

• Как в В.
• Плюс дисциплина формата: проверка в скрипте сверяет type по словарю сущностей, разделы, маркеры ручной зоны, разделитель <!-- timeline --> и формат строк хронологии.

Риски

• Формат страниц может разойтись с будущей версией gbrain. Это 🔮 небольшой риск: markdown остаётся источником истины (system-of-record.md), а gbrain принимает незнакомый тип страницы с предупреждением.
• Если кто-то поставит в type не тип сущности (например, «Example Page» или «Registry»), gbrain разложит страницы по неверным типам. Ловит проверка в скрипте.
• Соблазн «потом» превращается в «никогда». Это не страшно: этап 1 закрывает задачу и без этапа 2.

Как откатить

• Этап 1 — удалить репозиторий.
• Этап 2 — как в Б: удалить запись MCP и папку GBRAIN_HOME.

📊 Сравнение

🧭 Моё мнение — вариант Г

Главный довод:

• Всё ценное в задаче требует гео: карта, район, «ближе к пляжу», «несколько квартир в одном районе».
• Гео в gbrain нет ни в одном варианте (RESEARCH-task-009-gbrain-…md, раздел 3).
• Значит, скрипт по файлам нужен в любом случае.
• gbrain — надстройка, которую можно добавить позже, если страницы с первого дня в его формате.

Против А (источник в базе cheaptrip):

• Константин просил «отдельно от остального». А физически живёт в базе cheaptrip — отдельность держится на одном гранте токена.
• Русский поиск нельзя включить, не переиндексировав cheaptrip.
• Регистрация источника и выпуск токена идут через живой сервер cheaptrip или с его остановкой — рабочая база другого проекта становится зависимостью.

Против Б (отдельная база gbrain сразу):

• Сверх файлов он даёт поиск словами и инструменты хронологии. Но поиск по смыслу выключен, а гео нет — а это и есть суть задачи.
• Добавляет замок PGLite (одна сессия за раз), миграции и бэкап базы, sync после каждой правки.
• Две ловушки для cheaptrip: gbrain mcp expose перезаписывает её службу com.gbrain.serve, а setup-gbrain сталкивается с её записью MCP gbrain на уровне пользователя.
• На старте у нас 20 квартир, 36 контактов и 25 компаний — grep и jq на таком объёме отвечают мгновенно (🔮).

Против В (файлы без правил формата):

• По цене и пользе В почти совпадает с Г.
• Разница — одна договорённость о формате. Без неё в type окажется что попало, а gbrain берёт тип страницы именно из type — переход потом означает переписывание шапок.
• С договорённостью (type = тип сущности, маркеры ручной зоны и хронологии) переход — init, sources add и объявление типов, без переписывания страниц.
• Г стоит тех же часов и оставляет дверь открытой — переплаты нет.

Против подварианта «mount»:

• Даёт только удобство CLI, пишет в ~/.gbrain/mounts.json cheaptrip, а части команд ещё нет.

2️⃣ Модель данных

Сущности

• Сущности взяты из стандарта RESO, расширения EspoCRM и кадастра Испании, урезаны под личную базу (RESEARCH-task-009-realestate-crm-…md, раздел 1).
• Главное правило: квартира и объявление — разные сущности. Одну квартиру выставляют 2–3 агентства по разной цене.

• Пакет из двух квартир (On Urbe, Pescadors, оффер 290 000 € за обе) — это одна сделка deal на два listing. Модель «сделка = одно объявление» это бы потеряла.
• Стадии переговоров — своя воронка на каждое назначение (RESEARCH-task-009-realestate-crm-…md, 4.1):
  • покупка: found → asked-agent → visit-scheduled → visited → offer-made → negotiating → reserved → notary → won / lost;
  • аренда: found → asked-availability → visit-or-video → applied → documents-sent → contract-signed → won / lost.
• Итог переговоров — поля сделки:
  • outcome: won · lost · open;
  • lost_by: me (отказали мы) · them (отказали они) · silence (никто не ответил).
• lost без lost_reason не сохраняется — проверка в скрипте.
• Список lost_reason — единственный, живёт здесь. Страницы и скрипты ссылаются на этот список, своих не держат:
  • price-too-high — дорого;
  • sold-or-rented-to-other — продали или сдали другому, забронирована;
  • bad-condition — плохое состояние, дорогой ремонт;
  • noise-or-street — шум, улица;
  • floor-or-no-lift — этаж, нет лифта;
  • location-outside-search-zone — место вне зоны поиска (2 из 3 наших отказов: Housfy, Tecnocasa);
  • agent-unresponsive — агент пропал;
  • owner-refused-offer — хозяин не принял предложение;
  • we-chose-other — выбрали другое;
  • documents-problem — документы (прописка, договор, кадастр);
  • плюс свободный комментарий.
• Предпочтения в переговорах — поля агента и страница агента:
  • в полях: язык, канал, медиана скорости ответа, комиссия;
  • на странице: стиль торга, что сработало («пакет из двух со скидкой ~18–20 %», «короткий срок сделки как довод»).
  • Признаки уже посчитаны в описи данных (раздел 5).

Где живёт истина — правило «один факт — одно место»

• Устройство страницы, чтобы скрипт не затирал ручное:
  • frontmatter, «Сводка», «Факты» и другие разделы из реестров — генерирует скрипт;
  • между <!-- manual:begin --> и <!-- manual:end --> — ручная зона: впечатления, оценка, стиль агента, «чему учит», ## Open Threads; скрипт её сохраняет как есть;
  • хронология ниже <!-- timeline --> — генерируется из журнала событий.
  • Точный синтаксис: каждый маркер — отдельной строкой ровно <!-- manual:begin -->, <!-- manual:end -->, <!-- timeline -->, в этом порядке, по одному разу на страницу; всё до manual:begin и после timeline — генерируется.
• Проверка в скрипте (запускается при каждой сборке):
  • в генерируемых разделах нет ручных правок — сравнение с тем, что собрал бы скрипт;
  • каждый ID на странице есть в реестре;
  • у lost есть lost_reason;
  • у точки есть geo_precision и источник.
• Почему так, а не «страницы главные»:
  • скрипты задач 003–008 уже пишут реестры, сверяют ссылки контакт ↔︎ квартира ↔︎ компания и ищут дубли по listing_urls. Перенос истины в страницы ломает все три проверки (опись, раздел 7);
  • поля в JSON фильтруются картой напрямую, а текст страниц — нет.
• Что делать с полями, которых в реестрах не хватает (дом, этаж, координаты, язык агента, адрес офиса агентства): не добавлять их в реестры cl-cons-whats, а держать в новом репо с ключом property_id / contact_id / company_id. Тогда скрипты задач 003–008 остаются как есть.

Довод Константина за отдельность — что с ним при такой схеме

• Его слова (постановка задачи 009): отдельный репозиторий будет небольшим и однородным — агенты, аренда и покупка, переговоры, предпочтения, история, контакты — «такая CRM».
• Честно: при схеме выше (вопрос 2, вариант 2а) CRM делится на два репо.
  • В cl-cons-whats остаётся ядро CRM: контакты, компании, их роли, переписка и доказательства.
  • В новом репо — вид (страницы, карта), гео и то, чего в переписке нет: сделки и предложения, требования поиска, объявления с сайтов, оценки и предпочтения.
• Что из довода выполняется:
  • новый репо — небольшой и однородный: только недвижимость, ни одного чужого чата;
  • человек и агент, открывшие новый репо, видят CRM целиком: страница агента собирает контакт, сделки, хронологию — копией, сгенерированной из обоих мест.
• Что не выполняется:
  • править контакт или компанию нужно в cl-cons-whats, а не здесь — два репо в работе;
  • без cl-cons-whats рядом новый репо не соберётся.
• Если довод важнее «ничего не ломать» — чистая отдельность: реестры недвижимости переезжают в новый репо вместе со своими скриптами и правилами разбора, а cl-cons-whats только выгружает чаты (вопрос 2, вариант 2б). Цена — перенести и перепроверить работу задач 003–008. Я предлагаю начать с 2а и сделать этот переезд одним шагом позже, если работа в двух репо станет мешать: новый репо читает реестры по одному пути, поэтому переезд — смена этого пути плюс перенос скриптов.

3️⃣ Назначения и фильтр по назначению

• Поле назначения одно на все сущности — purposes, всегда список, только четыре значения из таблицы. Срок («весна 2027») — не в назначении, а в требованиях поиска (search).
• Точность точки — поле geo_precision: building · street · area (раздел 4).
• Квартира Давида одновременно my_current_rental и sublet_my_flat. Это один физический объект, сейчас он под разными именами живёт в двух репо (опись, раздел 3).
• Переход с нынешнего topic: buying_apartment_in_barceloneta → buy, my_current_rental → my_current_rental.
• Внутри темы покупки лежит и аренда: комната в Эшампле, Poblenou. Куда её — вопрос 7.
• Фильтр на карте — галочки по назначению (L.control.layers), выпадающий список района, статус. Так сделан прототип координатора.
• 🔮 Додумал: аренда Ukio с 1 марта по 31 мая и конец сабаренды 3 апреля 2027 пересекаются. Возможно, это повлияет на срок аренды — вопрос 5.

4️⃣ Гео

Как получаем координаты — по порядку надёжности

1. Со страницы объявления. У Ukio в коде страницы есть schema.org geo (широта и долгота), но улица без номера. Пишем geo_precision: street (🔮 сайт не говорит, что это точный дом).
2. Геокодер по адресу с номером дома, бесплатно и без ключа:
   • ICGC Geocoder — официальный для Каталонии, отдаёт нормализованную улицу и номер;
   • Nominatim — запасной, по его правилам: не чаще 1 запроса в секунду, свой User-Agent, результат кэшировать, массово не геокодировать.
   • Для нас это десятки адресов — не «массово».
   • Пишем geo_precision: building.
3. Кадастр (Catastro) — ключ дома. По адресу или по координатам он отдаёт кадастровый номер (14 символов — дом, 20 — квартира) без ключа API.
   • Решает «угловой дом с двумя адресами»: проверено на тестовом угловом доме Sant Carles 10 / Pescadors 13 (не наш объект).
   • Связывает две квартиры одного дома: Atlàntida 97-99 ×2, Grau i Torras 47-49 и Lucas Fox «Grau i Torras 47».
4. Только улица без номера (Pescadors) — точка в середине улицы, geo_precision: street.
5. Адреса нет (квартира Давида) — центр района, geo_precision: area.

• Кэш: все ответы геокодеров — в JSON-файле в репо. Один адрес запрашивается один раз в жизни.
• Нормализация написания перед запросом: Grau I Torres → Carrer de Grau i Torras, Atlantida → Carrer de l'Atlàntida. Адрес «как в данных» сохраняется рядом.

Как район привязывается к объекту

• Границы 73 barris — Open Data BCN, лицензия CC BY 4.0. Из JSON с полем WKT одним скриптом получается GeoJSON ≈366 КБ, без библиотек.
• Скрипт один раз проверяет, в какой полигон попадает точка (point-in-polygon), и записывает codi_barri в реестр гео.
• Район из ответа Nominatim (quarter) — только для сверки: названия OSM и Open Data BCN могут расходиться.
• Прототип координатора считает район прямо в браузере. В рабочей базе район хранится в данных, чтобы фильтры работали без вычислений.

Как фильтруем и группируем

• По району и округу — выпадающий список; полигоны barris — отдельным слоем.
• По назначению, статусу, цене «от–до» — галочки и ползунок по полям JSON.
• По дому — объекты с одним кадастровым номером дома раскрываются в один маркер со списком.
  • Для плотной Барселонеты — markercluster с раскрытием на крупном масштабе.
• Расстояние до пляжа — один способ везде: по прямой до линии пляжа Барселонеты, как на карте; 🔮 линия нарисована на глаз, пляжи Poblenou не учтены. С пометкой «пешком дальше».

Проблема тайлов при открытии двойным кликом (file://)

• С 2026 года tile.openstreetmap.org отвечает 403 «Referer is required» страницам, открытым с диска.
• Тайлы ICGC отвечают без Referer (проверено запросом из терминала; в браузере — 🔮, покажет прототип координатора). Поэтому ICGC — слой по умолчанию.
• Запасной путь для OSM — открыть карту через python3 -m http.server --bind 127.0.0.1.
• CARTO без ключа рисует водяной знак — не подходит.
• 🔮 Додумал: Leaflet грузится с unpkg, значит, без интернета карта не откроется. Если нужно офлайн — положить leaflet.js и leaflet.css в репо (≈150 КБ).

5️⃣ Кто и как пополняет базу

Поток данных

1. Константин запускает выгрузку WhatsApp (wacli sync — только он сам).
2. Агент в cl-cons-whats, как сейчас:
   • SCRIPT-whatsapp-update-registry-all-steps.py → новая переписка и черновики по ссылкам;
   • разбор переписки → правка реестров realestate-registry/ с доказательствами.
3. Агент в новом репо запускает одну сборку (🔮 условное имя SCRIPT-realestate-rebuild-geo-pages-and-map.py):
   • читает реестры cl-cons-whats — только чтение, по абсолютному пути;
   • геокодирует новые адреса (кэш, пауза 1 с) и считает район;
   • пересобирает генерируемые зоны страниц и хронологию;
   • собирает HTML-карту;
   • проверяет ссылки, lost_reason, ручные правки в генерируемых зонах.
4. Объявления с сайтов (Ukio и другие) — вручную:
   • Константин присылает ссылку или просит «найди на весну 2027»;
   • агент читает открытую страницу без входа и форм и пишет объявление с датой просмотра seen_at;
   • у объявления stale_after = 30 дней: цены Ukio динамические.
5. Слова Константина («были на просмотре, шумно», «предложили 280») → агент пишет событие в журнал, обновляет сделку и ручную зону страницы.

Ручная работа в неделю — 🔮 оценка

• В неделю без переписки и без новых объявлений — ноль: сборка ничего не меняет.

6️⃣ Имя и место репозитория

• Место: /Users/ws/uno-cl/<имя>, рядом с остальными cl-cons-*. Локально, GitHub — по желанию Константина.
• Слово области realestate идёт сразу после cl-cons-: так уже названы realestate-registry/ и SCRIPT-realestate-*. Тогда ls /Users/ws/uno-cl | grep realestate находит всё.

• Сам репозиторий не создан — ждёт ответа на вопрос 3.

Структура папок — на утверждение

• По правилу служебные папки нового направления — сначала утверждение создаю только после ответа Константина.
• 🔮 Предположение — моё: состав папок ниже, имена внутренних папок страниц (apartments/, people/ и т. д.). Подобраны под префиксы gbrain, чтобы этап 2 варианта Г шёл без переименований.

cl-cons-realestate-barcelona-apartments-and-agents/
├── README.md, CLAUDE.md, AGENTS.md, CHANGELOG.md, log.md
├── RULES-realestate-one-fact-one-place-registries-generate-pages.md
├── realestate-registry-local/
├── realestate-pages/
│   ├── apartments/   buildings/   areas/
│   ├── people/   companies/   deals/   searches/
├── realestate-geo-data/
├── realestate-scripts/
├── _cons-output-realestate-map/
├── _cons-project-context/
└── _cons-changes/

• Прямой вопрос Константину (он же в вопросе 3): помогает ли такая структура видеть шаги работы — «переписка → реестры → гео → страницы → карта»? Ничего ли не пропущено и нет ли лишнего?

7️⃣ Что делать дальше — после ответов Константина

1. Записать ответы в справочник решений проекта и в README задачи 009.
2. Если выбран вариант Г или В — создать репозиторий под утверждённым именем и с утверждённой структурой. Шапки OKF, AGENTS.md рядом с CLAUDE.md, указатели .LINK.md на общие правила.
3. Написать правило «один факт — одно место» и скрипты:
   • сначала геокодирование с кэшем и расчёт района;
   • затем сборка карты из реестров — прототип координатора станет шаблоном;
   • затем сборка страниц с ручной зоной;
   • затем проверка.
4. Перенести в рабочую базу объекты прототипа: 6 кандидатов на покупку с Барселонеты, 5 квартир Ukio, TAKSIM как ориентир. Квартиру Давида — по ответу на вопрос 6.
5. Завести требования поиска (searches/) по ответам на вопросы 4–5. Заново проверить Ukio с весенними датами — нет ли новых квартир на Барселонете.
6. Внести итог торга On Urbe и статус Sant Miquel 116 по ответам на вопросы 8–9.
7. Независимая проверка: карта открывается двойным кликом, 2–3 точки сверены с источником, в генерируемых зонах нет ручных правок.
8. Вариант Б (этап 2) — не делать, пока не появится один из сигналов из раздела «Вариант Г».