Skip to content

feat(mt-core): unresolvable — три тригери термінального стану - #31

Open
vitaliytv wants to merge 1 commit into
mainfrom
claude/unresolvable
Open

feat(mt-core): unresolvable — три тригери термінального стану#31
vitaliytv wants to merge 1 commit into
mainfrom
claude/unresolvable

Conversation

@vitaliytv

Copy link
Copy Markdown
Member

Хвиля 2, перший пункт

graph.md: «(1) streak ≥ agent_retry_max + engineer_retry_max; (2) plan-rejectedplan_reject_max; (3) sum(wall_sec) > budget_total_secunresolvable.md + алерт».

Маркер лише читався сканером — не писав його ніхто. Тобто термінальний стан був недосяжним: вузол із вичерпаною драбиною вічно лишався failed, і його щоразу підбирав наступний прохід оркестратора. Автомат не мав способу сказати «я більше не маю ходів».

Три різнорідні тригери

Тригер Що вичерпано
streak ≥ agent_retry_max + engineer_retry_max драбина виконання
plan-rejected ≥ plan_reject_max драбина планування
sum(wall_sec) > budget_total_sec сумарний час

Кожен окремо означає, що автомат вичерпався, і вихід лише людський — mt invalidate з правкою task.md, mt kill, або engineer на предку. Це записано в тіло маркера, щоб людина, яка на нього натрапила, одразу бачила свої опції.

Де перевіряється

  • runner — перед комітом worktree, тож маркер іде тим самим fenced push, що й run. Інакше вузол на мить лишався б у стані «ще ретраїмо» з уже вичерпаною драбиною, і наступний прохід оркестратора взяв би його в роботу.
  • spawn_reject — одразу після запису відмови, поки лічильник актуальний.

Запис ідемпотентний: маркер immutable, наявний не перезаписується.

Рішення, які варто знати

budget_total_sec лишається опційним (як у спеці): не заданий — тригер неактивний. Інакше будь-який достатньо довгий вузол ставав би термінальним.

Дефолти engineer_retry_max (1) і plan_reject_max (3) — вибір реалізації: graph.md їх називає, але значень не фіксує. Позначив коментарем у config_defaults, щоб це не читалось як цитата зі спеки.

Не покрито свідомо

Алерт власнику через relay push. Потребує orchestrator-ролі й relay-шляху — це хвиля 3; рядок карти позначено ЧАСТКОВО саме через це.

Тести

7: здоровий вузол мовчить; кожен із трьох тригерів окремо; опційність третього; ідемпотентність маркера; пріоритет unresolvable над failed. 315 passed у workspace, clippy чистий.

Для паралельного треку мандатів

Це та частина, на яку спирається retry-before-escalate: тепер вузол може дійти до термінального стану, і саме тут M6 чіплятиме конверсію «вичерпана драбина → decision-request» замість алерту навмання.

🤖 Generated with Claude Code

Хвиля 2, перший пункт. graph.md: «(1) streak >= agent_retry_max +
engineer_retry_max; (2) plan-rejected >= plan_reject_max; (3)
sum(wall_sec) > budget_total_sec -> unresolvable.md + алерт». Маркер
лише читався скануванням — не писав його ніхто, тому термінальний стан
був недосяжним: вузол із вичерпаною драбиною вічно лишався failed і
його щоразу брав наступний прохід оркестратора.

Тригери навмисно різнорідні — вичерпана драбина виконання, вичерпана
драбина планування, вичерпаний сумарний час. Кожен окремо означає
«автомат більше не має ходів», і вихід лише людський.

Маркер пишеться ДО коміту worktree, тож іде тим самим fenced push, що й
run: інакше вузол на мить лишався б у стані «ще ретраїмо» з уже
вичерпаною драбиною. Другий тригер перевіряється в spawn_reject одразу
після запису відмови. Запис ідемпотентний — маркер immutable.

budget_total_sec лишається опційним (спека): не заданий — тригер
неактивний, бо інакше будь-який довгий вузол ставав би термінальним.

Дефолти engineer_retry_max (1) і plan_reject_max (3) — вибір
реалізації: graph.md їх називає, але значень не фіксує; зазначено
коментарем у config_defaults.

Не покрито: алерт власнику через relay push — потребує orchestrator-
ролі й relay-шляху, тобто хвилі 3.

Тести: 7 — здоровий вузол, кожен із трьох тригерів окремо, опційність
третього, ідемпотентність маркера, пріоритет стану над failed.
315 passed у workspace, clippy чистий.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant