Единый источник инженерной правды

Маленькое ядро с жёсткими границами

Один Go-бинарник и PostgreSQL. Пять композиций из одинаковых байтов. Ядро решает платформенный допуск; продуктовые данные и окончательная бизнес-авторизация остаются у модулей.

Честная граница этого документаСхемы отражают замороженный код v1.0.0, публичные контракты и подтверждённый PROD-профиль. Будущие возможности помечены как roadmap и не изображаются как готовые.

Простыми словамиCore проверяет вход и платформенные ограничения. Product Module всё равно решает, можно ли этому субъекту работать именно с этим бизнес-объектом.

1 + 1Go-бинарник + PostgreSQL; без брокера, кэша и второй БД

5автономный, provider control, provider realm, Cell, Router

4глубоких публичных поверхности ядра

31текущий каталог internal/; Atlas следует коду, хотя исходный план упоминал 29

Четыре поверхности, один процесс

Это не обязательные микросервисы. Это владельцы решений и состояния, собранные в компактном профиле в одном процессе.

AUTHORITY

Кто действует и что ему можно

Идентичность, точный scope, live-ревокация, RBAC, Root, Agents, federation и политика раскрытия данных.

не авторизует бизнес-ресурс за модуль;
не импортирует роли и политики peer-а.

MODULE RUNTIME

Какие строительные блоки допущены

Подписанный manifest, deployment digest, enablement, workload identity, capability grants, UI contributions и readiness.

не устанавливает произвольный код;
не проксирует трафик модуля.

INTEGRATION

Как надёжно передаётся работа

Facts с outbox/inbox и Work с lease, fencing, retry, cancellation, DLQ, idempotency и bounded backpressure.

не event store;
не универсальный workflow engine.

ADMINISTRATION

Как система живёт и восстанавливается

Ключи, append-only Audit, миграции, backup/restore, health, диагностика, Cell lifecycle и capacity evidence.

не ambient support;
не обещает автоматический failover.

Пять композиций тех же байтов

Выбор выполняет PLATFORM_COMPOSITION; каждая композиция допускает только закрытый набор process roles и владельцев данных.

Composition	Основное состояние	Служит	Явная граница
`autonomous`	Authority + ModuleRuntime + Administration	локальная Installation, API/worker/maintenance	loopback listener за trusted ingress; без Provider
`provider-manager`	Provider Control	Tenant/Cell placement, move, quota, lifecycle	не хранит identity и tenant product data
`provider-realm`	Provider Realm	операторская identity и Tenant admission evidence	не принимает Cell-local resource decisions
`cell`	Cell Authority + ModuleRuntime + Administration + Capacity	bounded multi-tenant execution cell	таблиц password/passkey/external identity в композиции нет
`provider-router`	подписанная placement projection	mTLS ingress, route и bounded full-response proxy	не является Authority и не выбирает Tenant из caller header

Композиция исполнения

Стрелка означает вызов или доставку. Владелец продуктовых данных всегда остаётся за пределами Core.

request · синхронный вызов durable delivery · запись и receipt trust/evidence · подпись или assertion owns · владеет состоянием does not trust · связи нет

Текстовый маршрут схемы

Client приходит через trusted ingress.
Authority выводит principal и scope и принимает платформенное решение.
Module Runtime проверяет deployment и capability ceiling.
Product Module принимает окончательное решение по ресурсу.
Владелец пишет данные через собственную PostgreSQL role и forced RLS.

Полная карта исходных модулей

Фильтр ищет по имени, ответственности и классу. Тестовые и поддерживающие пакеты показаны честно, а не выданы за runtime-владельцев.

7Authority

5Module Runtime

3Integration

12Administration

4Cross-cutting

31 из 31

runtime ownerportable contractsupport / operationstest / optional / reference

