Каталог app/skill/agent — это MarshHub

1. Что MarshHub есть сегодня (факты, не гипотеза)

MarshHub — хостинг статических сайтов для учеников Mars IT School. Работает на инфраструктуре Mars (Node.js + Express + SQLite), сайты раздаёт reverse-proxy с автоматическим TLS на поддоменах *.marshub.uz.

1.1 Деплой — три канала, один backend

• CLI — npx marshub deploy [--name x]: паковка директории в архив (без node_modules, .git, .env) → загрузка на сервер → извлечение в релиз-директорию → симлинк на текущую версию → живой сайт на https://<name>.marshub.uz.
• Веб-панель marshub.uz/panel — drag-and-drop zip, вход через Mars ID cookie.
• Telegram — бот Mars: Mini App (та же панель, авто-авторизация) либо просто отправить zip/index.html в личку, либо команда для готового шаблона.
• MCP-сервер (stdio) — инструменты для деплоя, списка сайтов, удаления, смены статуса, а также публикации/обновления отдельных страниц и управления доступом к ним.

1.2 Идентичность и права — уже есть, не нужно изобретать

• Mars ID — единый вход через Telegram, подписанный токен с полями «кто, имя, роль, telegram-id, email».
• Список доступа на сайт — массив telegram-id в базе; пусто/null = публичный сайт. Это уже готовый механизм ограничения видимости на уровне ресурса.
• Управление доступом к отдельным страницам — режимы «публично / по паролю / через Mars ID» — тот же принцип, включая гостевой доступ по паролю без аккаунта.
• Единая точка проверки «пускать/не пускать» на уровне edge-прокси перед раздачей сайта.

1.3 Безопасность контента — уже есть песочница по смыслу

• Заблокированные расширения (.php .sh .bash .cgi .pl .py .rb .exe .bat .cmd .ps1 .jar .war .jsp .asp .aspx) — сервер отклоняет любой исполняемый код при деплое. MarshHub принципиально сервит только статику (HTML/CSS/JS/картинки) — де-факто модель «никакого server-side выполнения», то есть встроенная песочница на уровне типа контента.
• Защита от path traversal, блокировка симлинков при распаковке архива.
• Лимиты: 50 МБ на деплой, 1 ГБ на пользователя, 5000 файлов на сайт, 20 сайтов на пользователя, ограничение частоты деплоев.
• Версионирование: хранятся последние 5 релизов, есть откат к предыдущей версии.

1.4 Обнаружение и статусы

• Публичная витрина всех сайтов без авторизации — уже прото-каталог.
• Жизненный цикл публикации: черновик → превью → альфа → бета → live — аналог «готово к публикации / ещё нет».
• Периодический автопостинг live-сайтов в кураторский Telegram-канал «Сайты учеников Mars» — ручная дистрибуция уже есть, просто не структурирована по типам.
• Монетизация вовлечённости уже подключена: внутренняя валюта школы (Mars coins) начисляется за первый деплой и за достижение отметки уникальных посетителей — экономический стимул публиковать уже встроен в платформу.

1.5 Чего пока нет (важно не приписать существующему)

• Нет понятия «тип контента» (app vs skill vs agent) — всё это просто «сайт» или «страница».
• Нет манифеста (кто автор, что делает, какие данные/разрешения запрашивает, какая версия протокола).
• Нет установки «внутрь ОС» — только просмотр по ссылке в браузере.
• Нет категорий/тегов, нет поиска по каталогу, нет рейтингов/отзывов.
• Нет ролевой модели «агент может действовать автономно» — прокси раздаёт статику, а поведение (если оно на JS) исполняется в браузере зрителя без каких-либо ограничений полномочий.

2. Модель: три типа сущностей в каталоге cosy

cosy — «второй мозг семьи»: у него есть линзы (память по темам и членам семьи), действия и автономные помощники. Три типа сущности каталога маппятся на разный контракт исполнения.

Ключевое архитектурное следствие: app и skill естественно ложатся на существующую модель MarshHub (статика, раздаётся по запросу браузером/UI cosy). Agent — качественно другое: ему нужен вычислительный процесс на стороне сервера или устройства, а не просто раздача файлов. Каталог может регистрировать агента (манифест, права, откуда брать код), но исполнение — это уже не роль хостинга статики, а роль отдельного рантайма (например, инференс через Mars Token Factory + фоновый воркер на устройстве cosy или на серверной стороне Mars). MarshHub в этой схеме — реестр метаданных и хранилище кода агента, не его исполнитель.

3. Публикация: ребёнок-оператор → каталог

Идея — переиспользовать существующий деплой-флоу почти без изменений, чтобы не плодить новую ментальную модель для ребёнка, который уже умеет деплоить через marshub deploy.

3.1 Что есть уже (используем как есть)

1. Ребёнок пишет app/skill/agent (с помощью агента-помощника cosy или Mars Code).
2. Деплой той же командой — тот же архив, та же проверка заблокированных расширений.
3. Тот же жизненный цикл статусов (черновик → … → live) — черновик становится записью в каталоге, когда готов.
4. Тот же Mars ID — автор идентифицирован по telegram-id, и это же поле — линк на семью/ребёнка.

3.2 Что нужно добавить (новое)

1. Манифест cosy.json в корне деплоя (по аналогии с манифестом PWA) — новый файл, который парсится сервером при деплое:

   {
     "type": "app | skill | agent",
     "name": "Семейный трекер оценок",
     "category": "учёба | быт | творчество | безопасность",
     "min_age": 10,
     "permissions": ["memory:read:grades", "memory:write:reminders"],
     "entry": "index.html",
     "agent_trigger": "cron:0 18 * * *"
   }

   Без манифеста деплой падает в старый режим «просто сайт» — обратная совместимость с уже опубликованными сайтами: они остаются просто сайтами, не приложениями каталога.
