type: entity

entityType: project

observations: Стартап: AI-подбор земельных участков (Site Finder) + автоматическая генерация концепций застройки (Generative Design) для девелоперов РФ

observations: Two-in-one воронка: от инвест-критериев → найденный участок → концепт застройки → финансовая модель

observations: Конкуренты: rTIM (только концепт-стадия, нет site-selection), TestFit (нет РФ-данных)

observations: Целевая аудитория: инвестдепартаменты + архитектурно-проектные отделы региональных девелоперов

observations: Фаза 0 — Discovery MVP, апрель–июнь 2026 (3 месяца)

observations: Бюджет Фазы 0: 0,9–1,2 млн ₽

observations: Документы хранятся в docs/ внутри репозитория


observations: Решение зафиксировано в апреле 2026: переход с .NET на Python для Discovery MVP

observations: Backend: Python 3.12, FastAPI 0.115+, SQLAlchemy 2.0, GeoAlchemy2, Pydantic v2, Alembic, Celery + Redis, httpx

observations: Геометрия: Shapely 2.0, GeoPandas 1.0, Pyproj (проекции WGS84 ↔ UTM ↔ МСК-66 для Свердловской обл.), Rasterio

observations: ML: XGBoost (скоринг участков), scikit-learn, pandas, NumPy

observations: База данных: PostgreSQL 16 + PostGIS 3.4, Redis 7

observations: Frontend: Next.js 15, React 19, TypeScript 5, Tailwind CSS 4, shadcn/ui, TanStack Query, Mapbox GL JS или Leaflet

observations: Экспорт: WeasyPrint (PDF), ezdxf (DXF), openpyxl (Excel)

observations: Инфра: Yandex Cloud или VK Cloud, Docker, GitHub Actions, Sentry

observations: Dev tools: uv (зависимости), ruff (линтер+форматтер), mypy (типизация), pytest


entityType: goal

observations: К концу месяца 3 (июнь 2026): 3 платящих пилотных клиента, ≥30 тыс. ₽/мес каждый

observations: Заявка в реестр российского ПО подана

observations: Це́ль: получить право пройти в Раунд А на 20–25 млн ₽

observations: Acceptance criteria разбиты на 3 блока: функционально / бизнесово / технически

observations: Правило перехода: 3/3 → Раунд А; 2/3 → продление Фазы 0 на 1–2 мес.; 1/3 или меньше → стоп проекта

observations: В v2.2 цель = 3 пилота; в v2.1 (бизнес-план) указано 4 пилота — расхождение, требует синхронизации в пользу 3


entityType: phase

observations: Discovery MVP, месяцы 1–3 после старта

observations: Пилотный регион: Свердловская обл. (Екатеринбург, ПЗЗ Екатеринбурга, МСК-66)

observations: Месяц 1 цели: ООО зарегистрировано, прототип Site Finder с 1000 участков, 50 целевых клиентов в CRM, 5 cold-outreach, 3 встречи

observations: Месяц 2 цели: 15 встреч кумулятивно, 2 LOI, 1 платящий пилот (≥30 тыс. ₽/мес), демо на реальных участках, первая статья

observations: Месяц 3 цели: 20+ встреч, 3 платящих пилота, 7+ LOI, 1 регадминистрация в переговорах, заявка в реестр ПО, инвест-deck (12 слайдов), финмодель на 5 лет


entityType: review

observations: Дата валидации: 25 апреля 2026

observations: КРИТИЧНО: бизнес-план v2.1 не синхронизирован со стеком v2.2 — в плане 12 мес. месяцы 1–4 ещё ссылаются на .NET Core 8

observations: Несостыковка KPI: v2.1 = 4 платящих пилота, v2.2 = 3 — нужно остановиться на 3 (как в Acceptance Criteria v2.2)

observations: Регион не зафиксирован однозначно: v2.1 пишет «Свердл. или Лен.», v2.2 — только Свердл. — закрепить Свердловскую

observations: Прайсинг: пилот 30 тыс., прайс-лист 70–120 тыс. — уточнить в финмодели для инвесторов: 70 тыс./мес как baseline

observations: Технические риски: Time to First Value ≤10 мин амбициозно (предложение: 15 мин); генерация концепции ≤10 сек требует профилировки с первого билда

observations: PostgreSQL TDE отсутствует в open-source — заменить на pgcrypto + шифрование чувствительных полей на уровне приложения

