Session 891838ea

# decomposer session

- **id:** `891838ea-cc6d-44b8-a9d3-6b50f73cc8ff`
- **task:** RCL-382
- **created:** 2026-05-14T22:13:28.226055536+00:00
- **cost:** $0.7486
- **duration:** 107774ms
- **claude_session:** 492fc363-e7fc-4f64-98e6-013605866caf
- **error:** false

## System prompt

Разбиваешь задачу на подзадачи. Каждая — один чёткий deliverable с понятным DoD. Title — короткое читаемое название на русском, как в продуктовом бэклоге («Проверка судимости», «Модуль captcha», «Синхронизатор ФССП»). Без хеш-тегов, без имён классов, без кодов. Зависимости указывай в `blocked_by` при `mcp__neurobot__add_child_tasks` — демон исполняет параллельно всё, что не связано. Предпочтителен wave-подход (topological levels): связывай через `blocked_by` только реальные артефактные зависимости, чтобы получались широкие параллельные слои, а не длинная цепочка. В описание каждой подзадачи кидай выдержки из спеки и ссылки на аттачменты парента, чтобы ребёнок не копал заново.

## Prompt

You are decomposing a `epic` into child `story`s.

**Parent ID:** RCL-382
**Parent type:** epic
**Title:** 3D-шашки
**Description:** No description

Steps:
1. Read any attachments referenced in the description (PDF, MD in the working dir). Also read `.goal-agent/tasks/RCL-382/research.md` if it exists — its findings must inform the decomposition and be referenced in child descriptions.
2. Produce a list of `story`s — each a concrete deliverable one level below a `epic`. Each child will itself be decomposed into `task`s on its own decompose phase, so keep each story scoped to ~3-7 tasks of independent work.
3. **Determine execution order.** For every pair of children, ask: does B need A's output (schema, artifact, infra, decision)? If yes, B must have A's id in its `blocked_by`. Examples that almost always need ordering:
- scaffolding/bootstrap before feature work
- data model / migration before code that uses it
- a research/spike child before implementation children
- shared library/contract before consumers
Parallelism is the exception, not the default. Children with no real dependency may share the same `blocked_by`, but don't invent dependencies to serialize work that is genuinely independent.
4. **Write rich descriptions** for each child — the body you pass to `mcp__neurobot__create_issue` becomes the backend description AND is mirrored to `tasks.yaml` context by `add_child_tasks`. Include: scope, acceptance criteria in prose, links to the parent research (`.goal-agent/tasks/RCL-382/research.md`) and any attachments, constraints the parent already discovered. The richer this is, the cheaper the child's own research phase becomes — see rule below.
5. **Create each `story` as an issue via `mcp__neurobot__create_issue`.** Pass `parent = "RCL-382"`, the title and description from step 4, and `state = "Backlog"`. Collect the assigned identifier (e.g. `NB-42`) for each.
6. Once ALL child issues are created, call `mcp__neurobot__add_child_tasks` exactly once with the full list. Schema:
parent_id: "RCL-382"
children: [
{ id: "NB-41", title: "…", task_type: "story", workflow: "epic", blocked_by: [] },
{ id: "NB-42", title: "…", task_type: "story", workflow: "epic", blocked_by: ["NB-41"] },
…
]
`blocked_by` entries must reference ids in this same batch or existing tasks in tasks.yaml — the daemon rejects dangling refs. The daemon keeps a blocked child in `backlog` until every blocker reaches `done`.
7. Write a short human-readable summary to `.goal-agent/tasks/RCL-382/decomposition.md` including the dependency graph (e.g. `RCL-42 depends on RCL-41`).

Rules:
- Every child uses `task_type: "story"` and `workflow: "epic"` — do not pick a different type/workflow.
- Do NOT edit tasks.yaml by hand. Do NOT skip issue creation.
- Do NOT leave `blocked_by` empty on a child that actually needs earlier work — the daemon will launch it in parallel and two siblings will race. Order is enforced by this field, nothing else.

---

## project-memory
`.goal-agent/project-memory.md` — extracted knowledge для будущих агентов, не бортжурнал. Читай в начале, дописывай в `## Недавнее` в конце фазы — если есть что добавить.

Тест: «сэкономит ли эта строка время агенту, который через неделю откроет проект впервые?» Если да — пиши. Если факт есть в коде, git-логе, tasks.yaml, sessions/ или AC — он уже хранится, дублировать не надо. Если в фазе ничего такого не всплыло — пропусти запись.

Формат записи:
```
### <ISO-ts> — <task_id> <phase>
- <факт в одну строку>
- [→ устойчивое][важно?]: <факт-кандидат на подъём в `Устойчивые факты`>
```

Теги: `[→ устойчивое]` — поднять при следующей компактации; `[важно]` — сохранить дословно даже при сжатии.

---

**End-of-phase contract.** Before returning, call `mcp__neurobot__complete_phase` exactly once. Arguments (flat, no nested JSON):
- `task_id`: "RCL-382"
- `kind`: one of `complete` | `failed` | `blocked`
- `reason` (only when `kind=failed`): short explanation string
- `description` (only when `kind=blocked`): what specifically is blocking

Examples:
- Success: `complete_phase(task_id="RCL-382", kind="complete")`
- Failure: `complete_phase(task_id="RCL-382", kind="failed", reason="tests X and Y fail")`
- Blocker: `complete_phase(task_id="RCL-382", kind="blocked", description="need staging DB credentials")`

Do NOT put control-plane signals in your response text — the daemon ignores it.

## Response

Эпик RCL-382 декомпозирован на 6 stories (RCL-389..394) строго по натуральным швам research.md §5, цепочкой зависимостей scaffold → rules → scene → input → controller/UI → polish. Decomposition.md записан.