Summary
In a long /maister:development run, the orchestrator went straight from the last implementation task group to commit/push/PR, silently skipping the Phase 8 exit gate, Phase 10 (verification options) and Phase 11 (verification & issue resolution). The work shipped to a PR with no completeness check, code review, pragmatic review, production-readiness check or reality assessment.
The gates are marked mandatory and the run had honoured every earlier one (Phases 1, 2, 5, 6, 7 all gated correctly, including a spec-audit FAIL that was revised before planning). The skip happened at the implementation → verification boundary specifically.
Root cause: a name collision that is built into the skills
implementation-planner produced a plan whose last task group was:
### Task Group 14: Finalization — boost.d.ts regen & push readiness
The development orchestrator's last phase is also Phase 14: Finalization. When task group 14 finished, "finalization is done" became "Phase 14 is done", and everything between Phase 8 and Phase 14 fell into the gap. The plan even ended with "Hand over push and PR to the operator", which reads as the terminal step of the whole workflow rather than of the plan.
This is not a one-off: any plan whose last group covers regen/commit/push readiness will collide the same way, and planners naturally name that group "Finalization".
Contributing factors
- The executor's re-anchor instruction is too far away.
implementation-plan-executor → "POST-IMPLEMENTATION CONTINUATION" does say to update state and evaluate Phase 9 vs Phase 10, but it is read at skill-load time, hundreds of turns before the executor actually returns. Nothing in the hand-back itself names the next phase.
- Nothing enforces phase order at finalization. Phase 14 has a "Phase entry self-check" for the preceding gate, but no check that Phase 11 is in
completed_phases, so a jump from Phase 8 is not caught mechanically.
- "CI will verify it" absorbs the wrong scope. Phase 11's value is mostly not the test suite (which
skip_test_suite: true skips anyway) — it is code review, over-engineering detection, production readiness and completeness against the spec. Treating CI as the substitute quietly drops all of those.
- Session restart loses the phase anchor. After a restart mid-implementation, the live artifacts are the plan file and the work log, which are group-shaped.
orchestrator-state.yml has completed_phases, but nothing forces a "what phase am I in?" recomputation on resume.
- Executor Phase 3 conflicts with a common project convention. It says "Run full project test suite (all tests…)". Projects that forbid local full-suite runs (CI-only) make this step ad-hoc, which weakens the whole finalize block it sits in.
Suggested fixes
In rough order of value:
- Break the name collision. Either forbid
implementation-planner from naming a task group "Finalization" / "Push readiness" (reserve the word for orchestrator phases), or have the development orchestrator state explicitly: the implementation plan's last task group is never Phase 14; the executor returning means Phase 8 is finished.
- Make the executor's hand-back carry the next phase. Its structured return already has
status, counts, etc. Adding an explicit next_phase: "phase-8 exit gate → phase-10" puts the instruction in the returned payload rather than in a skill body read long before.
- Gate Phase 14 on state. A precondition that
phase-11 ∈ completed_phases (or an explicit user decision to skip it) turns a silent drop into a hard stop. Same shape as the existing Phase 13 precondition on Phase 12.
- Resume should recompute the phase. On resume, re-read
orchestrator-state.yml and print the current phase and the next gate before doing anything, so a restarted session re-anchors on the phase table instead of the plan file.
- Reconcile executor Phase 3 with CI-only conventions. Make the full-suite run conditional on a project setting rather than unconditional prose.
Impact
Sev: medium-high for long runs. The failure is silent — the run looks successful, the PR exists, the work log and dashboard are complete — and the missing phases are exactly the ones that would catch quality and production-readiness problems before review. The longer the implementation phase (14 task groups here, plus a session restart), the more likely the boundary is missed.
Environment
- Skills:
maister:development, maister:implementation-plan-executor, maister:implementation-planner
- Run shape: 14 task groups / 117 steps, parallel waves, one session restart mid-run
- Phases gated correctly earlier in the same run: 1, 2, 5, 6, 7 (including a spec-audit FAIL → revise → re-gate cycle)
Summary
In a long
/maister:developmentrun, the orchestrator went straight from the last implementation task group to commit/push/PR, silently skipping the Phase 8 exit gate, Phase 10 (verification options) and Phase 11 (verification & issue resolution). The work shipped to a PR with no completeness check, code review, pragmatic review, production-readiness check or reality assessment.The gates are marked mandatory and the run had honoured every earlier one (Phases 1, 2, 5, 6, 7 all gated correctly, including a spec-audit FAIL that was revised before planning). The skip happened at the implementation → verification boundary specifically.
Root cause: a name collision that is built into the skills
implementation-plannerproduced a plan whose last task group was:The development orchestrator's last phase is also Phase 14: Finalization. When task group 14 finished, "finalization is done" became "Phase 14 is done", and everything between Phase 8 and Phase 14 fell into the gap. The plan even ended with "Hand over push and PR to the operator", which reads as the terminal step of the whole workflow rather than of the plan.
This is not a one-off: any plan whose last group covers regen/commit/push readiness will collide the same way, and planners naturally name that group "Finalization".
Contributing factors
implementation-plan-executor→ "POST-IMPLEMENTATION CONTINUATION" does say to update state and evaluate Phase 9 vs Phase 10, but it is read at skill-load time, hundreds of turns before the executor actually returns. Nothing in the hand-back itself names the next phase.completed_phases, so a jump from Phase 8 is not caught mechanically.skip_test_suite: trueskips anyway) — it is code review, over-engineering detection, production readiness and completeness against the spec. Treating CI as the substitute quietly drops all of those.orchestrator-state.ymlhascompleted_phases, but nothing forces a "what phase am I in?" recomputation on resume.Suggested fixes
In rough order of value:
implementation-plannerfrom naming a task group "Finalization" / "Push readiness" (reserve the word for orchestrator phases), or have the development orchestrator state explicitly: the implementation plan's last task group is never Phase 14; the executor returning means Phase 8 is finished.status, counts, etc. Adding an explicitnext_phase: "phase-8 exit gate → phase-10"puts the instruction in the returned payload rather than in a skill body read long before.phase-11∈completed_phases(or an explicit user decision to skip it) turns a silent drop into a hard stop. Same shape as the existing Phase 13 precondition on Phase 12.orchestrator-state.ymland print the current phase and the next gate before doing anything, so a restarted session re-anchors on the phase table instead of the plan file.Impact
Sev: medium-high for long runs. The failure is silent — the run looks successful, the PR exists, the work log and dashboard are complete — and the missing phases are exactly the ones that would catch quality and production-readiness problems before review. The longer the implementation phase (14 task groups here, plus a session restart), the more likely the boundary is missed.
Environment
maister:development,maister:implementation-plan-executor,maister:implementation-planner