Путь изучения интеллектуальной рабочей среды (IWE)

IWE (Intellectual Work Environment) — интеллектуальная рабочая среда, аналог IDE для развития мышления. Как IDE даёт программисту редактор, компилятор, линтер и дебаггер — так IWE даёт человеку формализованные знания (Pack), автоматическое извлечение (Экстрактор), проверку корректности (FPF/SPF) и диагностику пробелов (Digital Twin). Человек работает вместе с ИИ-агентами, каждый из которых играет свою роль.

Каждый раздел: зачем → что изучить → где найти.

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

Новичок: Разделы 1-2 (что такое IWE, архитектура). Это ~1 час. Поймёшь, как всё устроено.
Первая неделя: Разделы 3-5 (фундамент, репозитории, повседневная работа). По мере необходимости.
Работающий пользователь: Разделы 6-8 (знания, агенты, качество). Когда начнёшь создавать Pack.
Продвинутый: Разделы 9-10 (платформа, рост). Когда захочешь масштабировать.
Справочник: Раздел 11 — быстрый поиск ответов.

Терминология: IWE = интеллектуальная рабочая среда, описываемая через 5 архитектурных видов: системы, описания, роли, методы, рабочие продукты (§ 1.2). Триада A.7: Роль → Метод → Рабочий продукт. Экзокортекс = система хранения описаний внутри IWE (CLAUDE.md + memory/). Подробнее: DP.IWE.001.

Установка: SETUP-GUIDE.md | Политика данных: DATA-POLICY.md | Быстрая справка: IWE-HELP.md | Принципы vs навыки: principles-vs-skills.md

Ссылки ./ — файлы в этом репо. Ссылки github.com/... — другие репозитории.

1. Что такое IWE

1.1. Определение

IWE — персональная система для интеллектуальной работы и развития. Как IDE объединяет редактор, компилятор и дебаггер в одну среду для программиста — так IWE объединяет знания, планирование и ИИ-агентов в одну среду для мышления.

1.1a. Ключевой принцип: экзоскелет, не протез

DP.ARCH.001 принцип #21. Подробно: DP.IWE.001 §5.1.

IWE усиливает мышление пользователя, а не заменяет его. Различение:

Протез: ИИ думает за вас → задача решена, но вы не научились → атрофия
Экзоскелет: вы думаете сами, ИИ усиливает → задача решена + вы стали компетентнее → рост

Три механизма экзоскелета в IWE:

Предъявление, а не генерация. ИИ показывает ваше же знание (Pack, memory/, ЦД) в нужный момент. Думаете вы.
Вопросы, а не ответы (в стратегических решениях). WP Gate заставляет планировать до действия. Consultation T2-T3 спрашивает «а ты как думаешь?» при ленивых запросах.
Убывающие подмостки (scaffolding). Тренировка: больше помощи на начальных уровнях, меньше — на продвинутых. Тиры T0→T4: от прямых ответов к со-мыслительству.

Критерий: после взаимодействия с IWE пользователь стал компетентнее, а не только получил результат.

1.2. Анатомия IWE: пять архитектурных видов

IWE состоит из элементов пяти разных типов: системы, описания, роли, методы и рабочие продукты. Каждый тип рассматривается через свой архитектурный вид (viewpoint) — стандартный подход к описанию сложных систем (ISO/IEC/IEEE 42010). Центральный организующий принцип — триада FPF A.7: Роль → Метод → Рабочий продукт.

Три классификации IWE: Виды (этот раздел) отвечают на «из чего состоит». Контуры L1–L4 (§ 2.1) — «где живёт». Тиры T0-T4 + TM/TA/TD (§ 9.1) — «какой уровень доступа».

Вид 1: Системы (U.System) — что имеет 4D-границы

Системы с границами, входами, выходами и владельцем. Можно запустить, остановить, обновить. Здесь перечислены основные системы IWE; дополнительные (WakaTime и др.) описаны в § 2.6.

Система	Тип	Что делает	Контур (§ 2.1)
Claude Code CLI (A1)	LLM-агент	Основной ИИ-исполнитель: код, анализ, планирование	L4 Personal
Telegram-бот (I1, @aist_me_bot)	Сервис	Заметки, программы, Digital Twin, уведомления	L2 Platform
MCP-серверы (I3-I8)	Протокол	Доступ к Pack, гайдам, DS-описаниям из Claude Code	L2 Platform
Git + GitHub	VCS	Версионирование, хранение, CI	L3 Template / L4
Экзокортекс	Файловая система	Хранение и доставка описаний (CLAUDE.md + memory/)	L3 Template / L4
Neon DB (ЦД)	СУБД	Хранение событий Цифрового двойника	L2 Platform

Тест: Есть 4D-граница, владелец, входы/выходы? → Система.

Экзокортекс виден из двух видов. Через линзу «Системы»: файловая система с lifecycle (Open/Close), владельцем, границами. Через линзу «Описания»: содержимое этих файлов — различения, принципы, протоколы. Не два объекта, а два ракурса на один (ISO 42010).

