Phase 0 — Proof-of-Concept: агент подключился → обнаружил конфигурацию → выдал аудит

Практический план · 2026-07-08 · цель: за 2–4 недели доказать, что read-only агент реально проводит advisory-аудит настройки. На основе index.md, 03, 04, 05.

Цель PoC (одно предложение)

Подключить агента read-only к одной системе с демо-конфигурацией, заставить его самостоятельно обнаружить структуру и автоматизации и выдать отчёт с флагами проблем — и проверить, что ≥70% флагов подтверждает человек.

Два трека — выбери стартовый

	Трек A — Odoo on-prem (рекомендую для первого PoC)	Трек B — Salesforce Dev Edition (для коммерческой релевантности)
Почему	Бесплатно, локально, за час; самый глубокий доступ (ORM + Python-код автоматизаций + SQL)	Доказывает «official out-of-box» через `@salesforce/mcp`; highest-value рынок
Стоимость	$0 (Docker)	$0 (Developer Edition / Trailhead Playground)
«Из коробки»-story	Средняя (ставишь MCP/ORM сам)	Сильная (официальный MCP, один конфиг)
Глубина аудита	Максимальная	Высокая (Metadata/Tooling API)

Рекомендация: начать с A (быстро и глубоко проверить саму идею аудита), затем повторить на B (это уже веха Фазы 1 «кросс-платформенность» + коммерческий showcase).

Трек A — Odoo on-prem, пошагово

1. Поднять среду (~1 час)

docker-compose с сервисами odoo:19 + postgres:16.
Создать БД с галочкой «Load demo data» — Odoo зальёт демо-записи и часть автоматизаций (готовый «грязный» материал для аудита).
Опционально накрутить долг вручную: добавить 5–10 кастомных полей (часть не заполнять), пару пересекающихся automation rules, дубли контактов.

2. Дать агенту доступ (read-only)

Создать сервисного пользователя с ограниченной ролью (принцип least-privilege из 05).
Вариант коннекта: (а) прямой XML-RPC (/xmlrpc/2/common → auth, /xmlrpc/2/object → execute_kw), либо (б) community MCP-сервер (tuanle96/mcp-odoo или ivnvxd/mcp-server-odoo) → подключить к Claude Code/Desktop одним конфигом.

3. Что агент читает (само-обнаружение)

Что	Вызов
Все модели	`search_read('ir.model', ...)`
Поля модели + метаданные	`fields_get(model)` / `ir.model.fields`
Автоматизации (+ Python-логика)	`ir.actions.server` (поле `code`), `base.automation`, `ir.cron`
Права/роли/правила	`res.groups`, `ir.model.access`, `ir.rule`
Записи для fill-rate/дублей	`search_read` + агрегации `read_group`

4. Аудит-эвристики (реализовать как чек-лист агента)

Мёртвые поля: кастомные поля с fill-rate < 5% на значимой выборке.
Дубли: совпадение email/phone/name среди контактов/лидов.
Конфликты автоматизаций: >1 активной автоматизации на одной модели с пересекающимся триггером.
Нет валидации: обязательные по смыслу поля без constraint.
Permission sprawl: роли с доступом шире, чем у 80% пользователей.
Застой: пайплайны/этапы без движения N дней; неактивные пользователи с лицензией.

5. Выход

Markdown-отчёт: инвентаризация + флаги, отсортированные по Impact×Effort, каждый флаг — с доказательством (какой объект/поле/запись).

Трек B — Salesforce Developer Edition, пошагово

Завести Developer Edition (developer.salesforce.com/signup) или Trailhead Playground (идёт с примерами приложений/флоу — готовый материал).
Установить Salesforce CLI, sf org login web → авторизация.
Подключить официальный MCP: npx -y @salesforce/mcp в конфиг Claude/Cursor (auth берётся из зашифрованных файлов CLI).
Агент читает: Metadata API retrieve (Flow/CustomObject/Profile/Role), Tooling API (Flow.Metadata, ApexTrigger.Body), SOQL (fill-rate/дубли), SetupAuditTrail, Reports API.
Те же аудит-эвристики → отчёт.

Критерии приёмки (falsifiable)

✅ Подключение: агент читает конфигурацию без ручной подготовки схемы (доказывает «self-onboarding»).
✅ Обнаружение: корректно перечисляет ≥90% автоматизаций и кастомных полей (сверка с UI).
✅ Аудит: выдаёт ≥10 флагов; ≥70% подтверждает человек-админ.
✅ Безопасность: сервисная учётка строго read-only; 0 записей/изменений в системе.
❌ Стоп-сигнал: если <50% флагов валидны → LLM-рассуждение по конфигу ненадёжно → сузить продукт до rule-based движка с LLM только на объяснениях.

Границы PoC (сознательно НЕ делаем)

Никакой записи/деплоя изменений (это Фаза 3, с sandbox + human-approve).
Пока одна система за раз (кросс-платформенность — Фаза 1).
Не трогаем amoCRM/Kommo (слабая API-поверхность — см. 03).

Что понадобится

Docker; аккаунт Salesforce Dev Edition; Node.js (для @salesforce/mcp); агент-раннер с MCP-клиентом (Claude Code / Desktop / Cursor); ~2–4 недели, 1 человек.

Риски PoC

⚠️ Демо-данных Odoo может не хватить для «реалистичной грязи» → докрутить долг вручную (шаг 1).
⚠️ Rate limits (см. 05): для скана батчить запросы; на Odoo Online — AUP ~1 rps (в on-prem неактуально).
⚠️ Community MCP Odoo — низкая зрелость → как fallback держать прямой XML-RPC.