‍

Протокол координации рабочих мест Альянса

 Публичный пост
21 июня 2026  137
Аватар Алеша Баженов Алеша Баженов

Проверочная GitHub-сборка

Актуальный выпуск: v0.4.2-preview

Репозиторий: industrial-ai-fashion-workspace

Это общий установочный пакет единого рабочего места резидента. Версия preview
предназначена для тестовых установок; базовая версия 1.0.0 планируется к 22
июля 2026 года.

В основе v0.4.2-preview находится проверенная каноническая KA4: 56
действующих глав, 7 будущих узлов и 2 якорных раздела. В публичном пакете 13
открытых глав доступны полным текстом, а 43 резидентских материала остаются
карточками-ссылками без закрытого текста. DocKA4 в общий пакет не включен.
Версия использует единый установщик и проверена в сценариях человека,
организации, нескольких ролей и границы расширенных полномочий на Linux и
Windows, включая обновление старого рабочего места по кириллическому пути и
отдельный staging-preflight для OneDrive/Codex-подобного контура:
11 из 11 проверок успешно.

Живые тесты Ланы подтвердили правильную границу LibraryOnly и сохранность
личных файлов, но старое OneDrive-место блокировало staging. Рабочее место
скопировано в локальную папку вне OneDrive: относительные пути, размеры и
SHA-256 совпали, write-preflight прошел. В v0.4.2-preview добавлены
автоматическое распознавание OneDrive, безопасная подсказка и протокол переноса.
Реальное LibraryOnly-обновление в новом месте и проверка VERSION.json еще
обязательны; старое место до этого остается резервом.

Размер v0.4.2-preview: GitHub Source ZIP около 0,65 MiB, распакованное
содержимое около 1,90 MiB, установленное рабочее место около 2,3 MB на
контрольной файловой системе. Личные данные, встречи, выбранные DocKA и архивы
в этот размер не входят.

Рабочее место не определяется одним типом. После установки раздельно
фиксируются:

  • владелец: человек или организация;
  • организационные контексты: марка, фабрика, вуз, медиа, ритейл и другие;
  • одна или несколько текущих ролей;
  • программы и кооперационные контуры;
  • права доступа и основание полномочий.

Марка и фабрика обычно являются организационными контекстами. Эксперт и
Архитектор являются ролями. Роль можно менять без переустановки, а расширенные
полномочия подтверждаются отдельно.

GitHub-пакет содержит не только KA. Слой alliance-system/ добавляет общую
точку входа, пошаговые CJM, форматы ролей, повторяемые сборки A1.x, правила
поиска и ссылки на протоколы. Для человека используется Markdown, для Codex -
YAML/JSON-индексы со стабильными ID и связями.

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

Установи единое рабочее место резидента Альянса в новую пустую папку.
После установки прочитай START_HERE.md, открой паспорт и помоги заполнить
владельца, текущие роли, доступы и ближайшую реальную задачу.

Ручная установка через macOS, Linux или Git Bash:

git clone https://github.com/abajenov2/industrial-ai-fashion-workspace.git
cd industrial-ai-fashion-workspace
bash install.sh /c/SITES2/alliance-workspace

Ручная установка через Windows PowerShell:

git clone https://github.com/abajenov2/industrial-ai-fashion-workspace.git
Set-Location industrial-ai-fashion-workspace
powershell -ExecutionPolicy Bypass -File .\install.ps1 -Target C:\SITES2\alliance-workspace

Папка назначения должна быть новой или пустой. Добавление роли не требует новой
установки.

Граница данных

Публичный GitHub содержит открытый Свод знаний, карточки-ссылки на резидентские материалы, общие шаблоны, навигаторы, авторов и связанные кейсы. В общий пакет не входят полные тексты закрытого DocKA, личные настройки, контакты, сырые транскрипты, переписки, cookies, токены и коммерческие данные резидентов. Личное рабочее место не отправляется обратно в публичный репозиторий.

Кто проверяет содержание и как выходят обновления

Пользователь не должен вручную сверять весь Свод по KA1-KA6, авторам, доступам, DocKA и RLTR. Эту проверку проводит Архитектор перед выпуском версии. Цикл обновления:

Архитектор обновляет эталон
-> создается проверенный локальный снимок
-> проходит аудит структуры, авторства и доступа
-> выпускается новая версия на GitHub
-> резидент обновляет только общую библиотеку

Паспорт, задачи и личный цифровой след резидента при обновлении общей библиотеки не перезаписываются.

Пилотная установка и обратная связь Codex

Первая установка или обновление библиотеки в каждом рабочем месте проводится в режиме тестирования. Это не молчаливая техническая операция, а проверка протокола на реальном компьютере и реальной роли.

До изменений Codex должен:

  1. прочитать этот Протокол, README.md, workspace.policy.yaml и AGENTS.md актуального GitHub-выпуска;
  2. определить, создается новое рабочее место или библиотека подключается к уже существующему;
  3. зафиксировать исходное состояние и не перезаписывать существующий паспорт, задачи, цифровой след, выбранные DocKA и приватные папки;
  4. клонировать GitHub repository в отдельную техническую папку;
  5. для существующего рабочего места сначала запустить dry-run в режиме LibraryOnly, затем использовать update-library.sh или update-library.ps1, а не повторную установку;
  6. если совместимость неясна, создать рядом новое пустое тестовое рабочее место и сравнить результат, не меняя действующее.

Нужно различать четыре операции:

  1. новая установка выполняется только в новую или пустую папку;
  2. LibraryOnly подключает или обновляет только открытый Свод знаний;
  3. обновление всего общего слоя дополнительно обновляет alliance-system с CJM, правилами и навигацией;
  4. роли и skill меняются отдельными операциями и не требуют повторной установки рабочего места.

Для живого рабочего места обязательна последовательность:

проверка версии и commit
-> фиксация хешей личных файлов
-> DryRun + LibraryOnly
-> проверка пути назначения и границы изменений
-> DryRun + LibraryOnly + CheckWriteAccess
-> проверка create/write/read/delete preflight
-> реальное LibraryOnly-обновление
-> повторная проверка хешей и версии библиотеки

Для Windows PowerShell актуальный пакет подключается так:

git clone --branch v0.4.2-preview https://github.com/abajenov2/industrial-ai-fashion-workspace.git industrial-ai-fashion-workspace-v0.4.2-preview
Set-Location industrial-ai-fashion-workspace-v0.4.2-preview
powershell -ExecutionPolicy Bypass -File .\update-library.ps1 -Target "C:\путь\к\рабочему-месту" -LibraryOnly -DryRun
powershell -ExecutionPolicy Bypass -File .\update-library.ps1 -Target "C:\путь\к\рабочему-месту" -LibraryOnly -DryRun -CheckWriteAccess
powershell -ExecutionPolicy Bypass -File .\update-library.ps1 -Target "C:\путь\к\рабочему-месту" -LibraryOnly

Реальная команда обновления запускается только после обычного dry-run,
успешного write-preflight и фиксации контрольных сумм личных файлов. Если
preflight или staging не проходит, Codex останавливается и возвращает отчет, не
копируя библиотеку вручную поверх действующего места.

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

Windows, OneDrive и кириллические пути

PowerShell-скрипты хранятся в UTF-8 with BOM и проверяются в Windows PowerShell
5.1. Если облачная синхронизация не нужна, постоянное рабочее место лучше
размещать в коротком ASCII-пути вне OneDrive, например
C:\Alliance\Workspace или D:\Alliance\Workspace. OneDrive не запрещен, но
скрипт должен явно распознать такой путь и предупредить о риске sync, ACL и
облачных атрибутов.

Для рабочего места в OneDrive с кириллическим путем Codex сначала
выполняет -LibraryOnly -DryRun, затем повторяет его с -CheckWriteAccess.
Preflight создает короткую временную папку, записывает и читает тестовый файл,
удаляет пробу и только после этого разрешает staging. Реальное обновление
повторяет preflight автоматически, использует короткие временные имена и
сравнивает контрольный файл, его SHA-256 и полноту дерева. Если OneDrive не
позволяет создать probe или staging, Codex не копирует файлы вручную поверх
действующего места, а проверяет тот же release в коротком ASCII-пути вне
OneDrive и возвращает журнал Архитектору.

Безопасный перенос рабочего места в Windows

