title: GOLDJAXE Brand OS v3 · CONSTITUTION type: constitution version: 1.0 status: ratified description: "Главный документ Brand OS v3 — источник правды дисциплины стандартов холдинга GOLDJAXE Enterprise. Читается первым любым новым участником команды. Преамбула + принципалы + 5 типов стандартов + 5 хозяев + 3 слоя soft RBAC + 4 триггера эскалации + workflow + 5 уроков Brand OS v3 + история версий + ревизия. Дата ратификации CEO ROOT: 2026-05-21." maintainer: Mission Control (CEO ROOT-сессия) ratified_by: Сергей Архангельский (CEO ROOT) ratified_at: 2026-05-21 review_cycle: 2 недели (или после значимых событий) next_review: 2026-07-12 related: - brand-os/owners.md - brand-os/templates-index.md - brand-os/AI-ATTEMPTS-LOG.md - command/decisions/2026-05-21-standards-constitution-roadmap.md

🏛 GOLDJAXE Brand OS v3 · CONSTITUTION¶

Это главный документ Brand OS v3. Все правки эталонов холдинга, все RBAC-решения, все workflow — отсчитываются от этой Конституции.

Дата ратификации: 2026-05-21 (CEO ROOT Сергей Архангельский · после закрытия Этапов 0+1+2+3). Следующая ревизия: 2026-07-12 (плановая ревизия 28.06 проведена · 0 регрессий за окно 04-28.06 · см. AI-ATTEMPTS-LOG «Soft RBAC review 2026-06-28»).

1 · Преамбула¶

Что такое Brand OS v3¶

Brand OS v3 — операционная система дисциплины стандартов холдинга GOLDJAXE Enterprise. Это третья попытка наведения порядка в эталонах холдинга, после провалов v1 (13-15.05.2026) и v2 (15-21.05.2026, застрял на 28%).

Brand OS v3 = набор правил, артефактов и процедур которые обеспечивают что: - В репо холдинга физически не может быть 3 копий одного эталона - Каждый тип стандарта имеет одного операционного хозяина под CEO ROOT - Правки эталонов проходят через predictable процесс routing к хозяину типа - Расхождения между Claude-сессиями ловятся на раннем этапе (soft RBAC) - При срабатывании триггеров эскалации — автоматический переход к hard enforcement через CI/hooks

Зачем существует Brand OS¶

Главная проблема: стандарты холдинга разбегаются между сессиями Claude и руками core team. Прецедент — в репо design.goldjaxe.ai до Brand OS v3 одновременно лежало 3 копии лендинга .ai: - ecosystem-prototype/2026-05-09/ai/landing.html (старая версия) - ecosystem-prototype/_ai-rebuild-2026-05-18/ai/landing.html (эталон до 21.05) - ecosystem-prototype/_ceo2-version-2026-05-11/ai/landing.html (CEO2 эксперимент)

Никто не знал какая копия главная. Правки шли в разные копии. Через месяц — 3 разные версии. CEO жаловался много раз.

Brand OS v3 делает это физически невозможным — через 5 типов стандартов × 5 хозяев × SSoT в canonical/ × soft RBAC enforcement.

Для кого этот документ¶

Аудитория	Что должны взять отсюда
Новый Claude в новой сессии	Понять как устроена дисциплина стандартов холдинга за 15 минут
Новый сотрудник core team	Понять кто за что отвечает и как правильно вносить правки
Я (Mission Control) через 2 недели	Вспомнить контекст и правила когда забуду детали
Артём (Maintainer goldjaxe-skills)	Понять когда от него нужна реализация hard enforcement
Внешний reviewer / аудитор холдинга	Понять зрелость процессов холдинга в одном документе

Стратегическая цель¶

Внутренняя: перевести стандарты холдинга из режима «реактивное латание» в систему которая самоподдерживается между Claude-сессиями
Продуктовая: разблокировать масштабирование экосистемы (5 продуктов → 10 → 50) без проседания качества
Брендовая: единый голос холдинга через единые стандарты production артефактов

2 · Принципалы и иерархия RBAC¶

Иерархия (от высшего к низшему)¶

┌─ Уровень 0 · CEO ROOT ────────────────────────────────────────────┐
│  Сергей Архангельский (CEO, ROOT, founder)                       │
│  ВСЕГДА сверху всех 5 типов стандартов.                          │
│  Полные права:                                                   │
│    • Перекрыть любое решение любого хозяина                      │
│    • Самостоятельно править любой canonical (без согласований)   │
│    • Заменить хозяина типа через decision document               │
│    • Утвердить или отклонить любые правки эталонов               │
│    • Ратифицировать или обновить эту Конституцию                 │
│  CI-сторож (после Этапа 3b) не блокирует commits CEO ROOT.       │
└──────────────────────────────────────────────────────────────────┘
                      ↓ делегирует рутинные правки ↑
