--- name: tide-flow description: Рабочая модель tide для агента, поднятого через `tide menu`/`tide go` — «всё есть арка», и вся работа ВЕДЁТСЯ ВНУТРИ арки (в её `workspace/`), а не вразброс. Покрывает: как сориентироваться на входе (status/board), как вести работу в арке (input→workspace→output), как уронить кандидата (в т.ч. в соседний проект из ростера), и как закрыть. Используй, когда ведёшь любую работу в tide-сессии, не уверен «куда писать файлы/прогресс», работаешь с арками/кандидатами, или на «как тут у вас всё устроено», «куда это класть», "tide flow", "/tide-flow". Для рутин (переиспользуемых процедур) — см. [[tide-routines]]. --- # tide-flow Ты в сессии, поднятой tide (`tide menu` → проект → тред/рутина → сессия). Сид уже дал тебе CANON.md проекта, паспорт активной арки и ростер. Этот скилл — про то, как здесь **вести работу**, чтобы она не растекалась. CLI — это твой API. Команды детерминированы; `tide help` и `tide --help` — источник истины по флагам. Скилл даёт МОДЕЛЬ, не дублирует справку. ## Два железных правила ### 1. Всё есть арка Любая единица работы живёт как арка (`NN-/` в `.tide/arcs/`). Тред (`kind: thread`) — контейнер сессий одной линии-нити: сессии связаны **хендоффами** (перенос контекста), а не пустыми пере-заходами. Закон треда: первая сессия рождается вместе с тредом, каждая следующая — из хендоффа (пустого «+ new session» посреди треда нет). Рутина (`kind: routine`) — контейнер ранов переиспользуемой процедуры; ран = свежее исполнение, поэтому у рутин «+ new run» остаётся (см. [[tide-routines]]). Не заводи «работу мимо арки»: нет подходящей — заведи (`tide arc new ` / `tide arc new-session -p `), а не пиши в воздух. ### 2. Работа ВЕДЁТСЯ ВНУТРИ арки Это ядро ценности tide: по арке всегда видно, что и как делалось. Жёсткая семантика трёх папок арки: | Папка | Что туда | Когда | |-------|----------|-------| | `input/` | с чего арка началась — сид, ТЗ, исходники | при заходе | | `workspace/` | **ВСЯ текущая работа** — промежуточные файлы, скачанное, обработанное, логи прогонов, черновики, заметки по ходу | пока работаешь | | `output/` | чем арка ЗАКОНЧИЛАСЬ — durable-пойнтеры только на финал | при закрытии | Конкретно: если задача идёт во внешний сервис, грузит картинку, обрабатывает её, зовёт API, генерит артефакт — **всё это кладётся в `/workspace/`**, а не в `/tmp`, не в корень проекта, не «рядом». Прогресс/события/решения по ходу — тоже в workspace (заметкой/логом). `output/` трогаешь только когда арка завершается. Не уверен, в какой ты арке → `tide status` (борд) покажет открытые арки; активную тебе назвал сид. Путь арки = `.tide/arcs//` (для сессии — `.tide/arcs//arcs//`). ## Цикл работы 1. **Сориентируйся** — `tide status`. Прочитай паспорт активной арки (его `## cursor` — точка возобновления). Не начинай, пока не понял, где работа. 2. **Веди в арке** — все файлы/прогресс в `workspace/` (правило 2). По ходу обновляй `## cursor`/`## context` в паспорте, чтобы следующая сессия подхватила. 3. **Заметил постороннее** — урони кандидатом, не отвлекаясь (см. ниже). 4. **Закрой** — когда сделано: положи durable-итог в `output/`, затем `tide arc close ` (гейт не даст закрыть с пустым output / плейсхолдерами). ## Выгрузка по ходу — `tide offload` (10 секунд, не отчёт) Правда пишется на диск в момент рождения, не в конце сессии. Принял решение, свернул на развилке, сделал кусок — одна команда: ```bash tide offload --cursor "<где стою — одна строка>" "<что решил / что дальше>" ``` Правило: по одной строке на каждое, без отчётов и списков. Это дописывает `## context` паспорта и двигает курсор — финальный хендофф тогда становится курацией готового, а не тяжёлой выгрузкой. Забыл — Stop-хук напомнит сам (workspace двигался, паспорт стоит >15 мин): выполни его команду и заканчивай ход. Не спорь с пинком и не откладывай — это и есть закон «ничего не тонет». ## Кандидаты — не теряй идеи Всплыло будущее-дело, которое НЕ относится к текущей арке — не делай его сейчас, урони в бэклог: ```bash tide candidate add "<полная идея>" # в ТЕКУЩИЙ проект tide candidate add "<идея>" --project # в СОСЕДНИЙ проект из ростера ``` Кросс-проектный вариант: работаешь в проекте A, заметил, что что-то относится к проекту B (он есть в ростере — см. блок Roster в сиде) → кидаешь кандидата прямо в B, он ляжет в его бэклог с пометкой `from: ↗ A`. Не переключай контекст, не тащи чужое в свою арку. Захват дешёвый; промоутит кандидата в арку только оркестратор того проекта (`tide candidate promote`), локально. ## Новый ПРОЕКТ ≠ новая нить (важно, кандидат 31) «Заводим проект» от человека = проект РОСТЕРА, а не нить. Разница уровней: - **Проект ростера** — строка в `roster.md` контрол-хоума; только он появляется в пикере «Pick a project». Заводится ОДНОЙ командой: `tide adopt [--name <имя-в-ростере>]` — git init + первый коммит + скелет `.tide/` + строка в ростер, идемпотентно и worktree-ready. - **Нить** (`NN-@slug` в `.tide/arcs/`) — линия работы ВНУТРИ проекта; в пикер проектов не попадает никогда. Завёл нить и отрапортовал «проект готов» → человек открывает пикер и проекта не находит. Сомневаешься, что имел в виду человек — спроси «проект в ростер или нить внутри текущего?». ## Роли (коротко) - **orchestrator** — ведёт CLI: открывает/закрывает арки, мёрджит канон, промоутит кандидатов. Команды знаешь ты, не человек. - **worker** — работает ОДНУ открытую арку; пишет только в её `workspace/`/`output/` + свой кандидат-дроп. Канон не мёрджит, кандидатов не промоутит. Твою роль назвал сид (и `TIDE_ROLE`). ## Скилл сломался или затупил? Зарепорти (важно) tide-скиллы (`tide-*`) — живой инструмент, и ты их главный пользователь. Если скилл из этой группы повёл себя криво, команда упала, инструкция не сошлась с реальностью, или ты затупил из-за неясной формулировки — **не молчи и не чини молча**. Урони репорт в проект-инбокс `tide-stack` одной командой: ```bash tide candidate add skill-<имя>-<кратко> \ "Скилл <имя> v<если знаешь>: что делал → что ожидал → что произошло (точная ошибка/команда). Как воспроизвести." \ --project tide-stack ``` Ляжет в бэклог `tide-stack` с пометкой `from: ↗ <твой проект>` — человек придёт, разберёт и починит скилл. Репортить дёшево; это и есть «история проблем» скилла (бэклог + git самого скилла). Чем точнее воспроизведение — тем быстрее фикс.