Перенос на другой диск или из OneDrive не является новой установкой. Codex:

  1. останавливает запись в исходное рабочее место;
  2. строит приватный манифест относительных путей, типов объектов, размеров и SHA-256;
  3. копирует дерево в новую папку, не удаляя источник;
  4. повторяет манифест и допускает переключение только при нулевом diff;
  5. в новой папке выполняет LibraryOnly -DryRun, затем LibraryOnly -DryRun -CheckWriteAccess;
  6. выполняет реальное LibraryOnly-обновление и проверяет VERSION.json и хеши защищенных личных файлов;
  7. оставляет старую папку резервом до подтверждения владельца.

Если удаление старого рабочего места блокируется ACL или OneDrive, Codex не
снимает запрет силой и не обходит права. Папка остается резервом либо позднее
удаляется владельцем через штатный интерфейс Windows после полной проверки
нового места. Подробная инструкция входит в GitHub-пакет:
alliance-system/protocols/WINDOWS_WORKSPACE_MIGRATION.md.

Если опубликованный Протокол указывает новый release, а владелец явно просит
проверить старый, Codex фиксирует расхождение. Старую версию можно тестировать
изолированно по прямому заданию владельца, но нельзя считать актуальным
эталоном или молча использовать для обновления живого рабочего места.

Во время установки Codex фиксирует:

  • дату, операционную систему, release/tag и commit;
  • выбранный режим: новая установка или обновление библиотеки;
  • выполненные команды и их результат;
  • какие файлы созданы или обновлены и какие пользовательские данные сохранены без изменений;
  • ошибки, ручные действия и непонятные места инструкции;
  • результат проверки границы данных;
  • один пробный проход через KA6 на реальной, но нечувствительной задаче владельца.

Журнал сохраняется локально:

00_Паспорт_рабочего_места/YYYY-MM-DD_тест_подключения_библиотеки.md

В конце Codex показывает владельцу короткий отчет:

версия библиотеки;
что сделано;
что изменилось и что сохранено;
результат тестовой задачи;
ошибки и ограничения;
что было непонятно;
какие правки предлагаются в Протокол, README, установщик или Свод знаний;
следующий шаг с владельцем и датой.

Наблюдения Codex считаются кандидатами на улучшение, а не автоматической правкой общего стандарта. Сначала владелец проверяет отчет. Затем Архитектор отделяет локальную особенность от повторяемого правила и при необходимости обновляет Протокол, GitHub-пакет или Свод знаний. Приватные данные и локальный журнал не отправляются наружу без отдельного подтверждения владельца.

Альянс собирает не просто сообщество и не просто библиотеку материалов. Мы строим среду, в которой человек, его роль, его цифровой след, его знания, его документы и его кооперационные связи постепенно собираются в более устойчивую систему работы. Эта система опирается на разнообразие, кооперацию и человеко-машинное развитие, где ИИ помогает не заменить человека, а усилить его способность удерживать контекст, подтверждать доверие, связывать разные уровни доступа и собирать новые формы совместной деятельности.

Рабочее место в этой среде — это не просто папка с файлами, а узел подключения к общей системе координации Альянса. Оно помогает человеку учиться, публиковать, проходить валидацию, вести цифровой след и входить в кооперационные цепочки, не теряя связи между личной практикой, рынком и общим Сводом знаний.

Эталонная версия на сайте: https://alliance.beinopen.ru/post/3871/

Яндекс Диск / файл skill: https://disk.yandex.ru/d/GyUWVguK3mTEhQ

Практический follow-up к протоколу: Чек-лист координации рабочих мест Альянса

Статус локального файла: рабочий снимок для Codex и настройки рабочих мест резидентов.

Если локальная версия расходится с сайтом, источником истины считается опубликованный пост на платформе Альянса. Локальный файл нужен для быстрого старта Codex без обязательного перехода на сайт в начале каждой сессии.

Skill для Codex

Для переноса этого протокола в рабочую практику Codex подготовлен skill:

  • локальная папка: 09_Скиллы_для_Codex/alliance-resident-workspace/;
  • архив для передачи и установки: 09_Скиллы_для_Codex/alliance-resident-workspace.zip;
  • файл для выгрузки: https://disk.yandex.ru/d/GyUWVguK3mTEhQ;
  • Яндекс Диск / внешний файл skill: https://disk.yandex.ru/d/GyUWVguK3mTEhQ
  • установленная копия Codex: ~/.codex/skills/alliance-resident-workspace/;
  • Google Drive: ссылка будет добавлена после загрузки архива.

Skill не заменяет протокол. Протокол описывает стандарт рабочего места резидента, а skill превращает этот стандарт в набор операционных правил для Codex: как безопасно создавать рабочее место, классифицировать доступ, связывать файлы с платформой Альянса, обрабатывать встречи, готовить публикации и вести цифровой след.

Правило синхронизации skill: если меняется папка alliance-resident-workspace/, сразу обновляется архив alliance-resident-workspace.zip и установленная копия Codex. Нельзя передавать резиденту старый архив после правки skill.

Отдельное правило по публикациям и комментариям: если пользователь просит опубликовать правку, комментарий или текст на уже открытом и залогиненном сайте Альянса, Codex не должен преждевременно отказываться только потому, что браузерный инструмент не виден "в лоб". Сначала нужно проверить встроенный браузер, DOM страницы, форму ввода и реальную возможность публикации, и только потом делать вывод о недоступности действия.

Установка skill перед первым запуском

Если рабочее место разворачивается не в уже настроенном контуре, а через архив skill, сначала нужно проверить и только потом переходить к структуре папок.

Минимальный порядок:

архив skill
-> проверка SKILL.md и references/
-> установка в Codex
-> при необходимости перезапуск Codex
-> проверка, что skill реально виден
-> только после этого создание рабочего места

Проверить:

  • где лежит архив;
  • совпадает ли имя skill с ожидаемым;
  • есть ли SKILL.md;
  • есть ли references/;
  • нужен ли перезапуск Codex;
  • не устарел ли архив по отношению к папке skill.

Это правило появилось из первого внедрения рабочего места Ланы: если пропустить установочную фазу, дальше человек начинает работать с неполным контуром и ошибочно считает, что проблема в самом протоколе, а не в установке.

Назначение

Протокол описывает, как разворачивать и поддерживать рабочие места резидентов Альянса: экспертов, предпринимателей, основателей брендов, фабрик, редакторов, координаторов, кураторов программ, студентов, сотрудников и других участников, которые зарегистрированы на платформе и приняли оферту.

В более широком смысле рабочее место — это не просто локальная папка, а узел координации в доверенной системе Альянса. Альянс можно рассматривать как близкую к децентрализованной автономной организации по функции координационную систему: не блокчейн-проект, а среду, где правила взаимодействия множества участников удерживаются офертой, меморандумом о кооперации, наблюдательным советом, цифровым следом, экспертной передачей доверия, валидацией и механизмами разрешения споров.

Базовая сущность - рабочее место резидента. Оно привязано к человеку, его профилю резидента, цифровому следу, правам доступа и реальной траектории TR.

Роль RL - это настройка рабочего места резидента под конкретную профессиональную функцию или совмещение функций. Экспертная настройка является только одним из вариантов: рядом с ней могут быть настройки основателя бренда, координатора, редактора, студента, фабрики, байера, куратора программы или участника кооперационной цепочки.

Рабочее место не является просто папкой с файлами. Это персональный узел работы внутри контуров Индустриального ИИ и связанных с ними внешних контекстов:

рабочее место резидента =
профиль резидента
+ роль / роли
+ траектория развития
+ рабочий ритм
+ библиотека роли
+ цифровой след
+ рамочная программа / координационный контур
+ права доступа
+ связь со Сводом знаний
+ кооперационные цепочки

Приватность при этом не является отдельным миром. Внутри любого контура могут существовать открытые, резидентские, партнерские и приватные рабочие слои.

Рабочее место должно различать четыре связанных, но разные сущности:

A1 = ось кооперационных контуров и модульных сборок Альянса
A1.0 = общий контур Альянса: оферта, меморандум, правила доверенной среды, резидентство, цифровой след, разрешение споров
A1.x = специальный контур совместной работы поверх A1.0
A1.x.y = устойчивый подконтур, сервис или типовой протокол внутри A1.x
TR = цифровой след одного резидента / организации
TRxTR = конкретный кейс пересечения траекторий нескольких участников
RLTR = эталонная ролевая траектория, выведенная из множества TR/TRxTR

A1.0 удерживает общий контур Альянса, а A1.x и A1.x.y используются только там, где поверх него уже возник специальный и различимый формат совместной работы.

Единичный кейс, участник, событие, тема или направление не получает номер A1.x или A1.x.y. Сначала кейс фиксируется как TRxTR; в A1.x или A1.x.y он превращается только после нескольких похожих кейсов, когда можно описать:

  • потребности заинтересованных сторон;
  • матрицу требований;
  • целевые показатели;
  • ресурсные ограничения;
  • типовые модули: роли, документы, знания, процедуры, статусы и договоренности;
  • повторяемую логику сборки;
  • пилотную валидацию или другой цифровой краш-тест;
  • результат и возможность повторения.

