Postmortem

/calibrate works in aggregate, and it requires that any anchor change "name the tickets in the PR description". This skill produces that per-ticket evidence: for one finished ticket, which estimate lines were priced from which anchor row, how much time actually went into each, and which rows the result argues against.

Redmine records time per ticket per day, never per line. So the per-line split is reconstructed: the ticket branch's commits say which lines the development time went into, and the developer who did the work confirms or corrects it. The write-up marks every number as either measured from git or judged by the developer. A postmortem that hides which is which is not evidence.

0. Preflight

rmine whoami

You need the product repo with the ticket's committed estimates/estimate-<id>.md, and the ticket branch available locally. No estimate file means there is nothing to hold the work against; say so and stop.

1. Only finished work

rmine issue view <id> -o json

Run on a ticket whose development is over: a closed status, or one whose name says the work shipped (for example Deployed, Verified or QA Completed). Ask when a status could mean either. An in-flight ticket makes every line look under, and a rubric PR built on it would lower anchors for no reason.

If the user wants it anyway, go ahead, but the write-up is marked PARTIAL in its header and summary, and says it must not be cited in a rubric PR.

2. Line up the estimate against the branch

python3 "${CLAUDE_PLUGIN_ROOT}/skills/postmortem/scripts/attribute.py" \
  --estimate estimates/estimate-<id>.md --repo <product repo> --json

It finds the one local branch that names the ticket. When the work is split across branches, a backend and a frontend one for example, pass --branch once for each; a commit two of them share counts once. Each branch is measured from where it left develop, main or master; when it was cut from something else, such as a release branch, pass that as --base, or that branch's own commits read as this ticket's work.

The script:

• parses the estimate's priced leaf lines, each with its section and any Anchor: row under it;
• takes each ticket branch's own commits (first-parent, merges excluded), keeps those by the people who logged time on the ticket and made after the estimate's Date:, and reports how many others it dropped;
• matches each changed file to the lines that name it (Cdw::Mappers::UkRecordMapper → cdw/mappers/uk_record_mapper.rb, a spec path to that spec);
• splits the logged Development hours across lines by each line's share of commit activity, in 0.25h steps that sum exactly to the Development total.

Other activities (Design, Peer Review, Testing) come back as their own totals, along with every time entry's date, hours and comment.

3. Resolve what git couldn't

Ask the developer who did the work (the one who logged the Development time), in one round:

• Unmatched files. Code rarely keeps the names an estimate used — PcbRecordMerger shipped as UkRecordConsolidator. For each unmatched file, which line it belongs to, or none (scope that wasn't in the estimate, which is itself a finding). Rerun with --assign <file-or-glob>=<line>.
• Lines git can't see. Demo, PR reviews and discussions make no commits. Use the non-Development activity totals and the time-entry comments ("Development completed and demo") to propose hours, and have the developer settle them.
• Estimating time. Time logged for reading the spec and writing the estimate is not work the estimate priced. Keep it out of the line comparison and report it on its own.
• How the work was actually done. Agent-driven (an agent wrote most of the code) or hand-written, whatever the estimate's Mode: assumed. The anchor rows are read in the column for the mode the work used; a mismatch with the estimate's mode is a finding of its own.

4. Confirm the split

Show one table: line, section, anchor, estimated, proposed actual, and whether the number is measured (git share, unchanged) or judged (set or changed by the developer). Ask the developer to confirm it with AskUserQuestion; any line they change becomes judged. The per-line actuals must add up to the logged work time, less estimating time; if they don't, say where the difference is.

5. Read the anchors

For each line with an Anchor: row, compare the confirmed actual against the anchor's range in the rubric column for the mode the work used, not just the line's estimate:

• inside the range: the row held, whatever the line's estimate was;
• outside it: the row looks wrong for this kind of work, and the line is evidence against it;
• lines with no anchor are judgment calls, and say nothing about the rubric.

One ticket is one data point. Never recommend changing a row from a single postmortem. Say what would make it evidence: the same row outside its range across several postmortems, linked together in a rubric PR as /calibrate requires.

6. Write it up

Write postmortems/postmortem-<id>.md in the product repo, next to estimates/ and never inside it: /calibrate reads every file in estimates/, and a postmortem there would be counted as a second estimate for the ticket.

Task: <subject>
Redmine: <url>
Estimate: estimates/estimate-<id>.md (<estimate date>, by <estimator>)
Postmortem: <today>, confirmed by <developer>
Status: <status>   [PARTIAL: ticket still in progress; not for rubric PRs]
Mode: estimated <mode>, work done <agent-driven|hand-written>

Summary: estimated <E> hrs, logged <L> hrs of work (<activities>), plus <S> hrs estimating.

Lines:
| # | Line | Anchor | Est | Actual | Basis |

Anchor rows (<mode> column):
- <row> (<range>): actual <A> — inside / outside the range

Scope not in the estimate: <files or work, with hours>

Method: <N> commits on <branch> (against <base>)[, <branch> ...] since <date> by <authors>; <M> dropped.
Assigned by the developer: <file → line>.

Keep the Mode: line and the Anchor rows lines in exactly that shape, with each row named as the rubric's table names it: scripts/rollup.py reads them, and a row it can't match is listed as missing rather than counted.

Tell the user to commit it. A postmortem that isn't committed can't be linked from the rubric PR it exists to support.

7. Roll up

One postmortem never moves a row; the same row across several does. After writing one, or whenever someone is preparing a rubric PR, roll up every committed postmortem:

python3 "${CLAUDE_PLUGIN_ROOT}/skills/postmortem/scripts/rollup.py" postmortems/

For each anchor row it lists the actual hours from every postmortem, grouped by the mode the work used, against that mode's column in the rubric as it stands today. A row becomes a candidate for a rubric PR when three or more postmortems put it outside its range, all on the same side (--min changes the three). The PR quotes those lines and links the postmortems. PARTIAL postmortems are never counted, and ones with no Mode: line are listed without a verdict until the line is added.

The Agent-driven column's judgment rows are the ones waiting for this: each measurement the roll-up shows for one is the first evidence that row has.