┌─ Уровень 1 · 5 операционных хозяев ──────────────────────────────┐
│  Designer · Document-Writer · Артём · Content + CMO              │
│  Зона ответственности — рутинные правки эталона своего типа.     │
│  Право единолично править canonical в своей зоне (с bump version)│
│  Soft RBAC self-check + routing через Mission Control            │
└──────────────────────────────────────────────────────────────────┘
                      ↓ передаёт задачи ↑
┌─ Уровень 2 · Все остальные ──────────────────────────────────────┐
│  Скилы / команда (Виктория, Свят) / подрядчики / новые участники │
│  НЕ правят canonical напрямую                                    │
│  Передают задачи хозяевам через CEO orchestrator или Mission     │
│  Control. После Этапа 3b — CI БЛОКИРУЕТ прямые правки вне RBAC.  │
└──────────────────────────────────────────────────────────────────┘

Ключевой принцип¶

Хозяева — это делегированные операционные исполнители, не равноуровневые партнёры CEO. CEO всегда может перекрыть, дополнить, заменить.

Почему это важно: если хозяин уходит в отпуск / увольняется / не справляется — CEO напрямую закрывает критические правки сам, не блокируется на ожидании. Это страховка от single point of failure на уровне операционных хозяев.

3 · 5 типов стандартов холдинга и 5 хозяев¶

Brand OS v3 признаёт 5 типов стандартов в холдинге GOLDJAXE. Каждый имеет одного операционного хозяина (под CEO ROOT).

#	Тип стандарта	ROOT-уровень	Операционный хозяин	Canonical файл (эталон)	Резерв при отсутствии хозяина
1	Лендинги (.ai/.com/.org/syndicate/academy/gate/linkstack/vault и все будущие) — Тип имеет 2 эталона: ROOT-эталон триады (`.ai`) + specialized sub-эталон Edu/Tier-ladder (`academy`)	CEO (override / direct edit / replace)	`goldjaxe-designer`	ROOT триады: `canonical/landings/ai.html` (RU) + `ai-en.html` (EN) для `.ai` v4.68.1 (Этап 0 ЗАКРЫТ 21.05) · Specialization Edu/Tier-ladder: `canonical/landings/academy/index.html` v4.82.1 (Wave 2 + production review fixes 24.05) — закрывает 8 дополнительных паттернов (Hero 4-tier ladder · Twin Frame Unified · Team grid 25 cards · Cases 3-col · Services teaser · Pricing 3-tier · MASTER KEY 4 perks · Hybrid theme by design). Применять academy эталон для будущих tier-ladder лендингов. Остальные 6 продуктов миграция в Этапе 5.	`goldjaxe-frontend` (для технической реализации после CEO-апрува визуала)
2	Документы PDF (договоры, КП, акты, инвойсы, NDA, оферты, letterhead, презентации, ТЗ, ADR, аудиты, меморандумы)	CEO	`goldjaxe-document-writer`	`document-system/` (закрыт Brand OS v2 Этапы 1-3 ✅ · 18 типов на комоде `_document.html`)	`goldjaxe-designer` (визуальные правки layout/typography, не контента)
3	Визуальные компоненты CSS (master CSS, токены, eco-* классы, темы light/dark, шрифты, цвета)	CEO	`goldjaxe-designer` (тот же что и Лендинги)	`ui-kit/eco-components.css` (~2068 строк) + `tokens/design-tokens.css` + `tokens/fonts.css`	`goldjaxe-frontend` (техническая имплементация в продакшн-репо через git submodule)
4	Скилы AI-команды (23+ production-скила в `goldjaxe-skills/skills/`)	CEO	Артём Земцов — делегированный Maintainer репо `goldjaxe-skills` (admin-доступ к git.q-standard.com, semver / CHANGELOG / release)	`goldjaxe-skills/skills/` (`SKILL.md` + `references/` + `playbooks/` каждого скила)	Mission Control (для CEO-only скилов: `goldjaxe-mission-control` правится только CEO через Mission Control)
5	Контент-стиль (brand voice, тон голоса, правила копирайта, словарь замен англицизмов, Corporate Brutalism canon)	CEO	`goldjaxe-content` (исполнение) + `goldjaxe-cmo` (стратегия бренда)	`brand-system-v1/voice/` (создаётся в Этапе 5 Brand OS v3 · сейчас placeholder)	`goldjaxe-academy-writer` (для контента LMS · отдельный sub-стандарт)

