IOP — Intent-Oriented Programming¶

Интенционально-ориентированное программирование (IOP) — прежде всего дисциплина коммуникации вокруг разработки: не «изобретённые заново слэш-команды», а способ договариваться о целях, процессах и изменениях так, чтобы это было видно всем участникам контура (люди, агент, артефакты).

В коммуникации весь ключ. Будет коммуникация — будут согласованные намерения, прозрачность и осмысленный код; не будет — локальный порядок в файлах и глобальный хаос, что агенты обнажили с новой силой. ИТ в глобальном смысле про информационный поток; ПО и его написание — лишь часть этого потока.

Cascade IDE — открытая рабочая реализация IOP: стек, где этот поток сделан явным в agent-first IDE для .NET.

Нормативная привязка

Детали, non-goals и связи с ADR — ADR 0121 (Accepted).
English: IOP manifest (EN).

Зачем IOP¶

ИТ называются информационными, потому что предмет работы — не синтаксис, а согласованный поток смысла: кто с кем и о чём говорит, какие цели и процессы, что считается сделанным, что видно наблюдателю. Если коммуникации нет и ничего не прозрачно — разрабатывать ПО бессмысленно: будет локальный порядок в файлах и глобальный хаос в команде.

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

Что IOP не есть¶

Не «зумеры придумали /build» — слэш, палитра и Melody — только поверхности одного смысла.
Не замена ООП/ФП: классы и функции остаются; меняется то, как команда договаривается о работе до и после правок.

Три столпа в Cascade IDE¶

1. Информационный поток и явное намерение¶

В центре — согласованный информационный поток (люди, агент, артефакты, статусы). Интент — не кнопка, а именованная договорённость о цели или целевом состоянии в этом потоке. В CIDE её несут Intercom, topic cards, ADR/KB, command_id, Intent Melody (c:), слэши (ADR 0119), палитра и те же команды в MCP — один смысл, несколько каналов, без разрозненных парсеров.

2. Двухконтурная верификация¶

Контур	Кто	Что
Синтез	Агент + MCP	Правки, сборка, рефакторинги, git
Верификация	Ты	Diff в Forward, Roslyn-диагностики, тесты, осознанный merge

Инфраструктура (HCI, Roslyn MCP, build/test, git) не даёт интенту нарушить «физику» проекта.

3. Эпистемический контекст¶

Вместо опоры только на типы в C# — канон и маршрутизация контекста: kb-public, agent-notes, дерево knowledge/ (подпапки вроде domains/agent-operations/ — путь в репозитории KB, не «домен» в смысле DDD, KE или таксономии приборов). Агент подбирает playbook'и через router / light-онтологию команды; KB — нормативный слой правил высшего порядка.

Intercom — центр коммуникации вокруг цели (перспектива)¶

Intercom (ADR 0080) в перспективе IOP — не «виджет чата», а центр коммуникации вокруг цели: здесь люди и агенты договариваются, выявляют намерения, уточняют контекст и по итогу ведут реализацию в том же контуре (редактор, MCP, верификация). Topic cards, spine, слэши (0119) — не лента ради ленты, а линии работы с явной целью.

Положение в кокпите — ADR 0120 (Accepted · Implemented): опция primary_work_surface = intercom, когда лобовой якорь — связь и намерение, а не только текст кода.

Честно о потоке от людей¶

IOP не обещает, что «вывезем любой входящий поток» — его не вывозят и сами люди, если всё свалить в одну бесконечную ленту. Ставка продукта — структурировать коммуникацию, а не умножать шум:

линии работы (topic cards, overview/detail) вместо одного хаотичного чата;
батчи уточнений и треды (0031), а не каждое сообщение = немедленный автономный рывок;
intent-first и паритет MCP — меньше дублирования «написал в чат / сделал в палитре / забыл в агенте»;
верификация — человек не обязан «переваривать» всё подряд; он арбитр дельты, а не диспетчер каждого токена.

Если коммуникация не выстроена — не спасёт ни агент, ни IDE. IOP как раз про то, чтобы сначала выстроить её.

Среда, не только приложение (перспектива)¶

IOP и Cascade в перспективе — среда командной работы, а не только окно IDE на одном столе.

Картина: 2–3 человека за отдельными рабочими местами — у каждого каноническая раскладка «три монитора» PFD / Forward / MFD (ADR 0017); в общем поле зрения комнаты — большой экран с командной ситуацией, а не зеркалом чата:

что в работе (линии / topic cards);
где агентам и людям достаточно контекста (KB, playbook, scope);
где нужно дополнить знания или уточнить намерение;
при необходимости — блокеры и фаза (синтез / уточнение / верификация).

Личный кокпит остаётся для своего цикла; общий дисплей — коллективный PFD комнаты (read-mostly проекция согласованной модели). Подробнее — ADR 0122 (Proposed).

Голос в комнате. Рядом за столами люди обычно говорят, а не переписываются в чат — и агент не может честно обещать, что «услышал весь разговор».

IOP не предполагает записывать и расшифровывать каждую устную реплику, чтобы потом выуживать из стенограммы решения: там слишком много шума (полфразы, шутки, передумывания) и мало явных итогов — как с бесконечной лентой сообщений.

На общий экран и в Intercom попадает то, о чём вы уже договорились: карточка темы, pin на room board, короткая структурированная заметка — не протокол всего, что было сказано вслух.

Как это выглядит в сессии¶

flowchart LR
  subgraph intent ["Intent surface"]
    I["Intercom / Melody / Palette / MCP"]
  end
  subgraph synth ["Synthesis"]
    A["Agent + tools"]
  end
  subgraph verify ["Verification"]
    H["Human: diff + diagnostics + tests"]
  end
  subgraph knowledge ["Epistemic layer"]
    K["KB canon / agent-notes"]
  end
  I --> A
  K -.-> A
  A --> H
  H -->|"accept / revise"| I

Что читать дальше¶

Если нужно…	Документ
Кокпит PFD / Forward / MFD	Раскладка UI
Intercom и слэши	ADR 0119
Командная среда и общий экран	ADR 0122
Intent Melody	intent-melody-language-v1.md, ADR 0109
Все решения	Навигатор ADR
Agent-first политика	architecture-policy.md

Cascade IDE — MIT · GitHub · организация AI-Guiders