A weekly retrospective, in full

/retrospective run <project-slug>

Scope: last retro-marker to now. Tier: T2, forced (the journal isn't this project's record by standing decision).

R1 sources, in authority order: action ledger -> daily plan notes -> latest handoff doc -> in-period review-log entries -> commit log since period start -> defect ledger occurrences/backlog. Transcripts only to resolve a contradiction, never to rebuild the period.

R0: every open action, last-line-wins, DONE/CARRIED/DROPPED with reason. R2: table every decision with a stated `expect`, score against it, state calibration.

Constraints: no git command that touches the index; single writer, IDE session idle. Panel: 4 lenses for a measurement-instrument project with unattended daily automation; the project's own standing rules are admissible questions. Cap: 3 new actions, R6 proposals only, no auto-apply. Stop list stands until a clean result exists.

Close: document filed, marker appended, ROTI scored, weakest part named.

Generalised and anonymised from an actual retrospective run this week on a different project, a solo-built pipeline that collects listings on a schedule, computes time-windowed outcome metrics, and publishes a small tracked dataset. Project name, person, file paths, commit hashes, and calendar dates are all removed or replaced with relative labels; the structure, the numbers, and the verdicts are real.

Frame

Weekly retrospective, tier forced by the invocation itself rather than by journal volume. Panel: facilitator plus tech lead, domain reviewer, end-user and practitioner, process archivist, five lenses against this tier's normal cap of four, justified because one finding thread cut across two lenses equally and was split so each finding stayed anchored to one. Sources: the project's action ledger (over 200 lines, zero parse failures), the event journal (zero new lines this period, by design), the commit log since the period start (roughly 30 commits, clean), the project's own review-log entries filed in the period, a data-integrity manifest file, a production log, a running defect ledger, and one older audit note with an item due this same day.

Prior actions

All fifteen non-closed items got a verdict, none skipped: six DONE, one DROPPED as superseded by a more precise replacement, eight CARRIED, zero left unaddressed. Two of the DONE items are worth naming specifically. One's stated success signal, zero count-type defects in the latest internal review, held and was checked against the real review log rather than assumed. Another had been written for exactly this scenario, a key tool going down mid-session, and this session lived that scenario for real: the fallback procedure produced a durable note naming what had been verified read-only, with no silent failure. First real test of that action, and it passed. One CARRIED item was flagged rather than just repeated: it has now gone three or more retrospectives with no due date at all, which the retro itself names as a structural problem, an item like that can't be judged on-track or overdue, because it was never given a way to fail.

Timeline

No process or structural surprises across roughly 30 commits. A tooling artefact and a first outcome-tracking result landed the same day both were specified in the prior retrospective. Across the week, a daily automated collection job ran clean every single morning. A validation tool was built and self-tested the day after. A mutation-testing sweep found roughly three dozen real coverage gaps, which were closed with genuine tests rather than padding, and the coverage baseline was recalibrated honestly upward instead of being left artificially loose. A continuous-integration pin broke and was fixed twice in one morning because an external dependency had no stable version tag. Midweek, a data-persistence redesign shipped, changing the collector so every fetched record is kept along with the decision made about it, tagged with a new schema version. The day after it shipped, the very first output line under the new schema matched its own stated expectation exactly, records persisted equalled records fetched, checked directly against the real output file rather than taken on a prior session's word. By the end of the week, a tracked outcome cell that had read zero all period recorded its first non-zero result. The event journal stayed empty the entire period, by an earlier deliberate decision that the ledger and daily notes carry this project's record instead, and this timeline was built entirely from that record without reconstructing anything from a transcript.

Decision review