Особенности назначений¶

Designer на 2 типа (1 + 3): Лендинг физически = HTML × CSS. Разнесение по разным хозяевам создавало бы координационный затор на каждой правке цвета. Designer владеет визуальной осью целиком — от токена цвета до готового экрана. Так устроено у Apple, Stripe, Linear — один Design Director отвечает за всё визуальное.

Артём как живой человек-хозяин (тип 4): единственный тип где операционный хозяин = живой человек, не виртуальный скил. Скилы — это сами артефакты, не могут быть собственным хозяином (рекурсия). Артём как Maintainer имеет реальный admin-доступ к git.q-standard.com:goldjaxe/goldjaxe-skills, делает git push, ведёт CHANGELOG. CEO всегда сверху — может в любой момент сам править любой скил.

Content + CMO как пара (тип 5): два совладельца на разных уровнях абстракции. CMO держит стратегическую ось (зачем такой голос, против кого, как меняется по каналам). Content держит исполнительскую (тексты, тон, словарь). Эта пара повторяет паттерн B2C-маркетинга — Strategy + Execution. CEO над обоими.

Полный RBAC регистр¶

См. brand-os/owners.md — детальное описание полномочий / обязанностей / запретов каждого хозяина + процедура смены хозяина + история изменений RBAC.

4 · 3 слоя soft RBAC enforcement¶

Решение CEO 2026-05-21: Brand OS v3 защищает эталоны через soft RBAC из 3 слоёв на уровне Claude tool use + canonical-файлов + скилов. БЕЗ hard enforcement (CI / pre-commit / hooks от Артёма) — пока soft не подведёт.

Принцип: 80% защиты от 20% усилий. Главный источник 90% риска = Claude-сессия CEO в спешке правит canonical напрямую. Эти 3 слоя адресуют именно этот риск.

Слой 1 · Visual warning в canonical-файлах¶

В первых строках каждого canonical-файла — RBAC header comment с типом, хозяином, требованиями к самопроверке.

<!--
============================================================================
🛡 BRAND OS v3 · RBAC PROTECTED FILE · 2026-05-21
============================================================================
Type:    Лендинги
Owner:   goldjaxe-designer · CEO ROOT override
============================================================================
ПЕРЕД ПРАВКОЙ — обязательная самопроверка:
1. Я хозяин типа? (Designer-скил активирован?)
2. CEO в курсе что я правлю?
3. Я прочитал brand-os/owners.md и подтвердил это моя зона?
4. Я не выхожу за свою зону?

Если хоть один пункт ❌ → СТОП. Передай задачу через Mission Control.
============================================================================
-->

Когда срабатывает: при любом Read файла Claude видит warning + 4-пунктный чеклист. Это passive reminder.

