# 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 |
|---|---|---|---|---|---|---|
| 2026-10-27 | 9 | `DebenuLicenseKeyResolver.Resolve` walks up to 10 directories from a starting point looking for `key.txt`, and the project's own real key sits at the repo root (`g:\CSV TO PDF Project\key.txt`), one level above `code/` — well within that search path. At least two prior points concluded no key was available without searching that far: the design of `DebenuPdfRendererIntegrationTests`/`DebenuPdfRendererRotationTests` (both soft-skip with "no Debenu license key available locally" when none is found) and the Sprint 7 Sprint Review's disclosed evidence-depth caveat (no shell/build access that session, compounding rather than caused by this issue, but consistent with the same "assume no key" pattern). This sprint's own deeper search (checking the actual repo root, not just under `code/`) found the key and used it for materially deeper verification (a licensed real-DLL probe with screenshots, a licensed pixel-based clipping test, and a full end-to-end CLI render) than several prior sprints achieved. This is a real, recurring (2+ occurrence) gap in verification depth, not a one-off — meets `AGENTS.md`'s bar for a kit-level fix. | `CLI_CONTRACT.md` ("Debenu license key" section), possibly `AGENTS.md` | 2nd+ time | Proposed | Not yet applied — recommend the human product owner decide the exact wording/placement. No code change needed (the resolver's search path was always correct); the proposed fix is a documentation nudge reminding future sessions to check the actual repo root for `key.txt` before concluding no license key is available, rather than stopping the search at `code/`. Logged as Proposed per the Sprint 9 retrospective (`backlog/sprints/sprint-9-retrospective.md`), not silently edited in. |
| | | | | 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). **Revisited at Sprint 8 (2026-10-26):** the gap did not recur — this session's product-owner review had shell/build access and ran `dotnet test` directly (433/433 confirmed), plus read the actual persistence/class code rather than relying on a static count. One clean data point in the team's favor, but the underlying cause (session tooling availability) isn't within the team's control, so this stays **Watching** rather than closing; a second gap-free sprint or a clear structural reason the gap can't recur would be the bar to close it outright. |
| 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. |