Рабочая формула:

матрица требований + библиотека типовых модулей + уникальная сборка под контур -> A1.x

Маршрутизация публикаций TRxTR:

TRxTR -> комната `AI оптимизация`
серия похожих TRxTR + матрица требований + типовые модули -> обобщение в A1.x / KA6 / Паспорт Свода / Онтологию / DocKA

Комната AI оптимизация используется как рабочая лаборатория цифрового следа, настройки рабочих мест, проверки траекторий, валидации и обучения Industrial AI. Если TRxTR содержит чувствительные данные, он публикуется только в закрытом режиме, обезличивается или остается private / локально до согласования участников.

Главная задача рабочего места - помогать резиденту Альянса расти в своей роли или совмещении ролей, работать с материалами Альянса, оставлять цифровой след, участвовать в рамочных программах Альянса, публиковать результаты и связываться с другими ролями, проектами и рынками.

Первый запуск и ближайшая задача

Рабочее место должно устанавливаться не вокруг папок, а вокруг ближайшей реальной задачи резидента на ближайшие 24-48 часов.

Минимальный рабочий запуск:

паспорт рабочего места
+ роли RL
+ рабочий ритм
+ ближайшая задача
+ правила доступа

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

Какую ближайшую задачу этот резидент должен провести через рабочее место в первые 24-48 часов?

Примеры:

  • координатор Форума: список участников -> сообщения -> follow-up -> цифровой след;
  • редактор: расшифровка -> конспект -> пост -> правка сайта;
  • эксперт: встреча -> рекомендации -> документ / комментарий -> валидация;
  • бренд: профиль -> проект -> запрос -> публикация / переговорный follow-up.

Не каждый резидент должен сразу проходить полное развертывание. На опыте теплых резидентов, как в кейсе Григория Лугового, иногда правильнее сначала проверить небольшой полезный шаг:

интерес
-> маленький эксперимент
-> одна встреча / один материал / один follow-up
-> первый цифровой след
-> решение, нужен ли полный контур рабочего места

Это помогает не перегружать человека полной настройкой в момент, когда ему важнее быстро проверить пользу.

Язык для резидента и язык архитектора

В рабочих материалах архитектора и Центра компетенций можно использовать термин CJM, если речь идет о проектировании пути, касаний, интерфейса, сообщений, воронки и точек потери человека.

В материалах для резидентов, сотрудников, экспертов и партнеров вместо CJM используем человеческие формулировки:

  • путь резидента;
  • путь участника;
  • сопровождение;
  • путь регистрации;
  • путь к проекту / валидации / подписке / кооперационной цепочке;
  • касания: тексты сайта, сообщения куратора, письма, уведомления, посты, комментарии, приглашения и follow-up.

Смысл не меняется: архитектор может видеть это как CJM, но для человека это должно звучать как понятный путь и помощь в следующем шаге.

Источники истины

Рабочее место резидента не должно превращаться в отдельную закрытую базу знаний, которая расходится с Альянсом. Поэтому для каждого типа данных нужно понимать, где источник истины, а где рабочая копия.

1. Эталон Архитектора и платформа Альянса

Рабочий эталон KA собирает и согласует роль Архитектора. Для внешней работы с
резидентами источником истины является утвержденная версия, опубликованная на
платформе Альянса:

До публикации эталоном для сборки является версия Архитектора. После публикации
внешнее применение сверяется с сайтом. GitHub release хранит установочную копию
только уже согласованного открытого Свода.

Если эталон Архитектора, сайт и GitHub разошлись, выпуск новой версии
останавливается до сверки. В паспорт синхронизации записываются версии всех трех
представлений, ссылка на repository, release или tag и commit.

2. Рабочие реестры

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

Формат реестра не задан жестко. Это может быть:

  • md-файл;
  • табличный файл, например xlsx в личном рабочем месте владельца;
  • таблица или раздел на платформе Альянса;
  • другой согласованный структурированный формат.

Например:

  • реестр документов, Свода знаний и глоссария;
  • реестр KA / DocKA / G;
  • рабочие списки ролей, траекторий, постов, статусов и связей.

Если рабочий реестр расходится со Сводом знаний на сайте, для структуры KA приоритет имеет сайт, а реестр должен быть приведен к нему или помечен как рабочее расхождение.

Для материалов, где у одной темы есть и статья KA, и документ DocKA, нужно проверять обе стороны связки:

  • есть ли ссылка из KA в DocKA;
  • есть ли обратная ссылка из DocKA в связанную KA;
  • есть ли эта позиция в оглавлении Свод знаний KA;
  • есть ли она на разводной странице DocKA, если документ уже стал частью набора.

DocKA и выборочная установка

Резидентская библиотека не копируется целиком в GitHub или в каждое рабочее
место. Она состоит из двух связанных объектов:

страница DocKA на платформе
-> назначение, связь с KA, авторство и режим доступа

единый файл в управляемом Yandex Disk
-> эталонная рабочая форма и версия

Рабочее место скачивает только документ, который нужен для текущей задачи или
модели компании. Вместе с файлом фиксируются DocKA ID, связанная KA, автор,
URL страницы, версия, хеш и дата получения. Заполненная версия хранится в
приватном слое владельца.

Опорный маршрут «Ладошка Сачек»:

  • KA1 — стратегия компании;
  • KA2 — бренд-стратегия;
  • KA3 — маркетинговая стратегия;
  • KA4 — ассортиментная стратегия;
  • KA5 — коммерческая стратегия.

Выбор документа начинается через KA6: рабочее место определяет роль, стадию,
текущую TR, целевую точку и главный блокирующий вопрос. После этого выбирается
нужная зона KA1-KA5, связанная RLTR, эксперт/кейс и только необходимый DocKA.

Новые внешние PDF, PPTX, таблицы и шаблоны сначала считаются входящими
источниками. До включения в DocKA должны быть определены автор, права, режим
доступа, тип документа, связь с KA и эталонный файл в Yandex Disk. При неясных
правах материал остается pending_rights.

3. Локальное рабочее место

Локальные файлы нужны, чтобы Codex и резидент могли быстрее думать, писать, сверять версии, готовить черновики, обрабатывать встречи и планировать обновления.

Локальные файлы являются источником истины только для:

  • приватного рабочего ритма резидента;
  • личных черновиков;
  • временных задач;
  • локальной структуры папок;
  • статусов обработки материалов до публикации.

Для сайта и общего стандарта локальные файлы становятся источником только после утверждения и публикации.

4. Архивы, транскрипты и выгрузки

Архивы, сырые транскрипты, дампы, выгрузки базы данных, скачанные документы и временные файлы не являются источником истины сами по себе. Это исходники для анализа.

Они должны получить статус:

  • удалить;
  • оставить в архиве;
  • перенести в рабочее место;
  • превратить в пост, протокол, траекторию TR, правку KA, документ DocKA или запись глоссария G;
  • вынести в Очередь_правок_на_сайт.md, если нужна правка сайта.

Практика публикации через встроенный браузер

При работе с сайтом Альянса бывают ситуации, когда поле ввода или редактор не являются обычным видимым textarea, а собраны через визуальный markdown-редактор.

Поэтому для Codex действует такой порядок:

  1. Не спорить с пользователем о принципиальной возможности публикации, если сайт уже открыт и пользователь говорит, что контур залогинен.
  2. Сначала проверить встроенный браузер и фактический интерфейс страницы.
  3. Если ввод в обычное поле не работает, посмотреть DOM и понять, какой редактор используется.
  4. Если это CodeMirror или похожий редактор, вводить текст в видимое поле редактора, а не полагаться только на hidden textarea.
  5. После публикации обязательно проверить:
    • что комментарий / правка реально появились;
    • что ссылка открывается;
    • что режим доступа, соавторы и статус публикации не изменились случайно.
  6. Если у поста на сайте уже есть заголовок, заданный через поле названия, не дублировать h1 в теле текста. Верхний уровень в теле начинать с лид-абзаца или с ##, иначе на странице появляется двойной заголовок.

Это правило нужно для снижения лишнего трения: сначала проверка реального интерфейса, потом выводы.

Живые реестры и Google Sheets

Если рабочий реестр ведется не в локальном md, а в live Google Sheets или другой живой таблице, перед любым изменением Codex обязан заново проверить:

  1. какие вкладки существуют сейчас;
  2. как называются текущие заголовки;
  3. не менял ли пользователь структуру вручную;
  4. какой диапазон действительно нужно править;
  5. является ли локальный xlsx / tsv / output только черновиком, а не источником истины.

