Сценарии развития

Если «сценарии исполнения» — это то, как ассистент действует здесь и сейчас (workflow, цепочки навыков), то «сценарии развития» можно рассматривать как надстройку-мета, показывающую эволюцию ассистента и пользователя вместе.

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

квестами («научить ассистента управлять списками дел», «добавить визуализацию»);
этапами роста (базовый ассистент → специализированный → интегрированный в среду → партнёр в творчестве);
ветвлением (пользователь выбирает, в какую сторону развивать — например, больше в сторону организации задач или в сторону мультимедиа).

🔹 Форматы сценариев развития

RPG-древо навыков — навыки и сценарии открываются как skill tree, а пользователь «прокачивает» ассистента своими действиями.
Кооперативное путешествие — пользователь и ассистент проходят «главы истории», где новые функции — это сюжетные находки.
Эволюция мира — интерфейс и функции ассистента визуально «обогащаются» с ростом (например, из пустого поля вырастает «сад возможностей»).
Метрика доверия — чем больше пользователь передаёт ассистенту задач, тем выше его «уровень автономности» и сценарии развития идут быстрее.

🔹 Сценарий развития «Напарник в квесте»

Этап 1. Знакомство («новичок»)

Пользователь видит «чистого» ассистента, который умеет мало (например, только отвечать на простые запросы).
Первое взаимодействие запускает подсказку: «Чтобы я стал полезнее, научи меня выполнять твои задачи».
Технически: базовый набор встроенных навыков + установка первого пользовательского навыка/сценария.

Этап 2. Совместная тренировка («ученик»)

Пользователь начинает использовать ассистента для повторяющихся действий.
Ассистент «запоминает» и предлагает оформить это как сценарий.
Технически: механизм записи сценариев, запуск по команде.

Этап 3. Автономность («спутник»)

Ассистент начинает предлагать сам: «Хочешь, я буду запускать это утром?»
Появляется первое условное планирование/событийное срабатывание.
Технически: базовое планирование задач, реакция на триггеры.

Этап 4. Расширение («партнёр»)

Пользователь видит, что ассистент умеет подключать внешние источники (API, данные).
Появляется чувство, что «напарник вырос».
Технически: подключение внешнего API через навык, демонстрация вариативности представлений данных.

отличный вопрос. если хотим «сценарии развития» как первую-классную сущность, нам нужны несколько недостающих кирпичиков в AdaOS. ниже — короткий, практичный чек-лист с примерами CLI/API и минимальными схемами.

что добавить в AdaOS

1) ядро сценариев развития (DSE: Development Scenarios Engine)

назначение: оркестратор «глав/этапов» развития с триггерами и действиями.
нужно:
мини-FSM (state machine) с stages, triggers, guards, actions, rewards.
стандартные actions: scenario.install|uninstall|enable|disable|run, skill.install|remove, planner.schedule, toggle.dev_mode, toggle.runtime_adapt, ui.nudge, grant.badge, set.flag, collect.metric.
декларативная схема (yaml/json) + валидация.

минимальная схема (yaml):

id: mvp.partner_quest
version: 0.1
stages:
  - id: novice
    entry:
      - ui.nudge: {text: "научи меня твоему первому делу"}
    triggers:
      - on: scenario.created
        if: {count_user_scenarios_gte: 1}
        go: apprentice
  - id: apprentice
    actions:
      - planner.schedule: {cron: "0 9 * * *", task: "run:daily_brief"}
    triggers:
      - on: user.accepted_suggestion
        go: companion
  - id: companion
    actions:
      - toggle.runtime_adapt: {enabled: true}
    triggers:
      - on: integration.connected
        if: {provider_in: ["notion","trello"]}
        go: partner
  - id: partner
    actions:
      - grant.badge: {name: "интеграции активны"}

2) жизненный цикл навыков/сценариев (Lifecycle Controller)

hooks: pre_install/post_install/pre_uninstall/post_uninstall/pre_upgrade/post_upgrade.
атомарность/rollback: транзакции на уровне репозитория (git-ориентированный), сохранение snapshot.
команды:
adaos scenario install <name>
adaos scenario remove <name> --purge
adaos scenario enable|disable <name>
adaos scenario run <name> [-p key=val]

3) переключатель режимов (Dev Mode & Runtime Adaptation)

См. ниже Контекст разработки

4) реестр событий + единый шина/контракты

