Один контур для портфеля, решений, рисков и следующего действия.
Project Apps
Управленческий слой мобильного портфеля.
Один контур, в котором направления, продукты, приложения, гипотезы, решения и summary-экономика собираются в ясную рабочую систему. Сюда попадает не шум первички, а смысл, по которому уже можно принимать решения.
Люди
Работают через админку, канон и ручное управленческое решение.
API
Пишет продукты, приложения, решения, задачи и summary-слой.
MCP
Читает контекст, обзор портфеля, канон и блок внимания.
Граница
Сырые store-метрики и шум кабинетов остаются во внешних системах.
Админка для людей, API для записи и MCP для чтения контекста.
Направления, продукты, приложения, гипотезы, инсайты и решения.
Сырые события, сторы и рекламный шум остаются в нижних системах.
Контур
Один контур вместо разрозненных инструментов.
Здесь собраны смысл системы, её границы и единая точка входа в документацию.
Что находится внутри
Внутри фиксируется всё, что нужно для продуктового управления: карта портфеля, гипотезы, решения, задачи, канон и верхнеуровневая экономика.
Портфельная карта
Направления, продукты и приложения в одной структуре вместо разрозненных списков.
Управленческий цикл
Гипотеза → инсайт → решение → задача, с привязкой к продукту и контексту.
Summary-экономика
Только сводные сигналы по росту, рискам, рынку и monetization без мусора из первички.
Что остаётся снаружи
Нижние системы не заменяются. Они остаются источниками сырых данных, а Project+apps забирает только переработанный смысл.
Сырые события и метрика
Логи, установки, сырые дашборды и шум из кабинетов остаются на своём месте.
Store-первичка
Отзывы, рейтинги, позиции и выплаты заходят сюда только как summary-вывод.
Ручные расследования
Глубокий анализ живёт в первичных системах; штаб хранит только управленческое решение.
Структура
Как строится управленческий цикл.
Система читается по понятной цепочке: от рынка и продуктового смысла к зафиксированному действию.
Направление
Крупный рынок или смысловой контур: fitness, utilities, watches и соседние линии.
Продукт
Отдельная продуктовая идея с фокусом, health-состоянием и следующими шагами.
Приложение
Конкретная реализация продукта или спорный app-кандидат до подтверждения структуры.
Инсайт и решение
Summary-сигнал превращается в вывод, решение, задачу или смену портфельного статуса.
Документация
Документация собрана в одном месте.
Одна точка входа на приветственной странице, а внутри переключение по вкладкам: API, MCP и рабочий контракт для агента.
HTTP API
Основной write-контур для интеграций и внешних агентов.
Через API создаются и обновляются продукты, приложения, решения, задачи, канон и summary-слой. Всё пишется по токену, без обходных схем и без raw data.
Base URL: https://apps.farmchel.org
Header: X-Project-Apps-Token
Формат: summary only
Что писать
products, apps, decisions, tasks, signals, insights, economics.
Что важно перед записью
Сначала проверить допустимые direction_slug и поискать существующий объект, чтобы не создать дубль.
POST https://apps.farmchel.org/api/project-apps/products
PATCH https://apps.farmchel.org/api/project-apps/apps/{mobileApp}
POST https://apps.farmchel.org/api/project-apps/signals
MCP
Контур чтения и навигации по штабу.
MCP помогает агенту читать обзор портфеля, канон, карту продуктов и текущий блок внимания. Основной принцип остаётся прежним: MCP читает, API пишет.
Local MCP: http://127.0.0.1:8010/mcp/project-apps
Cursor-ready
Лучше для read-only контекста
Что читать
Overview, canon, attention, product search и портфельный ресурс без погружения в сырой слой.
Когда не писать через MCP
Если клиент не умеет передавать payload в tool call, запись должна идти только через обычный HTTP API.
{
"mcpServers": {
"project-apps": {
"url": "http://127.0.0.1:8010/mcp/project-apps"
}
}
}
Агентный протокол
Короткая рабочая схема, чтобы агент не плодил хаос.
Для агентов здесь зафиксирован простой алгоритм: сначала прочитать контекст, затем проверить существующие объекты, и только после этого создавать или обновлять записи.
MCP читает
API пишет
Опора на slug и store identity
Алгоритм без дублей
Прочитать канон, найти существующий продукт или приложение, затем выбрать PATCH или POST.
Что нельзя делать
Нельзя писать raw data, создавать фиктивные продукты ради чистоты таблицы и игнорировать устойчивые идентификаторы.
1. MCP: canon + search + overview
2. API: GET directions / products / apps
3. API: PATCH if found, POST if absent