Правило:

live Google Sheet > старый локальный xlsx / tsv / output

Если таблица создается или обновляется через браузерную вставку, а не через коннектор или API, после вставки обязательно проверить:

  • стартовую ячейку;
  • наличие заголовков;
  • соседние столбцы;
  • число строк;
  • ссылку на live-документ;
  • запись ссылки на таблицу в файл проекта.

Если структура таблицы изменилась вручную, Codex должен остановить правку и сначала заново сверить структуру.

Handoff между чатами

После первого длинного рабочего цикла или перед переходом в новый чат нужно создавать явный файл передачи контекста:

00_Паспорт_рабочего_места/YYYY-MM-DD_контекст_для_нового_чата.md

В таком файле фиксируются:

  • владелец рабочего места;
  • текущие роли и ближайшая задача;
  • ключевые ссылки;
  • активные файлы;
  • что уже сделано;
  • что нельзя делать без подтверждения;
  • открытые ошибки / коррекции;
  • с чего продолжать в новом чате.

Чаты Codex не являются бесшовной общей памятью. Поэтому источником продолжения должен быть не старый чат сам по себе, а handoff-файл внутри рабочего места.

Технические рабочие зоны

Помимо смысловых папок, в рабочем месте могут появляться технические зоны:

outputs/
tools/
work/
node_modules/

Они допустимы, если обслуживают работу, но не считаются источниками истины. Это:

  • временные выгрузки;
  • preview-файлы;
  • служебные скрипты;
  • runtime-зависимости;
  • промежуточные результаты браузерных или табличных операций.

Если такие папки появились, их не нужно автоматически поднимать в эталон структуры роли. Сначала нужно понять, это временная техническая зона или новая смысловая сущность протокола.

Ошибки Codex и редакционные пометки

Если Codex ошибся в таблице, тексте, маршруте публикации или редакторской формулировке, ошибка не скрывается, а превращается в правило:

ошибка -> коррекция -> запись в handoff / рабочий файл -> новое правило

Если формулировка создана Codex и может быть принята за слова человека, используется явная пометка:

ред. Codex

Это особенно важно для:

  • расшифровок;
  • комментариев от имени Алексея;
  • сообщений участникам;
  • черновиков, которые могут стать публикацией;
  • рабочих таблиц и статусов.

Если Codex поставил напоминание или автоматизацию, это тоже должно быть зафиксировано в локальном рабочем файле: что напоминаем, кому, на какую дату и из какой задачи это возникло.

Как проверить, что рабочие места скоординированы

Скоординированные рабочие места - это не копии одних и тех же папок на разных компьютерах. Координация означает, что разные резиденты и их Codex одинаково понимают:

  • какой протокол считается эталонным;
  • где источники истины;
  • какой режим доступа у материалов;
  • какой у каждого ближайший следующий шаг;
  • через какие посты, проекты, события, комментарии и встречи их контуры связываются на платформе Альянса.

Минимальная проверка координации:

  1. обе стороны открывают один и тот же эталонный протокол;
  2. обе стороны открывают один общий артефакт связи;
  3. оба Codex отвечают на одну и ту же короткую форму:
    • какая текущая роль;
    • какая ближайшая задача;
    • что здесь источник истины;
    • какой следующий цифровой след должен появиться;
  4. ответы сравниваются не по стилю, а по смыслу;
  5. проверяется handoff;
  6. проверяется, можно ли вместо полного onboarding сделать один маленький полезный шаг;
  7. хотя бы один результат возвращается на платформу как цифровой след.

Практически это можно тестировать так:

рабочее место Алексея
<-> post / event / comment / реестр
<-> рабочее место Ланы

Если оба контура после этого дают одинаковый ответ на вопросы "что уже решено?", "что делать дальше?" и "где это зафиксировано?", координация работает.

Как понять, что рабочее место установлено

Рабочее место считается установленным, если:

  • есть паспорт рабочего места;
  • описаны 1-3 роли RL;
  • задан ближайший рабочий ритм;
  • выбрана ближайшая реальная задача;
  • определены источники истины;
  • определены правила доступа;
  • есть хотя бы один обработанный рабочий артефакт;
  • понятен следующий шаг;
  • Codex знает, что нельзя публиковать, отправлять, загружать или менять без подтверждения.

Рабочее место считается прошедшим первый реальный цикл, если дополнительно появились:

  • активный файл проекта;
  • обработанная встреча / конспект;
  • хотя бы один live-реестр или рабочий список;
  • запись в Очередь_правок_на_сайт.md или Опубликовано_на_сайте.md;
  • handoff-файл для следующего чата.

MBSE-описание роли, рабочего места и RLTR

Рабочее место нужно описывать не только как структуру папок, но и как прикладную модель роли. Для этого в 01_Роль_и_траектория/ добавляется смысловой центр рабочего места:

MBSE_паспорт_роли_RBS_FBS_SBS_WBS_DSM.md

В этом файле роль описывается через пять представлений:

  • RBS - требования к роли, рабочему месту и условиям успешной работы;
  • FBS - функции роли;
  • SBS - компоненты рабочей системы роли;
  • WBS - работы, регулярные действия и ритмы;
  • DSM - связи роли с другими ролями, KA, DocKA, TR, TRxTR, RLTR, A1.x, программами, проектами и рынком.

Одинаковой для всех рабочих мест является не начинка, а метод описания. У координатора форума, редактора, эксперта, резидента, архитектора, студента, фабрики и основателя марки будут разные требования, функции, компоненты, работы и связи.

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

RLTR - это не личный профиль человека, а эталонная траектория роли. Она может проверяться на одном человеке как на первом практическом случае, но должна постепенно становиться повторяемой моделью для других участников той же роли или совмещения ролей.

TRxTR фиксирует не отдельную роль, а пересечение нескольких траекторий: встречу, экспертный час, пилот, валидацию, заполнение анкеты, кейс совместной работы или другой эпизод, где несколько участников оставляют связанный цифровой след. Из нескольких похожих TRxTR может быть выведена A1.x как типовая модульная сборка только тогда, когда видны потребности, матрица требований, типовые модули, проверка результата и возможность повторения.

Публикационный маршрут для TRxTR по умолчанию — комната AI оптимизация, потому что такие кейсы нужны для обучения системы, настройки рабочих мест, проверки A1-сборок и развития Industrial AI. Это не отменяет режим доступа: чувствительные кейсы остаются закрытыми, обезличиваются или не публикуются до согласования.

Связка выглядит так:

RL - профессиональная роль
TR - реальная траектория человека / организации и ее цифровой след
TRxTR - конкретный кейс пересечения траекторий нескольких участников
RLTR - эталонная ролевая траектория
A1.x - типовая модульная сборка, выведенная из матрицы требований, типовых модулей и нескольких похожих TRxTR
рабочее место резидента - локальный контур применения RL/TR/TRxTR/RLTR в ежедневной работе

Для каждой пилотной роли нужно фиксировать:

  • какие RL совмещаются;
  • какая TR или практика человека проверяет роль;
  • какие TRxTR показывают пересечение этой роли с другими участниками;
  • какую RLTR мы постепенно формируем;
  • может ли серия похожих TRxTR стать основанием для A1.x: есть ли потребности, матрица требований, целевые показатели, ресурсные ограничения, типовые модули и проверка повторяемости;
  • какие требования, функции, компоненты, работы и связи описаны через RBS/FBS/SBS/WBS/DSM;
  • какие фрагменты можно вернуть в Свод знаний, Онтологию, DocKA или протоколы Альянса.

Пилотные примеры RLTR

Первые три примера нужны не как кадровые описания, а как контрольные случаи метода.

Максим Муратов

Опорный пост: Роль — редактор контент-потоков и Свода знаний Альянса (RLTR) https://alliance.beinopen.ru/post/3034/

RL: редактор контент-потоков;
RL: редактор Свода знаний и авторских публикаций;
RLTR: эталонная траектория редактора, который видит не только отдельный текст, но и поток, комнату, модерацию, авторство, режим доступа и связь со Сводом знаний.

Проверяет метод на задачах: вычитка постов, модерация, проверка попадания материалов в комнаты, редактура Свода знаний, поддержка 4 первых потоков из будущих 15.

Лана Харьговская

Опорный пост: Роль — координатор Форума и эксперт визуально-смысловой упаковки (RLTR) https://alliance.beinopen.ru/post/3873/