event registry: описатель event.yaml (тип, payload-schema, privacy-class).
нормализация: канонические темы: nlp.intent.*, ui.*, planner.*, integration.*, skill.*, scenario.*, quest.*.
политики доступа: кто может подписываться/паблишить (scoped tokens).

5) планировщик и триггеры

триггеры: cron, время суток, «первый раз/повтор N», событие, условие над метриками, кнопка в UI.
API: planner.schedule, planner.cancel, trigger.emit.

6) прогресс, телеметрия и бейджи

store: progress/{user_id}.jsonl или kv-таблица.
метрики: «кол-во созданных сценариев», «принятые предложения», «подключенные интеграции».
бейдж-сервис: декларативно в DSE (grant.badge).

7) шаблоны и scaffolding

генераторы: adaos create scenario, adaos create skill.
боевой минимум шаблонов: «повтор действия → сценарий», «напоминалка», «интеграция с внешним API», «kanban представление».

8) совместимый UI (Angular/Ionic)

Journey View (квест-лента): этапы, прогресс, триггеры, «принять предложение».
Dev HUD: индикатор режима, «записать макро», «просмотр трассы».
Представления данных: список/карточки/Kanban как сменные layout-плагины.

9) безопасность, согласия, политика изменений

consent prompts: при автозапусках/расписаниях/интеграциях.
scopes: scenarios.manage, skills.manage, planner.manage, integrations.connect.
audit log: кто что установил/изменил, когда.

10) версионирование, миграции и совместимость

semver для сценариев/навыков; schemaVersion.
adaos scenario migrate <name> --to 1.2.0.

11) тестовый стенд (Harness)

«сухие прогоны» DSE: adaos quest test mvp.partner_quest --with fixtures/demo.json.
snapshot-тесты этапов/триггеров.

быстрые «склейки» под MVP

CLI/SDK (скетч)

# включить квест развития
adaos quest enable mvp.partner_quest

# этап 1: пользователь оформил первый сценарий — DSE двинет состояние
adaos scenario create daily_brief --from template:repeat_action

# ассистент предлагает расписание → пользователь соглашается
adaos quest accept mvp.partner_quest --suggestion schedule_daily_brief

# подключение интеграции (kanban)
adaos integration connect trello --token $TRELLO_TOKEN

# переключить dev/runtime адаптацию
adaos dev on
adaos scenario adapt daily_brief --set view=kanban --dry-run
adaos dev off

минимальный контракт «действия» (SDK)

export type QuestAction =
  | { type: "scenario.install"; name: string; source?: string }
  | { type: "scenario.run"; name: string; params?: Record<string, any> }
  | { type: "toggle.dev_mode"; enabled: boolean }
  | { type: "toggle.runtime_adapt"; enabled: boolean }
  | { type: "planner.schedule"; cron: string; task: string }
  | { type: "grant.badge"; name: string }
  | { type: "ui.nudge"; text: string };

минимальный event-registry (yaml)

- name: scenario.created
  payload_schema: {type: object, properties: {name: {type: string}}}
  privacy: low

- name: user.accepted_suggestion
  payload_schema: {type: object, properties: {suggestion: {type: string}}}
  privacy: medium

- name: integration.connected
  payload_schema: {type: object, properties: {provider: {type: string}}}
  privacy: high

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

контекст разработки

1) что это

одна запись состояния в workspace:

можно вести по одному активному skill и/или scenario.
если пусто — ничего не находится в разработке.
операции над активом: отложить, использовать, опубликовать, удалить.

2) хранение

файл: ~/.adaos/dev/context.yaml (локально; при наличии хаба — синх по пользователю/узлу).

schemaVersion: 1
updatedAt: "2025-09-30T18:45:00Z"
active:
  skill:    # или null
    name: weather_skill
    path: "/home/user/.adaos/skills/weather_skill"
    branch: "dev/skill/weather_skill"
    status: "active"        # active|shelved|published|discarded
    startedAt: "2025-09-29T10:12:00Z"
    notes: "добавляю hourly"
  scenario: # или null
    name: daily_brief
    path: "/home/user/.adaos/scenarios/daily_brief"
    branch: "dev/scenario/daily_brief"
    status: "active"
    startedAt: "2025-09-29T12:05:00Z"
flags:
  runtime_adapt_safelisted: ["daily_brief"]  # какие сценарии можно «крутить на лету»
locks:
  heldBy: "device-id-123"    # для многодевайсной гонки
  expiresAt: "2025-09-30T19:00:00Z"

3) CLI (минимум)

