Skip to content

title: Re-validate Deferral Criterion Before Re-Activating Deferred Scope date: 2026-05-20 spec: SPEC-142 related: [SPEC-122] tags: [workflow, spec-management, scope-shaping, deferral, re-activation, evidence-based-scoping] category: patterns module: core-standards problem_type: process resolution_type: pattern severity: medium symptoms: - A deferred spec is re-activated with the original (pre-deferral) scope intact - "Why was this deferred?" answer is the same as when the deferral was made - Strategic review on the original scope yields the same NEEDS REVISION verdict it would have at deferral time - Original 3+ task scope still costs new SKILL.md, new plugin.json edits, new symlinks, new fan-out surface

Re-validate Deferral Criterion Before Re-Activating Deferred Scope

Problem

A spec defers a sub-scope on evidence grounds — "n=1 incident, no PM friction report yet, defer until evidence accumulates." Days or weeks later, the deferred sub-scope is re-activated as a follow-up spec. The natural move is to lift the original task definitions verbatim from the parent spec's deferred-tasks section and start building.

Failure mode: the evidence that triggered deferral is still unchanged. n=1 yesterday, n=1 today. The original scope was deferred precisely because building it at this evidence level was wasteful — yet re-activation skips that check and rebuilds the same wasteful surface.

Example (SPEC-142)

  • SPEC-122 Wave 1 (shipped 2026-05-19): Bug-Domain field + Open Bugs section in dashboard. n=1 bug in the toolkit (BUG-001), no PM friction reports.
  • SPEC-122 Wave 2 deferral: Strategic review during /vt-c-3-build flagged US-3 detail-skill as premature. Deferred to SPEC-142 with task definitions T13–T15 (new standalone /vt-c-pm-bugs skill + footer cross-link + integration test).
  • SPEC-142 first activation (2026-05-20): scope was carried over verbatim — 3 tasks, new SKILL.md, plugin.json edit, new symlink-manifest line, footer mutation in Wave 1 surface.
  • Second /vt-c-shape pass: product-challenge-reviewer flagged "n=1 evidence base unchanged — same deferral criterion still applies. Cheaper alternative satisfies US-3."
  • Pivot: scope shrank to a single --with-bug-bodies flag on the existing aggregate.sh script. ~30 lines, one test, no new SKILL.md, no plugin.json edit, no symlinks-manifest churn, no Wave 1 footer mutation.

Solution: re-run the original deferral criterion FIRST

When activating a spec that was deferred on evidence grounds, before any planning step:

  1. Locate the original deferral rationale. Read the parent spec's scope_history, decisions.md, or the deferral commit message. Extract the criterion in literal form: "deferred because n=1 incident" / "deferred until at least one PM friction report" / "deferred pending second observed case."
  2. Test the criterion against current evidence. Has it changed? n was 1 — is n still 1? Has a friction report or second incident landed in intake/? Has a PM logged the use case anywhere?
  3. Branch on the answer:
  4. Criterion still holds (evidence unchanged) → scope should shrink toward the minimum-viable surface. The deferred-but-still-cheap alternative beats the deferred-original blueprint. Pivot during /vt-c-shape, archive the original scope as a decisions-v1-*-superseded.md sibling, preserve the option to re-expand if re-open triggers fire later.
  5. Criterion has changed (evidence accumulated) → original scope may now be justified. Re-shape with the new evidence in scope_history and proceed.
  6. Encode re-open triggers in the new spec. Even when pivoting to a smaller scope, write down the evidence threshold that would justify the original scope. ("Re-open when: (a) second cross-cutting bug appears, OR (b) PM logs aggregate.sh --with-bug-bodies is insufficient for a real meeting.") This keeps the deferred-original option recoverable without re-litigating the framing.

Guard

The second /vt-c-shape strategic pass with product-challenge-reviewer is the structural place to catch this. Encode the question into shape-review prompts: "Was this scope previously deferred? If so, has the deferral criterion been revisited against current evidence?"

When the pattern does NOT apply

  • Spec was deferred on capacity grounds, not evidence grounds ("we have no time this sprint"). Capacity changes independently — no re-evidence check needed.
  • Spec was deferred to wait on an upstream dependency. Check dependency status, not user-evidence accumulation.
  • Original spec was deferred wholesale (not a sub-scope split). This pattern is specifically about re-activating a carved-out sub-scope; full-spec deferrals are simpler — re-validate the whole framing in /vt-c-shape as usual.

Compounding effect

Pairs with wave-independent-shipping.md (which handles the Wave 1 / Wave 2 split mechanics) and three-pass-spec-validation.md (which handles merit/strategic/ground-truth coverage). This pattern targets the specific transition moment between waves — the highest-risk point for scope creep, because the original blueprint is sitting in the parent spec's deferred-tasks section, ready to be lifted.

Reference

  • SPEC-142 spec.md scope_history records the 2026-05-20 reshape.
  • specs/142-pm-bugs-detail-skill/decisions-v1-pm-bugs-skill-superseded.md preserves the original 3-task design in full.
  • SPEC-122 Wave 2 deferral decision is in specs/122-prioritisierbare-spec-task-pipeline/tasks.md Phase 6 commentary.