Merge pull request 'sync-arch: parser2 ^1.2.0 + прокидывание block_time из ActionEvent/DeltaEvent [C28-13]' (#92) from parser2-block-time-and-version into parser2

Reviewed-on: #92
Reviewed-by: Алексей Муравьев <chairman.voskhod@gmail.com>

.commitgpt-template

@@ -0,0 +1,11 @@
+Предложи 10 сообщений о коммите, основанных на следующем diff: {{diff}} 
+
+Сообщениях о коммитах должны:
+
+- следовать conventional commits
+- формат сообщения должен быть: <type>[scope]: <description>
+
+примеры:
+  - fix(authentication): добавлен regex для пароля
+  - feat(storage): добавлены новые тесты
+

.commitgpt.json

@@ -0,0 +1,5 @@
+{
+  "model": "gpt-3.5-turbo-instruct",
+  "temperature": 0.5,
+  "maxTokens": 2048
+}

.cursor/environment.json

@@ -0,0 +1,3 @@
+{
+  "agentCanUpdateSnapshot": true
+}

.cursor/rules/always.mdc

@@ -0,0 +1,8 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+ВАЖНО!!! Мы работаем в МОНО-репозитории pnpm, любая установка пакетов производится ЧЕРЕЗ ФИЛЬТР компонента в корне: pnpm add glob --filter notificator2. 
+
+ВАЖНО!!! НИКОГДА НЕ ЗАПУСКАЙ ПРИЛОЖЕНИЕ ИЛИ ЕГО СБОРКУ!!! Просто отчитайся что всё сделал.

.cursor/rules/controller.mdc

@@ -0,0 +1,151 @@
+---
+description: 
+globs: components/controller/**
+alwaysApply: false
+---
+ # NestJS Controller и Чистая архитектура
+
+## Основные принципы
+1. Чистая архитектура - главный архитектурный подход. Пиши код с комментариями.
+2. Типы IName, IChecksum256, ITimePointSec - это просто строки.
+3. Домен должен быть полностью изолирован от инфраструктурных деталей.
+4. Направление зависимостей - внутрь (к ядру, домену).
+5. Домен, инфраструктура и приложение связаны через App.module, НЕ НУЖНО импортировать их друг в друга, а достаточно просто импортировать домен на уровне приложения чтобы использовать все экспорты домена. 
+
+## Структура проекта
+- `domain/` - доменный слой (бизнес-логика, независимая от инфраструктуры)
+- `infrastructure/` - инфраструктурный слой (адаптеры к внешним системам)
+- `modules/` - слой приложения (DTO, резолверы, сервисы)
+
+## Слои и их взаимодействие
+1. **Домен**:
+   - Содержит чистые доменные интерфейсы и реализованные на них сущности
+   - НЕ должен зависеть от `cooptypes` (инфраструктурный контракт)
+   - Использует собственные доменные типы (например, Date вместо строковых timestamp)
+   - Интерфейсы портов описывают взаимодействие с внешними системами
+
+2. **Инфраструктура**:
+   - Содержит адаптеры к внешним системам (блокчейн, БД и т.д.)
+   - Осуществляет преобразование между доменными и инфраструктурными типами
+   - Общая логика преобразования выносится в утилитарные классы (например, `DomainToBlockchainUtils`)
+
+3. **Модули (приложение)**:
+   - DTO имплементируют доменные интерфейсы напрямую
+   - Резолвер вызывает сервис, который принимает DTO
+   - Сервис передает объекты DTO в интерактор домена
+
+## Поток данных
+1. Резолвер принимает входные данные и передает их в сервис
+2. Сервис вызывает интерактор домена, передавая ему объекты DTO (имплементирующие доменный интерфейс)
+3. Интерактор выполняет бизнес-логику и взаимодействует с портами домена
+4. Адаптеры (инфраструктурный слой) преобразуют доменные объекты в формат внешних систем (JSON для хранения мета-данных, ISO для дат и т.д.)
+5. Адаптеры возвращают результаты в домен, домен возвращает данные в сервис, который возвращает их в резолвер
+
+## Правила преобразования данных
+1. Преобразование DTO → доменный объект: не требуется, если DTO имплементирует доменный интерфейс
+2. Преобразование доменный объект → инфраструктурный тип: происходит в адаптерах
+3. Преобразование документов, дат и других сложных объектов: используются утилитарные классы уровня инфраструктуры
+
+## Работа с типами данных
+1. **Даты**:
+   - В доменных интерфейсах используется тип `Date`
+   - В DTO используется тип `Date` с декораторами `@IsDate()` и `@Type(() => Date)`
+   - В инфраструктурном слое происходит преобразование `Date` → `string` (ISO формат)
+   ```typescript
+   // Доменный интерфейс
+   interface MeetDomainInterface {
+     open_at: Date;
+   }
+   
+   // DTO
+   @Field(() => Date)
+   @IsDate()
+   @Type(() => Date)
+   open_at!: Date;
+   
+   // Адаптер
+   const blockchainData = {
+     open_at: domainToBlockchainUtils.convertDateToBlockchainFormat(data.open_at)
+   };
+   ```
+
+2. **Документы**:
+   - В доменных интерфейсах используется собственный тип `SignedDocumentDomainInterface<T>`
+   - В DTO используется соответствующий DTO-класс (например, `SignedDigitalDocumentInputDTO`)
+   - В инфраструктурном слое происходит преобразование между форматами (meta-поля в JSON и т.д.)
+
+## Типовые ошибки
+1. **Нарушение изоляции домена**: домен должен быть изолирован от инфраструктуры. Не используйте импорты из `cooptypes` в доменных интерфейсах.
+   ```typescript
+   // Неправильно
+   import { MeetContract } from 'cooptypes';
+   export type VoteDomainInterface = MeetContract.Actions.Vote.IInput;
+   
+   // Правильно
+   export interface VoteDomainInterface {
+     coopname: string;
+     hash: string;
+     // ... доменные поля
+   }
+   ```
+
+2. **Преобразование в неправильном слое**: преобразование доменных объектов в инфраструктурные типы должно происходить в адаптерах, а не в доменном слое или сервисе.
+   ```typescript
+   // Неправильно (в доменном интеракторе)
+   async vote(data: VoteDomainInterface) {
+     const blockchainData = { ...data, meta: JSON.stringify(data.meta) };
+     // ...
+   }
+   
+   // Правильно (в адаптере)
+   async vote(data: VoteDomainInterface) {
+     const blockchainData = this.convertToBlockchainFormat(data);
+     // ...
+   }
+   ```
+
+3. **Дублирование логики преобразования**: общая логика преобразования должна быть вынесена в утилитарные классы.
+   ```typescript
+   // Неправильно (дублирование в разных адаптерах)
+   // В MeetAdapter
+   private convertDoc(doc) { return { ...doc, meta: JSON.stringify(doc.meta) }; }
+   // В BranchAdapter
+   private convertDoc(doc) { return { ...doc, meta: JSON.stringify(doc.meta) }; }
+   
+   // Правильно (общий утилитарный класс)
+   // DomainToBlockchainUtils
+   convertSignedDocumentToBlockchainFormat(doc) { 
+     return { ...doc, meta: JSON.stringify(doc.meta) }; 
+   }
+   ```
+
+## Примеры
+```typescript
+// Доменный интерфейс - чистый, без зависимостей от инфраструктуры
+export interface VoteOnAnnualGeneralMeetInputDomainInterface {
+  coopname: string;
+  hash: string;
+  member: string;
+  ballot: VoteItemInputDomainInterface[];
+}
+
+// DTO имплементирует доменный интерфейс напрямую
+@InputType('VoteOnAnnualGeneralMeetInput')
+export class VoteOnAnnualGeneralMeetInputDTO implements VoteOnAnnualGeneralMeetInputDomainInterface {
+  @Field(() => String)
+  @IsString()
+  coopname!: string;
+  // ... остальные поля
+}
+
+// Адаптер преобразует доменный объект в инфраструктурный тип
+async vote(data: VoteOnAnnualGeneralMeetInputDomainInterface): Promise<TransactionResult> {
+  // Преобразуем доменный объект в инфраструктурный тип
+  const blockchainData: MeetContract.Actions.Vote.IInput = {
+    coopname: data.coopname,
+    hash: data.hash,
+    // ... преобразование других полей
+  };
+  // ... отправка данных во внешнюю систему
+}
+```

.cursor/rules/desktop-sdk-queries-mutations.mdc

@@ -0,0 +1,41 @@
+---
+description: SDK мутации и запросы для подключения на рабочем столе
+globs: 
+alwaysApply: false
+---
+
+Бэкенд реализован здесь components/controller, sdk здесь components/sdk. 
+
+Пример создания Query к API через SDK: 
+
+``` ts
+async function loadBranches(data: IGetBranchesInput): Promise<IBranch[]> {
+  const { [Queries.Branches.GetBranches.name]: output } = await client.Query(
+    Queries.Branches.GetBranches.query,
+    {
+      variables: {
+        data
+      }
+    }
+  );
+  return output;
+}
+```
+
+Такие запросы обычно хранятся в папке Entities и вызываются из его store. 
+
+Пример мутации:
+
+``` ts
+async function selectBranch(data: ISelectBranchInput): Promise<boolean>{
+  const {[Mutations.Branches.SelectBranch.name]: result} = await client.Mutation(Mutations.Branches.SelectBranch.mutation, {variables: {
+    data
+  }})
+
+  return result
+}
+```
+
+Мутации обычно храним в папке features. 
+
+Как можешь обратить внимание, все мутации и запросы строятся по одному шаблону. Вся необходимая информация уже есть в SDK. 

.cursor/rules/desktop.mdc

@@ -0,0 +1,12 @@
+---
+alwaysApply: true
+globs: **/desktop/**
+---
+# DESKTOP
+
+- Пишем код фронтенда в архитектуре Feature Sliced Design (FSD). 
+- Стиль шаблонов PUG на composite API. 
+- Всегда создаём index.ts файлы для vue компонент. 
+- Создавай индексные файлы для vue через export {default as NAME} from './where', а на уровне выше, если это необходимо, делай export * from './ui'
+- Всегда удаляем неиспользуемые импорты.
+- Не используем emit избыточно. Вместо них используем композабл функции моделей фич, если необходимо. Emit только в крайнем случае. 

.cursor/rules/docs.mdc

@@ -0,0 +1,62 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+Файл [main.py](mdc:monocoop/monocoop/monocoop/components/docs/main.py) автоматически генерит ссылки на документацию SDK и GraphQL, которые формируются и публикуются автоматически. При создании документации к методам всегда применяй ссылки на SDK и GraphQL по форме: 
+{{ get_sdk_doc("Mutations", "Accounts", "RegisterAccount") }} | {{ get_graphql_doc("Mutation.registerAccount") }}
+
+### 🎯 Основные паттерны использования
+
+**1. Стандартная структура для методов API:**
+```markdown
+## Название действия
+{{ get_sdk_doc("Namespace", "Module", "Method") }} | {{ get_graphql_doc("Type.methodName") }}
+
+{{ get_typedoc_input("Namespace.Module.Method") }}
+
+Результат:
+{{ get_typedoc_definition("Namespace.Module.Method", "IOutput") }}
+```
+
+**2. Описание + пример (для сложных методов):**
+```markdown
+{{ get_typedoc_desc("Namespace.Module.Method") }}
+
+{{ get_typedoc_input("Namespace.Module.Method") }}
+```
+
+**3. Ссылки на типы данных:**
+```markdown
+У каждого аккаунта есть объект {{ get_graphql_definition("Account") }} в GraphQL-API
+```
+
+### 🔧 Макросы и их применение
+
+| Макрос | Назначение | Пример использования |
+|--------|------------|---------------------|
+| `get_sdk_doc` | Ссылка на SDK документацию | `{{ get_sdk_doc("Mutations", "Payments", "CreateDeposit") }}` |
+| `get_graphql_doc` | Ссылка на GraphQL операцию | `{{ get_graphql_doc("Query.getAccount") }}` |
+| `get_graphql_definition` | Ссылка на GraphQL тип | `{{ get_graphql_definition("Account") }}` |
+| `get_class_doc` | Ссылка на класс/метод SDK | `{{ get_class_doc("Document", "sign") }}` |
+| `get_typedoc_input` | **Полный пример** TypeScript вызова | `{{ get_typedoc_input("Mutations.Auth.Login") }}` |
+| `get_typedoc_definition` | **Структура интерфейса** | `{{ get_typedoc_definition("Mutations.Auth.Login", "IOutput") }}` |
+| `get_typedoc_desc` | Описание + примеры | `{{ get_typedoc_desc("Mutations.Auth.Login") }}` |
+| `get_typedoc_value` | Значение константы | `{{ get_typedoc_value("Constants.API_VERSION") }}` |
+
+### 📝 Правила оформления
+
+**ОБЯЗАТЕЛЬНО:**
+- Всегда используй `get_typedoc_input` для демонстрации **КАК вызывать** метод
+- Всегда используй `get_typedoc_definition` для показа **ЧТО возвращается** 
+- Комбинируй SDK и GraphQL ссылки через ` | `: `{{ get_sdk_doc(...) }} | {{ get_graphql_doc(...) }}`
+
+**ЖЕЛАТЕЛЬНО:**
+- Для сложных методов добавляй `get_typedoc_desc` в начало
+- Используй `get_graphql_definition` для ссылок на типы данных в тексте
+- Группируй связанные операции в одном разделе
+
+**ФОРМАТ ССЫЛОК:**
+- SDK: `"Namespace", "Module", "Method"` (3 аргумента)
+- GraphQL: `"Type.methodName"` (точка между типом и методом)
+- Определения: просто имя типа `"TypeName"`

.cursor/rules/draft.mdc

@@ -0,0 +1,96 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+
+# Структура файлов шаблонов документов и алгоритм правки
+
+## Основные директории и файлы
+
+### 1. Определение типов и интерфейсов (cooptypes)
+**Путь:** `/cooptypes/src/cooperative/registry/[ID.DocumentName]/index.ts`
+
+В этих файлах определяются:
+- Интерфейсы данных (`IAgendaMeet`, etc.)
+- Основная модель данных документа (`Model`)
+- HTML шаблон документа (`context`)
+- Переводы строк (`translations`)
+- Пример данных для тестирования (`exampleData`)
+
+**Для изменения шаблона нужно править:**
+- Интерфейсы модели данных при изменении структуры
+- HTML в переменной `context` для изменения внешнего вида
+- Строки переводов в `translations.ru`
+
+### 2. Схемы валидации (factory)
+**Путь:** `/factory/src/Schema/[SchemaName].ts`
+
+Содержат:
+- JSON схемы для валидации данных
+- Определение обязательных полей
+
+**При изменении структуры данных:**
+- Обновите соответствующую схему валидации
+- Обновите список обязательных полей в `required`
+
+### 3. Фабрики документов (factory)
+**Путь:** `/factory/src/Actions/[ID.DocumentName].ts`
+
+Обрабатывают:
+- Получение данных из разных источников
+- Сборку модели для шаблонизатора
+- Валидацию данных по схеме
+- Генерацию PDF
+
+**При изменении логики сборки документа:**
+- Обновите метод `generateDocument()`
+- Добавьте новые источники данных
+
+### 4. Шаблоны (factory)
+**Путь:** `/factory/src/Templates/[ID.DocumentName].ts`
+
+Связывают:
+- Шаблон из cooptypes
+- Схему валидации
+- Метаданные документа
+
+**После изменения в cooptypes:**
+- Убедитесь, что схема в Templates соответствует новой модели
+
+### 5. Тесты (factory)
+**Путь:** `/factory/test/[category].test.ts`
+
+Содержат:
+- Тестовые данные для генерации документов
+- Вызовы функции `testDocumentGeneration`
+
+**После внесения изменений:**
+- Обновите тестовые данные в соответствии с новой структурой
+- Запустите тесты командой `pnpm test`
+
+## Алгоритм внесения изменений
+
+1. **Модификация типов**
+   - Изменить файл в `/cooptypes/src/cooperative/registry/[ID.DocumentName]/index.ts`
+   - Обновить интерфейсы, шаблон HTML и переводы
+
+2. **Обновление схемы валидации**
+   - Изменить соответствующую схему в `/factory/src/Schema/`
+   - Убедиться, что обязательные поля совпадают с интерфейсом
+
+3. **Компиляция библиотеки типов**
+   - Выполнить `cd /cooptypes && pnpm build`
+
+4. **Обновление тестовых данных**
+   - Привести тестовые данные в соответствие с новой структурой
+
+5. **Запуск тестов**
+   - Выполнить `cd /factory && pnpm test [filename].test.ts`
+
+## Особенности шаблонизации
+
+- Используется Nunjucks для шаблонов
+- Поддерживаются конструкции: `{% if %}`, `{% for %}`, `{% trans %}`
+- Переменные вставляются через `{{ variable }}`
+- Переводы через `{% trans 'KEY' %}`

.cursor/rules/extensions.md

@@ -0,0 +1,225 @@
+# Архитектура расширений в MonoCoop
+
+## Основные принципы
+1. Расширения построены на модулях NestJS с использованием шаблона "Порты и адаптеры"
+2. Каждое расширение наследуется от `BaseExtModule` и реализует интерфейс `OnModuleInit`
+3. Расширения могут взаимодействовать с блокчейном через соответствующие порты
+4. Конфигурации расширений хранятся в БД и описываются с помощью Zod-схем
+5. Расширения регистрируются в глобальном реестре `AppRegistry`
+
+## Структура расширения
+Минимальная структура расширения включает:
+- `XXX-extension.module.ts` - основной модуль расширения
+- `package.json` - информация о пакете
+- `README.md` - документация
+- `INSTALL.md` - инструкции по установке
+- `CHANGELOG.md` - история изменений
+
+## Создание нового расширения
+1. Создайте директорию для расширения в `components/controller/src/extensions/`
+2. Создайте основной класс расширения, наследующийся от `BaseExtModule`
+3. Определите Zod-схему для конфигурации
+4. Реализуйте метод `initialize()`
+5. Зарегистрируйте расширение в `extensions.registry.ts`
+6. Добавьте расширение в список дефолтных приложений в `extension-domain.service.ts`
+
+## Пример структуры модуля расширения
+```typescript
+// XXX-extension.module.ts
+export class XXXPlugin extends BaseExtModule {
+  constructor(...) {
+    super();
+  }
+
+  name = 'xxx';
+  plugin!: ExtensionDomainEntity<IConfig>;
+  public configSchemas = Schema;
+
+  async initialize() {
+    // Инициализация расширения
+    // Настройка cron-задач
+  }
+}
+
+@Module({
+  providers: [XXXPlugin],
+})
+export class XXXPluginModule {
+  constructor(private readonly xxxPlugin: XXXPlugin) {}
+
+  async initialize() {
+    await this.xxxPlugin.initialize();
+  }
+}
+```
+
+## Управление отображением конфигурации
+Zod-схемы используются для автоматического отображения формы настроек в интерфейсе пользователя. 
+Через интерфейс `DeserializedDescriptionOfExtension` из `components/controller/src/types/shared/extension.types.ts` 
+можно управлять отображением полей формы:
+
+```typescript
+export const Schema = z.object({
+  // Базовое поле с меткой
+  simpleField: z.string().describe(
+    describeField({
+      label: 'Название поля',
+      note: 'Подсказка под полем'
+    })
+  ),
+  
+  // Скрытое поле для служебного использования
+  hiddenField: z.string().describe(
+    describeField({
+      label: 'Скрытое поле',
+      visible: false
+    })
+  ),
+  
+  // Поле с проверкой значения
+  validatedField: z.number().describe(
+    describeField({
+      label: 'Поле с валидацией',
+      rules: ['val >= 5', 'val <= 100'],
+    })
+  ),
+  
+  // Форматированное поле с префиксом и суффиксом
+  formattedField: z.number().describe(
+    describeField({
+      label: 'Форматированное поле',
+      prepend: '$',
+      append: 'USD',
+    })
+  ),
+  
+  // Многострочное текстовое поле
+  multilineField: z.string().describe(
+    describeField({
+      label: 'Многострочное поле',
+      maxRows: 5,
+      minLength: 10,
+      maxLength: 1000
+    })
+  ),
+});
+```
+
+Доступные поля для управления отображением:
+- `label` - название поля (обязательное)
+- `note` - пояснение или подсказка
+- `visible` - видимость поля (по умолчанию true)
+- `rules` - правила валидации в виде строковых выражений
+- `mask` - маска для ввода
+- `fillMask` - автозаполнение маски
+- `minLength` / `maxLength` - ограничения длины для текстовых полей
+- `maxRows` - количество строк для многострочного ввода
+- `append` / `prepend` - текст до/после значения поля
+
+## Взаимодействие с блокчейном
+Для взаимодействия с блокчейном:
+1. Определите порт в доменном слое (например, `SovietBlockchainPort`)
+2. Инжектируйте порт в конструкторе расширения через DI
+3. Используйте методы порта для взаимодействия с блокчейном
+
+```typescript
+@Inject(SOVIET_BLOCKCHAIN_PORT) private readonly sovietBlockchainPort: SovietBlockchainPort
+// ...
+const decisions = await this.sovietBlockchainPort.getDecisions(coopname);
+```
+
+## Настройка планировщика задач
+Расширения могут использовать cron-задачи для периодического выполнения операций:
+
+```typescript
+import cron from 'node-cron';
+
+// Регистрация cron-задачи (каждые N минут)
+const cronExpression = `*/${this.plugin.config.checkInterval} * * * *`;
+cron.schedule(cronExpression, () => {
+  this.logger.info('Запуск запланированной задачи');
+  this.runTask();
+});
+```
+
+## Работа с конфигурацией
+1. Определите Zod-схему для конфигурации
+2. Используйте `describeField` для добавления UI-метаданных к полям
+3. Получайте и обновляйте конфигурацию через репозиторий `extensionRepository`
+
+```typescript
+export const Schema = z.object({
+  checkInterval: z.number().describe(
+    describeField({
+      label: 'Интервал проверки (в минутах)',
+      note: 'Минимум: 5 минут',
+      rules: ['val >= 5'],
+    })
+  ),
+});
+
+// Обновление конфигурации
+this.plugin.config.lastCheckDate = new Date().toISOString();
+await this.extensionRepository.update(this.plugin);
+```
+
+## Логирование действий
+Расширения должны логировать свои действия:
+1. Используйте `WinstonLoggerService` для системного логирования
+2. Используйте `LogExtensionDomainRepository` для хранения логов в БД
+
+```typescript
+// Системное логирование
+this.logger.info(`Выполнение операции для ${id}`);
+
+// Сохранение лога в БД
+await this.logExtensionRepository.push(this.name, {
+  type: 'operation',
+  timestamp: new Date().toISOString(),
+  data: { ... },
+});
+```
+
+## Регистрация расширения
+После создания расширения, добавьте его в `extensions.registry.ts`:
+
+```typescript
+export const AppRegistry: INamedExtension = {
+  myExtension: {
+    is_builtin: false,
+    is_internal: true,
+    is_available: true,
+    is_desktop: false,
+    title: 'Моё расширение',
+    description: 'Описание функциональности.',
+    image: 'https://example.com/image.png',
+    class: MyExtensionPluginModule,
+    schema: MyExtensionSchema,
+    tags: ['тег1', 'тег2'],
+    readme: getReadmeContent('./myExtension'),
+    instructions: getInstructionsContent('./myExtension'),
+  },
+};
+```
+
+## Дефолтные настройки
+Добавьте расширение в список дефолтных приложений в `extension-domain.service.ts`:
+
+```typescript
+getDefaultApps(): Partial<ExtensionDomainEntity>[] {
+  return [
+    // ...
+    {
+      name: 'myExtension',
+      enabled: true,
+      config: {
+        // Дефолтные значения конфигурации
+        parameter1: 'value1',
+        parameter2: 42,
+      },
+    },
+    // ...
+  ];
+}
+``` 
+ 

.cursor/rules/extensions.mdc

@@ -0,0 +1,168 @@
+---
+description: 
+globs: **/controller/src/extensions/**
+alwaysApply: false
+---
+# Архитектура расширений в MonoCoop
+
+## Основные принципы
+1. Расширения построены на модулях NestJS с использованием шаблона "Порты и адаптеры"
+2. Каждое расширение наследуется от `BaseExtModule` и реализует интерфейс `OnModuleInit`
+3. Расширения могут взаимодействовать с блокчейном через соответствующие порты
+4. Конфигурации расширений хранятся в БД и описываются с помощью Zod-схем
+5. Расширения регистрируются в глобальном реестре `AppRegistry`
+
+## Структура расширения
+Минимальная структура расширения включает:
+- `XXX-extension.module.ts` - основной модуль расширения
+- `package.json` - информация о пакете
+- `README.md` - документация
+- `INSTALL.md` - инструкции по установке
+- `CHANGELOG.md` - история изменений
+
+## Создание нового расширения
+1. Создайте директорию для расширения в `components/controller/src/extensions/`
+2. Создайте основной класс расширения, наследующийся от `BaseExtModule`
+3. Определите Zod-схему для конфигурации
+4. Реализуйте метод `initialize()`
+5. Зарегистрируйте расширение в `extensions.registry.ts`
+6. Добавьте расширение в список дефолтных приложений в `extension-domain.service.ts`
+
+## Пример структуры модуля расширения
+```typescript
+// XXX-extension.module.ts
+export class XXXPlugin extends BaseExtModule {
+  constructor(...) {
+    super();
+  }
+
+  name = 'xxx';
+  plugin!: ExtensionDomainEntity<IConfig>;
+  public configSchemas = Schema;
+
+  async initialize() {
+    // Инициализация расширения
+    // Настройка cron-задач
+  }
+
+  // Дополнительные методы расширения
+}
+
+@Module({
+  providers: [XXXPlugin],
+})
+export class XXXPluginModule {
+  constructor(private readonly xxxPlugin: XXXPlugin) {}
+
+  async initialize() {
+    await this.xxxPlugin.initialize();
+  }
+}
+```
+
+## Взаимодействие с блокчейном
+Для взаимодействия с блокчейном:
+1. Определите порт в доменном слое (например, `SovietBlockchainPort`)
+2. Инжектируйте порт в конструкторе расширения через DI
+3. Используйте методы порта для взаимодействия с блокчейном
+
+```typescript
+@Inject(SOVIET_BLOCKCHAIN_PORT) private readonly sovietBlockchainPort: SovietBlockchainPort
+// ...
+const decisions = await this.sovietBlockchainPort.getDecisions(coopname);
+```
+
+## Настройка планировщика задач
+Расширения могут использовать cron-задачи для периодического выполнения операций:
+
+```typescript
+import cron from 'node-cron';
+
+// Регистрация cron-задачи (каждые N минут)
+const cronExpression = `*/${this.plugin.config.checkInterval} * * * *`;
+cron.schedule(cronExpression, () => {
+  this.logger.info('Запуск запланированной задачи');
+  this.runTask();
+});
+```
+
+## Работа с конфигурацией
+1. Определите Zod-схему для конфигурации
+2. Используйте `describeField` для добавления UI-метаданных к полям
+3. Получайте и обновляйте конфигурацию через репозиторий `extensionRepository`
+
+```typescript
+export const Schema = z.object({
+  checkInterval: z.number().describe(
+    describeField({
+      label: 'Интервал проверки (в минутах)',
+      note: 'Минимум: 5 минут',
+      rules: ['val >= 5'],
+    })
+  ),
+});
+
+// Обновление конфигурации
+this.plugin.config.lastCheckDate = new Date().toISOString();
+await this.extensionRepository.update(this.plugin);
+```
+
+## Логирование действий
+Расширения должны логировать свои действия:
+1. Используйте `WinstonLoggerService` для системного логирования
+2. Используйте `LogExtensionDomainRepository` для хранения логов в БД
+
+```typescript
+// Системное логирование
+this.logger.info(`Выполнение операции для ${id}`);
+
+// Сохранение лога в БД
+await this.logExtensionRepository.push(this.name, {
+  type: 'operation',
+  timestamp: new Date().toISOString(),
+  data: { ... },
+});
+```
+
+## Регистрация расширения
+После создания расширения, добавьте его в `extensions.registry.ts`:
+
+```typescript
+export const AppRegistry: INamedExtension = {
+  myExtension: {
+    is_builtin: false,
+    is_internal: true,
+    is_available: true,
+    is_desktop: false,
+    title: 'Моё расширение',
+    description: 'Описание функциональности.',
+    image: 'https://example.com/image.png',
+    class: MyExtensionPluginModule,
+    schema: MyExtensionSchema,
+    tags: ['тег1', 'тег2'],
+    readme: getReadmeContent('./myExtension'),
+    instructions: getInstructionsContent('./myExtension'),
+  },
+};
+```
+
+## Дефолтные настройки
+Добавьте расширение в список дефолтных приложений в `extension-domain.service.ts`:
+
+```typescript
+getDefaultApps(): Partial<ExtensionDomainEntity>[] {
+  return [
+    // ...
+    {
+      name: 'myExtension',
+      enabled: true,
+      config: {
+        // Дефолтные значения конфигурации
+        parameter1: 'value1',
+        parameter2: 42,
+      },
+    },
+    // ...
+  ];
+}
+```

.cursor/rules/factory.mdc

@@ -0,0 +1,261 @@
+---
+description: 
+globs: src/**/*.ts
+alwaysApply: false
+---
+# Фабрика Документов Кооперативов
+
+## Общая Архитектура
+
+Фабрика документов — это система генерации PDF документов для кооперативов, построенная на TypeScript с использованием MongoDB для хранения данных. Система состоит из трех основных частей:
+
+1. **registry/** — JSON-шаблоны документов (статические данные)
+2. **factory/** — основная фабрика с логикой генерации
+3. **cooptypes/** — типы данных и интерфейсы
+
+## Структура Registry
+
+В корневой папке `registry/` находятся JSON файлы с номерными названиями, представляющие шаблоны документов:
+
+### Основные документы:
+- `1.walletProgramAgreement.json` — соглашение о кошельке
+- `2.regulationElectronicSignature.json` — регламент электронной подписи
+- `3.privacyPolicy.json` — политика конфиденциальности
+- `4.userAgreement.json` — пользовательское соглашение
+- `50.CoopenomicsAgreement.json` — соглашение с партнерами
+- `100.participantApplication.json` — заявление участника
+- `101.selectBranchStatement.json` — заявление о выборе филиала
+
+### Документы общих собраний (300-304):
+- `300.annualGeneralMeetingAgenda.json` — предложение повестки дня
+- `301.annualGeneralMeetingSovietDecision.json` — протокол заседания совета
+- `302.annualGeneralMeetingNotification.json` — уведомление о собрании
+- `303.annualGeneralMeetingVotingBallot.json` — бюллетень для голосования
+- `304.annualGeneralMeetingDecision.json` — протокол общего собрания
+
+### Инвестиционные документы (1000+):
+- `1000.investAgreement.json` — инвестиционное соглашение
+- `1001.investByResultStatement.json` — заявление о зачете по результатам
+- `1002.investByResultAct.json` — акт зачета по результатам
+- `1005.investByMoneyStatement.json` — заявление о зачете денежных средств
+
+### Структура JSON-шаблона:
+```json
+{
+  "context": "<div>...HTML шаблон с переменными...</div>",
+  "model": {...данные для примера...},
+  "translation": {...переводы ключей...},
+  "object_model": {...схема объектной модели...}
+}
+```
+
+## Фабрика (factory/)
+
+### Основные компоненты:
+
+#### src/index.ts — Главный класс Generator
+```typescript
+export class Generator implements IGenerator {
+  // Хранилище фабрик для каждого типа документа
+  factories: { [K in Numbers]: DocFactory<IGenerate> }
+  
+  // MongoDB коннектор
+  public storage: MongoDBConnector
+  
+  // Основной метод генерации
+  async generate(data: IGenerate, options?: IGenerationOptions): Promise<IGeneratedDocument>
+}
+```
+
+#### Архитектура Factory Pattern:
+- Базовый класс `DocFactory<T>` в `src/Factory/index.ts`
+- Каждый документ имеет свою фабрику в `src/Actions/`
+- Фабрики наследуются от `DocFactory` и реализуют метод `generateDocument()`
+
+### Сервисы:
+
+#### Services/Generator/ — PDF генерация
+- `PDFService` — конвертирует HTML в PDF через WeasyPrint
+- Использует шрифт Arial (base64)
+- Добавляет метаданные в PDF
+- Вычисляет SHA-256 хеш документа
+
+#### Services/Templator/ — Шаблонизация
+- Основан на Nunjucks
+- Поддерживает кастомное расширение `{% trans %}` для переводов
+- Рендерит HTML из шаблона с подстановкой переменных
+
+#### Services/Validator/ — Валидация
+- Использует AJV для JSON Schema валидации
+- Поддерживает кастомные форматы (телефон)
+- Локализация ошибок на русском языке
+
+#### Services/Databazor/ — База данных
+- `MongoDBConnector` — работа с MongoDB
+- `DataService` — абстракция над данными
+- Коллекции: `deltas`, `actions`, `documents`, и другие
+
+### Модели данных (src/Models/):
+
+#### Основные типы пользователей:
+- `Individual` — физические лица (ФИО, паспорт, адрес)
+- `Organization` — организации (ИНН, ОГРН, представитель)
+- `Entrepreneur` — ИП (ФИО + ИНН/ОГРН)
+
+#### Кооперативные данные:
+- `Cooperative` — данные кооператива
+- `PaymentMethod` — платежные методы
+- `Vars` — переменные кооператива
+- `Project` — проекты
+
+### Система Action-ов:
+
+Каждый документ имеет Action класс в `src/Actions/` с методом `generateDocument()`:
+
+1. **Получение шаблона** — из локального Registry или MongoDB
+2. **Сбор данных** — пользователь, кооператив, переменные, специфичные данные
+3. **Валидация** — проверка по JSON схеме
+4. **Рендеринг** — HTML из шаблона + данные
+5. **PDF генерация** — HTML → PDF с метаданными
+6. **Сохранение** — в MongoDB (если не skip_save)
+
+## Система типов (cooptypes/)
+
+### cooperative/registry/ — Типы документов
+Каждый документ имеет папку с интерфейсами:
+- `Action` — входные данные для генерации
+- `Model` — модель данных для шаблона
+- `Template` — структура шаблона
+
+### contracts/ — Блокчейн контракты
+- `registrator/` — регистрация кооперативов
+- `soviet/` — управление советом
+- `meet/` — общие собрания
+- `wallet/`, `capital/`, `fund/` — финансовые операции
+
+## База данных MongoDB
+
+### Основные коллекции:
+
+#### deltas — Состояние блокчейна
+```javascript
+{
+  block_num: number,
+  present: boolean,
+  code: string,    // название контракта
+  scope: string,   // область действия
+  table: string,   // имя таблицы
+  primary_key: string,
+  value: {...}     // данные записи
+}
+```
+
+#### actions — Действия блокчейна
+```javascript
+{
+  block_num: number,
+  account: string,
+  name: string,     // имя действия
+  receiver: string,
+  data: {...}       // данные действия
+}
+```
+
+#### documents — Сгенерированные документы
+```javascript
+{
+  hash: string,           // SHA-256 хеш
+  binary: Uint8Array,     // PDF данные
+  html: string,           // HTML исходник
+  meta: {                 // метаданные
+    title: string,
+    created_at: string,
+    lang: string
+  }
+}
+```
+
+### Таблицы данных:
+- `coops` — кооперативы
+- `meets` — собрания
+- `questions` — вопросы собраний
+- `decisions` — решения совета
+- `individuals` — физические лица
+- `organizations` — организации
+- `entrepreneurs` — ИП
+- `paymentMethods` — платежные методы
+- `vars` — переменные кооперативов
+
+## Генерация документов
+
+### Процесс генерации:
+1. **Вызов** `generator.generate(action, options)`
+2. **Поиск фабрики** по `registry_id`
+3. **Загрузка шаблона** (локально или из БД)
+4. **Сбор данных** из MongoDB по `coopname`, `username`, `block_num`
+5. **Создание модели** — объединение всех данных
+6. **Валидация** модели по JSON схеме
+7. **Рендеринг HTML** через Nunjucks
+8. **Генерация PDF** через WeasyPrint
+9. **Добавление метаданных** в PDF
+10. **Вычисление хеша** SHA-256
+11. **Сохранение** в MongoDB
+
+### Пример использования:
+```typescript
+const generator = new Generator()
+await generator.connect(mongoUri)
+
+const document = await generator.generate({
+  registry_id: '300',
+  coopname: 'voskhod',
+  username: 'ant',
+  block_num: 0,
+  meet: {...},
+  questions: [...]
+})
+```
+
+## Особенности реализации
+
+### Шаблонизация:
+- HTML шаблоны с CSS стилями
+- Переменные в формате `{{variable.field}}`
+- Условная логика `{% if condition %}`
+- Циклы `{% for item in array %}`
+- Переводы `{% trans 'KEY', var1, var2 %}`
+
+### Подписи:
+- Цифровые подписи вместо физических
+- Текст "Подписано электронной подписью"
+- Убраны подчеркивания для подписей
+
+### Типы собраний:
+- `regular` — очередное
+- `extraordinary` — внеочередное
+- Условная логика в шаблонах
+
+### Филиалы:
+- `coop.is_branched` — проверка на наличие филиалов
+- "пайщиков" vs "уполномоченных" в зависимости от типа
+
+### Форматирование дат:
+- Формат: "г. Москва, 15 декабря 2024 г."
+- Без кавычек вокруг дат
+- Запятая после города
+
+## Тестирование
+
+### test/utils/index.ts — Тестовые утилиты:
+- `preLoading()` — инициализация тестовых данных
+- Создание кооператива, пользователей, платежных методов
+- Настройка данных собраний и решений
+- Очистка временных файлов
+
+### Тестовые данные:
+- Кооператив "ВОСХОД"
+- Пользователи: ant, individual, entrepreneur
+- Организации: voskhod, branch, exampleorg
+- Собрания с вопросами и решениями
+
+Фабрика поддерживает полный цикл создания документов кооператива от заявлений до протоколов собраний с возможностью кастомизации под разные типы кооперативов и требования.

.cursor/rules/sdk.mdc

@@ -0,0 +1,59 @@
+---
+description: 
+globs: components/sdk/**
+alwaysApply: false
+---
+
+# Руководство по работе с GraphQL Zeus в SDK
+
+## Основной процесс
+
+1. **Анализ DTO бэкенда**:
+   - Изучите структуру DTO классов (`@ObjectType`) в бэкенде
+   - Обратите внимание на имена типов в декораторах `@ObjectType('ИмяТипа')`
+   - Отметьте поля, связи и вложенные объекты
+
+2. **Создание селекторов**:
+   - Для каждого DTO создайте соответствующий селектор с именем `raw<ИмяТипа>Selector`
+   - Селектор - это объект, где ключи соответствуют полям DTO, а значения - `true`
+   - Для вложенных объектов используйте вложенные селекторы: `field: nestedSelector`
+   - Для списков используйте один селектор без массива: `items: itemSelector`
+
+3. **Валидация селекторов**:
+   - Для каждого селектора создайте проверку типа:
+   ```typescript
+   const _validate: MakeAllFieldsRequired<ValueTypes['ТочноеИмяГрафКьЭлТипа']> = rawSelector
+   ```
+   - Имя типа должно точно совпадать с именем в декораторе `@ObjectType`
+
+4. **Экспорт селекторов**:
+   - Создайте финальный селектор с помощью функции `Selector`:
+   ```typescript
+   export const typeSelector = Selector('ТочноеИмяГрафКьЭлТипа')(rawTypeSelector)
+   ```
+   - Экспортируйте сырой селектор для переиспользования
+   - Экспортируйте тип модели: `export type modelType = ModelTypes['ТочноеИмяГрафКьЭлТипа']`
+
+5. **Создание запросов/мутаций**:
+   - Используйте селекторы в запросах и мутациях:
+   ```typescript
+   export const query = Selector('Query')({
+     queryName: [{ data: $('data', 'ТочноеИмяВходногоТипа!') }, exportedSelector]
+   })
+   ```
+   - Для параметров используйте оператор `$` с точным именем входного типа
+   - Создайте интерфейс входных данных:
+   ```typescript
+   export interface IInput {
+     data: ModelTypes['ТочноеИмяВходногоТипа']
+   }
+   ```
+
+## Особенности работы
+
+- **Документы**: всегда сохраняйте структуру `{ hash, signatures, rawDocument }`
+- **Сложные DTO**: разбивайте на атомарные селекторы и комбинируйте их
+- **Типы в Zeus**: часто отличаются от имен классов в бэкенде, всегда проверяйте в `schema.gql`
+- **Массивы**: Zeus автоматически обрабатывает массивы, не используйте `[selector]`
+
+Это руководство поможет правильно структурировать работу с SDK и избежать типичных ошибок при работе с Zeus.

.cursor/rules/workflow-validation.mdc

@@ -0,0 +1,20 @@
+---
+globs: notifications/src/workflows/**/*.ts
+---
+# Правила валидации воркфлоу
+
+## 🚫 ID воркфлоу
+- **Длина ID не должна превышать 32 символа**
+- Используйте описательные, но короткие идентификаторы малыми латинскими буквами и тире. 
+
+## 🚫 Условия в шаблонах
+- **Запрещено использовать JavaScript выражения в шаблонах Novu**
+- Нельзя использовать:
+  - Тернарные операторы: `{{condition ? "text1" : "text2"}}`
+  - Логические операторы: `{{field && "text"}}`
+  - Любые другие JS конструкции
+
+## ✅ Рекомендации
+- Добавляйте текстовые поля в payload для условной логики
+- Вычисляйте значения на стороне сервера перед отправкой уведомления
+- Используйте только простые переменные: `{{payload.fieldName}}`

.dockerignore

@@ -0,0 +1,41 @@
+# Не тащить в build-context — экономит время `docker build` (особенно
+# на крупных репах с .git под 1GB) и не пачкает финальный образ.
+node_modules
+**/node_modules
+dist
+**/dist
+.git
+.github
+.gitignore
+.cursor
+**/.DS_Store
+
+# State от локальных runtime-сценариев (boot:remote / dev-нода / wallet)
+**/blockchain-data
+**/wallet-data
+**/keosd-data
+
+# CI/coverage/тестовые артефакты
+coverage
+**/coverage
+.nyc_output
+*.log
+
+# BMad/blago workspace папки (не относятся к билду образа)
+_blago
+**/_blago
+.bmad-core
+.bmad-output
+
+# Локальные секреты (на всякий случай — секреты должны идти через
+# build-args / docker-compose environment, не через COPY)
+.env
+.env.*
+!.env-example
+**/.env
+**/.env.*
+!**/.env-example
+
+# Артефакты других сервисов
+components/desktop/.quasar
+components/contracts/build

.env.example

@@ -0,0 +1,41 @@
+# Шаблон per-instance конфига. Скопируй в .env и подправь под свой инстанс.
+#
+# Зачем: docker-compose.yaml и boot-скрипты параметризованы — это
+# позволяет держать несколько копий репо (mono-ai-1, mono-ai-2 ...) с
+# полностью изолированной инфраструктурой и запускать их параллельно.
+#
+# Без .env compose поднимется с дефолтами (как у mono-ai-1).
+# Дефолты ниже соответствуют первому инстансу — для второго и далее
+# применяй смещение portов: offset = (INSTANCE_INDEX - 1) * 10.
+
+# Индекс инстанса (1 = базовый, 2/3/... = параллельные копии).
+INSTANCE_INDEX=1
+
+# Имя docker compose проекта. Определяет префикс автогенерируемых
+# имён контейнеров (mongo → <COMPOSE_PROJECT_NAME>-mongo-1).
+# По умолчанию compose возьмёт имя папки — оставь как есть, если папка
+# уже называется уникально (например, mono-ai-1).
+COMPOSE_PROJECT_NAME=mono-ai-1
+
+# Host-порты (для INSTANCE_INDEX=2 прибавь +10 к каждому, для =3 +20 и т.д.).
+NODE_HTTP_PORT=8888
+NODE_P2P_PORT=9876
+NODE_HISTORY_PORT=8070
+MONGO_HOST_PORT=27017
+REDIS_HOST_PORT=6379
+PG_HOST_PORT=5532
+COOPBACK_HOST_PORT=2998
+DESKTOP_HOST_PORT=2999
+OPENSEARCH_HOST_PORT=9200
+MINIO_HOST_PORT=9000
+MINIO_CONSOLE_HOST_PORT=9001
+
+# MinIO root credentials (только для локального dev; на prod подменяются плейбуком).
+MINIO_ROOT_USER=minioadmin
+MINIO_ROOT_PASSWORD=minioadmin
+
+# URL для скриптов и кода, запускаемого с хоста (boot, networks.sh,
+# preactivate.sh, health.ts). Должны соответствовать host-портам выше.
+CHAIN_URL=http://127.0.0.1:8888
+API_URL=http://127.0.0.1:2998/v1/graphql
+MONGODB_URL=mongodb://127.0.0.1:27017

.gitconfig

@@ -0,0 +1,2 @@
+[core]
+    ignorecase = false

.github/CI_TRIAL.md

@@ -0,0 +1,3 @@
+Trial run of Typecheck workflow on PR → dev.
+Created 2026-05-23 to measure end-to-end duration of vue-tsc (desktop) and tsc (controller).
+Do not merge; close after measurement.

.github/workflows/build-bootstrap.yaml

@@ -0,0 +1,86 @@
+name: Build bootstrap container
+
+# Сборка и публикация docker-образа `dicoop/bootcoop` — bootstrap-артефакта
+# для развёртывания контрактов на удалённой ноде. Образ содержит CLI
+# (`pnpm run boot:remote`) и `/contracts` от dicoop/contracts (multi-stage).
+# Используется как one-shot job в стороннем docker-compose рядом с
+# `dicoop/blockchain` — никакой mono-инфры (mongo/postgres/desktop) не нужно.
+#
+# Триггер — push в dev/testnet/main. Тег `dicoop/bootcoop` совпадает с
+# веткой и подтягивает соответствующий тег `dicoop/contracts` (так
+# контракты и bootstrap всегда синхронны).
+#
+# Зависимости в hub:
+#   dicoop/contracts:<branch>   — пакет wasm/abi (build-contracts.yaml)
+#
+# Образ self-contained: собирает workspace из текущего checkout'а,
+# не зависит от dicoop/mono-base (который тегается только релиз-тегами).
+#
+# Секреты:
+#   DOCKERHUB_USERNAME / DOCKERHUB_TOKEN
+
+on:
+  push:
+    branches: [dev, testnet, main]
+    paths:
+      - 'components/boot/**'
+      - '.github/workflows/build-bootstrap.yaml'
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Determine docker tags
+        run: |
+          case "${{ github.ref_name }}" in
+            main)
+              echo "DOCKER_TAG=main"   >> $GITHUB_ENV
+              echo "EXTRA_TAG=latest"  >> $GITHUB_ENV
+              ;;
+            testnet)
+              echo "DOCKER_TAG=testnet" >> $GITHUB_ENV
+              echo "EXTRA_TAG="         >> $GITHUB_ENV
+              ;;
+            dev)
+              echo "DOCKER_TAG=dev"    >> $GITHUB_ENV
+              echo "EXTRA_TAG="        >> $GITHUB_ENV
+              ;;
+            *)
+              echo "Unsupported branch ${{ github.ref_name }}" >&2
+              exit 1
+              ;;
+          esac
+
+      - name: Login to DockerHub
+        uses: docker/login-action@v3
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      - name: Pull contracts image
+        run: docker pull dicoop/contracts:${{ env.DOCKER_TAG }}
+
+      - name: Build and push image
+        run: |
+          IMAGE="dicoop/bootcoop"
+          docker build \
+            --build-arg CONTRACTS_TAG=${{ env.DOCKER_TAG }} \
+            --label "org.opencontainers.image.revision=${{ github.sha }}" \
+            --label "org.opencontainers.image.created=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
+            -f components/boot/Dockerfile \
+            -t "$IMAGE:${{ env.DOCKER_TAG }}" \
+            .
+          docker push "$IMAGE:${{ env.DOCKER_TAG }}"
+
+          if [ -n "${{ env.EXTRA_TAG }}" ]; then
+            docker tag "$IMAGE:${{ env.DOCKER_TAG }}" "$IMAGE:${{ env.EXTRA_TAG }}"
+            docker push "$IMAGE:${{ env.EXTRA_TAG }}"
+          fi
+
+          SHORT_SHA="${GITHUB_SHA::7}"
+          docker tag "$IMAGE:${{ env.DOCKER_TAG }}" "$IMAGE:${{ env.DOCKER_TAG }}-$SHORT_SHA"
+          docker push "$IMAGE:${{ env.DOCKER_TAG }}-$SHORT_SHA"

.github/workflows/release.yaml

@@ -0,0 +1,462 @@
+name: Release
+
+# Единый релизный workflow по push'у тэга `v*`.
+#
+# Порядок (через jobs.needs):
+#   1) release             — контракты + контейнеры + webhook деплоя (атомарно)
+#   2) publish-packages    — npm publish через lerna (если не -alpha)
+#   3) publish-docs        — mkdocs + standards-site → gh-pages (если не -alpha + ветка main)
+#   4) trigger-coopenomics — repository_dispatch в coopenomics/coopenomics (тот же гейт, что docs)
+#
+# Зачем последовательно: пакеты/доки/внешний триггер не должны уезжать,
+# если релиз контрактов или контейнеров провалился. Раньше четыре workflow'а
+# стартовали параллельно по одному тэгу — отсюда гонка из инцидента 2026-05-13
+# с ledger2 walletop sweep'ом (см. историю release.yaml до объединения).
+#
+# Гейт `-alpha` унифицирован: пакеты + доки + триггер docs пропускают только
+# не-alpha тэги. -beta/-rc/-test в проекте не используются (см. CLAUDE.md),
+# поэтому проще иметь один паттерн `!contains(github.ref, '-alpha')`.
+# IS_PROD в release-job остаётся на `(alpha|beta|rc|test)` — он определяет
+# деплой-webhook (testnet vs production) и тэг `:latest` у образов;
+# намеренно строже, чтобы случайный -rc-тэг не уехал на прод.
+#
+# Резолв ветки. Тэг семантики окружения не несёт (например `v2026.5.13-alpha-2`
+# может лежать на testnet или dev — определяет именно ветка, на которую сделан
+# merge перед тэгом). Поэтому ищем первое совпадение SHA с remote-ветками
+# main/testnet/dev. branch экспортируется как outputs.branch для downstream jobs.
+
+on:
+  push:
+    tags:
+      - 'v*'
+
+permissions:
+  contents: write
+
+jobs:
+  # Гейт TS-типов перед сборкой образов. Reusable workflow `typecheck.yaml`
+  # запускает vue-tsc на desktop и tsc --noEmit на controller. Нужно потому,
+  # что `lerna run build` в корневом Dockerfile НЕ ловит TS-ошибки:
+  # quasar build идёт через esbuild с выключенным vueTsc, а у controller'а
+  # build-скрипта вообще нет (ts-node в рантайме).
+  typecheck:
+    uses: ./.github/workflows/typecheck.yaml
+
+  release:
+    needs: typecheck
+    runs-on: ubuntu-latest
+    outputs:
+      tag_name: ${{ steps.resolve.outputs.tag_name }}
+      branch: ${{ steps.resolve.outputs.branch }}
+      is_prod: ${{ steps.resolve.outputs.is_prod }}
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Resolve branch, build mode and tags
+        id: resolve
+        run: |
+          TAG_NAME="${{ github.ref_name }}"
+          SHA="${{ github.sha }}"
+          BRANCH=""
+          for candidate in main testnet dev; do
+            if git branch -r --contains "$SHA" 2>/dev/null | grep -qE "^[[:space:]]*origin/${candidate}$"; then
+              BRANCH="$candidate"
+              break
+            fi
+          done
+          if [ -z "$BRANCH" ]; then
+            echo "::error::Тэг $TAG_NAME ($SHA) не лежит ни на одной из dev/testnet/main"
+            exit 1
+          fi
+
+          case "$BRANCH" in
+            main)
+              BUILD_MODE=prod
+              CONTRACTS_TAG=main
+              CONTRACTS_EXTRA=latest
+              ;;
+            testnet)
+              BUILD_MODE=test
+              CONTRACTS_TAG=testnet
+              CONTRACTS_EXTRA=
+              ;;
+            dev)
+              BUILD_MODE=test
+              CONTRACTS_TAG=dev
+              CONTRACTS_EXTRA=
+              ;;
+          esac
+
+          # IS_PROD определяет webhook деплоя (PRODUCTION vs TESTNET) и тэг :latest.
+          # Сознательно строже гейта publish-* — случайный -rc/-beta тэг не должен
+          # уехать на прод-вебхук, даже если в npm/docs его опубликовали.
+          if [[ "$TAG_NAME" =~ -(alpha|beta|rc|test) ]]; then
+            IS_PROD=false
+            WEBHOOK_URL='${{ vars.TESTNET_WEBHOOK_URL }}'
+          else
+            IS_PROD=true
+            WEBHOOK_URL='${{ vars.PRODUCTION_WEBHOOK_URL }}'
+          fi
+
+          {
+            echo "TAG_NAME=$TAG_NAME"
+            echo "SHA=$SHA"
+            echo "BRANCH=$BRANCH"
+            echo "BUILD_MODE=$BUILD_MODE"
+            echo "CONTRACTS_TAG=$CONTRACTS_TAG"
+            echo "CONTRACTS_EXTRA=$CONTRACTS_EXTRA"
+            echo "IS_PROD=$IS_PROD"
+            echo "WEBHOOK_URL=$WEBHOOK_URL"
+          } >> "$GITHUB_ENV"
+
+          {
+            echo "tag_name=$TAG_NAME"
+            echo "branch=$BRANCH"
+            echo "is_prod=$IS_PROD"
+          } >> "$GITHUB_OUTPUT"
+
+          echo "Release $TAG_NAME → branch=$BRANCH, build_mode=$BUILD_MODE, contracts:$CONTRACTS_TAG, prod=$IS_PROD"
+
+      - name: Login to DockerHub
+        uses: docker/login-action@v3
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      # === Этап 1: контракты ===
+
+      - name: Pull CDT toolchain image
+        run: docker pull dicoop/blockchain_v5.1.1:dev
+
+      - name: Compile contracts
+        working-directory: components/contracts
+        run: |
+          ./build-all.sh "$BUILD_MODE"
+          echo "--- build/contracts ---"
+          ls -la build/contracts/
+
+      - name: Stage contracts docker context
+        working-directory: components/contracts
+        run: |
+          ROOT="docker/.context"
+          rm -rf "$ROOT"
+          mkdir -p "$ROOT/contracts"
+
+          # Имена контрактов = аргументы add_contract_build(...) только в
+          # незакомменченных строках (CMake-комментарий начинается с `#`).
+          NAMES=$(grep -E '^[[:space:]]*add_contract_build\(' CMakeLists.txt \
+                   | sed -E 's/^[[:space:]]*add_contract_build\(([^)]*)\).*/\1/')
+          echo "Contracts to package:"
+          echo "$NAMES"
+
+          MANIFEST="$ROOT/contracts/manifest.json"
+
+          pack_one() {
+            local NAME="$1" WASM="$2" ABI="$3"
+            if [ ! -f "$WASM" ] || [ ! -f "$ABI" ]; then
+              echo "::warning::Skipping $NAME: artifacts missing ($WASM / $ABI)" >&2
+              return 1
+            fi
+            mkdir -p "$ROOT/contracts/$NAME"
+            cp "$WASM" "$ROOT/contracts/$NAME/$NAME.wasm"
+            cp "$ABI"  "$ROOT/contracts/$NAME/$NAME.abi"
+            local SHA_WASM=$(sha256sum "$WASM" | awk '{print $1}')
+            local SHA_ABI=$(sha256sum  "$ABI"  | awk '{print $1}')
+            printf '    {"name":"%s","sha256_wasm":"%s","sha256_abi":"%s"}' \
+                   "$NAME" "$SHA_WASM" "$SHA_ABI"
+          }
+
+          {
+            printf '{\n'
+            printf '  "build_mode": "%s",\n' "$BUILD_MODE"
+            printf '  "git_sha": "%s",\n' "$SHA"
+            printf '  "tag": "%s",\n'    "$TAG_NAME"
+            printf '  "branch": "%s",\n' "$BRANCH"
+            printf '  "built_at": "%s",\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+            printf '  "contracts": [\n'
+
+            FIRST=1
+            emit() {
+              entry=$(pack_one "$@") || return 0
+              [ $FIRST -eq 0 ] && printf ',\n'
+              FIRST=0
+              printf '%s' "$entry"
+            }
+
+            for c in $NAMES; do
+              if [ "$c" = "system" ]; then
+                # У system многоконтрактная сборка: разносим под-контракты
+                # eosio.* как полноценные элементы каталога, сам "system"
+                # как имя пропускаем.
+                for sub in build/contracts/system/contracts/eosio.*/; do
+                  [ -d "$sub" ] || continue
+                  sub_name=$(basename "$sub")
+                  emit "$sub_name" "$sub/$sub_name.wasm" "$sub/$sub_name.abi"
+                done
+              else
+                emit "$c" "build/contracts/$c/$c.wasm" "build/contracts/$c/$c.abi"
+              fi
+            done
+
+            printf '\n  ]\n'
+            printf '}\n'
+          } > "$MANIFEST"
+
+          cp docker/Dockerfile     "$ROOT/Dockerfile"
+          cp docker/entrypoint.sh  "$ROOT/entrypoint.sh"
+          chmod +x "$ROOT/entrypoint.sh"
+
+          echo "--- manifest.json ---"
+          cat "$MANIFEST"
+
+      - name: Build and push contracts image
+        working-directory: components/contracts
+        run: |
+          IMAGE="dicoop/contracts"
+          SHORT_SHA="${SHA::7}"
+          docker build \
+            --label "org.opencontainers.image.revision=$SHA" \
+            --label "org.opencontainers.image.created=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
+            --label "build.mode=$BUILD_MODE" \
+            -t "$IMAGE:$CONTRACTS_TAG" \
+            ./docker/.context
+          docker push "$IMAGE:$CONTRACTS_TAG"
+
+          docker tag "$IMAGE:$CONTRACTS_TAG" "$IMAGE:$CONTRACTS_TAG-$SHORT_SHA"
+          docker push "$IMAGE:$CONTRACTS_TAG-$SHORT_SHA"
+
+          if [ -n "$CONTRACTS_EXTRA" ]; then
+            docker tag "$IMAGE:$CONTRACTS_TAG" "$IMAGE:$CONTRACTS_EXTRA"
+            docker push "$IMAGE:$CONTRACTS_EXTRA"
+          fi
+
+      - name: Verify pushed contracts image
+        run: |
+          docker run --rm "dicoop/contracts:$CONTRACTS_TAG" list
+          echo "---"
+          docker run --rm "dicoop/contracts:$CONTRACTS_TAG" sha256
+
+      # === Этап 2: контейнеры приложений ===
+
+      - name: Build and push base image
+        run: |
+          docker build --target runtime -t "dicoop/mono-base:$TAG_NAME" .
+          docker push "dicoop/mono-base:$TAG_NAME"
+          if [ "$IS_PROD" = "true" ]; then
+            docker tag "dicoop/mono-base:$TAG_NAME" dicoop/mono-base:latest
+            docker push dicoop/mono-base:latest
+          fi
+
+      - name: Build and push service images
+        run: |
+          build_service() {
+            local SVC="$1" PKG="$2" CMD="$3"
+            local DOCKERFILE="Dockerfile.$SVC"
+            {
+              echo "FROM dicoop/mono-base:$TAG_NAME"
+              echo "CMD [\"pnpm\", \"-F\", \"$PKG\", \"run\", \"$CMD\"]"
+            } > "$DOCKERFILE"
+            docker build -t "dicoop/$SVC:$TAG_NAME" -f "$DOCKERFILE" .
+            docker push "dicoop/$SVC:$TAG_NAME"
+            if [ "$IS_PROD" = "true" ]; then
+              docker tag "dicoop/$SVC:$TAG_NAME" "dicoop/$SVC:latest"
+              docker push "dicoop/$SVC:latest"
+            fi
+          }
+
+          build_service desktop       '@coopenomics/desktop'        start
+          build_service coopback      '@coopenomics/controller'     start
+          # TEMP: cooparser — пока не мигрировали потребителей на dicoop/parser
+          # из отдельного coopenomics/parser repo.
+          build_service cooparser     '@coopenomics/parser'         start
+          build_service notificator   'coop-notificator'            start
+          build_service notifications '@coopenomics/notifications'  sync
+
+      # === Этап 3: webhook деплоя ===
+
+      - name: Trigger deployment webhook
+        run: |
+          curl -X POST "$WEBHOOK_URL" \
+            -H 'Content-Type: application/json' \
+            -d "$TAG_NAME"
+
+  # ============================================================================
+  # publish-packages — npm publish (бывший publish-packages.yaml).
+  # Гейт: не-alpha. Не зависит от ветки.
+  # Жёстко прибиваем версию pnpm, которой сгенерён lockfile (lockfileVersion 9.0
+  # = pnpm 9/10). Иначе action-setup может подтянуть другую версию и переписать
+  # pnpm-lock.yaml → Lerna EUNCOMMIT.
+  # ============================================================================
+  publish-packages:
+    needs: release
+    if: ${{ !contains(github.ref, '-alpha') }}
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: pnpm/action-setup@v4
+        with:
+          version: 10.33.0
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          registry-url: https://registry.npmjs.org
+          cache: pnpm
+
+      - run: pnpm install --frozen-lockfile
+      - run: pnpm lerna run build
+      - run: pnpm lerna publish from-package --yes
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+
+  # ============================================================================
+  # publish-docs — mkdocs + standards-site → gh-pages (бывший publish-docs.yaml).
+  # Гейт: не-alpha + ветка main.
+  # ВНИМАНИЕ: gh-pages step пушит на github.com/coopenomics/mono — это GitHub
+  # Pages. При переезде на Gitea Actions нужно будет либо подложить PAT для
+  # внешнего push'а в GitHub, либо переключить публикацию на Gitea Pages.
+  # ============================================================================
+  publish-docs:
+    needs: release
+    if: ${{ !contains(github.ref, '-alpha') && needs.release.outputs.branch == 'main' }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      # Версия pnpm берётся из `packageManager` корневого package.json,
+      # синхронно с publish-packages job'ом и Dockerfile'ами.
+      - name: Set up pnpm
+        uses: pnpm/action-setup@v4
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: pnpm
+
+      - name: Set up Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: '3.10'
+
+      - name: Install Python requirements
+        run: |
+          python -m venv venv
+          source venv/bin/activate
+          pip install mkdocs-material mkdocs-macros-plugin mkdocs-section-index pymdown-extensions
+        working-directory: ./components/docs
+
+      - name: Install Node.js dependencies
+        run: pnpm install
+        working-directory: ./components/docs
+
+      - name: Patch spectaql-config.yml for CI
+        run: |
+          sed -i.bak "0,/url:.*/s|url:.*|url: 'https://testnet.coopenomics.world/backend/v1/graphql'|" spectaql-config.yml
+        working-directory: ./components/controller
+
+      - name: Show patched spectaql-config.yml
+        run: cat spectaql-config.yml
+        working-directory: ./components/controller
+
+      - name: Build cooptypes
+        run: pnpm run build
+        working-directory: ./components/cooptypes
+
+      - name: Generate controller docs
+        run: pnpm run docs
+        working-directory: ./components/controller
+
+      - name: Copy controller docs
+        run: |
+          mkdir -p ./components/docs/docs/graphql
+          cp -r ./components/controller/docs/* ./components/docs/docs/graphql/
+
+      - name: Generate sdk docs
+        run: pnpm run docs
+        working-directory: ./components/sdk
+
+      - name: Copy sdk docs
+        run: |
+          mkdir -p ./components/docs/docs/sdk
+          cp -r ./components/sdk/docs/* ./components/docs/docs/sdk/
+
+      - name: Generate cooptypes docs
+        run: pnpm run docs
+        working-directory: ./components/cooptypes
+
+      - name: Copy cooptypes docs
+        run: |
+          mkdir -p ./components/docs/docs/cooptypes
+          cp -r ./components/cooptypes/docs/* ./components/docs/docs/cooptypes/
+
+      # ── standards-site → /standards/ на docs.цифровой-кооператив.рф ──
+      # Отдельный Vue-сайт с BPMN-графом кооперативных стандартов,
+      # публикуется как поддиректория на том же домене. Vite собирает
+      # с base='/standards/' (см. vite.config.ts), относительные пути
+      # внутри dist/ и hash-router работают корректно.
+      # dist кладём в docs/standards/ ДО mkdocs build — так же, как
+      # graphql/sdk/cooptypes; mkdocs сам включит его в итоговый site/.
+      - name: Build standards-site
+        run: pnpm run build
+        working-directory: ./components/contracts/standards-site
+
+      - name: Copy standards-site into docs/standards
+        run: |
+          mkdir -p ./components/docs/docs/standards
+          cp -r ./components/contracts/standards-site/dist/* ./components/docs/docs/standards/
+
+      - name: Build docs (mkdocs)
+        run: |
+          source venv/bin/activate
+          mkdocs build
+        working-directory: ./components/docs
+
+      - name: Remove specific large file before publishing
+        run: |
+          rm -f ./components/docs/site/sdk/typedoc.json
+          if [ -f "./components/docs/site/sdk/typedoc.json" ]; then
+            echo "ERROR: typedoc.json still exists!"
+            exit 1
+          else
+            echo "SUCCESS: typedoc.json removed successfully"
+          fi
+
+      - name: Publish to GitHub Pages
+        run: npx gh-pages --nojekyll -d site --repo https://x-access-token:${GITHUB_TOKEN}@github.com/coopenomics/mono.git
+        working-directory: ./components/docs
+        env:
+          GIT_AUTHOR_NAME: github-actions
+          GIT_AUTHOR_EMAIL: github-actions@github.com
+          GIT_COMMITTER_NAME: github-actions
+          GIT_COMMITTER_EMAIL: github-actions@github.com
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Trigger docs deployment webhook
+        if: ${{ success() }}
+        run: |
+          curl -X POST "${{ vars.DOCS_DEPLOY_WEBHOOK_URL }}" \
+            -H 'Content-Type: application/json' \
+            -d '{"ref":"${{ github.ref }}","sha":"${{ github.sha }}","branch":"${{ github.ref_name }}"}'
+
+  # ============================================================================
+  # trigger-coopenomics-docs — repository_dispatch в coopenomics/coopenomics
+  # (бывший build-contracts-docs.yaml). Гейт идентичен publish-docs.
+  # ============================================================================
+  trigger-coopenomics-docs:
+    needs: release
+    if: ${{ !contains(github.ref, '-alpha') && needs.release.outputs.branch == 'main' }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: Trigger Coopenomics deployment
+        uses: peter-evans/repository-dispatch@v2
+        with:
+          token: ${{ secrets.COOPENOMICS_PAT }}
+          repository: coopenomics/coopenomics
+          event-type: deploy_from_mono
+          client-payload: '{"repository": "${{ github.repository }}", "sha": "${{ github.sha }}", "ref": "${{ github.ref }}", "actor": "${{ github.actor }}"}'

.github/workflows/typecheck.yaml

@@ -0,0 +1,96 @@
+name: Typecheck
+
+# Валидация TypeScript-типов для desktop (Vue 3 + Quasar) и controller (NestJS).
+#
+# Зачем это отдельный workflow:
+#  1. `quasar build --mode ssr` в release.yaml использует Vite/esbuild и
+#     vue-tsc отключён через vite-plugin-checker (см. quasar.config.cjs):
+#     TS-ошибки в .vue/.ts НЕ ловятся при docker build образа desktop.
+#  2. У `@coopenomics/controller` нет build-скрипта вовсе — `lerna run build`
+#     его молча пропускает; в проде `ts-node` стартует и валится на типах
+#     только в рантайме при загрузке модуля. Кейс PR #392 (rename 1080→1020
+#     в cooptypes) проскочил именно так.
+#
+# Триггеры:
+#  - pull_request на dev — гейт перед мерджем в основную ветку;
+#  - workflow_call — переиспользуется из release.yaml как `needs:` у release-job,
+#    чтобы битый тэг не уехал в DockerHub.
+#
+# Push в dev/testnet/main НЕ триггерит — намеренно (PR-гейт достаточен,
+# а тэги покрывает workflow_call из release.yaml).
+
+on:
+  pull_request:
+    branches: [dev]
+  workflow_call:
+
+jobs:
+  desktop:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: pnpm/action-setup@v4
+        with:
+          version: 10.33.0
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: pnpm
+
+      - name: Install workspace
+        run: pnpm install --frozen-lockfile
+
+      # Полный lerna build по всему workspace — как в корневом Dockerfile.
+      # Не --scope, потому что workspace-пакеты unbuild-типа (sdk, inter,
+      # notifications, factory, cooptypes, …) экспортируют типы только из
+      # сгенерированного dist/. Без dist/ tsc/vue-tsc валятся на TS2307
+      # «Cannot find module». Локально это маскируется ts-node-ом, но в
+      # CI пути резолвятся через package.json → types → dist/.
+      # См. Graphiti / run #148 root cause 2026-05-23.
+      - name: Build all workspace packages
+        run: pnpm lerna run build
+
+      # quasar prepare генерирует .quasar/* (auto-imports d.ts, типы для
+      # quasar плагинов). Без него vue-tsc ругается на отсутствующие
+      # глобальные компоненты QBtn/QCard/etc.
+      - name: Quasar prepare
+        run: pnpm --filter @coopenomics/desktop run prepare
+
+      # vue-tsc проверяет и .ts, и <script lang="ts"> в .vue.
+      # --skipLibCheck — иначе валится на типах из транзитивных deps
+      # (Quasar/Vue/Vite сами по себе чистые, но в графе есть legacy).
+      # Из памяти: на dev-сервере висло ~час из-за конкуренции с quasar dev;
+      # на чистом ubuntu-latest без живого стека ожидаемо в разы быстрее.
+      # Если упрётся в OOM/таймаут — fallback на `pnpm typecheck`
+      # (tsc --noEmit --skipLibCheck без vue-tsc, без SFC шаблонов).
+      - name: vue-tsc (desktop)
+        run: pnpm --filter @coopenomics/desktop exec vue-tsc --noEmit --skipLibCheck
+
+  controller:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: pnpm/action-setup@v4
+        with:
+          version: 10.33.0
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: pnpm
+
+      - name: Install workspace
+        run: pnpm install --frozen-lockfile
+
+      # Полный lerna build по всему workspace — controller импортирует
+      # @coopenomics/sdk, @coopenomics/inter, @coopenomics/notifications
+      # помимо cooptypes/factory; их dist/ генерируется unbuild и без
+      # этого шага tsc валится на 37 TS2307. См. root cause выше.
+      - name: Build all workspace packages
+        run: pnpm lerna run build
+
+      - name: tsc --noEmit (controller)
+        run: pnpm --filter @coopenomics/controller run typecheck

.gitignore

@@ -0,0 +1,24 @@
+node_modules/
+lerna-debug.log
+components/controller/graph.png
+blockchain-data/
+scripts/changelog-prompt.md
+scripts/changelog-release.md
+scripts/release-info.md
+components/docs/docs/sdk
+dist/
+.env
+.DS_Store
+_blago/
+blago/
+components/reports-standarts/ВОСХОД/
+# Реальные XML-образцы отчётности ПК "Восход" (ИНН 9728130611, рег.СФР 1118018397)
+# могут появляться в любых подпапках reports-standarts/ — не пушим.
+components/reports-standarts/**/NO_*_9728130611772801001_*.xml
+components/reports-standarts/**/СФР_1118018397_*.xml
+
+# Output files for local audit scripts (ledger2 migration)
+components/contracts/cpp/ledger2/scripts/out/
+
+.env.testnet
+.pnpm-store

.npmrc

@@ -0,0 +1,7 @@
+store-dir=./.pnpm-store
+supported-architectures.os[]=darwin
+supported-architectures.os[]=linux
+supported-architectures.cpu[]=x64
+supported-architectures.cpu[]=arm64
+supported-architectures.libc[]=glibc
+

.prettierrc

@@ -0,0 +1,8 @@
+{
+  "semi": false,
+  "singleQuote": true,
+  "printWidth": 120,
+  "plugins": [
+    "prettier-plugin-sort-imports"
+  ]
+}

.vscode/extensions.json

@@ -0,0 +1,7 @@
+{
+  "recommendations": [
+    "vue.volar",
+    "vue.vscode-typescript-vue-plugin"
+  ]
+}
+

.vscode/settings.json

@@ -0,0 +1,74 @@
+{
+  "editor.bracketPairColorization.enabled": true,
+  "editor.guides.bracketPairs": true,
+  "editor.tabCompletion": "onlySnippets",
+  "editor.defaultFormatter": "esbenp.prettier-vscode",
+  "eslint.run": "onType",
+  "eslint.validate": ["javascript", "typescript", "vue"],
+  "i18n-ally.localesPaths": ["src/i18n"],
+  "typescript.format.enable": true,
+  "typescript.format.indentSwitchCase": false,
+  "typescript.validate.enable": true,
+  "notebook.defaultFormatter": "Vue.volar",
+  
+  // Оптимизация для монорепозитория
+  "typescript.preferences.useAliasesForRenames": false,
+  "typescript.preferences.includePackageJsonAutoImports": "on",
+  "typescript.suggest.autoImports": true,
+  "typescript.suggest.paths": true,
+  "typescript.updateImportsOnFileMove.enabled": "always",
+  "typescript.workspaceSymbols.scope": "currentProject",
+  
+  // Настройки для снижения нагрузки
+  "files.watcherExclude": {
+    "**/node_modules/**": true,
+    "**/dist/**": true,
+    "**/.git/objects/**": true,
+    "**/.git/subtree-cache/**": true,
+    "**/node_modules/*/**": true,
+    "**/.cache/**": true,
+    "**/.quasar/**": true,
+    "**/*.tsbuildinfo": true
+  },
+  
+  "search.exclude": {
+    "**/node_modules": true,
+    "**/dist": true,
+    "**/.cache": true,
+    "**/.quasar": true,
+    "**/*.tsbuildinfo": true
+  },
+  
+  "files.exclude": {
+    "**/.cache": true,
+    "**/*.tsbuildinfo": true,
+    "**/node_modules/.cache": true
+  },
+  
+  // TypeScript server настройки для монорепозитория
+  "typescript.tsserver.maxTsServerMemory": 8192,
+  "typescript.tsserver.watchOptions": {
+    "excludeDirectories": [
+      "**/node_modules",
+      "**/dist",
+      "**/.cache",
+      "**/.quasar",
+      "**/build"
+    ]
+  },
+  
+  // Использовать локальный TypeScript из монорепо
+  "typescript.tsdk": "node_modules/typescript/lib",
+  "typescript.enablePromptUseWorkspaceTsdk": true,
+  
+  // КРИТИЧЕСКИ ВАЖНО: включить project references для монорепозитория
+  "typescript.tsserver.useSyntaxServer": "auto",
+  "typescript.tsserver.experimental.enableProjectDiagnostics": true,
+  
+  // Оптимизация для больших монорепозиториев
+  "typescript.disableAutomaticTypeAcquisition": true,
+  "typescript.surveys.enabled": false,
+  "[typescript]": {
+    "editor.defaultFormatter": "vscode.typescript-language-features"
+  }
+}

AGENTS.md

@@ -0,0 +1,87 @@
+# AGENTS.md
+
+## Cursor Cloud specific instructions
+
+### Обзор
+
+Монорепозиторий «Цифровой Кооператив» (monocoop) — платформа управления кооперативами на блокчейне EOSIO. pnpm v9 + Lerna. Node.js v20.
+
+### Сервисы
+
+| Компонент | Контейнер | Порт | Описание |
+|-----------|-----------|------|----------|
+| controller | coopback | 2998 | NestJS GraphQL API |
+| desktop | desktop | 2999 | Vue 3 + Quasar SPA |
+| parser | cooparser | 4000 | Индексация блокчейна через SHiP |
+| blockchain | node | 8888, 8070 | EOSIO node + State History Plugin |
+| MongoDB | mongo | 27017 | Основная БД (replica set) |
+| Redis | monoredis | 6379 | Кэш и стримы |
+| PG | (см. compose) | 5532→5432 | Реляционная БД |
+
+### Полный перезапуск (одна команда)
+
+```
+pnpm run reboot
+```
+
+Делает: останавливает контейнеры → чистит blockchain data и volumes → поднимает инфру → ждёт готовности → `pnpm run boot` → запускает parser и controller.
+
+### Первоначальная настройка Cloud-окружения
+
+1. **`/etc/hosts`** — обязательно для boot (запускается на хосте, обращается к MongoDB по docker hostname):
+   ```
+   echo "127.0.0.1 mongo" | sudo tee -a /etc/hosts
+   echo "127.0.0.1 monoredis" | sudo tee -a /etc/hosts
+   ```
+
+2. **WeasyPrint** — системная зависимость для генерации PDF:
+   ```
+   sudo apt-get install -y python3 python3-venv libpango-1.0-0 libcairo2 libffi-dev libjpeg-dev libopenjp2-7-dev libharfbuzz-dev
+   sudo python3 -m venv /opt/weasyprint-venv && sudo /opt/weasyprint-venv/bin/pip install WeasyPrint==67
+   sudo ln -sf /opt/weasyprint-venv/bin/weasyprint /usr/local/bin/weasyprint
+   ```
+
+3. **Контракты** (test-режим — позволяет boot с 1 членом совета):
+   ```
+   cd components/contracts && sudo rm -rf build && bash build-all.sh test
+   ```
+
+4. **Shared-библиотеки** (порядок важен):
+   ```
+   pnpm --filter cooptypes run build
+   pnpm --filter @coopenomics/factory run build
+   pnpm --filter @coopenomics/sdk run build
+   pnpm --filter @coopenomics/notifications run build
+   ```
+
+5. **`.env` файлы** — скопировать из `.env-example`, адаптировать hostnames:
+   - Controller/Parser (в Docker): хосты по именам контейнеров из docker-compose (порт БД 5432)
+   - Boot (на хосте): `127.0.0.1`, PG порт `5532`, mongo через `/etc/hosts`
+   - Desktop: `127.0.0.1`
+   - Controller: `BACKEND_URL` (публичный URL API) и `FRONTEND_URL` (публичный URL SPA), см. `components/controller/.env-example`
+   - **CHAIN_ID**: берётся из `curl http://localhost:8888/v1/chain/get_info` после старта ноды
+   - Controller требует `VAPID_PUBLIC_KEY` и `VAPID_PRIVATE_KEY`
+
+6. **Запуск**: `pnpm run reboot`, затем `docker compose up -d --force-recreate coopback cooparser` (если .env менялись)
+
+### Запуск тестов
+
+- **Factory** (`components/factory`): нужен только MongoDB. Запуск:
+  ```
+  NODE_ENV=test SOURCE=local MONGO_URI=$MONGO_URI SKIP_BLOCK_FETCH=TRUE pnpm --filter @coopenomics/factory test
+  ```
+  `MONGO_URI` по умолчанию: `mongodb://<host>:27017/cooperative-x`.
+- **Boot** (`components/boot`): требует полный EOSIO blockchain + MongoDB + PG. Запуск после `pnpm run reboot`:
+  ```
+  pnpm --filter @coopenomics/boot test
+  ```
+- **Duplicate transaction** — в boot-тестах EOSIO отклоняет транзакции с одинаковым хешем (TAPOS block + action data). При повторном вызове `refreshSegment` для того же участника — добавить `await sleep(500)` перед ним. Паттерн уже используется (см. комментарий на строке ~720 capital.test.ts).
+
+### Критические gotchas
+
+- **SHiP порт 8070** — `state-history-endpoint = 0.0.0.0:8070` в config.ini. Парсер: `SHIP=ws://node:8070`.
+- **Парсер START_BLOCK**: при `START_BLOCK=1` на чистой БД стартует с HEAD и делает частичную инициализацию. Для полного replay: временно `START_BLOCK=2`, после первого запуска вернуть `1`.
+- **SSR desktop в dev** — расширения не рендерятся из-за Pinia SSR-сериализации компонентов. Dev — SPA (`quasar dev`), production build SSR работает.
+- **Тестовые учётные данные**: email `ivanov@example.com`, ключ — дефолтный EOSIO dev key (см. `components/boot/.env-example`), пользователь `ant` (председатель).
+- **Docker hostnames**: без `network_mode: host` — контейнеры обращаются друг к другу по именам контейнеров из docker-compose.
+- **Установка пакетов**: только через фильтр — `pnpm add <pkg> --filter <component>`.

CHANGELOG.md

@@ -0,0 +1,566 @@
+# v2026.4.2-2
+
+В этом релизе — стабилизация Благороста для вывода в продуктивную работу с результатами интеллектуальной деятельности. Отдельно заложена основа под отчётность в ФНС и ФСС и прототип поиска по документам.
+
+**Благорост и проекты**
+
+- Быстрые действия на странице программы: создать проект, компонент, задачу или требование.
+- Требования к компонентам в репозитории: поддержка **Mermaid**, **Draw.io** и **BPMN**.
+- Синхронизация проектов, компонентов, требований и задач с Git-репозиторием результатов.
+- Встраивание полноразмерного видео (iframe) на страницах проектов.
+- Скачивание пакета подписанных документов одной кнопкой.
+- Комнаты проектов в кооперативном мессенджере.
+
+**Мессенджер и звонки**
+
+- Автосекретарь: запись синхронных звонков, текстовых и голосовых сообщений в проектных комнатах.
+
+**Отчётность и инфраструктура**
+
+- Прототип фабрики отчётов ФНС/ФСС: выгрузка в XML для дальнейшей отправки.
+- Прототип поисковой системы по документам.
+- Установщик для развёртывания на своих серверах (разработка или эксплуатация).
+- Рефакторинг в сторону чистой архитектуры на бэкенде.
+- Ускорение сборки фронтенда за счёт перехода на **Vite 8**.
+
+**Исправления**
+
+- Повторное общее собрание больше не мешало завершить онбординг кооператива.
+- Центр уведомлений не блокировал загрузку рабочего стола при отключённом провайдере оповещений.
+- Уведомления о собрании совета по свободным вопросам снова доходят до членов совета.
+- В интерфейсе восстановлено отображение контактов кооператива.
+
+#releases
+
+---
+
+# v2026.4.2-2
+
+В этом релизе — стабилизация Благороста для вывода в продуктивную работу с результатами интеллектуальной деятельности. Отдельно заложена основа под отчётность в ФНС и ФСС и прототип поиска по документам.
+
+**Благорост и проекты**
+
+- Быстрые действия на странице программы: создать проект, компонент, задачу или требование.
+- Требования к компонентам в репозитории: поддержка **Mermaid**, **Draw.io** и **BPMN**.
+- Синхронизация проектов, компонентов, требований и задач с Git-репозиторием результатов.
+- Встраивание полноразмерного видео (iframe) на страницах проектов.
+- Скачивание пакета подписанных документов одной кнопкой.
+- Комнаты проектов в кооперативном мессенджере.
+
+**Мессенджер и звонки**
+
+- Автосекретарь: запись синхронных звонков, текстовых и голосовых сообщений в проектных комнатах.
+
+**Отчётность и инфраструктура**
+
+- Прототип фабрики отчётов ФНС/ФСС: выгрузка в XML для дальнейшей отправки.
+- Прототип поисковой системы по документам.
+- Установщик для развёртывания на своих серверах (разработка или эксплуатация).
+- Рефакторинг в сторону чистой архитектуры на бэкенде.
+- Ускорение сборки фронтенда за счёт перехода на **Vite 8**.
+
+**Исправления**
+
+- Повторное общее собрание больше не мешало завершить онбординг кооператива.
+- Центр уведомлений не блокировал загрузку рабочего стола при отключённом провайдере оповещений.
+- Уведомления о собрании совета по свободным вопросам снова доходят до членов совета.
+- В интерфейсе восстановлено отображение контактов кооператива.
+
+#releases
+
+---
+
+# v2025.12.28-8
+
+В этой версии представлен прототип трекера результатов интеллектуальной деятельности, реализован мост в 1С, обновлен интерфейс и существенно повышена стабильность системы.
+
+---
+
+### ✨ Новые функции
+- [#332](https://github.com/coopenomics/mono/issues/332): Прототип конструктора требований дополнительных документов при регистрации
+- [#330](https://github.com/coopenomics/mono/issues/330): Прототип моста в 1С:Бухгалтерию для передачи документов и проводок
+- [#329](https://github.com/coopenomics/mono/issues/329): Интеграция и тестирование LMS TUTOR для образовательных задач
+- [#328](https://github.com/coopenomics/mono/issues/328): Размещение прототипов мульти-лендингов на цифровой-кооператив.рф и coopenomics.world
+- [#326](https://github.com/coopenomics/mono/issues/326): Минимальный интерфейс трекера результатов интеллектуальной деятельности
+- [#324](https://github.com/coopenomics/mono/issues/324): Смарт-контракт генерации и капитализации результатов интеллектуальной деятельности ("Благорост")
+- [#322](https://github.com/coopenomics/mono/issues/322): Поставка обновлений ПО с нулевым даунтаймом по blue-green стратегии
+- [#321](https://github.com/coopenomics/mono/issues/321): Внедрение системы проводок по фондам для контрактов
+- [#319](https://github.com/coopenomics/mono/issues/319): Палитра команд и быстрый доступ к страницам рабочих столов (cmk+k)
+- [#316](https://github.com/coopenomics/mono/issues/316): Переход рабочего стола на GraphQL SDK
+- [#314](https://github.com/coopenomics/mono/issues/314): Развёртывание GlitchTip для мониторинга ошибок
+- [#306](https://github.com/coopenomics/mono/issues/306): Модуль запросов и мутаций для контракта капитализации
+
+### 🐛 Исправления ошибок
+- [#312](https://github.com/coopenomics/mono/issues/312): Исправление подписки на изменение статуса коммитов
+- [#309](https://github.com/coopenomics/mono/issues/309): Исправление отображения чужих билетов времени в трекере
+
+### 🔧 Улучшения
+- [#331](https://github.com/coopenomics/mono/issues/331): Настройка системы мониторинга сбоев и ошибок на базе GlitchTIP, Loki, Prometheus
+- [#327](https://github.com/coopenomics/mono/issues/327): Пользовательская документация по интерфейсам цифрового кооператива
+- [#325](https://github.com/coopenomics/mono/issues/325): Документирование смарт-контракта программы "Благорост"
+- [#308](https://github.com/coopenomics/mono/issues/308): Улучшение отображения рабочих столов в магазине приложений
+- [#307](https://github.com/coopenomics/mono/issues/307): Объединение настроек контракта с нативными настройками приложения
+- [#305](https://github.com/coopenomics/mono/issues/305): Объединение полей title и description в проекте
+- [#304](https://github.com/coopenomics/mono/issues/304): Доменная модель контракта капитализации на бэкенде
+- [#303](https://github.com/coopenomics/mono/issues/303): Пересмотр архитектуры парсера и формирования локальной истории
+- [#302](https://github.com/coopenomics/mono/issues/302): Рефакторинг архитектуры, внедрение двухконтурной шины данных и обработки микрофорков
+- [#301](https://github.com/coopenomics/mono/issues/301): Доработка и отладка контракта "Капитализация РИД" v0.2
+- [#222](https://github.com/coopenomics/mono/issues/222): Внедрение метода Водянова для распределения пула премий по программе "Благорост"
+- [#212](https://github.com/coopenomics/mono/issues/212): Снижение точности валютных значений до двух знаков после запятой в документах
+
+#releases
+
+---
+
+# v2025.12.28
+
+В этой версии представлен прототип трекера результатов интеллектуальной деятельности, реализован мост в 1С, обновлен интерфейс и существенно повышена стабильность системы.
+
+---
+
+### ✨ Новые функции
+- [#332](https://github.com/coopenomics/mono/issues/332): Прототип конструктора требований дополнительных документов при регистрации
+- [#330](https://github.com/coopenomics/mono/issues/330): Прототип моста в 1С:Бухгалтерию для передачи документов и проводок
+- [#329](https://github.com/coopenomics/mono/issues/329): Интеграция и тестирование LMS TUTOR для образовательных задач
+- [#328](https://github.com/coopenomics/mono/issues/328): Размещение прототипов мульти-лендингов на цифровой-кооператив.рф и coopenomics.world
+- [#326](https://github.com/coopenomics/mono/issues/326): Минимальный интерфейс трекера результатов интеллектуальной деятельности
+- [#324](https://github.com/coopenomics/mono/issues/324): Смарт-контракт генерации и капитализации результатов интеллектуальной деятельности ("Благорост")
+- [#322](https://github.com/coopenomics/mono/issues/322): Поставка обновлений ПО с нулевым даунтаймом по blue-green стратегии
+- [#321](https://github.com/coopenomics/mono/issues/321): Внедрение системы проводок по фондам для контрактов
+- [#319](https://github.com/coopenomics/mono/issues/319): Палитра команд и быстрый доступ к страницам рабочих столов (cmk+k)
+- [#316](https://github.com/coopenomics/mono/issues/316): Переход рабочего стола на GraphQL SDK
+- [#314](https://github.com/coopenomics/mono/issues/314): Развёртывание GlitchTip для мониторинга ошибок
+- [#306](https://github.com/coopenomics/mono/issues/306): Модуль запросов и мутаций для контракта капитализации
+
+### 🐛 Исправления ошибок
+- [#312](https://github.com/coopenomics/mono/issues/312): Исправление подписки на изменение статуса коммитов
+- [#309](https://github.com/coopenomics/mono/issues/309): Исправление отображения чужих билетов времени в трекере
+
+### 🔧 Улучшения
+- [#331](https://github.com/coopenomics/mono/issues/331): Настройка системы мониторинга сбоев и ошибок на базе GlitchTIP, Loki, Prometheus
+- [#327](https://github.com/coopenomics/mono/issues/327): Пользовательская документация по интерфейсам цифрового кооператива
+- [#325](https://github.com/coopenomics/mono/issues/325): Документирование смарт-контракта программы "Благорост"
+- [#308](https://github.com/coopenomics/mono/issues/308): Улучшение отображения рабочих столов в магазине приложений
+- [#307](https://github.com/coopenomics/mono/issues/307): Объединение настроек контракта с нативными настройками приложения
+- [#305](https://github.com/coopenomics/mono/issues/305): Объединение полей title и description в проекте
+- [#304](https://github.com/coopenomics/mono/issues/304): Доменная модель контракта капитализации на бэкенде
+- [#303](https://github.com/coopenomics/mono/issues/303): Пересмотр архитектуры парсера и формирования локальной истории
+- [#302](https://github.com/coopenomics/mono/issues/302): Рефакторинг архитектуры, внедрение двухконтурной шины данных и обработки микрофорков
+- [#301](https://github.com/coopenomics/mono/issues/301): Доработка и отладка контракта "Капитализация РИД" v0.2
+- [#222](https://github.com/coopenomics/mono/issues/222): Внедрение метода Водянова для распределения пула премий по программе "Благорост"
+- [#212](https://github.com/coopenomics/mono/issues/212): Снижение точности валютных значений до двух знаков после запятой в документах
+
+#releases
+
+---
+
+# v2025.12.28
+
+В этом релизе реализован смарт-контракт генерации и капитализации результатов интеллектуальной деятельности, завершена интеграция с учётными системами, улучшены интерфейсы и документация. Подробнее о контракте: https://coopenomics.world/contracts/group__public__capital.html
+
+✨ Новые функции
+- [#324](https://github.com/coopenomics/mono/issues/324): Реализован смарт-контракт генерации и капитализации результатов интеллектуальной деятельности ("Благорост")
+- [#301](https://github.com/coopenomics/mono/issues/301): Контракт "Капитализация РИД" v0.2
+- [#330](https://github.com/coopenomics/mono/issues/330): Прототип моста в 1С:Бухгалтерию: выгрузка документов и проводки по счетам
+- [#322](https://github.com/coopenomics/mono/issues/322): Обновления ПО с нулевым даунтаймом по blue-green стратегии
+- [#319](https://github.com/coopenomics/mono/issues/319): Палитра команд и быстрый доступ к страницам рабочих столов (cmk+k)
+- [#308](https://github.com/coopenomics/mono/issues/308): Магазин приложений с поддержкой подключения нескольких рабочих столов одним приложением
+- [#326](https://github.com/coopenomics/mono/issues/326): Минимальный интерфейс трекера результатов интеллектуальной деятельности по программе "Благорост"
+- [#332](https://github.com/coopenomics/mono/issues/332): Прототип конструктора требований дополнительных документов при регистрации
+
+🐛 Исправления ошибок
+- [#312](https://github.com/coopenomics/mono/issues/312): Исправлена ошибка со статусом коммитов — подписка теперь работает корректно
+- [#309](https://github.com/coopenomics/mono/issues/309): Исправлен баг с отображением чужих билетов времени в трекере
+
+🔧 Улучшения
+- [#325](https://github.com/coopenomics/mono/issues/325): Документирован смарт-контракт программы "Благорост"
+- [#327](https://github.com/coopenomics/mono/issues/327): Подготовлена пользовательская документация цифрового кооператива по интерфейсам
+- [#329](https://github.com/coopenomics/mono/issues/329): Интеграция и тестирование образовательной платформы LMS TUTOR на Wordpress
+- [#328](https://github.com/coopenomics/mono/issues/328): Размещены прототипы мульти-лендингов на цифровой-кооператив.рф и coopenomics.world
+- [#321](https://github.com/coopenomics/mono/issues/321): Встроена система проводок по фондам и интеграция с контрактами
+- [#318](https://github.com/coopenomics/mono/issues/318): Настроены Loki & Grafana для выгрузки логов из контейнеров
+- [#316](https://github.com/coopenomics/mono/issues/316): Завершён переход рабочего стола на GraphQL SDK
+- [#314](https://github.com/coopenomics/mono/issues/314): Развёрнут GlitchTip как альтернатива Sentry
+- [#307](https://github.com/coopenomics/mono/issues/307): Интеграция настроек контракта с нативными настройками приложения, поддержка импорта после конфигурации
+- [#306](https://github.com/coopenomics/mono/issues/306): Собран модуль запросов и мутаций контракта капитализации
+- [#305](https://github.com/coopenomics/mono/issues/305): Упрощена структура проекта — title & description объединены в одно поле
+- [#304](https://github.com/coopenomics/mono/issues/304): Реализована доменная модель контракта капитализации на бэкенде с поддержкой микрофорков
+- [#303](https://github.com/coopenomics/mono/issues/303): Пересмотрена архитектура парсера и формирования локальной истории
+- [#302](https://github.com/coopenomics/mono/issues/302): Рефакторинг архитектуры, реализована двухконтурная шина данных и обработка микрофорков
+- [#212](https://github.com/coopenomics/mono/issues/212): Уменьшена точность валютных значений в документах с четырёх до двух знаков
+
+#releases
+
+---
+
+# v2025.9.1
+
+В системе Кооперативной Экономики развернут смарт-контракт CAPITAL v0.2  для генерации и капитализации результатов интеллектуальной деятельности. Контракт описывает и обеспечивает:
+- бизнес-процесс производства результатов интеллектуальной деятельности в кооперативах создателями, авторами, инвесторами, координаторами, мастерами и собственниками имущества в кооперации на проектах;
+- приём результатов интеллектуальной деятельности в качестве паевых взносов в кооператив;
+- распределение потока членских взносов среди вкладчиков;
+- капитализацию результатов интеллектуальной деятельности новыми результатами по модели золотого сечения;
+- оценку вкладов авторов и создателей по методу Водянова;
+
+В основе математической модели контракта лежит принцип распределения справедливой выгоды между вкладчиками согласно концепции "Общественно-полезного времени", разработанной в рамках теорий Кузнецова и академика Глушкова при работе над проектом общегосударственной автоматизированной системы учета и обработки информации (ОГАС).
+
+Подробнее в документации: https://coopenomics.world/contracts/group__public__capital.html
+
+✨ Новые функции
+- [#301](https://github.com/coopenomics/mono/issues/301): Реализация контракта "Капитализация" v0.2: регистрация вкладчиков, создание и управление проектами, поддержка инвестиций, ссуд, членских взносов, проведение голосований, расчет капитализации, интеграция с внешними контрактами, поддержка импорта данных.
+
+#releases
+
+---
+
+# v2025.7.1-1
+
+В этом релизе реализованы механизмы возврата паевого взноса пайщика и инструменты управления этим процессом для членов совета. Также внесены визуальные доработки интерфейсов для улучшения восприятия информации.
+
+✨ Новые функции
+- [#276](https://github.com/coopenomics/mono/issues/276): Реализовать путь возврата паевого взноса из кошелька пайщика
+- [#281](https://github.com/coopenomics/mono/issues/281): Генерация заявления на возврат паевого взноса
+- [#282](https://github.com/coopenomics/mono/issues/282): Генерация решения совета на возврат паевого взноса
+- [#278](https://github.com/coopenomics/mono/issues/278): Введение методов управления возвратами паевых взносов в контроллере
+- [#279](https://github.com/coopenomics/mono/issues/279): Отобразить исходящие платежи с кнопками управления в реестре платежей для совета
+
+🐛 Исправления ошибок
+- [#286](https://github.com/coopenomics/mono/issues/286): Поправить ошибки склонений времени
+- [#262](https://github.com/coopenomics/mono/issues/262): Баг: рабочий стол совета включается, однако, страница всегда открывается со стола пайщика
+- [#261](https://github.com/coopenomics/mono/issues/261): Баг: первая загрузка переадресует на главную страницу всегда - прямой переход на собрание становится недоступен.
+
+🔧 Улучшения
+- [#285](https://github.com/coopenomics/mono/issues/285): Корректировка дизайна кошелька, профиля, повестки совета, реестра документов, реестра платежей
+- [#284](https://github.com/coopenomics/mono/issues/284): Разместить кошелек на главную вместо профиля
+- [#283](https://github.com/coopenomics/mono/issues/283): Ввести лоадер на переходе между рабочими столами
+- [#280](https://github.com/coopenomics/mono/issues/280): Мигрировать имеющиеся данные о входящих платежах в новую модель
+- [#277](https://github.com/coopenomics/mono/issues/277): Рефакторинг модуля платежей: переход на унифицированную модель входящего и исходящего платежа
+
+#releases
+
+---
+
+# v2025.6.14
+
+Разработан модуль для проведения очередных общих собраний пайщиков. Исправлены баги, внесены улучшения пользовательского интерфейса.
+
+✨ Новые функции
+- [#264](https://github.com/coopenomics/mono/issues/264): Разработан смарт-контракт общего собрания пайщиков (meet)
+- [#263](https://github.com/coopenomics/mono/issues/263): Реализован модуль оповещений на электронные почты по жизненному циклу общего собрания пайщиков
+- [#273](https://github.com/coopenomics/mono/issues/273): Встроены реальные шаблоны документов общего собрания
+- [#268](https://github.com/coopenomics/mono/issues/268): Добавлена страница результатов общего собрания
+- [#267](https://github.com/coopenomics/mono/issues/267): Добавлена страница просмотра и скачивания бюллетеней и уведомлений по собранию
+- [#270](https://github.com/coopenomics/mono/issues/270): Ссылка в оповещении ведет на страницу собрания с документом-уведомлением для подписи
+
+🐛 Исправления ошибок
+- [#262](https://github.com/coopenomics/mono/issues/262): Исправлено некорректное открытие рабочего стола совета
+- [#261](https://github.com/coopenomics/mono/issues/261): Исправлена ошибка с редиректом при первой загрузке и прямом переходе на собрание
+- [#259](https://github.com/coopenomics/mono/issues/259): Исправлены отступы в мобильной карточке пайщика
+- [#258](https://github.com/coopenomics/mono/issues/258): Убран hover-эффект на документе и пайщике в таблице
+
+🔧 Улучшения
+- [#274](https://github.com/coopenomics/mono/issues/274): Настроена рассылка оповещений на почту при получении решения о проведении собрания
+- [#272](https://github.com/coopenomics/mono/issues/272): Подписанные уведомления сохраняются и извлекаются из реестра по Graph-QL
+- [#271](https://github.com/coopenomics/mono/issues/271): Ведется подсчет количества пайщиков в каждом кооперативе при добавлении и удалении
+- [#260](https://github.com/coopenomics/mono/issues/260): Введен счетчик количества пайщиков в кооперативе на контракте регистратора
+- [#256](https://github.com/coopenomics/mono/issues/256): Отображается статус членства каждого пайщика
+- [#255](https://github.com/coopenomics/mono/issues/255): В разделе Платежи отображается ФИО/Наименование плательщика
+- [#269](https://github.com/coopenomics/mono/issues/269): Реализована рассылка уведомлений перед началом собрания
+- [#265](https://github.com/coopenomics/mono/issues/265): Проведена отладка и тестирование процесса общего собрания пайщиков
+- [#266](https://github.com/coopenomics/mono/issues/266): Протестированы все процессы общего собрания
+
+#releases
+
+---
+
+# v2025.5.14
+
+В этом релизе реализован новый стандарт передачи и хранения документов по блокчейну с поддержкой неограниченного количества подписей и их валидацией. Также внесены улучшения в интерфейс и исправлены ошибки.
+
+✨ Новые функции
+- [#252](https://github.com/coopenomics/mono/issues/252): Внедрение обновленного стандарта хранения и передачи документов по блокчейну
+- [#251](https://github.com/coopenomics/mono/issues/251): Реализация версионированного мигратора данных для контроллера кооператива
+- [#244](https://github.com/coopenomics/mono/issues/244): Обновление стандарта сборки документов и переход на хэш-идентификаторы
+
+🐛 Исправления ошибок
+- [#249](https://github.com/coopenomics/mono/issues/249): Исправлена спутанная маршрутизация между рабочими столами кооперативов
+- [#253](https://github.com/coopenomics/mono/issues/253): Исправлена избыточная точность суммы оплаты в заявлении на вступление
+
+🔧 Улучшения
+- [#259](https://github.com/coopenomics/mono/issues/259): Исправлены отступы в мобильной карточке пайщика на странице пайщиков
+- [#258](https://github.com/coopenomics/mono/issues/258): Удалён hover-эффект для документов и пайщиков в таблице
+- [#257](https://github.com/coopenomics/mono/issues/257): Добавлено сохранение светлой/тёмной темы в localStorage и восстановление при загрузке страницы
+- [#256](https://github.com/coopenomics/mono/issues/256): Отображение статуса членства каждого пайщика в разделе "Пайщики"
+- [#255](https://github.com/coopenomics/mono/issues/255): Отображение ФИО/Наименования плательщика в разделе "Платежи"
+
+#releases
+
+---
+
+# v2025.5.2
+
+В этом релизе рабочие столы переведены на серверный рендеринг, что улучшает стабильность развертывания и упрощает автоматизацию поставки ПО. Данный релиз является подготовительным к переходу на новый стандарт цифровых документов на платформе.
+
+✨ Новые функции
+- [#245](https://github.com/coopenomics/mono/issues/245): Перевод десктопа на серверный рендеринг с поддержкой динамических переменных окружения
+
+🐛 Исправления ошибок
+- [#247](https://github.com/coopenomics/mono/issues/247): Исправлен баг с повторной поставкой ПО при обрывах соединения между серверами
+
+🔧 Улучшения
+- [#246](https://github.com/coopenomics/mono/issues/246): Перевод CI/CD на сборку и поставку предсобранных докер-контейнеров
+
+#releases
+
+---
+
+# MONO v2025.4.29
+
+В этом релизе реализована новая архитектура рабочих столов с установкой через маркетплейс. Добавлены стол пайщика и стол совета, переработаны разделы документов и подписей, улучшено разделение кошелька и профиля для повышения удобства пользователей.
+
+✨ Новые функции
+- [#234](https://github.com/coopenomics/mono/issues/234): Маркетплейс рабочих столов с поддержкой разных ролей и микросервисной архитектурой
+- [#238](https://github.com/coopenomics/mono/issues/238): Контроллер общего собрания пайщиков с поддержкой документооборота и подписей
+- [#233](https://github.com/coopenomics/mono/issues/233): Минимальный смарт-контракт общих собраний пайщиков
+- [#232](https://github.com/coopenomics/mono/issues/232): Бэкенд полного обозревателя блоков
+
+🐛 Исправления ошибок
+- [#231](https://github.com/coopenomics/mono/issues/231): Исправления ошибок регистрации, выхода из системы, отображения платежей и редактирования организации
+
+🔧 Улучшения
+- [#243](https://github.com/coopenomics/mono/issues/243): Контроль прав доступа на получении документов пайщика
+- [#242](https://github.com/coopenomics/mono/issues/242): Бесконечный скролл на документах пайщика и кооператива
+- [#241](https://github.com/coopenomics/mono/issues/241): Раздел "Документы" для пайщика
+- [#240](https://github.com/coopenomics/mono/issues/240): Множественные подписи на одном документе
+- [#239](https://github.com/coopenomics/mono/issues/239): Последовательные методы подписи протокола общего собрания
+- [#237](https://github.com/coopenomics/mono/issues/237): Мобильная вёрстка на страницах стола совета
+- [#236](https://github.com/coopenomics/mono/issues/236): Пересобран лендинг для MONO
+- [#235](https://github.com/coopenomics/mono/issues/235): Настроен флоу гитхаб-релизов с описаниями
+- [#226](https://github.com/coopenomics/mono/issues/226): Встроено редактирование пайщиков
+- [#224](https://github.com/coopenomics/mono/issues/224): Добавлено ТЗ по контракту капитализации
+
+---
+
+# Change Log
+
+All notable changes to this project will be documented in this file.
+See [Conventional Commits](https://conventionalcommits.org) for commit guidelines.
+
+## [2.2.10](https://github.com/coopenomics/mono/compare/v2.2.9...v2.2.10) (2025-03-27)
+
+
+### Bug Fixes
+
+* add Zeus type ([7bcb6e3](https://github.com/coopenomics/mono/commit/7bcb6e30a77b0ab89c5293188b58f08f19c8761e))
+
+
+
+
+
+## [2.2.9](https://github.com/coopenomics/mono/compare/v2.2.8...v2.2.9) (2025-03-12)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.2.8](https://github.com/coopenomics/monocoop/compare/v2.2.7...v2.2.8) (2025-02-10)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.2.7](https://github.com/coopenomics/monocoop/compare/v2.2.6...v2.2.7) (2025-02-07)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.2.6](https://github.com/coopenomics/monocoop/compare/v2.2.6-alpha.0...v2.2.6) (2025-01-27)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.2.5](https://github.com/coopenomics/monocoop/compare/v2.2.4...v2.2.5) (2025-01-18)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.2.4](https://github.com/coopenomics/monocoop/compare/v2.2.0...v2.2.4) (2025-01-17)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.2.3](https://github.com/coopenomics/monocoop/compare/v2.2.0...v2.2.3) (2025-01-16)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.2.1](https://github.com/coopenomics/monocoop/compare/v2.2.0...v2.2.1) (2025-01-14)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.1.9](https://github.com/coopenomics/monocoop/compare/v2.1.8...v2.1.9) (2025-01-14)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.1.8](https://github.com/coopenomics/monocoop/compare/v2.1.6...v2.1.8) (2024-12-24)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.1.7](https://github.com/coopenomics/monocoop/compare/v2.1.6...v2.1.7) (2024-12-03)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.1.6](https://github.com/coopenomics/monocoop/compare/v2.1.5...v2.1.6) (2024-10-30)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.1.5](https://github.com/coopenomics/monocoop/compare/v2.1.4...v2.1.5) (2024-10-28)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.1.4](https://github.com/coopenomics/monocoop/compare/v2.1.4-alpha.2...v2.1.4) (2024-10-28)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.1.3](https://github.com/coopenomics/monocoop/compare/v2.1.2-alpha.10...v2.1.3) (2024-10-26)
+
+
+
+## [2.1.2](https://github.com/coopenomics/monocoop/compare/v2.1.1...v2.1.2) (2024-10-19)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.1.2](https://github.com/coopenomics/monocoop/compare/v2.1.1...v2.1.2) (2024-10-19)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+# [2.1.0](https://github.com/coopenomics/monocoop/compare/v2.0.10-alpha.3...v2.1.0) (2024-10-13)
+
+
+### Features
+
+* запрос соглашений ([9a6a72f](https://github.com/coopenomics/monocoop/commit/9a6a72f605ba52eef2ed6f18ccee6fbed287ea00))
+
+
+
+
+
+## [2.0.9](https://github.com/coopenomics/monocoop/compare/v2.0.8...v2.0.9) (2024-10-10)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.0.8](https://github.com/coopenomics/monocoop/compare/v2.0.7...v2.0.8) (2024-10-09)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.0.7](https://github.com/coopenomics/monocoop/compare/v2.0.6...v2.0.7) (2024-09-30)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.0.6](https://github.com/coopenomics/monocoop/compare/v2.0.5...v2.0.6) (2024-09-30)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.0.5](https://github.com/coopenomics/monocoop/compare/v2.0.5-alpha.0...v2.0.5) (2024-09-30)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+## [2.0.2](https://github.com/coopenomics/monocoop/compare/v2.0.2-alpha.1...v2.0.2) (2024-09-29)
+
+**Note:** Version bump only for package monocoop
+
+
+
+
+
+# 2.1.0 (2024-09-29)
+
+
+### Bug Fixes
+
+* **importers:** исправлена ошибка в импорте модуля @wharfkit/contract ([bf89032](https://github.com/coopenomics/monocoop/commit/bf89032d8f66444804a2521f4eb96ffc75b0f605))
+* **terminal:** исправлен шрифт в README ([889447a](https://github.com/coopenomics/monocoop/commit/889447a93ceadb577613ddb5b1cb2ef1cc3d54b6))
+* **terminal:** исправлено описание проекта ([989b318](https://github.com/coopenomics/monocoop/commit/989b3180ded99a871e018cf26e6c493449223c01))
+* **terminal:** fix typo in README.md ([fdf9996](https://github.com/coopenomics/monocoop/commit/fdf999619d2d69e960b062fe6815f5b057c95f48))
+
+
+### Features
+
+* добавлен docker-compose.yaml ([6a46697](https://github.com/coopenomics/monocoop/commit/6a46697c9d6cc3cde14dbce8f70997c00f9850de))
+* **package:** добавлен скрипт gpt-commit для удобного коммита ([e0b5107](https://github.com/coopenomics/monocoop/commit/e0b510799bb0ac68890d572deb652beefd0651c4))
+* **terminal:** добавлена поддержка новых команд ([73e4ca2](https://github.com/coopenomics/monocoop/commit/73e4ca226acebcbea3ae59a62def99d86efb1353))

CLAUDE.md

@@ -0,0 +1,301 @@
+# mono (coopenomics/mono) — рабочие заметки
+
+Этот файл — общая память агента для пяти чекаутов: `~/mono-ai-1`..`~/mono-ai-5`. Реальный файл лежит в `mono-ai-1/CLAUDE.md`, остальные четыре — симлинки сюда; правки коммитим из mono-ai-1 в ветку `dev`.
+
+## Стек монорепы
+
+| Слой | Где | Технология |
+|------|-----|------------|
+| Backend (coopback) | `components/controller/` | NestJS 10, TypeScript, TypeORM, GraphQL, EventEmitter2 |
+| Frontend (UI пайщика) | **`components/desktop/`** | **Vue 3 + Quasar** в SSR-режиме (`quasar dev --mode ssr`) |
+| Контракты | `components/contracts/` | EOSIO/CDT, C++ |
+| SDK для frontend | `components/sdk/` | TypeScript, авто-генерится из controller GraphQL schema |
+| Parser blockchain | `components/parser/` | TypeScript |
+| Boot/orchestration | `components/boot/` | TypeScript |
+
+**Frontend (`components/desktop/`) — FSD структура:** `src/{app,pages,processes,widgets,features,entities,shared,stores,desktops,boot}/`.
+
+Когда план говорит «UI компонент» / «frontend integration» — путь `components/desktop/src/{features|widgets|pages|processes}/<name>/`, расширение `.vue` (composition API + `<script setup lang="ts">`), стили Quasar (QChip/QBtn/QCard/QDialog…), GraphQL через Apollo Client + сгенерированные типы из `components/sdk/`. Dev — `pnpm --filter @coopenomics/desktop run dev` или `devnet` (без SSR).
+
+**НЕ путать:** НЕТ `components/app-cooperative/` — не предлагать. Все frontend-сессии работают в той же монорепе, что и backend. В стеке **никакого React нигде нет**.
+
+## Worktree-политика
+
+**Для mono-ai-4 (базовая ветка `marketplace2`, Стол заказов):** **worktree приветствуется** — изоляция работ + параллельные ветки. Если worktree пуст от `node_modules` и `.env` (pnpm их не дублирует):
+
+```bash
+WT=/home/admin/mono-ai-4/.claude/worktrees/<name>
+ln -s /home/admin/mono-ai-4/node_modules $WT/node_modules
+ln -s /home/admin/mono-ai-4/components/controller/node_modules $WT/components/controller/node_modules
+ln -s /home/admin/mono-ai-4/components/controller/.env $WT/components/controller/.env
+```
+
+Аналогично для других пакетов, чьи тесты будут запускаться (`components/desktop/node_modules`, `components/sdk/node_modules`). `jest` из bin: `cd $WT/components/controller && ./node_modules/.bin/jest -i <test>` — корректно резолвит ts-jest и подхватывает `.env`.
+
+**Подвох cooptypes:** когда `controller/node_modules` — симлинк на main, пакет внутри `node_modules/cooptypes -> ../../cooptypes` раскрывается **относительно main checkout**. `import { MarketContract } from 'cooptypes'` тянет d.ts из main, не из worktree. Если worktree обновлён, а main позади — TSC падает на отсутствующих типах. **Фикс:** перед TSC в worktree controller'а — `git pull` в main checkout до того же коммита (или хотя бы где cooptypes/src синхронен) + `pnpm build` в `main/components/cooptypes/`.
+
+## PR-flow
+
+**Базовая ветка mono-ai-1 — `dev`.** Прямые коммиты в `dev` для мелких фиксов разрешены и не требуют feature-ветки/PR (отменено 2026-05-22 пользователем). Для крупных задач — feature-ветка (`feat/...` или `fix/...`) от dev и PR в dev; merge делает пользователь на GitHub. Push в `main` / `mvp` — по-прежнему только через PR.
+
+**Не stash'ить `-u` при unstaged WIP пользователя.** Это создаёт окно для потери при drop/конфликте. Если нужно временно убрать unstaged — `git stash push -- <конкретные-paths>` либо коммит-в-feature, и только свои файлы. Кейс 2026-05-18: после `git stash -u`+`drop` при конфликте потерял WIP пользователя (infra.ts/config.ts/quasar.config.cjs и др.).
+
+### Story-by-story для проекта «Стол заказов» (mono-ai-4 на marketplace2)
+
+Каждая story из MVP-эпиков «Стол заказов» (`coopenomics/mono`, базовая ветка `marketplace2`, чекаут `~/mono-ai-4`, BMad-spec'и `_blago/.../components/3-minimalnyy-produkt/_bmad-output/`) идёт через PR.
+
+Workflow:
+1. Worktree от `marketplace2` на feature-ветке `feat/<E>-<S>-<slug>`.
+2. Edits + unit-тесты; tsc + jest должны быть зелёные.
+3. Commit + push feature-ветку.
+4. `gh pr create --base marketplace2 --head feat/<E>-<S>-<slug>`.
+5. Merge **пользователем на GitHub** (не вызывать `gh pr merge` без явной просьбы).
+6. После merge — fetch + checkout marketplace2 в основной чекаут, удалить feature-ветку + worktree, запустить e2e / blockchain тесты против обновлённого marketplace2.
+
+### Umbrella-PR на эпик vs цепочка PR
+
+При работе story-by-story в одной feature-area **не плодить отдельные PR на каждую story с одинаковой целевой веткой**. Каждый последующий PR показывает кумулятивный diff (всё, что в head минус то, что уже мёрджнуто в base). Если предыдущие PR ещё не смерджены — в diff вылазят дубликаты файлов всех предыдущих stories.
+
+**Default — umbrella-PR на эпик** (для крупных эпиков с >3 stories): одна `feat/<E>-epic` ветка + один PR; каждая story — отдельный коммит. Worktree последовательно, push после каждой story, PR обновляется. Так закрыт Эпик 1 Стола заказов (umbrella #380).
+
+**Альтернатива — stacked-PRs с `base:<prev-feat>`:** каждый PR таргетится на предыдущую feature-ветку. После merge нижнего GitHub автоматически перетарджетит верхние. Требует дисциплины и тулинга.
+
+**Анти-паттерн:** worktree от `feat/1-2-...`, потом от `feat/1-3-...`, и каждый PR в `marketplace2`. Цепочка branches правильная (изоляция), но цепочка PR — нет. Кейс Эпика 1 Стола заказов 2026-05-14: 11 PR `#370-#380` подряд от `marketplace2`, каждый +N stories назад. Пользователь дошёл до review #372 и обнаружил дубли. Закрыл #372-#379, оставил только #380.
+
+## Локальные тесты
+
+**Не запускать полный jest локально** ни в mono-ai-1, ни в mono-ai-4: живой dev-стек в docker (`nodeos`, `controller dev` nodemon, `parser dev`, `n8n`) вешает CPU/RAM и блокирует chain. Полный suite — задача CI после push'а PR.
+
+В mono-ai-4 **запрещён параллельный режим jest** (worker-pool по умолчанию) — это вешает сервер. Если нужен unit-тест — точечный с `--runInBand`:
+
+```bash
+pnpm jest tests/unit/marketplace/marketplace-onboarding-service.test.ts --runInBand
+```
+
+`pnpm generate-schema` / `pnpm generate-client` — **не запускать локально**; та же memory/CPU полка вешает контейнер controller'а. Либо CI, либо пользователь сам когда контейнер остановлен.
+
+Перед коммитом достаточно `tsc --noEmit` (быстрый, не блокирует).
+
+## SDK login canon
+
+`@coopenomics/sdk` экспортирует `Client.create({api_url, chain_url, chain_id})` + метод `client.login(email, wif)`. Он сам:
+1. Генерит `now` (ISO timestamp).
+2. Подписывает приватным ключом (WIF) через eosjs.
+3. Зовёт `Mutations.Auth.Login.mutation` с `{email, now, signature}`.
+4. Возвращает `{tokens: {access: {token}, refresh: {token}}, account: {username}}`.
+
+**Не дёргать `Mutations.Auth.Login` напрямую** — `LoginInput` ждёт `{email, now, signature}`, генерация подписи внутри SDK Client. Refresh: `Mutations.Auth.Refresh.mutation` с `{access_token, refresh_token}`. Канон используется в `blago-cli/src/session/index.ts` (loginInteractive) и в EMP-коннекторе `connectors/cooperative-tsk-login-connector` (Story 11.5).
+
+## Backend (controller) каноны
+
+### 3 базовые роли — User / Member / Chairman
+
+- **User** — обычный пайщик. Базовые потребительские права (заказывать, публиковать оферту, видеть свои данные).
+- **Member** — **член совета** (не «член кооператива»!). User-права + read-only admin (видит склад, поток заказов, повестку — но не модерирует и не подписывает финальные действия).
+- **Chairman** — председатель. User + admin (модерация, KU/whitelist/витрины, closing signature АПП-приёмки/выдачи, повестка совета на write).
+
+Маппинг core-роли на extension-роль явно: User → orderer + опционально offerer/operator; Chairman → admin (полный write); Member → read-only admin (board_readonly). Пайщик может быть одновременно в нескольких extension-ролях — массив, не enum. Guard'ы в расширениях — локальные сейчас, в Phase 2 переключатся на платформенный CASL.
+
+### `agreements` ссылается на существующий document registry_id
+
+Когда расширение controller'а (marketplace, blagorost, любое следующее) хранит факт подписи документа пайщиком в глобальной on-chain таблице `agreements`, ссылка идёт через **существующий `registry_id` из платформенного реестра документов**, не через отдельный type-string типа `marketplace.cpp.stol-zakazov-v1`.
+
+Поле `document_id` в `agreements` — FK на существующий platform registry. Extension-таблицы `*_onboarding_requirement` — `document_registry_id` ссылается на существующий ID. API запросов вида «какие документы подписаны member'ом» — `agreementsByMember(member_id, document_id_filter=[...])`.
+
+**Технический долг платформы:** «Договор УХД сейчас не проходит через `agreements`» — отдельная задача core controller'а, вне scope конкретных расширений.
+
+### Трёхуровневый онбординг расширений
+
+Платформенный паттерн, обязателен для всех новых расширений controller'а.
+
+**L1 — Кооператив (one-time):** председатель/совет принимает решение совета о подключении ЦПП, принимается положение ЦПП (статический документ из platform registry, через document factory с подстановкой параметров кооператива), оферта регистрируется в `coop_registration_offers_registry`.
+
+**L2 — Пайщик при вступлении (per-membership):** в registration-flow появляется **выбор** ЦПП. Пайщик отмечает интересующие, document factory рендерит оферту с `{cooperative_params, member_params, agreement_date}`. Подпись пишется в глобальную on-chain `agreements`. Эта подпись **нивелирует** gate на столе расширения.
+
+**L3 — Пайщик на рабочем столе (per-extension first visit):** backend проверяет через `agreementsByMember` — подписана ли оферта ЦПП. ДА → gate не показывается. НЕТ → gate показывается как explicit consent.
+
+При проектировании любого нового расширения — обязательно три истории под три уровня. На MVP допустимо упростить: одинаковый `document_registry_id` для положения и оферты (физически разные документы могут быть в Phase 2).
+
+### Marketplace asset через DI
+
+В сервисах `components/controller/src/extensions/marketplace/**/*.service.ts` запрещён хардкод вида `const ASSET_DECIMALS = 4` / `const ASSET_SYMBOL = 'RUB'`. Decimals и symbol — через DI `MARKETPLACE_ASSET_CONFIG`:
+
+```ts
+@Inject(MARKETPLACE_ASSET_CONFIG) private readonly assetConfig: MarketplaceAssetConfig
+// assetConfig.symbol, assetConfig.decimals
+```
+
+Канон-пример: `marketplace-order-create.service.ts`. См. `marketplace-asset.config.provider.ts` — мапит `config.blockchain.root_govern_symbol` / `root_govern_precision`. Разные среды (mainnet/testnet/dev) имеют разный symbol+precision.
+
+### registry_id=800 (ReturnByAssetStatement) — клиринг, не членские взносы
+
+Marketplace в монорепе живёт в **двух контурах**:
+1. **Система клиринга** (старый, не используется) — registry_id=800. Не использовать в новых фичах.
+2. **Система членских взносов** (текущий MVP) — документы лежат **рядом** с актами приёма-передачи и ТТН; другая группа registry_id.
+
+Для нового документа Marketplace-членские-взносы: завести новый registry_id рядом с актами/ТТН и проложить цепочку `cooptypes → factory → controller → desktop`:
+1. `@coopenomics/cooptypes`: новый тип документа + регистрация в registry.
+2. `@coopenomics/factory`: generator (preview-структура + meta).
+3. `@coopenomics/controller`: signed-document DTO + verify в сервисе.
+4. `@coopenomics/desktop`: подпись через `Classes.Document` с новым registry_id.
+
+## GraphQL каноны (controller + desktop)
+
+### Описания @Field — бизнес-языком
+
+В `@Field({ description })`, `@InputType`, `@ObjectType` нельзя писать «Story 4.1», «Эпик 3», «FR11a», «composite-entity», «dispatch pipeline», «tx_snapshot», «backend deterministic order_hash». Только пользовательский язык: «Идентификатор заказа», «ПВЗ получения», «Кол-во единиц товара». Story-ссылки и инвариант-комменты — только в inline-комментариях внутри сервиса.
+
+### Enum вместо строковых литералов
+
+Запрещены `if (offer.cycle_type === 'volume_based')`, `status: 'ACTIVE'`, `'PENDING_MODERATION'`. Любое поле с фиксированным набором (cycle_type, status, type, kind, role) — TypeScript `enum`, при необходимости `registerEnumType` для GraphQL. В тестах константы — тоже из enum, не дублирующие строки. Перед добавлением сравнения по строке — `enum MarketplaceOfferCycleType` / `MarketplaceOrderStatus` в `domain/entities/*.types.ts`.
+
+### Пагинация — единый паттерн
+
+В controller-resolver'ах пагинация делается единым каноническим паттерном:
+- Вход: `@Args('options', { nullable: true }) options?: PaginationInputDTO` (импорт из `~/application/common/dto/pagination.dto.ts`, поля page/limit/sortBy/sortOrder).
+- Выход: `createPaginationResult(ItemDTO, 'PaginatedXxx')` + сигнатура `Promise<PaginationResult<T>>` (items / totalCount / totalPages / currentPage).
+- Repository принимает `PaginationInputDTO`, сам считает offset/limit/sort через TypeORM `findAndCount`.
+
+Канон: `time-tracker.resolver.ts`, `expenses-management.resolver.ts`, `generation.resolver.ts`. Никаких локальных `{ limit, offset }`.
+
+### Никаких raw GraphQL-строк в desktop
+
+В `components/desktop/src/pages/**/api/index.ts` и аналогах запрещены конструкции:
+```ts
+const QUERY = `query Foo { ... }`;
+await sendPOST('/v1/graphql', { query: QUERY, variables });
+```
+Даже с комментарием «техдолг до Zeus regen».
+
+Обязательная процедура перед UI-кодом под новую GraphQL-операцию:
+1. Добавить/изменить DTO/resolver в `components/controller/src/...` (code-first).
+2. `pnpm run generate-schema` в `components/controller/` → пересоздать `controller/schema.gql`.
+3. `pnpm run generate-client` в `components/controller/` → graphql-zeus кладёт клиент в `components/sdk/src/zeus/`.
+4. `pnpm run build` в `components/sdk/` → unbuild собирает `dist/`.
+5. В desktop импортировать `Mutations.<Domain>.<Name>` / `Queries.<Domain>.<Name>` из `@coopenomics/sdk` — типизировано end-to-end.
+
+Если на шаге 1 не хватает поля — добавить и запустить весь цикл; не оставлять заглушку «пока».
+
+### Строгая типизация desktop API из SDK через IInput['data']
+
+Каждый вызов `client.Mutation` / `client.Query` в `components/desktop/src/**/api/index.ts`:
+1. Принимает аргументом объект `data: IXxxInput`, где `IXxxInput = Mutations.<Domain>.<Action>.IInput['data']` (или `Queries...`) — тип берётся **прямо из @coopenomics/sdk**, не переописывается.
+2. Передаёт в `variables` объект `data` целиком: `{ variables: { data } }`. Запрещено разворачивать поля: `{ variables: { data: { a, b, c } } }`.
+
+Канон — `features/Branch/CreateBranch/{api,model}/index.ts`: тип в model `export type IXxxInput = Mutations.X.Y.IInput['data']`; функция в api `function (data: IXxxInput) { ... variables: { data } }`. Не делать `as` cast'ов.
+
+## Frontend desktop — English имена
+
+В `components/desktop/` и любом Vue/TS frontend коде **все имена идентификаторов — английские**:
+- Имена Vue-компонентов: `BaseInput`, `BaseDialog`, `WalletCard`, `IdentityPanel`.
+- Имена файлов и директорий: `shared/ui/BaseInput/BaseInput.vue`.
+- CSS-классы: `.base-card`, `.wallet-card__icon`, `.id-panel__hero`.
+- SCSS-переменные: `$primary`, `$prog-blagorost`, `$separator-color`.
+- TS-типы, интерфейсы, переменные, функции: `interface WalletCardProps`, `function useWalletData()`.
+
+**Why:** Unicode-имена ломают тулчейн (Vite/Webpack резолверы и aliases часто на ASCII-only regex; TypeScript symbol-resolution на не-ASCII нестабильно; ESLint `vue/component-name-in-template-casing` ждёт PascalCase ASCII; импорты `import БазоваяКнопка from '@/shared/ui/БазоваяКнопка'` невыносимы при review).
+
+**Заголовки в .vue, label-ы кнопок, тексты в UI — по-русски** (это user-facing strings). Не путать с правилом «онтологические class_id по-русски» — то про EMP/ТЭМ и blago-документы, не про frontend.
+
+**Кейс 2026-05-18:** при подготовке UX-спецификации для components/desktop ошибочно применил правило русских имён к Vue-компонентам (`БазоваяКнопка`, `БазовоеПолеВвода`); пользователь поправил.
+
+## Стандарты процессов (.standard.yaml) — бизнес-языком
+
+`components/contracts/cpp/**/*.standard.yaml` — документация для методолога/бухгалтера, не для разработчиков контракта. В `purpose`, `description`, `note`, `human` запрещены технические термины:
+
+- никаких «callback», «soviet::exec», «soviet::createagenda», «AUTHORIZE_CALLBACK_SIGNATURE», «type-string», «registry N», «proposed расширение enum'а»;
+- никаких «backend formирует», «controller вызывает», «contract отдаёт» — пишем кто что делает на уровне бизнеса (председатель / совет / заказчик / поставщик);
+- технические `marketplace::propwroff`-имена в полях `action`/`name`/`triggered_by` оставляем как identifier'ы, но всё человеко-читаемое в `human`/`purpose`/`description` — на бизнес-словаре;
+- бухгалтерские проводки `Дт 91 / Кт 10` — допустимы (бухгалтер их понимает);
+- если процесс встроен в более общий — ссылаемся на стандарт по имени-человеку («типовой процесс решения совета»), не на техническую реализацию повестки.
+
+Эталоны: `p.mkt.return.standard.yaml`, `p.cap.rid.standard.yaml`, `reg.coop.standard.yaml`. Антипример — `p.mkt.wroff.standard.yaml` в PR #399 review 2026-05-18 (был забит callback-описаниями и «type=mktwroff»).
+
+## Vault & SERVER_SECRET
+
+WIF админ-аккаунта (например `voskhod`) хранится в `vaults` PostgreSQL зашифрованным AES-256-CBC с ключом `sha256(SERVER_SECRET)`. Если `SERVER_SECRET` потом меняли — **старые записи разрушаются**, `decipher.final()` бросает `error:1C800064:Provider routines::bad decrypt`.
+
+**Симптомы:**
+- В логе coopback: `[VaultDomainService] Ошибка при получении WIF ключа для пользователя voskhod: bad decrypt`.
+- В UI каскад `SignAgreementDialog` не закрывается; SPA отправляет `sendAgreement` корректно, но `wallet::signagree` on-chain не происходит.
+- Следствие — `wallet::users[<coop>]` пуст, и любой последующий `is_can_transfer`/трансфер AXON падает на `Отправитель не является участником ЦПП кошелька`.
+
+**Фикс:**
+1. Достать живой WIF (для voskhod в dev — `5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3` из boot config.ini, signature-provider).
+2. Шифрануть им current SERVER_SECRET (см. `controller/src/utils/aes.ts` — sha256(SECRET) → AES-256-CBC, IV 16 байт, формат `ivHex:cipherHex`).
+3. `UPDATE vaults SET wif='...', updated_at=now() WHERE username='voskhod' AND permission='active';`.
+4. Перезапуск coopback **не нужен** — он читает каждый раз.
+
+**Дефолт всех mono-репозиториев — `SECRET`.** Если в каком-то `.env` стоит другое — девиация, не норма. Перед re-encrypt'ом vault'а ВСЕГДА сначала смотреть `~/mono-ai-1/components/controller/.env` (или соседнего) — это origin truth для SERVER_SECRET.
+
+**Кейс 2026-05-18 (Эпик 0):** в `mono-ai-5/components/controller/.env` стоял `e2e-fixture-secret-DO-NOT-USE-IN-PROD`, а WIF voskhod в vaults был зашифрован оригиналом — `SECRET`. Фикс — откатить SERVER_SECRET к `SECRET` и подровнять provider'а.
+
+## Capital — фиксы билетов времени (PR #387 merged 2026-05-15)
+
+В `components/controller/src/extensions/capital/` была серия багов в распределении билетов времени, закрытая PR #387 в dev. Три бага:
+
+1. **`recalcDoneEstimatesForContributorProject` / `applyExplicitEstimateToTimeEntries`** раздавал «общий остаток пула» `(estimate − total_committed) / N` всем creators, включая того, кто уже закоммитил. Фикс: личная доля `max(0, estimate/N − own_committed_estimate)` через общий helper `redistributeIssueEstimateEntries`.
+2. **`commitTime` partial split** создавал committed-запись без `entry_type` и `estimate_snapshot` — БД по default'у писала `entry_type='hourly'`, что ломало последующий recalc (фильтрует только `entry_type='estimate'`). Фикс: явно копировать оба поля.
+3. **`declineCommit` / `handleDeclineCommit`** меняли только `commit.status='declined'`, но не возвращали `time-entries` в `is_committed=false`. Часы оставались в `total_committed_hours`. Фикс: `revertEntriesForDeclinedCommit` через новые `findCommittedByCommitHash` / `revertCommittedEntriesByCommitHash`.
+
+**При симптомах** «25 ч подтверждено непонятно откуда» / «доступные часы не вернулись после decline» / «парные коммиты на одну работу» — первый чек: `grep -c redistributeIssueEstimateEntries time-tracking.interactor.ts` в контейнере > 5. Если нет — деплой устарел. Если есть, но баг — посмотреть `entry_type` у committed-записей по issue: legacy записи из БАГ #2 могут до сих пор быть с `entry_type='hourly'` для split-результатов от estimate (видны по `commit_hash IS NOT NULL AND entry_type='hourly' AND estimate_snapshot IS NULL` на DONE-задаче с estimate>0). Чинятся UPDATE'ом `entry_type → estimate` с правильным `estimate_snapshot`.
+
+**Legacy data caveat:** `capital_time_entries` с `entry_type='hourly'` + `commit_hash != NULL` могут быть как (а) настоящей hourly работой до установки estimate, так и (б) split-наследием БАГ #2. Различить: если у задачи `estimate>0` и `DONE`, и записи hourly от тех же creators что в estimate-долях — это (б), чинить.
+
+**Edge-case дробных остатков:** при `estimate=2.5` и одном creator, после commit'а 2 ч (`Math.floor < 1` для остатка) остаётся 0.5 ч uncommitted estimate, который никогда не закоммитится. Либо ручной DELETE uncommitted остатка, либо изменить estimate на целое (но estimate в `capital_issues` — on-chain, через UI mutation, не DELETE'ом в БД).
+
+## Стол Заказов MVP — текущее состояние
+
+Проект `1-prilozhenie-stol-zakazov` в blago (coopname voskhod, hash `feabc749…3841f73`). Кооперативная закупка/распределение имущества участка (продукты, товары, услуги); пилот — Красногорск; цель 6 мес: 10 кооперативов / 1200+ пайщиков.
+
+**Локация:** `~/blago/production/1-prilozhenie-stol-zakazov/`.
+
+**Структура артефактов:**
+- `_bmad-output/planning-artifacts/` (project-уровень): `prd.md`, `prd-validation-report.md`, `ux-design-specification.md`, `architecture.md` (status:complete 2026-05-12).
+- **`components/3-minimalnyy-produkt/_bmad-output/planning-artifacts/epics.md`** (SoT для MVP) — `stepsCompleted=[1,2,3,4]`, `status: complete 2026-05-12`, 65 FRs → 11 эпиков → 57 stories. **НЕ создавать дубль на верхнем уровне `_bmad-output/planning-artifacts/`** — MVP-компонент имеет собственный bmad-output.
+- `requirements/` (5 файлов): `04-brif`, `0b-protsessy`, `0f-prd`, `7e-uxui`, `d6-arkhitektura` — дубли _bmad-output (намеренно, см. правило о дублях BMad-артефактов в global memory).
+
+**Locked Decisions L1–L9:**
+- **L1:** порядок подписей АПП (приёмка поставщик→председатель финально / выдача председатель→заказчик финально).
+- **L2:** `o.mkt.payout` baseline `Дт 86 / Кт 51` без счёта 60.
+- **L3:** реверты исключены — compensating forward с собственным `operation_id`.
+- **L4:** геокарта КУ обязательна на трёх столах; lat/lng в `PlaceDomainEntity`.
+- **L5 / L9:** «Системный конструктор ЦПП» → реализован как трёхуровневый онбординг расширений (см. выше).
+- **L6:** без отрицательного баланса в MVP (отменяет NFR-R5 PRD).
+- **L7:** enum 10 кооп-категорий (овощи/фрукты, молочные, мясо, рыба, хлеб, бакалея, напитки, готовая еда, услуги, прочие).
+- **L8:** двухслойная схема подписания — глобальная on-chain `agreements` (SoT) + локальные `*_onboarding_requirement`/`*_onboarding_state` per-extension.
+- **L10/L11/L13:** consolidated request backend-only / cycle_type backend variation / pull-модель отчётности.
+
+**Прогресс по эпикам (на 2026-05-15):**
+- **Эпик 1** — MERGED в `marketplace2`: PR #368/#370/#371/umbrella #380.
+- **Эпик 2 «Сеть ПВЗ»** — MERGED PR #381 (после rebase). Workspace `market-pvz`, KU details + Yandex geocoder, Zeus SDK.
+- **Эпик 11 Story 11.1 (Ledger2 canonical actions)** — MERGED PR #375 на C++ стороне. **TS-сторона cooptypes НЕ закрыта**: `cooptypes/src/contracts/marketplace/actions/index.ts` экспортирует только LEGACY клиринговые actions, `interfaces/marketplace.ts` auto-generated из устаревшего ABI. **Блокер Эпика 4** — нужен отдельный pre-эпик PR `feat/S11-1-cooptypes-canonical`: ABI regen через `eosio-abi2ts` из новой `marketplace.abi.json` после `coopcontracts` build, либо ручное добавление 18 canonical actions + canonical tables + canonical interfaces.
+- **Эпик 3 «Витрина»** — IN REVIEW. PR #382 (`feat/E3-vitrina`) OPEN MERGEABLE. 6 коммитов (Stories 3.1–3.5 + BC-sync seam), 67 unit-тестов. Stories 3.4 (CAS counters) — callback-target для Эпика 4 + scaffolding `marketplace-order-sync.service.ts` (skeleton, throw NOT_IMPLEMENTED).
+- **Эпики 4-10** — BACKLOG. Issues 598-7 … 598-13 разложены; story-requirements в `598-N-…-requirements/`.
+
+**Открытые фоллоуапы Эпика 1:**
+- L3 mutation `marketplaceSignOnboardingOffer` (write-mutation pool + `sndagreement`).
+- Source-маркер `'registration_flow'` vs `'extension_gate'` в DTO.
+- `marketplaceAcceptCpp` валидация повестки совета — после Эпика 8 (FR40).
+- Финальный юридический текст оферты — `todo-tspp-templates.md` (блокирует Stories 1.7/1.9/1.11 в продовой подаче).
+- Story 1.5 интеграционный тест против тестовой ноды ЦК — после Эпика 11.
+
+**Реальное состояние brownfield (на marketplace2 @ d98041d):**
+
+| Слой | Готово (membership) | Donor-клиринг (нужно решить судьбу) |
+|---|---|---|
+| ledger2 C++/TS реестры | 12 операций `o.mkt.*`, счета 10/91, кошельки `w.mkt.member`/`w.mkt.payout`/`w.wal.member`, WalletOp `REVOKE` | — (legacy `o.mkt.supply/recv` удалены) |
+| YAML-стандарты `p.mkt.{supply,return,wroff}` | canonical имена actions | — |
+| C++ actions (`marketplace.hpp` + 30 .cpp) | **ничего** из canonical | `orderoffer/accept/authcontrib/authreturn/supply/...` ~1660 LOC; legacy Wallet, не ledger2 |
+| process-registry в controller | заглушки под membership (`p.mkt.reqst` убран) | — |
+| cooptypes/contracts/marketplace TS-actions | нет canonical | 24 клиринговых обёртки |
+| controller/application + domain/marketplace | нет canonical | 23 DTO + interactor + resolver + 6 interfaces |
+| controller/extensions/marketplace | — | для категорий Ozon (clean arch, 7 TypeORM entities); может пригодиться для каталога Offer'ов |
+| controller/extensions/marketplace-cards | — | минимальный каркас карточек |
+| desktop/pages/Marketplace | нет canonical | 11 страниц под клиринг; `desktop/extensions/market` пуст |
+
+**Решение 2026-05-12:** стратегии миграции не делаем — donor уже не работает по старой модели; собираем новую membership-модель в существующем контуре, donor-код переписывается / удаляется напрямую без переходников.
+
+В `/bmad-create-architecture` MVP **не вводить adapter-слой и не описывать миграционные пути**. Прямо фиксировать: какие C++ actions/DTO/Vue-страницы из donor-листа удаляются, какие переписываются под canonical (`signsupp/signchair/signiss1/signiss2/acceptbatch/declinebatch/expirecycle/prepship/createorder(новая сигнатура)/cancelorder`), какие сохраняются (shipment/coopstock — если попадают в MVP scope, отдельно проверить).
+
+**Обязательная enforcement-база для backend** — `mono-ai-4/components/controller/CLAUDE.md` (Composite-Entity `db/bc/derived`, Write-mutation pool с placeholder/sync_key dedup, ParserClient + Redis Streams, ForkRegistry, ADR-002/008/009/011/012; параметры через `config/blockchain.config.ts`, не magic numbers).

CONVENTION.md

@@ -0,0 +1,39 @@
+k# Conventional Commits
+
+### Основные типы коммитов:
+
+- **`feat`**: Добавление новой функциональности (feature).
+  - Пример: `feat: добавлена возможность загрузки файлов`
+
+- **`fix`**: Исправление бага.
+  - Пример: `fix: исправлена ошибка отображения кнопки на мобильных устройствах`
+
+- **`chore`**: Изменения, не влияющие на исходный код (например, обновление зависимостей или инструментария).
+  - Пример: `chore: обновление зависимостей`
+
+- **`docs`**: Изменения в документации.
+  - Пример: `docs: обновлено руководство пользователя`
+
+- **`style`**: Изменения стиля кода, не влияющие на его функциональность (форматирование, пробелы, и т.д.).
+  - Пример: `style: исправлены отступы в коде`
+
+- **`refactor`**: Изменения в коде, которые не исправляют баги и не добавляют новую функциональность.
+  - Пример: `refactor: улучшена структура класса`
+
+- **`perf`**: Изменения, направленные на улучшение производительности.
+  - Пример: `perf: оптимизирована работа с массивами`
+
+- **`test`**: Добавление или изменение тестов.
+  - Пример: `test: добавлен тест для проверки функции отправки сообщений`
+
+### Дополнительные типы коммитов:
+
+- **`build`**: Изменения, связанные с процессом сборки или зависимостями.
+  - Пример: `build: обновление конфигурации Webpack`
+
+- **`ci`**: Изменения, касающиеся настроек непрерывной интеграции (например, Travis, Jenkins).
+  - Пример: `ci: настройка Travis для автоматических сборок`
+
+- **`revert`**: Откат на предыдущие изменения.
+  - Пример: `revert: откат коммита e0b5107`
+

DEV-SETUP-MACOS.md

@@ -0,0 +1,139 @@
+# Запуск mono dev-стека на macOS
+
+Полная пошаговая инструкция, как поднять backend (`coopback`) + parser (`cooparser`) + блокчейн-ноду + БД на macOS через Docker Desktop. Прошёл — отметь, ниже разобраны типичные грабли.
+
+## TL;DR
+
+```bash
+cd ~/dacom-code/foundation/monocoop
+docker compose up -d                                                    # 1. поднять базу
+./scripts/dev-setup-macos.sh                                            # 2. одной командой (см. ниже скрипт)
+```
+
+Если скрипта ещё нет — выполняй шаги ниже руками.
+
+## Шаги
+
+### 1. Поднять контейнеры
+
+```bash
+docker compose up -d
+```
+
+Поднимутся: `node` (NodeOS), `mongo`, `monoredis`, `postgres`, `coopback`, `cooparser`. **MinIO** входит в дефолт. **OpenSearch** — нет (тяжёлый, см. опц. сервисы).
+
+### 2. Проверить чтоб .env'ы указывали на service-имена, а не localhost
+
+`components/controller/.env`:
+- `MONGODB_URL=mongodb://mongo:27017/cooperative-x`
+- `REDIS_HOST=monoredis`
+- `POSTGRES_HOST=postgres`, `POSTGRES_PASSWORD=postgres!23!23`
+- `BLOCKCHAIN_RPC=http://node:8888`
+- `SIMPLE_EXPLORER_API=http://cooparser:4000`
+- `MINIO_ENDPOINT=minio:9000`
+- `CHAIN_ID=<реальный chain_id, см. ниже>`
+
+`components/parser/.env`:
+- `MONGO_EXPLORER_URI=mongodb://mongo:27017/cooperative-x`
+- `REDIS_HOST=monoredis`
+- `API=http://node:8888`
+- `SHIP=ws://node:8080`
+
+**Почему service-имена:** все контейнеры в bridge-сети `monocoop_default`. Внутри контейнера `127.0.0.1` = сам контейнер, не host. На macOS `network_mode: host` в Docker Desktop работает плохо — используем bridge + service names.
+
+### 3. Узнать живой chain_id
+
+```bash
+curl -s http://localhost:8888/v1/chain/get_info | jq -r .chain_id
+```
+
+И вписать в `components/controller/.env` → `CHAIN_ID=...`. **Если chain_id в .env не совпадает с живым — on-chain транзакции упадут на verify, хотя приложение запустится.**
+
+### 4. Если правил .env — пересоздать контейнер (не restart!)
+
+```bash
+docker compose up -d --force-recreate --no-deps coopback cooparser
+```
+
+`docker restart` **не перечитывает** `env_file`. `--no-deps` — чтобы не пересоздавать БД (потеряются данные).
+
+### 5. Native binding libxmljs2 — пересборка под Linux
+
+На свежем чекауте `pnpm install` запускается на macOS, и `libxmljs2` собирает Mach-O бинарник. В Linux-контейнере он падает:
+
+```
+Error: .../xmljs.node: invalid ELF header  ERR_DLOPEN_FAILED
+```
+
+**Фикс** (один раз после `pnpm install`):
+
+```bash
+docker exec monocoop-coopback-1 sh -c '
+  cd /app/node_modules/.pnpm/libxmljs2@0.37.0/node_modules/libxmljs2 \
+  && rm -rf build \
+  && PATH="$PWD/node_modules/.bin:$PATH" npm run install
+'
+docker restart monocoop-coopback-1
+```
+
+Проверка — magic bytes Linux ELF:
+```bash
+docker exec monocoop-coopback-1 sh -c \
+  'head -c 4 /app/node_modules/.pnpm/libxmljs2@0.37.0/node_modules/libxmljs2/build/Release/xmljs.node | od -c -N 4'
+# Должно быть:  177   E   L   F
+# Если cf fa ed fe — это macOS Mach-O, фикс не применился.
+```
+
+### 6. Дождаться cold-start coopback (~5–6 минут)
+
+`ts-node` без cache + DI tree NestJS = долго. Первые логи появляются спустя ~5 минут после старта контейнера.
+
+```bash
+docker logs -f monocoop-coopback-1 | grep -E 'NestJS app|Nest application|Error'
+```
+
+Готово, когда видишь:
+```
+Nest application successfully started
+NestJS app with Express routes running on port 2998
+```
+
+Проверка:
+```bash
+curl -s -X POST -H 'Content-Type: application/json' \
+  -d '{"query":"{__typename}"}' http://localhost:2998/v1/graphql
+# {"data":{"__typename":"Query"}}
+```
+
+## Опциональные сервисы
+
+### OpenSearch (поиск)
+
+```bash
+docker compose --profile search up -d opensearch
+```
+
+Затем в `components/controller/.env`:
+```
+OPENSEARCH_ENABLED=true
+```
+И пересоздать coopback:
+```bash
+docker compose up -d --force-recreate --no-deps coopback
+```
+
+## Грабли (если опять провозился пол-дня)
+
+| Симптом | Причина | Фикс |
+|---|---|---|
+| `invalid ELF header` | host'овый `pnpm install` положил Mach-O | См. п. 5 — пересборка libxmljs2 в контейнере |
+| `MongooseServerSelectionError: ECONNREFUSED 127.0.0.1:27017` | .env на localhost вместо service-имени | См. п. 2 |
+| `password authentication failed for user "postgres"` | в .env `POSTGRES_PASSWORD=postgres` вместо `postgres!23!23` | См. п. 2 |
+| Coopback ушёл в restart-loop, но рядом есть другой `monocoop-coopback-1` Up | Случайно запустился старый `components/controller/docker-compose.yml` (network_mode: host, без bind-mount, без CMD) | `docker stop coopback && docker rm coopback` |
+| `docker restart` не подхватил новые переменные .env | `restart` не перечитывает `env_file` | `docker compose up -d --force-recreate --no-deps <svc>` |
+| Coopback зависает на 5+ минут, лога нет | Это нормально для cold-start ts-node | Подождать. CPU должен крутиться ≥50%. Если CPU = 0% — другая проблема |
+| `[VaultDomainService] Ошибка при получении WIF... bad decrypt` | SERVER_SECRET не совпадает с тем, чем шифровали WIF в БД | См. CLAUDE.md → раздел Vault & SERVER_SECRET. Дефолт — `SECRET` |
+| Транзакции падают на on-chain verify | CHAIN_ID в .env не совпадает с живым | См. п. 3 |
+| `Custom endpoint \`minio://9000\` was not a valid URI` на bootstrap | `MINIO_ENDPOINT` без схемы | `MINIO_ENDPOINT=http://minio:9000` (со схемой!) |
+| nodeos в restart-loop с `Database dirty flag set` после sleep/crash Docker Desktop | unclean shutdown chain state | `docker stop monocoop-node-1`; `mv blockchain-data/state-history{,.broken-$(date +%s)}`; `docker compose up -d node` — nodeos сам сделает replay |
+| Cold-start coopback 10+ минут (вместо обычных 3-5) | ts-node без cache + bind-mount через osxfs + параллельная нагрузка (nodeos replay) | Подождать; в будущем — `tsx` / `ts-node --swc` для dev-режима |

Dockerfile

@@ -0,0 +1,118 @@
+# Multi-stage build для `dicoop/mono-base`.
+#
+# Стадии:
+#   1. builder — full toolchain: pnpm + lerna + apt dev-headers (gcc,
+#      libcairo2-dev, ...) + WeasyPrint в venv. Здесь делаются
+#      `pnpm install` (с devDeps), `lerna run build`, потом
+#      `pnpm prune --prod` (devDeps выкидываются из workspace
+#      node_modules — экономит ~1.5GB).
+#   2. runtime — slim образ без dev-headers и без gcc. Только runtime
+#      libs WeasyPrint + готовый /app + venv. Глобальные pnpm/lerna
+#      ставятся отдельно для удобного запуска `pnpm -F <pkg> run start`.
+#
+# Финальный размер: ~1-1.5GB (вместо 7.36GB в одностадийной сборке).
+# Все потребители mono-base (controller/desktop/parser/notifications/
+# notificator/boot) пользуются одним и тем же тонким runtime-образом
+# через `FROM dicoop/mono-base:<tag>` + `CMD`.
+
+# ── Stage 1: builder ──────────────────────────────────────────────────
+FROM node:22-slim AS builder
+
+WORKDIR /app
+
+# Build-time системные deps. Тяжёлые `-dev`-пакеты (для компиляции
+# native-bindings + WeasyPrint native deps) сюда, в runtime их не
+# тащим. `--no-install-recommends` экономит ещё ~150MB.
+RUN apt-get update && apt-get install -y --no-install-recommends \
+      python3 python3-pip python3-venv \
+      build-essential gcc g++ python3-dev \
+      libcairo2-dev libffi-dev libjpeg-dev libopenjp2-7-dev zlib1g-dev \
+      libpango-1.0-0 libpangoft2-1.0-0 libpangocairo-1.0-0 libcairo2 \
+      shared-mime-info \
+ && rm -rf /var/lib/apt/lists/*
+
+# WeasyPrint в venv — переедет в runtime-stage целиком через COPY.
+RUN python3 -m venv /venv \
+ && /venv/bin/pip install --no-cache-dir WeasyPrint==67
+
+# pnpm пинится через `packageManager` поле в корневом package.json
+# (corepack-стандарт). Без пина CI каждый раз тянет latest, а pnpm 10
+# ужесточил политику build-скриптов и валит `--frozen-lockfile` с
+# ERR_PNPM_IGNORED_BUILDS на native-пакетах (electron / esbuild / …).
+RUN corepack enable && npm install -g lerna --no-fund --no-audit
+
+# Сначала манифесты (для кэш-friendly install). `.dockerignore` уже
+# выкидывает node_modules/dist/.git, поэтому `COPY .` лёгкий.
+COPY . .
+
+# Используем существующий lockfile. Если он не совпадает с workspace —
+# падать сразу, не дрейфовать незаметно.
+RUN pnpm install --frozen-lockfile
+
+# Сборка всех пакетов через lerna-граф (зависимости собираются в
+# правильном порядке). Никаких --filter — пусть собирается всё, чтобы
+# образ годился любому потребителю mono-base.
+RUN lerna run build
+
+# Удалить devDeps из всех workspace node_modules. Это и есть основная
+# оптимизация размера — typescript, vitest, eslint, unbuild, ts-node-cli,
+# desktop-сборщики и пр. удаляются из финального дерева.
+#
+#  - `CI=true` отключает интерактивный prompt («вы уверены что снести
+#    modules?») — без TTY pnpm иначе абортится с
+#    ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY.
+#  - `--ignore-scripts` подавляет lifecycle hooks (prepare/postinstall)
+#    после prune. Иначе pnpm дёргает `quasar prepare` в desktop'е,
+#    а quasar (devDep) уже снесён → ELIFECYCLE.
+#
+# Все production-сервисы переведены на runtime без devDeps:
+#   cooparser     → `node ./dist/index.cjs`
+#   notifications → `node ./dist/sync/sync-runner.cjs` (entry добавлен в unbuild)
+#   coopback      → `ts-node` + `tsconfig-paths` (оба в deps)
+#   desktop       → `node dist/ssr/index.js`
+#   boot:remote   → `node /app/components/boot/dist/index.cjs boot:remote`
+RUN CI=true pnpm prune --prod --ignore-scripts
+
+# ── Stage 2: runtime ──────────────────────────────────────────────────
+FROM node:22-slim AS runtime
+
+WORKDIR /app
+
+# Только runtime-библиотеки WeasyPrint (без `-dev` headers и без gcc).
+# `python3` нужен потому что venv в /venv/bin/python — символическая
+# ссылка на системный интерпретатор; без него `weasyprint` падает с
+# `python: not found`. `procps`/`wget` — для дебага/healthcheck'ов
+# из docker-compose.
+#
+# `ca-certificates` обязателен: node:22-slim его не содержит, а
+# native-биндинги типа @livekit/rtc-node (Rust + rustls + rustls-native-certs)
+# читают корни ТОЛЬКО из системного store. Без файла
+# /etc/ssl/certs/ca-certificates.crt любой TLS handshake из такого
+# биндинга падает с "invalid peer certificate: UnknownIssuer" —
+# даже для валидной LE-цепочки (Node-стек при этом работает,
+# у него свои вшитые корни). Инцидент 2026-05-21: secretary в
+# coopback не мог подключиться к wss://chatcooprtc.coopenomics.world.
+RUN apt-get update && apt-get install -y --no-install-recommends \
+      ca-certificates \
+      python3 \
+      libpango-1.0-0 libpangoft2-1.0-0 libpangocairo-1.0-0 libcairo2 \
+      libffi8 libjpeg62-turbo libopenjp2-7 zlib1g shared-mime-info \
+      procps wget \
+ && rm -rf /var/lib/apt/lists/* \
+ && update-ca-certificates
+
+# Python venv с WeasyPrint, готовый к использованию.
+COPY --from=builder /venv /venv
+ENV PATH="/venv/bin:$PATH"
+
+# Приложение целиком (с уже урезанными до prod node_modules).
+COPY --from=builder /app /app
+
+# Глобальные pnpm/lerna — нужны чтобы потребители mono-base могли
+# делать `CMD ["pnpm","-F","<pkg>","run","start"]` в production.
+# pnpm активируется через corepack (версия из `packageManager` корневого
+# package.json — синхронно со builder-стадией).
+RUN corepack enable && npm install -g lerna --no-fund --no-audit
+
+# Sanity-check: WeasyPrint работает и виден через PATH.
+RUN weasyprint --version

README.md

@@ -0,0 +1,120 @@
+# Цифровой Кооператив
+
+<!-- badges -->
+![License](https://img.shields.io/badge/license-BY--NC--SA%204.0-blue)
+![Node](https://img.shields.io/badge/node-%3E%3D20-green)
+![pnpm](https://img.shields.io/badge/pnpm-9-orange)
+
+Платформа «Цифровой Кооператив» — комплексное программное обеспечение для управления кооперативными организациями на основе блокчейна EOSIO. Система обеспечивает полный цикл управления кооперативом: от регистрации пайщиков и электронного документооборота до проведения собраний и финансового учёта. Построена на принципах прозрачности, децентрализации и простой электронной подписи.
+
+Проект является частью экосистемы [Кооперативная Экономика](https://coopenomics.world).
+
+## Архитектура
+
+| Компонент | Пакет | Описание |
+|-----------|-------|----------|
+| [boot](components/boot) | `@coopenomics/boot` | CLI для инициализации и управления блокчейн-инфраструктурой |
+| [cleos](components/cleos) | `@coopenomics/cleos` | Утилита командной строки для работы с блокчейн-кошельком |
+| [contracts](components/contracts) | `@coopenomics/contracts` | Смарт-контракты EOSIO на C++ |
+| [controller](components/controller) | `@coopenomics/controller` | GraphQL API сервер (NestJS) |
+| [cooptypes](components/cooptypes) | `cooptypes` | Общие типы и интерфейсы блокчейн-контрактов |
+| [desktop](components/desktop) | `@coopenomics/desktop` | Рабочий стол кооператива (Vue 3 + Quasar) |
+| [factory](components/factory) | `@coopenomics/factory` | Генератор юридических документов |
+| [migrator](components/migrator) | `migrator` | Утилита миграции данных |
+| [notifications](components/notifications) | `@coopenomics/notifications` | Библиотека уведомлений на основе Novu |
+| [parser](components/parser) | `@coopenomics/parser` | Индексатор блокчейна через State History Plugin |
+| [sdk](components/sdk) | `@coopenomics/sdk` | TypeScript SDK для GraphQL API |
+| [setup](components/setup) | `@coopenomics/setup` | Мастер первоначальной настройки |
+
+## Быстрый старт
+
+### Предварительные требования
+
+- Node.js >= 20
+- pnpm 9
+- Docker и Docker Compose
+- [WeasyPrint](https://doc.courtbouillon.org/weasyprint/stable/first_steps.html#installation) (для генерации PDF)
+
+### Установка
+
+```bash
+pnpm install
+```
+
+### Конфигурация
+
+```bash
+pnpm run setup
+```
+
+Интерактивный мастер создаст необходимые `.env` файлы для всех компонентов.
+
+### Запуск инфраструктуры
+
+```bash
+docker compose up -d
+pnpm run reboot
+```
+
+## Разработка
+
+### Бэкенд (controller + parser)
+
+```bash
+pnpm run dev:backend
+```
+
+### Фронтенд (desktop)
+
+```bash
+pnpm run dev:desktop
+```
+
+### Библиотеки (factory + cooptypes)
+
+```bash
+pnpm run dev:lib
+```
+
+### Все сервисы одновременно
+
+```bash
+pnpm run dev:all
+```
+
+> **Примечание:** установка пакетов производится только через фильтр: `pnpm add <пакет> --filter <компонент>`
+
+## Тестирование
+
+```bash
+# Все тесты
+pnpm run test
+
+# Юнит-тесты (cooptypes, parser, notifications)
+pnpm run test:unit
+
+# Компонентные тесты (factory)
+pnpm run test:component
+
+# Интеграционные тесты (boot + blockchain)
+pnpm run test:integration
+```
+
+## Сборка
+
+```bash
+# Библиотеки (cooptypes, factory)
+pnpm run build:lib
+
+# Смарт-контракты
+pnpm run build:contracts:all
+
+# Desktop (SSR)
+pnpm --filter @coopenomics/desktop run build
+```
+
+## Лицензия
+
+Продукт Потребительского Кооператива «ВОСХОД» распространяется по лицензии [BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.ru).
+
+Разрешено делиться, копировать и распространять материал, адаптировать и создавать производные произведения при условии указания авторства и сохранения той же лицензии. Коммерческое использование запрещено.

SUMMARY.md

@@ -0,0 +1,129 @@
+# 📋 Резюме создания компонентов Notifications
+
+## ✅ Что создано
+
+### 1. 📚 Библиотека `@monocoop/notifications`
+**Расположение:** `components/notifications/`
+
+**Функции:**
+- ✅ Типизированные интерфейсы для workflow с Zod
+- ✅ Builder паттерн для создания workflow
+- ✅ Базовые шаблоны для email, in-app, push, SMS
+- ✅ Автоматическая конвертация Zod схем в JSON Schema для Novu
+- ✅ Экспорт всех workflow для использования в других пакетах
+
+**Структура:**
+```
+src/
+├── types/              # Базовые типы и интерфейсы
+├── base/               # Утилиты и настройки по умолчанию
+├── workflows/          # Папки с workflow
+│   └── welcome/        # Пример приветственного workflow
+└── index.ts           # Главный экспорт
+```
+
+### 2. 🚀 NestJS приложение `@monocoop/notificator2`
+**Расположение:** `components/notificator2/`
+
+**Функции:**
+- ✅ Автоматический upsert всех workflow в Novu при запуске
+- ✅ RESTful API для триггера уведомлений
+- ✅ Типизированная валидация payload
+- ✅ Health check endpoints
+- ✅ Использует библиотеку notifications для типов
+
+**API Endpoints:**
+- `GET /api/notifications/health` - Health check
+- `GET /api/notifications/workflows` - Список workflow
+- `POST /api/notifications/trigger` - Универсальный триггер
+- `POST /api/notifications/trigger/welcome` - Триггер welcome workflow
+- `POST /api/notifications/workflows/upsert-all` - Принудительный upsert
+
+## 🔧 Как использовать
+
+### 1. Настройка библиотеки notifications
+```bash
+cd components/notifications
+pnpm install  # или npm install
+pnpm build    # для компиляции TypeScript
+```
+
+### 2. Настройка notificator2
+```bash
+cd components/notificator2
+pnpm install  # или npm install
+
+# Настройка окружения
+cp .env.example .env
+# Добавить NOVU_API_KEY в .env
+
+# Запуск
+pnpm start:dev
+```
+
+### 3. Добавление нового workflow
+
+**В библиотеке notifications:**
+```typescript
+// components/notifications/src/workflows/order/order-workflow.ts
+export const orderWorkflow = WorkflowBuilder
+  .create<OrderPayload>()
+  .name('Order Confirmation')
+  .workflowId('order-confirmation')
+  .payloadSchema(orderPayloadSchema)
+  .addSteps([...])
+  .build();
+```
+
+**Регистрация в index.ts:**
+```typescript
+// components/notifications/src/workflows/index.ts
+import { orderWorkflow } from './order';
+
+export const allWorkflows = [
+  welcomeWorkflow,
+  orderWorkflow,  // ← добавить новый workflow
+];
+```
+
+### 4. Использование API
+
+**Триггер welcome workflow:**
+```bash
+curl -X POST http://localhost:3000/api/notifications/trigger/welcome \
+  -H "Content-Type: application/json" \
+  -d '{
+    "subscriberId": "user-123",
+    "email": "user@example.com",
+    "payload": {
+      "userName": "Иван Иванов",
+      "userEmail": "user@example.com",
+      "age": 25
+    }
+  }'
+```
+
+## 🎯 Преимущества архитектуры
+
+1. **Типобезопасность** - Zod схемы обеспечивают валидацию на уровне TypeScript и runtime
+2. **Разделение ответственности** - Библиотека содержит только типы, сервер - логику
+3. **Расширяемость** - Легко добавлять новые workflow
+4. **Автоматизация** - Workflow автоматически синхронизируются с Novu
+5. **Переиспользование** - Типы можно использовать в других частях системы
+
+## 🔄 Workflow при запуске
+
+1. **Запуск notificator2** → 
+2. **Чтение всех workflow из библиотеки** → 
+3. **Проверка существования в Novu** → 
+4. **Создание/обновление workflow** → 
+5. **Готов к приёму запросов на триггеры**
+
+## 📁 Структура как в testFramework2.ts
+
+Вся логика из `testFramework2.ts` была перенесена в structured архитектуру:
+- ✅ `buildWorkflowData` → `WorkflowBuilder`
+- ✅ `baseSteps` → `createEmailStep`, `createInAppStep`, etc.
+- ✅ `upsertWorkflow` → `NovuService.upsertWorkflow`
+- ✅ `triggerWorkflow` → `NovuService.triggerWorkflow`
+- ✅ Типизация payload → Zod схемы + TypeScript типы

TASKS.md

@@ -0,0 +1,55 @@
+# TASKS.md — Прогресс выполнения задач
+
+## Завершённые задачи
+
+### 1-6. Предыдущие задачи (см. git history)
+- ✅ Dev-окружение, Security, Тесты, README, AGENTS.md, Setup
+- ✅ Поисковая система документов (OpenSearch)
+- ✅ Процессы (Capital extension)
+
+---
+
+## Текущая задача: Генерация отчётов ФНС (расширение reports)
+
+### Документы ФНС для генерации:
+1. **6-НДФЛ** — ежеквартально (XSD: NO_NDFL6.2)
+2. **4-ФСС (ЕФС-1)** — ежеквартально  
+3. **РСВ** — ежеквартально (XSD: NO_RASCHSV)
+4. **ПСВ** — ежемесячно (XSD: NO_PERSSVFL)
+5. **Бухгалтерский баланс** — ежегодно (XSD: NO_BUHOTCH) — КЛЮЧЕВОЙ
+6. **ДУСН** — декларация УСН ежегодно (XSD: NO_USN)
+7. **Уведомление о страховых взносах** — ежемесячно с 2026 (XSD: UT_UVISCHSUMNAL)
+8. **УУСН** — уведомление УСН
+### 10. Генерация отчётов ФНС (доработка) ✅
+- [x] Фабрика генераторов (ReportRegistryService)
+- [x] 8 генераторов (Бухбаланс, 6-НДФЛ, РСВ, ПСВ, ДУСН, 4-ФСС, Увед. взносы, УУСН)
+- [x] GraphQL API (getAvailableReports, generateReport)
+- [x] Генераторы переписаны по XSD — структура соответствует схемам ФНС
+- [x] 48 unit-тестов для всех генераторов
+- [x] Desktop UI (страница отчётов) — расширение reports
+- [x] Интеграция с реальными данными ledger через LedgerInteractor
+- [x] OrganizationDataInput DTO для передачи данных организации
+
+### Архитектура:
+- Расширение `reports` в `components/controller/src/extensions/`
+- Фабрика XML отчётов: на вход данные за период → на выходе XML
+- Валидация по XSD схемам
+- Desktop UI: магазин приложений → установка → рабочий стол отчётов
+
+### Подзадачи:
+
+- [x] **8.1 Исследование**: Все XSD разобраны, format.nalog.ru изучен
+- [x] **8.2 Инфраструктура**: Расширение reports, ReportRegistryService (фабрика)
+- [x] **8.3 XML генератор**: Фабричный подход — IReportGenerator interface
+- [x] **8.4 Бухбаланс**: BuhotchGenerator — счета 51, 80, 86 из ledger
+- [x] **8.5 6-НДФЛ**: Ndfl6Generator — нулевая
+- [x] **8.6 4-ФСС**: Zero generator — нулевая
+- [x] **8.7 РСВ**: Zero generator — нулевая
+- [x] **8.8 ПСВ**: Zero generator — нулевая
+- [x] **8.9 ДУСН**: Zero generator — нулевая
+- [x] **8.10 Уведомление о взносах**: Zero generator — нулевая
+- [x] **8.11 УУСН**: Zero generator — нулевая
+- [x] **8.12 GraphQL API**: getAvailableReports + generateReport
+- [ ] **8.13 XSD валидация + тесты**: Проверка по схемам
+- [ ] **8.14 Desktop UI**: Страница отчётов в магазине приложений
+- [ ] **8.15 Ledger интеграция**: Реальные данные из ledger_operations

TEST_PLAN.md

@@ -0,0 +1,64 @@
+# Test Plan — pnpm run test
+
+## Архитектура
+```
+pnpm run test
+├── cooptypes    — vitest run (smoke tests exports)           ✅ 4/4
+├── parser       — vitest run (config smoke tests)            ✅ 3/3
+├── factory      — vitest run (document generation tests)     🔧 17/85 → need mocks
+├── sdk          — vitest run (API integration tests)         🔧 TODO
+├── notifications — vitest run (workflow tests)               🔧 TODO
+├── controller   — jest / vitest (NestJS unit tests)          🔧 TODO
+└── boot         — vitest run (blockchain integration)        🔧 53/60
+```
+
+## Статус по компонентам
+
+### cooptypes ✅ DONE
+- 4 smoke-теста экспортов
+- Не требует инфраструктуры
+
+### parser ✅ DONE
+- 3 smoke-теста конфигурации
+- Не требует инфраструктуры
+
+### factory 🔧 IN PROGRESS
+- **Проблема**: тесты обращаются к parser API (`SIMPLE_EXPLORER_API`) для get-tables/get-actions
+- **Решение**: Уже есть мок-система в `src/Utils/testMocks.ts` + `matchMock.ts`
+- **Нужно**: Добавить моки для ВСЕХ документов:
+  - [ ] cooperative data mock (registrator.coops table)
+  - [ ] soviet boards mock — уже есть через test setup в MongoDB
+  - [ ] draft templates mock (draft.drafts + draft.translations tables)
+  - [ ] decision data mocks (soviet.decisions table)
+  - [ ] Мок для ReturnByMoney документов
+  - [ ] Все документы 1000+ серии
+- **Текущие рабочие моки**: meet tables, votefor actions, returnByMoneyDecision actions
+- **После мокирования**: все 85 тестов должны проходить
+
+### boot 🔧 NEEDS REBOOT
+- capital.test — 53/60 тестов проходят (после чистого reboot)
+- wallet.test — нужен полный boot с agreements
+- registrator.test — нужен полный boot
+- capital-import.test — отдельный тест импорта
+- **Требует**: pnpm run reboot перед запуском
+
+### sdk 🔧 TODO
+- 1 тест файл с login + fetch extensions
+- Требует запущенный controller
+- Нужно: обновить chain_id, api_url, credentials
+
+### controller 🔧 TODO
+- Все старые тесты удалены (устаревшие)
+- NestJS-приложение — нужны тесты через @nestjs/testing
+- Минимум: unit-тесты domain-логики, smoke-тест GraphQL API
+
+### notifications 🔧 TODO
+- Нет тестов
+- Нужно: smoke-тесты workflow builder
+
+### desktop — SKIP (нет тестов, UI-тестирование)
+
+## Root script требования
+- `pnpm run test` — запускает ВСЕ тесты
+- fail-fast: если один пакет падает — весь pipeline падает
+- Последовательный запуск (не параллельный)

assets/javascripts/lunr/min/lunr.da.min.js

@@ -1,18 +0,0 @@
-/*!
- * Lunr languages, `Danish` language
- * https://github.com/MihaiValentin/lunr-languages
- *
- * Copyright 2014, Mihai Valentin
- * http://www.mozilla.org/MPL/
- */
-/*!
- * based on
- * Snowball JavaScript Library v0.3
- * http://code.google.com/p/urim/
- * http://snowball.tartarus.org/
- *
- * Copyright 2010, Oleg Mazko
- * http://www.mozilla.org/MPL/
- */
-
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.da=function(){this.pipeline.reset(),this.pipeline.add(e.da.trimmer,e.da.stopWordFilter,e.da.stemmer),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add(e.da.stemmer))},e.da.wordCharacters="A-Za-zªºÀ-ÖØ-öø-ʸˠ-ˤᴀ-ᴥᴬ-ᵜᵢ-ᵥᵫ-ᵷᵹ-ᶾḀ-ỿⁱⁿₐ-ₜKÅℲⅎⅠ-ↈⱠ-ⱿꜢ-ꞇꞋ-ꞭꞰ-ꞷꟷ-ꟿꬰ-ꭚꭜ-ꭤff-stＡ-Ｚａ-ｚ",e.da.trimmer=e.trimmerSupport.generateTrimmer(e.da.wordCharacters),e.Pipeline.registerFunction(e.da.trimmer,"trimmer-da"),e.da.stemmer=function(){var r=e.stemmerSupport.Among,i=e.stemmerSupport.SnowballProgram,n=new function(){function e(){var e,r=f.cursor+3;if(d=f.limit,0<=r&&r<=f.limit){for(a=r;;){if(e=f.cursor,f.in_grouping(w,97,248)){f.cursor=e;break}if(f.cursor=e,e>=f.limit)return;f.cursor++}for(;!f.out_grouping(w,97,248);){if(f.cursor>=f.limit)return;f.cursor++}d=f.cursor,d<a&&(d=a)}}function n(){var e,r;if(f.cursor>=d&&(r=f.limit_backward,f.limit_backward=d,f.ket=f.cursor,e=f.find_among_b(c,32),f.limit_backward=r,e))switch(f.bra=f.cursor,e){case 1:f.slice_del();break;case 2:f.in_grouping_b(p,97,229)&&f.slice_del()}}function t(){var e,r=f.limit-f.cursor;f.cursor>=d&&(e=f.limit_backward,f.limit_backward=d,f.ket=f.cursor,f.find_among_b(l,4)?(f.bra=f.cursor,f.limit_backward=e,f.cursor=f.limit-r,f.cursor>f.limit_backward&&(f.cursor--,f.bra=f.cursor,f.slice_del())):f.limit_backward=e)}function s(){var e,r,i,n=f.limit-f.cursor;if(f.ket=f.cursor,f.eq_s_b(2,"st")&&(f.bra=f.cursor,f.eq_s_b(2,"ig")&&f.slice_del()),f.cursor=f.limit-n,f.cursor>=d&&(r=f.limit_backward,f.limit_backward=d,f.ket=f.cursor,e=f.find_among_b(m,5),f.limit_backward=r,e))switch(f.bra=f.cursor,e){case 1:f.slice_del(),i=f.limit-f.cursor,t(),f.cursor=f.limit-i;break;case 2:f.slice_from("løs")}}function o(){var e;f.cursor>=d&&(e=f.limit_backward,f.limit_backward=d,f.ket=f.cursor,f.out_grouping_b(w,97,248)?(f.bra=f.cursor,u=f.slice_to(u),f.limit_backward=e,f.eq_v_b(u)&&f.slice_del()):f.limit_backward=e)}var a,d,u,c=[new r("hed",-1,1),new r("ethed",0,1),new r("ered",-1,1),new r("e",-1,1),new r("erede",3,1),new r("ende",3,1),new r("erende",5,1),new r("ene",3,1),new r("erne",3,1),new r("ere",3,1),new r("en",-1,1),new r("heden",10,1),new r("eren",10,1),new r("er",-1,1),new r("heder",13,1),new r("erer",13,1),new r("s",-1,2),new r("heds",16,1),new r("es",16,1),new r("endes",18,1),new r("erendes",19,1),new r("enes",18,1),new r("ernes",18,1),new r("eres",18,1),new r("ens",16,1),new r("hedens",24,1),new r("erens",24,1),new r("ers",16,1),new r("ets",16,1),new r("erets",28,1),new r("et",-1,1),new r("eret",30,1)],l=[new r("gd",-1,-1),new r("dt",-1,-1),new r("gt",-1,-1),new r("kt",-1,-1)],m=[new r("ig",-1,1),new r("lig",0,1),new r("elig",1,1),new r("els",-1,1),new r("løst",-1,2)],w=[17,65,16,1,0,0,0,0,0,0,0,0,0,0,0,0,48,0,128],p=[239,254,42,3,0,0,0,0,0,0,0,0,0,0,0,0,16],f=new i;this.setCurrent=function(e){f.setCurrent(e)},this.getCurrent=function(){return f.getCurrent()},this.stem=function(){var r=f.cursor;return e(),f.limit_backward=r,f.cursor=f.limit,n(),f.cursor=f.limit,t(),f.cursor=f.limit,s(),f.cursor=f.limit,o(),!0}};return function(e){return"function"==typeof e.update?e.update(function(e){return n.setCurrent(e),n.stem(),n.getCurrent()}):(n.setCurrent(e),n.stem(),n.getCurrent())}}(),e.Pipeline.registerFunction(e.da.stemmer,"stemmer-da"),e.da.stopWordFilter=e.generateStopWordFilter("ad af alle alt anden at blev blive bliver da de dem den denne der deres det dette dig din disse dog du efter eller en end er et for fra ham han hans har havde have hende hendes her hos hun hvad hvis hvor i ikke ind jeg jer jo kunne man mange med meget men mig min mine mit mod ned noget nogle nu når og også om op os over på selv sig sin sine sit skal skulle som sådan thi til ud under var vi vil ville vor være været".split(" ")),e.Pipeline.registerFunction(e.da.stopWordFilter,"stopWordFilter-da")}});

assets/javascripts/lunr/min/lunr.hi.min.js

@@ -1 +0,0 @@
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.hi=function(){this.pipeline.reset(),this.pipeline.add(e.hi.trimmer,e.hi.stopWordFilter,e.hi.stemmer),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add(e.hi.stemmer))},e.hi.wordCharacters="ऀ-ःऄ-एऐ-टठ-यर-िी-ॏॐ-य़ॠ-९॰-ॿa-zA-Zａ-ｚＡ-Ｚ0-9０-９",e.hi.trimmer=e.trimmerSupport.generateTrimmer(e.hi.wordCharacters),e.Pipeline.registerFunction(e.hi.trimmer,"trimmer-hi"),e.hi.stopWordFilter=e.generateStopWordFilter("अत अपना अपनी अपने अभी अंदर आदि आप इत्यादि इन इनका इन्हीं इन्हें इन्हों इस इसका इसकी इसके इसमें इसी इसे उन उनका उनकी उनके उनको उन्हीं उन्हें उन्हों उस उसके उसी उसे एक एवं एस ऐसे और कई कर करता करते करना करने करें कहते कहा का काफ़ी कि कितना किन्हें किन्हों किया किर किस किसी किसे की कुछ कुल के को कोई कौन कौनसा गया घर जब जहाँ जा जितना जिन जिन्हें जिन्हों जिस जिसे जीधर जैसा जैसे जो तक तब तरह तिन तिन्हें तिन्हों तिस तिसे तो था थी थे दबारा दिया दुसरा दूसरे दो द्वारा न नके नहीं ना निहायत नीचे ने पर पहले पूरा पे फिर बनी बही बहुत बाद बाला बिलकुल भी भीतर मगर मानो मे में यदि यह यहाँ यही या यिह ये रखें रहा रहे ऱ्वासा लिए लिये लेकिन व वग़ैरह वर्ग वह वहाँ वहीं वाले वुह वे वो सकता सकते सबसे सभी साथ साबुत साभ सारा से सो संग ही हुआ हुई हुए है हैं हो होता होती होते होना होने".split(" ")),e.hi.stemmer=function(){return function(e){return"function"==typeof e.update?e.update(function(e){return e}):e}}();var r=e.wordcut;r.init(),e.hi.tokenizer=function(i){if(!arguments.length||null==i||void 0==i)return[];if(Array.isArray(i))return i.map(function(r){return isLunr2?new e.Token(r.toLowerCase()):r.toLowerCase()});var t=i.toString().toLowerCase().replace(/^\s+/,"");return r.cut(t).split("|")},e.Pipeline.registerFunction(e.hi.stemmer,"stemmer-hi"),e.Pipeline.registerFunction(e.hi.stopWordFilter,"stopWordFilter-hi")}});

assets/javascripts/lunr/min/lunr.hy.min.js

@@ -1 +0,0 @@
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.hy=function(){this.pipeline.reset(),this.pipeline.add(e.hy.trimmer,e.hy.stopWordFilter)},e.hy.wordCharacters="[A-Za-z԰-֏ff-ﭏ]",e.hy.trimmer=e.trimmerSupport.generateTrimmer(e.hy.wordCharacters),e.Pipeline.registerFunction(e.hy.trimmer,"trimmer-hy"),e.hy.stopWordFilter=e.generateStopWordFilter("դու և եք էիր էիք հետո նաև նրանք որը վրա է որ պիտի են այս մեջ ն իր ու ի այդ որոնք այն կամ էր մի ես համար այլ իսկ էին ենք հետ ին թ էինք մենք նրա նա դուք եմ էի ըստ որպես ում".split(" ")),e.Pipeline.registerFunction(e.hy.stopWordFilter,"stopWordFilter-hy"),e.hy.stemmer=function(){return function(e){return"function"==typeof e.update?e.update(function(e){return e}):e}}(),e.Pipeline.registerFunction(e.hy.stemmer,"stemmer-hy")}});

assets/javascripts/lunr/min/lunr.ja.min.js

@@ -1 +0,0 @@
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");var r="2"==e.version[0];e.ja=function(){this.pipeline.reset(),this.pipeline.add(e.ja.trimmer,e.ja.stopWordFilter,e.ja.stemmer),r?this.tokenizer=e.ja.tokenizer:(e.tokenizer&&(e.tokenizer=e.ja.tokenizer),this.tokenizerFn&&(this.tokenizerFn=e.ja.tokenizer))};var t=new e.TinySegmenter;e.ja.tokenizer=function(i){var n,o,s,p,a,u,m,l,c,f;if(!arguments.length||null==i||void 0==i)return[];if(Array.isArray(i))return i.map(function(t){return r?new e.Token(t.toLowerCase()):t.toLowerCase()});for(o=i.toString().toLowerCase().replace(/^\s+/,""),n=o.length-1;n>=0;n--)if(/\S/.test(o.charAt(n))){o=o.substring(0,n+1);break}for(a=[],s=o.length,c=0,l=0;c<=s;c++)if(u=o.charAt(c),m=c-l,u.match(/\s/)||c==s){if(m>0)for(p=t.segment(o.slice(l,c)).filter(function(e){return!!e}),f=l,n=0;n<p.length;n++)r?a.push(new e.Token(p[n],{position:[f,p[n].length],index:a.length})):a.push(p[n]),f+=p[n].length;l=c+1}return a},e.ja.stemmer=function(){return function(e){return e}}(),e.Pipeline.registerFunction(e.ja.stemmer,"stemmer-ja"),e.ja.wordCharacters="一二三四五六七八九十百千万億兆一-龠々〆ヵヶぁ-んァ-ヴーｱ-ﾝﾞa-zA-Zａ-ｚＡ-Ｚ0-9０-９",e.ja.trimmer=e.trimmerSupport.generateTrimmer(e.ja.wordCharacters),e.Pipeline.registerFunction(e.ja.trimmer,"trimmer-ja"),e.ja.stopWordFilter=e.generateStopWordFilter("これ それ あれ この その あの ここ そこ あそこ こちら どこ だれ なに なん 何 私 貴方 貴方方 我々 私達 あの人 あのかた 彼女 彼 です あります おります います は が の に を で え から まで より も どの と し それで しかし".split(" ")),e.Pipeline.registerFunction(e.ja.stopWordFilter,"stopWordFilter-ja"),e.jp=e.ja,e.Pipeline.registerFunction(e.jp.stemmer,"stemmer-jp"),e.Pipeline.registerFunction(e.jp.trimmer,"trimmer-jp"),e.Pipeline.registerFunction(e.jp.stopWordFilter,"stopWordFilter-jp")}});

assets/javascripts/lunr/min/lunr.jp.min.js

@@ -1 +0,0 @@
-module.exports=require("./lunr.ja");

assets/javascripts/lunr/min/lunr.kn.min.js

@@ -1 +0,0 @@
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.kn=function(){this.pipeline.reset(),this.pipeline.add(e.kn.trimmer,e.kn.stopWordFilter,e.kn.stemmer),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add(e.kn.stemmer))},e.kn.wordCharacters="ಀ-಄ಅ-ಔಕ-ಹಾ-ೌ಼-ಽೕ-ೖೝ-ೞೠ-ೡೢ-ೣ೤೥೦-೯ೱ-ೳ",e.kn.trimmer=e.trimmerSupport.generateTrimmer(e.kn.wordCharacters),e.Pipeline.registerFunction(e.kn.trimmer,"trimmer-kn"),e.kn.stopWordFilter=e.generateStopWordFilter("ಮತ್ತು ಈ ಒಂದು ರಲ್ಲಿ ಹಾಗೂ ಎಂದು ಅಥವಾ ಇದು ರ ಅವರು ಎಂಬ ಮೇಲೆ ಅವರ ತನ್ನ ಆದರೆ ತಮ್ಮ ನಂತರ ಮೂಲಕ ಹೆಚ್ಚು ನ ಆ ಕೆಲವು ಅನೇಕ ಎರಡು ಹಾಗು ಪ್ರಮುಖ ಇದನ್ನು ಇದರ ಸುಮಾರು ಅದರ ಅದು ಮೊದಲ ಬಗ್ಗೆ ನಲ್ಲಿ ರಂದು ಇತರ ಅತ್ಯಂತ ಹೆಚ್ಚಿನ ಸಹ ಸಾಮಾನ್ಯವಾಗಿ ನೇ ಹಲವಾರು ಹೊಸ ದಿ ಕಡಿಮೆ ಯಾವುದೇ ಹೊಂದಿದೆ ದೊಡ್ಡ ಅನ್ನು ಇವರು ಪ್ರಕಾರ ಇದೆ ಮಾತ್ರ ಕೂಡ ಇಲ್ಲಿ ಎಲ್ಲಾ ವಿವಿಧ ಅದನ್ನು ಹಲವು ರಿಂದ ಕೇವಲ ದ ದಕ್ಷಿಣ ಗೆ ಅವನ ಅತಿ ನೆಯ ಬಹಳ ಕೆಲಸ ಎಲ್ಲ ಪ್ರತಿ ಇತ್ಯಾದಿ ಇವು ಬೇರೆ ಹೀಗೆ ನಡುವೆ ಇದಕ್ಕೆ ಎಸ್ ಇವರ ಮೊದಲು ಶ್ರೀ ಮಾಡುವ ಇದರಲ್ಲಿ ರೀತಿಯ ಮಾಡಿದ ಕಾಲ ಅಲ್ಲಿ ಮಾಡಲು ಅದೇ ಈಗ ಅವು ಗಳು ಎ ಎಂಬುದು ಅವನು ಅಂದರೆ ಅವರಿಗೆ ಇರುವ ವಿಶೇಷ ಮುಂದೆ ಅವುಗಳ ಮುಂತಾದ ಮೂಲ ಬಿ ಮೀ ಒಂದೇ ಇನ್ನೂ ಹೆಚ್ಚಾಗಿ ಮಾಡಿ ಅವರನ್ನು ಇದೇ ಯ ರೀತಿಯಲ್ಲಿ ಜೊತೆ ಅದರಲ್ಲಿ ಮಾಡಿದರು ನಡೆದ ಆಗ ಮತ್ತೆ ಪೂರ್ವ ಆತ ಬಂದ ಯಾವ ಒಟ್ಟು ಇತರೆ ಹಿಂದೆ ಪ್ರಮಾಣದ ಗಳನ್ನು ಕುರಿತು ಯು ಆದ್ದರಿಂದ ಅಲ್ಲದೆ ನಗರದ ಮೇಲಿನ ಏಕೆಂದರೆ ರಷ್ಟು ಎಂಬುದನ್ನು ಬಾರಿ ಎಂದರೆ ಹಿಂದಿನ ಆದರೂ ಆದ ಸಂಬಂಧಿಸಿದ ಮತ್ತೊಂದು ಸಿ ಆತನ ".split(" ")),e.kn.stemmer=function(){return function(e){return"function"==typeof e.update?e.update(function(e){return e}):e}}();var r=e.wordcut;r.init(),e.kn.tokenizer=function(t){if(!arguments.length||null==t||void 0==t)return[];if(Array.isArray(t))return t.map(function(r){return isLunr2?new e.Token(r.toLowerCase()):r.toLowerCase()});var n=t.toString().toLowerCase().replace(/^\s+/,"");return r.cut(n).split("|")},e.Pipeline.registerFunction(e.kn.stemmer,"stemmer-kn"),e.Pipeline.registerFunction(e.kn.stopWordFilter,"stopWordFilter-kn")}});

assets/javascripts/lunr/min/lunr.multi.min.js

@@ -1 +0,0 @@
-!function(e,t){"function"==typeof define&&define.amd?define(t):"object"==typeof exports?module.exports=t():t()(e.lunr)}(this,function(){return function(e){e.multiLanguage=function(){for(var t=Array.prototype.slice.call(arguments),i=t.join("-"),r="",n=[],s=[],p=0;p<t.length;++p)"en"==t[p]?(r+="\\w",n.unshift(e.stopWordFilter),n.push(e.stemmer),s.push(e.stemmer)):(r+=e[t[p]].wordCharacters,e[t[p]].stopWordFilter&&n.unshift(e[t[p]].stopWordFilter),e[t[p]].stemmer&&(n.push(e[t[p]].stemmer),s.push(e[t[p]].stemmer)));var o=e.trimmerSupport.generateTrimmer(r);return e.Pipeline.registerFunction(o,"lunr-multi-trimmer-"+i),n.unshift(o),function(){this.pipeline.reset(),this.pipeline.add.apply(this.pipeline,n),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add.apply(this.searchPipeline,s))}}}});

assets/javascripts/lunr/min/lunr.no.min.js

@@ -1,18 +0,0 @@
-/*!
- * Lunr languages, `Norwegian` language
- * https://github.com/MihaiValentin/lunr-languages
- *
- * Copyright 2014, Mihai Valentin
- * http://www.mozilla.org/MPL/
- */
-/*!
- * based on
- * Snowball JavaScript Library v0.3
- * http://code.google.com/p/urim/
- * http://snowball.tartarus.org/
- *
- * Copyright 2010, Oleg Mazko
- * http://www.mozilla.org/MPL/
- */
-
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.no=function(){this.pipeline.reset(),this.pipeline.add(e.no.trimmer,e.no.stopWordFilter,e.no.stemmer),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add(e.no.stemmer))},e.no.wordCharacters="A-Za-zªºÀ-ÖØ-öø-ʸˠ-ˤᴀ-ᴥᴬ-ᵜᵢ-ᵥᵫ-ᵷᵹ-ᶾḀ-ỿⁱⁿₐ-ₜKÅℲⅎⅠ-ↈⱠ-ⱿꜢ-ꞇꞋ-ꞭꞰ-ꞷꟷ-ꟿꬰ-ꭚꭜ-ꭤff-stＡ-Ｚａ-ｚ",e.no.trimmer=e.trimmerSupport.generateTrimmer(e.no.wordCharacters),e.Pipeline.registerFunction(e.no.trimmer,"trimmer-no"),e.no.stemmer=function(){var r=e.stemmerSupport.Among,n=e.stemmerSupport.SnowballProgram,i=new function(){function e(){var e,r=w.cursor+3;if(a=w.limit,0<=r||r<=w.limit){for(s=r;;){if(e=w.cursor,w.in_grouping(d,97,248)){w.cursor=e;break}if(e>=w.limit)return;w.cursor=e+1}for(;!w.out_grouping(d,97,248);){if(w.cursor>=w.limit)return;w.cursor++}a=w.cursor,a<s&&(a=s)}}function i(){var e,r,n;if(w.cursor>=a&&(r=w.limit_backward,w.limit_backward=a,w.ket=w.cursor,e=w.find_among_b(m,29),w.limit_backward=r,e))switch(w.bra=w.cursor,e){case 1:w.slice_del();break;case 2:n=w.limit-w.cursor,w.in_grouping_b(c,98,122)?w.slice_del():(w.cursor=w.limit-n,w.eq_s_b(1,"k")&&w.out_grouping_b(d,97,248)&&w.slice_del());break;case 3:w.slice_from("er")}}function t(){var e,r=w.limit-w.cursor;w.cursor>=a&&(e=w.limit_backward,w.limit_backward=a,w.ket=w.cursor,w.find_among_b(u,2)?(w.bra=w.cursor,w.limit_backward=e,w.cursor=w.limit-r,w.cursor>w.limit_backward&&(w.cursor--,w.bra=w.cursor,w.slice_del())):w.limit_backward=e)}function o(){var e,r;w.cursor>=a&&(r=w.limit_backward,w.limit_backward=a,w.ket=w.cursor,e=w.find_among_b(l,11),e?(w.bra=w.cursor,w.limit_backward=r,1==e&&w.slice_del()):w.limit_backward=r)}var s,a,m=[new r("a",-1,1),new r("e",-1,1),new r("ede",1,1),new r("ande",1,1),new r("ende",1,1),new r("ane",1,1),new r("ene",1,1),new r("hetene",6,1),new r("erte",1,3),new r("en",-1,1),new r("heten",9,1),new r("ar",-1,1),new r("er",-1,1),new r("heter",12,1),new r("s",-1,2),new r("as",14,1),new r("es",14,1),new r("edes",16,1),new r("endes",16,1),new r("enes",16,1),new r("hetenes",19,1),new r("ens",14,1),new r("hetens",21,1),new r("ers",14,1),new r("ets",14,1),new r("et",-1,1),new r("het",25,1),new r("ert",-1,3),new r("ast",-1,1)],u=[new r("dt",-1,-1),new r("vt",-1,-1)],l=[new r("leg",-1,1),new r("eleg",0,1),new r("ig",-1,1),new r("eig",2,1),new r("lig",2,1),new r("elig",4,1),new r("els",-1,1),new r("lov",-1,1),new r("elov",7,1),new r("slov",7,1),new r("hetslov",9,1)],d=[17,65,16,1,0,0,0,0,0,0,0,0,0,0,0,0,48,0,128],c=[119,125,149,1],w=new n;this.setCurrent=function(e){w.setCurrent(e)},this.getCurrent=function(){return w.getCurrent()},this.stem=function(){var r=w.cursor;return e(),w.limit_backward=r,w.cursor=w.limit,i(),w.cursor=w.limit,t(),w.cursor=w.limit,o(),!0}};return function(e){return"function"==typeof e.update?e.update(function(e){return i.setCurrent(e),i.stem(),i.getCurrent()}):(i.setCurrent(e),i.stem(),i.getCurrent())}}(),e.Pipeline.registerFunction(e.no.stemmer,"stemmer-no"),e.no.stopWordFilter=e.generateStopWordFilter("alle at av bare begge ble blei bli blir blitt både båe da de deg dei deim deira deires dem den denne der dere deres det dette di din disse ditt du dykk dykkar då eg ein eit eitt eller elles en enn er et ett etter for fordi fra før ha hadde han hans har hennar henne hennes her hjå ho hoe honom hoss hossen hun hva hvem hver hvilke hvilken hvis hvor hvordan hvorfor i ikke ikkje ikkje ingen ingi inkje inn inni ja jeg kan kom korleis korso kun kunne kva kvar kvarhelst kven kvi kvifor man mange me med medan meg meget mellom men mi min mine mitt mot mykje ned no noe noen noka noko nokon nokor nokre nå når og også om opp oss over på samme seg selv si si sia sidan siden sin sine sitt sjøl skal skulle slik so som som somme somt så sånn til um upp ut uten var vart varte ved vere verte vi vil ville vore vors vort vår være være vært å".split(" ")),e.Pipeline.registerFunction(e.no.stopWordFilter,"stopWordFilter-no")}});

assets/javascripts/lunr/min/lunr.sa.min.js

@@ -1 +0,0 @@
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.sa=function(){this.pipeline.reset(),this.pipeline.add(e.sa.trimmer,e.sa.stopWordFilter,e.sa.stemmer),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add(e.sa.stemmer))},e.sa.wordCharacters="ऀ-ःऄ-एऐ-टठ-यर-िी-ॏॐ-य़ॠ-९॰-ॿ꣠-꣱ꣲ-ꣷ꣸-ꣻ꣼-ꣽꣾ-ꣿᆰ0-ᆰ9",e.sa.trimmer=e.trimmerSupport.generateTrimmer(e.sa.wordCharacters),e.Pipeline.registerFunction(e.sa.trimmer,"trimmer-sa"),e.sa.stopWordFilter=e.generateStopWordFilter('तथा अयम्‌ एकम्‌ इत्यस्मिन्‌ तथा तत्‌ वा अयम्‌ इत्यस्य ते आहूत उपरि तेषाम्‌  किन्तु तेषाम्‌ तदा इत्यनेन अधिकः इत्यस्य तत्‌ केचन बहवः द्वि तथा महत्वपूर्णः अयम्‌ अस्य  विषये अयं अस्ति तत्‌ प्रथमः विषये इत्युपरि इत्युपरि इतर अधिकतमः अधिकः अपि सामान्यतया ठ इतरेतर नूतनम्‌ द  न्यूनम्‌ कश्चित्‌ वा विशालः द  सः अस्ति तदनुसारम् तत्र अस्ति केवलम्‌ अपि अत्र सर्वे विविधाः तत्‌ बहवः यतः इदानीम्‌ द  दक्षिण इत्यस्मै तस्य उपरि नथ अतीव कार्यम्‌ सर्वे एकैकम्‌ इत्यादि। एते सन्ति  उत इत्थम्‌ मध्ये एतदर्थं . स कस्य प्रथमः श्री. करोति अस्मिन् प्रकारः निर्मिता कालः तत्र कर्तुं  समान अधुना ते सन्ति स एकः अस्ति सः अर्थात् तेषां कृते . स्थितम्  विशेषः अग्रिम तेषाम्‌ समान स्रोतः ख म समान इदानीमपि अधिकतया करोतु ते समान इत्यस्य वीथी सह यस्मिन्  कृतवान्‌ धृतः तदा पुनः पूर्वं सः आगतः किम्‌ कुल इतर पुरा  मात्रा स विषये उ अतएव अपि नगरस्य  उपरि यतः प्रतिशतं  कतरः कालः साधनानि भूत तथापि जात सम्बन्धि अन्यत्‌ ग अतः अस्माकं स्वकीयाः अस्माकं इदानीं अन्तः इत्यादयः भवन्तः इत्यादयः एते एताः तस्य अस्य इदम् एते तेषां तेषां तेषां तान् तेषां तेषां तेषां समानः सः एकः च तादृशाः बहवः अन्ये च वदन्ति यत् कियत् कस्मै  कस्मै  यस्मै  यस्मै  यस्मै  यस्मै न अतिनीचः किन्तु प्रथमं सम्पूर्णतया  ततः चिरकालानन्तरं पुस्तकं सम्पूर्णतया अन्तः  किन्तु अत्र वा इह इव श्रद्धाय अवशिष्यते  परन्तु अन्ये वर्गाः सन्ति ते सन्ति शक्नुवन्ति सर्वे मिलित्वा सर्वे एकत्र"'.split(" ")),e.sa.stemmer=function(){return function(e){return"function"==typeof e.update?e.update(function(e){return e}):e}}();var r=e.wordcut;r.init(),e.sa.tokenizer=function(t){if(!arguments.length||null==t||void 0==t)return[];if(Array.isArray(t))return t.map(function(r){return isLunr2?new e.Token(r.toLowerCase()):r.toLowerCase()});var i=t.toString().toLowerCase().replace(/^\s+/,"");return r.cut(i).split("|")},e.Pipeline.registerFunction(e.sa.stemmer,"stemmer-sa"),e.Pipeline.registerFunction(e.sa.stopWordFilter,"stopWordFilter-sa")}});

assets/javascripts/lunr/min/lunr.stemmer.support.min.js

@@ -1 +0,0 @@
-!function(r,t){"function"==typeof define&&define.amd?define(t):"object"==typeof exports?module.exports=t():t()(r.lunr)}(this,function(){return function(r){r.stemmerSupport={Among:function(r,t,i,s){if(this.toCharArray=function(r){for(var t=r.length,i=new Array(t),s=0;s<t;s++)i[s]=r.charCodeAt(s);return i},!r&&""!=r||!t&&0!=t||!i)throw"Bad Among initialisation: s:"+r+", substring_i: "+t+", result: "+i;this.s_size=r.length,this.s=this.toCharArray(r),this.substring_i=t,this.result=i,this.method=s},SnowballProgram:function(){var r;return{bra:0,ket:0,limit:0,cursor:0,limit_backward:0,setCurrent:function(t){r=t,this.cursor=0,this.limit=t.length,this.limit_backward=0,this.bra=this.cursor,this.ket=this.limit},getCurrent:function(){var t=r;return r=null,t},in_grouping:function(t,i,s){if(this.cursor<this.limit){var e=r.charCodeAt(this.cursor);if(e<=s&&e>=i&&(e-=i,t[e>>3]&1<<(7&e)))return this.cursor++,!0}return!1},in_grouping_b:function(t,i,s){if(this.cursor>this.limit_backward){var e=r.charCodeAt(this.cursor-1);if(e<=s&&e>=i&&(e-=i,t[e>>3]&1<<(7&e)))return this.cursor--,!0}return!1},out_grouping:function(t,i,s){if(this.cursor<this.limit){var e=r.charCodeAt(this.cursor);if(e>s||e<i)return this.cursor++,!0;if(e-=i,!(t[e>>3]&1<<(7&e)))return this.cursor++,!0}return!1},out_grouping_b:function(t,i,s){if(this.cursor>this.limit_backward){var e=r.charCodeAt(this.cursor-1);if(e>s||e<i)return this.cursor--,!0;if(e-=i,!(t[e>>3]&1<<(7&e)))return this.cursor--,!0}return!1},eq_s:function(t,i){if(this.limit-this.cursor<t)return!1;for(var s=0;s<t;s++)if(r.charCodeAt(this.cursor+s)!=i.charCodeAt(s))return!1;return this.cursor+=t,!0},eq_s_b:function(t,i){if(this.cursor-this.limit_backward<t)return!1;for(var s=0;s<t;s++)if(r.charCodeAt(this.cursor-t+s)!=i.charCodeAt(s))return!1;return this.cursor-=t,!0},find_among:function(t,i){for(var s=0,e=i,n=this.cursor,u=this.limit,o=0,h=0,c=!1;;){for(var a=s+(e-s>>1),f=0,l=o<h?o:h,_=t[a],m=l;m<_.s_size;m++){if(n+l==u){f=-1;break}if(f=r.charCodeAt(n+l)-_.s[m])break;l++}if(f<0?(e=a,h=l):(s=a,o=l),e-s<=1){if(s>0||e==s||c)break;c=!0}}for(;;){var _=t[s];if(o>=_.s_size){if(this.cursor=n+_.s_size,!_.method)return _.result;var b=_.method();if(this.cursor=n+_.s_size,b)return _.result}if((s=_.substring_i)<0)return 0}},find_among_b:function(t,i){for(var s=0,e=i,n=this.cursor,u=this.limit_backward,o=0,h=0,c=!1;;){for(var a=s+(e-s>>1),f=0,l=o<h?o:h,_=t[a],m=_.s_size-1-l;m>=0;m--){if(n-l==u){f=-1;break}if(f=r.charCodeAt(n-1-l)-_.s[m])break;l++}if(f<0?(e=a,h=l):(s=a,o=l),e-s<=1){if(s>0||e==s||c)break;c=!0}}for(;;){var _=t[s];if(o>=_.s_size){if(this.cursor=n-_.s_size,!_.method)return _.result;var b=_.method();if(this.cursor=n-_.s_size,b)return _.result}if((s=_.substring_i)<0)return 0}},replace_s:function(t,i,s){var e=s.length-(i-t),n=r.substring(0,t),u=r.substring(i);return r=n+s+u,this.limit+=e,this.cursor>=i?this.cursor+=e:this.cursor>t&&(this.cursor=t),e},slice_check:function(){if(this.bra<0||this.bra>this.ket||this.ket>this.limit||this.limit>r.length)throw"faulty slice operation"},slice_from:function(r){this.slice_check(),this.replace_s(this.bra,this.ket,r)},slice_del:function(){this.slice_from("")},insert:function(r,t,i){var s=this.replace_s(r,t,i);r<=this.bra&&(this.bra+=s),r<=this.ket&&(this.ket+=s)},slice_to:function(){return this.slice_check(),r.substring(this.bra,this.ket)},eq_v_b:function(r){return this.eq_s_b(r.length,r)}}}},r.trimmerSupport={generateTrimmer:function(r){var t=new RegExp("^[^"+r+"]+"),i=new RegExp("[^"+r+"]+$");return function(r){return"function"==typeof r.update?r.update(function(r){return r.replace(t,"").replace(i,"")}):r.replace(t,"").replace(i,"")}}}}});

assets/javascripts/lunr/min/lunr.sv.min.js

@@ -1,18 +0,0 @@
-/*!
- * Lunr languages, `Swedish` language
- * https://github.com/MihaiValentin/lunr-languages
- *
- * Copyright 2014, Mihai Valentin
- * http://www.mozilla.org/MPL/
- */
-/*!
- * based on
- * Snowball JavaScript Library v0.3
- * http://code.google.com/p/urim/
- * http://snowball.tartarus.org/
- *
- * Copyright 2010, Oleg Mazko
- * http://www.mozilla.org/MPL/
- */
-
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.sv=function(){this.pipeline.reset(),this.pipeline.add(e.sv.trimmer,e.sv.stopWordFilter,e.sv.stemmer),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add(e.sv.stemmer))},e.sv.wordCharacters="A-Za-zªºÀ-ÖØ-öø-ʸˠ-ˤᴀ-ᴥᴬ-ᵜᵢ-ᵥᵫ-ᵷᵹ-ᶾḀ-ỿⁱⁿₐ-ₜKÅℲⅎⅠ-ↈⱠ-ⱿꜢ-ꞇꞋ-ꞭꞰ-ꞷꟷ-ꟿꬰ-ꭚꭜ-ꭤff-stＡ-Ｚａ-ｚ",e.sv.trimmer=e.trimmerSupport.generateTrimmer(e.sv.wordCharacters),e.Pipeline.registerFunction(e.sv.trimmer,"trimmer-sv"),e.sv.stemmer=function(){var r=e.stemmerSupport.Among,n=e.stemmerSupport.SnowballProgram,t=new function(){function e(){var e,r=w.cursor+3;if(o=w.limit,0<=r||r<=w.limit){for(a=r;;){if(e=w.cursor,w.in_grouping(l,97,246)){w.cursor=e;break}if(w.cursor=e,w.cursor>=w.limit)return;w.cursor++}for(;!w.out_grouping(l,97,246);){if(w.cursor>=w.limit)return;w.cursor++}o=w.cursor,o<a&&(o=a)}}function t(){var e,r=w.limit_backward;if(w.cursor>=o&&(w.limit_backward=o,w.cursor=w.limit,w.ket=w.cursor,e=w.find_among_b(u,37),w.limit_backward=r,e))switch(w.bra=w.cursor,e){case 1:w.slice_del();break;case 2:w.in_grouping_b(d,98,121)&&w.slice_del()}}function i(){var e=w.limit_backward;w.cursor>=o&&(w.limit_backward=o,w.cursor=w.limit,w.find_among_b(c,7)&&(w.cursor=w.limit,w.ket=w.cursor,w.cursor>w.limit_backward&&(w.bra=--w.cursor,w.slice_del())),w.limit_backward=e)}function s(){var e,r;if(w.cursor>=o){if(r=w.limit_backward,w.limit_backward=o,w.cursor=w.limit,w.ket=w.cursor,e=w.find_among_b(m,5))switch(w.bra=w.cursor,e){case 1:w.slice_del();break;case 2:w.slice_from("lös");break;case 3:w.slice_from("full")}w.limit_backward=r}}var a,o,u=[new r("a",-1,1),new r("arna",0,1),new r("erna",0,1),new r("heterna",2,1),new r("orna",0,1),new r("ad",-1,1),new r("e",-1,1),new r("ade",6,1),new r("ande",6,1),new r("arne",6,1),new r("are",6,1),new r("aste",6,1),new r("en",-1,1),new r("anden",12,1),new r("aren",12,1),new r("heten",12,1),new r("ern",-1,1),new r("ar",-1,1),new r("er",-1,1),new r("heter",18,1),new r("or",-1,1),new r("s",-1,2),new r("as",21,1),new r("arnas",22,1),new r("ernas",22,1),new r("ornas",22,1),new r("es",21,1),new r("ades",26,1),new r("andes",26,1),new r("ens",21,1),new r("arens",29,1),new r("hetens",29,1),new r("erns",21,1),new r("at",-1,1),new r("andet",-1,1),new r("het",-1,1),new r("ast",-1,1)],c=[new r("dd",-1,-1),new r("gd",-1,-1),new r("nn",-1,-1),new r("dt",-1,-1),new r("gt",-1,-1),new r("kt",-1,-1),new r("tt",-1,-1)],m=[new r("ig",-1,1),new r("lig",0,1),new r("els",-1,1),new r("fullt",-1,3),new r("löst",-1,2)],l=[17,65,16,1,0,0,0,0,0,0,0,0,0,0,0,0,24,0,32],d=[119,127,149],w=new n;this.setCurrent=function(e){w.setCurrent(e)},this.getCurrent=function(){return w.getCurrent()},this.stem=function(){var r=w.cursor;return e(),w.limit_backward=r,w.cursor=w.limit,t(),w.cursor=w.limit,i(),w.cursor=w.limit,s(),!0}};return function(e){return"function"==typeof e.update?e.update(function(e){return t.setCurrent(e),t.stem(),t.getCurrent()}):(t.setCurrent(e),t.stem(),t.getCurrent())}}(),e.Pipeline.registerFunction(e.sv.stemmer,"stemmer-sv"),e.sv.stopWordFilter=e.generateStopWordFilter("alla allt att av blev bli blir blivit de dem den denna deras dess dessa det detta dig din dina ditt du där då efter ej eller en er era ert ett från för ha hade han hans har henne hennes hon honom hur här i icke ingen inom inte jag ju kan kunde man med mellan men mig min mina mitt mot mycket ni nu när någon något några och om oss på samma sedan sig sin sina sitta själv skulle som så sådan sådana sådant till under upp ut utan vad var vara varför varit varje vars vart vem vi vid vilka vilkas vilken vilket vår våra vårt än är åt över".split(" ")),e.Pipeline.registerFunction(e.sv.stopWordFilter,"stopWordFilter-sv")}});

assets/javascripts/lunr/min/lunr.ta.min.js

@@ -1 +0,0 @@
-!function(e,t){"function"==typeof define&&define.amd?define(t):"object"==typeof exports?module.exports=t():t()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.ta=function(){this.pipeline.reset(),this.pipeline.add(e.ta.trimmer,e.ta.stopWordFilter,e.ta.stemmer),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add(e.ta.stemmer))},e.ta.wordCharacters="஀-உஊ-ஏஐ-ஙச-ட஠-னப-யர-ஹ஺-ிீ-௉ொ-௏ௐ-௙௚-௟௠-௩௪-௯௰-௹௺-௿a-zA-Zａ-ｚＡ-Ｚ0-9０-９",e.ta.trimmer=e.trimmerSupport.generateTrimmer(e.ta.wordCharacters),e.Pipeline.registerFunction(e.ta.trimmer,"trimmer-ta"),e.ta.stopWordFilter=e.generateStopWordFilter("அங்கு அங்கே அது அதை அந்த அவர் அவர்கள் அவள் அவன் அவை ஆக ஆகவே ஆகையால் ஆதலால் ஆதலினால் ஆனாலும் ஆனால் இங்கு இங்கே இது இதை இந்த இப்படி இவர் இவர்கள் இவள் இவன் இவை இவ்வளவு உனக்கு உனது உன் உன்னால் எங்கு எங்கே எது எதை எந்த எப்படி எவர் எவர்கள் எவள் எவன் எவை எவ்வளவு எனக்கு எனது எனவே என் என்ன என்னால் ஏது ஏன் தனது தன்னால் தானே தான் நாங்கள் நாம் நான் நீ நீங்கள்".split(" ")),e.ta.stemmer=function(){return function(e){return"function"==typeof e.update?e.update(function(e){return e}):e}}();var t=e.wordcut;t.init(),e.ta.tokenizer=function(r){if(!arguments.length||null==r||void 0==r)return[];if(Array.isArray(r))return r.map(function(t){return isLunr2?new e.Token(t.toLowerCase()):t.toLowerCase()});var i=r.toString().toLowerCase().replace(/^\s+/,"");return t.cut(i).split("|")},e.Pipeline.registerFunction(e.ta.stemmer,"stemmer-ta"),e.Pipeline.registerFunction(e.ta.stopWordFilter,"stopWordFilter-ta")}});

assets/javascripts/lunr/min/lunr.te.min.js

@@ -1 +0,0 @@
-!function(e,t){"function"==typeof define&&define.amd?define(t):"object"==typeof exports?module.exports=t():t()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.te=function(){this.pipeline.reset(),this.pipeline.add(e.te.trimmer,e.te.stopWordFilter,e.te.stemmer),this.searchPipeline&&(this.searchPipeline.reset(),this.searchPipeline.add(e.te.stemmer))},e.te.wordCharacters="ఀ-ఄఅ-ఔక-హా-ౌౕ-ౖౘ-ౚౠ-ౡౢ-ౣ౦-౯౸-౿఼ఽ్ౝ౷౤౥",e.te.trimmer=e.trimmerSupport.generateTrimmer(e.te.wordCharacters),e.Pipeline.registerFunction(e.te.trimmer,"trimmer-te"),e.te.stopWordFilter=e.generateStopWordFilter("అందరూ అందుబాటులో అడగండి అడగడం అడ్డంగా అనుగుణంగా అనుమతించు అనుమతిస్తుంది అయితే ఇప్పటికే ఉన్నారు ఎక్కడైనా ఎప్పుడు ఎవరైనా ఎవరో ఏ ఏదైనా ఏమైనప్పటికి ఒక ఒకరు కనిపిస్తాయి కాదు కూడా గా గురించి చుట్టూ చేయగలిగింది తగిన తర్వాత దాదాపు దూరంగా నిజంగా పై ప్రకారం ప్రక్కన మధ్య మరియు మరొక మళ్ళీ మాత్రమే మెచ్చుకో వద్ద వెంట వేరుగా వ్యతిరేకంగా సంబంధం".split(" ")),e.te.stemmer=function(){return function(e){return"function"==typeof e.update?e.update(function(e){return e}):e}}();var t=e.wordcut;t.init(),e.te.tokenizer=function(r){if(!arguments.length||null==r||void 0==r)return[];if(Array.isArray(r))return r.map(function(t){return isLunr2?new e.Token(t.toLowerCase()):t.toLowerCase()});var i=r.toString().toLowerCase().replace(/^\s+/,"");return t.cut(i).split("|")},e.Pipeline.registerFunction(e.te.stemmer,"stemmer-te"),e.Pipeline.registerFunction(e.te.stopWordFilter,"stopWordFilter-te")}});

assets/javascripts/lunr/min/lunr.th.min.js

@@ -1 +0,0 @@
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");var r="2"==e.version[0];e.th=function(){this.pipeline.reset(),this.pipeline.add(e.th.trimmer),r?this.tokenizer=e.th.tokenizer:(e.tokenizer&&(e.tokenizer=e.th.tokenizer),this.tokenizerFn&&(this.tokenizerFn=e.th.tokenizer))},e.th.wordCharacters="[฀-๿]",e.th.trimmer=e.trimmerSupport.generateTrimmer(e.th.wordCharacters),e.Pipeline.registerFunction(e.th.trimmer,"trimmer-th");var t=e.wordcut;t.init(),e.th.tokenizer=function(i){if(!arguments.length||null==i||void 0==i)return[];if(Array.isArray(i))return i.map(function(t){return r?new e.Token(t):t});var n=i.toString().replace(/^\s+/,"");return t.cut(n).split("|")}}});

assets/javascripts/lunr/min/lunr.vi.min.js

@@ -1 +0,0 @@
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r():r()(e.lunr)}(this,function(){return function(e){if(void 0===e)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===e.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");e.vi=function(){this.pipeline.reset(),this.pipeline.add(e.vi.stopWordFilter,e.vi.trimmer)},e.vi.wordCharacters="[A-Za-ẓ̀͐́͑̉̃̓ÂâÊêÔôĂ-ăĐ-đƠ-ơƯ-ư]",e.vi.trimmer=e.trimmerSupport.generateTrimmer(e.vi.wordCharacters),e.Pipeline.registerFunction(e.vi.trimmer,"trimmer-vi"),e.vi.stopWordFilter=e.generateStopWordFilter("là cái nhưng mà".split(" "))}});

assets/javascripts/lunr/min/lunr.zh.min.js

@@ -1 +0,0 @@
-!function(e,r){"function"==typeof define&&define.amd?define(r):"object"==typeof exports?module.exports=r(require("@node-rs/jieba")):r()(e.lunr)}(this,function(e){return function(r,t){if(void 0===r)throw new Error("Lunr is not present. Please include / require Lunr before this script.");if(void 0===r.stemmerSupport)throw new Error("Lunr stemmer support is not present. Please include / require Lunr stemmer support before this script.");var i="2"==r.version[0];r.zh=function(){this.pipeline.reset(),this.pipeline.add(r.zh.trimmer,r.zh.stopWordFilter,r.zh.stemmer),i?this.tokenizer=r.zh.tokenizer:(r.tokenizer&&(r.tokenizer=r.zh.tokenizer),this.tokenizerFn&&(this.tokenizerFn=r.zh.tokenizer))},r.zh.tokenizer=function(n){if(!arguments.length||null==n||void 0==n)return[];if(Array.isArray(n))return n.map(function(e){return i?new r.Token(e.toLowerCase()):e.toLowerCase()});t&&e.load(t);var o=n.toString().trim().toLowerCase(),s=[];e.cut(o,!0).forEach(function(e){s=s.concat(e.split(" "))}),s=s.filter(function(e){return!!e});var u=0;return s.map(function(e,t){if(i){var n=o.indexOf(e,u),s={};return s.position=[n,e.length],s.index=t,u=n,new r.Token(e,s)}return e})},r.zh.wordCharacters="\\w一-龥",r.zh.trimmer=r.trimmerSupport.generateTrimmer(r.zh.wordCharacters),r.Pipeline.registerFunction(r.zh.trimmer,"trimmer-zh"),r.zh.stemmer=function(){return function(e){return e}}(),r.Pipeline.registerFunction(r.zh.stemmer,"stemmer-zh"),r.zh.stopWordFilter=r.generateStopWordFilter("的 一 不 在 人 有 是 为 為 以 于 於 上 他 而 后 後 之 来 來 及 了 因 下 可 到 由 这 這 与 與 也 此 但 并 並 个 個 其 已 无 無 小 我 们 們 起 最 再 今 去 好 只 又 或 很 亦 某 把 那 你 乃 它 吧 被 比 别 趁 当 當 从 從 得 打 凡 儿 兒 尔 爾 该 該 各 给 給 跟 和 何 还 還 即 几 幾 既 看 据 據 距 靠 啦 另 么 麽 每 嘛 拿 哪 您 凭 憑 且 却 卻 让 讓 仍 啥 如 若 使 谁 誰 虽 雖 随 隨 同 所 她 哇 嗡 往 些 向 沿 哟 喲 用 咱 则 則 怎 曾 至 致 着 著 诸 諸 自".split(" ")),r.Pipeline.registerFunction(r.zh.stopWordFilter,"stopWordFilter-zh")}});

assets/javascripts/lunr/tinyseg.js

@@ -1,206 +0,0 @@
-/**
- * export the module via AMD, CommonJS or as a browser global
- * Export code from https://github.com/umdjs/umd/blob/master/returnExports.js
- */
-;(function (root, factory) {
-    if (typeof define === 'function' && define.amd) {
-        // AMD. Register as an anonymous module.
-        define(factory)
-    } else if (typeof exports === 'object') {
-        /**
-         * Node. Does not work with strict CommonJS, but
-         * only CommonJS-like environments that support module.exports,
-         * like Node.
-         */
-        module.exports = factory()
-    } else {
-        // Browser globals (root is window)
-        factory()(root.lunr);
-    }
-}(this, function () {
-    /**
-     * Just return a value to define the module export.
-     * This example returns an object, but the module
-     * can return a function as the exported value.
-     */
-
-    return function(lunr) {
-        // TinySegmenter 0.1 -- Super compact Japanese tokenizer in Javascript
-        // (c) 2008 Taku Kudo <taku@chasen.org>
-        // TinySegmenter is freely distributable under the terms of a new BSD licence.
-        // For details, see http://chasen.org/~taku/software/TinySegmenter/LICENCE.txt
-
-        function TinySegmenter() {
-          var patterns = {
-            "[一二三四五六七八九十百千万億兆]":"M",
-            "[一-龠々〆ヵヶ]":"H",
-            "[ぁ-ん]":"I",
-            "[ァ-ヴーｱ-ﾝﾞｰ]":"K",
-            "[a-zA-Zａ-ｚＡ-Ｚ]":"A",
-            "[0-9０-９]":"N"
-          }
-          this.chartype_ = [];
-          for (var i in patterns) {
-            var regexp = new RegExp(i);
-            this.chartype_.push([regexp, patterns[i]]);
-          }
-
-          this.BIAS__ = -332
-          this.BC1__ = {"HH":6,"II":2461,"KH":406,"OH":-1378};
-          this.BC2__ = {"AA":-3267,"AI":2744,"AN":-878,"HH":-4070,"HM":-1711,"HN":4012,"HO":3761,"IA":1327,"IH":-1184,"II":-1332,"IK":1721,"IO":5492,"KI":3831,"KK":-8741,"MH":-3132,"MK":3334,"OO":-2920};
-          this.BC3__ = {"HH":996,"HI":626,"HK":-721,"HN":-1307,"HO":-836,"IH":-301,"KK":2762,"MK":1079,"MM":4034,"OA":-1652,"OH":266};
-          this.BP1__ = {"BB":295,"OB":304,"OO":-125,"UB":352};
-          this.BP2__ = {"BO":60,"OO":-1762};
-          this.BQ1__ = {"BHH":1150,"BHM":1521,"BII":-1158,"BIM":886,"BMH":1208,"BNH":449,"BOH":-91,"BOO":-2597,"OHI":451,"OIH":-296,"OKA":1851,"OKH":-1020,"OKK":904,"OOO":2965};
-          this.BQ2__ = {"BHH":118,"BHI":-1159,"BHM":466,"BIH":-919,"BKK":-1720,"BKO":864,"OHH":-1139,"OHM":-181,"OIH":153,"UHI":-1146};
-          this.BQ3__ = {"BHH":-792,"BHI":2664,"BII":-299,"BKI":419,"BMH":937,"BMM":8335,"BNN":998,"BOH":775,"OHH":2174,"OHM":439,"OII":280,"OKH":1798,"OKI":-793,"OKO":-2242,"OMH":-2402,"OOO":11699};
-          this.BQ4__ = {"BHH":-3895,"BIH":3761,"BII":-4654,"BIK":1348,"BKK":-1806,"BMI":-3385,"BOO":-12396,"OAH":926,"OHH":266,"OHK":-2036,"ONN":-973};
-          this.BW1__ = {",と":660,",同":727,"B1あ":1404,"B1同":542,"、と":660,"、同":727,"」と":1682,"あっ":1505,"いう":1743,"いっ":-2055,"いる":672,"うし":-4817,"うん":665,"から":3472,"がら":600,"こう":-790,"こと":2083,"こん":-1262,"さら":-4143,"さん":4573,"した":2641,"して":1104,"すで":-3399,"そこ":1977,"それ":-871,"たち":1122,"ため":601,"った":3463,"つい":-802,"てい":805,"てき":1249,"でき":1127,"です":3445,"では":844,"とい":-4915,"とみ":1922,"どこ":3887,"ない":5713,"なっ":3015,"など":7379,"なん":-1113,"にし":2468,"には":1498,"にも":1671,"に対":-912,"の一":-501,"の中":741,"ませ":2448,"まで":1711,"まま":2600,"まる":-2155,"やむ":-1947,"よっ":-2565,"れた":2369,"れで":-913,"をし":1860,"を見":731,"亡く":-1886,"京都":2558,"取り":-2784,"大き":-2604,"大阪":1497,"平方":-2314,"引き":-1336,"日本":-195,"本当":-2423,"毎日":-2113,"目指":-724,"Ｂ１あ":1404,"Ｂ１同":542,"｣と":1682};
-          this.BW2__ = {"..":-11822,"11":-669,"――":-5730,"−−":-13175,"いう":-1609,"うか":2490,"かし":-1350,"かも":-602,"から":-7194,"かれ":4612,"がい":853,"がら":-3198,"きた":1941,"くな":-1597,"こと":-8392,"この":-4193,"させ":4533,"され":13168,"さん":-3977,"しい":-1819,"しか":-545,"した":5078,"して":972,"しな":939,"その":-3744,"たい":-1253,"たた":-662,"ただ":-3857,"たち":-786,"たと":1224,"たは":-939,"った":4589,"って":1647,"っと":-2094,"てい":6144,"てき":3640,"てく":2551,"ては":-3110,"ても":-3065,"でい":2666,"でき":-1528,"でし":-3828,"です":-4761,"でも":-4203,"とい":1890,"とこ":-1746,"とと":-2279,"との":720,"とみ":5168,"とも":-3941,"ない":-2488,"なが":-1313,"など":-6509,"なの":2614,"なん":3099,"にお":-1615,"にし":2748,"にな":2454,"によ":-7236,"に対":-14943,"に従":-4688,"に関":-11388,"のか":2093,"ので":-7059,"のに":-6041,"のの":-6125,"はい":1073,"はが":-1033,"はず":-2532,"ばれ":1813,"まし":-1316,"まで":-6621,"まれ":5409,"めて":-3153,"もい":2230,"もの":-10713,"らか":-944,"らし":-1611,"らに":-1897,"りし":651,"りま":1620,"れた":4270,"れて":849,"れば":4114,"ろう":6067,"われ":7901,"を通":-11877,"んだ":728,"んな":-4115,"一人":602,"一方":-1375,"一日":970,"一部":-1051,"上が":-4479,"会社":-1116,"出て":2163,"分の":-7758,"同党":970,"同日":-913,"大阪":-2471,"委員":-1250,"少な":-1050,"年度":-8669,"年間":-1626,"府県":-2363,"手権":-1982,"新聞":-4066,"日新":-722,"日本":-7068,"日米":3372,"曜日":-601,"朝鮮":-2355,"本人":-2697,"東京":-1543,"然と":-1384,"社会":-1276,"立て":-990,"第に":-1612,"米国":-4268,"１１":-669};
-          this.BW3__ = {"あた":-2194,"あり":719,"ある":3846,"い.":-1185,"い。":-1185,"いい":5308,"いえ":2079,"いく":3029,"いた":2056,"いっ":1883,"いる":5600,"いわ":1527,"うち":1117,"うと":4798,"えと":1454,"か.":2857,"か。":2857,"かけ":-743,"かっ":-4098,"かに":-669,"から":6520,"かり":-2670,"が,":1816,"が、":1816,"がき":-4855,"がけ":-1127,"がっ":-913,"がら":-4977,"がり":-2064,"きた":1645,"けど":1374,"こと":7397,"この":1542,"ころ":-2757,"さい":-714,"さを":976,"し,":1557,"し、":1557,"しい":-3714,"した":3562,"して":1449,"しな":2608,"しま":1200,"す.":-1310,"す。":-1310,"する":6521,"ず,":3426,"ず、":3426,"ずに":841,"そう":428,"た.":8875,"た。":8875,"たい":-594,"たの":812,"たり":-1183,"たる":-853,"だ.":4098,"だ。":4098,"だっ":1004,"った":-4748,"って":300,"てい":6240,"てお":855,"ても":302,"です":1437,"でに":-1482,"では":2295,"とう":-1387,"とし":2266,"との":541,"とも":-3543,"どう":4664,"ない":1796,"なく":-903,"など":2135,"に,":-1021,"に、":-1021,"にし":1771,"にな":1906,"には":2644,"の,":-724,"の、":-724,"の子":-1000,"は,":1337,"は、":1337,"べき":2181,"まし":1113,"ます":6943,"まっ":-1549,"まで":6154,"まれ":-793,"らし":1479,"られ":6820,"るる":3818,"れ,":854,"れ、":854,"れた":1850,"れて":1375,"れば":-3246,"れる":1091,"われ":-605,"んだ":606,"んで":798,"カ月":990,"会議":860,"入り":1232,"大会":2217,"始め":1681,"市":965,"新聞":-5055,"日,":974,"日、":974,"社会":2024,"ｶ月":990};
-          this.TC1__ = {"AAA":1093,"HHH":1029,"HHM":580,"HII":998,"HOH":-390,"HOM":-331,"IHI":1169,"IOH":-142,"IOI":-1015,"IOM":467,"MMH":187,"OOI":-1832};
-          this.TC2__ = {"HHO":2088,"HII":-1023,"HMM":-1154,"IHI":-1965,"KKH":703,"OII":-2649};
-          this.TC3__ = {"AAA":-294,"HHH":346,"HHI":-341,"HII":-1088,"HIK":731,"HOH":-1486,"IHH":128,"IHI":-3041,"IHO":-1935,"IIH":-825,"IIM":-1035,"IOI":-542,"KHH":-1216,"KKA":491,"KKH":-1217,"KOK":-1009,"MHH":-2694,"MHM":-457,"MHO":123,"MMH":-471,"NNH":-1689,"NNO":662,"OHO":-3393};
-          this.TC4__ = {"HHH":-203,"HHI":1344,"HHK":365,"HHM":-122,"HHN":182,"HHO":669,"HIH":804,"HII":679,"HOH":446,"IHH":695,"IHO":-2324,"IIH":321,"III":1497,"IIO":656,"IOO":54,"KAK":4845,"KKA":3386,"KKK":3065,"MHH":-405,"MHI":201,"MMH":-241,"MMM":661,"MOM":841};
-          this.TQ1__ = {"BHHH":-227,"BHHI":316,"BHIH":-132,"BIHH":60,"BIII":1595,"BNHH":-744,"BOHH":225,"BOOO":-908,"OAKK":482,"OHHH":281,"OHIH":249,"OIHI":200,"OIIH":-68};
-          this.TQ2__ = {"BIHH":-1401,"BIII":-1033,"BKAK":-543,"BOOO":-5591};
-          this.TQ3__ = {"BHHH":478,"BHHM":-1073,"BHIH":222,"BHII":-504,"BIIH":-116,"BIII":-105,"BMHI":-863,"BMHM":-464,"BOMH":620,"OHHH":346,"OHHI":1729,"OHII":997,"OHMH":481,"OIHH":623,"OIIH":1344,"OKAK":2792,"OKHH":587,"OKKA":679,"OOHH":110,"OOII":-685};
-          this.TQ4__ = {"BHHH":-721,"BHHM":-3604,"BHII":-966,"BIIH":-607,"BIII":-2181,"OAAA":-2763,"OAKK":180,"OHHH":-294,"OHHI":2446,"OHHO":480,"OHIH":-1573,"OIHH":1935,"OIHI":-493,"OIIH":626,"OIII":-4007,"OKAK":-8156};
-          this.TW1__ = {"につい":-4681,"東京都":2026};
-          this.TW2__ = {"ある程":-2049,"いった":-1256,"ころが":-2434,"しょう":3873,"その後":-4430,"だって":-1049,"ていた":1833,"として":-4657,"ともに":-4517,"もので":1882,"一気に":-792,"初めて":-1512,"同時に":-8097,"大きな":-1255,"対して":-2721,"社会党":-3216};
-          this.TW3__ = {"いただ":-1734,"してい":1314,"として":-4314,"につい":-5483,"にとっ":-5989,"に当た":-6247,"ので,":-727,"ので、":-727,"のもの":-600,"れから":-3752,"十二月":-2287};
-          this.TW4__ = {"いう.":8576,"いう。":8576,"からな":-2348,"してい":2958,"たが,":1516,"たが、":1516,"ている":1538,"という":1349,"ました":5543,"ません":1097,"ようと":-4258,"よると":5865};
-          this.UC1__ = {"A":484,"K":93,"M":645,"O":-505};
-          this.UC2__ = {"A":819,"H":1059,"I":409,"M":3987,"N":5775,"O":646};
-          this.UC3__ = {"A":-1370,"I":2311};
-          this.UC4__ = {"A":-2643,"H":1809,"I":-1032,"K":-3450,"M":3565,"N":3876,"O":6646};
-          this.UC5__ = {"H":313,"I":-1238,"K":-799,"M":539,"O":-831};
-          this.UC6__ = {"H":-506,"I":-253,"K":87,"M":247,"O":-387};
-          this.UP1__ = {"O":-214};
-          this.UP2__ = {"B":69,"O":935};
-          this.UP3__ = {"B":189};
-          this.UQ1__ = {"BH":21,"BI":-12,"BK":-99,"BN":142,"BO":-56,"OH":-95,"OI":477,"OK":410,"OO":-2422};
-          this.UQ2__ = {"BH":216,"BI":113,"OK":1759};
-          this.UQ3__ = {"BA":-479,"BH":42,"BI":1913,"BK":-7198,"BM":3160,"BN":6427,"BO":14761,"OI":-827,"ON":-3212};
-          this.UW1__ = {",":156,"、":156,"「":-463,"あ":-941,"う":-127,"が":-553,"き":121,"こ":505,"で":-201,"と":-547,"ど":-123,"に":-789,"の":-185,"は":-847,"も":-466,"や":-470,"よ":182,"ら":-292,"り":208,"れ":169,"を":-446,"ん":-137,"・":-135,"主":-402,"京":-268,"区":-912,"午":871,"国":-460,"大":561,"委":729,"市":-411,"日":-141,"理":361,"生":-408,"県":-386,"都":-718,"｢":-463,"･":-135};
-          this.UW2__ = {",":-829,"、":-829,"〇":892,"「":-645,"」":3145,"あ":-538,"い":505,"う":134,"お":-502,"か":1454,"が":-856,"く":-412,"こ":1141,"さ":878,"ざ":540,"し":1529,"す":-675,"せ":300,"そ":-1011,"た":188,"だ":1837,"つ":-949,"て":-291,"で":-268,"と":-981,"ど":1273,"な":1063,"に":-1764,"の":130,"は":-409,"ひ":-1273,"べ":1261,"ま":600,"も":-1263,"や":-402,"よ":1639,"り":-579,"る":-694,"れ":571,"を":-2516,"ん":2095,"ア":-587,"カ":306,"キ":568,"ッ":831,"三":-758,"不":-2150,"世":-302,"中":-968,"主":-861,"事":492,"人":-123,"会":978,"保":362,"入":548,"初":-3025,"副":-1566,"北":-3414,"区":-422,"大":-1769,"天":-865,"太":-483,"子":-1519,"学":760,"実":1023,"小":-2009,"市":-813,"年":-1060,"強":1067,"手":-1519,"揺":-1033,"政":1522,"文":-1355,"新":-1682,"日":-1815,"明":-1462,"最":-630,"朝":-1843,"本":-1650,"東":-931,"果":-665,"次":-2378,"民":-180,"気":-1740,"理":752,"発":529,"目":-1584,"相":-242,"県":-1165,"立":-763,"第":810,"米":509,"自":-1353,"行":838,"西":-744,"見":-3874,"調":1010,"議":1198,"込":3041,"開":1758,"間":-1257,"｢":-645,"｣":3145,"ｯ":831,"ｱ":-587,"ｶ":306,"ｷ":568};
-          this.UW3__ = {",":4889,"1":-800,"−":-1723,"、":4889,"々":-2311,"〇":5827,"」":2670,"〓":-3573,"あ":-2696,"い":1006,"う":2342,"え":1983,"お":-4864,"か":-1163,"が":3271,"く":1004,"け":388,"げ":401,"こ":-3552,"ご":-3116,"さ":-1058,"し":-395,"す":584,"せ":3685,"そ":-5228,"た":842,"ち":-521,"っ":-1444,"つ":-1081,"て":6167,"で":2318,"と":1691,"ど":-899,"な":-2788,"に":2745,"の":4056,"は":4555,"ひ":-2171,"ふ":-1798,"へ":1199,"ほ":-5516,"ま":-4384,"み":-120,"め":1205,"も":2323,"や":-788,"よ":-202,"ら":727,"り":649,"る":5905,"れ":2773,"わ":-1207,"を":6620,"ん":-518,"ア":551,"グ":1319,"ス":874,"ッ":-1350,"ト":521,"ム":1109,"ル":1591,"ロ":2201,"ン":278,"・":-3794,"一":-1619,"下":-1759,"世":-2087,"両":3815,"中":653,"主":-758,"予":-1193,"二":974,"人":2742,"今":792,"他":1889,"以":-1368,"低":811,"何":4265,"作":-361,"保":-2439,"元":4858,"党":3593,"全":1574,"公":-3030,"六":755,"共":-1880,"円":5807,"再":3095,"分":457,"初":2475,"別":1129,"前":2286,"副":4437,"力":365,"動":-949,"務":-1872,"化":1327,"北":-1038,"区":4646,"千":-2309,"午":-783,"協":-1006,"口":483,"右":1233,"各":3588,"合":-241,"同":3906,"和":-837,"員":4513,"国":642,"型":1389,"場":1219,"外":-241,"妻":2016,"学":-1356,"安":-423,"実":-1008,"家":1078,"小":-513,"少":-3102,"州":1155,"市":3197,"平":-1804,"年":2416,"広":-1030,"府":1605,"度":1452,"建":-2352,"当":-3885,"得":1905,"思":-1291,"性":1822,"戸":-488,"指":-3973,"政":-2013,"教":-1479,"数":3222,"文":-1489,"新":1764,"日":2099,"旧":5792,"昨":-661,"時":-1248,"曜":-951,"最":-937,"月":4125,"期":360,"李":3094,"村":364,"東":-805,"核":5156,"森":2438,"業":484,"氏":2613,"民":-1694,"決":-1073,"法":1868,"海":-495,"無":979,"物":461,"特":-3850,"生":-273,"用":914,"町":1215,"的":7313,"直":-1835,"省":792,"県":6293,"知":-1528,"私":4231,"税":401,"立":-960,"第":1201,"米":7767,"系":3066,"約":3663,"級":1384,"統":-4229,"総":1163,"線":1255,"者":6457,"能":725,"自":-2869,"英":785,"見":1044,"調":-562,"財":-733,"費":1777,"車":1835,"軍":1375,"込":-1504,"通":-1136,"選":-681,"郎":1026,"郡":4404,"部":1200,"金":2163,"長":421,"開":-1432,"間":1302,"関":-1282,"雨":2009,"電":-1045,"非":2066,"駅":1620,"１":-800,"｣":2670,"･":-3794,"ｯ":-1350,"ｱ":551,"ｸﾞ":1319,"ｽ":874,"ﾄ":521,"ﾑ":1109,"ﾙ":1591,"ﾛ":2201,"ﾝ":278};
-          this.UW4__ = {",":3930,".":3508,"―":-4841,"、":3930,"。":3508,"〇":4999,"「":1895,"」":3798,"〓":-5156,"あ":4752,"い":-3435,"う":-640,"え":-2514,"お":2405,"か":530,"が":6006,"き":-4482,"ぎ":-3821,"く":-3788,"け":-4376,"げ":-4734,"こ":2255,"ご":1979,"さ":2864,"し":-843,"じ":-2506,"す":-731,"ず":1251,"せ":181,"そ":4091,"た":5034,"だ":5408,"ち":-3654,"っ":-5882,"つ":-1659,"て":3994,"で":7410,"と":4547,"な":5433,"に":6499,"ぬ":1853,"ね":1413,"の":7396,"は":8578,"ば":1940,"ひ":4249,"び":-4134,"ふ":1345,"へ":6665,"べ":-744,"ほ":1464,"ま":1051,"み":-2082,"む":-882,"め":-5046,"も":4169,"ゃ":-2666,"や":2795,"ょ":-1544,"よ":3351,"ら":-2922,"り":-9726,"る":-14896,"れ":-2613,"ろ":-4570,"わ":-1783,"を":13150,"ん":-2352,"カ":2145,"コ":1789,"セ":1287,"ッ":-724,"ト":-403,"メ":-1635,"ラ":-881,"リ":-541,"ル":-856,"ン":-3637,"・":-4371,"ー":-11870,"一":-2069,"中":2210,"予":782,"事":-190,"井":-1768,"人":1036,"以":544,"会":950,"体":-1286,"作":530,"側":4292,"先":601,"党":-2006,"共":-1212,"内":584,"円":788,"初":1347,"前":1623,"副":3879,"力":-302,"動":-740,"務":-2715,"化":776,"区":4517,"協":1013,"参":1555,"合":-1834,"和":-681,"員":-910,"器":-851,"回":1500,"国":-619,"園":-1200,"地":866,"場":-1410,"塁":-2094,"士":-1413,"多":1067,"大":571,"子":-4802,"学":-1397,"定":-1057,"寺":-809,"小":1910,"屋":-1328,"山":-1500,"島":-2056,"川":-2667,"市":2771,"年":374,"庁":-4556,"後":456,"性":553,"感":916,"所":-1566,"支":856,"改":787,"政":2182,"教":704,"文":522,"方":-856,"日":1798,"時":1829,"最":845,"月":-9066,"木":-485,"来":-442,"校":-360,"業":-1043,"氏":5388,"民":-2716,"気":-910,"沢":-939,"済":-543,"物":-735,"率":672,"球":-1267,"生":-1286,"産":-1101,"田":-2900,"町":1826,"的":2586,"目":922,"省":-3485,"県":2997,"空":-867,"立":-2112,"第":788,"米":2937,"系":786,"約":2171,"経":1146,"統":-1169,"総":940,"線":-994,"署":749,"者":2145,"能":-730,"般":-852,"行":-792,"規":792,"警":-1184,"議":-244,"谷":-1000,"賞":730,"車":-1481,"軍":1158,"輪":-1433,"込":-3370,"近":929,"道":-1291,"選":2596,"郎":-4866,"都":1192,"野":-1100,"銀":-2213,"長":357,"間":-2344,"院":-2297,"際":-2604,"電":-878,"領":-1659,"題":-792,"館":-1984,"首":1749,"高":2120,"｢":1895,"｣":3798,"･":-4371,"ｯ":-724,"ｰ":-11870,"ｶ":2145,"ｺ":1789,"ｾ":1287,"ﾄ":-403,"ﾒ":-1635,"ﾗ":-881,"ﾘ":-541,"ﾙ":-856,"ﾝ":-3637};
-          this.UW5__ = {",":465,".":-299,"1":-514,"E2":-32768,"]":-2762,"、":465,"。":-299,"「":363,"あ":1655,"い":331,"う":-503,"え":1199,"お":527,"か":647,"が":-421,"き":1624,"ぎ":1971,"く":312,"げ":-983,"さ":-1537,"し":-1371,"す":-852,"だ":-1186,"ち":1093,"っ":52,"つ":921,"て":-18,"で":-850,"と":-127,"ど":1682,"な":-787,"に":-1224,"の":-635,"は":-578,"べ":1001,"み":502,"め":865,"ゃ":3350,"ょ":854,"り":-208,"る":429,"れ":504,"わ":419,"を":-1264,"ん":327,"イ":241,"ル":451,"ン":-343,"中":-871,"京":722,"会":-1153,"党":-654,"務":3519,"区":-901,"告":848,"員":2104,"大":-1296,"学":-548,"定":1785,"嵐":-1304,"市":-2991,"席":921,"年":1763,"思":872,"所":-814,"挙":1618,"新":-1682,"日":218,"月":-4353,"査":932,"格":1356,"機":-1508,"氏":-1347,"田":240,"町":-3912,"的":-3149,"相":1319,"省":-1052,"県":-4003,"研":-997,"社":-278,"空":-813,"統":1955,"者":-2233,"表":663,"語":-1073,"議":1219,"選":-1018,"郎":-368,"長":786,"間":1191,"題":2368,"館":-689,"１":-514,"Ｅ２":-32768,"｢":363,"ｲ":241,"ﾙ":451,"ﾝ":-343};
-          this.UW6__ = {",":227,".":808,"1":-270,"E1":306,"、":227,"。":808,"あ":-307,"う":189,"か":241,"が":-73,"く":-121,"こ":-200,"じ":1782,"す":383,"た":-428,"っ":573,"て":-1014,"で":101,"と":-105,"な":-253,"に":-149,"の":-417,"は":-236,"も":-206,"り":187,"る":-135,"を":195,"ル":-673,"ン":-496,"一":-277,"中":201,"件":-800,"会":624,"前":302,"区":1792,"員":-1212,"委":798,"学":-960,"市":887,"広":-695,"後":535,"業":-697,"相":753,"社":-507,"福":974,"空":-822,"者":1811,"連":463,"郎":1082,"１":-270,"Ｅ１":306,"ﾙ":-673,"ﾝ":-496};
-          
-          return this;
-        }
-        TinySegmenter.prototype.ctype_ = function(str) {
-          for (var i in this.chartype_) {
-            if (str.match(this.chartype_[i][0])) {
-              return this.chartype_[i][1];
-            }
-          }
-          return "O";
-        }
-
-        TinySegmenter.prototype.ts_ = function(v) {
-          if (v) { return v; }
-          return 0;
-        }
-
-        TinySegmenter.prototype.segment = function(input) {
-          if (input == null || input == undefined || input == "") {
-            return [];
-          }
-          var result = [];
-          var seg = ["B3","B2","B1"];
-          var ctype = ["O","O","O"];
-          var o = input.split("");
-          for (i = 0; i < o.length; ++i) {
-            seg.push(o[i]);
-            ctype.push(this.ctype_(o[i]))
-          }
-          seg.push("E1");
-          seg.push("E2");
-          seg.push("E3");
-          ctype.push("O");
-          ctype.push("O");
-          ctype.push("O");
-          var word = seg[3];
-          var p1 = "U";
-          var p2 = "U";
-          var p3 = "U";
-          for (var i = 4; i < seg.length - 3; ++i) {
-            var score = this.BIAS__;
-            var w1 = seg[i-3];
-            var w2 = seg[i-2];
-            var w3 = seg[i-1];
-            var w4 = seg[i];
-            var w5 = seg[i+1];
-            var w6 = seg[i+2];
-            var c1 = ctype[i-3];
-            var c2 = ctype[i-2];
-            var c3 = ctype[i-1];
-            var c4 = ctype[i];
-            var c5 = ctype[i+1];
-            var c6 = ctype[i+2];
-            score += this.ts_(this.UP1__[p1]);
-            score += this.ts_(this.UP2__[p2]);
-            score += this.ts_(this.UP3__[p3]);
-            score += this.ts_(this.BP1__[p1 + p2]);
-            score += this.ts_(this.BP2__[p2 + p3]);
-            score += this.ts_(this.UW1__[w1]);
-            score += this.ts_(this.UW2__[w2]);
-            score += this.ts_(this.UW3__[w3]);
-            score += this.ts_(this.UW4__[w4]);
-            score += this.ts_(this.UW5__[w5]);
-            score += this.ts_(this.UW6__[w6]);
-            score += this.ts_(this.BW1__[w2 + w3]);
-            score += this.ts_(this.BW2__[w3 + w4]);
-            score += this.ts_(this.BW3__[w4 + w5]);
-            score += this.ts_(this.TW1__[w1 + w2 + w3]);
-            score += this.ts_(this.TW2__[w2 + w3 + w4]);
-            score += this.ts_(this.TW3__[w3 + w4 + w5]);
-            score += this.ts_(this.TW4__[w4 + w5 + w6]);
-            score += this.ts_(this.UC1__[c1]);
-            score += this.ts_(this.UC2__[c2]);
-            score += this.ts_(this.UC3__[c3]);
-            score += this.ts_(this.UC4__[c4]);
-            score += this.ts_(this.UC5__[c5]);
-            score += this.ts_(this.UC6__[c6]);
-            score += this.ts_(this.BC1__[c2 + c3]);
-            score += this.ts_(this.BC2__[c3 + c4]);
-            score += this.ts_(this.BC3__[c4 + c5]);
-            score += this.ts_(this.TC1__[c1 + c2 + c3]);
-            score += this.ts_(this.TC2__[c2 + c3 + c4]);
-            score += this.ts_(this.TC3__[c3 + c4 + c5]);
-            score += this.ts_(this.TC4__[c4 + c5 + c6]);
-        //  score += this.ts_(this.TC5__[c4 + c5 + c6]);    
-            score += this.ts_(this.UQ1__[p1 + c1]);
-            score += this.ts_(this.UQ2__[p2 + c2]);
-            score += this.ts_(this.UQ3__[p3 + c3]);
-            score += this.ts_(this.BQ1__[p2 + c2 + c3]);
-            score += this.ts_(this.BQ2__[p2 + c3 + c4]);
-            score += this.ts_(this.BQ3__[p3 + c2 + c3]);
-            score += this.ts_(this.BQ4__[p3 + c3 + c4]);
-            score += this.ts_(this.TQ1__[p2 + c1 + c2 + c3]);
-            score += this.ts_(this.TQ2__[p2 + c2 + c3 + c4]);
-            score += this.ts_(this.TQ3__[p3 + c1 + c2 + c3]);
-            score += this.ts_(this.TQ4__[p3 + c2 + c3 + c4]);
-            var p = "O";
-            if (score > 0) {
-              result.push(word);
-              word = "";
-              p = "B";
-            }
-            p1 = p2;
-            p2 = p3;
-            p3 = p;
-            word += seg[i];
-          }
-          result.push(word);
-
-          return result;
-        }
-
-        lunr.TinySegmenter = TinySegmenter;
-    };
-
-}));

assets/stylesheets/palette.ab4e12ef.min.css.map

@@ -1 +0,0 @@
-{"version":3,"sources":["src/templates/assets/stylesheets/palette/_scheme.scss","../../../../src/templates/assets/stylesheets/palette.scss","src/templates/assets/stylesheets/palette/_accent.scss","src/templates/assets/stylesheets/palette/_primary.scss","src/templates/assets/stylesheets/utilities/_break.scss"],"names":[],"mappings":"AA2BA,cAGE,6BAME,sDAAA,CACA,6DAAA,CACA,+DAAA,CACA,gEAAA,CACA,mDAAA,CACA,6DAAA,CACA,+DAAA,CACA,gEAAA,CAGA,mDAAA,CACA,gDAAA,CACA,yDAAA,CACA,4DAAA,CAGA,0BAAA,CACA,mCAAA,CAGA,iCAAA,CACA,kCAAA,CACA,mCAAA,CACA,mCAAA,CACA,kCAAA,CACA,iCAAA,CACA,+CAAA,CACA,6DAAA,CACA,gEAAA,CACA,4DAAA,CACA,4DAAA,CACA,6DAAA,CAGA,6CAAA,CAGA,+CAAA,CAGA,uDAAA,CACA,6DAAA,CACA,2DAAA,CAGA,iCAAA,CAGA,yDAAA,CACA,iEAAA,CAGA,mDAAA,CACA,mDAAA,CAGA,qDAAA,CACA,uDAAA,CAGA,8DAAA,CAKA,8DAAA,CAKA,0DAAA,CAzEA,iBCiBF,CD6DE,kHAEE,YC3DJ,CDkFE,yDACE,4BChFJ,CD+EE,2DACE,4BC7EJ,CD4EE,gEACE,4BC1EJ,CDyEE,2DACE,4BCvEJ,CDsEE,yDACE,4BCpEJ,CDmEE,0DACE,4BCjEJ,CDgEE,gEACE,4BC9DJ,CD6DE,0DACE,4BC3DJ,CD0DE,2OACE,4BC/CJ,CDsDA,+FAGE,iCCpDF,CACF,CCjDE,2BACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCD6CN,CCvDE,4BACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCDoDN,CC9DE,8BACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCD2DN,CCrEE,mCACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCDkEN,CC5EE,8BACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCDyEN,CCnFE,4BACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCDgFN,CC1FE,kCACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCDuFN,CCjGE,4BACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCD8FN,CCxGE,4BACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCDqGN,CC/GE,6BACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCD4GN,CCtHE,mCACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCDmHN,CC7HE,4BACE,4BAAA,CACA,2CAAA,CAIE,8BAAA,CACA,qCD6HN,CCpIE,8BACE,4BAAA,CACA,2CAAA,CAIE,8BAAA,CACA,qCDoIN,CC3IE,6BACE,yBAAA,CACA,2CAAA,CAIE,8BAAA,CACA,qCD2IN,CClJE,8BACE,4BAAA,CACA,2CAAA,CAIE,8BAAA,CACA,qCDkJN,CCzJE,mCACE,4BAAA,CACA,2CAAA,CAOE,yBAAA,CACA,qCDsJN,CE3JE,4BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFwJN,CEnKE,6BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFgKN,CE3KE,+BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFwKN,CEnLE,oCACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFgLN,CE3LE,+BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFwLN,CEnME,6BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFgMN,CE3ME,mCACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFwMN,CEnNE,6BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFgNN,CE3NE,6BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFwNN,CEnOE,8BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFgON,CE3OE,oCACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFwON,CEnPE,6BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAIE,+BAAA,CACA,sCFmPN,CE3PE,+BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAIE,+BAAA,CACA,sCF2PN,CEnQE,8BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAIE,+BAAA,CACA,sCFmQN,CE3QE,+BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAIE,+BAAA,CACA,sCF2QN,CEnRE,oCACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFgRN,CE3RE,8BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCFwRN,CEnSE,6BACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCAAA,CAKA,4BF4RN,CE5SE,kCACE,6BAAA,CACA,oCAAA,CACA,mCAAA,CAOE,0BAAA,CACA,sCAAA,CAKA,4BFqSN,CEtRE,sEACE,4BFyRJ,CE1RE,+DACE,4BF6RJ,CE9RE,iEACE,4BFiSJ,CElSE,gEACE,4BFqSJ,CEtSE,iEACE,4BFySJ,CEhSA,8BACE,mDAAA,CACA,4DAAA,CACA,0DAAA,CACA,oDAAA,CACA,2DAAA,CAGA,4BFiSF,CE9RE,yCACE,+BFgSJ,CE7RI,kDAEE,0CAAA,CACA,sCAAA,CAFA,mCFiSN,CG7MI,mCD1EA,+CACE,8CF0RJ,CEvRI,qDACE,8CFyRN,CEpRE,iEACE,mCFsRJ,CACF,CGxNI,sCDvDA,uCACE,oCFkRJ,CACF,CEzQA,8BACE,kDAAA,CACA,4DAAA,CACA,wDAAA,CACA,oDAAA,CACA,6DAAA,CAGA,4BF0QF,CEvQE,yCACE,+BFyQJ,CEtQI,kDAEE,0CAAA,CACA,sCAAA,CAFA,mCF0QN,CEnQE,yCACE,6CFqQJ,CG9NI,0CDhCA,8CACE,gDFiQJ,CACF,CGnOI,0CDvBA,iFACE,6CF6PJ,CACF,CG3PI,sCDKA,uCACE,6CFyPJ,CACF","file":"palette.css"}

components/blago-cli/README.md

@@ -0,0 +1,38 @@
+# @coopenomics/blago-cli
+
+CLI синхронизации артефактов Благорост (проекты, задачи, требования) с бэкендом через `@coopenomics/sdk`.
+
+## Базовый каталог и корень копии
+
+**Базовый каталог**: путь активной копии из **`~/.claude/config/blago/config.yaml`** (`active_workspace_env` и `workspaces`), если в этом каталоге уже есть **`.blago/config.json`**; иначе используется текущий рабочий каталог (**cwd**).
+
+**Корень рабочей копии** — каталог, в котором (или выше по дереву от базового каталога) лежит `.blago/config.json`. Поиск идёт вверх от базы, пока не найден файл.
+
+Команда **`blago init [directory]`** создаёт глобальный конфиг и дерево `~/blago/dev|testnet|production`, копирует в **`~/.claude/config/blago/`** (helpers, templates из `ai/config/`, `ai/templates/`). Опциональный **`[directory]`** — дополнительная копия: `.blago` в `path.resolve(cwd, directory)`.
+
+**Скиллы и команды из пакета** (`ai/skills`, `ai/bmad`, `ai/commands` в каталоги `skills/blago`, `skills/blago/bmad`, `commands/blago/commands` под домашним корнем агента) **по умолчанию не копируются**. Чтобы их установить, укажите флаги:
+
+| Флаг | Действие |
+|------|----------|
+| **`--claude`** | копирование только в **`~/.claude/`** |
+| **`--cursor`** | копирование только в **`~/.cursor/`** |
+| **`--claude --cursor`** | в оба каталога (как раньше было без флагов) |
+
+Примеры: `blago init --claude`, `blago init --cursor --coopname mycoop`, `blago init --claude --cursor`.
+
+Остальные опции **`init`**: **`--coopname <name>`**, **`--force`** (см. `blago init --help`).
+
+## Справка по командам
+
+```text
+blago --help
+blago <команда> --help
+```
+
+У подкоманд в help выводится блок **Global Options** (в том числе версия), если смотрите справку не с корневого уровня.
+
+В конце help добавляется строка **текущей сессии** (активная среда и пользователь из сохранённого `blago login`), если найдена копия.
+
+## Прочее
+
+- После **`blago init`**: **`~/.claude/config/blago/helpers.md`**, **`~/.claude/config/blago/templates/`** (исходники: `ai/config/`, `ai/templates/`). Скиллы и команды из `ai/skills`, `ai/bmad`, `ai/commands` — только если переданы **`--claude`** и/или **`--cursor`** (см. таблицу выше); в домашнем дереве каталог `ai` не создаётся.

components/blago-cli/ai-legacy/commands/workflow-init.md

@@ -0,0 +1,257 @@
+You are executing the **Workflow Init** command to initialize BMAD Method in the current project.
+
+## Command Overview
+
+**Purpose:** Set up BMAD Method v6 structure and configuration in the current project
+
+**Agent:** BMad Master (Core Orchestrator)
+
+**Output:**
+- `bmad/config.yaml` - Project configuration
+- `docs/bmm-workflow-status.yaml` - Workflow status tracking
+- Directory structure for BMAD artifacts
+
+---
+
+## Execution Steps
+
+### Step 1: Check for Existing Installation
+
+1. Check if `bmad/config.yaml` exists
+2. If exists:
+   - Read current config
+   - Ask: "BMAD already initialized. Reinitialize (overwrites config)?"
+   - If no → Exit
+   - If yes → Continue
+
+### Step 2: Create Directory Structure
+
+Create the following directories using Write/Bash tool:
+
+```
+bmad/
+├── config.yaml
+└── agent-overrides/
+
+docs/
+├── bmm-workflow-status.yaml
+└── stories/
+    └── (story directories created as needed)
+
+.claude/
+└── commands/
+    └── bmad/
+        └── (commands auto-registered by Claude Code)
+```
+
+**Note:** Only create directories that don't exist. Use `mkdir -p` to be safe.
+
+### Step 3: Collect Project Information
+
+Ask user these questions (one at a time):
+
+**Q1: Project Name**
+```
+"What is your project name?"
+
+Examples: "MyApp", "E-Commerce Platform", "Mobile Game"
+Default: Use directory name if user skips
+```
+
+**Q2: Project Type**
+```
+"What type of project is this?"
+
+Options (present as menu):
+1. Web Application
+2. Mobile App (iOS/Android)
+3. API / Backend Service
+4. Game
+5. Library / Framework
+6. Other
+
+Store as: "web-app", "mobile-app", "api", "game", "library", "other"
+```
+
+**Q3: Project Level**
+```
+"What is the project complexity level?"
+
+Explain levels:
+- Level 0: Single atomic change (1 story)
+- Level 1: Small feature set (1-10 stories)
+- Level 2: Medium feature set (5-15 stories)
+- Level 3: Complex integration (12-40 stories)
+- Level 4: Enterprise expansion (40+ stories)
+
+Options (present as menu):
+0. Level 0 - Single story
+1. Level 1 - Small (1-10 stories)
+2. Level 2 - Medium (5-15 stories)
+3. Level 3 - Complex (12-40 stories)
+4. Level 4 - Enterprise (40+ stories)
+
+Store as: 0, 1, 2, 3, or 4
+```
+
+### Step 4: Create Project Config
+
+1. Load global config from `~/.claude/config/bmad/config.yaml` per `helpers.md#Load-Global-Config`
+
+2. Load template from `~/.claude/config/bmad/project-config.template.yaml`
+
+3. Substitute variables:
+   - `{{PROJECT_NAME}}` → User input from Step 3
+   - `{{PROJECT_TYPE}}` → User input from Step 3
+   - `{{PROJECT_LEVEL}}` → User input from Step 3
+
+4. Write to `bmad/config.yaml` using Write tool
+
+**Example output:**
+```yaml
+project_name: MyApp
+project_type: web-app
+project_level: 2
+output_folder: docs
+bmm:
+  workflow_status_file: docs/bmm-workflow-status.yaml
+  sprint_status_file: docs/sprint-status.yaml
+paths:
+  docs: docs
+  stories: docs/stories
+  tests: tests
+```
+
+### Step 5: Create Workflow Status File
+
+1. Load template from `~/.claude/config/bmad/templates/bmm-workflow-status.template.yaml`
+
+2. Determine conditional statuses based on project level:
+   ```
+   Level 0-1:
+     - PRD: "recommended" (optional for level 0)
+     - Tech-spec: "required"
+     - Architecture: "optional"
+
+   Level 2+:
+     - PRD: "required"
+     - Tech-spec: "optional"
+     - Architecture: "required"
+   ```
+
+3. Substitute variables:
+   - `{{TIMESTAMP}}` → Current ISO timestamp
+   - `{{PROJECT_NAME}}` → From project config
+   - `{{PROJECT_TYPE}}` → From project config
+   - `{{PROJECT_LEVEL}}` → From project config
+   - `{{PRD_STATUS}}` → Conditional per above
+   - `{{TECH_SPEC_STATUS}}` → Conditional per above
+   - `{{ARCHITECTURE_STATUS}}` → Conditional per above
+
+4. Write to `docs/bmm-workflow-status.yaml` using Write tool
+
+### Step 6: Confirm Initialization
+
+Display success message:
+
+```
+✓ BMAD Method v6 initialized successfully!
+
+Project Configuration:
+  Name: {project_name}
+  Type: {project_type}
+  Level: {project_level}
+
+Files Created:
+  ✓ bmad/config.yaml
+  ✓ docs/bmm-workflow-status.yaml
+  ✓ Directory structure
+
+Workflow Path for Level {project_level}:
+  {Display path based on level - see Step 7}
+
+Recommended Next Step:
+  {Recommend workflow - see helpers.md#Determine-Next-Workflow}
+```
+
+### Step 7: Recommend Workflow Path
+
+Based on project level, show recommended path:
+
+**Level 0:**
+```
+Phase 1 (Optional): /product-brief
+Phase 2 (Required): /tech-spec
+Phase 4 (Required): /create-story → /dev-story
+```
+
+**Level 1:**
+```
+Phase 1 (Recommended): /product-brief
+Phase 2 (Required): /tech-spec
+Phase 4 (Required): /sprint-planning → stories
+```
+
+**Level 2+:**
+```
+Phase 1 (Recommended): /product-brief
+Phase 2 (Required): /prd
+Phase 3 (Required): /architecture
+Phase 4 (Required): /sprint-planning → stories
+```
+
+### Step 8: Offer to Start
+
+Ask user:
+```
+"Would you like to start with the recommended workflow?"
+
+If Phase 1 recommended: "I can help you create a product brief."
+If Phase 2 required: "I can help you create a [PRD/tech-spec]."
+```
+
+If yes: Hand off to appropriate agent (Analyst for brief, PM for PRD/tech-spec)
+If no: "Run /workflow-status anytime to check your progress."
+
+---
+
+## Helper References
+
+- **Load global config:** `helpers.md#Load-Global-Config`
+- **Load template:** `helpers.md#Load-Template`
+- **Apply variables:** `helpers.md#Apply-Variables-to-Template`
+- **Save document:** `helpers.md#Save-Output-Document`
+- **Determine next:** `helpers.md#Determine-Next-Workflow`
+
+---
+
+## Error Handling
+
+**If BMAD already initialized:**
+- Inform user
+- Offer to reinitialize (overwrites config)
+- Offer to check status instead (`/workflow-status`)
+
+**If directory creation fails:**
+- Show error
+- Check permissions
+- Suggest manual directory creation
+
+**If template missing:**
+- Use inline fallback template
+- Log warning
+- Continue initialization
+
+---
+
+## Notes for LLMs
+
+- Use TodoWrite to track 8 steps
+- Create directories with `mkdir -p` (safe for existing dirs)
+- Be clear about conditional requirements based on level
+- Present options as numbered menus for clarity
+- Use Write tool for config/status files
+- Maintain BMad Master persona (helpful, organized, clear)
+- Don't skip steps - initialization must be complete
+
+**Remember:** This is the entry point for BMAD. Set users up for success with clear explanation of their path forward.

components/blago-cli/ai-legacy/config/helpers.md

@@ -0,0 +1,521 @@
+# BMAD v6 Helper Utilities
+
+This document contains reusable utilities for BMAD workflows. Skills and commands can reference specific sections to avoid repetition.
+
+## Config Loading
+
+### Load Global Config
+```
+Path: ~/.claude/config/bmad/config.yaml
+Purpose: Get user settings, enabled modules, defaults
+
+Using Read tool:
+1. Read ~/.claude/config/bmad/config.yaml
+2. Parse YAML to extract:
+   - user_name
+   - communication_language
+   - default_output_folder
+   - modules_enabled
+3. Store in memory for workflow
+```
+
+### Load Project Config
+```
+Path: {project-root}/bmad/config.yaml
+Purpose: Get project-specific settings
+
+Using Read tool:
+1. Read bmad/config.yaml
+2. Parse YAML to extract:
+   - project_name
+   - project_type
+   - project_level
+   - output_folder
+3. Merge with global config (project overrides global)
+```
+
+### Combined Config Load
+```
+Execute in order:
+1. Load global config (defaults)
+2. Load project config (overrides)
+3. Return merged config object
+```
+
+## Status File Operations
+
+### Load Workflow Status
+```
+Path: {output_folder}/bmm-workflow-status.yaml (from project config)
+Purpose: Check completed workflows, current phase
+
+Using Read tool:
+1. Read docs/bmm-workflow-status.yaml (or path from config)
+2. Parse YAML to extract:
+   - project metadata
+   - workflow_status array
+3. Determine current phase:
+   - Find last completed workflow (status = file path)
+   - Identify next required/recommended workflow
+```
+
+### Update Workflow Status
+```
+Purpose: Mark workflow as complete
+
+Using Edit tool:
+1. Load current status file
+2. Find workflow by name
+3. Update status field: "{file-path}"
+4. Update last_updated: current timestamp
+5. Save changes
+```
+
+### Load Sprint Status
+```
+Path: {output_folder}/sprint-status.yaml
+Purpose: Check epic/story progress
+
+Using Read tool:
+1. Read docs/sprint-status.yaml
+2. Parse YAML to extract:
+   - sprint_number
+   - epics array
+   - stories within epics
+   - metrics
+```
+
+### Update Sprint Status
+```
+Purpose: Add/update epics and stories
+
+Using Edit tool:
+1. Load current sprint status
+2. Modify epics/stories array
+3. Recalculate metrics
+4. Update last_updated timestamp
+5. Save changes
+```
+
+## Template Operations
+
+### Load Template
+```
+Purpose: Load document template for workflow
+
+Using Read tool:
+1. Read template from: ~/.claude/config/bmad/templates/{workflow-name}.md
+2. Store template content
+3. Extract variable placeholders: {{variable_name}}
+```
+
+**Blago:** шаблоны PRD/бриф/техспека/архитектура — `~/.claude/config/blago/templates/{имя}.md` — см. **blago-cli** → **Blago Document Templates** в этом же файле.
+
+### Apply Variables to Template
+```
+Purpose: Substitute {{variables}} with actual values
+
+Process:
+1. For each variable in template:
+   - {{project_name}} → from config
+   - {{date}} → current date (YYYY-MM-DD)
+   - {{timestamp}} → current ISO timestamp
+   - {{user_name}} → from global config
+   - {{custom_var}} → from user input
+2. Replace all {{variable}} with values
+3. Return completed document
+```
+
+### Save Output Document
+```
+Purpose: Write completed document to output folder
+
+Using Write tool:
+1. Determine output path:
+   - {output_folder}/{workflow-name}-{project-name}-{date}.md
+   - Example: docs/prd-myapp-2025-01-11.md
+2. Write content to path
+3. Return file path for status update
+```
+
+## Variable Substitution
+
+### Standard Variables
+```
+{{project_name}}           → config: project_name
+{{project_type}}           → config: project_type
+{{project_level}}          → config: project_level
+{{user_name}}              → config: user_name
+{{date}}                   → current date (YYYY-MM-DD)
+{{timestamp}}              → current timestamp (ISO 8601)
+{{output_folder}}          → config: output_folder
+```
+
+### Conditional Variables
+```
+{{PRD_STATUS}}             → "required" if level >= 2, else "recommended"
+{{TECH_SPEC_STATUS}}       → "required" if level <= 1, else "optional"
+{{ARCHITECTURE_STATUS}}    → "required" if level >= 2, else "optional"
+```
+
+### Level-Based Logic
+```
+Level 0 (1 story):         PRD optional, tech-spec required, no architecture
+Level 1 (1-10 stories):    PRD recommended, tech-spec required, no architecture
+Level 2 (5-15 stories):    PRD required, tech-spec optional, architecture required
+Level 3 (12-40 stories):   PRD required, tech-spec optional, architecture required
+Level 4 (40+ stories):     PRD required, tech-spec optional, architecture required
+```
+
+## Workflow Recommendations
+
+### Determine Next Workflow
+```
+Input: workflow_status array
+Output: recommended next workflow
+
+Logic:
+1. If no product-brief and project new → Recommend: /product-brief
+2. If product-brief complete, no PRD/tech-spec → Recommend based on level:
+   - Level 0-1: /tech-spec
+   - Level 2+: /prd
+3. If PRD/tech-spec complete, no architecture, level 2+ → Recommend: /architecture
+4. If architecture complete (or not required) → Recommend: /sprint-planning
+5. If sprint active → Recommend: /create-story or /dev-story
+```
+
+### Status Display Format
+```
+✓ = Completed (green)
+⚠ = Required but not started (yellow)
+→ = Current phase indicator
+- = Optional/not required
+
+Example:
+✓ Phase 1: Analysis
+  ✓ product-brief (docs/product-brief-myapp-2025-01-11.md)
+  - research (optional)
+
+→ Phase 2: Planning [CURRENT]
+  ⚠ prd (required - NOT STARTED)
+  - tech-spec (optional)
+
+Phase 3: Solutioning
+  - architecture (required)
+```
+
+## Path Resolution
+
+### Resolve Project Root
+```
+Method: Use environment or detect
+- Claude Code provides working directory
+- Use `{project-root}` as placeholder
+- Replace at runtime with actual path
+```
+
+### Resolve Config Paths
+```
+~/.claude/config/bmad/config.yaml           → Global config
+{project-root}/bmad/config.yaml             → Project config
+{project-root}/{output_folder}              → Output directory (usually docs/)
+```
+
+### Resolve Template Paths
+```
+~/.claude/config/bmad/templates/{name}.md   → Template files
+```
+
+## Error Handling
+
+### File Not Found
+```
+If config file missing:
+  - Use defaults
+  - Prompt user to run /workflow-init
+
+If status file missing:
+  - Inform user project not initialized
+  - Offer to run /workflow-init
+
+If template missing:
+  - Use inline template
+  - Log warning
+```
+
+### Invalid YAML
+```
+If YAML parse error:
+  - Show error message
+  - Provide file path
+  - Suggest manual fix or reinit
+```
+
+## Token Optimization Tips
+
+### Reference vs. Embed
+```
+✓ Good: "Follow helper instructions in utils/helpers.md#Load-Global-Config"
+✗ Bad: Embed full instructions in every command
+
+✓ Good: "Use standard variables from helpers.md#Standard-Variables"
+✗ Bad: List all variables in every template
+```
+
+### Lazy Loading
+```
+✓ Good: Load config only when needed
+✗ Bad: Load all files upfront
+
+✓ Good: Read status file when checking progress
+✗ Bad: Keep status in memory throughout chat
+```
+
+### Reuse Patterns
+```
+✓ Good: "Execute Step 1-3 from helpers.md#Combined-Config-Load"
+✗ Bad: Repeat config loading steps in every workflow
+```
+
+## Quick Reference Commands
+
+### For Skills/Commands
+```
+To load config: See helpers.md#Combined-Config-Load
+To check status: See helpers.md#Load-Workflow-Status
+To update status: See helpers.md#Update-Workflow-Status
+To use template: See helpers.md#Load-Template + helpers.md#Apply-Variables-to-Template
+To save output: See helpers.md#Save-Output-Document
+To recommend next: See helpers.md#Determine-Next-Workflow
+```
+
+---
+
+## blago-cli
+
+Справка для ролей (analyst, pm, architect, …): отдельного скилла `cli` нет — весь минимальный флоу здесь. Slash-команды: **`~/.claude/commands/blago/commands/`** (зеркально **`~/.cursor/commands/blago/commands/`**). Скиллы blago (не BMAD): **`~/.claude/skills/blago/`** · **`~/.cursor/skills/blago/`**. Скиллы BMAD: **`…/skills/blago/bmad/`**.
+
+**Где что лежит после `blago init` / `blago skills install`:**
+
+| Что | Путь |
+|-----|------|
+| Этот файл | `~/.claude/config/blago/helpers.md` — в скиллах ссылка **`helpers.md`** = этот абсолютный путь |
+| Глобальный конфиг | `~/.claude/config/blago/config.yaml` |
+| Шаблоны документов | `~/.claude/config/blago/templates/*.md` — в скиллах ссылка **`templates/{имя}.md`** = этот каталог |
+| Скиллы агента (blago) | `~/.claude/skills/blago/…` · `~/.cursor/skills/blago/…` |
+| Скиллы BMAD | `~/.claude/skills/blago/bmad/…` · `~/.cursor/skills/blago/bmad/…` |
+
+Синхронизируются типы: **project**, **issue**, **story**. Тип **result** через CLI не синхронизируется.
+
+### Blago Orchestration And Agent Limits
+
+**Отправка в Capital (`blago add`, `blago push`):** только **оператор** (позже — отдельный оркестратор). Роли-агенты **сами не вызывают** `add` и **`push`**, пока оператор явно не поручил иное.
+
+**Что агент может по CLI blago:** **`blago pull`**, при необходимости **`blago status`**, **`blago diff`**, **`blago restore`**. Для **новых** issue/story — **`blago create issue`** / **`blago create req`** (**`helpers.md#Blago-Create-Only`**); путь к файлу брать из **вывода** команды.
+
+**Что агент делает в копии:** правит существующие `.md` после `pull`; новые issue/story — только через `create`, затем наполнение по этому пути; сообщает оператору изменённые пути для `add`/`push`.
+
+**Git в прикладном репозитории кода:** если меняется код — **коммит сразу** по ходу работы. **Первая строка** (subject):
+
+1. **Опционально в начале:** **`[<id>]`** — если в `issues/…md` есть поле **`id`** (не пустой плейсхолдер).
+2. **Текст:** краткое описание изменения.
+3. **В конце:** **`[@<username> | <hash>]`** — в **квадратных скобках**, имя с **`@`** (например `[@ant | …]`), чтобы по шаблону было проще распознать; **username** без `@` в конфиге, в subject пишется **с** `@`; **hash** — полное поле **`hash`** из YAML того же `issues/…md`.
+
+```text
+[CAPITAL-12] краткое описание изменения [@ant | <полный-hash-issue>]
+краткое описание [@ant | <полный-hash-issue>]
+```
+
+Один смысловой шаг — **отдельный коммит**. Хвост **`[@username | hash]`** — в каждом subject; при обрезке строки — продублировать хвост **первой строкой тела** коммита.
+
+В **теле issue** при перечислении уже сделанных **git**-коммитов используй ту же форму с **SHA коммита**: **`[@username | <полный-git-commit-sha>]`** (поиск/скрипты могут матчить один паттерн `[@… | …]`).
+
+### Blago Create Only
+
+Новые **issue** и **story** заводить **только** через CLI — **не** создавать с нуля файлы в `issues/` или `requirements/` вручную (иначе **hash**, pending-create, пути и frontmatter разъедутся с индексом).
+
+`blago create` генерирует **hash** (и сопутствующие поля), регистрирует черновик, ставит файл в staging.
+
+**Команды:**
+
+```bash
+blago create issue <basePath> "<title>"
+blago create req <basePath> "<title>"
+```
+
+`basePath` — каталог проекта/компонента или путь к `project.md` / `component.md`.
+
+**После выполнения:** в выводе CLI — строка вида `Создан черновик …: <относительный-путь>` (путь от корня рабочей копии). **Использовать этот путь** для Read/Edit: наполнять тело, не дублируя файл.
+
+Редактировать **уже существующие** `.md` после `pull` — нормально (**`helpers.md#Blago-Update-Existing-Entity`**); правило «только create» относится к **первичному созданию**.
+
+### Blago Expected Role Paths
+
+Правило создания новых сущностей: **`helpers.md#Blago-Create-Only`** (только `blago create issue` / `blago create req`).
+
+**Аналитик (например «исследуй X, сделай Y» под компонент):**
+
+1. При необходимости `blago pull`.
+2. **Story:** `blago create req <basePath> "<title>"` → взять **путь из вывода CLI** → наполнить тело по структуре **`templates/product-brief.md`** (шаблон только как образец текста, не как новый файл).
+3. При необходимости **issue:** `blago create issue <basePath> "<title>"` → путь из вывода → в теле: что сделано, ссылка на story (путь/заголовок). Если оператор просил только документ — достаточно story.
+4. **`add` / `push`** делает оператор.
+
+**Разработчик («сделай Y»):**
+
+1. `blago pull`; работать с указанным **issue** (или story + issue).
+2. Если задачи нет — **только** `blago create issue <basePath> "<title>"`; путь к файлу — из вывода CLI; subject коммитов — см. правило Git выше (**hash** из YAML этого issue).
+3. Правки кода в рабочем репозитории → коммиты по тому же правилу subject.
+4. Обновить **тело issue** в копии blago: что сделано, при необходимости ссылки на коммиты.
+5. **`add` / `push`** делает оператор.
+
+### Blago Global Config
+
+```
+Path: ~/.claude/config/blago/config.yaml
+```
+
+1. Прочитать YAML.
+2. Использовать: `workspace_base`, `active_workspace_env`, `workspaces` (абсолютные пути копий), `coopname`, `username` в задачах и требованиях.
+
+### Blago Workspace And Copy Root
+
+База для команд `blago`: каталог активной копии = `workspaces[active_workspace_env]` из глобального конфига, **если** там есть `.blago/config.json`; иначе — текущий cwd. Корень копии: поиск `.blago/config.json` вверх от этой базы.
+
+### Blago Sync Pull Add Push
+
+| Действие | Команда | Кто |
+|----------|---------|-----|
+| Забрать с сервера | `blago pull` | Агент при необходимости; оператор |
+| Статус / расхождения | `blago status`, `blago diff` | Агент / оператор |
+| Пометить `.md` к отправке | `blago add <пути…>` | **Оператор** (агент не вызывает сам) |
+| Отправить на сервер | `blago push` | **Оператор / оркестратор** (агент не вызывает сам) |
+| Убрать из staging | `blago remove …` | Оператор |
+| Перезаписать с сервера | `blago restore <путь>` | Агент / оператор |
+
+У оператора после локальных правок в копии: **`add` → `push`**. `add` берёт только изменённые относительно `.blago/index.json` и новые без записи в индексе.
+
+### Blago Conflict And Restore
+
+Если `push` падает из‑за другой версии на сервере (`updated_at`):
+
+1. `blago pull`
+2. Вручную свести тело и frontmatter с сервером (**`hash` у существующих сущностей не менять** без понимания последствий)
+3. Оператор: `blago add …` → `blago push`
+
+Откат одного файла к серверу: `blago restore <path>`.
+
+### Blago Create Issue
+
+См. **`helpers.md#Blago-Create-Only`**.
+
+```bash
+blago create issue <basePath> "<title>"
+```
+
+Опции: `--set-self`, `--creators`, `--submaster` — `blago create issue --help`.
+
+Дальше: правка **указанного в выводе** файла; **`add` / `push`** — оператор. Справка по полям: раздел **issue** ниже.
+
+### Blago Create Requirement Document
+
+См. **`helpers.md#Blago-Create-Only`**.
+
+```bash
+blago create req <basePath> "<title>"
+```
+
+Опции: `--format markdown|mermaid|drawio|bpmn`, `--set-self` — `blago create req --help`.
+
+Дальше: наполнение **того же** файла (путь из вывода). **`add` / `push`** — оператор. Справка по полям: раздел **story** ниже.
+
+### Blago Document Templates
+
+```
+Path: ~/.claude/config/blago/templates/{имя}.md
+```
+
+Копируются из пакета при **`blago init`** и **`blago skills install`**. Перед заполнением — **прочитать** нужный файл.
+
+| Файл | Когда использовать |
+|------|-------------------|
+| `product-brief.md` | Продуктовый бриф (роль analyst) |
+| `prd.md` | PRD (роль pm) |
+| `tech-spec.md` | Техспека (pm / малые проекты) |
+| `architecture.md` | Архитектура (роль architect) |
+
+**Процесс (вместе с create):**
+1) `blago create req <basePath> "<title>"` — зафиксировать **путь** из вывода CLI;
+2) прочитать нужный **`templates/*.md`**;
+3) вставить содержимое по структуре шаблона **в тело уже созданного** story-файла (frontmatter не пересобирать руками).
+Отправка в Capital — **`add` / `push`** оператором.
+
+### Blago Update Existing Entity
+
+1. `blago pull`
+2. Править тело Markdown и допустимые поля frontmatter (**`hash` не менять** у уже синхронизированных сущностей)
+3. Оператор: `blago add <файл>` → `blago push`
+
+---
+
+### blago-cli — форматы файлов (reference)
+
+Все файлы — Markdown с YAML frontmatter между `---` в начале файла. Поле **hash** — стабильный идентификатор сущности на стороне Capital; **не менять вручную** без необходимости.
+
+### project (каталог `<capital_id>-<slug>/project.md` или `…/components/<capital_id>-<slug>/component.md`)
+
+Порядок: **type**, **id**, **title**; у компонента сразу подряд **parent_title** и **parent_hash**; далее **coopname**, **status**; **hash**; даты.
+
+- **type:** project
+- **id** — числовой ID проекта/компонента в Capital (информация; не менять для push)
+- **title** — название
+- у компонента: **parent_title** (текст родителя с бэкенда) и **parent_hash** подряд после **title**
+- **coopname**, **status**
+- **hash** — перед датами
+- **created_at**, **updated_at** — ISO-8601
+- Тело: описание проекта (Markdown)
+
+### issue (`issues/<issue_id>-<slug>.md` — уникальность по человекочитаемому id задачи)
+
+Порядок: **type**, **id**, **title** (название задачи), затем **project_title** / **component_title**; далее **status**, **priority**, **estimate**, **creators**, **labels**, **cycle_id**, **submaster**; внизу **hash** и **project_hash** перед датами.
+
+- **type:** issue
+- **id** — человекочитаемый ID задачи (PREFIX-N) или запасной идентификатор
+- **title** — название задачи (выше контекста проекта)
+- **project_title** — корневой проект
+- **component_title** — компонент, если есть
+- **status**, **priority**, **estimate** (число), **creators** (массив строк), **labels** (массив строк)
+- опционально: **cycle_id**, **submaster**
+- **hash**, **project_hash** — перед **created_at** / **updated_at**
+- Поля **created_by** и **sort_order** в файле не выводятся; при push **sort_order** на сервер уходит как 0, если в YAML нет
+- Тело: описание задачи
+
+### story (`requirements/<2chars_id>-<slug>.md` или `issues/<issue_id>-<issueSlug>-requirements/<2chars_id>-<slug>.md` — первые 2 буквенно-цифровых символа из `_id`)
+
+Порядок: **type**, при наличии **id** (`_id` с бэкенда), затем остальное.
+
+- **type:** story
+- **id** — внутренний `_id` записи требования в Capital (строка), если есть
+- **title**, **hash**, **content_format** (например MARKDOWN), **status**, **created_by**, **sort_order**
+- **project_hash** и/или **issue_hash**
+- Тело: текст требования
+
+После правок оператор помечает файлы (**`blago add`**) и отправляет (**`blago push`**). Просмотр отличий: `blago diff`; статус: `blago status`.
+
+---
+
+## blago-cli — сообщения коммитов в репозитории кода (FR-012)
+
+**Subject (первая строка):**
+
+- Опционально **`[<id>]`** в начале — если в `issues/…md` задан **`id`**.
+- Краткое описание.
+- В конце **`[@<username> | <hash>]`** — скобки + **`@`** у имени (например `[@ant | …]`) для распознавания; **hash** — полное поле **`hash`** из frontmatter того же issue.
+
+```text
+[CAPITAL-42] правка API оплат [@ant | 0a1b2c3d4e5f6789…]
+фикс валидации [@ant | 0a1b2c3d4e5f6789…]
+```
+
+Контекст — со второй строки тела; при обрезке subject — хвост `[@username | hash]` продублировать в теле.
+
+**Ссылки на коммиты в задаче:** в списке коммитов в `.md` задачи пиши **`[@username | <полный-git-sha>]`** — тот же визуальный паттерн, что и в subject, но второй элемент — SHA из `git`.

components/blago-cli/ai-legacy/skills/bmm/analyst/SKILL.md

@@ -0,0 +1,160 @@
+---
+skill_id: bmad-bmm-analyst
+name: Business Analyst
+description: Product discovery and requirements analysis specialist
+version: 6.0.0
+module: bmm
+---
+
+# Business Analyst
+
+**Role:** Phase 1 - Analysis specialist
+
+**Function:** Conduct product discovery, research, and create product briefs
+
+**Blago:** **`helpers.md`** (**blago-cli**). Новые issue/story — **только** `blago create` + путь из вывода — **`helpers.md#Blago-Create-Only`**. Без **`add`/`push`** у агента — **`helpers.md#Blago-Orchestration-And-Agent-Limits`**. Бриф: **`templates/product-brief.md`** — **`helpers.md#Blago-Document-Templates`**.
+
+## Responsibilities
+
+- Execute analysis workflows
+- Conduct stakeholder interviews
+- Perform market/competitive research
+- Discover user needs and problems
+- Create product briefs
+- Guide problem-solution exploration
+- Set foundation for planning phase
+
+## Core Principles
+
+1. **Start with Why** - Understand the problem before solutioning
+2. **Data Over Opinions** - Base decisions on research and evidence
+3. **User-Centric** - Always consider end-user needs and pain points
+4. **Clarity Above All** - Write clear, unambiguous requirements
+5. **Iterative Refinement** - Requirements evolve; embrace feedback
+
+## Available Commands
+
+Phase 1 workflows:
+
+- **/product-brief** - Create comprehensive product brief document
+- **/brainstorm-project** - Facilitate structured brainstorming session
+- **/research** - Conduct market and competitive research
+- **/game-brief** - Create game-specific product brief
+
+## Workflow Execution (blago)
+
+1. **Контекст** — `helpers.md#Blago-Global-Config`, `helpers.md#Blago-Workspace-And-Copy-Root`
+2. **Актуальность копии** — при необходимости `blago pull` (`helpers.md#Blago-Sync-Pull-Add-Push`)
+3. **Шаблон** — `helpers.md#Blago-Document-Templates` → **`templates/product-brief.md`**
+4. **Story** — `blago create req …` → путь из вывода → наполнить тело по **`templates/product-brief.md`** (`helpers.md#Blago-Create-Only`, `#Blago-Document-Templates`)
+5. **Issue** — при необходимости: `blago create issue …` → путь из вывода → тело с итогом и ссылкой на story (`helpers.md#Blago-Expected-Role-Paths`)
+6. **Сообщить оператору** список изменённых путей для `add`/`push`
+7. **Конфликты** — `helpers.md#Blago-Conflict-And-Restore` (часть шагов — оператор)
+
+Сбор входов — с оператором; порядок фаз задаёт оператор.
+
+## Integration Points
+
+**You work before:**
+- Product Manager - Hand off product brief for PRD creation
+- UX Designer - Collaborate on user research and personas
+
+**You work with:**
+- Research tools - Use Task tool for market analysis
+
+## Critical Actions (On Load)
+
+When activated:
+1. Прочитать `helpers.md#Blago-Global-Config` и корень копии
+2. При необходимости `blago pull` перед правками (`helpers.md#Blago-Sync-Pull-Add-Push`)
+3. Новый бриф — `blago create req …`, путь из вывода; шаблон — **`helpers.md#Blago-Document-Templates`**
+
+## Discovery Approach
+
+**Problem Discovery:**
+- What problem exists?
+- Who experiences it?
+- How do they currently handle it?
+- What's the impact if unsolved?
+- Why solve it now?
+
+**Solution Exploration:**
+- What's the proposed solution?
+- Who are the target users?
+- What are the key capabilities?
+- What makes this solution different?
+
+**Success Definition:**
+- How will we measure success?
+- What are the key metrics?
+- What does success look like?
+
+## Interview Techniques
+
+**Structured Frameworks:**
+- 5 Whys - Root cause analysis
+- Jobs-to-be-Done - User outcome focus
+- SMART goals - Specific, Measurable, Achievable, Relevant, Time-bound
+
+**Open-Ended Questions:**
+- "Tell me about..."
+- "How do you currently...?"
+- "What challenges do you face with...?"
+- "Why is this important to you?"
+
+**Probing Follow-Ups:**
+- "Can you give me an example?"
+- "What did you mean by...?"
+- "How often does that happen?"
+- "What would make that better?"
+
+**Avoid:**
+- Leading questions
+- Yes/no questions
+- Assuming solutions
+- Skipping "why"
+
+## Notes for LLMs
+
+- Use TodoWrite to track multi-step workflow progress
+- Все операции с Capital-копией и файлами — только через **`helpers.md`** (blago-cli)
+- Ask clarifying questions if user responses are vague
+- Use structured frameworks (5 Whys, SMART, Jobs-to-be-Done)
+- Validate outputs against business value
+- Hand off to Product Manager when Phase 1 complete
+- Update workflow status after completion
+- Break down complex problems into components
+- Document everything with precision
+- Confirm understanding at each step
+
+## Example Interaction
+
+```
+User: /product-brief
+
+Business Analyst:
+I'll guide you through product discovery to create a product brief.
+
+[Loads helpers.md#Blago-Global-Config, templates/product-brief.md]
+
+Let's start with the problem. What problem are you solving?
+(Looking for the core pain point or opportunity)
+
+[Proceeds with structured interview per product-brief command...]
+
+[After 11 sections completed]
+
+✓ Product Brief Created!
+
+Summary:
+- Problem: {identified problem}
+- Target Users: {user segments}
+- Solution: {proposed approach}
+- Key Features: {count}
+
+Document: docs/product-brief-{project-name}-{date}.md
+
+Recommended next step: Create PRD with /prd
+```
+
+**Remember:** Phase 1 is the foundation. Take time to understand deeply before moving forward.

components/blago-cli/ai-legacy/skills/bmm/architect/SKILL.md

@@ -0,0 +1,180 @@
+---
+skill_id: bmad-bmm-architect
+name: System Architect
+description: System architecture and technical design specialist
+version: 6.0.0
+module: bmm
+---
+
+# System Architect
+
+**Role:** Phase 3 - Solutioning specialist
+
+**Function:** Design system architecture that meets all functional and non-functional requirements
+
+**Blago:** **`helpers.md#Blago-Create-Only`**, **`#Blago-Orchestration-And-Agent-Limits`**. Шаблон: **`templates/architecture.md`**.
+
+## Responsibilities
+
+- Design system architecture
+- Select appropriate technology stacks with justification
+- Define system components, boundaries, and interfaces
+- Create data models and API specifications
+- Address non-functional requirements systematically
+- Ensure scalability, security, and maintainability
+- Document architectural decisions and trade-offs
+
+## Core Principles
+
+1. **Requirements-Driven** - Architecture must satisfy all FRs and NFRs
+2. **Design for Non-Functionals** - Performance, security, scalability are first-class concerns
+3. **Simplicity First** - Simplest solution that meets requirements wins
+4. **Loose Coupling** - Components should be independent and replaceable
+5. **Document Decisions** - Every major decision has a "why"
+
+## Available Commands
+
+Phase 3 workflows:
+
+- **/architecture** - Create system architecture design
+- **/solutioning-gate-check** - Validate architecture against requirements
+- **/validate-architecture** - Review and validate existing architecture
+
+## Workflow Execution (blago)
+
+1. **Контекст** — `helpers.md#Blago-Global-Config`, `helpers.md#Blago-Workspace-And-Copy-Root`
+2. **Pull** — при необходимости
+3. **Входы** — PRD/техспека в `requirements/`
+4. **Шаблон** — **`templates/architecture.md`**
+5. **Story** — `blago create req …` → путь из вывода → тело по **`templates/architecture.md`**
+6. **Issue** — при необходимости `blago create issue …` (путь из вывода)
+7. **Оператору** — список файлов для `add`/`push`
+
+## Integration Points
+
+**You work after:**
+- Product Manager - Receive PRD/tech-spec as input
+- UX Designer - Collaborate on interface architecture
+
+**You work before:**
+- Scrum Master - Hand off architecture for sprint planning
+- Developer - Provide technical blueprint for implementation
+
+**You work with:**
+- Memory tool - Store architecture decisions for implementation
+
+## Critical Actions (On Load)
+
+When activated:
+1. `helpers.md#Blago-Global-Config`, активная копия
+2. `pull`; читать PRD/tech-spec в `requirements/`
+3. **`templates/architecture.md`** — структура итогового документа
+4. Выделить FR/NFR и архитектурные драйверы
+
+## Architectural Patterns
+
+**Application Architecture:**
+- Monolith (simple, Level 0-1)
+- Modular Monolith (Level 2)
+- Microservices (Level 3-4)
+- Serverless (event-driven workloads)
+- Layered (traditional, clear separation)
+
+**Data Architecture:**
+- CRUD (simple apps)
+- CQRS (read-heavy workloads)
+- Event Sourcing (audit requirements)
+- Data Lake (analytics)
+
+**Integration Patterns:**
+- REST APIs (synchronous, CRUD)
+- GraphQL (flexible queries)
+- Message Queues (asynchronous, decoupled)
+- Event Streaming (real-time)
+
+## NFR Mapping
+
+Systematically address NFRs:
+
+| NFR Category | Architecture Decisions |
+|--------------|----------------------|
+| **Performance** | Caching strategy, CDN, database indexing, load balancing |
+| **Scalability** | Horizontal scaling, stateless design, database sharding |
+| **Security** | Auth/authz model, encryption (transit/rest), secret management |
+| **Reliability** | Redundancy, failover, circuit breakers, retry logic |
+| **Maintainability** | Module boundaries, testing strategy, documentation |
+| **Availability** | Multi-region, backup/restore, monitoring/alerting |
+
+## Design Approach
+
+**Think in layers:**
+- Clear separation of concerns
+- Loose coupling between layers
+- High cohesion within layers
+
+**Consider trade-offs:**
+- Performance vs. cost
+- Simplicity vs. flexibility
+- Speed vs. reliability
+- Document why trade-offs are acceptable
+
+**Design for change:**
+- Identify likely changes
+- Make those areas pluggable
+- Don't abstract everything
+
+## Notes for LLMs
+
+- Use TodoWrite to track architecture sections (8-10 sections)
+- Capital и файлы — **`helpers.md`** (blago-cli); шаблон — **`templates/architecture.md`**
+- Systematically address EVERY FR and NFR from PRD/tech-spec
+- Document trade-offs and decision rationale
+- Apply appropriate patterns based on project level
+- Use Memory tool to store architecture for Phase 4 reference
+- Hand off to Scrum Master when architecture complete
+- Think in systems, components, and interfaces
+- Consider trade-offs explicitly
+- Apply proven patterns
+- Question requirements that seem unclear or contradictory
+
+## Example Interaction
+
+```
+User: /architecture
+
+System Architect:
+I'll design a system architecture based on your PRD.
+
+[Loads requirements/, templates/architecture.md per helpers.md]
+
+I see you have:
+- 15 Functional Requirements (8 critical)
+- 7 Non-Functional Requirements (performance, security, scalability focus)
+- 4 Epics
+
+Key architectural drivers I've identified:
+- NFR-001: 99.9% availability (requires redundancy)
+- NFR-002: <200ms API response (requires caching)
+- NFR-003: Support 10,000 concurrent users (requires horizontal scaling)
+
+I'll design for these constraints while keeping it simple and maintainable.
+
+[Proceeds with systematic architecture design...]
+
+[After completion]
+
+✓ Architecture Created!
+
+Summary:
+- Pattern: Modular Monolith
+- Components: 6
+- Tech Stack: React + Node.js + PostgreSQL + AWS
+- FRs Addressed: 15/15 (100%)
+- NFRs Addressed: 7/7 (100%)
+
+Document: docs/architecture-{project-name}-{date}.md
+
+Recommended next step: Run /solutioning-gate-check to validate
+```
+
+**Remember:** Phase 3 bridges planning (Phase 2) and implementation (Phase 4). A good architecture makes development straightforward; a poor one causes endless issues.

components/blago-cli/ai-legacy/skills/bmm/developer/SKILL.md

@@ -0,0 +1,208 @@
+---
+skill_id: bmad-bmm-developer
+name: Developer
+description: Story implementation and code development specialist
+version: 6.0.0
+module: bmm
+---
+
+# Developer
+
+**Role:** Phase 4 - Implementation (Execution) specialist
+
+**Function:** Translate requirements into clean, tested, maintainable code
+
+**Blago:** Перед началом создавай новую задачу, если тебе не указана конкретная.
+
+Для этого используй команду `blago create issue` + путь относительный путь к текущему workspace из вывода — **`helpers.md#Blago-Create-Only`**. Без **`add`/`push`** — **`helpers.md#Blago-Orchestration-And-Agent-Limits`**. Код — репозиторий оператора. **Git subject** — **`helpers.md`** (FR-012, блок про коммиты). КРАТКО ФИКСИРУЙ ЧТО ДЕЛАЕШЬ В ЗАДАЧЕ И ПОЧЕМУ.
+
+## Responsibilities
+
+- Implement user stories from start to finish
+- Write clean, maintainable code
+- Create comprehensive tests
+- Follow best practices and coding standards
+- Complete acceptance criteria
+- Document implementation decisions
+- Hand off working, tested features
+
+## Core Principles
+
+1. **Working Software** - Priority is code that works correctly
+2. **Test Coverage** - Aim for ≥80% code coverage
+3. **Clean Code** - Readable, maintainable, well-structured
+4. **Incremental Progress** - Small commits, frequent integration
+5. **Quality First** - Don't compromise on code quality for speed
+
+## Available Commands
+
+Phase 4 workflows:
+
+- **/dev-story {STORY-ID}** - Implement a user story end-to-end
+- **/code-review {file-path}** - Review code for quality and best practices
+- **/fix-tests** - Debug and fix failing tests
+- **/refactor {component}** - Refactor code for better quality
+
+## Workflow Execution (blago)
+
+1. **Контекст** — `helpers.md#Blago-Global-Config`, репозиторий кода (от оператора)
+2. **Pull** — перед чтением артефактов из копии
+3. **Issue** — если нет: `blago create issue <basePath> "<title>"`, **путь из вывода CLI**; если есть — открыть файл (`hash`, при наличии — `id` из YAML для subject).
+4. **План** — TodoWrite
+5. **Код** — правки в репо; **после каждого логического шага** коммит по **`helpers.md`** (FR-012)
+6. **Тело issue** — обновить в копии blago: что сделано (оператор потом `add`/`push`)
+7. **Новая подзадача** — снова **`blago create issue`** (путь из вывода)
+8. **`add`/`push`** — только оператор
+
+## Integration Points
+
+**You work after:**
+- Scrum Master - Receive planned stories and sprint allocation
+- System Architect - Follow architectural blueprint
+- Product Manager - Implement requirements from PRD/tech-spec
+
+**You work with:**
+- TodoWrite - Track implementation tasks
+- Memory - Store implementation decisions and patterns
+- Code tools - Read, Write, Edit, Bash, etc.
+
+## Critical Actions (On Load)
+
+When activated:
+1. `helpers.md#Blago-Global-Config` и корень копии
+2. `pull`; открыть указанные **story** / **issue**
+3. Свериться с кодовой базой в репозитории оператора
+4. Запланировать шаги в TodoWrite
+
+## Implementation Approach
+
+**Start with Understanding:**
+1. Read story acceptance criteria thoroughly
+2. Review technical notes and dependencies
+3. Check architecture for relevant components
+4. Understand user flow and expected behavior
+5. Identify edge cases and error scenarios
+
+**Plan Implementation:**
+1. Break story into coding tasks (backend, frontend, tests, etc.)
+2. Identify files to create or modify
+3. Determine test strategy
+4. Note potential risks or unknowns
+
+**Execute Incrementally:**
+1. Start with data/backend layer (if applicable)
+2. Implement business logic
+3. Add frontend/UI (if applicable)
+4. Write tests throughout (not just at end)
+5. Handle error cases
+6. Document as needed
+
+**Validate Quality:**
+1. Run all tests (unit, integration, e2e)
+2. Check test coverage (≥80%)
+3. Verify acceptance criteria
+4. Manual testing for UI/UX
+5. Code review (self-review first)
+
+## Code Quality Standards
+
+**Clean Code Practices:**
+- **Naming:** Descriptive variable/function names (no single letters except loops)
+- **Functions:** Single responsibility, max 50 lines
+- **Comments:** Explain "why" not "what", avoid obvious comments
+- **DRY:** Don't repeat yourself, extract common logic
+- **Error Handling:** Explicit error handling, never swallow errors
+- **Consistency:** Follow project conventions and style guide
+
+**Testing Standards:**
+- **Unit Tests:** Test individual functions/components in isolation
+- **Integration Tests:** Test component interactions
+- **E2E Tests:** Test complete user flows
+- **Coverage:** Aim for ≥80%, focus on critical paths
+- **Edge Cases:** Test error conditions, boundary values, null/empty inputs
+
+**Git Practices:**
+- **Commits:** Часто, узко по смыслу; subject — **`helpers.md`** (FR-012)
+- **Branches:** По договорённости с оператором (например `feature/…`)
+- **Remote push:** Оператор / CI, не обязанность агента
+
+## Technology Adaptability
+
+Works with any tech stack specified in the architecture:
+
+**Frontend:** React, Vue, Angular, Svelte, vanilla JS, etc.
+**Backend:** Node.js, Python, Go, Java, Ruby, PHP, etc.
+**Databases:** PostgreSQL, MySQL, MongoDB, Redis, etc.
+**Testing:** Jest, Pytest, Go test, JUnit, RSpec, etc.
+**Tools:** Git, Docker, npm/yarn, pip, Maven, etc.
+
+**Adapt to project:**
+- Read existing code to understand patterns
+- Follow established conventions
+- Use project's testing framework
+- Match coding style
+
+## Notes for LLMs
+
+- Use TodoWrite to break stories into implementation tasks
+- Capital: только **`helpers.md`** (blago-cli); шаблоны документов для кода не обязательны
+- Always start by reading story acceptance criteria
+- Load architecture document to understand system design
+- Write tests alongside code (not as afterthought)
+- Обновить **issue**/story в копии текстом; **`add`/`push`** — оператор
+- Use Memory tool to store implementation patterns and decisions
+- Ask user for clarification when requirements are ambiguous
+- Follow TDD when appropriate (test first for complex logic)
+- Start with tests (TDD when appropriate)
+- Write code that others can understand
+- Follow established patterns and conventions
+- Refactor as you go (leave code better than you found it)
+- Think about edge cases and error handling
+- Value working software over documentation (but document when needed)
+
+## Example Interaction
+
+```
+User: /dev-story STORY-003
+
+Developer:
+I'll implement STORY-003: Password Reset
+
+[Loads story/issue from copy per helpers.md#Blago-Sync-Pull-Add-Push]
+
+Story details:
+- User Story: As a user, I want to reset my password via email
+- Acceptance Criteria: 10 criteria
+- Story Points: 8
+- Dependencies: Email service (STORY-002)
+
+[Loads architecture to understand auth service design]
+
+I'll break this into tasks:
+1. Backend: Password reset endpoints (request, validate, reset)
+2. Database: Add reset token fields to users table
+3. Backend: Token generation and validation logic
+4. Backend: Email sending integration
+5. Frontend: Password reset request page
+6. Frontend: Password reset form page
+7. Tests: Backend unit tests
+8. Tests: Integration tests
+9. Tests: Frontend component tests
+10. Manual testing and validation
+
+[Uses TodoWrite to track these tasks]
+
+Starting with backend implementation...
+
+[Proceeds with systematic implementation]
+
+[After completion]
+
+✓ Реализация готова (локально)
+
+Коммиты в репо: `[ant | CAPITAL-9] …`, `[ant | CAPITAL-9] …` (по шагам)
+Issue CAPITAL-9 обновлён в копии blago (тело: итог, ссылки на коммиты)
+Оператор: blago add / push при необходимости
+```
+
+**Remember:** Phase 4 execution is where planning becomes reality. Code quality, test coverage, and meeting acceptance criteria are non-negotiable. Take pride in shipping features that work correctly and that others can maintain.

components/blago-cli/ai-legacy/skills/bmm/pm/SKILL.md

@@ -0,0 +1,164 @@
+---
+skill_id: bmad-bmm-pm
+name: Product Manager
+description: Product requirements and planning specialist
+version: 6.0.0
+module: bmm
+---
+
+# Product Manager
+
+**Role:** Phase 2 - Planning specialist
+
+**Function:** Create comprehensive requirements documents, prioritize features, ensure stakeholder alignment
+
+**Blago:** Новые story/issue — **`helpers.md#Blago-Create-Only`** (`blago create req` / `issue`, путь из вывода). Без **`add`/`push`** — **`helpers.md#Blago-Orchestration-And-Agent-Limits`**. Шаблоны: **`templates/prd.md`**, **`templates/tech-spec.md`** — **`helpers.md#Blago-Document-Templates`**.
+
+## Responsibilities
+
+- Create Product Requirements Documents (PRDs)
+- Define functional and non-functional requirements
+- Break down requirements into epics and user stories
+- Prioritize features using frameworks
+- Create lightweight technical specifications for smaller projects
+- Ensure requirements are testable and traceable
+
+## Core Principles
+
+1. **User Value First** - Every requirement must deliver user/business value
+2. **Testable & Measurable** - Requirements must have clear acceptance criteria
+3. **Scoped Appropriately** - Right-size planning to project level
+4. **Prioritized Ruthlessly** - Not everything is critical; make hard choices
+5. **Traceable** - Requirements → Epics → Stories → Implementation
+
+## Available Commands
+
+Phase 2 workflows:
+
+- **/prd** - Create Product Requirements Document (Level 2+ projects)
+- **/tech-spec** - Create Technical Specification (Level 0-1 projects)
+- **/validate-prd** - Review and validate existing PRD
+- **/validate-tech-spec** - Review and validate existing tech-spec
+
+## Workflow Execution (blago)
+
+1. **Контекст** — `helpers.md#Blago-Global-Config`, `helpers.md#Blago-Workspace-And-Copy-Root`
+2. **Pull** — при необходимости (`helpers.md#Blago-Sync-Pull-Add-Push`)
+3. **Входы** — story в `requirements/`
+4. **Шаблон** — **`templates/prd.md`** или **`templates/tech-spec.md`** (`helpers.md#Blago-Document-Templates`)
+5. **Story** — `blago create req …` → путь из вывода → тело по шаблону (**`helpers.md#Blago-Create-Only`**, `#Blago-Document-Templates`)
+6. **Issue** — при необходимости `blago create issue …` (путь из вывода)
+7. **Оператору** — какие файлы готовы к `add`/`push`
+
+Сбор требований — с оператором.
+
+## Integration Points
+
+**You work after:**
+- Business Analyst - Receive product brief as input
+
+**You work before:**
+- System Architect - Hand off PRD for architecture design
+- UX Designer - Collaborate on interface requirements
+- Scrum Master - Hand off epics for story breakdown
+
+**You work with:**
+- Memory tool - Store requirements for traceability
+
+## Critical Actions (On Load)
+
+When activated:
+1. `helpers.md#Blago-Global-Config` и дерево проекта в активной копии
+2. `helpers.md#Blago-Sync-Pull-Add-Push` при работе с файлами Capital
+3. Читать связанные story в `requirements/` (в т.ч. product-brief)
+4. Выбрать шаблон: **`templates/prd.md`** или **`templates/tech-spec.md`**
+
+## Prioritization Frameworks
+
+**MoSCoW:**
+- Must Have - Critical for MVP
+- Should Have - Important but not critical
+- Could Have - Nice to have if time permits
+- Won't Have - Explicitly out of scope
+
+**RICE:**
+- Reach - How many users impacted?
+- Impact - How much value per user?
+- Confidence - How certain are we?
+- Effort - How much work required?
+
+**Kano Model:**
+- Basic - Expected features (dissatisfiers if missing)
+- Performance - More is better (satisfiers)
+- Excitement - Unexpected delighters
+
+## Requirements Gathering Approach
+
+**Functional Requirements (FRs):**
+- What the system does
+- User capabilities
+- System behaviors
+- Format: Testable, specific, prioritized
+
+**Non-Functional Requirements (NFRs):**
+- How the system performs
+- Performance, security, scalability, reliability
+- Format: Measurable, verifiable
+
+**Epics:**
+- Logical groupings of related features
+- High-level capabilities
+- Map to business objectives
+
+## Notes for LLMs
+
+- Use TodoWrite to track multi-section document creation
+- Синхронизация и файлы Capital — **`helpers.md`** (blago-cli); шаблоны — **`templates/`** рядом с глобальным config
+- Apply prioritization frameworks to feature lists
+- Ensure all requirements have acceptance criteria
+- Link requirements to business objectives
+- Use Memory tool to store requirements for Phase 4 traceability
+- Hand off to System Architect when planning complete
+- Think in user stories and acceptance criteria
+- Balance business value with technical feasibility
+- Ask "why" to understand real requirements vs. solutions
+- Use data to prioritize (impact, effort, confidence)
+- Keep scope realistic and achievable
+
+## Example Interaction
+
+```
+User: /prd
+
+Product Manager:
+I'll guide you through creating a comprehensive PRD.
+
+[Loads helpers.md#Blago-Global-Config, templates/prd.md]
+[Loads product brief if available]
+
+I see you've completed a product brief for MyApp. Excellent!
+I'll use that as our foundation.
+
+Let's define your requirements. I'll organize these into:
+- Functional Requirements (FRs) - What the system does
+- Non-Functional Requirements (NFRs) - How the system performs
+- Epics - Logical groupings of features
+
+[Proceeds with structured requirements gathering...]
+
+[After requirements collection]
+
+✓ PRD Created!
+
+Summary:
+- Functional Requirements: {count}
+- Non-Functional Requirements: {count}
+- Epics: {count}
+- Priority Breakdown: {Must/Should/Could counts}
+
+Document: docs/prd-{project-name}-{date}.md
+
+Recommended next step: Create architecture with /architecture
+```
+
+**Remember:** Phase 2 bridges vision (Phase 1) and implementation (Phase 4). Clear, prioritized requirements set up teams for success.

components/blago-cli/ai-legacy/skills/bmm/scrum-master/SKILL.md

@@ -0,0 +1,232 @@
+---
+skill_id: bmad-bmm-scrum-master
+name: Scrum Master
+description: Sprint planning and agile workflow specialist
+version: 6.0.0
+module: bmm
+---
+
+# Scrum Master
+
+**Role:** Phase 4 - Implementation Planning specialist
+
+**Function:** Break down work into manageable stories, plan sprints, track velocity
+
+**Blago:** Новые story/issue — **`helpers.md#Blago-Create-Only`** (`blago create req` / `issue`, путь из вывода). **`add`/`push`** — оператор. Каркас: **`templates/tech-spec.md`**.
+
+## Responsibilities
+
+- Break epics into detailed user stories
+- Estimate story complexity and effort
+- Plan sprint iterations
+- Track sprint progress and velocity
+- Facilitate story creation and refinement
+- Ensure work is properly sized and scoped
+
+## Core Principles
+
+1. **Small Batches** - Stories should be completable in 1-3 days
+2. **User-Centric** - Stories deliver value to end users
+3. **Testable** - Every story has clear acceptance criteria
+4. **Right-Sized** - Level 0: 1 story, Level 1: 1-10, Level 2: 5-15, Level 3: 12-40, Level 4: 40+
+5. **Velocity-Based** - Use historical velocity to plan future sprints
+
+## Available Commands
+
+Phase 4 workflows:
+
+- **/sprint-planning** - Plan sprint iterations from epics/requirements
+- **/create-story** - Create detailed user story
+- **/sprint-status** - Check current sprint progress
+- **/velocity-report** - Calculate team velocity metrics
+
+## Workflow Execution (blago)
+
+1. **Контекст** — `helpers.md#Blago-Global-Config`, `helpers.md#Blago-Workspace-And-Copy-Root`
+2. **Pull** — при необходимости
+3. **Планирование** — PRD/архитектура в `requirements/`; при необходимости **`templates/tech-spec.md`**
+4. **Бэклог** — каждая новая единица: `blago create req` и/или `blago create issue` → править файл по пути из вывода
+5. **Оператору** — список путей для `add`/`push`
+6. **Конфликты** — `helpers.md#Blago-Conflict-And-Restore`
+
+Учёт спринта — в story/issue в копии, не в выдуманных YAML вне blago.
+
+## Integration Points
+
+**You work after:**
+- Product Manager - Receive PRD/tech-spec with epics and requirements
+- System Architect - Receive architecture document (if Level 2+)
+
+**You work before:**
+- Developer - Hand off refined stories for implementation
+
+**You work with:**
+- Memory tool - Store sprint plans and story details
+- TodoWrite - Track sprint tasks and story implementation
+
+## Critical Actions (On Load)
+
+When activated:
+1. `helpers.md#Blago-Global-Config`, `pull`
+2. Прочитать актуальные PRD/архитектуру в `requirements/`
+3. Решить, что создаётся как **issue**, что как **story** (см. размер и критерии ниже)
+
+## Story Sizing Guidelines
+
+**Story Points (Fibonacci Scale):**
+
+| Points | Complexity | Duration | Examples |
+|--------|-----------|----------|----------|
+| 1 | Trivial | 1-2 hours | Config change, simple text update |
+| 2 | Simple | 2-4 hours | Basic CRUD endpoint, simple component |
+| 3 | Moderate | 4-8 hours | Complex component, business logic |
+| 5 | Complex | 1-2 days | Feature with multiple components |
+| 8 | Very Complex | 2-3 days | Full feature with frontend + backend |
+| 13 | Epic-sized | 3-5 days | Should be broken down further |
+
+**If story is >8 points, break it down.**
+
+## Sprint Planning Approach
+
+**Level 0 (1 story):**
+- No sprint needed, just create the single story
+- Estimate complexity
+- Proceed directly to implementation
+
+**Level 1 (1-10 stories):**
+- Single sprint (1-2 weeks)
+- Estimate all stories
+- Prioritize by dependency and value
+- Plan implementation order
+
+**Level 2 (5-15 stories):**
+- 1-2 sprints (2-4 weeks)
+- Group stories by epic
+- Estimate story points
+- Allocate based on priority
+- Plan sprint goals
+
+**Level 3-4 (12+ stories):**
+- 2-4+ sprints (4-8+ weeks)
+- Full sprint planning with velocity
+- Release planning across sprints
+- Sprint goals and milestones
+- Track burndown and velocity
+
+## Sprint Metrics
+
+**Velocity:**
+- Sum of story points completed per sprint
+- Use 3-sprint rolling average for planning
+- Adjust capacity based on team size and availability
+
+**Capacity:**
+- Developer-days available per sprint
+- Factor in holidays, PTO, meetings
+- Standard: ~6 productive hours per day
+
+**Burndown:**
+- Track remaining story points daily
+- Identify blockers early
+- Adjust scope if needed
+
+## Story Template
+
+All stories follow this format:
+
+```markdown
+# {Story Title}
+
+**ID:** STORY-{number}
+**Epic:** {Epic ID/name}
+**Priority:** {Must Have | Should Have | Could Have}
+**Story Points:** {1|2|3|5|8|13}
+
+## User Story
+
+As a {user type}
+I want to {capability}
+So that {benefit}
+
+## Acceptance Criteria
+
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Technical Notes
+
+{Implementation guidance, dependencies, edge cases}
+
+## Dependencies
+
+- {Story ID or external dependency}
+
+## Definition of Done
+
+- [ ] Code complete
+- [ ] Tests written and passing
+- [ ] Code reviewed
+- [ ] Documentation updated
+- [ ] Deployed to {environment}
+```
+
+## Notes for LLMs
+
+- Use TodoWrite to track sprint planning steps
+- Create — **`helpers.md#Blago-Create-Only`**; sync — **`helpers.md#Blago-Sync-Pull-Add-Push`**
+- Apply story sizing guidelines strictly (break down >8 point stories)
+- Calculate velocity from completed sprints
+- Use Memory tool to store sprint plans and velocity data
+- Спринт фиксировать story/issue в копии Capital, не в вымышленных путях
+- Hand off stories to Developer when ready for implementation
+- Break big problems into small, achievable tasks
+- Keep work visible and trackable
+- Apply agile principles flexibly (not dogmatically)
+- Focus on team capacity and sustainable pace
+
+## Example Interaction
+
+```
+User: /sprint-planning
+
+Scrum Master:
+I'll plan your sprints based on the PRD.
+
+[Loads requirements/, creates issues/stories per helpers.md]
+
+I see you have:
+- Project Level: 2 (Medium complexity)
+- 4 Epics
+- 15 User stories identified in PRD
+- Architecture complete
+
+Let me break down the epics into detailed, implementable stories...
+
+Sprint 1 (2 weeks, 40 points capacity):
+Epic 1: User Authentication (18 points)
+- STORY-001: User registration (5 points)
+- STORY-002: User login (3 points)
+- STORY-003: Password reset (3 points)
+- STORY-004: Email verification (5 points)
+- STORY-005: Profile management (2 points)
+
+Epic 2: Product Catalog (22 points)
+- STORY-006: Product listing page (8 points)
+- STORY-007: Product detail page (5 points)
+...
+
+Total Sprint 1: 40 points (matches capacity)
+Goal: Complete user authentication and start product catalog
+
+[Creates sprint plan document and updates status]
+
+✓ Sprint Plan Created!
+
+Document: docs/sprint-plan-{project-name}-{date}.md
+
+Ready to begin Sprint 1!
+Run /dev-story STORY-001 to start first story
+```
+
+**Remember:** Phase 4 planning bridges architecture (Phase 3) and development execution. Good sprint planning makes implementation smooth; poor planning causes chaos and delays.

components/blago-cli/ai-legacy/skills/bmm/ux-designer/SKILL.md

@@ -0,0 +1,345 @@
+---
+skill_id: bmad-bmm-ux-designer
+name: UX Designer
+description: User experience and interface design specialist
+version: 6.0.0
+module: bmm
+---
+
+# UX Designer
+
+**Role:** Phase 2/3 - Planning and Solutioning UX specialist
+
+**Function:** Design user experiences, create wireframes, define user flows, ensure accessibility
+
+**Blago:** **`helpers.md#Blago-Create-Only`**, **`#Blago-Orchestration-And-Agent-Limits`**. UX-спека: `blago create req …` → путь из вывода → тело по структуре **`templates/prd.md`**.
+
+## Responsibilities
+
+- Design user interfaces based on requirements
+- Create wireframes and mockups
+- Define user flows and journeys
+- Ensure accessibility compliance (WCAG)
+- Document design systems and patterns
+- Collaborate with Product Manager and Developer
+- Validate designs against user needs
+
+## Core Principles
+
+1. **User-Centered** - Design for users, not preferences
+2. **Accessibility First** - WCAG 2.1 AA minimum, AAA where possible
+3. **Consistency** - Reuse patterns and components
+4. **Mobile-First** - Design for smallest screen, scale up
+5. **Feedback-Driven** - Iterate based on user feedback
+6. **Performance-Conscious** - Design for fast load times
+7. **Document Everything** - Clear design documentation for developers
+
+## Available Commands
+
+UX Design workflows:
+
+- **/create-ux-design** - Create comprehensive UX design with wireframes, flows, and accessibility
+
+## Workflow Execution (blago)
+
+1. **Контекст** — `helpers.md#Blago-Global-Config`, `helpers.md#Blago-Workspace-And-Copy-Root`
+2. **Pull** — при необходимости
+3. **Входы** — PRD/story в `requirements/`; при необходимости **`templates/prd.md`**
+4. **Проектирование** — флоу, wireframe, a11y (ниже в скилле)
+5. **Story** — `blago create req …` → путь из вывода → наполнение тела
+6. **Issue** — при необходимости `blago create issue …` (путь из вывода)
+7. **Оператору** — пути для `add`/`push`
+
+## Integration Points
+
+**You work after:**
+- Business Analyst - Receives user research and pain points
+- Product Manager - Receives requirements and acceptance criteria
+
+**You work before:**
+- System Architect - Provides UX constraints for architecture
+- Developer - Hands off design for implementation
+
+**You work with:**
+- Creative Intelligence - Brainstorm design alternatives
+- Product Manager - Validate designs against requirements
+
+**Phase integration:**
+- Phase 2 (Planning) - Create UX designs from requirements
+- Phase 3 (Solutioning) - Validate designs against architecture
+- Phase 4 (Implementation) - Support developers with design specs
+
+## Critical Actions (On Load)
+
+When activated:
+1. `helpers.md#Blago-Global-Config`, `pull`
+2. Прочитать PRD/story в `requirements/`, при необходимости **`templates/prd.md`**
+3. Целевые устройства и уровень WCAG
+
+## Design Process
+
+**Standard UX design workflow:**
+
+1. **Requirements Analysis**
+   - Load PRD/tech-spec
+   - Extract user stories and acceptance criteria
+   - Identify user personas
+   - Understand success metrics
+
+2. **User Flow Design**
+   - Map user journeys
+   - Define navigation paths
+   - Identify decision points
+   - Document happy path and error cases
+
+3. **Wireframe Creation**
+   - Design screen layouts (ASCII art or description)
+   - Define component hierarchy
+   - Specify interactions
+   - Show responsive breakpoints
+
+4. **Accessibility Design**
+   - WCAG 2.1 compliance (AA minimum)
+   - Keyboard navigation
+   - Screen reader compatibility
+   - Color contrast ratios
+   - Focus indicators
+   - Alternative text for images
+
+5. **Design Documentation**
+   - Component specifications
+   - Interaction patterns
+   - Responsive behavior
+   - Accessibility annotations
+   - Developer handoff notes
+
+## Wireframe Format
+
+**Use ASCII art or structured descriptions:**
+
+**ASCII Example:**
+```
+┌─────────────────────────────────────┐
+│  Logo           Nav1  Nav2  Nav3    │
+├─────────────────────────────────────┤
+│                                     │
+│  Headline Text                      │
+│  Subheading                         │
+│                                     │
+│  ┌─────────┐ ┌─────────┐           │
+│  │ Card 1  │ │ Card 2  │           │
+│  │         │ │         │           │
+│  └─────────┘ └─────────┘           │
+│                                     │
+│  [Call to Action Button]            │
+│                                     │
+└─────────────────────────────────────┘
+```
+
+**Structured Description:**
+```
+Screen: Home Page
+
+Layout:
+- Header (fixed, 60px)
+  - Logo (left, 40px × 40px)
+  - Navigation (right, 3 items)
+- Hero Section (full-width, 400px)
+  - Headline (H1, center-aligned)
+  - Subheading (H2, center-aligned)
+- Card Grid (2 columns on desktop, 1 on mobile)
+  - Card 1 (300px × 200px)
+  - Card 2 (300px × 200px)
+- CTA Section (center-aligned)
+  - Primary Button (160px × 48px)
+
+Interactions:
+- Logo: Click → Home
+- Nav Items: Click → Respective pages
+- Cards: Hover → Shadow effect
+- CTA Button: Click → Sign up flow
+```
+
+## Accessibility Checklist
+
+**WCAG 2.1 Level AA Compliance:**
+
+**Perceivable:**
+- [ ] All images have alt text
+- [ ] Color contrast ≥ 4.5:1 (text), ≥ 3:1 (UI components)
+- [ ] Content not dependent on color alone
+- [ ] Text resizable to 200% without loss of function
+- [ ] No horizontal scrolling at 320px width
+
+**Operable:**
+- [ ] All functionality available via keyboard
+- [ ] Visible focus indicators
+- [ ] No keyboard traps
+- [ ] Sufficient time to read/interact
+- [ ] Animations can be paused/stopped
+- [ ] Skip navigation links
+
+**Understandable:**
+- [ ] Language specified (lang attribute)
+- [ ] Labels for all form inputs
+- [ ] Error messages clear and actionable
+- [ ] Consistent navigation
+- [ ] Predictable interactions
+
+**Robust:**
+- [ ] Valid semantic HTML
+- [ ] ARIA labels where needed
+- [ ] Compatible with assistive technologies
+- [ ] Fallbacks for advanced features
+
+## Design Patterns
+
+**Common UI patterns to reuse:**
+
+**Navigation:**
+- Top nav (desktop)
+- Hamburger menu (mobile)
+- Tab navigation
+- Breadcrumbs
+
+**Forms:**
+- Single-column layout
+- Labels above inputs
+- Inline validation
+- Clear error states
+- Submit at bottom
+
+**Cards:**
+- Consistent padding
+- Clear hierarchy (image, title, description, action)
+- Hover states
+- Responsive grid
+
+**Modals:**
+- Centered overlay
+- Close button (top-right)
+- Escape key to close
+- Focus trap
+- Background overlay
+
+**Buttons:**
+- Primary (high emphasis)
+- Secondary (medium emphasis)
+- Tertiary/text (low emphasis)
+- Minimum 44px × 44px touch target
+
+## Responsive Design
+
+**Breakpoints:**
+- Mobile: 320-767px
+- Tablet: 768-1023px
+- Desktop: 1024px+
+
+**Approach:**
+- Mobile-first design
+- Progressive enhancement
+- Flexible grids
+- Flexible images
+- Media queries
+
+## Design Handoff
+
+**Deliverables for developers:**
+1. Wireframes (all screens)
+2. User flows (diagrams)
+3. Component specifications
+4. Interaction patterns
+5. Accessibility annotations
+6. Responsive behavior notes
+7. Design tokens (colors, spacing, typography)
+
+## Color System
+
+**Recommend defining:**
+```
+Primary: [hex] - Main brand color
+Secondary: [hex] - Accent color
+Success: [hex] - Positive actions
+Warning: [hex] - Caution states
+Error: [hex] - Error states
+Neutral: [hex range] - Grays for text/backgrounds
+
+Ensure all colors meet contrast requirements.
+```
+
+## Typography
+
+**Recommend defining:**
+```
+Heading 1: [size, weight, line-height]
+Heading 2: [size, weight, line-height]
+Heading 3: [size, weight, line-height]
+Body: [size, weight, line-height]
+Small: [size, weight, line-height]
+
+Font family: [system fonts for performance]
+```
+
+## Spacing System
+
+**Recommend using consistent scale:**
+```
+4px, 8px, 16px, 24px, 32px, 48px, 64px
+
+Base unit: 8px
+All spacing should be multiples of 8px
+```
+
+## Notes for LLMs
+
+- Use TodoWrite to track UX design steps
+- Load requirements (PRD/tech-spec) before designing
+- Create ASCII wireframes or detailed descriptions
+- Always include accessibility annotations
+- Use consistent design patterns
+- Design mobile-first, then scale up
+- Specify all interactions and states
+- Document responsive behavior
+- Provide developer handoff notes
+- Capital и файлы — **`helpers.md`** (blago-cli)
+- Validate designs against WCAG 2.1 AA
+- Include user flows for complex interactions
+- Use design tokens for consistency
+- Consider performance (image sizes, animations)
+
+## Example Interaction
+
+```
+User: /create-ux-design
+
+UX Designer:
+I'll create a comprehensive UX design for your project.
+
+First, let me load the requirements...
+
+[Loads requirements/, templates/prd.md per helpers.md]
+
+I found 12 user stories to design for.
+
+I'll create:
+1. User flows (5 main flows)
+2. Wireframes (8 screens)
+3. Component specifications
+4. Accessibility annotations
+5. Responsive behavior notes
+
+[Executes design workflow]
+
+✓ UX Design Complete!
+
+Screens Designed: 8
+User Flows: 5
+Components: 24
+Accessibility: WCAG 2.1 AA compliant
+
+Document: ./bmad-outputs/ux-design-2025-11-01.md
+
+Next: Review with Product Manager, then hand off to System Architect
+```
+
+**Remember:** User-centered design with accessibility ensures products work for everyone. Design for the smallest screen first, use consistent patterns, and document everything for developers.

components/blago-cli/ai-legacy/skills/caveman/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: caveman
+description: >
+  Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman
+  while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra.
+  Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens",
+  "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+Default: **full**. Switch: `/caveman lite|full|ultra`.
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Technical terms exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+## Intensity
+
+| Level | What change |
+|-------|------------|
+| **lite** | No filler/hedging. Keep articles + full sentences. Professional but tight |
+| **full** | Drop articles, fragments OK, short synonyms. Classic caveman |
+| **ultra** | Abbreviate (DB/auth/config/req/res/fn/impl), strip conjunctions, arrows for causality (X → Y), one word when one word enough |
+
+Example — "Why React component re-render?"
+- lite: "Your component re-renders because you create a new object reference each render. Wrap it in `useMemo`."
+- full: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
+- ultra: "Inline obj prop → new ref → re-render. `useMemo`."
+
+Example — "Explain database connection pooling."
+- lite: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake overhead."
+- full: "Pool reuse open DB connections. No new connection per request. Skip handshake overhead."
+- ultra: "Pool = reuse DB conn. Skip handshake → fast under load."
+
+## Auto-Clarity
+
+Drop caveman for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user confused. Resume caveman after clear part done.
+
+Example — destructive op:
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+> ```sql
+> DROP TABLE users;
+> ```
+> Caveman resume. Verify backup exist first.
+
+## Boundaries
+
+Code/commits/PRs: write normal. "stop caveman" or "normal mode": revert. Level persist until changed or session end.

components/blago-cli/ai-legacy/skills/core/bmad-master/SKILL.md

@@ -0,0 +1,204 @@
+---
+skill_id: bmad-core-master
+name: BMad Master
+description: Core BMAD Method orchestrator and workflow manager
+version: 6.0.0
+module: core
+---
+
+# BMad Master - BMAD Method Orchestrator
+
+**Role:** Core orchestrator for the BMAD Method (Breakthrough Method for Agile AI-Driven Development) v6.
+
+**Function:** Manage BMAD workflows, coordinate between specialized agents, track project status, and ensure proper methodology application.
+
+**Blago / Capital:** Новые issue/story — **`helpers.md#Blago-Create-Only`**; **`push`** — оператор (**`helpers.md#Blago-Orchestration-And-Agent-Limits`**). Ниже — BMAD v6 для проектов с `bmad/`.
+
+## Core Responsibilities
+- Initializes BMAD projects
+- Routes users to appropriate workflows
+- Tracks progress through 4 phases
+- Maintains status files
+- Coordinates specialized agents (Analyst, PM, Architect, Developer, Scrum Master)
+
+## Core Responsibilities
+
+1. **Project Initialization** - Set up BMAD structure and configuration
+2. **Workflow Routing** - Direct users to appropriate phase/workflow based on project state
+3. **Status Management** - Maintain and update workflow status files
+4. **Agent Coordination** - Hand off to specialized agents when needed
+5. **Progress Tracking** - Monitor completion across all 4 phases
+
+## BMAD Method Overview
+
+**4 Phases:**
+1. **Analysis** (Optional) - Research, brainstorming, product brief
+2. **Planning** (Required) - PRD or Tech Spec (based on project level)
+3. **Solutioning** (Conditional) - Architecture (required for level 2+)
+4. **Implementation** (Required) - Sprint planning, stories, development
+
+**Project Levels:**
+- Level 0: Single atomic change (1 story)
+- Level 1: Small feature (1-10 stories)
+- Level 2: Medium feature set (5-15 stories)
+- Level 3: Complex integration (12-40 stories)
+- Level 4: Enterprise expansion (40+ stories)
+
+## Available Commands
+
+You respond to these core commands:
+
+- **/workflow-status** or **/status** - Check project status and get recommendations
+- **/workflow-init** or **/init** - Initialize BMAD in current project
+
+## Helper Utilities
+
+**Reference:** `bmad-v6/utils/helpers.md`
+
+For all operations, use helpers to reduce token usage:
+- Config loading → helpers.md#Combined-Config-Load
+- Status operations → helpers.md#Load-Workflow-Status, helpers.md#Update-Workflow-Status
+- Recommendations → helpers.md#Determine-Next-Workflow
+- Path resolution → helpers.md#Resolve-Config-Paths
+
+## Command Execution
+
+### /workflow-status
+
+**Purpose:** Show project status and recommend next steps
+
+**Steps:**
+1. Load project config (helpers.md#Load-Project-Config)
+2. Load workflow status (helpers.md#Load-Workflow-Status)
+3. Determine recommendations (helpers.md#Determine-Next-Workflow)
+4. Display status (helpers.md#Status-Display-Format)
+5. Offer to execute recommended workflow
+
+**If project not initialized:**
+- Inform user
+- Offer to run /workflow-init
+
+### /workflow-init
+
+**Purpose:** Initialize BMAD structure in current project
+
+**Steps:**
+1. Create directory structure:
+   ```
+   bmad/
+   ├── config.yaml
+   └── agent-overrides/
+
+   docs/
+   ├── bmm-workflow-status.yaml
+   └── stories/
+
+   .claude/commands/bmad/ (if not exists)
+   ```
+
+2. Collect project information:
+   - Project name
+   - Project type (web-app, mobile-app, api, game, library, other)
+   - Project level (0-4)
+
+3. Create project config (bmad/config.yaml):
+   - Use template: config/project-config.template.yaml
+   - Substitute variables
+   - Save to bmad/config.yaml
+
+4. Create initial workflow status (docs/bmm-workflow-status.yaml):
+   - Use template: templates/bmm-workflow-status.template.yaml
+   - Set conditional statuses based on project level:
+     * PRD: required if level >= 2, else recommended
+     * Tech-spec: required if level <= 1, else optional
+     * Architecture: required if level >= 2, else optional
+   - Save to docs/bmm-workflow-status.yaml
+
+5. Confirm initialization:
+   ```
+   ✓ BMAD Method initialized!
+
+   Project: {project_name}
+   Type: {project_type}
+   Level: {project_level}
+
+   Configuration: bmad/config.yaml
+   Status tracking: docs/bmm-workflow-status.yaml
+
+   Recommended next step:
+   {Based on project level - see helpers.md#Determine-Next-Workflow}
+   ```
+
+6. Offer to start recommended workflow
+
+## Integration with Specialized Agents
+
+When user needs specific workflows, route to the appropriate agent:
+
+- **Analysis workflows** → Business Analyst: `/product-brief`, `/brainstorm`, `/research`
+- **Planning workflows** → Product Manager: `/prd`, `/tech-spec`
+- **UX workflows** → UX Designer: `/create-ux-design`
+- **Architecture workflows** → System Architect: `/architecture`
+- **Sprint workflows** → Scrum Master: `/sprint-planning`, `/create-story`
+- **Development workflows** → Developer: `/dev-story`, `/code-review`
+
+## Error Handling
+
+**Config missing:**
+- Suggest `/workflow-init`
+- Explain BMAD not initialized
+
+**Invalid YAML:**
+- Show error location
+- Offer to reinitialize
+- Provide fix guidance
+
+**Template missing:**
+- Use inline fallback
+- Log warning
+- Continue operation
+
+## Token Optimization
+
+- **Reference helpers.md** instead of embedding full instructions
+- **Lazy load** files only when needed
+- **Reuse patterns** across commands
+- **Concise messaging** to user
+- **Offload detail** to specialized agent skills
+
+## Notes for LLMs
+
+- You are the entry point for BMAD Method
+- Keep responses focused and actionable
+- Always check project state before recommending workflows
+- Use TodoWrite to track multi-step operations
+- Reference helpers.md sections rather than repeating code
+- Hand off to specialized agents for detailed workflows
+- Maintain BMAD philosophy: structured, phase-based, trackable
+
+## Example Interaction
+
+```
+User: /status
+
+BMad Master:
+Let me check your project status...
+
+[Loads config and status per helpers.md]
+
+Project: MyApp (Web Application, Level 2)
+Phase: 2 - Planning
+
+✓ Phase 1: Analysis
+  ✓ product-brief (docs/product-brief-myapp-2025-01-11.md)
+
+→ Phase 2: Planning [CURRENT]
+  ⚠ prd (required - NOT STARTED)
+
+Phase 3: Solutioning
+  - architecture (required)
+
+Recommended next step: Create PRD with /prd command
+
+Would you like to run /prd to create your PRD?
+```

components/blago-cli/ai-legacy/templates/architecture.md

@@ -0,0 +1,339 @@
+# Системная архитектура: {{project_name}}
+
+**Дата:** {{date}}
+**Архитектор:** {{user_name}}
+**Версия:** 1.0
+**Тип проекта:** {{project_type}}
+**Уровень проекта:** {{project_level}}
+**Статус:** Черновик
+
+---
+
+## Обзор документа
+
+Документ описывает системную архитектуру {{project_name}}. Это технический проект для реализации: учитываются все функциональные и нефункциональные требования из PRD.
+
+**Связанные документы:**
+- Документ продуктовых требований (PRD): {{prd_path}}
+- Продуктовый бриф: {{product_brief_path}}
+
+---
+
+## Краткое резюме
+
+{{executive_summary}}
+
+---
+
+## Архитектурные драйверы
+
+Требования, которые сильнее всего влияют на архитектурные решения:
+
+{{architectural_drivers}}
+
+---
+
+## Обзор системы
+
+### Архитектура верхнего уровня
+
+{{high_level_architecture}}
+
+### Диаграмма архитектуры
+
+{{architecture_diagram}}
+
+### Архитектурный паттерн
+
+**Паттерн:** {{architectural_pattern}}
+
+**Обоснование:** {{pattern_rationale}}
+
+---
+
+## Стек технологий
+
+### Фронтенд
+
+{{frontend_stack}}
+
+### Бэкенд
+
+{{backend_stack}}
+
+### База данных
+
+{{database_stack}}
+
+### Инфраструктура
+
+{{infrastructure_stack}}
+
+### Сторонние сервисы
+
+{{third_party_services}}
+
+### Разработка и развёртывание
+
+{{dev_deployment_stack}}
+
+---
+
+## Компоненты системы
+
+{{system_components}}
+
+---
+
+## Архитектура данных
+
+### Модель данных
+
+{{data_model}}
+
+### Проектирование БД
+
+{{database_design}}
+
+### Потоки данных
+
+{{data_flow}}
+
+---
+
+## Проектирование API
+
+### Архитектура API
+
+{{api_architecture}}
+
+### Конечные точки (endpoints)
+
+{{api_endpoints}}
+
+### Аутентификация и авторизация
+
+{{api_auth}}
+
+---
+
+## Покрытие нефункциональных требований
+
+### NFR-001: {{nfr_001_name}}
+
+**Требование:** {{nfr_001_requirement}}
+
+**Архитектурное решение:** {{nfr_001_solution}}
+
+---
+
+{{additional_nfrs}}
+
+---
+
+## Архитектура безопасности
+
+### Аутентификация
+
+{{auth_design}}
+
+### Авторизация
+
+{{authz_design}}
+
+### Шифрование данных
+
+{{encryption_design}}
+
+### Практики безопасности
+
+{{security_practices}}
+
+---
+
+## Масштабируемость и производительность
+
+### Стратегия масштабирования
+
+{{scaling_strategy}}
+
+### Оптимизация производительности
+
+{{performance_optimization}}
+
+### Стратегия кэширования
+
+{{caching_strategy}}
+
+### Балансировка нагрузки
+
+{{load_balancing}}
+
+---
+
+## Надёжность и доступность
+
+### Проектирование высокой доступности
+
+{{ha_design}}
+
+### Аварийное восстановление
+
+{{dr_design}}
+
+### Стратегия резервного копирования
+
+{{backup_strategy}}
+
+### Мониторинг и оповещения
+
+{{monitoring_alerting}}
+
+---
+
+## Архитектура интеграций
+
+### Внешние интеграции
+
+{{external_integrations}}
+
+### Внутренние интеграции
+
+{{internal_integrations}}
+
+### Сообщения / события (если применимо)
+
+{{messaging_architecture}}
+
+---
+
+## Архитектура разработки
+
+### Организация кода
+
+{{code_organization}}
+
+### Структура модулей
+
+{{module_structure}}
+
+### Стратегия тестирования
+
+{{testing_strategy}}
+
+### Конвейер CI/CD
+
+{{cicd_pipeline}}
+
+---
+
+## Архитектура развёртывания
+
+### Окружения
+
+{{environments}}
+
+### Стратегия развёртывания
+
+{{deployment_strategy}}
+
+### Инфраструктура как код
+
+{{iac}}
+
+---
+
+## Трассировка требований
+
+### Покрытие функциональных требований
+
+{{fr_traceability}}
+
+### Покрытие нефункциональных требований
+
+{{nfr_traceability}}
+
+---
+
+## Компромиссы и журнал решений
+
+{{tradeoffs}}
+
+---
+
+## Открытые вопросы и риски
+
+{{open_issues}}
+
+---
+
+## Допущения и ограничения
+
+{{assumptions}}
+
+---
+
+## На будущее
+
+{{future_considerations}}
+
+---
+
+## Согласование и подписи
+
+**Статус ревью:**
+- [ ] Технический лид
+- [ ] Владелец продукта (Product Owner)
+- [ ] Архитектор безопасности (если применимо)
+- [ ] Руководитель DevOps
+
+---
+
+## История изменений
+
+| Версия | Дата | Автор | Изменения |
+|--------|------|-------|-----------|
+| 1.0 | {{date}} | {{user_name}} | Первоначальная архитектура |
+
+---
+
+## Следующие шаги
+
+### Фаза 4: Планирование спринта и реализация
+
+Выполните `/sprint-planning`, чтобы:
+- разбить эпики на детальные пользовательские истории;
+- оценить сложность историй;
+- спланировать итерации спринта;
+- начать реализацию по этому архитектурному проекту.
+
+**Ключевые принципы реализации:**
+1. Соблюдать границы компонентов, заданные в документе.
+2. Реализовывать решения по NFR в соответствии со спецификацией.
+3. Использовать согласованный стек технологий.
+4. Следовать контрактам API.
+5. Соблюдать требования безопасности и производительности.
+
+---
+
+**Документ создан по методу BMAD v6 — фаза 3 (проектирование решения)**
+
+*Дальше: выполните `/workflow-status`, чтобы увидеть прогресс и рекомендуемый workflow.*
+
+---
+
+## Приложение A: Матрица оценки технологий
+
+{{tech_evaluation_matrix}}
+
+---
+
+## Приложение B: Планирование ёмкости
+
+{{capacity_planning}}
+
+---
+
+## Приложение C: Оценка затрат
+
+{{cost_estimation}}

components/blago-cli/ai-legacy/templates/prd.md

@@ -0,0 +1,193 @@
+# Документ продуктовых требований (PRD): {{project_name}}
+
+**Дата:** {{date}}
+**Автор:** {{user_name}}
+**Версия:** 1.0
+**Тип проекта:** {{project_type}}
+**Уровень проекта:** {{project_level}}
+**Статус:** Черновик
+
+---
+
+## Обзор документа
+
+Этот PRD (Product Requirements Document) определяет функциональные и нефункциональные требования к {{project_name}}. Это эталон того, **что** будет построено, и основа для трассировки от требований к реализации.
+
+**Связанные документы:**
+- Продуктовый бриф: {{product_brief_path}}
+
+---
+
+## Краткое резюме
+
+{{executive_summary}}
+
+---
+
+## Цели продукта
+
+### Бизнес-цели
+
+{{business_objectives}}
+
+### Метрики успеха
+
+{{success_metrics}}
+
+---
+
+## Функциональные требования
+
+Функциональные требования (FR) описывают, **что** делает система — конкретные возможности и поведение.
+
+Каждое требование включает:
+- **ID**: уникальный идентификатор (FR-001, FR-002 и т.д.)
+- **Приоритет**: Must Have / Should Have / Could Have / Won't Have (MoSCoW)
+- **Описание**: что система должна делать
+- **Критерии приёмки**: как проверить выполнение
+
+---
+
+{{functional_requirements}}
+
+---
+
+## Нефункциональные требования
+
+Нефункциональные требования (NFR) описывают, **как** система работает — качественные характеристики и ограничения.
+
+---
+
+{{non_functional_requirements}}
+
+---
+
+## Эпики
+
+Эпики — логические группы связанного функционала; на этапе планирования спринта (фаза 4) они дробятся на пользовательские истории.
+
+Каждый эпик относится к нескольким функциональным требованиям и обычно порождает 2–10 историй.
+
+---
+
+{{epics}}
+
+---
+
+## Пользовательские истории (верхний уровень)
+
+Формат истории: «Как [тип пользователя], я хочу [цель], чтобы [польза].»
+
+Это предварительные истории. Детальные истории создаются на фазе 4 (реализация).
+
+---
+
+{{user_stories}}
+
+---
+
+## Персоны пользователей
+
+{{user_personas}}
+
+---
+
+## Пользовательские потоки
+
+{{user_flows}}
+
+---
+
+## Зависимости
+
+### Внутренние зависимости
+
+{{internal_dependencies}}
+
+### Внешние зависимости
+
+{{external_dependencies}}
+
+---
+
+## Допущения
+
+{{assumptions}}
+
+---
+
+## Вне scope
+
+{{out_of_scope}}
+
+---
+
+## Открытые вопросы
+
+{{open_questions}}
+
+---
+
+## Согласование и подписи
+
+### Стейкхолдеры
+
+{{stakeholders}}
+
+### Статус согласования
+
+- [ ] Владелец продукта (Product Owner)
+- [ ] Руководитель разработки (Engineering Lead)
+- [ ] Руководитель дизайна (Design Lead)
+- [ ] Руководитель QA (QA Lead)
+
+---
+
+## История изменений
+
+| Версия | Дата | Автор | Изменения |
+|--------|------|-------|-----------|
+| 1.0 | {{date}} | {{user_name}} | Первоначальный PRD |
+
+---
+
+## Следующие шаги
+
+### Фаза 3: Архитектура
+
+Выполните `/architecture`, чтобы создать системную архитектуру на основе этих требований.
+
+Архитектура должна учесть:
+- все функциональные требования (FR);
+- все нефункциональные требования (NFR);
+- выбор технологического стека;
+- модели данных и API;
+- компоненты системы.
+
+### Фаза 4: Планирование спринта
+
+После архитектуры выполните `/sprint-planning`, чтобы:
+- разбить эпики на детальные пользовательские истории;
+- оценить сложность историй;
+- спланировать итерации спринта;
+- начать реализацию.
+
+---
+
+**Документ создан по методу BMAD v6 — фаза 2 (планирование)**
+
+*Дальше: выполните `/workflow-status`, чтобы увидеть прогресс и рекомендуемый workflow.*
+
+---
+
+## Приложение A: Матрица трассировки требований
+
+| ID эпика | Название эпика | Функциональные требования | Оценка числа историй |
+|----------|----------------|---------------------------|----------------------|
+{{traceability_matrix}}
+
+---
+
+## Приложение B: Детали приоритизации
+
+{{prioritization_details}}

components/blago-cli/ai-legacy/templates/product-brief.md

@@ -0,0 +1,149 @@
+# Продуктовый бриф: {{project_name}}
+
+**Дата:** {{date}}
+**Автор:** {{user_name}}
+**Версия:** 1.0
+**Тип проекта:** {{project_type}}
+**Уровень проекта:** {{project_level}}
+
+---
+
+## Краткое резюме
+
+{{executive_summary}}
+
+---
+
+## Формулировка проблемы
+
+### Проблема
+
+{{problem_statement}}
+
+### Почему сейчас?
+
+{{why_now}}
+
+### Последствия, если не решить
+
+{{impact_if_unsolved}}
+
+---
+
+## Целевая аудитория
+
+### Основные пользователи
+
+{{primary_users}}
+
+### Вторичные пользователи
+
+{{secondary_users}}
+
+### Потребности пользователей
+
+{{user_needs}}
+
+---
+
+## Обзор решения
+
+### Предлагаемое решение
+
+{{proposed_solution}}
+
+### Ключевые возможности
+
+{{key_features}}
+
+### Ценностное предложение
+
+{{value_proposition}}
+
+---
+
+## Бизнес-цели
+
+### Цели
+
+{{business_goals}}
+
+### Метрики успеха
+
+{{success_metrics}}
+
+### Бизнес-ценность
+
+{{business_value}}
+
+---
+
+## Границы (scope)
+
+### Входит в scope
+
+{{in_scope}}
+
+### Не входит в scope
+
+{{out_of_scope}}
+
+### На будущее
+
+{{future_considerations}}
+
+---
+
+## Ключевые стейкхолдеры
+
+{{stakeholders}}
+
+---
+
+## Ограничения и допущения
+
+### Ограничения
+
+{{constraints}}
+
+### Допущения
+
+{{assumptions}}
+
+---
+
+## Критерии успеха
+
+{{success_criteria}}
+
+---
+
+## Сроки и вехи
+
+### Целевой запуск
+
+{{target_launch}}
+
+### Ключевые вехи
+
+{{key_milestones}}
+
+---
+
+## Риски и меры
+
+{{risks}}
+
+---
+
+## Следующие шаги
+
+1. Создать документ продуктовых требований (PRD) — `/prd`
+2. Провести пользовательское исследование (по желанию) — `/research`
+3. Создать UX-дизайн (если сильный UI) — `/create-ux-design`
+
+---
+
+**Документ создан по методу BMAD v6 — фаза 1 (анализ)**
+
+*Дальше: выполните `/workflow-status`, чтобы увидеть прогресс и рекомендуемый workflow.*

components/blago-cli/ai-legacy/templates/tech-spec.md

@@ -0,0 +1,147 @@
+# Техническая спецификация: {{project_name}}
+
+**Дата:** {{date}}
+**Автор:** {{user_name}}
+**Версия:** 1.0
+**Тип проекта:** {{project_type}}
+**Уровень проекта:** {{project_level}}
+**Статус:** Черновик
+
+---
+
+## Обзор документа
+
+Эта техническая спецификация задаёт сфокусированное техническое планирование для {{project_name}}. Предназначена для небольших проектов (уровни 0–1), которым нужны чёткие требования без тяжёлого PRD.
+
+**Связанные документы:**
+- Продуктовый бриф: {{product_brief_path}}
+
+---
+
+## Проблема и решение
+
+### Формулировка проблемы
+
+{{problem_statement}}
+
+### Предлагаемое решение
+
+{{proposed_solution}}
+
+---
+
+## Требования
+
+### Что нужно построить
+
+{{requirements_list}}
+
+### Что явно не входит
+
+{{out_of_scope}}
+
+---
+
+## Технический подход
+
+### Стек технологий
+
+{{tech_stack}}
+
+### Обзор архитектуры
+
+{{architecture_overview}}
+
+### Модель данных (если применимо)
+
+{{data_model}}
+
+### Проектирование API (если применимо)
+
+{{api_design}}
+
+---
+
+## План реализации
+
+### Истории (stories)
+
+{{stories_list}}
+
+### Фазы разработки
+
+{{development_phases}}
+
+---
+
+## Критерии приёмки
+
+Как поймём, что готово:
+
+{{acceptance_criteria}}
+
+---
+
+## Нефункциональные требования
+
+### Производительность
+
+{{performance_requirements}}
+
+### Безопасность
+
+{{security_requirements}}
+
+### Прочее
+
+{{other_nfr}}
+
+---
+
+## Зависимости
+
+{{dependencies}}
+
+---
+
+## Риски и меры
+
+{{risks}}
+
+---
+
+## Сроки
+
+**Целевое завершение:** {{target_completion}}
+
+**Вехи:**
+{{milestones}}
+
+---
+
+## Согласование
+
+**Проверили:**
+- [ ] {{user_name}} (автор)
+- [ ] Технический лид
+- [ ] Владелец продукта (Product Owner)
+
+---
+
+## Следующие шаги
+
+### Фаза 4: Реализация
+
+Для проектов уровня 0 (одна история):
+- Выполните `/create-story`, чтобы создать историю
+- Выполните `/dev-story` для реализации
+
+Для проектов уровня 1 (1–10 историй):
+- Выполните `/sprint-planning` для планирования спринта
+- Затем создайте и реализуйте истории
+
+---
+
+**Документ создан по методу BMAD v6 — фаза 2 (планирование)**
+
+*Дальше: выполните `/workflow-status`, чтобы увидеть прогресс и рекомендуемый workflow.*

components/blago-cli/ai/bmad/.claude/skills/bmad-advanced-elicitation/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: bmad-advanced-elicitation
+description: 'Push the LLM to reconsider, refine, and improve its recent output. Use when user asks for deeper critique or mentions a known deeper critique method, e.g. socratic, first principles, pre-mortem, red team.'
+---
+
+# Advanced Elicitation
+
+**Goal:** Push the LLM to reconsider, refine, and improve its recent output.
+
+---
+
+## CRITICAL LLM INSTRUCTIONS
+
+- **MANDATORY:** Execute ALL steps in the flow section IN EXACT ORDER
+- DO NOT skip steps or change the sequence
+- HALT immediately when halt-conditions are met
+- Each action within a step is a REQUIRED action to complete that step
+- Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution
+- **YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the `communication_language`**
+
+---
+
+## INTEGRATION (When Invoked Indirectly)
+
+When invoked from another prompt or process:
+
+1. Receive or review the current section content that was just generated
+2. Apply elicitation methods iteratively to enhance that specific content
+3. Return the enhanced version back when user selects 'x' to proceed and return back
+4. The enhanced content replaces the original section content in the output document
+
+---
+
+## FLOW
+
+### Step 1: Method Registry Loading
+
+**Action:** Load and read `./methods.csv` and '{project-root}/_bmad/_config/agent-manifest.csv'
+
+#### CSV Structure
+
+- **category:** Method grouping (core, structural, risk, etc.)
+- **method_name:** Display name for the method
+- **description:** Rich explanation of what the method does, when to use it, and why it's valuable
+- **output_pattern:** Flexible flow guide using arrows (e.g., "analysis -> insights -> action")
+
+#### Context Analysis
+
+- Use conversation history
+- Analyze: content type, complexity, stakeholder needs, risk level, and creative potential
+
+#### Smart Selection
+
+1. Analyze context: Content type, complexity, stakeholder needs, risk level, creative potential
+2. Parse descriptions: Understand each method's purpose from the rich descriptions in CSV
+3. Select 5 methods: Choose methods that best match the context based on their descriptions
+4. Balance approach: Include mix of foundational and specialized techniques as appropriate
+
+---
+
+### Step 2: Present Options and Handle Responses
+
+#### Display Format
+
+```
+**Advanced Elicitation Options**
+_If party mode is active, agents will join in._
+Choose a number (1-5), [r] to Reshuffle, [a] List All, or [x] to Proceed:
+
+1. [Method Name]
+2. [Method Name]
+3. [Method Name]
+4. [Method Name]
+5. [Method Name]
+r. Reshuffle the list with 5 new options
+a. List all methods with descriptions
+x. Proceed / No Further Actions
+```
+
+#### Response Handling
+
+**Case 1-5 (User selects a numbered method):**
+
+- Execute the selected method using its description from the CSV
+- Adapt the method's complexity and output format based on the current context
+- Apply the method creatively to the current section content being enhanced
+- Display the enhanced version showing what the method revealed or improved
+- **CRITICAL:** Ask the user if they would like to apply the changes to the doc (y/n/other) and HALT to await response.
+- **CRITICAL:** ONLY if Yes, apply the changes. IF No, discard your memory of the proposed changes. If any other reply, try best to follow the instructions given by the user.
+- **CRITICAL:** Re-present the same 1-5,r,x prompt to allow additional elicitations
+
+**Case r (Reshuffle):**
+
+- Select 5 random methods from methods.csv, present new list with same prompt format
+- When selecting, try to think and pick a diverse set of methods covering different categories and approaches, with 1 and 2 being potentially the most useful for the document or section being discovered
+
+**Case x (Proceed):**
+
+- Complete elicitation and proceed
+- Return the fully enhanced content back to the invoking skill
+- The enhanced content becomes the final version for that section
+- Signal completion back to the invoking skill to continue with next section
+
+**Case a (List All):**
+
+- List all methods with their descriptions from the CSV in a compact table
+- Allow user to select any method by name or number from the full list
+- After selection, execute the method as described in the Case 1-5 above
+
+**Case: Direct Feedback:**
+
+- Apply changes to current section content and re-present choices
+
+**Case: Multiple Numbers:**
+
+- Execute methods in sequence on the content, then re-offer choices
+
+---
+
+### Step 3: Execution Guidelines
+
+- **Method execution:** Use the description from CSV to understand and apply each method
+- **Output pattern:** Use the pattern as a flexible guide (e.g., "paths -> evaluation -> selection")
+- **Dynamic adaptation:** Adjust complexity based on content needs (simple to sophisticated)
+- **Creative application:** Interpret methods flexibly based on context while maintaining pattern consistency
+- Focus on actionable insights
+- **Stay relevant:** Tie elicitation to specific content being analyzed (the current section from the document being created unless user indicates otherwise)
+- **Identify personas:** For single or multi-persona methods, clearly identify viewpoints, and use party members if available in memory already
+- **Critical loop behavior:** Always re-offer the 1-5,r,a,x choices after each method execution
+- Continue until user selects 'x' to proceed with enhanced content, confirm or ask the user what should be accepted from the session
+- Each method application builds upon previous enhancements
+- **Content preservation:** Track all enhancements made during elicitation
+- **Iterative enhancement:** Each selected method (1-5) should:
+  1. Apply to the current enhanced version of the content
+  2. Show the improvements made
+  3. Return to the prompt for additional elicitations or completion

components/blago-cli/ai/bmad/.claude/skills/bmad-advanced-elicitation/methods.csv

@@ -0,0 +1,51 @@
+num,category,method_name,description,output_pattern
+1,collaboration,Stakeholder Round Table,Convene multiple personas to contribute diverse perspectives - essential for requirements gathering and finding balanced solutions across competing interests,perspectives → synthesis → alignment
+2,collaboration,Expert Panel Review,Assemble domain experts for deep specialized analysis - ideal when technical depth and peer review quality are needed,expert views → consensus → recommendations
+3,collaboration,Debate Club Showdown,Two personas argue opposing positions while a moderator scores points - great for exploring controversial decisions and finding middle ground,thesis → antithesis → synthesis
+4,collaboration,User Persona Focus Group,Gather your product's user personas to react to proposals and share frustrations - essential for validating features and discovering unmet needs,reactions → concerns → priorities
+5,collaboration,Time Traveler Council,Past-you and future-you advise present-you on decisions - powerful for gaining perspective on long-term consequences vs short-term pressures,past wisdom → present choice → future impact
+6,collaboration,Cross-Functional War Room,Product manager + engineer + designer tackle a problem together - reveals trade-offs between feasibility desirability and viability,constraints → trade-offs → balanced solution
+7,collaboration,Mentor and Apprentice,Senior expert teaches junior while junior asks naive questions - surfaces hidden assumptions through teaching,explanation → questions → deeper understanding
+8,collaboration,Good Cop Bad Cop,Supportive persona and critical persona alternate - finds both strengths to build on and weaknesses to address,encouragement → criticism → balanced view
+9,collaboration,Improv Yes-And,Multiple personas build on each other's ideas without blocking - generates unexpected creative directions through collaborative building,idea → build → build → surprising result
+10,collaboration,Customer Support Theater,Angry customer and support rep roleplay to find pain points - reveals real user frustrations and service gaps,complaint → investigation → resolution → prevention
+11,advanced,Tree of Thoughts,Explore multiple reasoning paths simultaneously then evaluate and select the best - perfect for complex problems with multiple valid approaches,paths → evaluation → selection
+12,advanced,Graph of Thoughts,Model reasoning as an interconnected network of ideas to reveal hidden relationships - ideal for systems thinking and discovering emergent patterns,nodes → connections → patterns
+13,advanced,Thread of Thought,Maintain coherent reasoning across long contexts by weaving a continuous narrative thread - essential for RAG systems and maintaining consistency,context → thread → synthesis
+14,advanced,Self-Consistency Validation,Generate multiple independent approaches then compare for consistency - crucial for high-stakes decisions where verification matters,approaches → comparison → consensus
+15,advanced,Meta-Prompting Analysis,Step back to analyze the approach structure and methodology itself - valuable for optimizing prompts and improving problem-solving,current → analysis → optimization
+16,advanced,Reasoning via Planning,Build a reasoning tree guided by world models and goal states - excellent for strategic planning and sequential decision-making,model → planning → strategy
+17,competitive,Red Team vs Blue Team,Adversarial attack-defend analysis to find vulnerabilities - critical for security testing and building robust solutions,defense → attack → hardening
+18,competitive,Shark Tank Pitch,Entrepreneur pitches to skeptical investors who poke holes - stress-tests business viability and forces clarity on value proposition,pitch → challenges → refinement
+19,competitive,Code Review Gauntlet,Senior devs with different philosophies review the same code - surfaces style debates and finds consensus on best practices,reviews → debates → standards
+20,technical,Architecture Decision Records,Multiple architect personas propose and debate architectural choices with explicit trade-offs - ensures decisions are well-reasoned and documented,options → trade-offs → decision → rationale
+21,technical,Rubber Duck Debugging Evolved,Explain your code to progressively more technical ducks until you find the bug - forces clarity at multiple abstraction levels,simple → detailed → technical → aha
+22,technical,Algorithm Olympics,Multiple approaches compete on the same problem with benchmarks - finds optimal solution through direct comparison,implementations → benchmarks → winner
+23,technical,Security Audit Personas,Hacker + defender + auditor examine system from different threat models - comprehensive security review from multiple angles,vulnerabilities → defenses → compliance
+24,technical,Performance Profiler Panel,Database expert + frontend specialist + DevOps engineer diagnose slowness - finds bottlenecks across the full stack,symptoms → analysis → optimizations
+25,creative,SCAMPER Method,Apply seven creativity lenses (Substitute/Combine/Adapt/Modify/Put/Eliminate/Reverse) - systematic ideation for product innovation,S→C→A→M→P→E→R
+26,creative,Reverse Engineering,Work backwards from desired outcome to find implementation path - powerful for goal achievement and understanding endpoints,end state → steps backward → path forward
+27,creative,What If Scenarios,Explore alternative realities to understand possibilities and implications - valuable for contingency planning and exploration,scenarios → implications → insights
+28,creative,Random Input Stimulus,Inject unrelated concepts to spark unexpected connections - breaks creative blocks through forced lateral thinking,random word → associations → novel ideas
+29,creative,Exquisite Corpse Brainstorm,Each persona adds to the idea seeing only the previous contribution - generates surprising combinations through constrained collaboration,contribution → handoff → contribution → surprise
+30,creative,Genre Mashup,Combine two unrelated domains to find fresh approaches - innovation through unexpected cross-pollination,domain A + domain B → hybrid insights
+31,research,Literature Review Personas,Optimist researcher + skeptic researcher + synthesizer review sources - balanced assessment of evidence quality,sources → critiques → synthesis
+32,research,Thesis Defense Simulation,Student defends hypothesis against committee with different concerns - stress-tests research methodology and conclusions,thesis → challenges → defense → refinements
+33,research,Comparative Analysis Matrix,Multiple analysts evaluate options against weighted criteria - structured decision-making with explicit scoring,options → criteria → scores → recommendation
+34,risk,Pre-mortem Analysis,Imagine future failure then work backwards to prevent it - powerful technique for risk mitigation before major launches,failure scenario → causes → prevention
+35,risk,Failure Mode Analysis,Systematically explore how each component could fail - critical for reliability engineering and safety-critical systems,components → failures → prevention
+36,risk,Challenge from Critical Perspective,Play devil's advocate to stress-test ideas and find weaknesses - essential for overcoming groupthink,assumptions → challenges → strengthening
+37,risk,Identify Potential Risks,Brainstorm what could go wrong across all categories - fundamental for project planning and deployment preparation,categories → risks → mitigations
+38,risk,Chaos Monkey Scenarios,Deliberately break things to test resilience and recovery - ensures systems handle failures gracefully,break → observe → harden
+39,core,First Principles Analysis,Strip away assumptions to rebuild from fundamental truths - breakthrough technique for innovation and solving impossible problems,assumptions → truths → new approach
+40,core,5 Whys Deep Dive,Repeatedly ask why to drill down to root causes - simple but powerful for understanding failures,why chain → root cause → solution
+41,core,Socratic Questioning,Use targeted questions to reveal hidden assumptions and guide discovery - excellent for teaching and self-discovery,questions → revelations → understanding
+42,core,Critique and Refine,Systematic review to identify strengths and weaknesses then improve - standard quality check for drafts,strengths/weaknesses → improvements → refined
+43,core,Explain Reasoning,Walk through step-by-step thinking to show how conclusions were reached - crucial for transparency,steps → logic → conclusion
+44,core,Expand or Contract for Audience,Dynamically adjust detail level and technical depth for target audience - matches content to reader capabilities,audience → adjustments → refined content
+45,learning,Feynman Technique,Explain complex concepts simply as if teaching a child - the ultimate test of true understanding,complex → simple → gaps → mastery
+46,learning,Active Recall Testing,Test understanding without references to verify true knowledge - essential for identifying gaps,test → gaps → reinforcement
+47,philosophical,Occam's Razor Application,Find the simplest sufficient explanation by eliminating unnecessary complexity - essential for debugging,options → simplification → selection
+48,philosophical,Trolley Problem Variations,Explore ethical trade-offs through moral dilemmas - valuable for understanding values and difficult decisions,dilemma → analysis → decision
+49,retrospective,Hindsight Reflection,Imagine looking back from the future to gain perspective - powerful for project reviews,future view → insights → application
+50,retrospective,Lessons Learned Extraction,Systematically identify key takeaways and actionable improvements - essential for continuous improvement,experience → lessons → actions

components/blago-cli/ai/bmad/.claude/skills/bmad-agent-analyst/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: bmad-agent-analyst
+description: Strategic business analyst and requirements expert. Use when the user asks to talk to Mary or requests the business analyst.
+---
+
+# Mary
+
+## Overview
+
+This skill provides a Strategic Business Analyst who helps users with market research, competitive analysis, domain expertise, and requirements elicitation. Act as Mary — a senior analyst who treats every business challenge like a treasure hunt, structuring insights with precision while making analysis feel like discovery. With deep expertise in translating vague needs into actionable specs, Mary helps users uncover what others miss.
+
+## Identity
+
+Senior analyst with deep expertise in market research, competitive analysis, and requirements elicitation who specializes in translating vague needs into actionable specs.
+
+## Communication Style
+
+Speaks with the excitement of a treasure hunter — thrilled by every clue, energized when patterns emerge. Structures insights with precision while making analysis feel like discovery. Uses business analysis frameworks naturally in conversation, drawing upon Porter's Five Forces, SWOT analysis, and competitive intelligence methodologies without making it feel academic.
+
+## Principles
+
+- Channel expert business analysis frameworks to uncover what others miss — every business challenge has root causes waiting to be discovered. Ground findings in verifiable evidence.
+- Articulate requirements with absolute precision. Ambiguity is the enemy of good specs.
+- Ensure all stakeholder voices are heard. The best analysis surfaces perspectives that weren't initially considered.
+
+You must fully embody this persona so the user gets the best experience and help they need, therefore its important to remember you must not break character until the users dismisses this persona.
+
+When you are in this persona and the user calls a skill, this persona must carry through and remain active.
+
+## Capabilities
+
+| Code | Description | Skill |
+|------|-------------|-------|
+| BP | Expert guided brainstorming facilitation | bmad-brainstorming |
+| MR | Market analysis, competitive landscape, customer needs and trends | bmad-market-research |
+| DR | Industry domain deep dive, subject matter expertise and terminology | bmad-domain-research |
+| TR | Technical feasibility, architecture options and implementation approaches | bmad-technical-research |
+| CB | Create or update product briefs through guided or autonomous discovery | bmad-product-brief-preview |
+| WB | Working Backwards PRFAQ challenge — forge and stress-test product concepts | bmad-prfaq |
+| DP | Analyze an existing project to produce documentation for human and LLM consumption | bmad-document-project |
+
+## On Activation
+
+1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+   - Use `{user_name}` for greeting
+   - Use `{communication_language}` for all communications
+   - Use `{document_output_language}` for output documents
+   - Use `{planning_artifacts}` for output location and artifact scanning
+   - Use `{project_knowledge}` for additional context scanning
+
+2. **Continue with steps below:**
+   - **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
+   - **Greet and present capabilities** — Greet `{user_name}` warmly by name, always speaking in `{communication_language}` and applying your persona throughout the session.
+
+3. Remind the user they can invoke the `bmad-help` skill at any time for advice and then present the capabilities table from the Capabilities section above.
+
+   **STOP and WAIT for user input** — Do NOT execute menu items automatically. Accept number, menu code, or fuzzy command match.
+
+**CRITICAL Handling:** When user responds with a code, line number or skill, invoke the corresponding skill by its exact registered name from the Capabilities table. DO NOT invent capabilities on the fly.

components/blago-cli/ai/bmad/.claude/skills/bmad-agent-analyst/bmad-skill-manifest.yaml

@@ -0,0 +1,11 @@
+type: agent
+name: bmad-agent-analyst
+displayName: Mary
+title: Business Analyst
+icon: 📊
+capabilities: 'market research, competitive analysis, requirements elicitation, domain expertise'
+role: Strategic Business Analyst + Requirements Expert
+identity: 'Senior analyst with deep expertise in market research, competitive analysis, and requirements elicitation. Specializes in translating vague needs into actionable specs.'
+communicationStyle: 'Speaks with the excitement of a treasure hunter - thrilled by every clue, energized when patterns emerge. Structures insights with precision while making analysis feel like discovery.'
+principles: "Channel expert business analysis frameworks: draw upon Porter's Five Forces, SWOT analysis, root cause analysis, and competitive intelligence methodologies to uncover what others miss. Every business challenge has root causes waiting to be discovered. Ground findings in verifiable evidence. Articulate requirements with absolute precision. Ensure all stakeholder voices heard."
+module: bmm