| 1 | # IOP — Intent-Oriented Programming |
| 2 | |
| 3 | **Интенционально-ориентированное программирование (IOP)** — прежде всего **дисциплина коммуникации** вокруг разработки: не «изобретённые заново слэш-команды», а способ договариваться о целях, процессах и изменениях так, чтобы это было **видно** всем участникам контура (люди, агент, артефакты). |
| 4 | |
| 5 | **В коммуникации весь ключ.** Будет коммуникация — будут согласованные намерения, прозрачность и осмысленный код; не будет — локальный порядок в файлах и глобальный хаос, что агенты обнажили с новой силой. ИТ в глобальном смысле про **информационный поток**; ПО и его написание — лишь часть этого потока. |
| 6 | |
| 7 | Этот текст — **манифест IOP**: зачем, что это, чего не является, как входить, опоры, форма работы. **Экосистема** (IDE, KB, конкретные продукты) — **пример применения**, не синоним дисциплины — см. [§ Пример: экосистема Cascade](#пример-экосистема-cascade). |
| 8 | |
| 9 | **Как войти:** не обязательно с манифеста целиком — [§ Два порога входа](#два-порога-входа). |
| 10 | |
| 11 | !!! info "Нормативная привязка" |
| 12 | Детали, non-goals и связи с ADR — [ADR 0121](adr/0121-intent-oriented-programming-paradigm.md) (Accepted). |
| 13 | English: [IOP manifest (EN)](en/iop-manifest-v1.md). |
| 14 | |
| 15 | --- |
| 16 | |
| 17 | ## Зачем IOP |
| 18 | |
| 19 | ИТ называются **информационными**, потому что предмет работы — не синтаксис, а **согласованный поток смысла**: кто с кем и о чём говорит, какие цели и процессы, что считается сделанным, что видно наблюдателю. Если коммуникации нет и ничего не прозрачно — разрабатывать ПО бессмысленно: будет локальный порядок в файлах и глобальный хаос в команде. |
| 20 | |
| 21 | IOP ставит в центр **явное намерение** (цель, целевое состояние, договорённый процесс) и **наблюдаемую дельту** исполнения. Код в репозитории остаётся источником правды для программы; IOP — не «вместо кода», а **дисциплина коммуникации**, в которой код — проверяемый результат договорённости. |
| 22 | |
| 23 | --- |
| 24 | |
| 25 | ## Что IOP не есть |
| 26 | |
| 27 | - **Не** «зумеры придумали `/build`» — слэш, палитра, горячие клавиши — только **поверхности** одного смысла. |
| 28 | - **Не** замена ООП/ФП: классы и функции остаются; меняется то, *как команда договаривается* о работе до и после правок. |
| 29 | - **Не** документация на конкретный продукт или KB: манифест не подменяет гайд по базе знаний, router или онбординг в IDE. |
| 30 | |
| 31 | --- |
| 32 | |
| 33 | ## Два порога входа |
| 34 | |
| 35 | Снаружи IOP часто показывают **уже собранным** — как будто с первого дня нужны и философия, и вся инфраструктура. На деле у многих был другой старт, и он по-прежнему нормален. |
| 36 | |
| 37 | | Путь | О чём речь | |
| 38 | |------|------------| |
| 39 | | **Любопытство** | Папка, один честный разговор с агентом, одна гипотеза — без готовой «системы вокруг» | |
| 40 | | **Интегрированный** | Уже сложившийся контур: продукт, канон, привычные поверхности — удобно тем, кто внутри | |
| 41 | |
| 42 | Оба сходятся в одной дисциплине: **явное намерение**, **наблюдаемая дельта**, человек и агент в одном потоке смысла (артефакты, не болталка сбоку). Разница — в том, **что показывают первым**, а не в «настоящей» и «упрощённой» версии IOP. |
| 43 | |
| 44 | **Заметка об истории (один референс, не норма для всех).** Сначала был разговор — «как ты вообще думаешь?» — без канона и без маркеров: их просто ещё не существовало. Контур не спускали сверху: его **складывали вместе** — человек и агент, вопросы, разногласия, уточнения. Потом появился общий файл, куда агент мог дописывать между сессиями. Позже отдельно выросли база знаний, IDE, каналы вроде Intercom — как **следствие** практики, не как входной билет. Капитан остаётся у человека; без агента в том же цикле многие вещи, которые мы теперь называем IOP, просто не успели бы оформиться. |
| 45 | |
| 46 | Показывать скептику только «вершину» — значит рисовать ложную картину. Рассказывать старт так, будто всё уже было — тоже. |
| 47 | |
| 48 | --- |
| 49 | |
| 50 | ## Три опоры IOP |
| 51 | |
| 52 | ### 1. Поток смысла и явное намерение |
| 53 | |
| 54 | В центре — **согласованный информационный поток** (люди, агент, артефакты, статусы). **Интент** — не кнопка, а **именованная договорённость** о цели или целевом состоянии в этом потоке. Один смысл может проявляться в чате, в командах, в ADR — без разрозненных «миров». |
| 55 | |
| 56 | ### 2. Двухконтурная верификация |
| 57 | |
| 58 | | Контур | Кто | Что | |
| 59 | |--------|-----|-----| |
| 60 | | **Синтез** | Агент + инструменты | Правки, сборка, рефакторинги, автоматизация | |
| 61 | | **Верификация** | Человек | Diff, тесты, диагностики, осознанное принятие | |
| 62 | |
| 63 | Инфраструктура не даёт намерению нарушить «физику» проекта; капитан на этапе верификации — человек. |
| 64 | |
| 65 | ### 3. Эпистемический слой |
| 66 | |
| 67 | Помимо кода и типов — **канон и маршрутизация контекста**, чтобы намерение не держалось только в голове и в последнем сообщении чата. Как устроен канон в конкретной среде — вопрос **реализации** (use case), не манифеста. |
| 68 | |
| 69 | --- |
| 70 | |
| 71 | ## Агент до реализации |
| 72 | |
| 73 | Агент в IOP полезен **до** коммита и тяжёлой автоматизации: проговорить углы, оспорить, сузить scope — без ожидания коллеги и без типичного социального трения. Это не отменяет ревью людей и не делает ADR «автоматическими»: оператор остаётся капитаном. |
| 74 | |
| 75 | --- |
| 76 | |
| 77 | ## Честно о потоке от людей |
| 78 | |
| 79 | IOP **не обещает**, что «вывезем любой входящий поток» — его **не вывозят и сами люди**, если всё свалить в одну бесконечную ленту. Ставка — **структурировать** коммуникацию, а не умножать шум: |
| 80 | |
| 81 | - **линии работы** вместо одного хаотичного чата; |
| 82 | - **батчи уточнений** и треды, а не каждое сообщение = немедленный автономный рывок; |
| 83 | - **один смысл** на разных поверхностях — меньше «написал в чат / сделал в палитре / забыл в агенте»; |
| 84 | - **верификация** — человек арбитр **дельты**, а не диспетчер каждого токена. |
| 85 | |
| 86 | Если коммуникация не выстроена — не спасёт ни агент, ни IDE. IOP как раз про то, чтобы **сначала** выстроить её. |
| 87 | |
| 88 | --- |
| 89 | |
| 90 | ## Как это выглядит в сессии |
| 91 | |
| 92 | ```mermaid |
| 93 | flowchart LR |
| 94 | subgraph intent ["Намерение"] |
| 95 | I["Поверхность договорённости"] |
| 96 | end |
| 97 | subgraph synth ["Синтез"] |
| 98 | A["Агент + инструменты"] |
| 99 | end |
| 100 | subgraph verify ["Верификация"] |
| 101 | H["Человек: дельта, тесты, принятие"] |
| 102 | end |
| 103 | subgraph knowledge ["Эпистемика"] |
| 104 | K["Канон / контекст"] |
| 105 | end |
| 106 | I --> A |
| 107 | K -.-> A |
| 108 | A --> H |
| 109 | H -->|"принять / уточнить"| I |
| 110 | ``` |
| 111 | |
| 112 | --- |
| 113 | |
| 114 | ## Пример: экосистема Cascade |
| 115 | |
| 116 | **Use case**, не определение IOP. [Cascade IDE](https://github.com/AI-Guiders/cascade-ide) — открытая **рабочая реализация** дисциплины для .NET: agent-first IDE, in-proc MCP, канон KB ([kb-public](https://github.com/AI-Guiders/kb-public), agent-notes). Другие стеки (Cursor + MCP, свой продукт) могут нести те же опоры иначе. |
| 117 | |
| 118 | **По духу Agile (не Scrum):** короткие циклы, проверка и адаптация, кооперация вместо обвинений — то же семейство привычек, что в [Agile Manifesto](https://agilemanifesto.org/iso/ru/manifesto.html), но команда шире (люди + агент), а дисциплина здесь названа **IOP** (манифест отдельно от фреймворка — как Agile от Scrum). Публичный нарратив «среда уже так живёт» — [статья на KDGIO](https://karataevdmitry.github.io/ru/writing/agent-workspace-agile.html). |
| 119 | |
| 120 | ### Как опоры легли на стек |
| 121 | |
| 122 | | Опора IOP | В экосистеме Cascade | |
| 123 | |-----------|----------------------| |
| 124 | | Поток и намерение | Intercom, topic cards, ADR/KB, `command_id`, Intent Melody (`c:`), слэши ([0119](adr/0119-chat-slash-commands-intercom-surface.md)), палитра, те же команды в MCP | |
| 125 | | Верификация | Diff в Forward, Roslyn-диагностики, тесты, осознанный merge | |
| 126 | | Эпистемика | `knowledge/`, router, [SHOWCASE](https://github.com/AI-Guiders/kb-public) — **гайд по KB**, не этот манифест | |
| 127 | |
| 128 | ### Intercom |
| 129 | |
| 130 | **Intercom** ([ADR 0080](adr/0080-intercom-naming-and-multi-party-channel-model.md)) — не «виджет чата», а **центр коммуникации вокруг цели** в этом use case: договорённости, намерения, реализация в том же контуре (редактор, MCP). [0120](adr/0120-primary-work-surface-intercom-or-editor.md): `primary_work_surface = intercom`, когда лобовой якорь — связь, а не только код. Дизайн и attach — [intercom-design-hub](design/intercom-design-hub-v1.md); агент как спарринг — [philosophy §8](design/cascadeide-philosophy-v1.md#8-агент-как-партнёр-для-проектирования-до-кода). |
| 131 | |
| 132 | ### Среда команды (перспектива) |
| 133 | |
| 134 | Не только окно IDE: раскладка PFD / Forward / MFD ([0017](adr/0017-multi-window-workspace-and-agent-surfaces.md)), общий экран комнаты ([0122](adr/0122-collaborative-iop-environment-and-shared-situational-display.md) Proposed). На экран попадает **то, о чём уже договорились** — не стенограмма всего, что сказали вслух. |
| 135 | |
| 136 | Онбординг в продукте (не в IOP): [handbook §1.1](design/cide-design-handbook-v1.md#11-два-порога-входа-cide). |
| 137 | |
| 138 | --- |
| 139 | |
| 140 | ## Что читать дальше |
| 141 | |
| 142 | | Если нужно… | Документ | |
| 143 | |-------------|----------| |
| 144 | | **IOP (манифест)** | этот файл · [ADR 0121](adr/0121-intent-oriented-programming-paradigm.md) | |
| 145 | | **Agile по духу (human–agent)** | [KDGIO: среда «человек–агент»](https://karataevdmitry.github.io/ru/writing/agent-workspace-agile.html) | |
| 146 | | **Экосистема Cascade (use case)** | [§ выше](#пример-экосистема-cascade) · [handbook](design/cide-design-handbook-v1.md) · [навигатор ADR](site/adr-nav/index.md) | |
| 147 | | **KB (отдельно от IOP)** | [kb-public / SHOWCASE](https://github.com/AI-Guiders/kb-public) | |
| 148 | | Раскладка UI, Melody, политика agent-first | [UI layout](ui-ux/cascade-ide-ui-layout-v1.md) · [intent-melody](intent-melody-language-v1.md) · [architecture-policy](architecture-policy.md) | |
| 149 | |
| 150 | --- |
| 151 | |
| 152 | *Cascade IDE — MIT · [GitHub](https://github.com/AI-Guiders/cascade-ide) · [AI-Guiders](https://ai-guiders.github.io/)* |
| 153 | |