T-ACX9-converge-the-post-mortem-stub-onto-the-d-0014-task-content

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

Goal

T-H7LB-task-work-appends-post-mortem-stub (#464) makes start_task.ts inject a ## Post-mortem stub into the task body at Step 5b start-time, with the stub’s structure owned by a self-contained literal in start_task.ts and mirrored by the documented three H3 headings in SKILL.md Step 8 — two sources of truth for the same shape. D-0014 (the markdown-structure-validation ADR, #455) introduces a per-type content-model contract that will validate the task H2 sequence. Once that substrate exists, the post-mortem should become a recognized member of the task contract, the contract should enforce its presence across the lifecycle, and start_task.ts should render the stub from the contract — collapsing the two (soon three) definitions of the post-mortem’s shape into one.

Today

## Post-mortem is a runtime-injected section that the task body-template never generates — the first case where a live, valid task document carries an H2 the template did not produce. Its shape lives in two places, and the D-0014 contract that would be the natural third does not exist on main yet.

Location	Role today
plugin/skills/task-work/start_task.ts	Owns the injected ## Post-mortem stub as a self-contained module-level literal (H2 + caption + three H3 subsections); appends it at Step 5b when absent.
plugin/skills/task-work/SKILL.md	Step 8 documents the same three H3 headings as the fill-time structure source — a second definition of the post-mortem shape.
plugin/lib/model/entities/task/body-template.eta	The authoring template; deliberately does NOT contain ## Post-mortem (it is start-time tooling, not authored spec).

D-0014 / B-8FL9 (the validation library + per-type content-model manifest) are not yet on main: D-0014 is open/proposed in #455 pending its spikes, and B-8FL9 is an untriaged backlog seed for the phase-1 implementation.

Proposed

The D-0014 task content-model is the single structural source of truth for the post-mortem section. It declares ## Post-mortem as an optional, trailing, recognized section (so an injected stub never trips the unpermitted-unknown- section rule at any lifecycle stage), plus a status-conditional docRule that enforces the section’s presence once a task is in-progress or closed. start_task.ts renders its stub from the contract rather than from a self-owned literal, and SKILL.md Step 8 points at the contract as the structure source — so the post-mortem’s shape is defined exactly once.

Approach

The exact manifest shape and the contract API are defined by D-0014’s phase-1 implementation (B-8FL9); these steps firm up at definition time, once that substrate lands.

1. In the D-0014 task content-model, add ## Post-mortem as an optional, trailing, recognized section (alias-free; never required as a bare presence check). This is the minimum that stops injected post-mortems from reading as unpermitted-unknown sections.
2. Add a status-conditional docRule — the same mechanism as the 20a-real-task-closed-without-completion-note example: status in the in-progress* family ⇒ ## Post-mortem present (stub-level: H2 + three H3 children); closed/* ⇒ present and filled (not just _TBD_). The rule inherits D-0014’s grandfather severity (existing corpus → report, new/edited → error), which is exactly right: every task that went in-progress before #464 merged predates the injected stub.
3. Refactor start_task.ts to render the injected stub from the D-0014 contract (the H2 + the three required H3 child headings + ordering) instead of its self-owned literal; delete the literal. Update plugin/skills/task-work/tests/start_task.test.ts to assert the rendered stub matches the contract.
4. Reword SKILL.md Step 8 so the three H3 headings reference the contract as the structure source rather than restating them — no third definition.

Files to touch

Exact paths for the contract/manifest depend on D-0014’s phase-1 shape and are pinned at definition time. The known touchpoints:

Location	Kind	Change
plugin/skills/task-work/start_task.ts	modify	Render the post-mortem stub from the D-0014 contract; remove the self-owned literal.
plugin/skills/task-work/SKILL.md	modify	Step 8: point the three H3 headings at the contract as the structure source.
plugin/skills/task-work/tests/start_task.test.ts	modify	Assert the rendered stub matches the contract; drop literal-specific assertions.

Acceptance criteria

• AC-1: The D-0014 task content-model recognizes ## Post-mortem as an optional trailing section — a task carrying an injected (or filled) post-mortem validates clean, and one without it also validates clean during definition.
• AC-2: A status-conditional docRule reports/errors (per grandfather severity) when an in-progress*/closed/* task lacks the ## Post-mortem H2 and its three H3 children.
• AC-3: start_task.ts no longer carries the post-mortem stub literal; the stub it injects is derived from the D-0014 contract, asserted by a test in start_task.test.ts.
• AC-4: SKILL.md Step 8 references the contract as the post-mortem structure source rather than independently restating the three H3 headings.

Out of scope

• D-0014’s own acceptance, spikes, and phase-1 build — owned by #455 / B-8FL9; this task consumes that substrate, it does not build it.
• Changing the post-mortem’s three-H3 schema, caption wording, or fill semantics — this task relocates ownership of the shape, it does not redesign it.
• Backfilling injected stubs into tasks that went in-progress before #464 — those are grandfathered by the docRule’s severity policy, not retrofitted.

Dependencies

• Hard dependency on D-0014 (#455) being accepted and its phase-1 implementation (seeded by B-8FL9-validate-markdown-structure-by-applying-json-schema-to-its-ast) landing the validation library + per-type content-model manifest. There is no contract to declare the section on, no docRule mechanism to enforce it, and nothing for start_task.ts to render from until that substrate exists. Recorded as related: rather than depends_on: because B-8FL9 is still a backlog item; promote to a frontmatter depends_on: link once B-8FL9 becomes the phase-1 task.
• Builds on T-H7LB-task-work-appends-post-mortem-stub (#464), which lands the injection half with the interim self-owned literal.

Discovery context

Spawned 2026-06-20 from the design discussion on #464 (T-H7LB): a template change was weighed against start-time injection, which surfaced that the post-mortem is a runtime-injected section living outside the body-template — and that D-0014’s content-model contract (#455) is where its shape and lifecycle enforcement ultimately belong.

---

← Back to Tasks