observations: mypy --strict для всего MVP избыточен соло-разработчику — оставить только для core-модулей (geometry/scoring/financial)

observations: 99% uptime в рабочие часы для соло-разработчика рискованно — реалистично 95% + ответ в течение рабочего дня

observations: Заявка в реестр ПО ≠ свидетельство; срок рассмотрения 60–180 дней — учесть для расчёта Раунда А

observations: Бюджет 1,2 млн ₽ + 3 мес. + один основатель плотный; рекомендация — заложить буфер +1 месяц или урезать DXF-экспорт из Discovery


entityType: feedback

observations: Правило: вся информация по проекту gendesign хранится в memory-gendesign.jsonl (context="gendesign"). Информация = факты, решения, результаты анализа, обсуждения стратегии, KPI, списки рисков, протоколы валидации и т.д.

observations: НИКОГДА не создавать .md / .docx / .pdf / .pptx файлы самостоятельно — даже если кажется, что это поможет. Документы генерируются ТОЛЬКО по явному запросу («сделай md», «собери в документ», «выгрузи в docx»).

observations: При поступлении новых фактов/решений в разговоре — сразу сохраняем в память через aim_memory_store / aim_memory_add_facts в context="gendesign".

observations: Для файловой генерации по запросу: запрос срез из памяти (aim_memory_search/read_all) → сборка документа. Память = единый источник правды, файлы = производные.

observations: **Why:** пользователь хочет избежать разъехавшейся инфы между версиями доков (как случилось с v2.1/v2.2). Единый источник (граф памяти) — синхронен по определению.

observations: **How to apply:** в любом обмене по этому проекту — (1) сначала читаем gendesign-память, (2) ведём диалог/анализ, (3) сохраняем новые выводы в память, (4) файлы только если пользователь явно запросил.


entityType: team

observations: 2 фуллстек-разработчика (оба пишут Python + TypeScript)

observations: Оба part-time по 20 ч/неделю — итого ~40 person-hours/неделю (эффективных с координацией ~33)

observations: Разделение по фичам, а не по слоям — оба трогают backend и frontend

observations: Ритм координации: 1 синк/неделю (30 мин), daily-async в Telegram, PR review обязательный

observations: Ветвление: trunk-based, feature ветки ≤ 3 дней

observations: Критичный тулинг: openapi-typescript для codegen TS-типов из Pydantic-схем (иначе два фуллстека плодят расхождения в API-контракте)


entityType: plan

observations: Порядок: строго последовательный — Generative полностью, потом Site Finder

observations: Общая оценка: 12 недель (Stage 0: 1 нед., Stage 1: 6 нед., Stage 2: 5 нед.)

observations: Stage 0 (нед. 1) — скелет: монорепо backend+frontend, Docker с PostGIS+Redis, FastAPI hello, Next.js hello, openapi-typescript codegen, GitHub Actions CI, ruff+mypy(core)+pytest. Без JWT (single-tenant + X-Demo-User до Раунда А)

observations: Stage 1a (нед. 2-3) — геометрия + API-контракт. A: Shapely-сервис (отступы, сетка), Pydantic ConceptInput/Output, POST /api/v1/concepts с заглушкой. B: страница /concept, Leaflet, импорт GeoJSON + отрисовка, форма параметров, вывод 3 вариантов в табах

observations: Stage 1b (нед. 4-5) — алгоритм размещения. A: жадное заполнение, 3 стратегии, STRtree для коллизий, профилировка (цель ≤10с, fallback 15с). B: визуализация корпусов, метрики ТЭП, сравнение вариантов

observations: Stage 1c (нед. 6-7) — ТЭП + финмодель + экспорты. A: teap.py, financial.py, openpyxl. B: WeasyPrint шаблон, ezdxf, UI кнопок скачивания

observations: Acceptance Stage 1 (конец нед. 7): полигон→3 варианта→ТЭП+финмодель→PDF/Excel/DXF. Продаваемый артефакт для встреч с месяца 2

observations: Stage 2a (нед. 8-9) — data pipeline. A: парсер ПКК Rosreestr (httpx async, retries), модель Parcel с GeoAlchemy2, загрузка 1000+ участков Екбурга. B: Overpass API для POI, ДОМ.РФ/ЦИАН для цен м², кеш в Redis

