Герцогство AHEAD 2.0: как устроено новое управление, Пульт AMS, два Mac и iPhone

Восемь разделов и восемь наглядных схем: как работает обновлённое Герцогство 2.0 без бюрократии, как устроен новый Пульт управления деятельностью (AMS + Asana), как идеи превращаются в продукты за 5–30 минут, кто такие Главный Архитектор, Канцлер, Проектный директор HEADAI и Стюард, и как связаны твой iPhone, два компьютера Mac и сервер VPS.

В Герцогстве 2.0 (Приказ Р-734) убрана любая бумажная волокита между агентами. В центре стоит Владелец — Герцог (Дмитрий). Над техническими трениями стоит Главный Архитектор (Antigravity / HD-ARCH), который держит связность всей системы. Законы и ревью договоров ведёт Канцелярия (Claude), быстрые выкатки делает Компактный Штаб 2.0 (Codex), а 24/7 на сервере работают 26 боевых профилей Hermes во главе с Проектным директором HEADAI.

По закону §82 Конституции у тебя есть строго 3 входные двери, куда можно сказать любую идею голосом или текстом: 1) Дворецкий Джарвис, 2) Продуктовый визионер VISIO (HD-002), 3) Главный Архитектор (Antigravity). Дальше система сама везёт задачу по одной из двух скоростных дорожек: по Дорожке 1 («Зелёный коридор») сначала за 5–30 минут делается живой визуальный прототип на *.pult.navidad.ae, ты смотришь глазами и говоришь «Да», после чего идёт полная сборка. А изменения законов и сервера идут по Дорожке 2 («Канонический тракт») через Главного Архитектора.

