offplan · online
Plan · agenda-2026-04-27

Agenda — Monday 2026-04-27 и следующая неделя

Activeplanagenda-2026-04-27
Created
2026-04-24

Этот файл — что делать в понедельник и дальше на неделе. Не меняет launch-plan-v3.md (канонический план). Действует как приоритет-лист, по результатам можно вносить правки в launch-plan-v3 в отдельной сессии.

🎯 Резюме — что делать первым делом

Priority #1: Визуальный ленгвич + брендбук через AI + Figma. Это основа всего — после этого делаем admin UX и все последующие визуальные задачи.

Priority #2: MCP wrapper (4.1.5) — архитектурное решение которое может изменить приоритет фаз. Обсудить с Ильёй реалистичность быстрой реализации.

Priority #3: Разобраться на каком агенте/модели автоматически запускается /resume — настроить так чтобы было правильно по умолчанию (см. секцию E ниже).

Note: Звонок с Надеждой (Dubai client) — ✅ уже просмотрен. Инсайты из него учтены в секции A.1 этого документа.

📋 Explicit список от Сергея (Monday tasks)

  1. Посмотреть видео от Ромы — competitor analysis (Dropbox «Competition Analysis»)
    • Звонок с Надеждой ✅ просмотрен, инсайты учтены в A.1
    • Оставшиеся: Cramon Creative, BuildMedia, Binyanovsky, DisplaceFate (старейшие на рынке)
    • Цель: понять что работает у конкурентов, что не работает, где наш UX-gap
  2. Сделать брендбук через AI используя нашу Figma
    • Получена Figma (пока без админки) — кормим Claude
    • Можно использовать Claude Design (новый инструмент)
    • Output: визуальный language, цветовая палитра, typography, button styles, component library direction
    • Это база для всех следующих визуальных задач
  3. Начать Фазу 1.6.3 (Visual language refresh) в первую очередь
    • Опирается на брендбук (пункт 2)
    • Status indicators (available/reserved/sold) — убрать светофоры
    • Typography, spacing, icon set
    • Плоское обновление palette без полного редизайна (тот в 4.3.5)
  4. Исследовать 4.1.5 MCP wrapper — полезность + возможность быстрой реализации
    • Обсудить с Ильёй: насколько быстро можно обернуть существующий API в MCP?
    • Scope: read-only vs read+write
    • Потенциальный impact: если MCP работает, значительная часть admin-функциональности может быть automated через Claude / GPT
    • Возможно этот пункт стоит перенести выше в плане — Сергей говорит «without MCP не запускаться»
  5. Фаза 1.2.7 Team management — начать прорабатывать
    • Критично для B2B (студия = несколько людей)
    • После обсуждения с Ромой — это гораздо сложнее чем в текущем плане. 5 уровней доступа (см. ниже секцию «Multi-level access»). Требует отдельной проработки
  6. Дать Илье план с пунктами из первой фазы
    • Отправить launch-plan-v3 (или его Стадию 1) — plans/launch-plan-v3.md
    • Просить:
      • Что уже готово / реализовано
      • Что нереализуемо / не нужно
      • Эстимейт по критичным задачам
      • Его фидбэк по приоритизации
  7. Фаза 1.1 (Security) — важно но не первоочередно
    • Сергей + Рома договорились: это базовый уровень (как «сходить в туалет»)
    • Илья даёт Илье, он просто удостоверяется что всё сделано
    • Не требует отдельного обсуждения менеджмента

🔍 Синтез из разговора с Ромой (2026-04-24)

Разговор добавил несколько новых моментов которых нет в launch-plan-v3 или которые требуют существенной корректировки. Всё разложено по темам.

A. 🔴 Критичные открытия (ломают текущий план)

A.1 — UX-флоу sales-app: фильтры вместо хотспотов (Надежда feedback)

Проблема: текущий флоу — заходишь в проект → видишь здание с хотспотами → клик на хотспот → юнит. Это ломается на больших проектах (300+ юнитов = 300 точек = хаос).

Правильный флоу (из звонка с Надеждой):

  1. Заходишь в проект → красивый лендинг (видео/360/галерея проекта)
  2. Клик «Floor Plans»
  3. Фильтры: по bedroom count (1BR / 2BR / 3BR...) + по view direction (на город / на море / на парк)
  4. Показываются только подходящие floor plans
  5. Клик на floor plan → показан стояк: все квартиры этого типа, статус (available / reserved / sold)
  6. Выбираешь конкретный юнит

Что это значит для плана:

Action: посмотреть звонок Надежды полностью, потом обсудить с Ромой + Ильёй.

A.2 — Multi-level access (signup гораздо сложнее)

Текущий план 1.2.1 и 1.2.7 описывает team management как «студия имеет несколько пользователей». Это неполно.

