Style-Write Unification:
двухагентная коллаборация

1. TL;DR — что произошло

Что хотели

Унифицировать запись стилей инспектора между VS Code-расширением и SaaS. Сделать стратегию шеренной, framework-aware, source-aware, condition-aware и theme-aware. Два агента (Claude и Codex) должны были автономно дискутировать на таймерах и сходиться к рабочей спеке.

Что вышло

Спека получилась богатая (5 документов, ~10к строк), архитектурно цельная — есть StyleWritePlan union, framework adapter umbrella, source ownership с confidence, theme resolver, prop mappers. Codex нашёл 3 P1 регрессии в моём прошлом пасе — две из них я починил (RuntimeThemeContext проза, ScriptObjectStylePlan + mantine), одну починил частично (CssFilePlan invariants — оставил optional с runtime guard вместо discriminated union, и Codex это снова поймал в следующем ревью).

Что сломалось в коллаборации

Дискуссии не было. Был asymmetric ping-pong: Claude правит → Codex поллит и ревьюит → Claude получает явный пинг от Alex и снова правит. Codex запущен как daemon с 10-минутным polling-loop; Claude каждый раз — fresh session, инициируется только Alex'ом вручную. Никакого механизма «Codex разбудил Claude» нет. Convergence criterion отсутствует. Споров между агентами не было — каждый просто принимает фиксы другого как должное.

2. Таймлайн коллаборации

День 1 — 2026-04-14 (вечер): elaboration в одиночку

День 2 — 2026-04-15 (утро): попытка установить протокол

День 2 — 2026-04-15 (день): polling loop без партнёра

День 3 — 2026-04-16: реконструкция и postmortem

3. Архитектура спеки (что наработали)

Спека описывает шеренный pipeline для записи стилей: один путь для VS Code-расширения и SaaS. Три ключевых уровня — capabilities (что доступно в проекте/элементе), source ownership (кто владеет свойством сейчас), write plan (конкретная мутация).

3.1 Pipeline записи (write flow)

3.2 Source Tab routing — кто решает куда писать

3.3 Theme resolution — что особенного

Theme — отдельная подсистема. Differentiates:

Ключевое правило: system — это IDE preference, не source condition. Resolver приводит system → light или dark до роутинга.

4. Канонические решения

5. Postmortem: почему коллаборация развалилась

Протокол был задокументирован в workprocess.md. На бумаге выглядел разумно. На практике развалился по 6 конкретным причинам.

5.1 Asymmetric agents

5.2 No invocation channel

5.3 Session context loss

5.4 No convergence criterion

5.5 No discussion / disagreement protocol

5.6 Observer как message bus

5.7 Что в этом всё-таки сработало

6. Протокол v2 — конкретный дизайн

Цель: исключить Alex'а как message bus. Сохранить asymmetric roles. Добавить convergence criterion и disagreement handling.

6.1 Архитектура: orchestrator + структурированный ledger

6.2 Структурированный ledger

Дополнить workprocess.md машинным findings.yaml рядом:

findings:
  - id: F-001
    title: "RuntimeThemeContext composition-root prose contradiction"
    severity: P1
    status: closed
    raised_by: codex
    raised_at: 2026-04-15T13:28+02:00
    fix_owner: claude
    fixed_at: 2026-04-15T14:58+02:00
    verified_by: codex
    verified_at: 2026-04-15T15:09+02:00

  - id: F-004
    title: "PlainCssFilePlan compile-valid invalid targets"
    severity: P1
    status: open
    raised_by: codex
    raised_at: 2026-04-15T15:09+02:00
    fix_owner: claude
    notes: |
      Discriminated union required (mode: 'existing-owner' | 'create-rule')
      Runtime guard insufficient.

  - id: F-005
    title: "Tailwind + CSS Modules tie-breaker policy"
    severity: P1
    status: open_question
    raised_by: codex
    raised_at: 2026-04-15T13:28+02:00
    fix_owner: observer
    notes: "Requires product decision before implementation."

6.3 Orchestrator pseudocode

#!/usr/bin/env bash
# agent-loop.sh — runs both agents until convergence
set -euo pipefail

LEDGER=docs/specs/2026-04-14-style-write-unification-workprocess.md
FINDINGS=docs/specs/2026-04-14-style-write-unification-findings.yaml
QUIET_CYCLES=0
MAX_QUIET=3

while true; do
  open_for_claude=$(yq '[.findings[] | select(.status=="open" and .fix_owner=="claude")] | length' "$FINDINGS")
  open_for_codex=$(yq '[.findings[] | select(.status=="open" and .fix_owner=="codex")] | length' "$FINDINGS")
  disputes=$(yq '[.findings[] | select(.status=="dispute")] | length' "$FINDINGS")

  if [[ $disputes -gt 0 ]]; then
    notify_observer "disputes need adjudication: $disputes"
    break
  fi

  prev_count=$(wc -l < "$LEDGER")

  if [[ $open_for_claude -gt 0 ]]; then
    claude -p "Read $LEDGER and $FINDINGS. Address all findings where fix_owner=claude AND status=open. Mark each closed in findings.yaml. Append a 📍 Review Session turn to $LEDGER."
  elif [[ $open_for_codex -gt 0 ]]; then
    codex exec "Same instruction, fix_owner=codex."
  else
    # Both sides clear → run codex review of last claude turn
    codex exec "Review the most recent 📍 turn by claude in $LEDGER. If you find new findings, append them to $FINDINGS with raised_by=codex."
  fi

  new_count=$(wc -l < "$LEDGER")
  if [[ $new_count -eq $prev_count ]]; then
    QUIET_CYCLES=$((QUIET_CYCLES + 1))
    [[ $QUIET_CYCLES -ge $MAX_QUIET ]] && { notify_observer "convergence reached"; break; }
  else
    QUIET_CYCLES=0
  fi

  sleep 60
done

6.4 Что новый протокол даёт

6.5 Что НЕ решается v2

7. Что осталось открытым

8. Action items

Немедленно (этой неделе)

1. Закрыть F-004 (PlainCssFilePlan discriminated union) — 5-минутная правка plan.md.
2. Принять решение по F-005 (Tailwind+CSS Modules tie-breaker). Рекомендация: CSS Modules выигрывает как explicit owner; Tailwind показывается как probable с диагностикой.
3. Закрыть F-007 и F-008 — добавить комментарии и validation rules в plan.md.

В рамках следующего sprint'а

1. Реализовать agent-loop.sh orchestrator + findings.yaml формат.
2. Тест-драйв на следующей multi-agent задаче (можно начать с не-критичной — например, аудит ProseMirror integration plan).
3. Если orchestrator работает — портировать workprocess.md и findings.yaml в шаблон, использовать на всех multi-agent специациях.

Долгосрочно

1. Использовать Anthropic prompt caching для удешевления повторных чтений ledger.
2. Расширить orchestrator до 3+ агентов (Claude + Codex + Gemini для tertiary view).
3. Конвертировать spec examples в failing тесты (Phase 0 в plan.md) до начала имплементации — иначе спека не верифицируется.

9. График прогресса тестов

Динамика green-тестов с 2026-04-22 по настоящее время. Максимум: 2211 (полная E2E матрица). Отмечены ключевые события: коммиты с фиксами, старты прогонов, переломные моменты.

📊 Открыть полный интерактивный график