Neon DB — аналогично. Через линзу «Системы»: работающая СУБД с 4D-границами (HD #27: бот — клиент, не владелец). Через линзу «Рабочие продукты»: события, записанные в эту СУБД.

Роли (Вид 3) запускаются автоматически через системный планировщик ОС: launchd (macOS) или cron (Linux). Планировщик не входит в IWE — это инфраструктура операционной системы. Устанавливается один раз при setup.

Вид 2: Описания (U.Description) — знания, загружаемые в системы

Текстовые описания, которые загружаются в контекст ИИ и определяют его поведение. Не запускаются — читаются.

Описание	Состав	Назначение
Принципы (FPF, SPF, ZP)	Закодированы в экзокортексе и промптах	Принципы корректного мышления, fallback chain
Содержимое экзокортекса	`CLAUDE.md` + `MEMORY.md` + `memory/*.md`	Правила, различения, SOTA, навигация
Pack-сущности	`PACK-{область}/pack/*/.md`	Формализованные описания предметных областей (source-of-truth)
Промпты ролей	`roles//prompts/.md`	Конфигурация ролей: day-plan, week-review, session-close и др.

Тест: Можно передать файлом, загрузить в систему? → Описание.

Вид 3: Роли (U.RoleAssignment) — функции, независимые от исполнителя

Роль описывает функцию (ЧТО делать), а не исполнителя (КТО). Один исполнитель (holder) может играть несколько ролей. Одну роль могут играть разные исполнители (Claude, bash-скрипт, человек). Подробнее: DP.ROLE.001 §3.

Роль	Код	Исполнитель (holder)	Что делает	Когда
Стратег	R1	Claude CLI (по расписанию)	Планирование, рефлексия, подготовка к сессиям	Каждое утро, вечер, неделя
Экстрактор	R2	Claude CLI	Извлечение описаний в Pack	При Close, по запросу, каждые 3 ч
Синхронизатор	R8	bash-скрипт (по расписанию)	Координация расписания, уведомления, ночной обзор	По расписанию
Проводник	R13	Telegram-бот	Навигация пользователя по сервисам платформы	При обращении пользователя
Пользователь	—	Человек	Принятие решений, создание, рефлексия	Всегда

Тест: Функция, описываемая без имени исполнителя? → Роль.

Роль ≠ Исполнитель (HD #5). Нотация «Стратег (R1) ← Claude» читается: роль Стратег, holder — Claude. «Человек» — не роль, а исполнитель, играющий роль «Пользователь».

Нотация FPF: Holder#Role:Context@Window (A.2). Полный каталог: 21 платформенная роль в DP.ROLE.001 §3.2.

Вид 4: Методы (U.MethodDescription) — как роль производит рабочий продукт

Описания методов (процедуры «как делать»), связывающие роль с рабочим продуктом. Имеют собственный жизненный цикл, владельцев и тесты корректности.

Метод	Что описывает	Роль-владелец	Рабочий продукт
Протокол ОРЗ	Open → Work → Close каждой сессии	Все роли	WP context, планы, отчёты
Capture-to-Pack	Извлечение знаний на рубежах работы	R2 Экстрактор	Pack-сущности
ArchGate (ЭМОГССБ)	Оценка архитектурных решений по 7 характеристикам	R1 Стратег	Таблица оценки, решение
Knowledge Extraction (KE)	Трансформация сырых данных в Pack-сущности	R2 Экстрактор	Pack-сущности
Note-Review	Разбор заметок, маршрутизация в нужные репо	R1 Стратег	Разобранные заметки, задачи

Тест: Процедура «как делать», описываемая независимо от исполнителя? → Метод.

Почему отдельный вид? Триада A.7 (Role → Method → Work) — центральное различение FPF. Без вида «Методы» протоколы теряются в Описаниях, хотя они — не просто знания, а процедуры, связывающие роли с рабочими продуктами.

Вид 5: Рабочие продукты (U.Work) — что производится

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

Рабочий продукт	Где	Кто производит	Для чего
Стратегический хаб	`DS-strategy/`	R1 Стратег + Пользователь	Хранение личных документов (планы, стратегия, inbox) и проведение сессий стратегирования
Pack-документы	`PACK-{область}/`	R2 Экстрактор + Пользователь	Накопление формализованных описаний предметной области (единственный source-of-truth)
Проектные репо	`DS-{проекты}/`	Пользователь + Claude Code	Создание конкретных продуктов: код, боты, курсы, контент
События ЦД	Neon DB	Бот + LMS + Клуб	Персонализация и рефлексия: профиль, прогресс, самооценка
Заметки	`DS-strategy/inbox/`	Бот (из Telegram)	Быстрая фиксация мыслей и наблюдений для последующей обработки Стратегом
Посты, черновики	`DS-strategy/drafts/`, Knowledge Index	Пользователь	Кристаллизация мыслей и публикация

Тест: Можно передать другому без слов? Остаётся после завершения работы? → Рабочий продукт.

Как виды связаны

         Роль ──method──→ Метод ──produces──→ Рабочий продукт
              ↑                                    │
         Описания                            Capture-to-Pack
         загружаются в роли                  обратно в Описания
              ↑
         Системы
         исполняют роли

Примеры цепочек (Роль → Метод → Рабочий продукт):
  R1 Стратег ──── ОРЗ ──────────────── WeekPlan, DayPlan
  R2 Экстрактор ── Capture-to-Pack ──── Pack-сущности
  R1 Стратег ──── Note-Review ─────── Разобранные заметки
  Пользователь ── ArchGate ─────────── Таблица ЭМОГССБ + решение

Принцип целостности: Убери любой вид — и IWE деградирует. Без систем — нет исполнения. Без описаний — stateless ассистент. Без ролей — хаос задач. Без методов — работа ad hoc. Без рабочих продуктов — нет результата.

1.3. Путь пользователя

Ось T (учащийся):
T0 Без Ory          T1 Старт            T2 Изучение         T3 Персонализация    T4 Созидание (IWE)
├── /start в боте   ├── Регистрация Ory  ├── Программы        ├── Digital Twin      ├── setup.sh
├── telegram_id     ├── UUID             ├── Марафон          ├── Профиль + цели    ├── Claude Code
├── trial 30 дней   ├── trial 30 дней    ├── Бот + контент    ├── Наставник         ├── Стратег + планы
└── Базовый поиск   └── Ассистент        └── Эксперт          └── Наставник         └── Со-мыслитель

Ортогональные оси (назначаются):
TM1-TM3: Наставник    TA1-TA4: Администратор    TD1: Разработчик

Ключевое: T0–T3 работают без Git — всё через бот. T4 добавляет Claude Code, Git, автоматических агентов. TD1 (разработчик) — ортогональная ось: доступ к исходному коду, деплою и архитектурным решениям. Владелец = T4 + TA4 + TD1. Переход постепенный — всё ранее накопленное (Digital Twin, профиль, прогресс) сохраняется.

Центральный инвариант IWE: Обновления платформы (Standard) никогда не затрагивают данные пользователя (Personal). Твои планы, знания и стратегия принадлежат тебе.

2. Архитектура: контуры и пространства

2.1. Четыре контура системы

IWE существует не изолированно — она часть 4-контурной системы. Каждый контур соответствует своему уровню в иерархии принципов (§ 3.1):

L1: Ecosystem    — вся система: платформа + сообщество + все IWE пользователей
  L2: Platform   — инфраструктура и сервисы (бот, MCP, Knowledge Index)
    L3: Template — этот шаблон (CLAUDE.md + memory/ + Стратег + seed/)
      L4: Personal IWE — твой экземпляр (настроенный, с личными Pack и данными)

Контур	Что для тебя	Пример	Как обновляется
L1: Ecosystem	Сообщество, семинары, контент	systemsworld.club, Telegram-каналы	Ты участвуешь
L2: Platform	Сервисы, к которым подключаешься	Бот @aist_me_bot, Knowledge Index	Обновляется разработчиком
L3: Template	Шаблон, из которого создан твой IWE	Этот репо (FMT-exocortex-template)	`update.sh` — Platform-space
L4: Personal IWE	Твоя работа, планы, знания	~/IWE/CLAUDE.md, DS-strategy/	Только ты (User-space)

Где изучить:

ONTOLOGY.md § «Контуры системы»
DS-ecosystem-development/11-platform-contours.md — полная архитектурная модель

2.2. От шаблона к рабочему пространству

Структура репо FMT-exocortex-template

FMT-exocortex-template/
│
├── CLAUDE.md                        # Правила для Claude Code
├── README.md                        # Быстрый старт
├── REPO-TYPE.md                     # Тип репозитория (Format)
├── ONTOLOGY.md                      # Онтология экзокортекса
├── update.sh                        # Обновление из upstream
│
├── memory/                          # Оперативная память (≤10 файлов)
│   ├── MEMORY.md                    # ★ PERSONAL: задачи, навигация
│   └── *.md                         # PLATFORM: протоколы, SOTA, чеклисты
│
├── docs/                            # Справочная документация
│   └── LEARNING-PATH.md             # Этот файл
│
├── roles/                          # Роли (точка расширения)
│   └── strategist/                  # Стратег: промпты + скрипты + launchd
│
├── seed/                            # Заготовки → отдельные репо после setup
│   └── strategy/                    # → DS-strategy/
│
└── .claude/                         # Конфигурация Claude Code
    ├── hooks/                       # WakaTime heartbeat
    └── skills/                      # /setup-wakatime

Четыре зоны

Зона	Что	update.sh	Пользователь
PLATFORM	`CLAUDE.md` (§1-7), `memory/protocol-*.md`, `roles/`, `docs/`, `.claude/`	Обновляет	Не трогает
USER-SPACE	`CLAUDE.md` § «Мои правила» (секция `<!-- USER-SPACE -->`)	Не трогает	Свои правила, различения
CONFIG	`memory/day-rhythm-config.yaml`	Не трогает	Настраивает параметры
PERSONAL	`memory/MEMORY.md`, AUTHOR-ONLY зоны в протоколах	Не трогает	Редактирует
SEED	`seed/strategy/`	N/A	После setup → отдельный репо DS-strategy/

USER-SPACE — секция «8. Мои правила» в конце CLAUDE.md. Добавляйте свои правила, различения и уроки только сюда — они сохраняются при обновлении. Всё что выше (§1-7) — платформенное и обновляется через update.sh. AUTHOR-ONLY зоны — блоки внутри PLATFORM-файлов, помеченные  маркерами. При update.sh они сохраняются. Подробности: CLAUDE.md §7.

Что делает setup.sh

Форкает шаблон → твой GitHub аккаунт
Подставляет 7 плейсхолдеров ({{GITHUB_USER}}, {{WORKSPACE_DIR}} и др.)
Копирует CLAUDE.md → корень рабочей директории
Копирует memory/*.md → ~/.claude/projects/.../memory/
Создаёт DS-strategy/ из seed/strategy/ (отдельный приватный репо)
Устанавливает launchd-агентов для Стратега

Workspace после setup

~/IWE/
├── CLAUDE.md                          # читается каждую сессию (авто)
├── DS-strategy/                       # ★ ежедневно: планы, inbox, стратегия
│   ├── current/DayPlan, WeekPlan      # Стратег пишет, ты читаешь
│   ├── inbox/WP-*.md                  # контексты задач
│   └── docs/Strategy.md              # твоя стратегия
├── FMT-exocortex-template/            # НЕ трогать (обновляется через update.sh)
├── PACK-{область}/                    # когда создашь: доменные знания
└── DS-{проекты}/                      # когда создашь: код, инструменты

2.3. Что даёт платформа через шаблон (Standard)

Через шаблон и обновления ты получаешь готовую методологию:

Компонент	Что это	Файлы
Протоколы	Open → Work → Close: как вести сессию	`memory/protocol-*.md`
Память	11 файлов: различения, SOTA, роли, чеклисты, навигация	`memory/*.md`
Стратег	7 сценариев автоматического планирования	`roles/strategist/prompts/`
Инструменты	WakaTime hook, Claude Code skills	`.claude/hooks/`, `.claude/skills/`
Правила	Архитектура репо, процессы, gates	`CLAUDE.md`

Всё это обновляется через update.sh — ты получаешь улучшения без потери личного.

2.4. Что накапливается у тебя (Personal)

Твои данные живут отдельно и никогда не затрагиваются обновлениями:

Слой	Что	Где	Как растёт
Fleeting notes	Мимолётные заметки	`DS-strategy/inbox/fleeting-notes.md`	Бот: «.текст»
Captures	Захваченные знания	`DS-strategy/inbox/captures.md`	Claude: Capture-to-Pack
Память	Задачи, уроки, навигация	`MEMORY.md`	Claude обновляет каждую сессию
Конфигурация	Параметры поведения	`memory/day-rhythm-config.yaml`	Ты настраиваешь
AUTHOR-ONLY зоны	Твои расширения протоколов	`memory/protocol-*.md`	Ты добавляешь
Pack-сущности	Формализованные знания	`PACK-{область}/`	Экстрактор формализует captures
Контент	Посты, курсы	`DS-{проекты}/`	Ты создаёшь

Три паттерна кастомизации (L3 → L4)

Паттерн	Механизм	Пример	Для чего
Конфиг	yaml-файл с параметрами	`strategy_day: saturday`	Настройки поведения агентов
AUTHOR-ONLY зоны	HTML-маркеры в протоколах	Проверки специфичных систем	Расширение протоколов без конфликтов с update.sh
Плейсхолдеры	`{{WORKSPACE_DIR}}` и др.	Пути, имя пользователя GitHub	Автоподстановка при setup

Подробнее о AUTHOR-ONLY зонах: CLAUDE.md §7.

2.5. Обновления: update.sh

Одна команда: cd ~/IWE/FMT-exocortex-template && bash update.sh

Скрипт скачивает манифест обновлений с GitHub, сравнивает sha256 локальных файлов с upstream, показывает превью и применяет после подтверждения:

Шаг	Что делает	Результат
0. Self-update	Проверяет, есть ли новая версия update.sh	Скрипт всегда актуален
1. Манифест	Скачивает `update-manifest.json` из GitHub	Список файлов для обновления
2. Сравнение	sha256 локальных файлов vs remote	Список нового и изменённого
3. Превью	Показывает: новые файлы, обновлённые, не затрагиваемые	Ты решаешь: применить или нет
4. Применение	Скачивает и заменяет файлы, подставляет переменные	Платформенные файлы обновлены
5. Platform-space	Копирует CLAUDE.md → workspace, memory/ → ~/.claude/	Живые файлы обновлены
6. Роли	Переустанавливает роли, если их файлы изменились	Агенты обновлены

Что НЕ затрагивается:

CLAUDE.md § «Мои правила»  ← Секция USER-SPACE (твои правила и различения)
MEMORY.md                   ← Твоя таблица РП
DS-strategy/                ← Твои планы, inbox/, docs/
PACK-{область}/             ← Твои доменные знания
.secrets/, .mcp.json        ← Ключи и конфигурация
.claude/settings.local.json ← Твои permissions

Свои правила: добавляй в секцию «8. Мои правила» в конце CLAUDE.md (после маркера ). Эта секция сохраняется при обновлении. Правила в <repo>/CLAUDE.md конкретных репо не затрагиваются вообще.

Дополнительные режимы:

bash update.sh --check — только показать, есть ли обновления (без применения)
bash update.sh --yes — применить без подтверждения

Накопительная модель обновлений:

Изменения в шаблоне накапливаются. Ты можешь обновляться раз в день, раз в неделю или раз в месяц — одна команда bash update.sh применит всё накопленное за этот период. CHANGELOG.md покажет, что изменилось.

Оповещения в Telegram:

Каждое утро в 7:28 бот @aist_me_bot отправляет дайджест изменений за последние 24 часа (если они были). Подпишись на канал обновлений, чтобы не пропустить. Оповещение = информация. Решение обновляться — всегда за тобой.

Три способа обновить:

Терминал: bash update.sh
AI CLI: скажи своему ИИ «обнови мой экзокортекс»
Проверить без применения: bash update.sh --check

2.6. Опциональные сервисы

Шаблон (L3) рекомендует, но не обязывает. Каждый настраивается отдельно:

Сервис	Тип	Настройка	Роль	Продукт
WakaTime	Инструмент	`/setup-wakatime`	Observability работы	Метрики по проектам и категориям
Digital Twin	Данные	Бот → `/twin`	Персонализация ответов и планов	Цели, самооценка, контекст
systemsworld.club	Экосистема	Регистрация	Сообщество, семинары	Доступ к материалам
Git + GitHub	Инфраструктура	`setup.sh` (авто)	Версионирование, агенты	Репозитории, CI
Marp	Инструмент	VS Code extension + CLI	Markdown → слайды	Слайдоменты (PDF/HTML)
Cloud Scheduler	Автоматика	`setup/optional/setup-cloud-scheduler.sh`	IWE работает 24/7 при выключенном Mac	Backup, health check, уведомления

Cloud Scheduler — облачная автоматика IWE: GitHub Actions workflow запускает backup и health check ежедневно в 04:00 MSK — даже если Mac выключен. Базовый уровень ($0/мес, без LLM). Опционально: Telegram-уведомления с отчётом. Установка: bash setup/optional/setup-cloud-scheduler.sh. Подробности: setup/optional/README.md, сценарий DP.SC.019.

Настройка Health Check (расширенный): По умолчанию health check проверяет только strategy-репо. Для мульти-репо мониторинга:

GitHub → Settings → Variables → Actions → добавьте HEALTH_CHECK_REPOS — список ваших репо через запятую (owner/repo, owner/repo2)
(Опционально) Добавьте BOT_HEALTH_URL — URL health endpoint бота для проверки доступности
(Опционально) Добавьте Secrets: TELEGRAM_BOT_TOKEN + TELEGRAM_CHAT_ID для уведомлений в Telegram
PAT (STRATEGY_REPO_TOKEN) должен иметь доступ ко всем указанным репо

Ручной запуск: gh workflow run cloud-scheduler.yml --field task=health-check. Отчёт: коммиты (24ч + 7д по репо), DayPlan, WeekPlan, backup (<48ч), сессии, статус бота, WP-статистика, светофор.

Marp — подготовка презентаций: Marp превращает Markdown-файлы в слайды (PDF, HTML, PPTX). Workflow: пишешь .md с разделителем --- → предпросмотр в VS Code (Marp extension) → экспорт marp --pdf slides.md. Слайдоменты (MIM.WP.001) — текстовые, поэтому Markdown + Git = версии, диффы, правки через Claude Code. Установка: npm install -g @marp-team/marp-cli + VS Code → Extensions → «Marp for VS Code».

Правило IntegrationGate: Перед добавлением нового инструмента в свой IWE: (1) тип, (2) контур (L2/L3/L4), (3) роли, (4) продукты, (5) процессы.

3. Фундамент мышления

3.1. Иерархия принципов

Всё знание организовано в 4 уровня. Каждый следующий ограничен предыдущим:

Уровень 0: ZP (нулевые принципы)         ← аксиомы, фреймворка нет
    ↓ дисциплинируют
Уровень 1: FPF (первые принципы)          ← принципы + фреймворк (бандл)
    ↓ ограничивают
Уровень 2: SPF → Pack (вторые принципы)   ← фреймворк + принципы (раздельно)
    ↓ определяют
Уровень 3: S2R и др. → DS                  ← фреймворки + принципы (раздельно)

Fallback chain: DS (3-й) → Pack (2-й) → Base.Принципы (SPF → FPF → ZP). Если непонятно на текущем уровне — поднимись на уровень выше.

Нулевые принципы (ZP) — 6 транс-дисциплинарных ограничений:

Принцип	Суть
ZP.1 Аксиоматичность	Строй на аксиомах, не на интуиции
ZP.2 Структура и симметрия	Описывай через инварианты, не объекты
ZP.3 Многомасштабность	Модель должна работать на разных масштабах
ZP.4 Оптимизация	Ищи экстремум, не перебирай
ZP.5 Вероятность и информация	Описывай неопределённость количественно
ZP.6 Вычислительные пределы	Учитывай конечность ресурсов

Где изучить:

ZP/hierarchy.md — карта всех 4 уровней
ZP/principles/ — каждый принцип подробно
CLAUDE.md § 1 — таблица типов и fallback chain

3.2. Жёсткие различения

30+ пар понятий, которые нельзя путать. Путаница — главный источник ошибок:

#	Пара	Суть
1	Система ≠ Эпистема	Физические границы vs. область знаний
2	Метод ≠ Инструмент	Способ работы vs. инструмент работы
3	Рабочий продукт ≠ Описание	Наблюдаемый артефакт vs. текст о нём
4	Учёт ≠ Планирование	Фиксация фактов vs. намерения
5	Роль ≠ Агент ≠ Инструмент	Маска vs. кто носит маску vs. инструмент
6	Метод ≠ Навык	Воспроизводимый процесс vs. личная способность
7	Наблюдение ≠ Суждение	Факт vs. интерпретация
8-11	Данные ≠ Инсайт, Артефакт ≠ Процесс, Pack ≠ Governance, Процесс ≠ Сервис ≠ Сценарий	Онтологические
12-22	Описание ≠ Знание, DDD стратегический ≠ тактический, Platform ≠ Template ≠ Personal IWE, ...	Методологические и операционные
25-26	Черновик ≠ Заготовка, Заготовка ≠ Пост	Стадии творческого конвейера
27	Бот ≠ Платформа; Neon = один ЦД	Архитектура ЦД
28	Протез ≠ Экзоскелет	Паттерн взаимодействия ИИ с человеком (§ 1.1a)
29	Pack-знание ≠ Реализационное решение	Доменная истина → Pack. Технический выбор → DS
32	Три класса верификации	closed-loop / open-loop / problem-framing (§ 5.1b)
36	Экзокортекс ≠ IWE	Экзокортекс — подсистема хранения описаний внутри IWE

Где изучить:

memory/hard-distinctions.md — все 22 пары с примерами и тестами

3.3. Первые принципы FPF

FPF (First Principles Framework) — «операционная система для мышления». Определяет базовые конструкции и правила их комбинирования.

Часть	Содержание	Когда читать
A	Ядро: Холон, BoundedContext, Роль-Метод-Работа	Базовые различения
B	Агрегация, Доверие, Циклы эволюции	Понимание процессов
C	Доменные расширения (CAL)	Кастомные исчисления
D	Этика и оптимизация конфликтов	Многомасштабные решения
E	Конституция и авторство	Управление фреймворком
F	Терминология: UTS, Мосты	Кросс-доменное выравнивание
G	SoTA Kit	Паттерны knowledge work

Как читать: НЕ последовательно. Сначала оглавление, затем нужные секции через поиск по коду (например FPF A.7 = Strict Distinction).

Где изучить:

FPF/README.md — обзор
memory/fpf-reference.md — навигация по ключевым секциям

4. Репозитории и проекты

4.1. Три типа репозиториев

Каждый репозиторий принадлежит одному из 3 типов. Тип определяет, кто создаёт и что хранит:

Тип	Подтип	Что хранит	Source-of-truth?	Примеры
Base	Принципы	ZP, FPF, SPF — принципы и фреймворки	Да	ZP, FPF, SPF
Base	Форматы	FMT-* — протоколы структуры	Да (для формата)	FMT-exocortex-template, FMT-s2r
Pack	—	Паспорт предметной области	Да	PACK-{область}
DS	instrument / governance / surface	Производные от Pack	Нет	DS-strategy, DS-ai-systems

Ключевое: Base = платформа выдаёт (принципы, фреймворки, шаблоны). Pack и DS = пользователь создаёт. Pack — единственный source-of-truth для доменного знания. DS потребляет, не создаёт.

Где изучить:

CLAUDE.md § 1 — полная таблица, fallback chain
memory/repo-type-rules.md — правила по каждому типу

4.2. DS: три подтипа

DS — самый частый тип репозитория, который ты будешь создавать:

Подтип	Что хранит	Примеры	Когда создавать
governance	Планы, стратегия, координация	DS-strategy, DS-ecosystem-development	При setup (DS-strategy — автоматически)
instrument	Код, боты, агенты, MCP	DS-ai-systems, DS-aist-bot	Когда строишь систему на основе Pack
surface	Курсы, гайды, посты, контент	DS-Knowledge-Index, DS-blog	Когда создаёшь образовательный контент

4.3. Base/Форматы — стандартные шаблоны

Платформа предоставляет стандартные форматы (Base/Форматы) — протоколы структуры репозиториев:

Формат	Назначение	Для кого
FMT-exocortex-template	Персональное рабочее пространство (IWE)	Каждый пользователь T4+
FMT-s2r	Проектные репо: 3×3 матрица (системы × роли)	Продвинутые пользователи с многокомпонентными проектами

FMT-s2r (System-to-Role) организует проект по ядрам (kernels), каждое из которых описывается через 9 документов (3 системы × 3 роли). Полезен, когда проект имеет несколько систем: мобильное приложение + бэкенд + инфраструктура.

Свои форматы: Пользователь может создать собственный формат — это будет репо DS с пометкой template: true в REPO-TYPE.md.

Где изучить:

FMT-s2r/README.md — обзор и структура

4.4. Создание и управление DS-проектами

Когда создавать:

Ситуация	Что создать	Как
Определил область знаний	`PACK-{область}`	Из шаблона SPF/pack-template
Строишь систему (бот, инструмент)	`DS-{проект}` (instrument)	`gh repo create DS-my-tool --private`
Создаёшь курс или контент	`DS-{проект}` (surface)	`gh repo create DS-my-course --private`
Координируешь несколько систем	`DS-{хаб}` (governance)	`gh repo create DS-my-hub --private`

Что должно быть внутри каждого DS-*:

CLAUDE.md — правила для Claude Code (специфичные для этого репо)
WORKPLAN.md — текущие задачи
MAPSTRATEGIC.md — куда двигается ЭТА система

MAPSTRATEGIC.md vs Strategy.md:

	MAPSTRATEGIC.md	Strategy.md
Где	В каждом репо системы	`DS-strategy/docs/`
Кто пишет	Владелец системы	Стратег (агрегация)
Что	«Куда двигается ЭТА система»	«Куда двигаюсь Я»

Поток: MAPSTRATEGIC (каждый репо) → Стратег (session-prep) → Strategy.md → WeekPlan

4.5. Именование и кодирование

Префиксы репозиториев:

Префикс	Тип	Пример
`ZP`, `FPF`, `SPF`	Base/Принципы	ZP, FPF, SPF
`FMT-`	Base/Форматы	FMT-exocortex-template
`PACK-`	Pack	PACK-digital-platform
`DS-`	DS	DS-ai-systems, DS-strategy

Кодирование Pack-сущностей: КОНТЕКСТ.ТИП.NNN

Часть	Что	Пример
Контекст	Аббревиатура Pack	DP (digital-platform), MIM, PD
Тип	Вид сущности	M (метод), WP (рабочий продукт), D (различение), FM (failure mode)
Номер	Уникальный порядковый	001, 002, ...

Примеры: DP.M.001 (метод), MIM.FM.003 (failure mode), DP.ROLE.001 (агент)

Где изучить:

SPF/spec/SPF.SPEC.001-entity-coding.md — полная спецификация

5. Повседневная работа

5.1. ОРЗ-фрактал: День и Сессия

ОРЗ (Открытие → Работа → Закрытие) — фрактальный паттерн, работающий на двух масштабах. День состоит из сессий, каждая сессия — полный цикл ОРЗ внутри дневного цикла.

День (Day)
├── Day Open   — утренний ритуал: вчера → план → саморазвитие → мир
│   ├── Сессия 1: Open → Work → Close
│   ├── Сессия 2: Open → Work → Close
│   └── ...
└── Day Close  — вечерний ритуал: итоги → похвала → задел на завтра

Сессия (Session)
├── Session Open  — WP Gate → Ритуал согласования
├── Session Work  — Capture-to-Pack + рубежные проверки
└── Session Close — KE → статусы → backup → отчёт

Пропуск Open = незапланированная работа. Пропуск Close = незафиксированный результат.

Масштаб	Стадия	Триггер	Роль
День	Открытие	«открывай день»	R1 Стратег
День	Работа	Между Day Open и Day Close	R1 + R6
День	Закрытие	«закрываю день» / «итоги дня»	R1 Стратег
Сессия	Открытие	Любое задание (без исключений)	R6 Кодировщик
Сессия	Работа	После прохождения Открытия	R6 Кодировщик
Сессия	Закрытие	«закрываю» / «всё» / «закрывай»	R6 Кодировщик

Различение: День ≠ Сессия. Day Open/Close — отдельные сессии-ритуалы (только триггер, без задания). Session Open/Close — всегда в контексте конкретной работы.

Day Open (утренний ритуал)

Стратег (R1) выполняет 7 шагов:

Вчера — коммиты за вчера по всем репо → 1-3 ключевых результата
План на сегодня — из WeekPlan выбрать 2-4 РП. Слот 1 = саморазвитие (обязательно)
Саморазвитие — текущее руководство, где остановился, активные черновики
Стратегирование — если сегодня strategy_day (из day-rhythm-config.yaml) → DayPlan НЕ создавать (план дня уже в WeekPlan → секция «План на понедельник»). Показать WeekPlan, пропустить шаг 7 4b. Помидорки — показать текущие настройки (work/break/long break), предложить скорректировать
IWE за ночь — логи автоматики (sync-agent, note-review, reindex) — отработали?
Мир — дайджест по настроенным топикам (RSS / WebSearch)
Запись — создать/обновить DayPlan YYYY-MM-DD.md в DS-strategy/current/. Пропускается в strategy_day (шаг 4)

Продукт: DayPlan (в обычные дни) или WeekPlan (в strategy_day) — handoff-артефакт от Стратега к Человеку.

Day Close (вечерний ритуал)

Стратег (R1) собирает итоги дня:

Обзор — таблица «РП × статус» (done / partial / not started)
Что нового узнал — captures в Pack, различения, инсайты, руководство
Похвала — что получилось, что было непросто
Не забыто? — незакоммиченные изменения, синхронизация веток, обещания
Задел на завтра — с чего начать, какой контекст подготовить (Agent→Agent handoff)
Запись — дописать «Итоги дня» в DayPlan, обновить статусы в WeekPlan + MEMORY.md

Day Work (правила дня)

#	Правило	Суть
1	Слот 1 = саморазвитие	Не переходить к текучке, пока слот не отработан
2	Сессии = ОРЗ	Каждая сессия — полный цикл Open → Work → Close
3	Помидорки	25/5, длинный перерыв после 4 циклов
4	Напоминание	Сессия > 50 мин без перерыва → напоминание
5	Сверка с планом	Между сессиями: «Я ещё на плане дня?»

5.1b. Session Open: WP Gate + Ритуал

WP Gate (блокирующее)

Первое действие на ЛЮБОЕ задание: проверить, есть ли задача в плане.

Прочитать MEMORY.md → секция «РП текущей недели»
Совпадает → работаем + DayPlan Gate: если РП нет в DayPlan текущего дня → добавить строку
Не совпадает → СТОП → записать РП в 4 места (MEMORY.md, WP-REGISTRY, WeekPlan, WP context file) → только потом начать

Исключения: задачи ≤15 мин, вопросы без изменений, экстренные баг-фиксы. Но если исключение перерастает в реальную работу → «Это перерастает в РП. Записать?»

Ритуал согласования

Перед работой Claude объявляет:

«Роль пользователя: [из 4 ролей]. Роль Claude: [из каталога]. Работа: [что]. РП: [артефакт]. Класс верификации: [trivial / closed-loop / open-loop / problem-framing]. Метод: [как]. Оценка: [~Xh]. Модель: [текущая] — рекомендую [модель] ([причина]).»

4 роли пользователя (Tseren в своём IWE):

Разработчик платформы → Pack, DS-ecosystem, FMT
Пользователь платформы → бот, LMS, курсы
Разработчик своего IWE → exocortex, CLAUDE.md, протоколы (НАД системой)
Пользователь своего IWE → планы, ревью, посты, captures (В системе)

Класс верификации (определяет режим работы):

Класс	Проверка	Режим	Рекомендация модели
trivial	Не нужна (результат очевиден)	Агент автономно, без captures	Haiku
closed-loop	Дешёвая, авто (тесты)	Агент автономно	Sonnet
open-loop	Дорогая, отложенная	Совместно, captures обязательны	Opus
problem-framing	Неизвестная	Экзоскелетный: вопросы > ответы	Opus

Переключение модели — два сценария:

Вся сессия на другой модели: Если при открытии Claude определил, что задача trivial/closed-loop и текущая модель избыточна, он скажет: «Эта задача trivial, рекомендую переключиться на Haiku через /model. Переключить автоматически я не могу.» Пользователь сам переключает → вся сессия на дешёвой модели.

Отдельная задача внутри сессии: Посреди сессии появилась trivial-задача → Claude делегирует sub-agent'у на дешёвой модели. Сессия не прерывается. Делегирование только вниз: Opus→Sonnet/Haiku, Sonnet→Haiku. Переключение вверх — только через /model.

Экзоскелетный режим (только problem-framing): Claude НЕ предлагает решение сразу. Сначала 3 уточняющих вопроса (Что? Зачем? Ограничения?) → ответы → 2-3 варианта подхода с trade-offs → пользователь выбирает → работа.

Регистрация сессии: после согласования → строка в DS-agent-workspace/scheduler/open-sessions.log.

5.1c. Session Close: полный чеклист

Exit Protocol (для всех ролей)

#	Шаг	Зачем
1	Артефакт	Без артефакта — работа не существует
2	Статус	Без статуса — прогресс невидим
3	Уведомление	Без уведомления — цепочка обрывается

Где изучить:

CLAUDE.md § 2 — slim-правила и триггеры
memory/protocol-open.md — Day Open + Session Open (полные алгоритмы)
memory/protocol-work.md — Day Work + Session Work
memory/protocol-close.md — Day Close + Session Close (полные алгоритмы)

5.2. Трёхслойная память

Слой	Файл	Что содержит	Лимит	Когда читается
1	`MEMORY.md`	Задачи недели, уроки, навигация	≤200 строк	Каждая сессия (авто)
2	`CLAUDE.md`	Правила, архитектура, процессы, триггеры	≤150 строк	При старте (авто)
3	`memory/*.md`	Протоколы, различения, SOTA, роли, чеклисты	≤11 файлов	По триггерам из CLAUDE.md

Файлы memory/:

Файл	Тема	Когда читать
`protocol-open.md`	Протокол открытия	Каждая сессия (авто)
`protocol-work.md`	Протокол работы	После открытия
`protocol-close.md`	Протокол закрытия	При завершении
`navigation.md`	Навигация по репо	Поиск файлов
`hard-distinctions.md`	30+ различений	При путанице в терминах
`fpf-reference.md`	Навигация по FPF	При создании/ревью Pack
`sota-reference.md`	SOTA-практики	При архитектурных решениях
`checklists.md`	Чеклисты качества	Перед ответом, модификацией
`repo-type-rules.md`	Правила по типам репо	При работе с конкретным типом
`roles.md`	Каталог ролей (ИИ + человеческие)	При ритуале открытия сессии

roles.md — развиваемый файл. Шаблон поставляет платформенные роли (R1–R21). Добавляйте свои роли в секцию «Пользовательские роли» (R100+). Это помогает Claude точно выбирать поведение для каждой задачи — не угадывать, а сверяться с таблицей.

Политика: Максимум 11 файлов. Справочники ≤100 строк, протоколы ≤150, реестры ≤200 + чистка на Close. Кросс-системное → memory/. Системное → <repo>/CLAUDE.md.

5.3. Capture-to-Pack: фиксация знаний

На каждом рубеже (подзадача завершена, паттерн обнаружен, решение принято) спроси: есть ли знание для записи? Есть ли зерно для поста?

Тип знания	Куда	Когда	Кто пишет
Правило для всех репо (1-3 строки)	`~/IWE/CLAUDE.md`	Сразу	Claude
Правило для одного репо	`<repo>/CLAUDE.md`	Сразу	Claude
Доменное (архитектура, паттерны)	Соответствующий Pack	При Close	R2 Экстрактор → Pack
Различение, метод, FM, WP	Соответствующий Pack	При Close	R2 Экстрактор → Pack
Реализационное (протоколы, процессы, конфиги)	DS docs/, PROCESSES.md, protocol-*.md	Сразу/Close	Claude / R2
Зерно для поста	`DS-strategy/drafts/draft-list.md` + `drafts/`	При Close	Claude
Крупный урок	`memory/<topic>.md`	Сразу	Claude

Двойной routing KE (HD #29): Pack-знание ≠ Реализационное решение. Экстрактор (R2) при Close предлагает записать знания в два места: доменное → Pack, реализационное → DS docs/. Один pipeline, два выхода.

Формат анонса: «Capture: [что] → [куда]»

5.4. CLAUDE.md: как устроен и как настраивать

Система использует два уровня CLAUDE.md:

Уровень	Файл	Область действия	Кто обновляет
Корневой	`~/IWE/CLAUDE.md`	Все репо в workspace	Platform (update.sh) + ты (уроки)
Репозиторный	`<repo>/CLAUDE.md`	Только этот репо	Ты (правила конкретного репо)

Когда что использовать:

Правило применимо ко всем проектам → корневой CLAUDE.md
Правило специфично для одного репо → <repo>/CLAUDE.md
Пример: «Всегда pull before commit в DS-strategy» → корневой. «Формат коммитов в DS-aist-bot: feat/fix/chore» → репозиторный.

Когда ты создаёшь новый DS- репо*, добавь в него CLAUDE.md с:

Тип репо (downstream/instrument)
Связанные Pack (откуда знания)
Специфичные правила (формат коммитов, тесты, деплой)

5.5. Стратег: автоматическое планирование

Стратег — роль R1, исполняемая Claude Code по расписанию (launchd на macOS, cron на Linux) или по триггеру:

Сценарий	Когда	Что делает	Продукт
Day Open	Утро (триггер «открывай день»)	7 шагов: вчера → план → саморазвитие → помидорки → IWE за ночь → мир → запись	DayPlan
Day Close	Вечер (триггер «закрываю день»)	Итоги → что узнал → похвала → задел на завтра	Обновлённый DayPlan
Session-Prep	Пн утро (авто)	Анализ прошлой недели + MAPSTRATEGIC	Черновик WeekPlan
Strategy-Session	После session-prep	Интерактивное обсуждение плана	Утверждённый WeekPlan
Week-Review	Вс вечер (авто)	Метрики WakaTime, достижения, уроки	WeekReport
Note-Review	По необходимости	Обработка fleeting notes и captures	Маршрутизация в Pack/inbox
Add-WP	При новой задаче	Добавление РП в план (4 места)	Обновлённый WeekPlan + WP-файл

DS-strategy — стратегический хаб:

Папка	Что содержит
`current/`	Текущий WeekPlan, DayPlan
`inbox/WP-*.md`	Контексты задач (живая история работы)
`docs/Strategy.md`	Твоя общая стратегия
`docs/Dissatisfactions.md`	Неудовлетворённости (триггеры изменений)
`drafts/`	Личные черновики + draft-list.md (индекс, ≤7 дней TTL)
`archive/`	Завершённые планы
`exocortex/`	Backup memory/ + CLAUDE.md

Паттерн Hub-and-Spoke: DS-strategy (хаб) координирует, WORKPLAN.md в каждом репо (споки).

Настройка дня стратегирования

По умолчанию сессия стратегирования запускается в понедельник (strategy_day: monday в memory/day-rhythm-config.yaml). Ты можешь выбрать любой день недели:

# memory/day-rhythm-config.yaml
day_open:
  strategy_day: saturday   # monday..sunday — твой день стратегирования

В этот день:

strategist.sh запускает session-prep вместо day-plan
scheduler.sh запускает week-review (обзор недели)
Day Open не создаёт DayPlan — план дня уже встроен в WeekPlan (секция «План на [день]»)
Все три компонента читают strategy_day из конфига — хардкод не используется

Activation Gate: как pending-РП попадают в план

Каждый РП в статусе ⏳ pending имеет условие активации — ответ на вопрос «при каком условии этот РП попадёт в WeekPlan?»

Тип условия	Пример	Как проверяется
date	`W15`, `после 1 апр`	Стратег при Session-Prep: `date ≤ текущая неделя?`
dep	`dep: WP-73`	При Close зависимости: `WP-73 = done → alert`
on-demand	`когда будет бюджет`	Только вручную на стратегировании

Dormant Review: on-demand старше 3 недель → автоматически в повестку стратегирования. Вопрос: «Архивировать (📦) или назначить конкретное условие?» Это предотвращает накопление «мёртвых» РП.

Условия хранятся в колонке «Активация» в WP-REGISTRY.

Где изучить:

roles/strategist/prompts/ — 9 промптов для каждого сценария

5.6. Творческий конвейер: от заметки до поста

Формализация: PD.FORM.005 Creative Pipeline

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

4 стадии артефакта

Заметка (≤7д) → Черновик (≤7д) → Заготовка (≤14д) → Пост
fleeting-notes   DS-strategy/      Knowledge Index      Published
inbox/           drafts/            status: draft         status: published

Стадия	Где хранится	TTL	Видимость
Заметка	`DS-strategy/inbox/fleeting-notes.md`	≤7 дней	Личная
Черновик	`DS-strategy/drafts/*.md`	≤7 дней	Личная
Заготовка	`DS-Knowledge-Index/docs/` (status: draft)	≤14 дней	Публичная
Пост	`DS-Knowledge-Index/docs/` (status: published)	—	Публичная

7 направлений заметки

Note-Review классифицирует каждую заметку в одно направление. Черновик — только рекомендация, создание после согласования.

#	Категория	Критерий	Куда
1	НЭП	Неудовлетворённость, дискомфорт, «хочу изменить»	`Dissatisfactions.md`
2	Задача	Конкретное действие, «завтра сделать»	WeekPlan / DayPlan
3	Знание	Паттерн, различение, метод, правило, инсайт	`captures.md` → Pack
4	Черновик	Зерно для поста, рефлексия с концептами	Рекомендация → `drafts/` (после согласования)
5	Идея 🔄	Размышление, нет конкретного действия	Остаётся в заметках (вернуться на стратегировании)
6	Личные данные	Контакт, аккаунт, токен, реквизиты	`personal/*.md`
7	Шум	Тест, дубль, уже сделано, ссылка без контекста	~~зачёркнуто~~ → архив

Два ключевых различения

Черновик ≠ Заготовка. Черновик — личный текст (DS-strategy/drafts/), может быть сырым. Заготовка — публичный текст (DS-Knowledge-Index/, status: draft), должен быть связным. Тест: можно показать другому? Нет → черновик.
Заготовка ≠ Пост. Заготовка опубликована, но не продвигается. Пост — активно продвигается. Тест: готов привлекать внимание? Нет → заготовка.

Anti-accumulation: TTL и guards

Каждый артефакт ОБЯЗАН выйти в одно из направлений за TTL. При накоплении черновиков срабатывают guards:

Порог	Реакция	Что делать
≤5 черновиков	Норма	Работай по приоритетам
6-10 черновиков	Предупреждение	Приоритизируй или закрой лишние до ≤5
>10 черновиков	Блокировка	Нельзя добавлять новые. Сначала продвинь или закрой до ≤5

Guards проверяются при каждом Note-Review и при создании нового черновика.

Замкнутый цикл: Pack ↔ Контент

Конвейер работает не линейно, а как замкнутый цикл:

Обратная связь от постов — реакции читателей → новые заметки → новый цикл.
Pack → Контент — когда Экстрактор добавляет ≥3 сущностей по одной теме в Pack → автоматически предлагается черновик для поста (популяризация формализованного знания).

Тест здоровья конвейера (на каждом стратегировании)

Входящие ≈ исходящие? (создано N заметок → сортировано ~N)
TTL не нарушены? (заметки >7д? черновики >7д? заготовки >14д?)
Guard не нарушен? (черновиков ≤5?)
Pack → пост? (были captures → предложен черновик?)

Если ≥2 ответа «нет» → конвейер застопорился → вопрос на стратегировании.

IWE-материализация

Компонент	Файл
Индекс черновиков	`DS-strategy/drafts/draft-list.md`
Черновики	`DS-strategy/drafts/*.md`
Протокол сортировки	`roles/strategist/prompts/note-review.md` (категория #4)
Протокол Close	`memory/protocol-close.md` (шаг 9: draft-list)

6. Знания: Pack и экстракция

6.1. Что такое Pack

Pack — формализованный паспорт предметной области. Единственный source-of-truth для доменного знания.

Содержит:

Bounded Context (границы области)
Различения (что нельзя путать)
Онтология (сущности и связи)
Роли (кто действует)
Методы (как действовать)
Рабочие продукты (результаты методов)
Failure Modes (типичные ошибки)
SOTA-аннотации (актуальность знания)

Живой пример: PACK-digital-platform (40+ сущностей)

6.2. Создание Pack (11 стадий SPF)

SPF определяет процесс создания Pack:

#	Стадия	Суть
01	Выбор домена	Определить и ограничить область
02	Bounded Context	Установить семантические границы
03	Работа с различениями	Какие пары нельзя путать
04	Идентификация сущностей	Роли, объекты, ограничения
05	Приём информации	Ввод материалов для анализа
06	Анализ и формализация	Формализация через различения
07	Извлечение методов и РП	Методы → рабочие продукты
08	Извлечение failure modes	Типичные ошибки интерпретации
09	SOTA-аннотации	current / hypothesis / deprecated
10	Обслуживание карты	Граф связей между сущностями
11	Цикл ревью и эволюции	Протокол непрерывного обновления

Где изучить:

SPF/process/ — все 11 стадий
SPF/pack-template/ — шаблон структуры

6.3. Структура Pack

PACK-{область}/
├── 00-pack-manifest.md           # Заголовок: имя, версия, BC
├── 01-domain-contract/
│   ├── 01A-bounded-context.md    # Семантическая рамка
│   ├── 01B-distinctions.md       # Ключевые различения
│   └── 01C-ontology.md           # Сущности и связи
├── 02-domain-entities/
│   ├── 02A-roles.md              # Роли в области
│   ├── 02B-objects-of-attention.md
│   ├── 02C-methods-index.md      # Индекс методов
│   └── 02D-tools-index.md        # Индекс инструментов
├── 03-methods/                    # Карточки методов
├── 04-work-products/              # Карточки рабочих продуктов
├── 05-failure-modes/              # Типичные ошибки
├── 06-sota/                       # SOTA-аннотации
└── 07-map/                        # Навигационная карта

6.4. Экстрактор знаний (R2)

Роль: Трансформирует информацию в формализованные сущности Pack.

Пайплайн: классифицировать → маршрутизировать → формализовать → валидировать

Сценарий	Триггер	Когда ты видишь результат
Session-Close	Протокол Close	При закрытии сессии Claude предложит новые Pack-сущности
On-Demand	Твоя команда	Немедленно в Claude Code
Bulk-Extraction	Обработка документов	После анализа — Extraction Report
Inbox-Check	Расписание	В DayPlan (если есть новое)

Ключевое правило: Экстрактор всегда предлагает — никогда не пишет без одобрения.

Как это работает для тебя:

Работаешь в Claude Code → по ходу сессии появляются captures
При Close → Claude активирует роль Экстрактора (R2) и показывает Extraction Report
Ты одобряешь → сущности записываются в Pack

Где изучить:

Протокол Close (§ 5.1) — когда активируется Экстрактор
DP.ROLE.001 R2 — полное описание роли

6.5. MCP-серверы знаний

Claude Code подключается к 3 MCP-серверам платформы (через https://claude.ai/settings/connectors). Одна база знаний — бот и экзокортекс работают с одними и теми же серверами.

knowledge-mcp — поиск по базе знаний

Hybrid search (vector + keyword) по всем Pack-репозиториям и документации. ~5400 документов.

Инструмент	Что делает	Пример
`search`	Семантический + keyword поиск	`search("тиры обслуживания", source_type="pack")` → DP.ARCH.002
`get_document`	Конкретный документ по имени	`get_document("DP.ROLE.001-platform-roles.md")`
`list_sources`	Список всех источников	Показывает количество документов по категориям

Типы источников: pack (доменные знания), guides (руководства), ds (процессы).

Поиск по руководствам: knowledge-mcp search("запрос", source_type="guides"). Отдельный guides-сервер не нужен — knowledge-mcp объединяет все источники.

ddt — цифровой двойник ученика

Метамодель данных ученика: цели, самооценка, контекст, прогресс.

Инструмент	Что делает	Пример
`describe_by_path`	Структура метамодели	`describe_by_path("/")` → 4 категории IND.1-4
`read_digital_twin`	Чтение данных	`read_digital_twin("1_declarative/1_2_goals")` → цели ученика
`write_digital_twin`	Запись в IND.1	`write_digital_twin("1_declarative/...", data)`

IND.1 (Declarative) — единственная записываемая категория. IND.2 (Collected), IND.3 (Derived), IND.4 (Generated) — только чтение.

Когда какой MCP использовать

Ситуация	MCP-инструмент
Доменный вопрос, паттерн, архитектура	`knowledge-mcp search(query, source_type="pack")`
Конкретный документ по коду (DP.ROLE.001)	`knowledge-mcp get_document("filename")`
Обучение, методология, руководства	`knowledge-mcp search(query, source_type="guides")`
Цели ученика, самооценка	`ddt read_digital_twin("path")`
Перед записью в Pack — проверка дубликатов	`knowledge-mcp search` + `get_document`

6.6. Онтология: граф знаний

Онтология — граф понятий и связей. Каждый уровень имеет свою:

Уровень	Где	Что
SPF-level	`SPF/ontology.md`	Универсальные понятия фреймворка
Pack-level	`PACK-{}/01-domain-contract/01C-ontology.md`	Сущности конкретного Pack
Экосистемная	`DS-ecosystem-development/ontology.md`	31 понятие: платформа + экосистема
Личная	`DS-strategy/ontology.md`	Личное развитие + кросс-связи

Принцип: SPF наследует FPF → Pack расширяет SPF → Downstream ссылается на Pack.

Где изучить:

SPF/ontology.md — SPF-level
SPF/docs/conceptual-model.md — концептуальная карта

7. Роли и ИИ-агенты

7.1. Ролецентричный подход (DP.D.033)

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

Понятие	Определение
Роль	Функция: ЧТО делать (обязательства, РП, методы)
Исполнитель (holder)	Система: КТО делает (Claude, bash, человек)
Агент	Исполнитель с автономностью (Grade 2+)
Инструмент	Исполнитель без автономности (Grade 0-1)

Ключевые принципы:

Роль ≠ Система. Одно имя может обозначать и роль, и систему — это разные ракурсы
Один исполнитель — много ролей. Claude играет роли Стратега, Экстрактора, Кодера
Одна роль — много исполнителей. Роль Синхронизатора: bash (механика) + Claude (аудит)

Нотация: Holder#Role:Context@Window (FPF A.2)

7.2. Каталог агентов

У тебя (L4 Personal IWE)

Эти агенты работают в твоём Claude Code, на твоей машине:

Агент	Роль	Что делает	Когда видишь результат
Стратег (R1)	Планирование	Day Open/Close, WeekPlan, DayPlan, стратегические сессии	Утро (launchd → Telegram), сессия (Claude Code)
Экстрактор (R2)	Формализация знаний	Captures → Pack-сущности (двойной routing: Pack + DS)	Close сессии в Claude Code

На платформе (L2 Platform)

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

Агент	Роль	Что делает	Как ты видишь результат
Синхронизатор (R8)	Координация	Fleeting-notes sync, уведомления	Telegram-уведомления
Шаблонизатор (R9)	Обновление шаблона	Drift detection, validation	При `update.sh`
Статистик (R10)	Аналитика	DAU/WAU/MAU, retention	`/analytics` в боте
Наладчик (R11)	Исправление ошибок	Auto-fix, restart, escalate	GitHub Issues, TG-уведомления

Для T4 пользователя: R1 (Стратег) и R2 (Экстрактор) — основные. Платформенные агенты (R8-R11) работают в фоне.

7.3. Схема взаимодействия агентов

Расписание / Действие пользователя
    ↓
R8 Синхронизатор (диспетчер)
    ├─→ R1 Стратег (планы, обзоры)
    │   └─→ DS-strategy/current/Plan, Day, Report
    ├─→ R2 Экстрактор (знания)
    │   └─→ Pack-сущности, DS-strategy/inbox/
    ├─→ R9 Шаблонизатор (обновления)
    │   └─→ FMT-exocortex-template/
    ├─→ R11 Наладчик (ошибки бота)
    │   └─→ GitHub PR, Issues
    ├─→ R10 Статистик (аналитика)
    │   └─→ TG-отчёт, /analytics
    └─→ Уведомления в Telegram

Где изучить:

Каталог ролей (21 роль R1-R21): DP.ROLE.001
Архитектурное обоснование: DP.D.033

7.4. Контракт роли (для разработчиков)

Каждая роль в roles/ следует формальному контракту — спецификации того, что директория роли должна содержать. Контракт обеспечивает автодискавери: setup.sh и update.sh автоматически находят и обрабатывают роли без hardcoded списков.

Минимальный набор файлов:

role.yaml — машиночитаемый манифест (имя, тип, режим установки)
README.md — человекочитаемое описание
install.sh — точка входа установки

Подробности и схема role.yaml: roles/ROLE-CONTRACT.md

8. Качество и архитектура решений

8.1. ArchGate (ЭМОГССБ)

Блокирующее правило: Любое архитектурное решение оценивается по 7 характеристикам. Порог ≥8.

Характеристика	Вопрос
Эволюционируемость	Что сломается при изменении?
Масштабируемость	Что будет при 10x?
Обучаемость	Сколько читать, чтобы начать? Экзоскелет или протез?
Генеративность	Создаёт ли платформу для нового?
Скорость	Какая задержка? (бот <3 сек, CLI <1 сек)
Современность	Как решают лучшие? Проверь SOTA.
Безопасность	Какие угрозы? PII, секреты, injection surface?

Формат: Решение → принципы (шаг 1) → таблица оценки (шаг 2) → что слабо → как усилить (шаг 3).

Coordination cost check (при мультиагентных решениях): координационные издержки < выигрыш от параллелизма? Три условия: (1) context isolation, (2) parallelism gain, (3) tool specialization. Все три НЕ выполнены → single-agent.

8.2. SOTA-практики

Приоритетная тройка (проверяй ВСЕГДА при архитектурных решениях):

#	Практика	Суть
1	Context Engineering	Write/Select/Compress/Isolate — что попадает в контекст агента
2	DDD Strategic	BC = Pack scope, UL = ontology, Context Map = typed `related:`
3	Coupling Model	Связи по 3 измерениям: knowledge, distance, volatility

Полный список: платформенные + Pack-архитектурные практики.

Где изучить:

memory/sota-reference.md — все 18 с описаниями
CLAUDE.md § 5 — чеклист современности

8.3. Чеклисты качества

Чеклист	Когда
Перед ответом	Хотя бы 1 файл загружен, тип репо известен
Перед модификацией	CLAUDE.md прочитан, source-of-truth не ломается
При записи процесса	Pack + PROCESSES.md + CLAUDE.md (все три)
Перед предложением fix	ArchGate применён, корень проблемы исправлен

Где изучить:

memory/checklists.md — все чеклисты

8.4. IntegrationGate

Перед добавлением нового инструмента, агента или системы — СТОП. Ответь на 5 вопросов:

Тип: инструмент (Grade 0-1) или агент (Grade 2+)?
Контур: L2 Platform / L3 Template / L4 Personal?
Роли: какие роли исполняет?
Продукты: что создаёт и кому?
Процессы: какие описания методов затронуты?

Нет ответов → НЕ начинать. Определи уровень → опиши → потом реализуй.

8.5. Безопасность в IWE

IWE работает с персональными данными: стратегия, планы, цели, цифровой двойник. Безопасность — архитектурная характеристика (ЭМОГССБ), а не надстройка.

Модель безопасности: 3 зоны

┌────────────────────────────────────────────────────┐
│  Зона 1: ЛОКАЛЬНАЯ (твой компьютер)                │
│  CLAUDE.md, memory/, DS-strategy/ (local copy)     │
│  → Защита: OS-уровень (FileVault, пароль)          │
└───────────────────────┬────────────────────────────┘
                        │ git push (ты контролируешь)
┌───────────────────────▼────────────────────────────┐
│  Зона 2: ПРИВАТНЫЕ РЕПО (твой GitHub)              │
│  DS-strategy/, PACK-*/, DS-*/ (private repos)      │
│  → Защита: GitHub access control + SSH/OAuth       │
└───────────────────────┬────────────────────────────┘
                        │ API calls (авторизованные)
┌───────────────────────▼────────────────────────────┐
│  Зона 3: ПЛАТФОРМА (сервисы IWE)                   │
│  Бот, Claude API, Digital Twin                     │
│  → Защита: per-user OAuth, токены, изоляция        │
└────────────────────────────────────────────────────┘

Принципы безопасности IWE

Принцип	Что значит	Как реализовано
Секреты вне git	API-ключи, токены не попадают в репозитории	`~/.config/`, `~/.wakatime/`, env vars
Per-user blast radius	Компрометация одного пользователя не затрагивает других	Per-user OAuth 2.0, изолированные данные
Персональные данные изолированы	Твои планы и стратегия — только у тебя	Приватные репо, локальная memory/
Platform-space ≠ User-space	Методология (общая) отделена от данных (личных)	Standard vs Personal зоны
CLI permission whitelist	Claude Code исполняет только разрешённые команды	`.claude/settings.local.json` с явным allowlist

Что знает Claude (и чего не знает)

Claude видит	Claude НЕ видит
CLAUDE.md, memory/*.md (твои инструкции)	Пароли, SSH-ключи, API-токены
Файлы в открытых сессиях (когда ты работаешь)	Файлы других пользователей
Контекст текущего разговора	Историю прошлых разговоров (сброс при новой сессии)
Содержимое репо, к которым ты дал доступ	Репо за пределами рабочей директории

Anthropic API: Anthropic не использует данные из API для обучения моделей. Данные обрабатываются, но не сохраняются для тренировки.

Что делать пользователю

DS-strategy/ — приватный. Убедитесь при создании: gh repo create DS-strategy --private
Не коммитьте .env файлы. Если работаете с API-ключами — добавьте в .gitignore
Используйте SSH для git. gh auth login → SSH → надёжнее паролей
FileVault (macOS) / LUKS (Linux). Шифрование диска защищает локальную зону
Ротация токенов. Если скомпрометировали — gh auth refresh, смена ключей в ~/.config/

Безопасность ИИ-систем (AI-специфичные угрозы)

IWE использует LLM (Claude) — это создаёт специфический класс угроз:

Угроза	Описание	Как IWE защищает
Prompt injection	Вредоносная инструкция в данных	CLAUDE.md — явный allowlist, ArchGate проверяет injection surface
Context leakage	Данные из одной сессии попадают в другую	Каждая сессия Claude Code — новый контекст. Memory — только то, что ты записал
Чрезмерное доверие к ИИ	ИИ предлагает, но может ошибаться	Протоколы требуют подтверждения: WP Gate, ArchGate, Capture

Где изучить:

CLAUDE.md § 5 — ЭМОГССБ (включая характеристику Безопасность)
DP.ARCH.001 § 4.7 — архитектурная характеристика Безопасность

9. Платформа: бот и тиры

9.1. 4-осевая модель тиров

Ось T (учащийся):

Тир	Название	Вход	ИИ-роль	Рабочее пространство
T0	Без Ory	/start в боте (telegram_id) + trial 30 дней	Справочник	Только бот (trial: все функции)
T1	Старт	Регистрация в Ory (UUID) + trial 30 дней	Ассистент	Только бот (trial: все функции)
T2	Изучение	Подписка БР (system-school.ru)	Эксперт	Бот + контент
T3	Персонализация	Digital Twin	Наставник	+ Digital Twin
T4	Созидание (IWE)	setup.sh	Со-мыслитель	+ Git + Claude Code + Стратег

T0/T1 — актуальная номенклатура. Старые названия (T1_NEW, T1_START) устарели и не используются. T5-T9 зарезервированы.

Ортогональные оси (назначаются):

Ось	Тиры	Что даёт	Требует
TM (наставник)	TM1-TM3	Панель проверки ДЗ, группы	T2+
TA (администратор)	TA1-TA4	Управление потоками, финансами, доступами	T1+
TD (разработчик)	TD1	Исходный код, деплой, управление шаблоном	T2+

Каждый тир T — конфигурация 5 измерений: знания, данные, ИИ-роль, действия, рабочее пространство. Оси TM/TA/TD ортогональны: один человек = T + TM? + TA? + TD?. Владелец платформы = T4 + TA4 + TD1.

9.2. Маппинг тиров на контуры

Тир	Контуры	Что доступно
T0-T3	L2 (Platform)	Сервисы платформы через бот
T4	L3 → L4	Шаблон инстанцируется в Personal IWE
TD1	L2 + L3	Разработка платформы и шаблона

9.3. Бот (@aist_me_bot)

Telegram-бот — основная точка входа для T1-T3. Для T4+ бот остаётся полезным для быстрых действий.

Что бот умеет:

Возможность	Команда / действие	Тир
Поиск по базе знаний	Любой вопрос	T1+
Марафоны и программы	`/programs`	T2+
Заметки (fleeting notes)	`.текст` или `.` + reply	T2+
Digital Twin	`/twin`	T3+
Персональные ответы	Авто (из Twin)	T3+
Расписание занятий	`/schedule`	T2+

Связь с экзокортексом: Бот синхронизирует fleeting notes → DS-strategy/inbox/fleeting-notes.md. Стратег видит их при Note-Review.

Где изучить:

DP.ARCH.002 — тиры обслуживания

9.4. Процессы и сценарии IWE

Различение: Процесс / Сервис / Сценарий

Термин	Что	Аналогия
Процесс	Логика внутри одной системы	Комната
Сервис	Точка входа в процесс	Дверь
Сценарий	Межсистемный путь (владелец меняется)	Путь через здания

Ключевые сценарии

Пользовательские:

1.1: Рабочая сессия (Open → Work → Close)
1.2: Недельная стратегическая сессия (Week-Review → Session-Prep → Strategy-Session)
1.3: Ежедневный цикл (DayPlan → фокус → DayClose)

Платформенные:

2.1: Day-Close (сбор коммитов, обновление планов, backup)
2.2: Backup экзокортекса (memory/ → DS-strategy/)
2.3: Ontology sync (Pack → мастер)
2.4: File sync (GitHub → local)
2.5: Template sync (автор → FMT-exocortex-template)
2.6: Pack projection (Pack → Downstream)

Где изучить:

CLAUDE.md § 3 — различение и размещение
DS-ecosystem-development/PROCESSES.md — все сценарии

10. Рост и развитие

10.1. Создание своего Pack

Когда создавать:

Регулярно работаешь в одной области
Важно не терять знания между сессиями
Хочешь, чтобы Claude знал термины и паттерны твоей области

# 1. Клонируй SPF (read-only reference)
gh repo clone TserenTserenov/SPF ~/IWE/SPF

# 2. Создай Pack из шаблона
cp -r ~/IWE/SPF/pack-template ~/IWE/PACK-my-domain
cd ~/IWE/PACK-my-domain
git init && git add -A && git commit -m "Initial Pack: my-domain"
gh repo create PACK-my-domain --private --source=. --push

Затем откройте Claude Code — он проведёт через 11 стадий SPF.

10.2. Новые агенты и инструменты

Перед добавлением — IntegrationGate (§ 8.4). После определения:

Компонент	Тип	Где описание	Где реализация
Экстрактор	Агент (Grade 2)	DP.ROLE.001 R2	DS-ai-systems/extractor/
Синхронизатор	Агент + Инструмент	DP.ROLE.001 R8	DS-ai-systems/synchronizer/

Принцип: Минимальная сложность на старте. Стратег один достаточен для первых месяцев. Экстрактор — когда Pack достигнет 10+ сущностей. Синхронизатор — когда 3+ репозитория.

10.3. MAPSTRATEGIC.md: стратегия каждой системы

Когда создаёшь новый репо, добавь MAPSTRATEGIC.md:

# MAPSTRATEGIC: {Название системы}

## Текущая фаза
{Описание: какие задачи решаются сейчас}

## Следующая фаза
{Куда двигается система}

## Горизонт
{Долгосрочное видение}

Стратег читает все MAPSTRATEGIC при Session-Prep и агрегирует в Strategy.md.

10.4. Как развивать IWE самостоятельно

Принцип: Начни с минимума, усложняй по мере роста.

День 1:       setup.sh → FMT (fork) + DS-strategy          ← старт
Неделя 1:     Ежедневная работа с Claude Code + Стратег     ← привычка
Неделя 2-4:   Первый PACK-{область}                        ← формализация знаний
Месяц 2-3:    DS-{проекты} (код, контент)                  ← созидание
По мере роста: Экстрактор, Синхронизатор, свои Format      ← масштабирование

Рекомендации:

Не клонируй все репозитории сразу — начни с FMT + DS-strategy
Не создавай Pack пока не определил область и не накопил captures
Не добавляй агентов пока не справляешься без них (IntegrationGate, § 8.4)
Клонируй SPF только когда готов создать Pack (read-only reference)

11. Быстрый справочник

Архитектура FAQ: Практические вопросы («как сделать») — здесь. Доменные вопросы («что такое», «зачем») — DP.IWE.002 §11 (source-of-truth для бота).

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

Вопрос	Ответ	Где
Куда записать знание?	Pack (доменное), CLAUDE.md (правило), memory/ (урок)	CLAUDE.md § 2
Можно ли пропустить WP Gate?	Только если ≤15 мин, исследование, или экстренный баг-фикс	CLAUDE.md § 2
Как предложить решение?	Сначала ArchGate (7 характеристик, порог ≥8)	CLAUDE.md § 5
Как закончить сессию?	Close Protocol (15 шагов)	§ 5.1c
Почему pending-РП не попадает в план?	Проверь условие активации в WP-REGISTRY (date/dep/on-demand)	§ 5.5
Что делать со старыми pending-РП?	Dormant Review на стратегировании: архивировать или назначить условие	§ 5.5
Как сменить день стратегирования?	`strategy_day: saturday` в `memory/day-rhythm-config.yaml`	§ 5.5
Почему в Пн нет DayPlan?	В strategy_day план дня встроен в WeekPlan	§ 5.1, 5.5

Репозитории и структура

Вопрос	Ответ	Где
Какой тип у этого репо?	Смотри `REPO-TYPE.md` в репо	`<repo>/REPO-TYPE.md`
Это система или эпистема?	Различение #1	hard-distinctions.md
Как создать DS-проект?	`gh repo create DS-my-project --private` + CLAUDE.md	§ 4.4
Что такое S2R?	Format для проектных репо (3×3 матрица)	§ 4.3
Как настроить CLAUDE.md для нового репо?	Тип + связанные Pack + специфичные правила	§ 5.4

Знания и Pack

Вопрос	Ответ	Где
Какой SOTA применим?	Приоритетная тройка	sota-reference.md
Где доменное знание?	Pack-репозитории или Knowledge MCP	§ 6.5
Как создать Pack?	11 стадий SPF	§ 6.2
Что значит Pack entity ID?	`КОНТЕКСТ.ТИП.NNN`	§ 4.5

Навигация и инструменты

Вопрос	Ответ	Где
В каком контуре я?	L4 (Personal IWE), если T4+. L2 (Platform), если T1-T3	§ 2.1
Куда добавить инструмент?	IntegrationGate: определи контур	§ 8.4
Как обновить шаблон?	`bash update.sh`	§ 2.5
Где моя стратегия?	`DS-strategy/docs/Strategy.md`	§ 5.5
Как настроить WakaTime?	`/setup-wakatime` в Claude Code	§ 2.6
Где мой Digital Twin?	Бот → `/twin`	§ 2.6
Как попасть в клуб?	systemsworld.club	§ 2.6

Типичные проблемы и решения

«Claude теряет контекст между сессиями»

Что происходит. Ты подробно описываешь задачу в чате — Claude понимает, работает. Новая сессия — как будто ничего не было.

Почему. Claude Code не «помнит» чат. Между сессиями сохраняется только то, что записано в файлы: MEMORY.md, CLAUDE.md, memory/*.md, WP-файлы в inbox/. Если информация осталась только в чате — она исчезла.

Что делать.

WP-файл = постоянная память задачи. При создании РП через WP Gate Claude записывает контекст в DS-strategy/inbox/WP-{N}-slug.md. В следующей сессии он читает этот файл и восстанавливает контекст.
Если WP-файл не создался — вероятно, задача оценена как ≤2h и ≤1 сессии. Скажи: «Создай контекстный файл для этой задачи». Или добавь в <repo>/CLAUDE.md правило: «Всегда создавать WP-файл при добавлении РП».
Массовый приём задач (из Obsidian, заметок, backlog): создай один РП «Триаж задач из [источник]». Результат = набор WP-файлов в inbox/ с полным контекстом каждой задачи. Потом на стратегической сессии отсортируешь их по неудовлетворённостям.

Ключевое: Claude не теряет контекст — он его не записывает, если не сказано куда. Протокол Close (§ 5.1) + WP-файлы решают эту задачу.

«Pack не используется при работе»

Что происходит. Ты положил знания в Pack-репозиторий. Но при работе Claude их не видит и не учитывает.

Почему. Claude автоматически видит только 3 вещи: MEMORY.md, CLAUDE.md, memory/*.md. Pack-репозитории — это файлы на диске, которые Claude не читает без явной команды.

Три способа подключить Pack (от простого к мощному):

Способ	Когда	Что сделать
1. Прямая ссылка	Pack <50 файлов	В `memory/navigation.md` добавь путь к Pack. При постановке задачи скажи: «Контекст: см. Pack-X/entity-Y.md»
2. Индекс в CLAUDE.md	Pack 50-100 файлов	Добавь список ключевых сущностей Pack в `<repo>/CLAUDE.md` или `memory/navigation.md`
3. MCP-сервер	Pack >100 файлов	Настрой knowledge-mcp для своих Pack (DP.IWE.002 § 7.1). Claude сможет искать по всей базе

Практический минимум: Добавь в memory/navigation.md секцию со ссылками на свои Pack:

## Мои Pack-репозитории
| Pack | Путь | Тема |
|------|------|------|
| PACK-my-domain | ~/IWE/PACK-my-domain/ | Ключевые сущности моей области |

«Не понимаю, что куда записывается»

Правило одной строки: если Claude должен видеть это каждую сессию — MEMORY.md или CLAUDE.md. Всё остальное — файлы, которые Claude читает по запросу.

Что	Куда	Почему именно туда
Список задач (РП) недели	`MEMORY.md`	Claude видит каждую сессию, проверяет через WP Gate
Правила работы для всех проектов	`~/IWE/CLAUDE.md`	Claude видит каждую сессию
Правила для одного проекта	`<repo>/CLAUDE.md`	Claude видит при работе в этом репо
Справочник (термины, чеклисты)	`memory/*.md`	Claude читает по триггеру (§ 5.2)
Подробности каждой задачи	`DS-strategy/inbox/WP-*.md`	Claude читает при открытии задачи (Ритуал, шаг 3)
Доменные знания	Pack-репозитории	Claude читает при явном запросе или через MCP
Стратегия, неудовлетворённости	`DS-strategy/docs/`	Стратег (R1) использует при планировании

Где физически лежит memory/: ~/.claude/projects/{workspace-hash}/memory/. Это скрытая папка Claude Code. Бэкап → DS-strategy/exocortex/.

«Не создаются WP автоматически»

WP Gate обязан срабатывать на каждое задание. Если не срабатывает, проверь:

CLAUDE.md на месте? Файл ~/IWE/CLAUDE.md должен существовать и содержать секцию «Стадии сессии — ОРЗ».
MEMORY.md на месте? ~/.claude/projects/{workspace-hash}/memory/MEMORY.md должен содержать таблицу «РП текущей недели».
protocol-open.md на месте? memory/protocol-open.md рядом с MEMORY.md.
Задача >15 мин? Задачи ≤15 мин — исключение из WP Gate.
Модель? Opus надёжнее соблюдает протоколы. Sonnet может пропускать шаги. Для первых сессий рекомендуется Opus. Haiku — только для trivial-задач (переименование, форматирование, поиск) и cron-агентов.

Если всё на месте, но WP Gate всё равно не срабатывает — проверь, что в CLAUDE.md есть строка: «WP Gate: При ЛЮБОМ задании → протокол Открытия».

«Что можно менять в CLAUDE.md, а что нельзя?»

Зона	Можно менять?	Примеры
Свои правила	Да, свободно	«Всегда пиши коммиты на русском», «Используй pytest»
MEMORY.md	Да, это твои данные	Задачи, статусы, заметки
*memory/.md**	Осторожно	Добавлять уроки можно. Менять протоколы — понимая последствия
Корневой CLAUDE.md (standard)	С оговоркой	update.sh перезапишет стандартную часть. Свои дополнения — в конец секций

Безопасный паттерн: Добавляй свои правила в <repo>/CLAUDE.md (не затрагивается update.sh).

«Зачем такая структура папок?»

DS-strategy/
├── docs/        ← Долгоживущее (стратегия, неудовлетворённости) — меняется редко
├── current/     ← Текущее (план недели/дня) — меняется ежедневно
├── inbox/       ← Входящее (контексты задач, заметки) — обрабатывается и уходит
├── drafts/      ← Черновики (посты, идеи) — TTL ≤7 дней
├── archive/     ← Закрытое (завершённые планы) — для ретроспективы
└── exocortex/   ← Бэкап memory/ — страховка

Паттерн Inbox → Processing → Archive: входящее обрабатывается → результат в docs/ или Pack → исходник архивируется. Ничего не накапливается бесконтрольно.

Менять можно, но сохраняй разделение «активное / входящее / закрытое» — без него inbox будет расти бесконечно.

«Какие возможности у стратега?»

Основные сценарии:

#	Сценарий	Запуск	Что делает	Результат
1	Day Open	Утро (триггер)	7 шагов: вчера → план → саморазвитие → помидорки → IWE → мир → запись	DayPlan
2	Day Close	Вечер (триггер)	Итоги → что узнал → похвала → задел на завтра	Обновлённый DayPlan
3	session-prep	Пн утро (авто)	Анализ прошлой недели + MAPSTRATEGIC из всех репо	Черновик WeekPlan
3b	strategy-session	Вручную	Интерактивный разбор неудовлетворённостей → приоритеты	Утверждённый WeekPlan
4	week-review	Вс вечер (авто)	Метрики WakaTime + что сделано + уроки	WeekReport
5	add-wp	Вручную	Добавить новую задачу в план (4 места)	Обновлённый WeekPlan + WP-файл
6	note-review	По потребности	Классифицировать заметки → Pack/inbox/archive	Маршрутизированные заметки

Стратег НЕ умеет: писать код, ходить в Pack без MCP, деплоить. Он планирует, рефлексирует и маршрутизирует.

«Как работать с IWE на двух устройствах (ноут + десктоп)?»

Что происходит. У тебя два компьютера (возможно на разных ОС). Нужно одинаковое окружение и возможность переключаться между ними.

Архитектура. IWE состоит из слоёв с разными механизмами синхронизации:

#	Слой	Механизм	Кросс-ОС
1	Репо (код, Pack, DS)	git push/pull	Да
2	Экзокортекс (CLAUDE.md, memory/)	git backup в DS-strategy → restore на втором устройстве	Да
3	Claude Code конфиг (.claude/)	Часть в git (exocortex backup), часть локальная	Да (JSON)
4	VS Code	Settings Sync (встроенный, через GitHub)	Да
5	MCP серверы	Шаблон конфига + envsubst (пути различаются между ОС)	Шаблон + platform-specific
6	Секреты (.env, API keys)	Менеджер паролей (1Password CLI / Bitwarden CLI)	Да
7	Cron/LaunchAgents	macOS: plist. Linux: systemd/cron. Setup-скрипт в репо	Разные форматы
8	Пакеты (brew, apt)	Brewfile (macOS) + аналог для Linux	Setup-скрипт

Критичное правило: Push before switch. Перед переключением на другое устройство — push all dirty repos. Проверка:

for repo in ~/IWE/*/; do
  [ -d "$repo/.git" ] && git -C "$repo" status --porcelain | grep -q . && echo "DIRTY: $repo"
done

Кросс-ОС нюансы:

Пути: Использовать ~/IWE/ (тильда кросс-платформенна), или переменную $IWE_HOME
Symlinks: memory/ → .claude/... — на каждом устройстве свой setup.sh создаёт symlinks
LaunchAgents vs systemd: Шаблоны обоих хранятся в репо, setup.sh ставит нужный
MCP пути: claude_desktop_config.json содержит абсолютные пути — использовать шаблон + envsubst или platform-specific configs
Line endings: .gitattributes с * text=auto

Bootstrap нового устройства:

git clone <all-repos> ~/IWE/
cd ~/IWE && ./setup.sh   # создаёт symlinks, ставит пакеты, настраивает cron

setup.sh определяет ОС (uname) и выполняет нужные действия. Живёт в DS-ecosystem-development или dotfiles-репо.

Где: § 2.2 (от шаблона к workspace), § 5.2 (память)

FilesExpand file tree

LEARNING-PATH.md

Latest commit

History

LEARNING-PATH.md

File metadata and controls

Путь изучения интеллектуальной рабочей среды (IWE)

1.1. Определение

1.1a. Ключевой принцип: экзоскелет, не протез

1.2. Анатомия IWE: пять архитектурных видов

Вид 1: Системы (U.System) — что имеет 4D-границы

Вид 2: Описания (U.Description) — знания, загружаемые в системы

Вид 3: Роли (U.RoleAssignment) — функции, независимые от исполнителя

Вид 4: Методы (U.MethodDescription) — как роль производит рабочий продукт

Вид 5: Рабочие продукты (U.Work) — что производится

Как виды связаны

1.3. Путь пользователя

2.1. Четыре контура системы

2.2. От шаблона к рабочему пространству

Структура репо FMT-exocortex-template

Четыре зоны

Что делает setup.sh

Workspace после setup

2.3. Что даёт платформа через шаблон (Standard)

2.4. Что накапливается у тебя (Personal)

Три паттерна кастомизации (L3 → L4)

2.5. Обновления: update.sh

2.6. Опциональные сервисы

3.1. Иерархия принципов

3.2. Жёсткие различения

3.3. Первые принципы FPF

4.1. Три типа репозиториев

4.2. DS: три подтипа

4.3. Base/Форматы — стандартные шаблоны

4.4. Создание и управление DS-проектами

4.5. Именование и кодирование

5.1. ОРЗ-фрактал: День и Сессия

Day Open (утренний ритуал)

Day Close (вечерний ритуал)

Day Work (правила дня)

5.1b. Session Open: WP Gate + Ритуал

WP Gate (блокирующее)

Ритуал согласования

5.1c. Session Close: полный чеклист

Exit Protocol (для всех ролей)

5.2. Трёхслойная память

5.3. Capture-to-Pack: фиксация знаний

5.4. CLAUDE.md: как устроен и как настраивать

5.5. Стратег: автоматическое планирование

Настройка дня стратегирования

Activation Gate: как pending-РП попадают в план

5.6. Творческий конвейер: от заметки до поста

4 стадии артефакта

7 направлений заметки

Два ключевых различения

Anti-accumulation: TTL и guards

Замкнутый цикл: Pack ↔ Контент

Тест здоровья конвейера (на каждом стратегировании)

IWE-материализация

6.1. Что такое Pack

6.2. Создание Pack (11 стадий SPF)

6.3. Структура Pack

6.4. Экстрактор знаний (R2)

6.5. MCP-серверы знаний

knowledge-mcp — поиск по базе знаний

ddt — цифровой двойник ученика

Когда какой MCP использовать

6.6. Онтология: граф знаний

7.1. Ролецентричный подход (DP.D.033)

7.2. Каталог агентов

У тебя (L4 Personal IWE)

На платформе (L2 Platform)

7.3. Схема взаимодействия агентов

7.4. Контракт роли (для разработчиков)

8.1. ArchGate (ЭМОГССБ)

8.2. SOTA-практики

8.3. Чеклисты качества

8.4. IntegrationGate

8.5. Безопасность в IWE

Модель безопасности: 3 зоны