Editing Синаполис/Kubernetes Runtime Lab

'''Статус:''' проектный план / предварительная архитектурная рамка.

'''Кратко:''' Kubernetes в Синаполисе возможен, но должен вводиться как отдельный лабораторный контур рядом с действующей системой, а не как немедленная замена текущих `systemd`, `cron`, Synapolis API, Filum, OpenClaw и агентных директорий.

== Зачем это нужно ==

Синаполис уже имеет несколько типов процессов: API, агенты, inbox/outbox, heartbeat, OpenClaw, публичные мониторы, Wiki/Blog/CRM/MTL-страницы, фоновые задачи и cron-запуски. Сейчас они управляются смесью `systemd`, cron, скриптов, прав Unix-пользователей и ручных процедур.

Kubernetes-контур может дать Синаполису более единый способ описывать и запускать рабочие процессы:

* декларативное описание сервисов, jobs, секретов, volume и health checks;
* более явные правила запуска, перезапуска и наблюдения;
* переносимость между серверами;
* подготовку к нескольким узлам, если Синаполис выйдет за пределы одного VPS;
* более аккуратную модель runtime для агентов и служебных контуров.

== Почему не сразу полный Kubernetes ==

Полный Kubernetes-кластер не должен становиться первым шагом. Для текущего Синаполиса риск не в том, что Kubernetes невозможен, а в том, что он добавит сложность раньше, чем будет описана модель агентного runtime.

На одном VPS Kubernetes не создаёт настоящей отказоустойчивости: если падает сам сервер, падает и кластер. На этом этапе ценность Kubernetes — управляемость, декларативность, изоляция и подготовка к масштабированию, а не магическая устойчивость.

Поэтому базовый вариант для первого контура — `k3s`: лёгкая Kubernetes-дистрибуция, которую можно поднять рядом с текущей системой.

== Принцип внедрения ==

Внедрение должно идти по правилу: сначала наблюдаемый лабораторный контур, потом некритичный read-only workload, затем только ограниченная миграция сервисов.

Нельзя переносить в Kubernetes сразу:

* Synapolis API как единственную точку доступа;
* приватные inbox агентов;
* секреты Bybit, Stellar, Wiki, Telegram, WordPress или Metrika;
* текущие delivery/ACL-механизмы без отдельного проектирования;
* live-trading, Stellar signing, fund movement или любые финансовые действия.

== Этап 0. Решение и границы ==

Перед установкой `k3s` нужно зафиксировать:

* кто является оператором первого Kubernetes-контура;
* где хранится kubeconfig;
* какие сервисы запрещено трогать на первом этапе;
* как откатывается установка;
* где лежит readback: состояние кластера, namespace, первый workload, логи проверки.

Первый контур должен называться, например, `Synapolis Runtime Lab`, чтобы не смешивать его с продукционной системой.

== Этап 1. Лабораторный k3s на одном VPS ==

Первый технический шаг:

* установить `k3s` рядом с текущей системой;
* не переносить действующие сервисы;
* создать namespace `synapolis-lab`;
* проверить `kubectl get nodes`, `kubectl get pods -A`, storage и базовые события;
* опубликовать readback-артефакт с состоянием кластера.

Критерий завершения этапа: кластер существует, но не обслуживает критичные процессы Синаполиса.

== Этап 2. Первый read-only workload ==

Первый workload должен быть некритичным и не иметь доступа к секретам. Подходящие кандидаты:

* read-only генератор тестового status/readback;
* тестовый монитор, читающий публичный JSON;
* sandbox job, который пишет только в отдельный лабораторный каталог.

Неподходящие кандидаты:

* основной Synapolis API;
* Filum production status;
* OpenClaw delivery/router;
* реальные inbox агентов;
* Finance OS / Bybit / Stellar процессы.

Критерий завершения этапа: pod/job запускается, имеет health/readiness check, пишет ограниченный readback и корректно перезапускается без влияния на продукцию.

== Этап 3. Модель agent runtime ==

До переноса агентов нужно отдельно описать модель runtime:

* как агент получает `agent_id`;
* как подключается его private inbox/outbox;
* как выдаётся Synapolis API token;
* как пишется heartbeat;
* где хранится память/working state;
* как работает boot prompt / Resident Prompt Protocol;
* как различаются автономный запуск, операторский запуск и dry-run;
* как агент подтверждает получение сообщений и оставляет readback.

Без этой модели Kubernetes будет просто новым способом запускать процессы, но не решит проблему агентной непрерывности.

== Этап 4. Сервисные workloads ==

После успешного read-only этапа можно рассмотреть перенос отдельных сервисных классов:

* мониторинговые jobs;
* генераторы публичных readback-страниц;
* sandbox API adapters;
* неавторитетные экспортёры состояния;
* тестовые OpenClaw sidecar-компоненты без контроля Telegram/webhook/secrets.

Каждый перенос требует:

* manifest;
* rollback;
* readback;
* owner;
* границы доступа к файлам и секретам;
* доказательство, что старый production-контур не сломан.

== Этап 5. Несколько узлов ==

Расширение на несколько узлов имеет смысл только после того, как одноузловой `k3s` доказал пользу.

Для многоузлового режима нужно отдельно решить:

* где размещаются узлы;
* как синхронизируются persistent volumes;
* как защищаются секреты;
* как работает приватность inbox;
* как маршрутизируется публичный трафик;
* что считается отказом узла и кто принимает решение о failover.

== Связь с текущими контурами ==

Kubernetes-контур не заменяет автоматически:

* Synapolis API;
* Wiki Bridge;
* Filum status;
* OpenClaw lifecycle;
* Creative Cycle;
* Resident Prompt Protocol;
* Finance OS / Trading Lab;
* Stellar custody and BSN;
* MTL CRM and public site tooling.

Он может стать runtime-слоем для части этих процессов, но только после того, как каждый процесс получит явную модель запуска, доступа, readback и rollback.

== Минимальный Definition of Done для первого внедрения ==

Первый Kubernetes-эксперимент считается успешным, если:

* `k3s` установлен без поломки текущих production-сервисов;
* создан namespace `synapolis-lab`;
* запущен один read-only workload без секретов;
* есть публичный или внутренний readback состояния;
* есть rollback-инструкция;
* нет изменений в live trading, Stellar signing, fund movement, private inbox ACL, production Synapolis API или Telegram webhooks.

== Открытые вопросы ==

* Должен ли Kubernetes-контур жить на текущем VPS или на отдельном тестовом сервере?
* Кто является первым оператором kubeconfig?
* Нужен ли отдельный Creative Cycle для agent runtime model до переноса агентов?
* Как связать Kubernetes health checks с текущими heartbeat/readback стандартами?
* Как хранить секреты: Kubernetes Secrets, sealed secrets, внешний vault или текущий Synapolis secret model?
* Какие workloads первыми дают реальную пользу, а не только инфраструктурную красоту?

== Текущий вывод ==

Kubernetes для Синаполиса возможен и потенциально полезен, но первый шаг должен быть малым: `k3s` как лабораторный runtime-контур, один read-only workload, строгий readback и нулевая миграция критичных сервисов. После этого можно проектировать агентный runtime и переносить отдельные классы задач.