observations: Stage 2b (нед. 10-11) — скоринг+API+UI. A: 3 критерия скоринга (эвристики, без XGBoost), POST /parcels/search. B: страница /site-finder, Mapbox, градация по рейтингу, фильтры, карточка

observations: Stage 2c (нед. 12) — интеграция + полировка. Кнопка «Обсчитать концепцию», демо-наполнение 50 участков, бэкапы БД, подача в реестр ПО

observations: Урезано из v2.2 из-за part-time ×2: XGBoost→Фаза 1, JWT-auth→перед Раундом А, mypy --strict только на core, время генерации ≤15с (а не 10с) как fallback


entityType: decision

observations: Дата: 25 апреля 2026

observations: Выбор хостинга для РФ: рассматривались Yandex Cloud, VK Cloud, Selectel, Timeweb Cloud, Cloud.ru (Сбер)

observations: Рекомендован Yandex Cloud как основной вариант для Discovery + Production

observations: Обоснование: (1) лучшая поддержка PostGIS в Managed PostgreSQL в РФ; (2) Container Registry + Container Solution включены; (3) входит в реестр российского ПО — плюс к нашей заявке; (4) солидно выглядит для инвесторов Раунда А

observations: Стоимость Discovery (~10–15 тыс ₽/мес): VM Compute s3-c2-m4 (~3-4 тыс), Managed Postgres 1vCPU/4GB/30GB SSD (~5-7 тыс), Container Registry (бесплатно до 5GB), Object Storage для бэкапов (~500₽)

observations: Альтернатива для жёсткой экономии: Selectel дешевле в 1.5–2 раза, но требует ручной PostGIS-рутины. Резерв на случай проблем с YC

observations: Архитектура production: 1×VM с Docker Compose (backend + frontend + Caddy reverse proxy + auto-TLS) + Managed PostgreSQL (отдельный сервис) + Object Storage (бэкапы)

observations: Образы: backend + frontend пушатся в Yandex Container Registry из GitHub Actions; на VM выполняется docker compose pull && up -d

observations: GitHub Secrets для deploy: YC_SA_JSON_CREDENTIALS, YC_REGISTRY_ID, DEPLOY_HOST, DEPLOY_USER, DEPLOY_SSH_KEY, DEPLOY_PORT (опционально)

observations: Caddy выбран вместо nginx: авто-TLS через Let's Encrypt без ручных certbot-рутин — дешевле по времени сопровождения для part-time команды

observations: Домен: покупать в .ru зоне (REG.RU или РуЦентр), DNS на Yandex Cloud DNS или Cloudflare бесплатный

observations: Production-путь на VM: /opt/gendesign/docker-compose.prod.yml + .env + Caddyfile


entityType: procedure

observations: MCP-сервер для памяти: npm-пакет mcp-knowledge-graph (запуск через npx -y)

observations: Команда в claude_desktop_config.json: command=npx, args=['-y','mcp-knowledge-graph','--memory-path','<путь к папке с .jsonl файлами>']

observations: Путь в рабочей среде основателя: C:\mcp\.aim

observations: Стратегия разделённой памяти между коллегами: git синхронизация файла memory-gendesign.jsonl + хард-линк из репо в MCP-папку. Источник правды — репо

observations: Конфликты в .jsonl обычно простые (файл построчный): решаются выбором "оставить обе стороны". rebase, не merge

observations: Ритуал: git pull перед началом работы, git commit+push после изменений памяти

observations: Полный текст процедуры выдан в чате 25 апреля 2026; при повторном запросе — восстановить из этой сущности


entityType: research

observations: Дата проверки: 25 апреля 2026, фактические цены с сайтов провайдеров

observations: Целевой конфиг: 2 vCPU / 4 GB RAM / 30-40 GB NVMe SSD + public IPv4. 60 GB избыточен для Discovery (реальное использование диска 12-15 GB: OS+Docker 5-7 GB + Postgres+PostGIS 0.5-1 GB + логи+бэкапы 1-2 GB + буфер 5 GB)

observations: Selectel Standard Line 2/4 GB = 2308.86 ₽/мес (CPU+RAM only) + диск 30 GB Network SSD ~270 ₽ + public IP. Итого ~2700-3000 ₽/мес. Дороже конкурентов в 2-3 раза