Реальная модель — 5 уровней доступа:

  1. VV master access — мы сами (Сергей, Рома, Илья) можем зайти в любой tenant для помощи
  2. Studio admin — владелец аккаунта студии (может всё внутри своего tenant)
  3. Studio employees — сотрудники студии с назначенными правами (назначаются admin'ом)
  4. Developer client (инвайт от студии) — клиент студии (девелопер) которого студия пригласила
  5. Developer client employees / agents — сотрудники / агенты девелопера (назначаются самим девелопером)

Каждый уровень имеет свои permissions, видит только свои проекты, может назначать роли только ниже своего уровня.

Что это значит для плана:

Action: расписать permission model отдельно перед тем как двигать 1.2.7 в работу.

A.3 — Domain strategy: проекты, не студии

Текущий план 1.2.2 + 1.2.3 говорит про «студия получает свой поддомен + может подключить custom domain».

Корректировка от Сергея:

Что это значит для плана:

Action: переписать описания 1.2.2 и 1.2.3 в следующей сессии.

A.4 — MCP wrapper должен быть раньше

Текущий план — 4.1.5 (MCP server wrapper) в Стадии 4, приоритет Низкий-Средний.

Позиция Сергея после обсуждения с Ромой:

«Нам нужно самим, для себя и вообще для всех, построить MCP wrapper вокруг всей нашей административной части, вокруг всего нашего API. Это нужно сделать как можно быстрее. Если MCP есть, клиент может тупо через Claude создавать проект. Без этого не запускаться.»

Что это значит:

Action в понедельник: обсудить с Ильёй — сколько времени займёт MCP wrapper? Можно ли параллелить с остальной Стадией 1?

B. 🟡 Уточнения / корректировки в существующих фазах

B.1 — Онбординг wizard (1.2.4)

B.2 — Demo-проект vs Empty-state (1.2.5)

B.3 — Email onboarding sequence (1.2.6)

B.4 — Фаза 1.1 (Security) — базовый уровень

B.5 — Фаза 1.3 (Admin UX Critical Blockers) — downgrade

B.6 — Admin upload formats

C. 🟢 Идеи / направления для проработки

C.1 — Airtable-like DB view для admin

Сергей показал в Craft mockup в стиле Airtable — grid-like view где видны все сущности, можно расширять, фильтровать, редактировать inline. Это фундамент Power Editor (Фаза 4.3.2), но возможно быстрее реализуется если взять готовое решение (Airtable API + custom UI) вместо полностью своего grid.

Action: посмотреть на Airtable как potential backbone для Power Editor.

C.2 — Три view параллельно (admin redesign)

Подход из разговора с Ильёй подтверждается:

  1. Classic view — текущий admin (продолжаем улучшать)
  2. Power Editor — Excel/Airtable-like для bulk operations + AI
  3. Visual Editor — inline на публичной странице (light-touch правки)

Новое от Ромы: возможно Visual Editor не заменит Classic даже в долгосрочной перспективе. Классик останется как «backup» для сложных операций.

C.3 — Brand book via Claude Design (новый инструмент)

Claude недавно выпустил Claude Design. Это меняет подход к визуальной работе:

D. 📞 Что обсудить с Ильёй (на звонке на этой неделе)

  1. MCP wrapper (A.4) — сколько времени? Можно ли раньше Стадии 4?
  2. Sales-app UX (A.1) — насколько готова архитектура к filter-based флоу? Это частичный rebuild?
  3. Multi-level access (A.2) — готова ли текущая архитектура к 5 уровням? Что нужно добавить?
  4. Domain strategy (A.3) — инфраструктура под per-project subdomains
  5. Upload formats backend (B.6) — когда выкатывается? Покрывает ли PDF / HEIC / прочее?
  6. 1.1 Security — какие из задач 1.1 реально нужны tech team'у, какие overkill?
  7. 1.3 Admin UX Critical Blockers — верифицировать на проде какие баги real, какие dev-only
  8. Backlog tech team — доступ (Сергей уже просил, ждём)
  9. Prod-like env (teremki.offplan.online) — когда будет готов

E. 🛠 Tooling — auto-model на /resume

Суть задачи: Понять какая Claude-модель автоматически активна когда я запускаю /resume. Хочу чтобы default был правильным — дешёвый Sonnet для обычной работы, а Opus включался только когда нужно (планирование, сложная архитектура).

Текущее состояние (проверить):

Что нужно сделать:

  1. Запустить Claude Code в чистой сессии → сразу /resume → посмотреть в статусной строке какая модель активна
  2. Если Opus — подкорректировать хук либо instructions чтобы default для /resume был Sonnet
  3. Если уже Sonnet — ничего не делаем, просто зафиксировать как ожидаемое поведение
  4. Опционально: сделать чтобы после завершения /plan модель возвращалась в Sonnet автоматически (но hooks не могут переключать модель сами — см. Learning «Claude Code hooks cannot switch model automatically»)

Варианты решения:

Стоимость вопроса:

Action в понедельник: провести эксперимент (шаг 1), принять решение по (a/b/c), реализовать.

📅 План на неделю (Monday → Friday)

Monday 2026-04-27

Утро:

День:

Вечер:

Tuesday-Wednesday

Работа:

Коммуникация:

Thursday-Friday

Sintesis:

🔑 Key Priorities в одну фразу

  1. Брендбук — основа визуальной работы
  2. MCP wrapper — потенциально архитектурный game-changer
  3. Multi-level access + domain strategy — корректировки плана
  4. Auto-model на /resume — tooling task (секция E)

📎 Ссылки