Модуль	Поверхность	Ответственность	Класс
`administration`	Administration	Audit, trust, keys, recovery, exports, Cell operations	Core owner
`authority`	Authority	Scopes, RBAC, Root, Human/Agent, federation, data governance	Core owner
`backup`	Administration	Encrypted bundle, verify, restore, recovery anchors	Operations
`capacity`	Administration	Probes, quota, reservation, capacity admission	Operations
`cellrecovery`	Administration	Authority-free restored-Cell locking and reconciliation contract	Contract
`conformance`	ModuleRuntime	Neutral Reference Module for contract proof	Reference
`controlcontract`	Administration	Signed Provider/Cell control documents	Contract
`corecontract`	Authority	Principal, scope, security-governance and data-use semantics	Contract
`dbtest`	Cross-cutting	Disposable PostgreSQL and topology helpers	Test only
`encryptedstream`	Integration	Bounded authenticated chunk streams	Security support
`federationcontract`	Authority	Bilateral trust, exposure, assertion, epoch and signatures	Contract
`identityadapter`	Authority	Out-of-process OIDC/provisioning Adapter runtime	Optional process
`identityadaptercontract`	Authority	Portable identity Adapter seam	Contract
`identityrealm`	Authority	Authentication, sessions, recovery and step-up	Core owner
`integration`	Integration	Facts, Work, retry/DLQ, leases and queue controls	Core owner
`m8testsupport`	Cross-cutting	Canonical load/scale measurement harness	Test only
`maintenancecredentialfile`	Administration	Maintenance credential file validation	Security support
`migration`	Administration	Ordered owner waves, adoption and role policy	Operations
`modruntime`	ModuleRuntime	Admission, enablement, workload and Tenant-local lifecycle	Core owner
`modulecontract`	ModuleRuntime	Manifest, Connector, deployment and scope operations	Contract
`modulekit`	ModuleRuntime	Local/remote/MCP adapters and conformance helpers	Internal kit
`moduleprotocol`	ModuleRuntime	One-use admission tickets, discovery, signed authority contexts	Portable protocol
`offlineregister`	Administration	Offline trust/recovery anchors and successor rotation	Security support
`platform`	Cross-cutting	Composition root, HTTP ingress, gateways, roles and shell	Runtime shell
`privatefile`	Administration	No-follow reads resistant to symlink swaps	Security support
`providercontrol`	Administration	Tenant/Cell placement, move, quota, retirement, support relay	SaaS control
`providerrealm`	Authority	Provider operator identity, evidence and Tenant admission	SaaS control
`providerrouter`	Integration	Signed placement projection, bounded proxy, readiness	SaaS data
`runtimehealth`	Administration	Truthful bounded readiness/liveness tracking	Runtime support
`storage`	Cross-cutting	Scope-safe execution, role pools and maintenance fences	Storage adapter
`telemetry`	Administration	Bounded observations; never authoritative state	Runtime support

Atlas доступен, Core остаётся закрытым

Два HTTPS-адреса ведут только к автономному read-only HTML. Публичного router-а к Core API нет: продуктовый интерфейс и login boundary будут спроектированы отдельно.

Работает локально на сервере

platform-api — 127.0.0.1:18080;
platform-maintenance — 127.0.0.1:18081;
PostgreSQL TLS — 127.0.0.1:55434;
readiness обеих process roles подтверждён.

Публичен только Atlas

https://2chalks.com и https://platform.2chalks.com;
отдельный статический контейнер без host ports;
нет Traefik router-а к Core API, maintenance или PostgreSQL;
API-доступ откроется только вместе с отдельной моделью login/ingress.

Atlas hosts: 2chalks.com · platform.2chalks.com
Runtime identity: v1.0.0 · binary SHA-256 b542e1c95cd4c83ea62cca15bb86a8018bd27e6c66c98b1b4320d1fda5e4056d
Boundary: Core single-host loopback profile; автоматический failover и публичный SLO не заявлены

Живой каталог замороженного PROD

База как граница безопасности

Один PostgreSQL, но не одна всесильная runtime-роль: отдельные схемы, закрытые права, forced RLS и отсутствие межсхемных внешних ключей.

Снимок каталогаPostgreSQL 17.10, автономная композиция, 27 августа 2026. Числа ниже получены запросами к pg_catalog, не подсчётом строк документации.

146пользовательских таблиц, включая 4 migration ledger

279индексов в живом каталоге

117RLS-политик; все 117 scoped-таблиц с RLS принудительно защищены

0межсхемных FK и application role memberships

Autonomous / Realm

Identity, password, passkey, external identity и session state находятся в композиции владельца идентичности.

Cell

Identity-таблиц физически нет. Cell получает provider evidence и хранит только локально допущенные tenant-scoped authority данные.

Схемы и владельцы состояния

Public содержит только четыре таблицы версий миграций. Идентичность физически отсутствует в Cell-манифесте, а не фильтруется одним предикатом.

Схема	Таблицы	Индексы	RLS forced	Функции	Линия миграций
`authority`	83	164	68 / 68	20	31
`administration`	42	88	36 / 36	34	16
`module_runtime`	16	22	13 / 13	8	4
`foundation`	1	1	0	0	2
`public`	4 ledgers	4	0	0	goose metadata

Изоляция в трёх слоях