observations: Selectel Shared Line 2/4 GB с 10% vCPU = 1239 ₽/мес — дешевле, но CPU слишком слабый для Postgres+PostGIS под реальной нагрузкой

observations: Timeweb Cloud MSK 50: 2 vCPU 3.3 GHz / 4 GB / 50 GB NVMe / 1 Гбит/с = 1062 ₽/мес со скидкой 10% при годовом контракте (или ~1180 ₽ без контракта). IPv4 включён. Реестр ПО № 15725

observations: Beget VPS Standard 2 vCPU 3+ GHz / 4 GB / 40 GB NVMe = 33 ₽/день сервер + 5 ₽/день IPv4 = 38 ₽/день ≈ 1140 ₽/мес. Автобэкапы раз в несколько дней бесплатно. KVM. Реестр ПО № 16697

observations: Beget VPS 2/2/30 = 27 ₽/день + 5 ₽ IP = 32 ₽/день ≈ 960 ₽/мес — ещё дешевле, но 2 GB RAM маловато для Postgres+PostGIS+Redis+backend+frontend+Caddy

observations: Рекомендация Discovery: Beget VPS 2/4/40 NVMe + IP ≈ 1140 ₽/мес (самый дешевый реально рабочий конфиг) или Timeweb Cloud MSK 50 ≈ 1062 ₽/мес (лучше NVMe, больше диск)

observations: Ранее в Hosting_Decision_Apr25 был предложен Yandex Cloud (~10-15 тыс ₽/мес с managed services). Это вариант для продакшена после Раунда А, не для Discovery

observations: Для Discovery Beget выигрывает по цене и бесплатным бэкапам. Timeweb выигрывает по UI/UX панели и большему диску. Selectel оправдан только если планируется быстрый перевод на managed Postgres/K8s в их экосистеме


entityType: infrastructure

observations: SSH-ключ для проекта: ed25519, без passphrase (для автодеплоя из GitHub Actions)

observations: Локация: $HOME\.ssh\gendesign_deploy (приватный) + .pub (публичный)

observations: SSH config alias: 'Host gendesign' с IdentityFile ~/.ssh/gendesign_deploy — коннект командой 'ssh gendesign'

observations: Публичный ключ вручную загружается в панель хостинг-провайдера при создании сервера

observations: Приватный ключ позже пойдёт в GitHub Secret DEPLOY_SSH_KEY (для deploy.yml workflow)

observations: Windows-специфика: icacls нужен для ограничения прав на приватный ключ, иначе OpenSSH ругается на 'UNPROTECTED PRIVATE KEY FILE'


observations: Принцип разделения: вертикальные срезы по этапам пользовательского пути, не по слоям

observations: Person A — 'Geometry → Variants' owner: Shapely-сервис, нормативные отступы, жадный алгоритм с 3 стратегиями, STRtree коллизии, профилировка. API endpoint POST /concepts, владелец схемы ConceptInput+buildings_geojson. Фронт: Leaflet, импорт/отрисовка полигона, форма параметров, рендеринг 3 вариантов на карте

observations: Person B — 'Variants → Reports' owner: TEAP-сервис, финансовая модель, экспорты PDF/Excel/DXF (WeasyPrint+openpyxl+ezdxf). API endpoint /concepts/:id/export, владелец схем TEAP+FinancialModel. Фронт: таблицы ТЭП, форма финмодели, кнопки скачивания, сравнение вариантов

observations: Точка стыка = Pydantic-контракт ConceptVariant в backend/app/schemas/concept.py. Договариваются в первый день Stage 1a, дальше оба работают с заглушками друг друга без блокировки

observations: Точка стыка 2 — codegen TS-типов: при любой правке схемы оба запускают 'npm run codegen' локально

observations: Календарь по неделям (Stage 1, нед.2-7): A движется по вектору схема→отступы→алгоритм→стратегии→тесты. B движется по вектору схема→TEAP→financial→Excel→DXF→PDF→тесты

observations: Альтернативный расклад при асимметрии навыков: Алгоритмист (A) берёт все 4 backend-сервиса (geometry+TEAP+financial+exporters), фронт минимум. Продуктовик (B) берёт весь фронт + UI экспортов, backend минимум (тонкий export endpoint)

observations: Анти-паттерны: разделение backend/frontend (блокирует второго), общие прямые пуши в main, молчаливые правки Pydantic без codegen, pair programming на каждой задаче (дорого для part-time ×2)