Seven decisions were tabled, each with what was known when it was made and what was expected to happen. Five landed exactly as expected: an indexing approach validated on one real artefact rolled cleanly on a rerun days later; a rolling-update tool built before any real data existed passed its own safety check the first time it ran against real data; the persistence redesign's very first real output matched its stated expectation to the exact field, verified directly rather than cited from an earlier claim; a sequencing conflict flagged the previous week got reworded on schedule, this same retrospective. Two didn't land cleanly, and both are named as such rather than softened. A standing safety rule against certain operations on the working copy had already been violated twice in two earlier sessions before this period began, scored here as a bad call caught early, not excused. A freshness-check signal treated as a simple two-state flag threw one false alarm this period, a workflow-only change had tripped it, and while the immediate alarm resolved the same day, the underlying design gap, that the flag can't distinguish a real change from a cosmetic one, is still there and gets logged as its own finding rather than re-argued as a decision. Calibration: five of seven resolved decisions matched expectation exactly; no case of a good decision getting lucky, or a bad one getting away with it, either direction, this period.

What worked

Every decision this period carried a stated, checkable expectation, and every one of them was verified against a real artefact, a data file, a commit, a safety-check result, rather than a prior session's summary of it. An automated safety check added after the previous retrospective held for six straight mornings with zero false refusals, the exact failure that had cost real work the period before did not recur. And the habit of quoting the actual data-file line instead of restating an earlier claim, used throughout this retrospective's own timeline and decision review, is exactly the habit two earlier actions were written to install. It held.

Findings

An open action with no due date at all, carried three-plus retrospectives, is called out as structurally unfalsifiable, not just overdue. A second pair of open actions had been saying the same thing at two different levels of detail for a full period before this retrospective caught the overlap; nothing between retrospectives currently checks for that kind of duplication. A rollout believed solid for days turned out to have been verified this retrospective, for the first time, against the actual output file; every earlier claim about it had been citing other claims about it, not the artefact, and it held, but by good fortune rather than by design. A pending accuracy question has two days of new data behind it, enough to confirm the redesign works, not enough to decide the harder question riding on it; deciding now would repeat a known pattern of setting a threshold before its denominator is actually known, so it stays open on purpose. And the reliability of one particular tool is named plainly as the project's dominant operational risk: three separate standing actions have been born from it in the last few days alone, it recurred again during this very retrospective, and today's session proved the fallback procedure is now genuinely load-bearing rather than theoretical.

Insights

A defect pattern that had shipped once before got caught this time by an automated check before it could ship again, downgraded from a recurring risk to resolved, pending one more clean cycle before closing the matter for good. Open items with no due date, or that duplicate another item at a different level of detail, are shown to survive undetected between retrospectives, since nothing but the retrospective itself currently reads the whole ledger; a lighter, more frequent check would catch both cheaply. And the tool-reliability risk above is named as needing one real, written procedure, not three separate reminders scattered across the ledger, which is exactly what happens next.

Actions

Capped at three, cap respected. Write one canonical procedure for the "key tool is down" scenario, replacing three scattered standing reminders with a single reference, success measured by whether the next such session actually cites it instead of re-deriving the workaround. Run the next stage of the accuracy analysis now that it's unblocked, scheduled for the very next working session rather than left to drift toward its original, much later due date. Give the undated open action a real date, and fold the duplicate action into its sibling's wording at the ledger level, so neither problem is still sitting there at the next retrospective.

Meta-changes

Proposed only, nothing auto-applied. A daily-check's rule gets a reworded condition: it used to refuse whenever a manual override had already landed before the automated check ran, two days running, the new wording treats that case as a pass, since the manual step already did the job. A new backlog entry is proposed for the freshness-signal gap, flagged as the same shape as an existing defect class but a distinct instance, left as the project owner's call whether to fold it in or open a new category. And one small governance question, whether to build an enforcement tool for a documentation rule or simply keep it as an honour-system rule, is explicitly left to the owner, asked separately, not decided inside the document.

Close

All fifteen open prior actions got a verdict, every finding is anchored to a commit, a data-file field, or a ledger id, three new actions filed against a cap of three, the closing marker gets appended to the journal on save.

ROTI: 4 out of 5. This period's actions produced outcomes checked against real artefacts rather than assumed, and one previously recurring risk was downgraded on real evidence instead of optimism. One point held back on purpose: the dominant operational risk named above has now been reminded three times in three days without a single consolidated fix, and this retrospective adds a fourth reminder instead of building it, since the fix needs the owner's input on where it should live.

Weakest part, named directly: the panel ran five lenses against a nominal cap of four for this tier. Justified above. Still a cap violation, not a clean run.