Каждый слой закрывает отдельный класс ошибки. Ни один из них не считается достаточным в одиночку.

trusted scopeowner boundarycross-owner write запрещён

Текстовый маршрут схемы

Trusted ingress выводит scope на сервере.
Go owner открывает типизированную scoped transaction.
Отдельная runtime role ограничивает доступ к таблицам и функциям.
Forced RLS повторно проверяет tenant/scope внутри PostgreSQL.
Эффект остаётся в таблицах одного владельца; межсхемных FK нет.

Что показал глубокий анализ

Не только сильные стороны: здесь зафиксированы исправленные узкие места и честные пределы текущего профиля.

Runtime role	Схема	Таблиц	Фактические классы прав
`authority_runtime`	`authority`	83	SELECT, INSERT, UPDATE, DELETE — только через owner API и forced RLS
`administration_runtime`	`administration`	35	SELECT, INSERT, UPDATE; append-only Audit не получает DELETE
`administration_api_runtime`	`administration`	6	SELECT
`administration_maintenance_runtime`	`administration`	6	SELECT, INSERT
`administration_portability_runtime`	`administration`	10	SELECT
`module_runtime_runtime`	`module_runtime`	14	SELECT, INSERT; lifecycle mutation выполняют закрытые owner functions
`module_runtime_recovery`	`module_runtime`	3	SELECT

Защита каталога

148 FK, из них 0 пересекают схемы владельцев.
0 функций доступны PUBLIC на EXECUTE.
у всех 62 пользовательских функций задан явный search_path.
application-ролей в членствах ролей — 0; три членства относятся только к встроенному pg_monitor.
runtime Audit может добавлять историю, но не удалять её.

Эффективность

Work claim переведён на индексируемый порядок; добавлена миграция reference/00016.
Cell data-use больше не захватывает второе соединение внутри транзакции.
пулы и claim batch ограничены, используются lease/fencing и SKIP LOCKED.
миграции выполняются offline owner-wave с advisory fence.

Executable schema: db/migrations/ · internal/migration/manifest.go
Scope-safe SQL: internal/storage/
Claim hot path: internal/conformance/reference/postgres/work.go · reference/00016

Не заявлено: автоматический PostgreSQL failover, multi-primary, шифрование тома силами Core или online mixed-version migration. Это ответственность выбранного deployment profile и отдельной приёмки.

Только то, что реализовано в коде

Двустороннее доверие без общего центра

Два точных root scope обмениваются подписанным transcript. Они не объединяют базы, каталоги пользователей, роли, политики или деревья ресурсов.

Главное правилоPeer доказывает, кто он и что запросил. Разрешение всегда заново вычисляет локальная сторона — по своей exposure, RBAC, data-use policy и правилу владельца ресурса.

2независимых Root подтверждают exact trust epoch

5production peer HTTPS operations

Ed25519purpose-separated canonical signatures

TLS 1.3обязателен; cross-peer mTLS не заявлен

Протокол доверия и сходимости

Worker повторяет те же canonical bytes после рестарта. Каждое изменение привязано к точному trust epoch и локальному владельцу.

InvitationRoot A предлагает exact scopes и keys
AcceptanceRoot B независимо проверяет и подписывает
ExposureВладелец объявляет доступный capability
AssertionОдноразовый запрос exact audience/resource
RotationНовое поколение control/access key
AckPeer подтверждает transcript
ReconcileDesired и observed state сходятся
TombstoneДоверие закрывается терминально

Ed25519 · canonical documentTLS 1.3 · transportнет импорта peer roles/policies

Текстовый маршрут схемы

Root A подписывает invitation по canonical bytes.
Root B независимо проверяет endpoint, scopes, epochs и key proofs.
Каждая сторона хранит собственный trust state и exposure.
Доступ использует одноразовый assertion, после чего локальная сторона заново проверяет RBAC, data-use policy и правило Product Module.
Rotation, acknowledgement, reconciliation и tombstone выполняются restart-safe worker-ом.

Решение по удалённому доступу

Все семь проверок — пересечение, а не импорт чужого allow. Любой deny закрывает путь.

Текущий trust epochОба Root приняли точные scope, Federation ID, key set и transcript.
Локальная signed exposureВладелец ресурса явно выставил exact capability и audience.
Локальный Root admissionРазрешены peer principal, capability, audience и origin-qualified resource.
Авторизация источникаУ исходного principal есть live federation.access.request на текущей policy revision.
Одноразовый assertionЦель проверяет подпись, epoch, audience, ресурс, сроки и atomic replay fence.
Решение Product ModuleМодуль отдельно проверяет бизнес-отношение к своему ресурсу.
Data governanceДля protected bytes правило должно отдельно разрешать principal kind federated_guest.

