CSV_TO_PDF_REPORT/logs/process_improvement_log.md

Process Improvement Log

Append-only log of insights about the Scrum kit itself (this repo's process/, templates/, .claude/agents/, or AGENTS.md) — as distinct from insights about how one team works, which stay in that sprint's retrospective and plan. Maintained by .claude/agents/scrum-master.md per process/07_process_improvement.md. Do not delete entries once applied or rejected — mark status instead.

Date	Sprint	Insight	Affected file(s)	Recurrence	Status	Resolution
				1st time / 2nd time / 3rd+	Watching / Proposed / Applied / Rejected
2026-09-22	3	Sprint 3's product-owner sprint review leaned more heavily on dev-team's own pre-written verification notes in backlog/epics/03_csv_integration_and_field_mapping.md (already written in a “Sprint Review verification” style before the review step ran) than in prior sprints, where epic notes were written fresh by product-owner at review time. No AC was actually missed and the one story without a pre-written note (the throughput story) received a fully independent product-owner confirmation that added real judgment, so this has not yet caused a defect — but if epic-note authorship keeps drifting from “PO writes it at review time” toward “dev-team writes it, PO signs it,” the review step's independence could erode unnoticed. Logged now as a first-occurrence watch item per AGENTS.md's bar, not yet severe or recurring enough for a kit edit.	process/04_sprint_review.md, .claude/agents/product-owner.md	1st time	Resolved	Revisited at Sprint 4 review/retrospective (backlog/sprints/sprint-4-retrospective.md, “Follow-up on previous retro's actions” item 4): this sprint, dev-team was explicitly instructed not to write or touch epic “Status:"/verification content, and product-owner wrote all three Sprint 4 stories’ Sprint Review verification notes fresh and independently — citing dev-team's evidence but forming its own judgment on it (e.g. explicitly assessing whether a flagged sizing-note risk was “genuinely resolved rather than papered over,” not just restating dev-team's own framing). The concern never caused an actual missed AC in either sprint, and this sprint's structural separation of “who implements and self-verifies” from “who writes the Sprint Review's AC verification” resolves it without needing a process/04_sprint_review.md edit. Closed; no kit change made. Re-open as a new entry if this drifts back in a future sprint rather than reusing this row.
2026-10-19	7	Product-owner's Sprint 7 review session had no shell/build tool access, so it substituted an independent static count of [Fact]/[Theory]/[InlineData] attributes across test files (landed on exactly 400, matching dev-team's reported 400/400) and direct source-code reading in place of an actual dotnet test run and a live re-run of dev-team's built-.exe screenshots. Disclosed explicitly by product-owner as “a review-process limitation ... not a defect in the sprint's delivery,” not smoothed over. The top-level session independently ran dotnet test afterward and confirmed 400/400 exactly, so this did not produce a wrong verdict this time. Distinct from the 2026-09-22 (Sprint 3) PO-review-independence entry below: that item was about whether PO forms independent judgment versus leaning on dev-team's pre-written narrative (resolved structurally at Sprint 4); this item is about PO's tooling access to actually execute a build/test pass, which is a different failure mode and not yet resolved by any structural change. First occurrence of this specific shape — logged now per AGENTS.md's bar (not yet severe or recurring), not folded into the closed Sprint 3 entry.	process/04_sprint_review.md, .claude/agents/product-owner.md	1st time	Watching	Sprint 7 retrospective (backlog/sprints/sprint-7-retrospective.md) carried forward a Sprint 8 action: if product-owner again lacks shell/build access, disclose it and arrange an independent cross-check, as done this sprint. Revisit at Sprint 8 review/retrospective; if this recurs with a mismatched result (not just a missing capability), it would meet the bar for a kit edit (e.g., a process/04_sprint_review.md note requiring an explicit disclosure + follow-up cross-check whenever PO verification can't execute a build/test pass).
2026-09-11	1	templates/definition_of_done.md's “runnable in the current local development setup” bar let two GUI-launching stories (Sprint 1 Batches 4-5, “Launch a text-only render from the desktop app” and “Show render progress and completion summary”) reach Done using an in-process/dev-shell test harness that never exercised the actual built artifact the real target user (an operator double-clicking a shipped .exe) would run. This let a real bug (Debenu error 999 — the CLI only read its license key from a process environment variable a double-clicked app never has) through both DoD sign-off and past state.md advancing to Phase 4, only caught same-day by a real user report, not by the sprint's own verification. Judged severe enough on its own (per AGENTS.md's “Process Self-Improvement” bar — a single occurrence that visibly broke a Done story's core happy path for the target user) to log now rather than wait for a second occurrence, though scrum-master should confirm at the retrospective before any kit edit is proposed.	templates/definition_of_done.md (possibly process/03_sprint_execution.md's verification guidance)	1st time	Applied	Decided at the Sprint 1 retrospective (backlog/sprints/sprint-1-retrospective.md, “Kit-level decision” section): this single occurrence meets the severity bar (silently broke a Done story's core happy path for the actual target user and let state.md advance to Phase 4 undetected). User approved the proposed edit on 2026-09-11; applied to templates/definition_of_done.md as a new bullet immediately after the existing “runnable in the current local development setup” line: “If the story changes how the product is launched, packaged, or resolves runtime configuration (e.g., a new desktop entry point, a new child-process launch, a new license/config resolution path), verification includes running the actual built artifact the way the target user would run it — not only an in-process test harness or a dev-shell invocation such as dotnet run.” Scoped only to launch/packaging/config-resolution stories, not all stories.