RL: координатор Форума и пути участников;
RL: эксперт визуально-смысловой упаковки;
RLTR: эталонная траектория координатора, который ведет участника через приглашение, регистрацию, профиль, проект, экспертную валидацию, выступление, публикации и follow-up.

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

Анна Сахарова

Опорный пост: Роль — эксперт-трекер e-commerce и соорганизатор экспертных программ (RLTR) https://alliance.beinopen.ru/post/3874/

RL: эксперт-трекер по e-commerce, маркетплейсам и продуктовому росту;
RL: соорганизатор Форума и куратор экспертных программ / контура сопровождения;
RLTR: эталонная траектория эксперта, который совмещает предметную экспертизу, сопровождение участников, клиентские follow-up и вклад в Свод знаний.

Проверяет метод на задачах: экспертные сессии, запросы предпринимателей, сопровождение участников, клиентские follow-up, кейсы e-commerce и связь с KA1, KA5, KA6.

Финальная структура рабочего места роли

Если папка уже является рабочим местом конкретного человека, разделы лежат прямо в корне:

00_Паспорт_рабочего_места/
01_Роль_и_траектория/
02_Рабочий_ритм_и_план_работ/
03_Библиотека_роли/
04_Проекты_и_рабочие_задачи/
05_Встречи_и_цифровой_след/
06_Публикации_и_обновления_платформы/
07_Права_доступы_авторство/
08_Кооперационные_цепочки_и_рынок_роли/
99_Архив_исходников/

Если рабочее место создается внутри общей папки или передается как шаблон, допускается обертка:

Рабочее_место_Имя_Фамилия/

00_Паспорт_рабочего_места/
  Паспорт_рабочего_места.md
  Источники_истины.md
  Правила_доступа_для_ИИ.md

01_Роль_и_траектория/
  Мои_роли_RL.md
  Моя_траектория_TR.md
  Эталонная_траектория_RLTR.md
  MBSE_паспорт_роли_RBS_FBS_SBS_WBS_DSM.md
  План_развития_роли.md

02_Рабочий_ритм_и_план_работ/
  Рабочий_ритм.md
  Команда_Видения_ритма.md
  План_недели.md
  Горизонт_14_дней.md
  Контрольные_точки.md

03_Библиотека_роли/
  01_Открытый_стандарт/
    Индекс_быстрой_навигации.md
    Глоссарий_Альянса.md
    Онтология_Альянса.md
    Паспорт_Свода_знаний_KA.md
    Свод_знаний_KA.md

  02_Внутренняя_практика_индексы_и_правила/
    Индекс_ссылок_на_платформу.md
    Правила_работы_с_внутренней_практикой.md
    Обезличенные_паттерны_по_роли.md
    Разрешенные_к_локальному_хранению_материалы.md

  03_Приватные_материалы_роли/
    Авторская_методика/
    Черновики/
    Личные_заметки/
    Настройки_ИИ_ассистента/
    Внутренние_инструкции/

  04_Избранное_и_быстрые_справки/
    Избранные_посты.md
    Быстрые_ссылки.md
    Частые_вопросы.md

04_Проекты_и_рабочие_задачи/
  Активные_проекты.md
  Задачи_по_проектам.md
  Решения_и_статусы.md

05_Встречи_и_цифровой_след/
  Календарь_и_подготовка.md
  Встречи_к_обработке.md
  Временные_транскрипты/
  Рабочая_база_встреч/
  Конспекты_и_извлечения/
  Follow_up.md

06_Публикации_и_обновления_платформы/
  Черновики_постов/
  Комментарии_к_постам/
  Правки_Свода_знаний/
  Очередь_правок_на_сайт.md
  Опубликовано_на_сайте.md

07_Права_доступы_авторство/
  Реестр_прав_и_доступов.md
  Что_можно_публиковать.md
  Что_нельзя_хранить_локально.md
  Авторство_и_соавторство.md
  Уровни_доступа_public_resident_private.md

08_Кооперационные_цепочки_и_рынок_роли/
  Кому_полезна_моя_роль.md
  С_кем_связана_моя_роль.md
  Партнеры_и_запросы.md
  Потенциальные_клиенты_и_заказы.md
  Спецусловия_и_возможности.md

99_Архив_исходников/
  Старые_версии/
  Экспорты/
  Временные_файлы/
  Необработанные_материалы/

Правило: на локальном компьютере активным является рабочее место владельца. Эталонные инструкции и шаблоны для других ролей хранятся на сайте Альянса, а не в локальном реестре чужих рабочих мест.

Что хранится в разделах

00_Паспорт_рабочего_места - кто работает, в какой роли, с какими источниками истины, правами доступа и правилами работы с ИИ.

01_Роль_и_траектория - текущая роль, личная траектория развития, эталонная ролевая траектория и план развития.

В эталонной траектории роли нужно фиксировать не только карьерный рост человека, но и то, как его сертифицированная роль может накладываться на эталонные траектории других ролей. Для ролей, связанных с координацией Альянса, особенно важно описывать стадии зрелости, нетворкинг через самоотметку и алгоритм сопровождения участника через контур Альянса.

02_Рабочий_ритм_и_план_работ - ежедневный и еженедельный ритм, план недели, горизонт 14 дней, контрольные точки и команда, работающая в этом ритме.

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

03_Библиотека_роли - справочная и обучающая библиотека роли:

  • открытый стандарт: Свод знаний, глоссарий, онтология, быстрые индексы;
  • внутренняя практика: ссылки, правила, дайджесты и обезличенные паттерны без локального копирования чужих траекторий;
  • приватные материалы роли: авторская методика, черновики, личные заметки, настройки ИИ;
  • избранное: быстрые ссылки и часто используемые справки.

Локальные копии открытого стандарта нужно регулярно сверять с эталонами на сайте: раз в неделю в период активных изменений и раз в месяц после стабилизации структуры.

04_Проекты_и_рабочие_задачи - активные проекты, рамочные программы / альянсовые контуры, задачи, решения, статусы и следующие шаги.

05_Встречи_и_цифровой_след - встречи, временные транскрипты, рабочая база встреч, конспекты, извлечения и follow-up.

06_Публикации_и_обновления_платформы - материалы, которые должны уйти на платформу: посты, комментарии, правки Свода знаний, обновления сайта.

07_Права_доступы_авторство - уровни доступа, авторство, соавторство, правила публикации, запреты на локальное хранение и особые режимы доступа.

08_Кооперационные_цепочки_и_рынок_роли - кому полезна роль, с кем она связана, какие есть партнеры, запросы, клиенты, заказы и спецусловия.

Цепочки собираются по совместимости стадий зрелости: XS с XS, S с S, M с M/L. Если роль работает с другой стадией, это должно быть подтверждено экспертной валидацией. В этом разделе фиксируется прикладная сборка цепочек: какая сертифицированная роль на какую эталонную траекторию накладывается, какой запрос или предложение человек сам отметил и что нужно сделать для следующего шага.

99_Архив_исходников - старые версии, экспорты, временные файлы и необработанные материалы.

Архив не является источником истины. Это зона временного хранения, разбора и маршрутизации исходников: удалить, перенести в рабочий раздел, превратить в пост, конспект, правку Свода знаний или оставить с понятным статусом.

Быстрый запуск рабочего места

Этот чеклист нужен для первого запуска рабочего места любой роли: координатора, редактора, эксперта, предпринимателя, фабрики, байера, студента, куратора программы, разработчика или другого резидента.

Цель первого запуска - не создать идеальную структуру, а за 15-30 минут получить минимальное рабочее место, с которым резидент и Codex могут начать действовать.

Шаги первого запуска

  1. Открыть этот протокол:

    https://alliance.beinopen.ru/post/3871/

  2. Уточнить, кто владелец рабочего места:

    • имя;
    • ссылка на профиль Альянса;
    • главная роль или совмещение ролей;
    • ближайшая реальная задача.

  3. Создать минимальную папку рабочего места или выбрать уже существующую рабочую папку владельца.

  4. Создать только три обязательных файла:

    00_Паспорт_рабочего_места/Паспорт_рабочего_места.md
01_Роль_и_траектория/Мои_роли_RL.md
02_Рабочий_ритм_и_план_работ/Рабочий_ритм.md

  5. В Паспорт_рабочего_места.md зафиксировать:

    • кто резидент;
    • какие роли он сейчас выполняет;
    • какие задачи нужно держать в ближайшую неделю;
    • какие материалы можно показывать ИИ;
    • что нельзя публиковать, отправлять или хранить локально без согласования.

  6. В Мои_роли_RL.md записать 1-3 роли простым языком:

    RL: ...
