Ролі

Дев'ять ролей, шість етапів

Роль — це Markdown-файл з коротким frontmatter і промптом. У harness-demo їх дев'ять. Роль — не колонка на дошці: координатор кожного етапу викликає одну чи кілька ролей усередині свого юніта.

З увімкненим deliver.pr підтверджена задача отримує ще один крок, і жодна роль його не виконує: runner сам пушить гілку і відкриває pull request. Його описано на сторінці Життя задачі.

Ролі

Кожна картка каже, що роль читає, що пише і який токен вердикту код від неї чекає.

Чому автор тестів — не qa

Здається охайним дати одній ролі і писати тести, і перевіряти роботу. Це пастка.

Тому tester працює всередині implement-юніта, а qa лише читає. Тести й код потрапляють в один коміт, а потім цей коміт перевіряють дві ролі, які не написали з нього нічого. Заодно на коло лишається один юніт, що пише: qa-юніту, який міг би писати, знадобився б власний коміт і ширший контракт scope.

Де закінчується кожна роль

Файл задачі поділено на секції, і в кожної секції один власник. Роль може писати лише у свою секцію. Дашборд пише лише те, чим володіє людина.

Завдяки секціям-власникам два автори ніколи не б'ються за один файл: коли harness і дашборд обидва чіпають задачу, кожен редагує лише свою ділянку. Коду й тестів у файлі задачі немає взагалі; їх стереже контракт scope.

Додай файл — отримай спеціаліста

Дев'ять ролей — стартовий набір, а не закритий список. Harness зливає дві теки в один реєстр:

• agents/ у harness-demo — базові ролі;
• <project>/.claude/agents/ у твоєму проєкті — твої власні спеціалісти.

Агент проєкту з тим самим ім'ям, що й базовий, заміняє його. Для кожного юніта runner лишає лише агентів, у чиїх stages: є етап юніта, записує їх у .harness/trace/unit-NNNN.agents.json і передає цей файл у Claude Code через --agents. У твій проєкт нічого не пишеться. Далі координатор обирає спеціалістів, потрібних задачі.

Новий спеціаліст — це один новий файл. Крім звичних name, description, model і tools, його frontmatter каже, на яких етапах і коли його можна викликати:

---
name: a11y
description: Checks new UI against keyboard and screen-reader basics
model: sonnet
tools: Read, Grep, Glob
stages: [qa]
when: the task has kind ui
---

Типові спеціалісти проєкту: triager, який розбиває чернетку з кількома задачами всередині, перевірка a11y поруч із qa для ui-задач і docs, який тримає README і changelog в актуальному стані, в межах scope.

Контракт фіксує лише обов'язкові вердикти для кожного етапу, у config.json проєкту: qa-юніту потрібен токен qa:, юніту судді — токен judge:. Будь-який додатковий спеціаліст дозволений.

harness agents показує злитий реєстр, harness agents --check проганяє перевірки дрейфу й моделей, а harness agents --sync копіює постійні правила в кожного базового агента.

Модель на кожну роль

Модель кожного координатора береться з roles.models у config.json. Модель спеціаліста — з його власного frontmatter, а roles.models.<name> її перевизначає. За замовчуванням implementer і tester працюють на sonnet, суддя — на opus, explorer — на haiku. За цим вибором стоять два правила:

• Спершу виміряй, потім здешевлюй. Дешевша модель для explorer чи writer може бути ок; дешевший implementer може коштувати більше на повернених колах, ніж зекономить. Міняй одну роль за раз і порівнюй.
• Суддя — навмисно інша модель, ніж implementer і tester. Модель, що рев'юїть вихід свого ж типу, має ті самі сліпі плями. Код здається їй правдоподібним з тих самих причин, з яких вона його написала. Інша модель помиляється по-іншому, тож ловить частину помилок, яких автори не бачать. Це правило примусове: суддя з тією ж моделлю, що й implementer чи tester, змушує runner вийти з кодом 2 — зламана конфігурація.

Якщо два рев'ю-юніти на задачу задорого, увімкни roles.mergeQaJudge: true. Тоді qa-юніт отримує ще й спеціаліста judge з його критеріями. Qa PASS перезапускає кожну команду [closes], перш ніж задача перейде в done, — так само, як judge CONFIRMED, — а червоний критерій перетворює PASS на повернення. Колонка Judge зникає. Дешевше і слабше: другого юніта зі свіжим контекстом більше немає.