observations: Дата: 25 апреля 2026

observations: В РФ открытых данных по реальным сделкам (Росреестр) НЕТ — только агрегаты. Цены и площади из агрегаторов (ЦИАН/ДомКлик/Авито) — по объявлениям, не по сделкам

observations: Открытые официальные источники (бесплатно, без юрриска): ДОМ.РФ (наш.дом.рф + api.dom.rf, реестр новостроек, площади в жк, колво квартир по комнатностям, класс жилья); Росстат (fedstat.ru, средние цены м² по регионам квартально); Минстрой (норматив цены м² для субсидий); Главгосэкспертиза НЦС (gge.ru, себестоимость м² строительства)

observations: Скрейпинг агрегаторов (серая зона): ЦИАН (cianparser/cianscraper либы на GitHub, но Cloudflare и рейтлимит); Авито; ДомКлик; Яндекс.Недвижимость. Юридически — нарушение ТОС, но исков против мелких парсеров немного

observations: Платные отраслевые: ЕРЗ.РФ Премиум (50-100тыс ₽/год, отраслевой стандарт); Knight Frank/NF Group/CBRE отчеты; PROEstate Analytics; СберИндекс (бесплатно)

observations: Рекомендация для Discovery: Цены — Росстат baseline + ручной парсинг/скрейп ЦИАН 200 объявлений по районам Екбурга. Площади+unit-mix — захардкодить таблицу с возможностью ручной правки. Себестоимость — НЦС Главгосэкспертизы. Новостройки-конкуренты — API ДОМ.РФ

observations: Для реестра ПО декларируем только легальные источники: ДОМ.РФ, Росстат, Главгосэкспертиза, OpenStreetMap. Скрейп ЦИАН — «внутренний справочник curating». Для инвесторов Раунда А — «договорённости с источниками рыночных данных в проработке»


entityType: strategy

observations: Дата анализа: 25 апреля 2026

observations: Исходный вопрос: можно ли косвенно понять, какие квартиры продаются и какие нет. Ответ: да, через ejednevnyy мониторинг шахматок застройщиков + delta-tracking

observations: Прямые данные о сделках в РФ закрыты: Росреестр ДДУ не в open data, нотариусы и банки — закрытые источники

observations: Косвенные источники по точности: 1) Шахматки застройщиков — 95%+ точность, золотая жила. 2) ДОМ.РФ реестр ДДУ по ЖК — 100% на уровне агрегата. 3) Delta-tracking listings ЦИАН/Авито — 70% точность. 4) ДомКлик ипотечная статистика — sanity check на уровне района. 5) Фиксация снижений цен — сигнал «не продаётся»

observations: Шахматки = золотая жила. На сайтах ПИК/Брусника/Атомстройкомплекс/ТЭН-Девелопмент/Стройтэк/ЛСР и др. интерактивная шахматка с поквартирным статусом (доступно/бронь/продано). Даёт площадь, комнатность, этаж, секцию, цену, дату продажи

observations: Тех-план: воркер services/site_finder/sales_tracker.py + поадаптеру на каждого застройщика (brusnika_scraper.py, atomstroy_scraper.py...). Cron 1×в сутки. SPA-сайты — Playwright. SSR — httpx+BS4

observations: Схема БД: apartments(id, jk_id, room_count, area_sqm, floor, section, price_rub, status, last_seen_at) + sales_history(apartment_id, sold_date, sold_price). Materialized views для velocity в радиусе X от точки

observations: Три киллер-фичи из этих данных: A) Velocity Score в Site Finder — дополнительный 4-й критерий скоринга (сколько квартир продаётся/мес в радиусе 1км). B) Smart Unit-Mix в Generative — рекомендация долей 1/2/3-комн на основе реальных продаж в районе. C) Validation финмодели — бенчмарк прогноза выручки против факта по соседним ЖК

observations: Это самый важный data moat: TestFit без РФ-данных, rTIM без site-selection и аналитики спроса. Через 6-12 мес накопления — уникальный источник данных для девелоперов, который не воспроизвести конкурентам быстро

observations: План Discovery: Stage 2a нед.8-9 добавляется воркер sales_tracker параллельно парсеру ПКК. Реализуем 5-7 адаптеров (топ-застройщики Екбурга). К концу месяца 3 имеем 2-3 недели исторических данных