RL: ...
RL: ...

  7. В Рабочий_ритм.md записать ближайшие 1-3 действия:

    • кому написать;
    • какую встречу подготовить;
    • какой пост, проект, комментарий, документ или follow-up сделать;
    • что должно вернуться на платформу Альянса как цифровой след.

  8. После первого запуска Codex должен выдать короткий результат:

    • что уже понятно о роли;
    • какие источники истины используются;
    • какие риски доступа есть;
    • какие 1-3 действия делать сегодня или завтра;
    • что нужно уточнить у владельца рабочего места.

Стартовая команда для Codex

Прочитай Протокол координации рабочих мест Альянса:
https://alliance.beinopen.ru/post/3871/

Помоги мне настроить рабочее место резидента Альянса для моей роли.

Сначала помоги мне:
1. понять минимальную структуру рабочего места;
2. создать или проверить три файла: паспорт рабочего места, мои роли RL, рабочий ритм;
3. описать мои 1-3 текущие роли;
4. выбрать 1-3 ближайших действия;
5. определить, какие материалы можно хранить локально, а какие должны оставаться на платформе Альянса.

Ничего не публикуй, не отправляй и не загружай без моего явного согласия.

Процедура создания рабочего места с нуля

  1. Открыть эталонный протокол координации рабочих мест:

    https://alliance.beinopen.ru/post/3871/

  2. Создать корневую папку, если рабочее место разворачивается отдельно:

    Рабочее_место_Имя_Фамилия/

    Если текущая папка уже является рабочим местом владельца компьютера, дополнительная обертка не нужна.

  3. Создать базовые разделы:

    00_Паспорт_рабочего_места/
01_Роль_и_траектория/
02_Рабочий_ритм_и_план_работ/
03_Библиотека_роли/
04_Проекты_и_рабочие_задачи/
05_Встречи_и_цифровой_след/
06_Публикации_и_обновления_платформы/
07_Права_доступы_авторство/
08_Кооперационные_цепочки_и_рынок_роли/
99_Архив_исходников/

  4. Заполнить 00_Паспорт_рабочего_места/:

    • кто человек;
    • какие роли RL;
    • какие зоны ответственности;
    • какие источники истины;
    • какие права доступа;
    • что можно показывать ИИ;
    • какие материалы нельзя хранить локально.

  5. Заполнить 01_Роль_и_траектория/:

    • текущая профессиональная роль;
    • личная траектория TR;
    • эталонная ролевая траектория RLTR, если она уже описана;
    • ближайшие разрывы и шаги развития роли.
    • как роль может входить в кооперационные цепочки;
    • на какие траектории других ролей она может накладываться после валидации.

  6. Заполнить 02_Рабочий_ритм_и_план_работ/:

    • ежедневные проверки;
    • недельный план;
    • горизонт 14 дней;
    • контрольные точки;
    • регулярные встречи, публикации и follow-up.
    • командный контур: кто отвечает, где задача зафиксирована на сайте, какой ритм должен появиться у ответственного.

  7. Настроить 03_Библиотека_роли/:

    • 01_Открытый_стандарт/ - локальные снимки и индексы Свода знаний, глоссария, онтологии и материалов по роли;
    • 02_Внутренняя_практика_индексы_и_правила/ - ссылки, индексы, правила, дайджесты, обезличенные паттерны;
    • 03_Приватные_материалы_роли/ - личные черновики, авторская методика, настройки ИИ, внутренние инструкции;
    • 04_Избранное_и_быстрые_справки/ - быстрые ссылки, избранные посты, ответы на частые вопросы.

  8. Настроить 05_Встречи_и_цифровой_след/:

    • куда попадают транскрипты;
    • как фиксируются дата, источник, участники и статус доступа;
    • как встреча превращается в конспект, пост, правку Свода знаний или задачу.

  9. Настроить 07_Права_доступы_авторство/:

    • public - открытые материалы;
    • resident / только для своих - материалы для резидентов Альянса;
    • private - приватные материалы роли;
    • что нельзя хранить локально;
    • какие есть особые режимы доступа.

  10. Проверить рабочее место:

  • есть ли паспорт;
  • есть ли роль и траектория;
  • есть ли рабочий ритм;
  • есть ли правила доступа;
  • понятно ли Codex, где искать открытый стандарт, внутреннюю практику и приватные материалы.

Как подключить коллегу к Codex и связать рабочие места через Альянс

После согласования паспорта роли или черновика траектории коллеге можно дать короткую инструкцию по настройке рабочего места.

Идея простая: у каждого участника может быть свой Codex / ИИ-помощник, который помогает держать рабочий ритм, читать материалы Альянса, готовить посты, фиксировать встречи, вести задачи и собирать свою профессиональную траекторию.

Важно: личные Codex не связываются напрямую друг с другом и не обмениваются приватными файлами без согласования. Связь между рабочими местами идет через Альянс:

  • профиль резидента;
  • посты и проекты на платформе;
  • комментарии;
  • задачи;
  • события;
  • конспекты встреч;
  • Свод знаний;
  • общие протоколы и инструкции.

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

Что нужно сделать коллеге

  1. Установить Codex на свой компьютер.

  2. Зарегистрироваться / войти в Альянс и проверить свой профиль:

    https://alliance.beinopen.ru/user/me/

  3. Скинуть Алексею ссылку на свой профиль.

  4. Прочитать свой паспорт роли или черновик траектории.

  5. Дать Codex ссылку на свой паспорт роли и написать:

    Прочитай этот пост / файл как паспорт моей роли в Альянсе.
Помогай мне держать рабочий ритм, задачи, публикации, встречи, follow-up и цифровой след.
Не публикуй и не отправляй ничего без моего явного согласия.
Если не хватает файла или инструкции, смотри эталон на сайте Альянса или спрашивай меня.

  6. Начать работать через простые ежедневные шаги:

    • что сегодня нужно сделать;
    • кому написать;
    • какой пост / проект / комментарий подготовить;
    • что передать Алексею, Максиму, Лане, Марии или другому участнику;
    • что должно попасть в Свод знаний или рабочую траекторию.

Как рабочие места связываются между собой

Связь идет не через личные папки, а через платформу Альянса.

человек
-> профиль
-> роль
-> проект / пост / комментарий
-> задача
-> встреча
-> конспект
-> цифровой след
-> Свод знаний / траектория / кооперационная цепочка

Пример:

  • Лана ведет участника Форума по понятному пути: приглашение, регистрация, профиль, проект, выступление, follow-up.
  • Максим редактирует и проверяет публикации.
  • Анна помогает как эксперт-трекер / со-организатор.
  • Алексей и ИИ собирают протокол, связывают материалы и обновляют Свод знаний.

Каждый работает у себя, но результаты становятся видимыми через Альянс.

Минимальный набор ссылок для старта

Правило безопасности

Личный Codex может хранить и анализировать личные рабочие материалы только в пределах согласованного режима доступа.

Нельзя автоматически публиковать:

  • приватные переписки;
  • сырые транскрипты;
  • данные резидентов без согласия;
  • файлы с непроверенными правами;
  • внутренние материалы, которые должны остаться в личном контуре.

Для публикации используется правило:

сначала черновик -> потом согласование -> потом пост / комментарий / задача на платформе

Стартовая команда для Codex коллеги

Ты помогаешь мне как участнику Альянса.
Моя задача - развиваться в своей роли, оставлять полезный цифровой след, работать с задачами, встречами, постами, проектами и Сводом знаний.
Сначала прочитай мой профиль и паспорт роли.
Каждый день помогай мне выбрать 1-3 конкретных шага.
Ничего не публикуй и никому не отправляй без моего явного согласия.

Минимальные шаблоны ключевых файлов

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

00_Паспорт_рабочего_места/Паспорт_рабочего_места.md

# Паспорт рабочего места

**Статус:** черновик / рабочая версия / согласовано.

**Эталонный протокол:** https://alliance.beinopen.ru/post/3871/

## Человек

Имя:
Профиль Альянса:
Город:
Контакты через профиль:

## Роль в Альянсе

Краткое описание роли:

## Основные роли RL

- 
- 
- 

## Главные контуры ответственности

- 
- 
- 

## Особый режим доступа

Нет / есть. Если есть, описать отдельно и сослаться на `07_Права_доступы_авторство/`.

## Что должен делать Codex

- держать рабочий ритм;
- помогать с материалами роли;
- связывать задачи с KA, RL, TR, DocKA и рамочными программами;
- напоминать, что должно вернуться на сайт Альянса.

00_Паспорт_рабочего_места/Источники_истины.md

# Источники истины

## Эталонные источники на сайте

