CSV_TO_PDF_REPORT/backlog/sprints/sprint-9-retrospective.md

Sprint Retrospective

Sprint: 9 Date: 2026-10-27 Facilitated by: scrum-master, per process/05_sprint_retrospective.md Inputs used: backlog/sprints/sprint-9.md, backlog/backlog.md (Sprint 9 refinement, planning, and Review outcome notes), backlog/epics/04_live_preview_and_record_navigation.md, logs/technical_debt_log.md, logs/impediment_log.md, logs/process_improvement_log.md, backlog/sprints/sprint-8-retrospective.md (for follow-through check). This session had direct shell/build access throughout and ran dotnet test itself, confirming 476/476, plus real licensed access to the Debenu vendor DLL.

Signals

Objective:

• 1/1 committed story Done (13/13 points), sprint goal assessed “met in full” at Sprint Review (backlog/backlog.md, Sprint 9 Review outcome).
• Test suite grew from 448/448 (Sprint 8 close, including the two post-Sprint-8 ad hoc features) to 476/476 (357 desktop, 119 CLI) — independently confirmed via a direct dotnet test run during both execution and review.
• Zero new impediments; the two pre-existing open ones (asset path strategy, UNC timeout/retry) remain non-blocking and untouched.
• Zero new technical debt logged — the story's one open design question (resize-handle coexistence) was resolved by a simpler unified design, not worked around or deferred.
• Live verification spanned three independent layers, not just one: (1) a standalone real-DLL probe against the actual Debenu library, with real rasterized screenshots, performed before any implementation code was written; (2) a true end-to-end pipeline run (hand-authored template through the real built EnvelopeRenderer.Cli.exe against the real 392-record sample CSV, output PDF rasterized and visually inspected); (3) a reflection-driven built-form smoke against the real TemplateDesignerForm, driving the actual content TextBox, the actual Box width/height panel fields, and the actual mouse-driven resize-handle drag, with a real canvas screenshot.

Subjective:

