Skip to content
sdlc

T-Z3ZZ-task-work-defers-status-flip-until-ensure-ready

Status: closed/superseded · Impact: medium · Complexity: small

Auto-generated from a /sdlc:task-work post-mortem. Review and promote to ready before picking up.

Goal

Section titled “Goal”

/sdlc:task-work currently sets status: in-progress in Step 3 and then invokes /sdlc:task-ensure-ready in Step 5. The implementation-ready contract disqualifies in-progress from the readiness gate, so strict contract application makes the skill self-defeating: ensure-ready would always downshift the task back to proposed/needs-definition and stop the run. Closing this gap makes task-work safe to run start-to-finish under the strict contract. Cited by T-J2CW-add-epic-entity-task-depends-on-dependencies (and previously by T-3A6G-implement-entities-migrate).

Today

Section titled “Today”

From the originating post-mortem:

/sdlc:task-work step 3 sets status: in-progress BEFORE step 5 invokes /sdlc:task-ensure-ready. The implementation-ready contract (plugin/entities/task/implementation-ready.md) explicitly disqualifies in-progress — so strict contract application makes task-work self-defeating (every invocation would downshift to proposed/needs-definition and stop). Applied the pragmatic interpretation here.

The same friction was independently logged in T-3A6G-implement-entities-migrate’s post-mortem — the orchestrator “had to skip Step 5” because re-running ensure-ready after Step 3 would have corrupted verified state.

Implementation-ready contract: plugin/entities/task/implementation-ready.md — disqualifies status: in-progress.

Skill: plugin/skills/task-work/SKILL.md — Step 3 flips status, Step 5 invokes ensure-ready.

Proposed

Section titled “Proposed”

/sdlc:task-work runs ensure-ready BEFORE flipping the task to in-progress. Concretely: Step 5 (or equivalent readiness gate) executes against the original status; only after it passes does the skill stamp status: in-progress. Alternative resolution: ensure-ready tolerates in-progress when a recent readiness_verified_at is present. Pick one; the sub-agent that authored the gap leaned slightly toward reordering task-work since it keeps the contract narrow.

Approach

Section titled “Approach”
  1. Decide between “reorder task-work” vs “ensure-ready tolerates in-progress when readiness_verified_at is fresh”. Default: reorder task-work — it keeps the readiness contract a pure pre-condition.
  2. Reorder plugin/skills/task-work/SKILL.md so ensure-ready runs against the pre-flip status; move the status: in-progress write to immediately after ensure-ready returns success.
  3. Smoke-test by running /sdlc:task-work against a real ready task and confirming no downshift occurs.

Files to touch

Section titled “Files to touch”
  • plugin/skills/task-work/SKILL.md — reorder Step 3 and Step 5; the status flip becomes a post-condition of the readiness gate.
  • (Maybe) plugin/entities/task/implementation-ready.md — only if we pick the alternative resolution.

Acceptance criteria

Section titled “Acceptance criteria”
  • AC-1: A clean run of /sdlc:task-work against a status: ready task no longer downshifts it to proposed/needs-definition, with the implementation-ready contract applied strictly.
  • AC-2: The skill’s documented step order makes the readiness gate precede the status flip; nothing in the skill body still implies ensure-ready can run against in-progress.

Out of scope

Section titled “Out of scope”
  • Adding a readiness_verified_at time-window check to ensure-ready (an alternative path, deliberately deferred).
  • Other ordering bugs in /sdlc:task-work (e.g. branch-check before pull, flagged in T-3A6G-implement-entities-migrate).

Dependencies

Section titled “Dependencies”
  • none

Discovery context

Section titled “Discovery context”

Spawned by /sdlc:task-work post-mortem of T-J2CW-add-epic-entity-task-depends-on-dependencies on 2026-05-19.

← Back to Tasks