Главный пульт управления деятельностью (https://pult.navidad.ae/) построен вокруг единого источника задач — Asana — и чёткой управленческой вертикали: Ты (Герцог) задаёшь цели и принимаешь решения, HEADAI (HD-001) работает как жёсткий Проектный директор (контролирует сроки, блокеры и портфель проектов), а Стюард (S11 / ag004-steward) работает как Проектный менеджер, который руками ведёт порядок в Asana и собирает входящие задачи из Plaud AI, почты, Telegram и голосового Джарвиса.

Твоя цифровая среда работает как единое кольцо из четырёх узлов, связанных защищённой сетью Tailscale: Стационарный MacBook Pro (домашний сервер 24/7, адрес 100.98.4.15), Дорожный MacBook Air (ноутбук-близнец для поездок, адрес 100.83.150.71), iPhone 15 Pro Max и боевой сервер Ahead VPS. Стационарный Mac каждые 30 минут бесшумно синхронизирует рабочие папки на дорожный (road-sync), а в поездке дорожный Mac передаёт наработки обратно командой road-push.

На обоих твоих компьютерах в нижней панели (Dock) выстроен одинаковый порядок программ: ChatGPT Desktop (Codex) — для Штаба 2.0, голосового Джарвиса и 10 проектов PRJ; Claude Desktop — для Канцелярии (00-stavka), вычитки договоров и Академии; Hermes Desktop — для прямой связи с 26 агентами на сервере; Antigravity — твой Главный Архитектор; и Командный Пульт Герцогства (duchy) — единая кнопка проверки здоровья всей системы.

Как устроены современные ИИ-системы: Модели, Агенты, Память, MCP и Голосовой ИИ

Шесть фундаментальных разделов со схемами: чем отличается языковая модель (LLM) от ИИ-агента, как собирается «голова» агента и почему важен Prompt Caching, что такое протокол MCP и скиллы, как работают локальные модели на чипах Apple Silicon (Whisper) и как правильно управлять роем агентов.

Самая частая путаница в мире ИИ — не различать Модель (LLM) и Агентную систему. Модель (например, Claude 4.6 Opus, GPT-5.4, Gemini 4) — это гигантский «мозг в банке»: она умеет только читать текст и предсказывать следующий текст или просить вызвать функцию. Сама по себе модель не может нажать кнопку, прочитать файл на диске или зайти на сервер. А вот Агентная система (Antigravity, Claude Code, Codex App, Hermes Agent) — это тело и руки вокруг модели: она даёт модели доступ к терминалу, файлам, браузеру и базам данных, выполняет её команды и проверяет результат в цикле до победы.

В Герцогстве AHEAD ты используешь четыре лучшие в мире ИИ-среды, и у каждой — своя суперсила:

Чтобы ИИ не был «рыбкой Дори», которая всё забывает в каждом новом чате, современная архитектура ИИ делит знания агента на 4 умных слоя. Самый важный секрет скорости и экономии денег называется Prompt Caching (Кэширование промпта): базовая инструкция агента (его SOUL.md, CLAUDE.md, память MEMORY.md и оглавление навыков) собирается ровно один раз в начале беседы и замораживается. Поэтому сервер платит за неё в 10 раз меньше и отвечает мгновенно, а подробные инструкции (SKILL.md) агент подгружает только тогда, когда они реально понадобились!

Не все задачи нужно отправлять в платное облако. В процессорах твоих компьютеров Mac (Apple Silicon M-серии) встроен мощный нейронный блок (GPU + Neural Engine) с единой быстрой памятью. Именно поэтому мы развернули на твоём Mac локальный движок распознавания речи mlx-whisper (модель Large-v3-turbo): он расшифровывает многочасовые аудиозаписи с точностью человека прямо внутри твоего ноутбука — абсолютно бесплатно, без интернета и со 100% секретностью (ни один звук не покидает твой компьютер).

1. Говори цель и образ результата, а не технические шаги. Тебе не нужно диктовать агенту, какую команду набрать в терминале. Скажи: «Хочу, чтобы на телефоне и компьютере была единая Академия со схемами» — а технический маршрут выберет Архитектор.
2. Правило «Сначала покажи глазами». Для любого нового сайта, пульта или интерфейса требуй сначала живую ссылку на *.pult.navidad.ae. Один взгляд глазами заменяет 20 страниц ТЗ.
3. Один чат = одна крупная тема (гигиена контекста). Когда диалог разрастается до сотен сообщений на разные темы, внимание любой модели размывается. Закончили крупный проект — зафиксировали итог в Памяти или Академии и открыли свежий быстрый чат.
4. Используй мультиагентность (Рой субагентов). Когда задача большая (например, проверить 26 профилей или разобрать 10 папок), Главный Архитектор или Claude запускает параллельных помощников-субагентов — это ускоряет работу в 5–10 раз.
5. Всё важное сразу превращай в Навык (Skill) или Главу Академии. Если мы нашли крутое решение один раз — мы записываем его в SKILL.md для агентов и в Академию AHEAD для людей. Так система становится умнее каждую неделю.

Как устроен Hermes Agent и как с ним работать на сервере

Одиннадцать разделов: из чего состоит Hermes, где его файлы и базы, как собирается «голова» агента перед ответом, как подключаются модели, какие есть четыре вида агентов, где хранить твои данные, и как всё это ложится на Ahead. В конце пошаговый рецепт создания агента на сервере.

Hermes — это одна программа на Python, которая живёт на сервере как постоянный процесс (шлюз). Внутри неё цикл агента: получить сообщение, собрать запрос, спросить модель, выполнить инструмент, повторить, ответить. Сама модель снаружи. Всё, что агент помнит и умеет, лежит в одной папке на диске. Эту папку называют профиль.

Профиль по умолчанию — папка ~/.hermes пользователя, под которым запущен Hermes. Каждый дополнительный агент — папка ~/.hermes/profiles/имя/ с тем же набором файлов. На сервере Ahead домашняя папка Hermes задана явно: /srv/ahead/services/hermes/data у службы ahead-hermes (права 0700, .env 0600). Ниже каждый файл и зачем он.

Модель ничего не помнит между вызовами. Поэтому перед каждым обращением Hermes собирает ей полный запрос из слоёв: кто ты, правила проекта, что ты помнишь, какие рецепты и инструменты есть, что было в этом разговоре, и наконец, что сказал пользователь. Порядок важен: верхние слои меняются редко и кэшируются провайдером, это экономит деньги.

Важное следствие для Ahead: правила проекта живут в AGENTS.md в репозитории, и их читает любой агент любой платформы. Личность конкретного агента живёт в его SOUL.md. Не смешивать: первое про проект, второе про роль.

Настроек два файла и одна командная строка. config.yaml для всего несекретного, .env для ключей и токенов, флаги команды для разового переопределения. Команда hermes config set сама решает, куда писать: имена ЗАГЛАВНЫМИ идут в .env, имена с точками в config.yaml.

# кто главнее (сверху вниз)
1. флаг команды        hermes chat --model anthropic/claude-sonnet-4
2. config.yaml         model: anthropic/claude-sonnet-4
3. .env                ANTHROPIC_API_KEY=...   (секреты только здесь)
4. встроенные умолчания

# примеры
hermes config set model anthropic/claude-opus-4      # → config.yaml
hermes config set OPENROUTER_API_KEY sk-or-...        # → .env
hermes config check                                   # что не хватает / устарело
hermes setup                                          # мастер для новичка
hermes model                                          # выбрать провайдера и модель интерактивно
hermes tools                                          # включить инструменты по платформам

Главные разделы config.yaml

Что лежит в .env

OPENROUTER_API_KEY=...          # или ANTHROPIC_API_KEY / OPENAI_API_KEY
TELEGRAM_BOT_TOKEN=...          # у каждого профиля свой бот
TELEGRAM_ALLOWED_USERS=123456   # твой числовой id; чужих бот игнорирует
GATEWAY_ALLOWED_USERS=123456
HERMES_TIMEZONE=Europe/...      # для cron
# никакого GATEWAY_ALLOW_ALL_USERS=true на сервере

Модель — это строка провайдер/имя в config.yaml плюс ключ в .env. Провайдер — тот, кто принимает запрос и выставляет счёт. У одного агента обычно три модели: основная (думает), вспомогательная дешёвая (сжимает историю, смотрит картинки) и запасная (если основная упала). Субагентам можно назначить свою, дешевле.

Инструмент — это то, что агент может сделать сам, без тебя. Инструменты собраны в наборы (toolsets), и набор зависит от того, откуда пришёл запрос: из терминала агент может всё, из Telegram меньше, из cron ещё меньше. Это настраивается командой hermes tools.

Песочница: где агент выполняет команды

Настройка terminal.backend. local — команды выполняются прямо в Ubuntu от имени пользователя Hermes, с его правами. docker — каждая команда в одноразовом контейнере с лимитами CPU, памяти и диска, без доступа к остальной системе. Для агента, который слушает Telegram на сервере с продом, документация рекомендует docker. Внутри контейнера проверки опасных команд отключаются: контейнер и есть граница.

MCP: телефонная книга сервисов

MCP (Model Context Protocol) — стандартный способ дать агенту инструменты внешнего сервиса. Сервер MCP либо запускается рядом как процесс (stdio), либо живёт у поставщика по адресу (http). Инструменты появляются у агента с префиксом mcp_имя_.

# config.yaml
mcp_servers:
  asana:                                   # Asana через OAuth
    url: https://mcp.asana.com/v2/mcp
    auth: oauth
    oauth: { client_id: "${ASANA_CLIENT_ID}", client_secret: "${ASANA_CLIENT_SECRET}",
             redirect_host: localhost, redirect_port: 27890 }
  github:                                  # GitHub локальным процессом, токен из .env
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env: { GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}" }
    tools: { include: [list_issues, create_issue, get_pull_request] }
  ahead_db:                                # твоя база Postgres (любой MCP-сервер для Postgres)
    command: npx
    args: ["-y", "@modelcontextprotocol/server-postgres", "${AHEAD_DB_URL_RO}"]

# затем: hermes mcp login asana   (один раз, токен ляжет в mcp-tokens/)

Слово «агент» в Hermes означает четыре разные вещи, и для Ahead важно их не путать. Профиль — постоянный сотрудник. Субагент — временный помощник внутри одного ответа. Cron-запуск — тот же сотрудник, разбуженный будильником без памяти о разговоре. Группа Bot Mode — несколько сотрудников в одной комнате.

Два разных вопроса. Данные агента (что он помнит и что говорил) живут в его папке профиля, и это устроено Hermes. Данные Ahead (контакты, финансы, проекты, документы) должны жить отдельно, в твоей базе и твоих папках, а агенты ходят к ним через инструменты. Нельзя класть бизнес-данные в память агента: блокнот на 2200 знаков, а архив разговоров не база данных.

Куда класть свои базы: три варианта по росту

1. Файлы в рабочей папке. Markdown, CSV, JSON в /srv/ahead/workspace. Агент читает и пишет инструментами файлов. Хватает для старта и для знаний.
2. Postgres в контейнере рядом. Для контактов, финансов, задач. Агенту даётся пользователь только на чтение через MCP; запись только через проверенные скрипты или через приложение, которое напишут разработчики.
3. Внешние системы правды. Asana для поручений, Google Drive для документов, Obsidian для решений, GitHub для кода. Агенты ходят туда через MCP, у себя ничего не дублируют.

Сессия — это один разговор с историей. В Telegram сессия чата живёт бесконечно, пока ты не сказал /new. Документация советует начинать новую сессию на границе темы: так история не распухает и сжатие не теряет важное. Всё, что было, остаётся в state.db и находится поиском.

Ahead шире Hermes. В Ahead три слоя: управляющие роли, программное ядро Core и среды исполнения. Hermes — одна из сред: интерфейс для разговора и исполнитель инструментов в пилоте. Правила, мандаты, очередь поручений, журнал эффектов и приёмка принадлежат Core и ролям, а не Hermes.

Чем Hermes отличается от Core и от ролей

Из этого следует главное правило интеграции: Hermes не получает права независимо от Core менять одни и те же рабочие объекты. Hermes общается, рассуждает и вызывает инструменты Core; Core проверяет мандат и пишет журнал; один scheduler на канон. Два runtime не инициируют один бизнес-эффект.

Путь одного поручения в Ahead

Обращение владельца / разрешённый источник
  → HEADAI: разбор, ответственный, зависимости
  → CODEX: цель и критерии, если нужна продуктовая постановка
  → одна каноническая задача Asana + ограниченный TaskEnvelope
  → Core: идентичность, роль, мандат, версия, scope
  → устойчивая очередь → допущенный исполнитель / инструмент   ← здесь может стоять Hermes
  → артефакт + фактические IDs + квитанция + readback
  → предметная / техническая проверка, продуктовый вердикт CODEX
  → ARBITER в своей области и при существенных отклонениях
  → принятие результата → Asana + знания + наблюдения в интерфейсе

Сравни с разделом 4: там цикл одного агента. Здесь тот же цикл сидит внутри шага «допущенный исполнитель». Всё, что выше и ниже него, Hermes не делает: не ставит задачу в Asana сам, не выдаёт себе мандат, не принимает результат. Состояния задачи: proposed → scoped → ready → running → presented → verified → accepted, плюс waiting_human, waiting_host, outcome_unknown. Потерянный ответ сервиса не повторяется вслепую: сначала сверка, затем решение о повторе.

Что работает, когда Mac выключен

Сущности Ahead и механизмы Hermes: что можно, что решено

Что подтверждено и что открыто (срез R17, 13:01 UTC 10.10.2026)

Сверка моих предложений с решениями Ahead

На первой странице я предлагал несколько вещей от себя. По пакету они не являются решениями Дмитрия. Где есть действующий источник, он главнее.

Пример для Хедая. Для остальных профилей тот же порядок с другим именем и другим SOUL.md. Команды выполняются по SSH под пользователем, от которого работает Hermes (не root).

1. Создать профиль и выбрать модель.

   hermes profile create hedai            # папка ~/.hermes/profiles/hedai/ и команда-алиас hedai
   hedai model                            # мастер: провайдер и основная модель
   hedai config set agent.max_turns 40
   hedai config set terminal.backend docker
   hedai config set terminal.cwd /srv/ahead/workspace

2. Дать характер и роль. Файл ~/.hermes/profiles/hedai/SOUL.md: кто он, восемь областей ответственности, три уровня самостоятельности, что всегда возвращать тебе, язык ответов. Одна страница, конкретно.
3. Дать правила проекта. Файл /srv/ahead/workspace/AGENTS.md в Git: структура папок, источники правды, что нельзя, как оформлять задачу в Asana, ступени готовности. Его прочитают и Hermes, и Codex, и Claude Code разработчиков.
4. Завести бота и пустить только себя. В Telegram у @BotFather создать бота, токен в profiles/hedai/.env:

   TELEGRAM_BOT_TOKEN=...
   TELEGRAM_ALLOWED_USERS=твой_числовой_id
   chmod 600 ~/.hermes/profiles/hedai/.env

5. Включить инструменты по платформам. hedai tools: для Telegram без терминала, если не нужно; для cron минимум. Проверить hedai config check.
6. Подключить сервисы. В config.yaml профиля блок mcp_servers (Asana, GitHub, Postgres только чтение), затем hedai mcp login asana.
7. Запустить как службу и проверить.

   hedai gateway install                  # служба hermes-gateway-hedai
   hedai gateway status
   journalctl --user -u hermes-gateway-hedai -f
   # написать боту «привет, кто ты?» и прочитать ответ

8. Проверить ступени готовности (срез 08). Описано: SOUL.md и AGENTS.md в Git. Настроено: config check чистый. Проверено локально: hedai chat -q "перечисли свои инструменты". Проверено с реальным источником: агент прочитал задачу из Asana и пересказал. Принято: ты подтвердил один законченный цикл. Эксплуатируется: служба в автозапуске, cron, бэкап папки профиля.
9. Дать будильник. В чате: «каждый будний день в 8:00 пришли сводку: открытые задачи Asana с просрочкой и что ждёт моего решения». Проверить: hedai cron list, hedai cron run имя.
10. Второй агент за минуту. hermes profile create finance --clone-from hedai --clone копирует config, .env (без бота), SOUL.md, скиллы и память; затем свой SOUL.md, свой токен бота, свой MCP-ключ к базе.

Повседневная наладка

• Порт веб-дашборда в официальной документации не указан; на сервере Ahead он проверен: 127.0.0.1:9119, туннель на Mac 19119.
• Подключение приложения Hermes на Mac к профилям на VPS: документация описывает «Create on» для нескольких подключений, но точный способ настройки проверить в приложении.
• Hostinger AI Router: описание из поддержки Hostinger; состав моделей и цены смотреть в hPanel.
• Раздел 10 построен на пакете передачи Codex от 10.10.2026 (AHEAD-CONTEXT.md, SOURCEBOOK.md, asana-readback.json) и на «WIKI AHEAD». Это чтение сохранённых доказательств до среза R17 13:01 UTC, не live-аудит VPS.
• Пример «hedai» в разделе 11 — учебный рецепт создания профиля, не решение о размещении HEADAI в Hermes: триада живёт в контекстах Codex.

Источники, проверены 10 октября 2026: Configuration · Memory · Context files · Skills · Tools · MCP · Profiles · Delegation · Cron · Bot Mode · Security · CLI reference · Messaging gateway · Hostinger: Hermes на VPS · WIKI AHEAD: content/docs · пакет передачи: PRJ-0016-private-office-os/handoff/claude/2026-10-10/ (AHEAD-CONTEXT.md, SOURCEBOOK.md, source-manifest.json, asana-readback.json).

Как устроен VPS с Hermes и как ты с ним работаешь с Mac

Часть I: семь схем от общей картины до того, где лежат файлы. Часть II: как на тот же сервер посадить двух разработчиков с Claude Code, чтобы твои планы превращались в продукты. Цвет на всех схемах одинаковый: оранжевое — ты и твой Mac, бирюзовое — разработчики, синее — сервер, фиолетовое — чужие сервисы снаружи, зелёное — данные.

VPS (Virtual Private Server) — это кусок большого компьютера в дата-центре Hostinger, который отдали тебе целиком, как отдельную машину. У него своя операционная система (Ubuntu), свой IP-адрес, свой диск. Он не выключается, когда ты закрываешь ноутбук. Hermes живёт там, а ты с Mac только подключаешься.

Hostinger ставит Hermes через Docker Manager. Это значит, что Hermes запущен не «прямо в Ubuntu», а внутри контейнера. Контейнер — это коробка с программой и всем, что ей нужно, которую можно целиком снести и поставить заново, не трогая остальное. Рядом стоит Traefik — швейцар на входе, который принимает HTTPS-соединения с порта 443 и передаёт их нужному контейнеру.

У тебя четыре разных способа попасть на сервер, и они нужны для разного. Панель Hostinger (hPanel) — это не внутри сервера, это управляющая компания: она может выключить, переустановить, сделать снимок. SSH — твой ключ от двери в Ubuntu. Telegram — домофон к дворецкому. Приложение или веб-интерфейс Hermes — то же самое, но с экраном.

Про панель 127.0.0.1:19119, которую ты уже видел на Mac: это локальный веб-интерфейс Hermes. Чтобы та же панель показывала сервер, её либо запускают на VPS за Traefik, либо прокидывают через SSH-туннель (команда ssh -L 19119:localhost:19119 root@IP), и тогда адрес на Mac остаётся локальным, а данные идут с сервера.

Это главная схема. Всё остальное — обвязка вокруг этого цикла. Ты пишешь «проверь, что в Asana горит на этой неделе». Дальше происходит вот что.

В Hermes агент = профиль. У каждого профиля своя папка (свой HERMES_HOME), а значит свой конфиг, своя память, свои сессии, свои навыки, свои cron-задачи и, если нужно, свой Telegram-бот. Профили запускаются командой hermes -p имя и могут работать одновременно, каждый как отдельная служба. Внутри одного агента ещё бывают субагенты: временные помощники для параллельной подзадачи, они умирают, когда подзадача сделана.

Это место, где люди теряют всё. Контейнер можно пересоздать, но данные должны лежать на диске вне контейнера. Диск VPS тоже не вечен: случайная команда или переустановка ОС через hPanel стирают его полностью (Hostinger об этом прямо предупреждает). Поэтому нужны три копии разного вида.

Повседневный цикл. Ты сидишь за Mac, сервер работает сам.

Где именно делать каждое действие

Словарь

Задача: ты с Hermes и Claude Code придумываешь продукт и пишешь план. Двое ребят берут план, строят с Claude Code, тестируют в песочнице и отдают обратно тебе или во внешние сервисы. Всё на одном VPS, у каждого свой аккаунт, одна общая рабочая область.

Принцип: один сервер, но три зоны с разными правами. Штаб — твой, там Hermes и секреты прода. Мастерская — у разработчиков, каждый под своим Linux-пользователем, без root. Прод — отдельные контейнеры, в которые код попадает только через слияние в главную ветку, а не руками. Единая рабочая область держится не на общей папке, а на трёх общих вещах: репозиторий в GitHub, доска задач и файл правил CLAUDE.md, который читает Claude Code каждого из вас.

Главная схема части II. Каждый шаг — один столбец доски задач. Разработчик сам берёт карточку из столбца «Готово к работе», и это единственный момент выбора: никто не раздаёт задачи вручную. Обратно к тебе задача возвращается не словами, а ссылкой на стенд и PR.

Что лежит в «пакете задачи» (шаг 2)

Это то, что ты и агенты производите в штабе, и единственное, что разработчику нужно, чтобы начать. Пакет лежит в репозитории в папке docs/tasks/123-название/ и ссылается с карточки на доске.

Разработчик сидит за своим Mac, но код и Claude Code живут на сервере. Он подключается по SSH под своим пользователем (например dev-a), открывает терминал или VS Code с удалённой папкой и запускает Claude Code там. Claude Code входит в его собственный аккаунт Claude, поэтому лимиты и счёт его, а не твои. Файл правил CLAUDE.md в корне репозитория один на всех: там стек, стиль, запреты и команда для тестов. Так три разных Claude ведут себя как один.

Это то, что делает «отдельные места» отдельными. Права выдаёт root, то есть ты, один раз при заведении пользователя. Главный принцип: разработчик может сломать только свою папку и свой стенд. Прод и штаб он не видит даже случайно.

Как это делается технически, одной строкой на каждое: отдельные Linux-пользователи (adduser dev-a), SSH только по ключам, Docker людям не выдаётся (стенды поднимает раннер), защита ветки main в GitHub (слияние только через PR с одобрением), файлы прода с правами только для root, GitHub Secrets для выката.

С чего начать: порядок заведения

1. Репозиторий и правила. Один приватный репозиторий в GitHub на продукт, в корне CLAUDE.md с правилами и docs/ для пакетов задач. Защита ветки main: слияние только через PR с твоим одобрением.
2. Доска. GitHub Projects при репозитории, шесть столбцов как на схеме 9. Если удобнее Asana, то карточки там, а ссылка на PR обязательна.
3. Пользователи на сервере. dev-a, dev-b с SSH-ключами, без sudo, с правом поднимать стенды. Твой dmitry отдельно от root.
4. Стенды. Один шаблон docker-compose.yml с переменной имени PR и правилом Traefik pr-NNN.dev.домен с паролем. Домен *.dev.домен направить на IP сервера.
5. Автотесты. GitHub Actions: тесты, линтер, сборка образа на каждый PR. Красный PR нельзя слить.
6. Выкат. Действие «из main в прод»: сначала вручную тобой, потом автоматически.
7. Агент приёмки. Профиль Hermes или команда Claude Code, которая берёт критерии из пакета задачи, ходит на стенд и пишет отчёт в PR.
8. Первая задача. Маленькая, на день, через весь путь от идеи до прода. Это проверка конвейера, а не продукта.

Разделы 8–12 описывают рабочую модель. Здесь честная рецензия на неё: одна ошибка, два узких места и список забытого.

Ошибка на схеме 10: Docker для разработчиков

Доступ к Docker на Linux равен правам root: человек из группы docker может смонтировать любой диск и прочитать секреты прода. Поэтому строка «группа docker-dev» неверна. Правильно: стенды поднимает автоматика по событию PR, разработчик Docker не трогает совсем. Матрица в разделе 11 тогда честная.

Два узких места

• Один сервер на прод и мастерскую. Чужая сборка съела память, упал прод; ошибочная очистка Docker снесла тома. Лучше: KVM 8 под штаб и прод, второй дешёвый VPS под мастерскую и стенды. Схема не меняется, меняется адрес стендов. Пока сервер один: лимиты памяти на контейнеры стендов и прод в отдельном Docker-проекте.
• Ты как единственный приёмщик. Уедешь на неделю, конвейер встанет. Агент приёмки проверяет критерии и пишет отчёт в PR, разработчик проходит чек-лист сам, ты смотришь только продуктовые вещи. Одному из ребят право слить низкорисковый PR после зелёных тестов и отчёта агента.

Что пересмотреть в идее

• Работа на сервере по SSH не обязательна. Договор между вами: репозиторий, CLAUDE.md, автотесты. Где стоит редактор, не важно. Вариант без доступа к серверу вообще: облачные сессии Claude Code (claude.ai/code), подключённые к GitHub. Для минимальной команды это самый безопасный путь.
• Продукты ребят часто сами будут агентами: навык Hermes, MCP-коннектор, новый профиль. Для них «прод» — твой штаб. Значит, в песочнице нужен отдельный тестовый Hermes, где навык проверяется до попадания в боевой профиль.
• Роли инструментов не смешивать. Hermes: связь, расписание, отчёты, приёмка. Claude Code: код.

Забытые элементы

Порядок разворачивания

1. Домен, DNS, файрвол, бэкапы с проверкой восстановления. Ещё без команды.
2. GitHub-организация, репозиторий, CLAUDE.md, доска, защита main, автотесты.
3. Стенды из автоматики по PR, тестовый Hermes в песочнице.
4. Один разработчик, одна маленькая задача через весь путь до прода.
5. Второй разработчик, агент приёмки, мониторинг.

Что не подтверждено и где проверить

• Состав контейнеров шаблона Hostinger: в инструкции Hostinger названы только Hermes Agent и Traefik. Реальный список покажет docker ps на твоём сервере.
• Порт и адрес веб-панели Hermes на сервере в официальных документах не указаны. Панель 127.0.0.1:19119, которую ты видел, локальная; её связь с VPS нужно настроить отдельно.
• Хранение профилей: в документах сказано, что у каждого профиля свой HERMES_HOME и своя служба. Точный путь подпапок смотри командой hermes profile list.
• Часть II — проектное предложение, а не описание уже существующего. Хватит ли KVM 8 на штаб, два верстака, несколько стендов и прод одновременно, покажет первая неделя: смотреть htop и docker stats. При нехватке памяти стенды переносят на второй, дешёвый VPS, схема при этом не меняется.

Источники: Hostinger: Hermes Agent на VPS · Hermes: Messaging Gateway · Hermes: Architecture · Hermes Agent (Nous Research). Проверено 10 октября 2026.

Герцогство Ahead: как оно устроено и как работает

Семнадцать разделов и пятнадцать схем: зачем Ahead нужен, кто в нём главный, из чего он состоит, как проходит одно поручение, где живут данные, что стоит на сервере, с чем герцогство связано снаружи, как рождается продукт, как выглядит обычный день, где границы, и по каким этапам всё это строится. Простым языком, со статусами «решено», «подтверждено», «открыто».

Ahead — личный частный офис Дмитрия, в котором люди, AI, приложения и автоматизация делают предметную работу в одной понятной системе. Две цели: освободить внимание владельца от текущих личных дел и создавать, проверять и передавать в использование продукты. Рабочая модель называется кентавр: AI делает основную предметную работу, человек даёт данные, следит за качеством и разбирает исключения, автоматизация доводит разрешённые действия до конца и записывает результат.

Всё, что делает Ahead, относится к одному из двух контуров. Личный офис создаёт результаты для жизни и работы Дмитрия: цели, проекты, календарь, контакты, финансы, поездки, дом, здоровье, обучение. Внутренний контур создаёт и обслуживает сам Ahead: фабрики, знания, инфраструктуру, публикацию, контроль. Контур определяется целью действия, а не инструментом. Один и тот же GitHub может служить и личному проекту, и фабрике.

Три управляющие AI-системы равны по месту и различны по предмету. HEADAI организует: принимает поручения, назначает ответственного, следит за зависимостями и контрольными точками. CODEX отвечает за продукт: потребность, требования, критерии, продуктовая приёмка. ARBITER отвечает за правила, исправность, происхождение и доказательства. Любое изменение программного состава Ahead допускается только двумя положительными решениями HEADAI и ARBITER на одну и ту же версию. Спор о полномочиях решает Дмитрий.

Человеческая часть герцогства описана функциями. Их восемь, и один человек может совмещать несколько, если сохраняются компетенция и независимость проверки. Должность не выдаёт доступ к личным данным и право действовать от имени человека; доступ проверяется в сервисе, а не в файле.

В пакете названы: Семён Корнеев как общий инженер первого выпуска TRIAD-R1 и ответственный за core, I1/I2 и интеграцию (это роль, а не назначение в Asana, где все карточки временно на Дмитрии). Остальные имена не выдумываются.

Каталог Ahead — это 52 участника и 88 функций, итого 140 паспортов. Восемь агентств объединяют 18 предметных направлений, у каждого направления есть паспорт и рабочая инструкция AGENTS.md. 88 функций — это 78 предметных плюс 10 общих, и у каждой ровно один владелец. Четыре уже существующих исполнителя фабрики переиспользуются. Важно: это охват описания и будущей приёмки, а не 140 работающих процессов.

Это главная схема. Любая работа в Ahead идёт по одному маршруту: от обращения через разбор, одну каноническую задачу Asana, проверку мандата в Core, допущенного исполнителя, артефакт с квитанцией, независимую проверку и принятие. У поручения один ответственный. Состояние задачи видно на каждом шаге, и «задача передана», «код написан», «сервис отвечает», «результат принят» — разные состояния.

Что происходит, когда что-то идёт не так

Core — программное ядро на Python с одной базой SQLite и одним писателем. Оно не думает и не управляет. Оно детерминированно проверяет права, бюджеты, версии, повторы и внешние эффекты, а LLM предлагает и исполняет внутри разрешённого маршрута. Core хранит шесть видов записей, и у каждой есть версия.

У каждого вида данных одно каноническое место и один писатель. Между участниками передаются ID и ссылки, а не копии. Портал, Core, Hermes и чаты только показывают проекции. Это защищает от самого частого сбоя таких систем: двух редактируемых копий одного и того же.

Весь backend и вся разработка живут на одном Hostinger KVM 8 (8 vCPU, 32 ГБ, 400 ГБ NVMe, Дюссельдорф, оплачен до 09.10.2027). Mac и телефон — пульты. Модели работают у внешних провайдеров, сервер хранит приложения, инструменты и состояние. На сервере три среды с разными пользователями, лимитами памяти, базами и портами: dev для трёх инженеров, staging для кандидата на выпуск, live для принятой версии.

Герцогство окружено четырьмя видами внешнего мира: провайдеры моделей, облачные сервисы, устройства и клиенты владельца, внешние люди. Через границу проходят только определённые вещи, и у каждой есть правило.

У каждой сущности Ahead один ID и три блока. Паспорт полностью описывает сущность, основания, источники и архитектуру, и из него выбирается ограниченный первый выпуск с критериями. Разработка — самостоятельное пространство реализации выбранного выпуска: Asana, код, ревью, песочница, evidence, передача. Agent Studio показывает установленную и принятую версию, фактические настройки, состояние и результаты. Изменение возвращается в Паспорт и идёт тем же кругом.

Две стадии в Asana. Стадия A — подготовка: оформление, продукт и бизнес-анализ (CODEX), исследование (Gemini, Grok), архитектура (Claude), подготовка разработки, готовность. Стадия B — цикл разработки: цель цикла, инженерная работа, PR со ссылкой на задачу, ревью, выпуск с допуском, закрытие. Работа без Asana-карточки и вне стадии и мандата блокируется; пока это документированное правило, техническая блокировка впереди.

Конституция делит решения на три яруса. Стандартная предметная работа и операционные решения внутри мандата выполняются AI самостоятельно с сохранённым основанием. Существенное решение или новый мандат готовится AI, а принимает уполномоченный человек. Изменение самой системы проходит допуск HEADAI + ARBITER, а новые права и расходы остаются за владельцем.

Полная последовательность сборки из мастер-плана и Asana (305 карточек, 14 разделов). Этапы 3–5 и 6 идут параллельно и сходятся на этапе 7. Цвет показывает состояние по срезу R17: что сделано, что частично, что открыто. Это учёт, не процент готовности.

• Не принимает runtime: пересказ сохранённых доказательств до R17 не заменяет live-аудит VPS и приёмку по критериям.
• Не закрывает карточки Asana и не меняет назначения.
• Не поручает новую инфраструктуру, перенос, второй VPS, Postgres или новые права.
• Не добавляет решений: там, где вики или пакет говорят «не решено» (размещение ролей, порог skill, маршрут Claude, второй сервер), здесь тоже «не решено».
• Имена людей взяты только из пакета: Дмитрий, Маргарита (оператор по плану), Семён Корнеев (инженер TRIAD-R1). Остальные функции без имён.

Источники: пакет передачи PRJ-0016-private-office-os/handoff/claude/2026-10-10/ (AHEAD-CONTEXT.md, SOURCEBOOK.md с 38 источниками, source-manifest.json, asana-readback.json). Прямо прочитаны: ARCHITECTURE, CENTAUR-MODEL, IMPLEMENTATION-CONTRACTS, HEDAY-ENGINEERING-DESIGN, CONNECTORS-AND-SKILLS, KNOWLEDGE-AND-VERSIONS, HOSTINGER-SINGLE-SERVER-PLAN, HOSTINGER-HERMES-OWNER-GUIDE, HOSTINGER-LAUNCH-PROGRESS, HERMES-CONTROL-AND-INTEGRATIONS, ROLE-MAPPING, R15, VPS-исследование. Остальные через структурированный дайджест. Связанные страницы: VPS и Hermes · Как устроен Hermes Agent. Навигация проекта: GitHub · Asana PRJ-0016 · портал.

Как работать с ИИ и документами в системе AHEAD (Руководство для команды)

Четыре простых и наглядных урока для профильных специалистов команды, которые не занимаются программированием: как устроена модель работы «Кентавр», в каких папках хранить документы, как правильно называть файлы и как за 2 минуты проверять договоры и таблицы с помощью Claude и ChatGPT.

Если вы юрист, бухгалтер, финансист или помощник руководителя — вам вообще не нужно знать программирование или открывать терминал. Вся работа строится по модели «Кентавр»: ИИ-помощник за 2 минуты делает долгую черновую работу (вычитывает 40 страниц договора, ищет скрытые штрафы, сверяет таблицы, готовит рыбу письма), а вы — как профильный эксперт — проверяете суть, вносите правки и принимаете профессиональное решение.

1. Единый вход для новых файлов (00_inbox): все новые несортированные документы кладутся в папку 00_inbox на Google Drive (или в 50-59_ai/53_exchange/in, если это задание для ИИ-агента). На Рабочем столе разрозненные рабочие файлы не хранятся.
2. Золотой стандарт имени файла:
   ГГГГ-ММ-ДД_Тема_Статус_v01.расширение
   Примеры: 2026-10-28_Договор_поставки_review_v01.docx, 2026-10-28_Бюджет_Остен_approved_v02.xlsx.
3. Запрещённые слова в названиях: никогда не пишите слова новый, последний, финал2, точно_финал. Вместо этого просто меняйте номер версии (v01 → v02) и статус (draft → review → approved → signed).