Skip to content
sdlc

T-E4ZB-clarify-out-of-scope-requirement

Status: closed/done · Impact: low · Complexity: small

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

Goal

Section titled “Goal”

plugin/entities/task/implementation-ready.md says Out of scope is required “only when the surrounding scope is non-obvious,” but the task-ensure-ready evaluator effectively treats it as required. The two readings should agree. Picking one — and updating the evaluator and contract prose to match — removes a class of false positives / false negatives in readiness checks. Surfaced during T-T5RB-consolidate-task-status-enum.

Today

Section titled “Today”

“The implementation-ready contract requires an Out of scope section ‘only when the surrounding scope is non-obvious.’ The task-ensure-ready evaluator currently treats it as effectively-required (it caught this task because the spec includes one). Two reasonable readings of the contract — worth disambiguating in implementation-ready.md.”

The contract prose is intentionally fuzzy; the evaluator is binary. A task author following the literal contract may omit the section and fail readiness anyway.

Proposed

Section titled “Proposed”

The contract states unambiguously whether Out of scope is required, conditionally required, or optional. The evaluator implements the same rule. If the rule is conditional, the contract spells out the condition in a way the evaluator can implement deterministically.

Approach

Section titled “Approach”
  1. Adopt the policy: Out of scope is always required, with - none as a valid value when scope is obvious. This matches the existing evaluator behavior and removes ambiguity.
  2. Update plugin/entities/task/implementation-ready.md to state the policy unambiguously: remove the “only when the surrounding scope is non-obvious” qualifier; add the - none-allowed note.
  3. Update plugin/skills/task-ensure-ready/SKILL.md if its evaluator-language wording differs from the new contract text.
  4. Update plugin/entities/task/template.md so the seeded ## Out of scope section pre-populates - none (instead of the current “Delete this section if scope is obvious” instruction).

Files to touch

Section titled “Files to touch”
  • plugin/entities/task/implementation-ready.md — clarify the Out of scope rule.
  • plugin/skills/task-ensure-ready/SKILL.md — align evaluator language.
  • plugin/entities/task/template.md — seed - none if policy becomes “always required.”

Acceptance criteria

Section titled “Acceptance criteria”
  • AC-1: plugin/entities/task/implementation-ready.md contains exactly one binding statement about Out of scope (required, conditional with specified condition, or optional).
  • AC-2: A task that follows the literal contract text passes the task-ensure-ready evaluator on first run, with no surprise downshifts attributable to the Out of scope section.

Out of scope

Section titled “Out of scope”
  • Reforming any other contract section. This task is narrowly about the Out of scope rule.

Dependencies

Section titled “Dependencies”
  • none

Discovery context

Section titled “Discovery context”

Spawned by /sdlc:task-work post-mortem of T-T5RB-consolidate-task-status-enum on 2026-05-19.

Post-mortem

Section titled “Post-mortem”

Captured by /sdlc:task-work on 2026-05-21. PR: pending.

Acceptance criteria coverage

Section titled “Acceptance criteria coverage”
  • AC-1: agent-manual — command grep -n "Out of scope\|always required" plugin/entities/task/implementation-ready.md confirms exactly one binding statement (“always required”) in the rewritten bullet.
  • AC-2: auto — /sdlc:task-ensure-ready re-stamped this task as READY against the updated contract; the contract-and-evaluator agreement is now structural (the evaluator delegates literally to the contract prose, which is the only authoritative source).

What worked

Section titled “What worked”
  • Task spec was tight: three files named, one policy decision already pre-made in the Approach. No design clarification needed — went straight from gate-pass to implementation.
  • Quality checks (6/6) caught nothing because the change is prose-only; the schema/validator regression surface was zero.

Friction and automation gaps

Section titled “Friction and automation gaps”
  • Step 5b rebase surfaced a last_reviewed conflict because Step 5a committed the readiness stamp on the feat branch with the old last_reviewed: '2026-05-20', while Step 5b’s main commit updated it to '2026-05-21'. The two stamps then collided on rebase — task-work either needs to update last_reviewed in 5a too, or 5b’s rebase should know last_reviewed is monotonic and auto-prefer the main side. → T-H98A-last-reviewed-rebase-collision

Spawned follow-up tasks

Section titled “Spawned follow-up tasks”

← Back to Tasks