observations: Целевые застройщики Екбурга для Discovery: Атомстройкомплекс, Брусника, ТЭН-Девелопмент, Стройтэк, Прогресс, УГМК-Застройщик, Кортрос, ЛСР-Урал, Forum-group, ПИК (если есть в ЕКБ)

observations: Юридика: шахматки = публичные маркетинговые данные (без авторизации, серая зона мягче ЦИАН). Прецедентов исков застройщиков к парсерам практически нет (им нужны шахматки как воронка маркетинга). Для реестра ПО декларируем как «партнёрские интеграции с открытыми источниками застройщиков»

observations: Анти-риски: 1) Сайт застройщика меняет вёрстку — скрейпер ломается, нужен Sentry alerting. 2) Юр-претензия от крупного застройщика — митигация через «партнёрство возамен аналитики» с топ-3 таргетов. 3) Низкое качество сайтов мелких застройщиков — берём только тех, у кого нормальный веб-интерфейс

observations: Через 6 мес накопления: сезонные коэффициенты, absorption curves по типам квартир, ML-предсказание velocity для нового участка. Для Раунда А это идеальный narrative: «уникальная база продаж новостроек Свердловской обл., которой нет в открытых источниках и у западных игроков»


observations: Дата: 25 апреля 2026, вечер. Обсуждали с Антоном (второй разработчик)

observations: Новые вводные: Антон сказал, что есть доступ ко всем сделкам для анализа. Детали по данным будут в понедельник 27 апреля 2026

observations: Предложение Антона: сначала аналитика по продажам (что строить, какие квартиры, площади), потом всё остальное

observations: Решение (предварительное, ждём детали): НЕ полный pivot. Перестановка порядка этапов: Stage 1 = Sales Analytics (нед 2-5), Stage 2 = Generative со Smart Defaults из аналитики (нед 6-10), Stage 3 = Site Finder с Velocity Score (нед 11-12)

observations: Обоснование не полного pivot: Generative — главный дифференциатор против rTIM/TestFit. Без него конкурируем напрямую с ЕРЗ/ДОМ.РФ (у них 5 лет данных и команда). Аналитика становится мозгом для Generative и Site Finder, а не их заменой

observations: Концепция «3 плитки»: ввод участок + класс жилья → (1) ЧТО СТРОИТЬ (unit-mix с velocity), (2) СКОЛЬКО ПРОСИТЬ (распределение цен м² по классам + тренд), (3) ЗА КАКОЕ ВРЕМЯ ПРОДАСТСЯ (absorption curves по АНАЛОГам). Кнопка «Сгенерировать концепцию» ведёт в Generative

observations: Плюс нового плана: продаваемый артефакт уже после мес 1 (раньше был конец мес 2). Меньше технического риска. Другой ICP (инвестдепартамент вместо архитектуры)

observations: КРИТИЧНО: «доступ ко всем сделкам» — это фундамент или мина. Бывают 4 сценария: 1) Легальный богатый ongoing (ЕРЗ Premium/банк/админ) → полный pivot, аналитика фундамент. 2) Легальный ограниченный → план A + шахматки параллельно для ongoing. 3) Серый канал → НЕ строим бизнес на этом, используем только «для себя». 4) Обещают но не дают → идём по плану шахматок, ждём

observations: 6 блоков вопросов к Антону на 27 апреля: Природа канала (что именно за доступ); Поля данных (цена/метраж/комнатность/покупатель?); Покрытие (регионы/история); Свежесть (разовая выгрузка или ongoing); Условия использования в коммерческом продукте; Цена доступа

observations: Что делаем до пн (не останавливаемся, но с осторожностью): SSH-ключ, выбор хостинга (Beget/Timeweb), Stage 0 скелет уже сделан. НЕ начинаем Shapely геометрию или парсер ПКК — приоритет может сместиться

observations: Шахматки застройщиков НЕ отменяются даже если данные Антона полные: 1) Сделки в Росреестре регистрируются с лагом 1-3 месяца. 2) Бронирования и доступность — сделки этого не показывают. 3) Маркетинговая цена vs фактическая различается

observations: Сообщили Кене ответ Антону: направление в точку, но не полный pivot. Ждём детали по данным в пн. Вижу 6 блоков вопросов. От ответов зависит тип плана

