Skip to content

T-WZ5O-post-mortem-evidence-reproducibility

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

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

When /sdlc:task-work spawns a follow-up task from a post-mortem friction bullet whose evidence is a single observed incident, the resulting spec often implies the failure is universal. If the bug is actually intermittent (e.g. depends on commit-content overlap, race windows, or environment shape), the implementer can spend a full investigation cycle failing to reproduce before realizing the spec overstated reliability. Motivating example: T-N2X3-start-task-preserves-readiness-stamp was spawned from a single observed incident but framed as universal; the implementing run could not reproduce the failure because it was conditional on commit-content overlap the spec didn’t name.

LocationRole today
apps/sdlc/lib/model/entities/task/spawn-from-post-mortem.mdstep 5 briefs /sdlc:spawn-task-pr on the spawned task’s body content (Goal brief plus dedup audit trail); no reproducibility-tier requirement
apps/sdlc/skills/task-work/SKILL.mdStep 8 dispatches the sub-agent that executes that procedure

The originating bullet reaches the spawned task only through the Goal brief and the dedup block, and a single bullet often doesn’t carry the “I saw this once” vs “this happens every time” distinction.

Spawned tasks carry an explicit reproducibility tier as a labeled Reproducibility: <tier> line in the ## Today section. A labeled prose line keeps authoring friction low while staying greppable for automated checks; a frontmatter field would need a task-schema change this task doesn’t warrant. Three tiers:

  • reliable — the bullet describes a deterministic failure path reproducible from a clean checkout following the steps named in the bullet.
  • intermittent — the failure was observed but depends on conditions the bullet doesn’t fully name (commit-content overlap, timing, environment).
  • single-incident — observed once; the cause is hypothesized but not yet pinned down.

An implementer reading the new task sees the tier up front and adjusts investigation scope accordingly.

  1. Update apps/sdlc/lib/model/entities/task/spawn-from-post-mortem.md step 5 to require a Reproducibility: <tier> line in the spawned task’s ## Today section. Update the Step 8 sub-agent dispatch in apps/sdlc/skills/task-work/SKILL.md accordingly.
  2. Optionally add a task-ensure-ready check that flags spawned tasks missing the tier (only fires when the originating-task link is present, i.e. the task came from a post-mortem).
LocationKindChange
apps/sdlc/lib/model/entities/task/spawn-from-post-mortem.mdmodifyrequire a Reproducibility: <tier> line in step 5’s body-content brief
apps/sdlc/skills/task-work/SKILL.mdmodifycarry the tier requirement in the Step 8 sub-agent dispatch
apps/sdlc/skills/task-ensure-ready/SKILL.mdmodifyoptional: flag post-mortem-spawned tasks missing the tier
  • AC-1: apps/sdlc/lib/model/entities/task/spawn-from-post-mortem.md step 5 requires the spawned task to label evidence as one of reliable, intermittent, or single-incident.
  • AC-2: A spawned task missing the tier is detectable by automated inspection — either via a test fixture in apps/sdlc/skills/task-work/tests/ or via task-ensure-ready surfacing a definition gap.
  • Retroactively labelling existing spawned tasks.
  • Tracking reproducibility on tasks that did NOT come from a post-mortem.
  • A frontmatter reproducibility: field and the task-schema change it would require.
  • none

Spawned by /sdlc:task-work post-mortem of T-N2X3-start-task-preserves-readiness-stamp on 2026-05-21.

The spawn-time dedup search found no overlapping open task (all top candidates were closed/done). Decision: SPAWNED.


← Back to Tasks