Skip to content

v2.1.29 — PDCA Predecessor-Task Completion Chain

Choose a tag to compare

@agent-kay-it agent-kay-it released this 06 Jul 00:24
· 71 commits to main since this release
76bd1af

bkit v2.1.29 — PDCA Predecessor-Task Completion Chain

A focused, cosmetic-but-real fix for the pdca skill's Task lifecycle, reported by external dogfooder @hslee-cmyk with a full reproduction (issue #137). Same task-lifecycle area as v2.1.27 (#132) and v2.1.28 (#135).

The problem

The pdca skill chains phase Tasks with blockedBy ([Plan]→[Design]→[Do]→[Check]→…), but skills/pdca/SKILL.md documented Task creation only. No step ever told the model to mark the predecessor phase Task completed when advancing — and no hook did it either. So a predecessor left in_progress (e.g. [Design] for the entire Do phase) leaked a stale phase into Claude Code's ambient prompt context on every turn, disagreeing with .bkit/state/pdca-status.json's phase field — the phase source of truth, which was correct the whole time.

Nothing functional broke (PDCA state and deliverables were always correct); the bug was purely the confusing two-sources-of-truth discrepancy the stale Task surfaced.

What changed for you

  • The PDCA task list now stays honest. When bkit advances a phase, it first marks the previous phase's Task completed — so the task list you see in Claude Code matches the actual phase at all times. No more "still in Design" signal while you're already in Do.
  • A new Phase Transition Rule in the skill's ## Task Integration section documents this explicitly, with the rationale, so it's discoverable rather than implicit.

Why we did NOT take the "auto-complete via hook" route

The issue suggested an alternative: have a hook auto-complete the predecessor Task. We verified against the official Claude Code hooks documentation that this is infeasible — command hooks communicate via stdout/exit-code/additionalContext only and cannot call TaskUpdate; only the model can. Any hook approach would still depend on the model acting on a reminder, making it no more reliable than an explicit skill instruction, only noisier. So we chose the deterministic, model-executed fix. No new hook, no new runtime surface, no dead code.

Scope & safety

  • skills/pdca/SKILL.md only. Related skills carry no multi-phase blockedBy chain (plan-plus uses a single [Plan] Task, cc-version-analysis uses subtask tracking, sprint uses per-feature Tasks) and needed no change.
  • No architecture-count or runtime-behavior change — 44 skills / 34 agents / 22 hook events / 195 lib modules unchanged. The TaskCreated/TaskCompleted audit + auto-advance handlers are untouched.
  • Regression-guarded: new test/regression/issue-137-predecessor-task-completion.test.js (25 assertions) fails if any per-transition completion instruction is removed.
  • Zero new regressions vs the main baseline (identical failing-file set); verified live via claude -p … --plugin-dir ..

Full changelog: see CHANGELOG.md. Thanks again to @hslee-cmyk for a precise, reproducible report. 🙏