observations: Уточнение 25.04.2026 вечер: Антон подтвердил — речь идёт о ДДУ (Договорах Долевого Участия). Это идеальный источник для аналитики: ground truth по продажам новостроек, выше качеством чем шахматки

observations: ДДУ поля стандартно: кадастровый номер квартиры, площадь, цена, дата регистрации, застройщик, ЖК. иногда комнатность/этаж/секция. ПН-поверхность: ПДн покупателя часто включены — обязательное обезличивание до записи в нашу БД (152-ФЗ)

observations: Лаг ДДУ: 30-90 дней от реальной сделки до регистрации в Росреестре. Поэтому шахматки застройщиков НЕ отменяются — они дают 'today snapshot', ДДУ дают 'historical truth'

observations: 5 блоков к понедельнику (сужены до ДДУ-специфики): 1) Канал — держатель и договор (DOM.RF API/ЕРЗ Premium/банк/администрация/другое). 2) Поля (все ли обязательные + комнатность и ПДн). 3) Покрытие (регионы/история). 4) Свежесть (разовая/ongoing/real-time и лаг). 5) Условия коммерческого использования

observations: Преимущество ДДУ над шахматками: ground truth по фактической цене (не маркетинговой), историческая глубина, юридически чистый источник (если канал легален), data moat относительно TestFit/rTIM


entityType: runbook

observations: Источник: фактическая настройка сервера Jolly Yakov в Beget Cloud, 25.04.2026. Сервер 2 vCPU / 4GB RAM / 40GB NVMe / Ubuntu 24.04, IP 46.173.16.127

observations: ШАГ 1: Создание сервера в cp.beget.com/cloud → Создать сервис → VPS → Standard 3+ GHz → 2 ядра/4GB/40GB. ОС: Ubuntu 24.04. Включить публичный IPv4. После создания сервер получает IP, root пароль выслан на email

observations: ШАГ 2: Генерация SSH-ключа локально (если ещё нет). Windows PowerShell: ssh-keygen -t ed25519 -C 'gendesign-deploy' -f $HOME\.ssh\gendesign_deploy. Пароль оставить пустым (Enter Enter) — нужно для автодеплоя

observations: ШАГ 3: Добавление публичного ключа на сервер через панель Beget. При проблемах со SSH (Connection reset, fail2ban) — войти через VNC терминал в браузере и добавить в ~/.ssh/authorized_keys

observations: ШАГ 4: Первый вход по SSH с явным ключом. Команда: ssh -i $HOME\.ssh\gendesign_deploy root@<IP>. При первом коннекте спросит fingerprint — yes

observations: ШАГ 5: На сервере (root): обновить пакеты 'apt update && apt upgrade -y'. Если [-f /var/run/reboot-required] то ребут. Установить hostname/timezone: hostnamectl set-hostname gendesign; timedatectl set-timezone Europe/Moscow

observations: ШАГ 6: Создание non-root пользователя. adduser gendesign (задать сильный пароль, остальное Enter). usermod -aG sudo gendesign. Копия SSH-ключа root→gendesign: mkdir -p /home/gendesign/.ssh && cp ~/.ssh/authorized_keys /home/gendesign/.ssh/ && chown -R gendesign:gendesign /home/gendesign/.ssh && chmod 700 /home/gendesign/.ssh && chmod 600 /home/gendesign/.ssh/authorized_keys

observations: ШАГ 7: Тест первого входа как gendesign. Важно: хранить root-сессию открытой как safety net до конца. В новом окне: ssh -i $HOME\.ssh\gendesign_deploy gendesign@<IP>. Проверка sudo: sudo whoami → root

observations: ШАГ 8 (Windows-специфика): SSH config не создавать через Notepad — он добавляет .txt и сохраняет в UTF-8 с BOM. Правильный способ: PowerShell heredoc | Out-File -Encoding ascii -FilePath $HOME\.ssh\config. Блок Host: HostName <IP>, User gendesign, Port 22, IdentityFile ~/.ssh/gendesign_deploy, IdentitiesOnly yes, ServerAliveInterval 60. Критично включать IdentitiesOnly yes — иначе Windows OpenSSH перебирает все ключи и получает MaxAuthTries reset не дойдя до нужного

observations: ШАГ 9: Отключение root-логина и паролей в SSH. ТОЛЬКО ПОСЛЕ подтверждения gendesign работает и sudo работает. sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak; sudo nano /etc/ssh/sshd_config → PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes. sudo sshd -t для валидации. sudo systemctl reload ssh

