Skip to content

backlog-burndown: the worktree-only disposition has no actor or timing, and its use sites disagree with it #1272

Description

@ptr727

backlog-burndown separates two worktree dispositions in "Cleanup Is the Orchestrator's": retiring a worktree alone (the branch left standing, a clean tree the whole test) and removing a worktree together with its branch (which additionally needs a branch check). The separation is stated, but the worktree-only half is under-specified and its use sites disagree with it.

  • The worktree-only disposition names a test but no actor and no timing. The full procedure gets all three, "the whole procedure moves to the orchestrator, which runs it from the base clone at the round's cleanup step", and the branch-deleting case gets an explicit failure path. All three worktree-only use sites are off-cycle, outside the round's cleanup step: "Dispatching a Worker"'s local-strict-review bullet ("its worktree is then retired", passive), "Raising a Blocked Question"'s resume-time retire, and "The Promotion Boundary" step 5's next-round-dispatch-time retire. "The Round" step 6 defines the cleanup step as covering only groups "that has finished or been abandoned", which none of those three is, so the "at the round's cleanup step" claim is crisper than the rule it now covers.
  • The new paragraph claims "Every disposition in this skill names which of the two it is", and "Raising a Blocked Question"'s "Resuming retires that worktree first, then dispatches a fresh worker" names neither. That site also removes a tree that is not clean ("apply what the answer said about its uncommitted work and then remove it"), where the paragraph states flatly that a tree that is not clean is left exactly as it stands. Either that site names its disposition and states its exception, or the universal claim goes.
  • In "Dispatching a Worker"'s local-strict-review bullet, "its worktree is then retired, the branch left standing, since git refuses to attach that branch anywhere else while the reporting tree holds it" attaches the since clause to the wrong half: it is the reason the worktree must be retired, not the reason the branch is left standing. The real reason is the next sentence.
  • The same bullet gives two opposite defaults for one state. "A clean tree is retired and the group re-dispatched to a seat that can dispatch. A dirty one is left exactly as it stands and the group stopped for the maintainer, as is a group for which no seat that can dispatch exists." A clean tree with no dispatching seat is covered by both halves and resolves only by leaving the unit.
  • "The Promotion Boundary" step 5 retires the holder's worktree unconditionally, with no test and no failure path, where a holder yielding a file is the case most likely to hold uncommitted edits to that very file.
  • Step 5 also enumerates only a parked holder and a pushed holder. A stopped group also "keeps its branch and its claim", and "Raising a Blocked Question" leaves its worktree "exactly as it stands while the question is open", which is the opposite of step 5's retire. A promotion fix needing a stopped group's file has no rule, and the two that could apply contradict.
  • "Raising a Blocked Question" says "This is the same retire-then-dispatch shape 'Bounding the Wait on a Worker' uses", and that section removes the tree and its branch and returns the issue to ranking rather than dispatching onto the same branch. The retire-then-dispatch shape lives in "Dispatching a Worker"'s local-strict-review bullet.

Raised by the local-strict-review carried-content passes on the pull request that added this skill, and deferred there under that skill's own review-round budget.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    proseA defect in rule or procedure textskillsAgent skill

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions