boss: after the primary task, continue to autonomously-doable open follow-ups instead of stopping at a manufactured done-state #21
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Brummel/Skills#21
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
When a
/bossrun's primary task completes and its closing gate (audit /milestone fieldtest) surfaces new follow-up work, the orchestrator may file the
follow-ups as tracker issues and then stop — treating "primary task
complete" as done-state. That is a manufactured done-state: the skill defines
done-state as "queue empty AND cycle ratified" (
SKILL.mdIron Law:DONE-STATE = QUEUE EMPTY, NOT SUB-GOAL COMPLETE), and the queue was justrepopulated by the very follow-ups the run filed. The run should instead
continue onto the open follow-ups that can be done autonomously, and stop
only when the remaining queue is empty or its remaining items genuinely require
the user.
Observed instance (shape)
In a recent run (aura, the World/C21 milestone): the primary objective was a
discussed ticket sequence; the closing milestone fieldtest returned
bugs_found. The orchestrator filed the findings as new tracker issues andthen reported a done-state and stopped — while one of those freshly filed items
was a clear, fork-free bug (a panic where a clean
exit 2was required, with analready-established sibling fix pattern in the same surface). A narrow reading of
the original task's scope ("only the discussed tickets") halted the run on an
item that was plainly executable without the user.
Desired behavior
After the primary task is complete, the boss loop continues onto open follow-ups
that pass the autonomously-doable test — the direction-freedom criteria the
skill already carries:
mechanical / type edit, a test-specifiable feature);
close (a deliberate manual act), no external-service consent.
Stop (done-state, or a bounce) only when:
prioritization judgment the user reserves (e.g.
idea-labelled items, whichare droppable-by-definition), or a user-reserved act.
The discriminator is the existing direction-freedom test. The fix is that the
done-state check must route closing-gate-discovered, autonomously-doable
follow-ups back into the continue-loop rather than let "the primary ticket is
done" halt the run. Primary-ticket-complete is a sub-goal, not a done-state.
Boundary (what still stops the run)
This does not turn every follow-up into auto-work.
idea-labelled ortaste-dependent items, genuine design forks, and anything reserved to the user
(push, milestone close, external calls) still stop the run for triage. The
change is narrow: an open follow-up that is clearly and forklessly executable
is not a stopping point merely because it was discovered after — rather than
before — the primary task.
Where it lands
boss/SKILL.md— the done-state definition (Step 4 / Step 5) and§ Direction freedom. Make explicit that closing-gate-discovered follow-ups
re-enter the queue, and that the loop continues onto the autonomously-doable
subset before declaring done-state. The nuance to add over today's text: the
done-state check is not just "is the queue empty" but "is the queue empty of
autonomously-doable items" — a queue holding only user-reserved / fork /
ideaitems is a legitimate done-state; a queue holding a clear fork-freefollow-up is not.
Implemented in
52c87d1. Two calls made during implementation, beyond the issue text:A leftover design fork is a bounce-back, never a done-state. The issue's stop list ("Stop (done-state, or a bounce) only when … a real design fork, a prioritization judgment the user reserves, or a user-reserved act") left open which stop mode a fork-only residue takes. Classifying it as done-state would have collided with bounce-back triggers 1/4 and the problem-state notify, which already own exactly that condition (an actionable ask, not a wrap-up). Resolution: the done-state residue is
idea-labelled items and user-reserved acts only; a remaining fork takes the problem-state bounce, and when both kinds remain, the bounce governs. Adversarial review flagged the collision independently from two lenses (boundary, corpus-consistency).Closing-gate finding disposition is stated neutrally. audit routes drift items inline (fix path) and fieldtest routes findings to debug/planner via its spec — neither documents tracker-issue filing as its mechanism, while the observed instance did file issues (the milestone shape). The new text covers both ("routed inline or filed onto the tracker") instead of asserting filing as the mechanism, so it cannot drift against audit/fieldtest SKILL.md.