Что шифруется и подписывается

canonical JSON документы подписываются Ed25519;
назначения ключей разделены: control и access;
SHA-256 связывает transcript и exact bytes;
HTTPS TLS 1.3 даёт конфиденциальность в пути;
private signing seeds находятся вне PostgreSQL.

Что намеренно не изображается готовым

нет cross-Federation mTLS/DPoP sender constraining;
нет application-layer encryption документов;
протокол не переносит Product Module content или bearer secrets;
нет транзитивной федерации и центральной policy-службы;
HSM/KMS и volume encryption — профиль развёртывания.

Public wire contract: OpenAPI · security profile
Protocol values: internal/federationcontract/
Authority owner: lifecycle · convergence
Transport: TLS client · peer ingress

Permit-only, default-deny

Политики не подменяют владельца ресурса

Core принимает платформенное решение и контролирует выход защищённых данных. Модуль всё равно принимает окончательное доменное решение.

Исправлено в remediationМногострочная data-use policy теперь не зависит от порядка правил; Cell и Installation одинаково перевалидируют полный Agent run и не используют stale evidence.

Девять ворот раскрытия данных

Только после последнего шага владелец эффекта получает sealed admission. Caller не может прислать собственные classification, decision или policy revision.

Платформенная авторизация

scope выводится сервером;
live Account/Membership/grant/epoch;
RBAC capability на Workspace/Space/ResourceRef;
optimistic policy revision;
step-up для привилегированных действий;
Root имеет отдельные, непередаваемые обычным admin-путём правила.

Data-use policy

типизированные закрытые правила, не DSL;
0 или 1 human approval — quorum engine не симулируется;
правила независимы от порядка;
principal kinds сопоставляются точно;
deny не превращается в непроверенный allow;
изменение байтов требует нового digest и решения.

Граница: Core v1 не содержит Rego/Cedar/OPA и не пытается описывать все доменные отношения. Сложная политика конкретного продукта принадлежит Product Module.

Nine-step gateway: internal/modulekit/data_use.go
Policy evaluator: internal/authority/data_governance.go
Typed administration: security admin HTTP
Portable schema: data-governance.schema.json

Authentication ≠ authorization

Пять классов principal, один доверенный контекст

Способ входа доказывает личность и assurance. Права возникают только после отдельной live-проверки scope, Membership, роли, capability, epoch и текущей policy revision.

Текущая federation-модельPeer assertion создаёт только federated_guest. Он не получает чужую роль, не становится workload и не может выдавать транзитивные assertions.

Principal	Как аутентифицируется	Как ограничивается	Не может
Human	Password/Argon2, WebAuthn/passkey, OIDC через Adapter, session	Membership, roles, scope epoch, AAL/step-up	выбрать trusted scope заголовком
Workload	отдельный bound credential; Remote Module дополнительно private mTLS	deployment, grant, audience, credential epoch	использовать human cookie
Agent	sponsor + workload execution grant + exact run evidence	ceiling, delegation, credential epoch, expiry, live access revision	самостоятельно расширять полномочия
Federated guest	one-use peer-signed access assertion	trust epoch ∩ exposure ∩ local admission ∩ module rule	импортировать peer role или chain federation
Support / maintenance	purpose-bound operational credential and ceremony	time window, exact action/scope, audit, process role	ambient unrestricted access

Путь решения

Portable RequestAuthorityContext — результат доверенного resolver-а, а не JSON, которому верят на входе.

credential evidencelive authorizationfinal module decision

Текстовый маршрут схемы

Credential подтверждает способ аутентификации и assurance.
Trusted resolver проверяет подпись/secret, свежесть и replay.
Live context заново получает actor, effective principal, scope, epochs и policy revision.
CheckPlatform проверяет RBAC, capability, target и step-up.
Product Module отдельно решает доступ к своему бизнес-ресурсу.

Реализовано

local account, Argon2, passkey/WebAuthn;
sessions, refresh rotation, recovery, revoke, AAL2 step-up;
OIDC IdentityConnection stage/apply/activate/disable/retire;
workload и Agent principals;
provider identity lease и Cell-local Membership;
типизированный security-admin API с audit.

Коннекторы по триггеру

SAML — через официальный Adapter, когда нужен заказчику;
SCIM — внешний provisioning Adapter/public server отдельно;
upstream single logout — после подтверждённого сценария;
public OAuth authorization server/consent — для third-party apps;
HSM/KMS custody — для соответствующего production profile.