# выбрать актив в разработку (создаст ветку, scaffold по шаблону)
adaos dev pick skill weather_skill
adaos dev pick scenario daily_brief --from template:repeat_action

# показать состояние
adaos dev status

# отложить (перевести в shelved: упаковать «полку», закрыть ветку)
adaos dev shelve scenario daily_brief -m "жду токен API"

# использовать (собрать → установить/обновить → включить)
adaos dev use scenario daily_brief --install --enable

# опубликовать (semver bump, тесты, tag, push в registry/forge)
adaos dev publish scenario daily_brief --version 0.2.0 --visibility team

# удалить (очистить рабочие файлы и контекст; спросит подтверждение)
adaos dev discard scenario daily_brief --purge

# разрешить «адаптацию на лету» для активного сценария
adaos scenario adapt daily_brief --set view=kanban
# внутри SDK: проверка, что scenario в safelist или активен в dev-context

короткие алиасы:

pick → начать/продолжить разработку,
shelve → отложить,
use → использовать локально,
publish → опубликовать,
discard → удалить.

4) lifecycle-хуки (интеграция с уже существующим контроллером)

onDevPick(type,name) → scaffold, ветка dev/<type>/<name>, регистр в context.
onDevShelve → snapshot (tar.gz), запись status=shelved.
onDevUse → build/install/enable; эмит dev.used.
onDevPublish → тест-харнесс, semver, tag, push, запись status=published.
onDevDiscard → cleanup, status=discarded.

5) события (чтобы DSE/квест видел прогресс)

dev.context.changed {active:{skill?,scenario?}, op}
dev.shelved / dev.used / dev.published / dev.discarded
scenario.adapted {name, diff}

пример: квест «Напарник в квесте» ловит dev.used и двигает стадию «ученик» → «спутник».

6) политика runtime-адаптации

без общего dev-тумблера достаточно safelist:
разрешены только сценарии: in dev-context или явно в flags.runtime_adapt_safelisted.
SDK проверяет политику перед применением изменений.
adaos scenario adapt ... --dry-run всегда допустим, но без применения.

7) UI (Ionic)

бейдж «разработка» в шапке, если актив хоть один.
карточки активов с кнопками: отложить / использовать / опубликовать / удалить.
индикатор локера «занято другим устройством» + «забрать» (respect locks).

8) git-операции по умолчанию

pick создаёт ветку dev/<type>/<name>, инициирует commit «WIP start».
shelve делает архив «полки» ~/.adaos/dev/shelves/<type>/<name>-<ts>.tgz.
publish мержит в main/stable, ставит тег skill/<name>@<ver> или scenario/....

9) права и согласия

publish: нужен scope skills.publish/scenarios.publish.
use: локально всегда, но для системных сценариев — только с admin scope.
UI подтверждения: публикация для всех/команды/только мне.

10) интеграция с планировщиком/registry

use может (опционально) прикрутить расписание, если в манифесте сценария задан suggestedSchedules.
publish регистрирует артефакт и метаданные в реестре.

мини-контракт API (SDK)

type DevEntityType = "skill" | "scenario";
type DevStatus = "active" | "shelved" | "published" | "discarded";

interface DevRecord {
  type: DevEntityType;
  name: string;
  path: string;
  branch?: string;
  status: DevStatus;
  startedAt: string;
  notes?: string;
}

interface DevContext {
  schemaVersion: number;
  updatedAt: string;
  active: { skill?: DevRecord; scenario?: DevRecord };
  flags: { runtime_adapt_safelisted: string[] };
  locks?: { heldBy: string; expiresAt: string };
}

interface DevService {
  pick(t: DevEntityType, name: string, opts?: { fromTemplate?: string }): Promise<DevRecord>;
  shelve(t: DevEntityType, name: string, msg?: string): Promise<void>;
  use(t: DevEntityType, name: string, opts?: { install?: boolean; enable?: boolean }): Promise<void>;
  publish(t: DevEntityType, name: string, opts: { version: string; visibility: "me"|"team"|"public" }): Promise<void>;
  discard(t: DevEntityType, name: string, opts?: { purge?: boolean }): Promise<void>;
  status(): Promise<DevContext>;
}

как это подключается к нашему «сценарию развития»

этап 2 → 3: пользователь делает dev use scenario daily_brief → событие dev.used → квест предлагает расписание.
этап 3 → 4: publish или подключение интеграции — квест фиксирует прогресс.
«выход из разработки» — это одна из четырёх операций: отложить, использовать, опубликовать, удалить.