- Протокол координации рабочих мест Альянса: https://alliance.beinopen.ru/post/3871/
- Свод знаний KA: https://alliance.beinopen.ru/docs/2836/
- Онтология Альянса: https://alliance.beinopen.ru/post/3341/
- Глоссарий Альянса: https://alliance.beinopen.ru/post/3305/

## Рабочее различение индексов

```text
TR = цифровой след одного резидента / организации
TRxTR = конкретный кейс пересечения траекторий нескольких участников
A1.x = типовая модульная сборка, выведенная из матрицы требований, типовых модулей и нескольких похожих TRxTR
RLTR = эталонная ролевая траектория, выведенная из множества TR/TRxTR

Единичный кейс не получает номер A1.x: сначала это TRxTR, а типовая сборка появляется только после нескольких похожих кейсов, когда можно описать потребности, матрицу требований, целевые показатели, ресурсные ограничения, типовые модули, проверку результата и повторяемость.

TRxTR публикуется в комнате AI оптимизация, если кейс нужен для обучения системы, настройки рабочих мест, проверки модульных сборок A1.x, цифрового следа, валидации или сопровождения резидентов. Обобщение из серии похожих TRxTR переносится в A1.x, KA6, Паспорт Свода, Онтологию или DocKA только вместе с матрицей требований и типовыми модулями.

Локальные снимки

Правило

Локальный файл помогает Codex думать и работать быстрее, но если локальная версия расходится с сайтом, источник истины - опубликованный материал на платформе Альянса.


### `01_Роль_и_траектория/Мои_роли_RL.md`

```md
# Мои роли RL

## Текущие роли

1. 
2. 
3. 

## Как использовать этот файл

Codex должен сверять задачи дня с этими ролями и уточнять, в какой роли человек сейчас действует.

Одна встреча или задача может относиться к нескольким ролям:

- как специалист - к профессиональной практике;
- как участник Альянса - к цифровому следу и профилю;
- как эксперт - к Своду знаний и валидации;
- как участник рамочной программы - к программе, графику, follow-up и публикациям.

01_Роль_и_траектория/Моя_траектория_TR.md

# Моя траектория TR

**Статус:** черновик / рабочая версия / согласовано.

## Текущее состояние


## Цель развития роли


## Ближайшие разрывы

- 
- 
- 

## Следующие шаги

- 
- 
- 

## Цифровой след, который подтверждает движение

- профиль:
- посты:
- встречи:
- проекты:
- документы:

01_Роль_и_траектория/Эталонная_траектория_RLTR.md

# Эталонная траектория RLTR

**Статус:** требует разработки.

Эталонная ролевая траектория должна описывать, как развивается роль, какие уровни зрелости она проходит, какие компетенции и документы подтверждают движение.

## Функция роли


## Принцип стадий зрелости

Цепочки собираются по совместимости стадий зрелости: XS / S / M / L.

## Наложение ролей на траектории

Какая сертифицированная роль может быть наложена на эталонную траекторию другой роли:

- 
- 

## Нетворкинг через самоотметку

Как человек может отметить себя: я предлагаю / я ищу / я могу обучить / мне нужна помощь.

## Алгоритм сопровождения через контур Альянса

Приглашение -> профиль -> специальные условия -> комментарий -> проект -> экспертная валидация -> траектория -> кооперация -> новый цифровой след.

## Предварительные стадии

1. 
2. 
3. 

## Что нужно сверить со Сводом знаний

- KA:
- RL:
- DocKA:
- TR:

## Следующий шаг

02_Рабочий_ритм_и_план_работ/Рабочий_ритм.md

# Рабочий ритм

## Ежедневный цикл

1. Календарь на сегодня.
2. Горизонт 14 дней.
3. Сайт и `Очередь_правок_на_сайт.md`.
4. Свод знаний, глоссарий, онтология, DocKA.
5. Задачи сотрудников / коллег / участников.
6. Рамочные программы / альянсовые контуры.
7. Встречи, транскрипты, конспекты и публикации.

## Принцип

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

02_Рабочий_ритм_и_план_работ/Команда_Видения_ритма.md

# Команда Видения ритма

Этот файл фиксирует не чужие рабочие места, а командный контур, который владелец рабочего места удерживает в своем ежедневном ритме.

## Карточка участника команды

Человек:
Профиль Альянса:
Роль / зона ответственности:
Рамочная программа / альянсовый контур:
Пост-задача / проект / событие на сайте:
Что должно появляться регулярно:
Ритм: ежедневно / еженедельно / по событию
Кто проверяет:
Следующий контроль:
Статус:

02_Рабочий_ритм_и_план_работ/Горизонт_14_дней.md

# Горизонт 14 дней

## Формат строки

Дата:
Встреча:
Рамочная программа / альянсовый контур:
Цель:
Кого пригласить:
Ответственный:
Материалы до встречи:
Нужна ли запись / расшифровка:
Артефакт после встречи:
Где публикуем follow-up:
Связь с KA/RL/TR/DocKA/проектом:

05_Встречи_и_цифровой_след/Рабочая_база_встреч/README.md

# Рабочая база встреч

Каждая встреча должна иметь карточку или файл с минимальными полями:

Дата:
Название:
Рамочная программа / альянсовый контур:
Участники:
Источник:
Режим доступа:
Статус обработки:
Связанные посты/события/проекты:
Что извлечь для Свода знаний:
Следующий шаг:

06_Публикации_и_обновления_платформы/Очередь_правок_на_сайт.md

# Очередь правок на сайт

## Очередь обновлений

Дата:
Материал / решение:
Где изменить на сайте:
Рамочная программа / альянсовый контур:
Режим доступа:
Автор / участники / соавторы:
Почему важно:
Связь с KA / RL / TR / DocKA:
Связанные посты / события / комнаты:
Ответственный:
Кто проверяет:
Статус: planned / draft_ready / needs_review / moved_to_site / published / postponed
Проверка после публикации:

07_Права_доступы_авторство/Реестр_прав_и_доступов.md

# Реестр прав и доступов

## Режимы доступа

- `public` - открытые материалы.
- `resident` - материалы для зарегистрированных резидентов Альянса.
- `private` - приватные материалы роли.
- `local_working` - рабочие локальные материалы.
- `pending_rights` - права требуют уточнения.

## Требования к чувствительному материалу

Название материала:
Источник:
Дата:
Автор / участники / соавторы:
Рамочная программа / альянсовый контур:
Режим доступа: public / resident / private / local_working / pending_rights
Можно хранить локально: да / нет / временно
Можно публиковать: да / только для своих / нет / после согласования
Где опубликовано:
Связь с KA / RL / TR / DocKA:
Кто проверяет:
Статус:
Комментарий:

08_Кооперационные_цепочки_и_рынок_роли/Партнеры_и_запросы.md

# Партнеры и запросы

## Формат записи

Партнер:
Профиль Альянса / сайт:
Роль в цепочке:
Запрос:
Что можем предложить:
Что нужно от партнера:
Стадия зрелости партнера: XS / S / M / L
С какой стадией может работать:
Валидация стадии: подтверждена / требует проверки / не подходит
Сертифицированная роль партнера:
На какую эталонную траекторию роль может быть наложена:
Самоотметка партнера: я предлагаю / я ищу / я могу обучить / мне нужна помощь
Рамочная программа / альянсовый контур:
Связь с KA / RL / TR / DocKA:
Связанные посты / события / комнаты:
Следующий шаг:
Ответственный:
Статус:

99_Архив_исходников/README.md

# Архив исходников

Архив не является источником истины. Если материал становится актуальным, его нужно перенести в рабочий раздел и указать статус.

## Карточка исходника

Название:
Источник:
Дата получения:
Рамочная программа / альянсовый контур:
Режим доступа:
Автор / участники / соавторы:
Зачем хранится:
Что из него извлечено:
Куда перенесено:
Статус: temporary / processed / archived / delete_later / pending_rights
Комментарий:

Если профиль роли еще не заполнен

Если человек еще ничего о себе не рассказал, Codex не должен придумывать роль и траекторию.

Минимальный первый шаг:

  1. Зарегистрироваться или войти на платформу Альянса.

  2. Открыть свой профиль:

    https://alliance.beinopen.ru/user/me/

  3. Заполнить профиль / intro.

  4. Прислать ссылку на свой публичный профиль.

  5. Указать 1-3 профессиональные роли, в которых человек хочет развиваться.

  6. Дать ссылки на проекты, материалы, сайт, соцсети или портфолио.

После этого Codex может собрать первичный паспорт рабочего места на основе цифрового следа, а не на основе догадок.

Правило отсутствующего файла