Human sessions: internal/identityrealm/ · auth HTTP
RBAC and scope: internal/authority/
OIDC Adapter: runtime · contract
Agent live evidence: agent principal

Remote Module Protocol v1

Внешний модуль больше не зависит от Go internal

JSON Schema, OpenAPI, canonical fixtures, contract-set digests и независимый consumer формируют language-neutral boundary для отдельного репозитория и любого языка.

Не завышать контрактFacts, Work и data-governance — owner-port contracts, а не выдуманные публичные HTTP endpoints. OpenAPI описывает только реально обслуживаемые admission/discovery routes.

3реально обслуживаемых Remote Module HTTP routes

≤ 30 sодноразовый human admission ticket

≤ 15 ssigned authority context

0импортов родительского internal/ в независимом consumer

Human → Remote Module

Core session cookie остаётся в Core. Module backend предъявляет свой workload credential на отдельном private listener.

Семейство	Машиночитаемая форма	Что гарантирует	Доступность
Manifest + Connector	JSON Schema + fixtures	identity, artifact digest, capabilities, operations, egress binding	public contract
Admission + authority context	Schema + OpenAPI + signatures	single-use human handoff без утечки cookie	served
Capabilities	Schema + OpenAPI	runtime discovery без ложной рекламы SAML/SCIM/OAuth	served
Facts	JSON Schema + fixtures	outbox/inbox, receipts, retry, DLQ, reconciliation	owner port
Work	JSON Schema + fixtures	claim, lease/fence, checkpoint, cancellation, terminal receipt	owner port
Data governance	JSON Schema + fixtures	classification/disclosure evidence без возможности подделать verified value	owner port
UI + lifecycle	JSON Schema + fixtures	immutable contributions, readiness, credential rotation	contract
Federation	отдельный contract-set + OpenAPI	bilateral peer trust и convergence	separate protocol

Для внешних приложений: standalone SPA/mobile/desktop и third-party delegated clients не маскируются под Module workload. Им нужен отдельный public ApplicationClient/consent/token design; это roadmap, а не скрытый endpoint v1.

Contract digest: contract-set.json
HTTP surface: OpenAPI · production handler
Independent consumer: conformance/remote-module-v1/
Integration guide: Product Module guide

После заморозки v1.0.0

От ядра к первому продукту

Принятый и воспроизводимый Core release уже заморожен и запущен в закрытом PROD. Следом — frontend shell и один вертикальный Product Module, который докажет контракты на реальном сценарии.

Правило roadmapПопулярность технологии и запас «на будущее» не являются триггером. Новая инфраструктура появляется только после измеренного предела или конкретного customer requirement.

Этапы 1–9

Remediation реализован

DB bootstrap, data policy, security admin, federation convergence, Remote Module Protocol, queue/router bounds, evidence tooling и закрытый PROD.

готово в коде

Freeze + release

Platform Core v1.0.0

Normal/race, retained M8, deep assurance, reproducible bytes, final PROD smoke, evidence index и private GitHub Release.

выполнено

Следом

Frontend shell

Domain-neutral navigation, session/scope UX, module slots, accessible design system и typed client только к опубликованным Core APIs.

после v1 release

Vertical slice

Первый Product Module

Отдельный owner schema/role, manifest, workload, UI contribution, Facts/Work, final resource policy и protected-data path.

после shell seam

Evidence

HA / RPO / RTO profile

Внешний PostgreSQL failover/fencing, backup schedule, restore drills и fault-domain evidence на точной конфигурации.

до HA claim

Triggers

Enterprise connectors и platform splits

SAML/SCIM, OAuth clients, HSM/KMS, delegated Tenant admin, broker/cache/service extraction — только по отдельным измеримым триггерам.

не Core v1

Freeze identity

Source revision: v1.0.0
Core binary SHA-256: b542e1c95cd4c83ea62cca15bb86a8018bd27e6c66c98b1b4320d1fda5e4056d
Schema / contract set: foundation@2 · authority@31 · cell-authority@10 · module-runtime@4 · reference@16 · administration@16 · module-contract:4c17394b32cb315d2b374f41f2a01688471425914000a34c431afdf7a0c9c39f · federation-contract:8b246460907e7a4f3a11f954ad3610c048a9ca1030869668985891dd2ebb1542
Production profile: autonomous-core · loopback API/maintenance · PostgreSQL TLS 1.3
Public documentation: 2chalks.com · platform.2chalks.com; no public Core API router