observations: ШАГ 10: Критический тест в третьем окне: ssh gendesign → пускает по ключу. В четвёртом: ssh root@<IP> → должен отказать. Старую root-сессию закрываем только после этого

observations: Распространённые грабли: 1) Connection reset при неверном пароле = fail2ban Beget. Обход через VNC. 2) Notepad вместо config пишет config.txt — проверять ls $HOME\.ssh\. 3) Windows OpenSSH без IdentitiesOnly перебирает все ключи. 4) Группа sudo не подхватывается без выхода-входа. 5) При UNPROTECTED PRIVATE KEY FILE использовать icacls /inheritance:r /grant:r '<имя>:(R)'

observations: Статус 25.04.2026 вечер: Шаги 1-7+8 выполнены. gendesign@46.173.16.127 работает по ключу, sudo работает. Осталось: SSH hardening (Шаг 9), UFW firewall, установка Docker, клонирование репо в /opt/gendesign

observations: Статус 25.04.2026 вечер (обновлён): Базовая настройка VPS завершена. gendesign@46.173.16.127 работает по ключу, sudo работает. UFW активен (22/80/443). SSH hardening: PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes через drop-in /etc/ssh/sshd_config.d/00-gendesign-hardening.conf (приоритет 00- перебивает cloud-init defaults). Docker и git установлены. Репо клонировано в /opt/gendesign через deploy key github_deploy. PostgreSQL+PostGIS и Redis работают в докер-компоуз. PostGIS_Version() = 3.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1

observations: Осталось: GHCR setup (замена YCR на GHCR в deploy.yml + docker-compose.prod.yml), GitHub Secrets, Caddy reverse proxy, домен, первый автодеплой backend+frontend

observations: ВЕХА 25.04.2026 вечер: Первый успешный автодеплой. GitHub Actions воркфлоу deploy.yml прошёл полный цикл: build обоих образов (backend ~2.5мин, frontend ~1мин) → push в GHCR (ghcr.io/lekss361/gendesign-backend, gendesign-frontend, приватные) → SSH на сервер → docker compose pull (с PAT-авторизацией) → up -d. /health отвечает {status:ok, environment:prod}

observations: GHCR пакеты остаются ПРИВАТНЫМИ (решение пользователя для защиты алгоритмов). Сервер авторизуется в GHCR через PAT с read:packages, сохранён в ~/.docker/config.json. PAT с длительным сроком или без срока

observations: Исправлены во время деплоя: backend Dockerfile (убрал невалидный conditional COPY для alembic, перешли на uv sync без --frozen до генерации lockfile); frontend package.json (react-leaflet 4→5 для совместимости с React 19); frontend Dockerfile (npm install --legacy-peer-deps вместо npm ci, пока нет lockfile); frontend/public/.gitkeep для Next.js standalone build

observations: Статус инфраструктуры к 25.04.2026 19:00: VPS Beget работает (Москва, 2/4/40 NVMe). UFW + SSH hardening + non-root user. Docker compose prod поднят с 5 сервисами (postgres+redis+backend+frontend+caddy). GitHub Actions автодеплой работает на push в main. /health публичен внутри VM (127.0.0.1:8000)

observations: Осталось до «infra-ready»: домен, Caddy TLS с Let's Encrypt на этот домен, регулярные pg_dump в Object Storage, frontend NEXT_PUBLIC_API_BASE_URL на реальный домен (сейчас пустая). И дальше — Stage 1 разработки по выбранному PlanA_AnalyticsFirst_Apr25 (после понедельника с Антоном по ДДУ-данным)


entityType: test

observations: Тестовая запись, дата 25.04.2026 поздний вечер

observations: Цель: проверить, что после пересоздания хард-линка записи MCP попадают в репо-файл memory/memory-gendesign.jsonl

observations: Ожидаемый результат: размер репо-файла увеличится, git status покажет modified

observations: Наблюдение: предыдущий хард-линк разорвался (LinkType был null, синхронизация репо-файла с MCP-папкой прекратилась). Репо-файл был 16550 байт, источник 43957 байт

observations: Если тест пройдёт (синхронизация восстановлена) — рабочий цикл из README снова валиден. Если не пройдёт — нужен sync-memory.ps1 скрипт или альтернатива