Применяется к: - canonical/landings/ai.html + ai-en.html (есть с Этапа 3) - document-system/*.html (добавляется при правке) - ui-kit/eco-components.css (добавляется при правке) - goldjaxe-skills/skills/*/SKILL.md (добавляется при правке) - brand-system-v1/voice/*.md (после Этапа 5)

Слой 2 · Routing в Mission Control и CEO orchestrator¶

В goldjaxe-mission-control/references/00-iron-rules.md (Принцип 14) и goldjaxe-ceo/SKILL.md (Принцип 12) — обязательный workflow при делегировании.

Получаю задачу от CEO «правь файл X»
   ↓
Проверка: X в protected paths?
   - canonical/**
   - document-system/**
   - ui-kit/eco-components.css, tokens/**
   - goldjaxe-skills/skills/**
   - brand-system-v1/voice/**
   ↓ да
Читаю brand-os/owners.md → определяю хозяина типа
   ↓
НЕ правлю сам · активирую хозяина-скил через триггер:
- Лендинги / CSS → «делай как senior» (Designer)
- Документы PDF → «делай как документатор» (Document-Writer)
- Скилы AI → передача задачи Артёму или прямое редактирование если CEO-only скил
- Контент-стиль → «делай как content» + bcc CMO для стратегии
   ↓
Хозяин-скил делает правку в правильном контексте
   ↓
Mission Control собирает результат + checkpoint CEO

Когда срабатывает: CEO активирует Mission Control или CEO orchestrator → задача автоматически routing-ится хозяину.

CEO ROOT override: если CEO явно говорит «я правлю сам» или «не отвлекай Designer-скил, делай напрямую» → CEO override-полномочия разрешают прямую правку без routing.

Слой 3 · Self-check в SKILL.md хозяев¶

В блоке «🏛 Я хозяин» каждого скила-хозяина — pre-action checklist (5-6 пунктов).

Designer + Document-Writer + Content обязаны мысленно пройти чеклист перед любой правкой своего canonical:

☐ Я активирован явно (триггер или CEO mandate) — НЕ автоматически из default-режима
☐ CEO в курсе что я правлю (или CEO сам инициировал)
☐ Я прочитал owners.md и подтвердил это моя зона
☐ Я не превышаю свою зону (только мои типы)
☐ Я прочитал текущий эталон ДО правки

Document-Writer добавляет 6-й пункт: LOCKED params Document System v2 не нарушаются (17 параметров — не меняю без CEO + bump major).

Content добавляет: Я согласовал с CMO стратегические изменения (CMO держит стратегию бренда, я держу исполнение).

Любой пункт ☐ → стоп, передача через Mission Control / CEO orchestrator.

Почему soft (а не hard)¶

CEO 2026-05-21 явно выбрал soft RBAC enforcement через 3 слоя вместо hard через Артёма (CI / pre-commit / hooks). Логика:

Главный источник 90% риска = Claude в спешке. Слои 1-3 именно его адресуют
Артём занят другими приоритетами — GOL-91 биллинг, Contract Factory Phase 2, GOL-97 ERP Discovery. Не вызывать без необходимости
80% защиты от 20% усилий — принцип Парето. Если soft подведёт — вернёмся к Артёму за hard
Меньше overengineering — текущие 10 правок canonical в неделю не требуют CI gate

См. feedback_soft_rbac_three_layer_model.md — полная модель + триггеры эскалации.

5 · 4 триггера эскалации к hard enforcement¶

Возвращаемся к Артёму за CI / pre-commit / hooks ТОЛЬКО при одном из 4 событий. Каждый из них означает что soft защита не справляется и нужен server-side enforcement.

#	Триггер	Конкретное условие	Действие при срабатывании
1	Регрессия в эталоне в течение 2 недель после внедрения Этапа 3	0 регрессий → soft работает · ≥1 регрессия → эскалация	Mission Control flag CEO + бриф Артёму на CI gate (Этап 3b)
2	>3 случаев рассогласования за месяц	Любая копия эталона в неправильном месте, любая правка вне RBAC	Soft недостаточно → hard обязателен · бриф Артёму
3	Новый хозяин в команде	Например Frontend-скил начнёт править canonical · routing работает плохо для новых participants	CI закрепляет RBAC автоматически
4	Push доступ выдан внешнему подрядчику	Внешний разработчик имеет write access к репо	Server-side enforcement обязателен (CI или pre-receive hook)

Дедлайн первой ревизии¶

2026-06-04 (через 2 недели от ратификации Конституции).

Mission Control обязан проверить: - 0 регрессий → запись в AI-ATTEMPTS-LOG.md секция «Soft RBAC review · PASS» · продолжаем без CI - ≥1 регрессия → flag CEO + бриф Артёму на Слой 4 (CI server-side) - ≥3 регрессий → срочный CEO checkpoint + emergency бриф Артёму

Что если эскалация необходима¶

Этап 3b будет реализован: - Артём пишет _deploy/scripts/check-rbac.py (~100 строк Python) - В .gitlab-ci.yml добавляется stage brand-os-rbac-check до deploy - Тот же скрипт может быть запущен из pre-commit framework для live разработчиков - См. полный бриф в command/decisions/2026-05-21-standards-constitution-roadmap.md секция «Этап 3b backlog»

6 · Workflow при правке canonical-эталона¶

Сценарий 1 · CEO просит правку через Mission Control¶

Это рекомендуемый workflow.

CEO: «открой mission-control, правь заголовок в hero лендинга .ai»
   ↓
Mission Control:
1. Активируется (читает `00-iron-rules.md` + `owners.md`)
2. Проверяет: `canonical/landings/ai.html` в protected paths? — да
3. Определяет хозяина: Designer (тип 1 Лендинги)
4. Активирует Designer через триггер «делай как senior»
   ↓
Designer:
1. Активируется (читает SEMANTIC-CORE + 7 правил эталона .ai)
2. Проходит pre-action self-check (5 пунктов)
3. Read `canonical/landings/ai.html` — видит header RBAC warning
4. Делает правку
5. Возвращает результат Mission Control
   ↓
Mission Control собирает + CEO checkpoint

🔴 DoD любой canonical-правки экрана (дополнение 10.06.2026 · Fold-first · Mobile-first, апрув CEO): поставка хозяина типа НЕ готова без (1) программной фолд-проверки смыслового ядра в 1440×900 (числа, не «на глаз»), (2) мобильного адаптива в той же поставке (≤767 + экстрим 358-390, touch ≥48), (3) visual verify обе темы. Канон правила — ui-kit/SEMANTIC-CORE.md Якорь 0 + playbook/01-mental-models.md §4.

Сценарий 2 · CEO просит правку через CEO orchestrator¶

То же самое, но через goldjaxe-ceo orchestrator (декомпозиция задачи) вместо Mission Control.

Сценарий 3 · Прямая правка от CEO¶

CEO имеет override-полномочия — может править любой canonical напрямую без routing. Soft RBAC не блокирует CEO (header warning игнорируется по CEO mandate).

Когда CEO правит напрямую: - Экспресс-правка опечатки - Personal touch на эталоне после CEO визуальной проверки - Override решения хозяина (CEO может перекрыть)

Сценарий 4 · Случайная правка от не-хозяина (failure path)¶

Если Claude в спешке (не активировав скил-хозяин) пытается править canonical:

Слой 1 защиты: при Read файла видит header RBAC warning → должен остановиться
Слой 2 защиты: если работает через Mission Control / orchestrator — task routing активирует хозяина
Слой 3 защиты: если хозяин активирован но это не его тип — pre-action checklist ловит выход за зону

Если все 3 слоя пропущены (Claude забыл) → правка идёт, попадает в commit, CEO видит → возврат коммита.

Это и есть failure case который мы измеряем в ревизии 2026-06-04 — если ≥1 случай за 2 недели → эскалация к hard enforcement.

Сценарий 5 · Артём правит свою зону (тип 4 Скилы AI)¶

Артём — единственный живой человек-хозяин. Когда он правит goldjaxe-skills/skills/: - Soft RBAC не блокирует (он хозяин) - Self-check он делает мысленно или через pre-commit hook (если установит свою копию) - git push идёт прямо в master goldjaxe-skills

После Этапа 3b (если триггеры эскалации сработают) — CI server-side check будет проверять и Артёма (он в whitelist для типа 4, но не для типов 1/2/3/5).

7 · 5 уроков Brand OS v3¶

Уроки родились в процессе закрытия Этапов 0-3. Каждый — структурный fix конкретной ошибки коммуникации или процесса. Применяются ко всем будущим этапам Brand OS и любым большим программам холдинга.

Урок 1 · Главную цель называть СНАЧАЛА простым языком¶

Прецедент: Этап 1 (RBAC). Mission Control начал с технических вопросов про назначение хозяев (Designer на 2 типа? Артём как Maintainer? Content+CMO как пара?), не объяснив зачем это нужно. CEO: «ты основную цель вообще понимаешь? назови мне ее сначала».

Структурный fix: в любом длинном артефакте Mission Control (decision · pulse update · roadmap · CEO checkpoint) — раздел «🎯 Главная цель простым языком» в начале, до технических деталей.

Memory: feedback_simple_language_ceo_checkpoint.md.

Урок 2 · Варианты с рекомендацией + логикой + альтернативами¶

Прецедент: Этап 1 (RBAC). Mission Control задавал «согласен или нет?» без рекомендации + без обоснования + без альтернатив. CEO: «ты забыл что нужно рекомендовать решения и объяснять логику?».

Структурный fix: на каждом CEO checkpoint — формат «Моя рекомендация: X · Логика: Y · Альтернатива: Z · Почему рекомендую X: W».

Memory: feedback_recommend_with_reasoning.md (существующая).

Урок 3 · CEO ROOT в RBAC всегда явно сверху¶

Прецедент: Этап 1 (RBAC). Mission Control написал «единственный человек-хозяин = Артём», создалось впечатление что CEO исключён из RBAC. CEO: «я не понимаю почему только артем может а я нет».

Структурный fix: в любом RBAC-артефакте (owners.md, users.md, любой будущий register) — первый раздел = иерархия с CEO ROOT сверху + override-полномочия. Хозяева — это делегаты, не равноуровневые партнёры.

Memory: feedback_ceo_root_in_rbac.md.

Урок 4 · Scope drift во время implementation → checkpoint CEO до продолжения¶

Прецедент: Этап 2 (SSoT). Mission Control при discovery обнаружил что план «архивировать 3 целые папки» сломал бы 55 рабочих URL других prototypes. Принял решение в одну сторону (архивировать только AI-prototype + landing-файлы) без отдельного CEO checkpoint до продолжения implementation. В финальном checkpoint показал отклонение, CEO апрувил.

Структурный fix: при обнаружении значимого scope drift во время implementation — Mission Control должен остановиться и спросить CEO до продолжения, не принимать решения сам. Процедурно правильно: сначала checkpoint, потом implementation.

Memory: feedback_canonical_migration_playbook.md секция «Шаг 1 Discovery».

Урок 5 · Возвращайся к сути если завёл CEO в технические дебри¶

Прецедент: Этап 3 (RBAC enforcement). Mission Control последовательно усложнял решение — CI gitlab-ci.yml → pre-commit framework → PreToolUse hooks → multi-layer defense из 5 слоёв → разделение по actor. CEO: «я запутался. давай вернёмся по простому».

Корень ошибки: на каждом шаге технического обсуждения я добавлял очередной слой защиты, не проверяя «а проблема-то насколько острая? И самое простое решение?» Технический инженер во мне взял верх над стратегом-партнёром CEO.

Структурный fix: 5-шаговый алгоритм возврата к сути: 1. Признать ошибку коммуникации (одна строка) 2. Проблема одной строкой простым языком 3. Что уже сделано (вычитание контекста) 4. Анализ риска (где живёт реальная проблема) 5. Простое решение + явный список «что НЕ делаем»

Plus самопроверка перед длинным техническим ответом — 5 пунктов чеклиста (объяснил зачем? CEO знает термины? дал рекомендацию? сказал что НЕ делаем? указал триггер эскалации?).

Memory: feedback_return_to_essence_when_lost_in_details.md (главный урок дня).

Применение уроков¶

Эти 5 уроков обязательны к применению Mission Control в: - Любом стратегическом обсуждении с CEO - Любом плане большой программы (Brand OS, ERP, Digital State, Контент-завод, и т.д.) - Любом CEO checkpoint после исполнения этапа - Любом длинном техническом ответе

Если хоть один урок нарушен — переписать, не отправлять.

8 · История версий Brand OS¶

Brand OS v1.0 · 13-15.05.2026 · ❌ ПРОВАЛ¶

Длительность: 2 дня.

Что планировали: первая попытка собрать брэнд-операционку холдинга — общие правила бренда, цветов, типографики, документов.

Что пошло не так: - Claude собирал артефакты «из головы», без эталонов холдинга - Отсутствовал first-read эталона перед каждым CSS/HTML/PDF - CEO: «откуда ты это взял · какой же ты тупой стал»

Корень провала: не было правила «не создавать с нуля если есть эталон». Claude занимался синтезом вместо адаптации.

Что вынесли: - Введено правило feedback_no_create_from_scratch_if_canonical_exists.md — flag CEO если нет эталона - Введена концепция templates-index как single source of truth - Введена концепция «комод» документов (один шаблон-родитель)

Brand OS v2 · 15-21.05.2026 · ⚠️ ЗАСТРЯЛ НА 28%¶

Длительность: 6 дней, не доведён до конца до Brand OS v3 ratification.

Что планировали (CEO mandate 15.05): «Вариант В Максимальный · закрыть вопрос раз и навсегда» через 7 этапов на 9-15 дней.

Этапы Brand OS v2 (статус): | Этап | Что | Статус | |---|---|---| | 0 | Фиксация 5 memory + decision + handoff | ✅ закрыт 15.05 | | 1 | Enforcement infrastructure + cover redo bonus | ✅ закрыт 15.05 | | 1.5 | Комод документов класса Б (4 типа на _document.html) | ✅ закрыт 17.05 | | 2 | Класс А — 10 юр-форм РФ | ✅ закрыт 18.05 | | 3 | 3 уровня бренда (full/monogram/unbranded) | ✅ закрыт 18.05 | | 5 | Hard-gate first-read в 5 SKILL.md | ✅ закрыт 18.05 | | 4 | 4 лендинга + email/соцсети + OG | ⏳ ЗАСТРЯЛ → переехал в Brand OS v3 | | 6 | Финал — линтер green + skills v1.0.0 milestone | ✅ ЗАКРЫТ 21.05 через Brand OS v3 Этап 4 (этот документ) |

Корень застревания: 1. План не имел якоря в pulse (главная страховка) 2. Этап не имел фиксированного scope + DoD — новые правки вливались внутрь 3. Не было правила «новое требование = backlog, не текущий этап»

Что переносится в v3: - ✅ Все закрытые Этапы 0-3 + 5 (фундамент документов остаётся как есть) - Этап 4 (лендинги) разворачивается в полноценный Этапы 0-2 Brand OS v3 (эталон + SSoT) - Этап 6 (финал) интегрируется в Этап 4 Brand OS v3 (эта Конституция)

Brand OS v3 · 2026-05-21 → · ✅ ФУНДАМЕНТ ЗАВЕРШЁН¶

Старт: 2026-05-21 (CEO ratification). Дедлайн фундамента (Этапы 1-4): ~3 недели по плану, фактически 1 день (рекорд для холдинга). Дедлайн миграции (Этап 5): ~5 недель после фундамента.

Этап	Что	Статус
0	Эталон лендинга .ai v4.68.1	✅ ЗАКРЫТ 21.05 (CEO «полный апрув, все идеально»)
1	Назначение 5 хозяев в `owners.md`	✅ ЗАКРЫТ 21.05 v4.69.2 (CEO «согласен поехали дальше»)
2	SSoT для лендингов `canonical/landings/`	✅ ЗАКРЫТ 21.05 v4.70.1 (CEO «закрываем · поехали Этап 3»)
3	Soft RBAC из 3 слоёв	✅ ЗАКРЫТ 21.05 v4.71.1 (CEO «согласен. зафиксируй везде в железобетонном правиле»)
4	Эта Конституция + Brand OS v2 финал	✅ ЗАКРЫТ 21.05 v4.72.0
5	Миграция остальных 4 типов в `canonical/` (по 1 в неделю)	⏸ pending · ~5 недель
3b	Hard CI от Артёма (только если триггеры)	⏸ pending · на основе ревизии 2026-06-04

9 страховок Brand OS v3 (защита от потери плана): 1. Pulse Активная ставка (vs v2 жил в handoff) 2. Memory active + дата (vs v2 не имел статус) 3. Журнал попыток AI-ATTEMPTS-LOG.md (vs v2 не имел истории) 4. Анти-scope-creep (главный fix vs v2 Этап 4 застревание) 5. Определение провала на этапе (vs v2 не понимали когда стоп) 6. Визуальная карта прогресса (vs v2 CEO видел только в handoff) 7. Раз в 3-5 дней апдейт pulse (vs v2 неделя тишины) 8. Никаких параллельных «Brand OS X» 9. Реестр программ — универсальная модель

9 · Связи с другими документами холдинга¶

Документы Brand OS (`design.goldjaxe.ai/brand-os/`)¶

Документ	Роль
CONSTITUTION-v3.md (этот)	Главный документ Brand OS v3 — источник правды
owners.md	RBAC карта 5 типов × 5 хозяев · детальные полномочия
templates-index.md	Каталог утверждённых эталонов холдинга
AI-ATTEMPTS-LOG.md	Журнал попыток наведения стандартов (v1 → v2 → v3)
document-map.md	Карта документов холдинга (Brand OS v2)
index.html	Visual catalog с фильтрами

Decisions и memory¶

command/decisions/2026-05-21-standards-constitution-roadmap.md — родительское стратегическое решение CEO
feedback_standards_constitution_roadmap.md (memory) — active план искоренения проблемы стандартов
feedback_soft_rbac_three_layer_model.md — модель soft RBAC + триггеры эскалации
feedback_ceo_root_in_rbac.md — универсальный паттерн «CEO ROOT всегда сверху»
feedback_canonical_migration_playbook.md — playbook миграции типа в canonical/ (для Этапа 5)
feedback_return_to_essence_when_lost_in_details.md — урок 5 коммуникации

Skills которые упоминают Конституцию (mandatory first-read)¶

goldjaxe-mission-control — Принцип 14 в 00-iron-rules.md
goldjaxe-ceo — Принцип 12 в SKILL.md
goldjaxe-designer — блок «Я хозяин 2 типов» + pre-action self-check
goldjaxe-document-writer — блок «Я хозяин Документы PDF» + self-check
goldjaxe-content — блок «Я хозяин Контент-стиль» + self-check

Команды и реестры¶

command/programs-registry.md — Brand OS v3 = программа №1 в реестре стратегических программ холдинга
command/pulse.md — еженедельный статус Brand OS v3 в Активных ставках

10 · Ревизия и обновление Конституции¶

Цикл ревизии¶

Раз в 2 недели или после значимых событий (что наступит раньше).

Триггер ревизии	Что проверяем
Каждые 2 недели (`next_review` в frontmatter)	Регрессии в эталонах · soft RBAC работает · нужна ли эскалация
После закрытия любого этапа Brand OS v3	Обновить раздел 8 «История версий» + статусы
После срабатывания триггера эскалации	Обновить раздел 5 «4 триггера» + добавить запись о hard enforcement
После добавления нового типа стандарта	Обновить раздел 3 + `owners.md` + workflow
После значимого CEO решения по Brand OS	Зафиксировать в разделе 8 + decision document

Кто обновляет¶

Mission Control обновляет Конституцию по триггерам выше. CEO ROOT ратифицирует крупные изменения (новый раздел, изменение принципов, изменение хозяев).

Bump version Конституции: - Patch (1.0 → 1.0.1) · опечатка / малое уточнение - Minor (1.0 → 1.1) · новый раздел / новый урок Brand OS v3 / уточнение workflow - Major (1.0 → 2.0) · смена модели RBAC / Brand OS v4 (надеемся не понадобится)

Что делать через 2 недели (2026-06-04 · следующая ревизия)¶

Mission Control обязан:

Проверить регрессии в эталонах за 2 недели:
Прогнать grep -r "canonical/landings" --include="*.html" /Users/a/Documents/GOLDJAXE/claude/design.goldjaxe.ai/ — есть ли копии эталона лендинга .ai в других папках?
Проверить git log на правки canonical/**, document-system/**, ui-kit/eco-components.css от не-хозяев email
Проверить commit author email vs owners.md хозяев
Если 0 регрессий → soft работает:
Запись в AI-ATTEMPTS-LOG.md секция «Soft RBAC review 2026-06-04 · PASS»
Bump Конституции patch (1.0.x)
Установить next_review = 2026-06-18 (+ 2 недели)
Если ≥1 регрессия → бриф Артёму на CI:
Срочный CEO checkpoint
Бриф Артёму на реализацию Слоя 4 (CI server-side check) по плану из command/decisions/2026-05-21-standards-constitution-roadmap.md секция «Этап 3b backlog»
Bump Конституции minor (1.1) — добавить запись «Этап 3b активирован»
Если ≥3 регрессий → emergency:
Срочный созвон CEO
Параллельная реализация Слоя 4 (CI) + audit зачем soft не сработал
Bump Конституции minor (1.1) — обновить раздел 4 (3 слоя могут быть недостаточны)

Версия Конституции¶

v1.0 — initial ratification 2026-05-21 (после закрытия Этапов 0+1+2+3 + Brand OS v2 Этап 6 финал).

Следующая запланированная ревизия: 2026-06-04 (или раньше если триггер сработает).

📜 Ратификация¶

Принципал: Сергей Архангельский (CEO, ROOT, основатель GOLDJAXE Enterprise). Дата ратификации: 2026-05-21. Контекст: после закрытия 4 этапов Brand OS v3 (Этапы 0+1+2+3) за один день. CEO явный апрув: «стартуй Этап 4 (CONSTITUTION)» + «согласен. зафиксируй вообще этот контекст и твои рассуждения в железобетонном правиле везде чтобы ты сам потом не забыл об этом».

Кто составил: Mission Control (CEO ROOT-сессия). Кто применяет: все скилы холдинга (через mandatory first-read) + core team Claude-сессий + CEO ROOT в любое время.

Re-entry якорь¶

«прочти CONSTITUTION-v3» / «прочти конституцию Brand OS» / «как устроена дисциплина стандартов холдинга» — Claude перечитывает этот файл целиком (10 разделов) + проверяет статус Brand OS v3 в pulse и programs-registry.

Если ты новый Claude в новой сессии и видишь этот файл первым — добро пожаловать в Brand OS v3. После прочтения ты знаешь: - Кто что правит (раздел 3) - Как правильно работать (раздел 6) - Что нельзя нарушать (раздел 4 + 7 уроков) - Куда смотреть дальше (раздел 9)

▸ Призма Ф5 + Ф6 — Конституция превращает Brand OS v3 из набора практик в формальный документ-источник правды который работает на годы вперёд. Любой будущий участник холдинга начинает с этой страницы. ▸ Ф6 (knowledge capture): эта Конституция — переиспользуемый template для конституций других больших программ холдинга (Digital State / Контент-завод / ERP). Структура «преамбула → принципалы → стандарты → enforcement → триггеры эскалации → workflow → уроки → история → связи → ревизия» применима к любой большой программе.