2. Новая таблица каталога в базе платформы: имя сайта, тип, категория, права, минимальный возраст, число установок, рейтинг — расширяет существующую таблицу сайтов, не ломает её.
3. Эндпоинт каталога с фильтрами по типу и категории — аналог существующей публичной витрины, но с фильтрами вместо плоского списка. Переиспользует ту же логику публичной выдачи.
4. Расширение жизненного цикла статусов: сегодня статусы управляют видимостью сайта. Для каталога финальный статус должен означать ещё и «прошёл модерацию» — нужен доп. статус или флаг подтверждения (родитель/ментор одобрил перед тем как app попадёт в семейный каталог). Это новый шаг поверх существующей машины состояний.
5. Рантайм-регистрация для agent: манифест с триггером должен не просто лежать в статике, а зарегистрировать задачу в отдельном воркере (новый сервис, по образу существующих периодических скриптов платформы — тот же паттерн «процесс + расписание», но новый процесс). Деплой с типом «agent» должен дёргать этот воркер, а не просто извлекать архив в раздаваемую папку.

4. Установка: устройство ↔ каталог ↔ автор

4.1 Схема потока

Ребёнок-автор (Telegram ID, Mars ID)
        │  деплой + манифест cosy.json
        ▼
MarshHub API (приём деплоя)
  → проверка заблокированных расширений (есть)
  → разбор манифеста, type=app/skill/agent (НОВОЕ)
  → запись в таблицу каталога (НОВОЕ)
  → релиз-директория сайта (есть)
        │
        ▼
GET /каталог?type=&category=  (НОВОЕ, аналог витрины)
        │
        ▼
cosy-ОС на устройстве члена семьи
  → показывает карточку (иконка, название, автор, права)
  → «Установить» = член семьи жмёт кнопку в UI cosy
        │
        ▼
Установка = запись в семейную БД cosy: {app_id, кем установлен, выданные права}
  + для app/skill: просто ссылка на URL (webview грузит сайт по требованию)
  + для agent: cosy отправляет команду рантайм-воркеру «активировать задачу для этой семьи»

4.2 Права и безопасность — переиспользуем Mars ID + список доступа, добавляем слой разрешений

Есть и переиспользуется:

• Идентификация автора — telegram-id через Mars ID, тот же подписанный токен — не нужна новая система входа.
• Список доступа на сайт — уже поддерживает ограничение видимости по списку telegram-id. Прямое применение: приватный семейный app виден только членам конкретной семьи.
• Режим доступа «войди через Mars ID, чтобы увидеть» — готовый механизм, тот же самый нужен для приватных семейных app без дополнительной разработки авторизации.
• Заблокированные расширения / раздача только статики — это и есть песочница уровня «app не может выполнить произвольный код на сервере». App/skill выполняются в браузере/webview устройства — их песочница — обычная браузерная изоляция по origin, это уже так и работает сегодня.

Нужно добавить:

• Слой разрешений поверх списка доступа: сегодня список доступа — это «кто видит сайт» (бинарно). Каталогу нужна модель «что именно app может прочитать/записать в семейной памяти cosy» — это не функция MarshHub (у него нет понятия «семейная память»), это код на стороне cosy-ОС, которая при установке app сверяет права из манифеста и просит подтверждение у родителя/ребёнка. MarshHub только хранит и отдаёт декларацию прав в манифесте — проверку и применение делает рантайм cosy на устройстве.
• Возрастной гейт — новое поле, фильтрует каталог в UI cosy по профилю ребёнка (данные о возрасте уже есть в связке Mars ID/учебного профиля — можно переиспользовать существующую проекцию «телеграм-id → профиль ученика», но это относится к Mars ID, не к MarshHub).
• Модерация перед публикацией в семейный каталог (см. 3.2, п.4) — родитель или ментор проверяет, поскольку дети публикуют инструменты друг другу, а не только смотрят сайты.
• Изоляция исполнения agent: agent — не статика, значит его код выполняется не в браузере зрителя, а на общем воркере. Здесь нужна отдельная песочница (в духе блокировки расширений при деплое, но для рантайма) — например, каждая задача агента исполняется в ограниченном процессе со списком разрешений из манифеста, без произвольного файлового/сетевого доступа сверх задекларированного. Это прямое расширение духа «заблокированных расширений», но применённое не к деплою файлов, а к рантайму — новый компонент, которого сегодня нет вообще.

5. Итоговая таблица: есть vs добавить

6. Ключевой архитектурный вывод

MarshHub сегодня закрывает большую часть задачи каталога «бесплатно», потому что он уже:

1. решил проблему простой публикации ребёнком (главная боль любого app store для детей);
2. решил идентичность автора через Mars ID;
3. решил базовую приватность через список доступа;
4. решил безопасность на уровне деплоя через заблокированные расширения и раздачу только статики;
5. имеет прото-витрину и прото-модерацию (жизненный цикл статусов).

Разрыв — в семантике (MarshHub не знает, что такое «app», «skill», «agent», «право», «установка») и в рантайме для agent (MarshHub — хостинг статики, agent требует активного вычислительного процесса, которого в модели MarshHub нет вообще).

Правильная стратегия: не переписывать MarshHub, а надстроить манифест и каталожный слой (новая таблица, новый эндпоинт, новое поле в деплое) поверх существующего API, и вынести рантайм агентов в отдельный сервис, для которого MarshHub остаётся местом регистрации и хранения кода, но не исполнителем.