Если в рабочем месте нет нужного файла, Codex не должен считать это ошибкой структуры.

Сначала нужно обратиться к эталону на сайте:

https://alliance.beinopen.ru/post/3871/

Затем:

  1. проверить, есть ли нужный раздел или шаблон в эталонном протоколе;
  2. если раздел есть, создать локальный файл по эталону;
  3. если раздела нет, предложить новую правку в протокол;
  4. после согласования обновить сайт;
  5. после обновления сайта обновить локальную копию.

Правило:

Сайт Альянса = эталон.
Локальная папка = рабочий снимок.
Отсутствующий локальный файл восстанавливается от эталона на сайте.
Новая структура сначала согласуется, затем возвращается на сайт.

Правило внутренней практики резидентов

Внутренняя практика резидентов хранится на платформе Альянса в согласованном режиме доступа.

По умолчанию рабочие места сотрудников и внешних экспертов не хранят локально чужие траектории, полные транскрипты, закрытые посты и чувствительные материалы резидентов.

В локальном рабочем месте могут храниться:

  • индексы ссылок на платформу;
  • правила работы с внутренней практикой;
  • дайджесты без чувствительных деталей;
  • обезличенные паттерны по роли;
  • материалы, для которых явно разрешено локальное хранение.

Особые режимы доступа фиксируются не в общем протоколе, а в паспорте конкретного рабочего места.

Правило синхронизации

Если локальная работа привела к изменению структуры рабочего места, термина, роли, траектории, доступа или процедуры, изменение должно получить один из статусов:

  • draft - обсуждается локально;
  • в очереди на сайт - принято, но еще не перенесено на сайт;
  • опубликовано на сайте - опубликовано на сайте и стало новым эталоном;
  • needs_review - требует проверки с экспертом, редактором или юристом.

После публикации на сайте локальная копия обновляется от эталона. Если изменение
затрагивает Свод знаний или протокол рабочих мест, после проверки также
обновляется GitHub-версия и ее ссылка фиксируется в паспорте синхронизации.

Перед первым внешним release рабочего места нужно отдельно запросить у владельца
актуальный эталон Свода, сверить все пункты KA1-KA6, авторов, режимы доступа,
DocKA-связи, RLTR и навигацию. Без этой сверки текущий локальный снимок не
объявляется актуальным релизом.

Правило GitHub-рабочих мест

GitHub используется как канал версий, установки и контролируемого backup самого
рабочего места, а не как файловое хранилище всей библиотеки Альянса.

industrial-ai-fashion-workspace содержит общий каркас, шаблоны ролей,
установщик и согласованный открытый Свод. Полный DocKA и его бинарные файлы в
общий репозиторий не входят.

Обязательный вход в Свод внутри рабочего места — KA6: как найти свое положение,
понять траекторию, выбрать KA/DocKA и зафиксировать следующий шаг с датой.

Марка, эксперт, фабрика, куратор и архитектор используют один тип рабочего
места. Архитектор — резидент с расширенными правами: он собирает эталон KA,
удерживает паспорта синхронизации и выпускает согласованные версии.

Private GitHub-backup создается отдельно для конкретного владельца. Нельзя
объединять приватные данные разных резидентов в один репозиторий типа роли.

Правило доступа:

GitHub release задает версию рабочего места и открытого Свода;
платформа показывает DocKA и проверяет контур резидента;
Yandex Disk хранит единый эталонный файл DocKA;
workspace.policy.yaml задает правила для ИИ;
локальное рабочее место хранит выбранные и заполненные документы владельца.

Текущий полный локальный снимок DocKA является только прототипной
инвентаризацией. Он не пушится в GitHub и будет пересобран ролью Архитектора
после проектирования единого Yandex-каталога.

Рабочая архитектура хранится в:

04_Проекты_и_рабочие_задачи/Рабочие_места_GitHub/

Паспорт версии:

04_Проекты_и_рабочие_задачи/Рабочие_места_GitHub/Паспорт_синхронизации_Свода_и_рабочих_мест.md
Аватар Алеша Баженов
Алеша Баженов @abajenov
Координатор — Центр компетенций Альянса x Beinopen
📍Москва, Россия
✖ Институт Beinopen

Ведущий эксперт направления «Реинжинириг системы моды» в Институте развития креативных индустрий НИУ ВШЭ.
Институт развития индустрии моды Beinopen.

https://t.me/abajenov
Соцсети @abajenov2

Связанные посты
15
мая
Форум Альянса x Beinopen: Построение бизнеса в индустрии моды 2026–2030
Аватар Алеша Баженов
Иконка комнаты Акселератор Альянса Акселератор Альянса 29 комментариев
10
сентября
Форум Альянса «Индустриальный искусственный интеллект в моде и эталонная фабрика»
Аватар Алеша Баженов
3 комментария
22
июля
Девятая встреча форкурса. КА6: Навигатор сообщества
Аватар Алеша Баженов
Иконка комнаты Форкурс Форкурс 0 комментариев
5 комментариев
Аватар Лана Харьговская
Лана Харьговская Стилист 25 июня в 10:05

@abajenov, попрсила кодекс сделать анализ как внедряется рабочее место и какие правки он бы внес, он собрал md файл и у меня кончились лимиты до 27го. Как возобновится, могу попросить внести правки или опубликовать как черновик на платформе

  Развернуть 1 комментарий
Аватар Лана Харьговская Лана Харьговская 25 июня в 10:09

@LanaW, https://docs.google.com/document/d/1-MvsBTN2oEMVP_NXoT4ArlGQyO-t3j7_4814GdQKpes/edit?usp=sharing перенесла пока в гугл докс

  Развернуть 1 комментарий
Аватар Алеша Баженов Алеша Баженов 25 июня в 11:06 автор ✖ Институт Beinopen

@LanaW, Норм лимиты заканчиваются)

Ну будем значит беречь)

  Развернуть 1 комментарий
Аватар Алеша Баженов
Алеша Баженов Координатор ✖ Институт Beinopen автор 27 июня в 15:03

@LanaW, спасибо. Мы этот анализ уже частично внесли в сам протокол. Из главного:

  1. Базовая сущность теперь не рабочее место роли, а рабочее место резидента; роль RL описывается как настройка внутри него.
  2. Рабочее место нужно запускать не с абстрактной структуры папок, а с ближайшей живой задачи на 24-48 часов.
  3. Добавлен быстрый запуск на 15-30 минут: паспорт рабочего места, роли, рабочий ритм и ближайшая задача.
  4. Разведены источники истины: платформа Альянса, рабочий реестр, локальное рабочее место, архивы / транскрипты / выгрузки.
  5. CJM оставили внутренним термином архитектора, а для резидента используем человеческие формулировки: путь участника, сопровождение, касания.
  6. Зафиксировали, что рабочий реестр не обязан быть Google Sheets: это может быть md, xlsx, таблица на платформе или другой согласованный формат.
  7. Отдельно добавили правило синхронизации skill: обновили skill -> обновили архив -> обновили установленную копию.

То есть главное изменение такое: рабочее место — это не просто папка, а персональный прикладной контур роли, ритма, цифрового следа, прав доступа и ближайшей задачи. Если нужно, следующим шагом можем отдельно вынести предложения из Google Docs в новую версию протокола или в черновик настройки рабочего места Ланы.

  Развернуть 1 комментарий
Аватар Алеша Баженов
Алеша Баженов Координатор ✖ Институт Beinopen автор 27 июня в 15:33

@LanaW, после чтения самого Google Docs еще дообогатили протокол. Внутрь 3871 уже добавили: отдельную фазу установки skill до создания папок, правило про теплого резидента и маленький полезный шаг до полного развертывания, технические рабочие зоны outputs/tools/work/node_modules и отдельный блок, как проверять, что рабочие места реально скоординированы между собой.

Что тебе полезно проверить на своем этапе:

  1. видит ли твой Codex один и тот же эталонный протокол 3871 как источник истины;
  2. есть ли у тебя handoff-файл для нового чата;
  3. понятно ли, какой live-реестр сейчас главный, а что только локальный черновик;
  4. можешь ли ты из рабочего места за 1-2 шага ответить: что уже решено, что делать дальше и где это зафиксировано на платформе.

Если хочешь, следующим шагом можно отдельно собрать короткий чек-лист "рабочее место Ланы прошло проверку / не прошло" и использовать его как тест координации между нашими контурами.

  Развернуть 1 комментарий

Автор поста открыл его для чтения, но комментировать могут только зарегистрированные участники Альянса Beinopen.

Об Альянсе x Beinopen


Войти   или  Присоединиться к Альянсу