Add a debrief step to the os-sdlc implementation process #921

New issue

Open

opened 2026-10-03 12:41:37 +00:00 by jared · 1 comment

jared commented

2026-10-03 12:41:37 +00:00

Owner

Problem

The os-sdlc implementation process has no step that lists what a shipped diff also changes or leaves unverified beyond the ticket. Ticket #860 showed five such effects: a class-level option (check_unknown_options!) that changed a sibling command, an untested effect (dispatch_refusing_bad_switches), a test that became a subprocess, a stale comment, and useless help flags. Jared's rule: "Every ticket that is implemented should make the codebase incrementally better in some way, without any regression."

Reproduce

n/a: design ticket; the evidence is the review of #860 on 2026-10-03.

Approach

Add a debrief step after the final implementation step and before commit or merge. The step lists what the diff also changes or leaves unverified beyond the ticket. Each finding results in a revision of the current ticket when it weakens the code, or in a derivative ticket when it does not.

Open points that need Jared's ruling:

Heuristics for "weakens", "hardens", and "regression".
Where the step lives. ADR-0046 and ADR-0234 apply to the related drain-step decision. See docs/handoffs/2026-10-02-challenge-moves-and-derivative-tickets.md and docs/research/challenge-moves/prediction-scores.md.

Required work: none beyond the acceptance criteria.

Acceptance criteria

Given Jared has ruled on the open points, when this ticket is decomposed, then it states the heuristics, the step location, and the ADR needed.

Origin

Trigger: review of closed ticket #860 with Jared, 2026-10-03; Jared proposed this step.
Improvised this session: none.
Chain: unreviewed side effects shipped in #860 ← no post-implementation debrief ← DESIGN (docs/handoffs/2026-10-02-challenge-moves-and-derivative-tickets.md).
Root candidate: the drain-step decision (#918).
Where: os-sdlc implementation process (plugins/os-sdlc)
Session: a0dbd5c4-ce77-4eaa-bb8a-9517044ae3ad (capture session; the review session ID was not available)
Transcript: /home/jared/.claude/projects/-home-jared-dev-cc-os/a0dbd5c4-ce77-4eaa-bb8a-9517044ae3ad.jsonl

## Problem The os-sdlc implementation process has no step that lists what a shipped diff also changes or leaves unverified beyond the ticket. Ticket #860 showed five such effects: a class-level option (`check_unknown_options!`) that changed a sibling command, an untested effect (`dispatch_refusing_bad_switches`), a test that became a subprocess, a stale comment, and useless help flags. Jared's rule: "Every ticket that is implemented should make the codebase incrementally better in some way, without any regression." ## Reproduce n/a: design ticket; the evidence is the review of #860 on 2026-10-03. ## Approach Add a debrief step after the final implementation step and before commit or merge. The step lists what the diff also changes or leaves unverified beyond the ticket. Each finding results in a revision of the current ticket when it weakens the code, or in a derivative ticket when it does not. Open points that need Jared's ruling: - Heuristics for "weakens", "hardens", and "regression". - Where the step lives. ADR-0046 and ADR-0234 apply to the related drain-step decision. See docs/handoffs/2026-10-02-challenge-moves-and-derivative-tickets.md and docs/research/challenge-moves/prediction-scores.md. Required work: none beyond the acceptance criteria. ## Acceptance criteria 1. Given Jared has ruled on the open points, when this ticket is decomposed, then it states the heuristics, the step location, and the ADR needed. ## Origin - Trigger: review of closed ticket #860 with Jared, 2026-10-03; Jared proposed this step. - Improvised this session: none. - Chain: unreviewed side effects shipped in #860 ← no post-implementation debrief ← DESIGN (docs/handoffs/2026-10-02-challenge-moves-and-derivative-tickets.md). - Root candidate: the drain-step decision (#918). - Where: os-sdlc implementation process (plugins/os-sdlc) - Session: a0dbd5c4-ce77-4eaa-bb8a-9517044ae3ad (capture session; the review session ID was not available) - Transcript: /home/jared/.claude/projects/-home-jared-dev-cc-os/a0dbd5c4-ce77-4eaa-bb8a-9517044ae3ad.jsonl

jared added the

plugin/os-sdlc

filed-by/user

labels

2026-10-03 12:41:37 +00:00

jared commented

2026-10-03 13:54:32 +00:00

Author

Owner

Additions from Jared, 2026-10-03, while he scored #907 (session a0dbd5c4).

Debrief check: test coverage of likely states. The debrief asks which states of the changed behavior are likely and whether each has a test. It does not ask for obscure states (no speculative hardening, YAGNI). Example from #907: the new tests covered a staged deletion but not a deletion that is not staged. If that state is likely, the finding is worth one more test-reviewer to test-writer cycle. Jared ranks this lower in importance. He expects the test-reviewer and the test-writer to ask this question themselves.
Live runs. Many tickets close with no live run. Jared does not want open tickets that only wait for a live run to fill the queue. His proposal: label each ticket that needs a live run waiting/live-run, with its live-run close criteria. In the debrief (or the final step of the take-down process), when the take-down included a live run, compare the waiting/live-run tickets with their criteria and close each satisfied ticket with evidence.
ADR challenge. When an ADR is the reason that the obvious correct answer was avoided, the debrief or the challenge step challenges the ADR, in the same way as a lens challenge. Jared suspects that an ADR which prescribes structure (for example a specific git verb) prevents good code, and that such an ADR must be discarded or revised.

Additions from Jared, 2026-10-03, while he scored #907 (session a0dbd5c4). 1. Debrief check: test coverage of likely states. The debrief asks which states of the changed behavior are likely and whether each has a test. It does not ask for obscure states (no speculative hardening, YAGNI). Example from #907: the new tests covered a staged deletion but not a deletion that is not staged. If that state is likely, the finding is worth one more test-reviewer to test-writer cycle. Jared ranks this lower in importance. He expects the test-reviewer and the test-writer to ask this question themselves. 2. Live runs. Many tickets close with no live run. Jared does not want open tickets that only wait for a live run to fill the queue. His proposal: label each ticket that needs a live run `waiting/live-run`, with its live-run close criteria. In the debrief (or the final step of the take-down process), when the take-down included a live run, compare the `waiting/live-run` tickets with their criteria and close each satisfied ticket with evidence. 3. ADR challenge. When an ADR is the reason that the obvious correct answer was avoided, the debrief or the challenge step challenges the ADR, in the same way as a lens challenge. Jared suspects that an ADR which prescribes structure (for example a specific git verb) prevents good code, and that such an ADR must be discarded or revised.

jared added the

category/owner-ruling

label

2026-10-10 13:31:50 +00:00