• Dev-team explicitly investigated the vendor API's actual capabilities (via a real, licensed probe) before designing the CLI-side implementation, rather than assuming a custom word-wrap algorithm would be needed — this materially changed and simplified the design (native DrawTextBox/DrawRotatedTextBox calls instead of hand-rolled line-breaking).
• A found-during-execution fact (Debenu composes rotation and wrapping natively in one call) made the next queued story's own estimate likely stale. Rather than silently ship against the stale number or unilaterally re-size it without team input, dev-team flagged it explicitly for re-confirmation at the next refinement — the same “flag, don't silently override” discipline this team has applied to sizing notes before.
• A real, previously-unknown local resource (the project's own Debenu license key at the repo root) was found this sprint, materially deepening this sprint's own verification and retroactively explaining why several earlier sprints’ reviews had to disclose “no license key available” as an evidence-depth caveat.

What Went Well

• Vendor-API investigation moved earlier and got more rigorous. Previous sprints’ “confirm empirically against the real DLL” discipline (e.g., the original rotation story's DrawRotatedText sign-convention probe) has always happened during implementation. This sprint did the equivalent probe before committing to any design at all, using real screenshots to settle open questions (does DrawTextBox clip or only wrap? does rotation compose with wrapping in one call?) rather than assumption plus a fallback verification later.
• A cleaner solution replaced a harder design question. The story's own sizing note flagged “how does the new handle coexist with the just-shipped font-size handle” as an open Development Team decision, implicitly assuming two handles would be needed. The actual solution — one context-sensitive handle, mode chosen once at drag-start — is simpler than either option the sizing note considered, and was found by asking “does this really need two handles?” rather than defaulting to the more complex path.
• Honest handling of a stale estimate found mid-sprint, rather than either silently shipping against it or unilaterally shrinking it. The next queued story's 8-point estimate was explicitly flagged for re-confirmation rather than assumed complete or silently kept.
• Full-depth evidence at every layer this sprint (vendor probe, end-to-end CLI pipeline, built-form GUI smoke) — no evidence-depth caveats needed this time.

What Didn't Go Well

• The live built-form GUI smoke was initially dropped from the story's own task list and daily-log entry during execution (only the CLI-side end-to-end check was recorded as done), even though the story genuinely touches canvas/properties-panel UI (the new resize-handle mode and Box width/height fields) and this team's own Definition of Done and multiple prior retrospective action items specifically call for a real built-form smoke on GUI-touching stories. Caught and corrected within the same session before Sprint Review (the reflection-driven harness was run afterward, with a real screenshot), so no gap reached the review itself — but the near-miss is worth naming: “the CLI-side check felt sufficient” is exactly the kind of reasoning that has caused a real gap before (Sprint 1's license-key bug, Sprint 2's thin-GUI-evidence weakness).

Patterns / Insights (Prioritized)

1. (Process-level, real and actionable) The project's own Debenu license key (g:\CSV TO PDF Project\key.txt) sits one directory above code/, exactly within DebenuLicenseKeyResolver's own documented 10-level upward search — but at least two prior sessions (this session's own earlier searches this same conversation, and by inference whatever produced the “no key available” disclosures in DebenuPdfRendererIntegrationTests’/DebenuPdfRendererRotationTests's class remarks and the Sprint 7 review) only checked under code/ and concluded no key existed. This is a real, recurring (2+ occurrence) gap in verification depth, not a one-off — it meets AGENTS.md's bar for a kit-level fix, logged below rather than left as a one-sprint observation.
2. (Team-level) Doing real vendor-API investigation before writing implementation code (not just before finalizing a sizing estimate) is a stronger version of an already-good habit — worth naming as the standard to reach for whenever a story's design hinges on an external library's undocumented-in-this-repo behavior, not just for render-engine work specifically.
3. (Team-level, minor) A GUI-touching story's own task checklist can drift away from its own stated DoD requirement (the built-form smoke) during execution if the “easier” check (CLI-only, in this case) is completed first and feels sufficient. Worth a lightweight discipline: check the story's own AC/task list against what was actually verified before marking it done, not just before Sprint Review.

Action Items (Add These To Sprint 10's Plan)

• When a story's Definition of Done or its own task list calls for a built-form GUI smoke alongside another verification layer (e.g., a CLI end-to-end check), do not consider the story's verification complete until both layers are actually run — treat the GUI layer as equally load-bearing, not optional once a different check “feels sufficient” — owner: dev-team — due: ongoing.
• Re-confirm/re-size “Support rotated wrapped text and a live wrap/clip indicator for text elements” (epic 4, previously 8 pts) before it is committed to a sprint — this sprint's own shipped code likely already satisfies its rotation-composition half — owner: product-owner/dev-team — due: next backlog refinement that considers it.
• Carry forward, unchanged (third sprint in a row untriggered): apply the built-form-vs-canvas-only smoke rule per story when epic 6's multi-select/align pair is finally pulled — owner: dev-team — due: whichever sprint commits that pair.
• Carry forward, unchanged: evaluate extracting the pre-existing Sprint 6 Address Control hit-test/move/resize logic to a CanvasElementEditor-equivalent before/alongside the next story that deepens Address Control interaction — the queued “...Address Control lines” wrap/clip story is now a concrete, likely trigger for this — owner: dev-team — due: whenever that story is pulled.

Deferred / Lower-Priority Ideas

• “Warn on text overflow before render” (epic 4, provisional 5 pts) remains blocked on both remaining epic-4 wrap/clip stories landing first; not a Sprint 10 candidate on its own.
• The still-open product question would not apply here (it was resolved this backlog cycle) — no remaining deferred product questions from this sprint.

Follow-Up On Previous Retro's Actions

All three of Sprint 8's retrospective action items, checked against backlog/sprints/sprint-9.md and backlog/backlog.md's Sprint 9 planning/review outcomes:

1. Apply the built-form-vs-canvas-only smoke rule per story for epic 6's multi-select/align pair — Not applicable again. Epic 6's pair was not pulled into Sprint 9 either (the wrap/clip core story was prioritized instead, per Sprint 9 planning's own reasoning). Carried forward unchanged for a third sprint — flagged above as its own action item so this doesn't quietly become permanent.
2. Continue the fresh-full-form-screenshot-per-batch discipline — Applied in substance, though the sprint's shape (a single story, not multiple batches) meant there was no “reuse an earlier batch's screenshot” risk to guard against specifically. The story's own built-form smoke was a genuine, freshly-captured screenshot, not reused from anywhere — consistent with the discipline's intent even though its literal multi-batch trigger condition didn't arise. Noted above as a near-miss that it was initially skipped mid-execution before being caught and completed within the same session.
3. Evaluate extracting the pre-existing Sprint 6 Address Control interaction code to a CanvasElementEditor-equivalent before/alongside the next story that deepens Address Control interaction — Not triggered. This sprint's story deepened standalone text element interaction (the resize handle), not Address Control's. Carried forward unchanged — now with a concrete likely trigger identified (the queued Address Control wrap/clip story).

One item shows genuine follow-through in substance despite its literal trigger not arising (item 2); two items correctly carry forward unchanged since their trigger conditions have not yet occurred (items 1 and 3) — no drops.

Kit-Level Decision

Proposed (not yet applied — recommend the human product owner review before this becomes a durable kit change): log the license-key-search-depth finding to logs/process_improvement_log.md as a new entry. This meets AGENTS.md's recurrence bar — the “no key.txt found” conclusion recurred across at least two prior points (whatever produced DebenuPdfRendererIntegrationTests’/DebenuPdfRendererRotationTests's documented soft-skip design, and the Sprint 7 review's disclosed evidence-depth caveat) before this sprint's deeper search found it sitting in plain sight one directory above code/. Recommended concrete fix, for the human product owner to weigh: no code change is needed (the resolver's search path was always correct) — the fix is a team-practice reminder, e.g. a one-line note in AGENTS.md or CLI_CONTRACT.md's existing “Debenu license key” section pointing future sessions to check the actual repo root (not just code/) before concluding no key is available. Logged as Proposed, not Applied, since it's a documentation nudge affecting future verification depth, worth a deliberate decision rather than a silent edit.

Anti-Patterns Checked

• No follow-through on prior retro actions: Ruled out; see “Follow-Up” above — one item shows genuine follow-through in substance, two correctly carry forward unchanged since untriggered, no drops.
• Blame-focused discussion: Ruled out; the built-form-smoke near-miss and the license-key search-depth finding are both described as process/practice gaps, not attributed to a person or session.
• Hidden mini-waterfall within the sprint: Ruled out; the single committed story was designed (real vendor probe), implemented, tested, documented, and live-verified across all three evidence layers within one batch, consistent with every prior sprint's practice.
• Avoiding an obvious known problem: Ruled out; the stale dependent-story estimate was named and flagged rather than quietly shipped against or silently corrected, and the initially-incomplete built-form smoke was caught and fixed rather than left as an unacknowledged gap.
• Status-theater: Ruled out; evidence is concrete and independently checkable at every layer — real vendor-DLL screenshots, a real 392-page end-to-end PDF render with specific observed wrap/clip content, and a real built-form screenshot with specific before/after Width/Height/FontSize values from an actual mouse-driven drag.
• Review rubber-stamping (Sprint 3-named, resolved Sprint 4, checked again here): Ruled out. Sprint 9's review independently re-ran the full test suite and read the actual DebenuPdfRenderer/TemplateLayoutXmlSerializer/TemplateXmlParser code and new test files directly, and explicitly assessed (rather than accepted at face value) whether the dependent story's estimate should be treated as still-firm.