Close out Sprint 8 review/retro, ship Sprint 9 wrap/clip, and two ad hoc UX fixes

Sprint 8: completed product-owner review and scrum-master retrospective for whole-Address-Control rotation (13/13 points, sprint goal met in full). Same-day, outside-ceremony fixes/features: - Fixed a canvas drag/rotate smoothness bug for dynamic/mixed elements (an expensive properties-panel refresh was running on every mouse-move tick). - Added a font-size resize handle for standalone text elements. - Gathered requirements for adjustable element width/height, resolving the long-open "Warn on text overflow before render" product question. Sprint 9: shipped "Add an adjustable width and height with text wrapping to static and dynamic text elements" (13/13 points). Static/dynamic text elements can now wrap within a set width and clip content exceeding a set height, using Debenu's native DrawTextBox/DrawRotatedTextBox (confirmed via a real licensed vendor-DLL probe) for the CLI render, and GDI+'s native rectangle-bounded drawing for a design-time canvas/preview approximation. The existing font-size resize handle became context-sensitive (box mode vs. font-scale mode) rather than needing a second handle. Completed sprint review and retrospective. Test suite grew from 433/433 to 476/476 across both sessions of work. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
пре 4 дана · ee27de7499
--- a/backlog/backlog.md
+++ b/backlog/backlog.md
@@ -8,8 +8,8 @@ Index of all epics, ordered by priority (top = highest priority). Each epic is i
 | 2 | Template Designer GUI Foundation | `epics/02_template_designer_gui_foundation.md` | Done (7 of 7 stories — Sprint 2, 4, 6) |
 | 3 | CSV Integration and Field Mapping | `epics/03_csv_integration_and_field_mapping.md` | Done (4 of 4 stories — Sprint 4) |
 | 4 | CLI Rendering Engine and Debenu Integration | `epics/05_cli_rendering_engine_and_debenu_integration.md` | Done (6 of 6 stories — Sprint 1-5) |
 | 5 | Live Preview and Record Navigation | `epics/04_live_preview_and_record_navigation.md` | In Progress (2 of 3 stories Done — Sprint 7; 1 story, "Warn on text overflow before render," remains Not Ready, blocked on an open product question for the human product owner) |
 | 6 | Composite Address Controls and Mixed-Content Text | `epics/08_composite_address_controls.md` | In Progress (2 of 2 original stories Done — Sprint 5-6; reopened 2026-10-19 with 2 new Ready stories for whole-control rotation — 13 pts total, human-product-owner-requested, recommended first pull for Sprint 8; see Sprint 8 refinement outcome below) |
 | 5 | Live Preview and Record Navigation | `epics/04_live_preview_and_record_navigation.md` | In Progress (2 of original 3 stories Done — Sprint 7; the new wrap/clip core story also Done — Sprint 9; "Support rotated wrapped text..." (8 pts, flagged for re-sizing — largely already delivered as a byproduct) and "...Address Control lines" (8 pts) remain Ready; "Warn on text overflow before render" provisionally sized at 5 pts, still Not Ready until both land) |
 | 6 | Composite Address Controls and Mixed-Content Text | `epics/08_composite_address_controls.md` | Done (4 of 4 stories — Sprint 5, 6, 8; whole-control rotation delivered Sprint 8, see Sprint 8 Review outcome below) |
 | 7 | Layout Efficiency and Operator Tooling | `epics/06_layout_efficiency_and_operator_tooling.md` | In Progress (1 of 4 stories Done — Sprint 7; "Select multiple elements at once on the canvas" and "Align and distribute multiple elements" Ready as a dependent pair, "Undo and redo layout changes" Ready, feasibility-checked 2026-10-19, still highest-uncertainty) |
 | 8 | Dynamic and Network Image Handling | `epics/07_dynamic_and_network_image_handling.md` | Not Started (still blocked behind 2 open impediments; confirmed still non-blocking — both Composite Address Controls and Layout Efficiency still sit ahead of it in this table's order — see Sprint 8 refinement outcome below) |
@@ -153,6 +153,209 @@ Index of all epics, ordered by priority (top = highest priority). Each epic is i
 - **Open question restated for the human product owner, not re-decided here:** "Warn on text overflow before render" (epic 4, Live Preview and Record Navigation) has now been parked unresolved since 2026-10-16 across two backlog refinements. It remains non-blocking for every Sprint 8 candidate above, so it is not holding anything up — but it is the oldest open item in this backlog and worth a direct decision from the human product owner whenever convenient (does "overflow" mean page-edge overflow only, or does it require a new enforced per-element/control width boundary first).
 - No changes to the two open impediments (template asset path strategy; UNC timeout/retry behavior, both in `logs/impediment_log.md`) — confirmed still Open, unresolved since 2026-09-04, and still non-blocking for every Sprint 8 candidate named above.
 ### Sprint 8 Review outcome (2026-10-26)
 - Both committed Sprint 8 stories (13/13 points) are Done; each is verified against its acceptance criteria with real evidence, recorded story-by-story in `backlog/epics/08_composite_address_controls.md`. Full daily detail: `backlog/sprints/sprint-8.md`.
 - **Sprint goal met in full**, directly delivering the human product owner's Sprint 6 Review reversal ("whole-control rotation remains out of scope") — an Address Control can now be rotated as a rigid unit via the properties panel or a canvas drag handle, staying record-stable and visually consistent across the editing canvas, the Sprint 7 preview panel, and the real CLI-rendered PDF. Verification was independent, not a rubber-stamp: re-ran the full test suite directly (`dotnet test`, 433/433 passing — 326 desktop, 107 CLI, exactly matching dev-team's reported count) and read the actual persistence code (`TemplateLayoutXmlSerializer.CreateAddressControl`, `TemplateXmlParser.ParseAddressControl`) to confirm the new `angle` attribute round-trips with a `0` default on both the CLI and desktop sides independently. Confirmed the claimed new unit-tested classes genuinely exist (`PointRotation.cs`/`PointRotationTests.cs`, `AddressControlRotateHandle.cs`/`AddressControlRotateHandleTests.cs`) and that `AddressControlLayout.BoxCenter` is a pure function of authored geometry with no record input, supporting the pivot-stability acceptance criterion.
 - One caveat on evidence depth, disclosed rather than smoothed over: this review session did not rebuild or re-drive the actual desktop `.exe` itself, so dev-team's live built-form screenshot evidence (properties-panel wiring, canvas/preview/PDF visual parity, rotated hit-testing, live drag-to-rotate) was cross-checked against the underlying code rather than re-observed firsthand. Flagging this as a review-process limitation, consistent with how the Sprint 7 review disclosed the same kind of gap, not a defect in the sprint's delivery.
 - **Technical debt reviewed, confirmed reasonable to leave open:** the 2026-10-26 entry in `logs/technical_debt_log.md` (pre-existing Sprint 6 Address Control hit-test/move/resize logic remains WinForms-only and untestable, unlike this sprint's own newly-extracted, unit-tested rotation math) is confirmed Low-impact and non-blocking — a testability/maintainability gap with no known behavioral defect, and a proportional, in-scope call not to retroactively refactor already-shipped Sprint 6 code as part of this sprint's stories.
 - The Composite Address Controls and Mixed-Content Text epic is now **Done outright** (4 of 4 stories). No new product backlog item is required from this review.
 - No changes to the two open impediments (template asset path strategy; UNC timeout/retry behavior, both in `logs/impediment_log.md`) — still non-blocking. "Complete the first text-only operator workflow" (epic 1, 5 pts) remains flagged from Sprint 8 planning as needing product-owner re-verification of its stale "Ready" label before ever being pulled — not resolved in this review, carried forward as-is.
 ### New stories added during backlog refinement (2026-10-26) — adjustable width/height with text wrapping
 - Same-day, outside-formal-ceremony follow-up to the two live-build fixes above: the user asked
  for a way to make element/control boxes longer. `product-owner` clarified scope directly with
  the user across two rounds of questions (which controls; wrap vs. clip; which dimensions) before
  writing anything down. The answers — both standalone elements and Address Control; wrap text
  within the box but warn when it's happening; both width and height, with height acting as a hard
  clip boundary once wrapped content exceeds it — directly resolve the "Warn on text overflow
  before render" story's blocking open question, parked unresolved since the 2026-10-16 refinement
  across three separate refinement sessions (the single oldest open item in this backlog).
 - Wrote two new dependent stories in `epics/04_live_preview_and_record_navigation.md`: "Add an
  adjustable width and height with text wrapping to static and dynamic text elements" (the
  foundational, from-zero case — standalone elements have no width/height concept at all today)
  and "Add an adjustable width and height with text wrapping to Address Control lines" (extends
  the first story's engine to the composite control, whose `Width` exists today as a resize-handle-
  only value with no render effect, and whose `Height` doesn't exist as an independent value at
  all). This mirrors this team's own established general-capability-then-composite-control
  sequencing (Sprint 5 mixed content -> Sprint 6 Address Control).
 - **Material de-risking finding, confirmed by code inspection, not assumed:** grepped the vendor
  Debenu interop file before writing either story and found native wrap/box-drawing primitives
  this product has never called — `DPLDrawWrappedText`, `DPLDrawTextBox`, `DPLGetWrappedTextHeight`/
  `DPLGetWrappedTextLineCount` (directly useful for the "detect when wrapping/clipping is
  happening" requirement) — meaning this feature very likely does not require inventing a
  from-scratch word-wrap algorithm. Flagged in the epic for dev-team to confirm the exact semantics
  empirically during sizing, the same way the original rotation story empirically confirmed
  `DrawRotatedText`'s anchor behavior before committing to a design.
 - Updated "Warn on text overflow before render" (previously Not Ready, blocked on an undefined
  product question) to reflect the resolved question and re-scoped it as the full-CSV, all-records
  pre-render validation pass sitting on top of the new wrap/clip engine — distinct from the two new
  stories' own live, single-sample-record canvas/preview indicator. It now depends on both new
  stories rather than being blocked on a product decision.
 - **Not sized yet — flagged for dev-team at the next backlog refinement/Sprint 9 planning.** Both
  new stories are explicitly marked "Not Ready (needs dev-team sizing)" in the epic file per the
  Definition of Ready's "rough size estimate provided by the Development Team" requirement; the
  standalone-element story is flagged as likely comparable to or larger than the 13-point "Mix
  static text and CSV fields" story given it touches all three render surfaces plus a wholly new
  geometry concept, with a possible further split recommended at sizing time if it doesn't fit one
  sprint even alone.
 ### Sprint 9 Review outcome (2026-10-27)
 - The committed story (13/13 points) is Done; verified against all 6 acceptance criteria with
  real, non-simulated evidence, recorded in `backlog/epics/04_live_preview_and_record_navigation.md`.
  Full daily detail: `backlog/sprints/sprint-9.md`.
 - **Sprint goal met in full.** Independently re-ran the full test suite directly (`dotnet test`,
  476/476 confirmed — 357 desktop, 119 CLI — not trusted from dev-team's report alone) and read
  the actual `DebenuPdfRenderer.AddPage` box-branch code, `TemplateLayoutXmlSerializer`/`TemplateXmlParser`'s
  `width`/`height` persistence, and the new `DebenuPdfRendererWrapTests`/`CanvasElementEditorTests`
  directly to confirm the claims rather than rubber-stamping them.
 - **Genuinely strong evidence quality, worth naming explicitly:** this story's verification went
  beyond this project's usual bar — a real, licensed probe against the actual vendor DLL (not
  assumption) found and confirmed native Debenu wrap/box entry points before any implementation
  code was written, and the final live check was a true end-to-end pipeline run (a hand-written
  template through the real built `EnvelopeRenderer.Cli.exe` against the real 392-record sample
  CSV, with the resulting PDF rasterized and visually inspected showing genuine multi-line wrap and
  genuine height-based clipping) rather than a unit-level or mocked check.
 - **Real de-risking finding accepted, not just noted:** Debenu composes rotation and wrapping
  natively in one `DrawRotatedTextBox` call, meaning "Support rotated wrapped text and a live
  wrap/clip indicator for text elements" (8 pts, next in the epic 4 wrap/clip chain) is very likely
  already mostly satisfied by this story's shipped code for its rotation half. Confirmed this is
  correctly left un-re-sized rather than assumed complete — it still needs the live wrap/clip
  visual indicator (genuinely new UI) and an explicit confirming test for the rotated case. Agree
  with flagging it for re-sizing at the next backlog refinement rather than either silently keeping
  a stale 8-point estimate or unilaterally shrinking it without dev-team confirmation.
 - **Process-improvement finding, carried to the retrospective, not corrected retroactively:** the
  project's own Debenu license key (`key.txt`, repo root) was found this sprint after several
  earlier sprints' reviews (Sprint 7's review; both `DebenuPdfRendererIntegrationTests`/
  `DebenuPdfRendererRotationTests`) disclosed "no license key available locally" — those searches
  stopped one directory short of where both the resolver's own upward walk and the actual key live.
  This means some earlier evidence-depth caveats were avoidable tooling gaps, not genuine
  environment constraints. Not re-litigating those sprints' already-accepted verification (they
  were independently corroborated by other means at the time per their own review records) — this
  is a forward-looking process fix, which `scrum-master` should weigh at the retrospective.
 - No new technical debt logged this sprint — the one open design question from planning (resize-
  handle coexistence) was resolved by a simpler design (one context-sensitive handle) than either
  option originally considered, not worked around.
 - Epic 4 (Live Preview and Record Navigation) status: 2 of its original 3 stories Done (Sprint 7)
  plus this new wrap/clip core story Done (Sprint 9); "Support rotated wrapped text..." (8 pts,
  flagged for re-sizing) and "...Address Control lines" (8 pts) remain Ready; "Warn on text
  overflow before render" (provisional 5 pts) remains Not Ready until both land.
 - No changes to the two open impediments (template asset path strategy; UNC timeout/retry
  behavior, both in `logs/impediment_log.md`) — still non-blocking.
 ### Sprint 9 backlog refinement outcome (2026-10-26)
 `product-owner` ran Sprint 9 backlog refinement after the human product owner confirmed the
 post-Sprint-8-retrospective pause point with "continue," folding in the Sprint 8 retrospective's
 action items (see `state.md`) and completing the sizing this session's own earlier ad hoc
 wrap/clip requirements-gathering left as "not yet sized."
 - **Re-verified epic 6's two Ready items (multi-select, undo/redo) before trusting them**, since
  real code changed since their 2026-10-16/10-19 sizing (this session's own font-size resize handle
  and `IsInteracting` smoothness fix). No material change found — `CanvasElementEditor.Selected`
  is still a single reference, so multi-select's core scope is unchanged. One honest addition:
  "Undo and redo layout changes" should track the new font-size resize-drag as a mutation type
  alongside move/rotate — the same shape of mutation, not new complexity, so its 13-point estimate
  stands unchanged. Full detail: `epics/06_layout_efficiency_and_operator_tooling.md`'s new
  2026-10-26 re-verification note.
 - **Sized the three new epic-4 wrap/clip stories via real code/vendor-API inspection**, completing
  what this session's earlier ad hoc requirements-gathering left unsized:
  - "Add an adjustable width and height with text wrapping to static and dynamic text elements":
    **13 points.** Real de-risking finding: the vendor Debenu library already exposes native
    wrap/box-drawing entry points (`DPLDrawWrappedText`, `DPLDrawTextBox`,
    `DPLGetWrappedTextHeight`/`LineCount`) with confirmed parameter shapes, and GDI+ has an
    equivalent native rectangle-wrap capability for the canvas side — neither surface needs a
    hand-rolled word-wrap algorithm. Real risk found, not assumed: the desktop app and the CLI are
    two separate processes with no shared code path (confirmed no Debenu reference anywhere in
    `EnvelopeRenderer.Desktop*`), so canvas/preview wrap (GDI+) and the final PDF's wrap (Debenu)
    are two genuinely independent text engines that cannot be made to agree by construction the
    way every prior "shared TextResolver" fix could — scoped as an accepted, documented
    approximation (mirroring `MeasureElement`'s existing language) rather than a blocking problem.
  - **Found too large to respect as one story and split further at sizing time** (the same
    fallback-split shape "Mix static text and CSV fields" itself once offered): "Support rotated
    wrapped text and a live wrap/clip indicator for text elements," **8 points**, carved out of the
    story above — rotation composed with wrapping has no precedent in this codebase, and the "warn
    this is happening" visual indicator is new UI, but both build directly on the core story's
    already-established model and native-call pattern rather than inventing a second one.
  - "Add an adjustable width and height with text wrapping to Address Control lines": **8 points**
    — reuses the two stories above's engine; real residual scope is the auto-computed-vs-explicit-
    `Height` interaction and per-line wrap allocation, comparable in shape to how "Group lines into
    a single, movable Address Control" reused Sprint 5's run model but still carried genuine new
    composite-element scope.
  - "Warn on text overflow before render" (already in the backlog, previously blocked on the
    now-resolved open question): **provisional 5 points**, sized by analogy to two already-Done
    patterns at this scale (`RenderEngine`'s existing pre-flight validation pass; "Jump to a
    specific record number"'s full-file scan) — explicitly flagged as provisional, to be
    re-confirmed once the three stories above's actual data model exists.
  - **Total new scope: 34 points across four stories** — larger than the entire 26-point Composite
    Address Controls epic, and realistically 2+ sprints on its own given this team's proven
    18-20 point range. Full detail, findings, and Confirmation criteria for all four stories:
    `epics/04_live_preview_and_record_navigation.md`.
 - **Epic ordering not changed, and this backlog's existing order already puts epic 4 ahead of
  epic 6** (position 5 vs. 7) — a standing order, not a new decision made here. The wrap/clip
  request is also a direct, fresh, explicit ask from the human product owner this same session,
  the same character of signal ("recent, explicit, human-directed") that justified epic 8 jumping
  the queue for Sprint 8. Recommend the epic 4 wrap/clip chain as Sprint 9's first candidate on
  both grounds — standing table order and request freshness agree here, unlike epic 8's case where
  only the second reason applied. Epic 6's multi-select/align pair (10 pts) and undo/redo (13 pts)
  remain Ready and unchanged, next in line once the wrap/clip chain is underway.
 - **Definition of Ready exit criteria checked:** epic 6's multi-select/align pair (10 pts) and
  undo/redo (13 pts) remain Ready; three of the four new epic-4 stories are now Ready (13, 8, 8
  pts); "Warn on text overflow before render" remains Not Ready (blocked on those three landing
  first, per its own dependency chain) despite carrying a provisional estimate. Combined Ready
  backlog: 52 points — comfortably enough for 2-3 sprints per this process's own exit criteria.
 - No changes to the two open impediments (template asset path strategy; UNC timeout/retry
  behavior, both in `logs/impediment_log.md`) — confirmed still Open, unresolved since 2026-09-04,
  still non-blocking for every candidate above. "Complete the first text-only operator workflow"
  (epic 1, 5 pts) remains flagged from Sprint 8 planning as needing product-owner re-verification
  of its stale "Ready" label before ever being pulled — not resolved in this refinement, carried
  forward as-is.
 ### Sprint 9 planning outcome (2026-10-26)
 `scrum-master` facilitated with `product-owner`/`dev-team` input, immediately following Sprint 9
 backlog refinement above.
 - Capacity signal now has eight data points (Sprints 1-8: 20, 19, 18, 18, 15, 18, 18, 13). The
  18-20 point range from Sprints 1-4/6-7 still holds as the team's *proven, repeatable* velocity;
  both 15 (Sprint 5) and 13 (Sprint 8) are documented, deliberate under-commits around one
  large/risky or fresh story, not capacity misses — consistent with how Sprint 8 planning itself
  already treated Sprint 5's 15.
 - **Committed 13 points**: "Add an adjustable width and height with text wrapping to static and
  dynamic text elements" (epic 4) alone, as a deliberate under-commit — the same posture Sprint 5
  and Sprint 8 each took around their own largest/riskiest or freshest story, not a default.
  Full plan: `backlog/sprints/sprint-9.md`.
 - **Capacity reasoning, weighed explicitly:** two larger combinations were considered and rejected.
  (a) Pulling this story's own dependent follow-up, "Support rotated wrapped text and a live
  wrap/clip indicator" (8 pts), in the same sprint would total 21 points — a new team-wide high
  (previous best 20) for a *first-of-its-kind* geometry/render capability with two real, cited
  unknowns (Debenu's exact wrap/box-call semantics, and how rotation composes with wrapping) still
  to be confirmed empirically. Unlike prior "pull the whole dependent pair" precedents (Sprint 4's
  and Sprint 8's rotation chains, Sprint 7's preview pair — each ≤13-18 points total), this
  story's own Conversation notes establish it is independently valuable and shippable *without*
  its follow-up (a resizable box that genuinely wraps/clips in the real PDF), so there is no
  "no independent value without its pair" pressure to pull both at once the way align/distribute
  has with multi-select. (b) Pulling epic 6's multi-select/align pair (10 pts) alongside this
  story (23 points total) was rejected for the same reason Sprint 8 rejected pairing multi-select
  with its own drag-handle story: stacking two large, genuinely novel, first-of-its-kind
  initiatives (a new multi-item selection model, and a new element-geometry/wrap-render model) in
  one sprint is exactly the risk profile this team has consistently avoided, and no external
  date/contractual pressure was cited to justify reaching for an unproven new high instead.
 - **Checked for a smaller item to round out capacity — found none that cleanly fits**, the same
  conclusion Sprint 8 planning reached for the identical reason: epic 6's multi-select cannot be
  pulled alone without its align/distribute pair per this team's own established "pull a
  hard-dependent pair whole or not at all" practice (multi-select's own card frames it as valuable
  standalone, but the team's precedent for *this specific pair* has been to sequence them
  together), and "Complete the first text-only operator workflow" (epic 1, 5 pts) remains
  explicitly flagged as a stale label needing re-verification before ever being pulled blind.
 - **Sequencing recommendation for the epic 4 wrap/clip chain beyond Sprint 9:** "Support rotated
  wrapped text and a live wrap/clip indicator" (8 pts) is the natural next pull once this sprint's
  story lands, then "Add an adjustable width and height with text wrapping to Address Control
  lines" (8 pts). Epic 6's multi-select/align pair (10 pts) and undo/redo (13 pts) remain queued
  and unchanged, available whenever a sprint's planning session chooses them over continuing the
  wrap/clip chain — no additional urgency signal has been given for either over the other.
 ### Sprint 8 planning outcome (2026-10-26)
 - `scrum-master` facilitated with `product-owner`/`dev-team` input. Capacity signal now has seven data points (Sprints 1-7: 20, 19, 18, 18, 15, 18, 18), a stable 18-20 point range.
 - **Committed 13 points**: the full epic 8 whole-Address-Control-rotation pair — "Rotate the whole Address Control as a single unit" (8 pts) then "...by dragging a handle on the canvas" (5 pts, dependent) — as a deliberate, reasoned under-commit, not a capacity miss. Full plan: `backlog/sprints/sprint-8.md`.
--- a/backlog/epics/02_template_designer_gui_foundation.md
+++ b/backlog/epics/02_template_designer_gui_foundation.md
@@ -41,6 +41,10 @@ As a **print operator**, I want to place static and dynamic text placeholders on
 - [ ] An operator can select and reposition text elements visually.
 - [ ] Element position updates are reflected accurately in the saved layout state.
 **Post-Sprint-8 user-requested feature (2026-10-26, handled outside formal ceremony):** User asked for a way to make static and dynamic text elements bigger or smaller on the canvas. Clarified scope directly with the user first: a "Font size (pt)" numeric field already exists in the properties panel (`_fontSizeInput`, wired since Sprint 2's "Edit selected text properties in a properties panel" story), but the user specifically wanted a **draggable resize handle on the canvas**, the same direct-manipulation style already shipped for the Address Control's width handle and this epic's own rotate handle. A standalone element has no independent Width/Height of its own today — its box is purely derived from measuring `DisplayText` at the current `FontSize` (`TemplateCanvasControl.MeasureElement`) — so, unlike the Address Control's width handle, dragging this new handle uniformly scales `FontSize` itself (the only property that actually changes what renders), rather than an inert design-time-only box: it stays consistent with this story's own original "Resizing can be limited to what is needed for text boxes in MVP" conversation note without opening the separate, still-unresolved "Warn on text overflow before render" question (epic 4), since no wrap/clip boundary concept is introduced here. Implementation: a new `CanvasElementEditor.ResizeHandlePosition`/`HitTestResizeHandle`/`BeginResizeDrag`/`ResizeDragTo` (Desktop.Core, framework-free, unit tested — 15 new tests) places a square handle (matching the Address Control resize handle's visual style, deliberately distinct from this epic's round rotate-handle dot) at the box's top-right corner, diagonally opposite the element's fixed (X, Y) anchor; dragging computes an absolute scale factor from the pointer's current distance to that anchor versus the box diagonal captured at drag-start (the same "recompute from scratch every tick" style `RotateDragTo` already uses, avoiding incremental-delta drift), clamped to the properties panel's own existing Font size bounds (1-1000pt) so a drag can never produce a value the panel would silently re-clamp. The properties panel's Font size field stays bidirectionally synced via the same `RefreshInteractivePositionFields`/gesture-end-full-refresh mechanism the move/rotate smoothness fix below introduced — confirmed the new gesture is exempt from the same choppiness bug (0 header-list enumerations mid-drag). Live-verified through the real `OnMouseDown`/`OnMouseMove`/`OnMouseUp` pipeline via a reflection-driven harness against the real built assembly: a synthetic click on the handle's real computed pixel position correctly started a resize-drag, dragging outward grew a 12pt dynamic placeholder to ~43pt with the panel field tracking live, and dragging back toward the anchor shrank it to the clamped 1pt minimum. Full test suite: 448/448 (up from 433), no regressions.
 **Post-Sprint-8 user-reported fix (2026-10-26, handled outside formal ceremony):** User reported that dragging or rotating a dynamic/mixed-content element on the canvas felt visibly choppy, not smooth like a static element. Root cause confirmed by code inspection before writing anything down: `TemplateCanvasControl.OnMouseMove` fires `ElementsChanged` on every single mouse-move tick of a drag or rotate gesture, and `TemplateDesignerForm`'s handler responded by running the full `RefreshPropertiesPanel()` — which, for an element bound to a single CSV column (`HasSingleColumnRun`), also calls `RefreshRebindColumnComboBox`, clearing and fully repopulating the rebind combo box from every loaded CSV header (plus a `.ToList().FindIndex(...)` re-scan) on every tick. A purely static element skips that path entirely (`isSingleColumn` is false), which is exactly why the choppiness was specific to dynamic/mixed elements and easy to miss during Sprint 2's original static-vs-dynamic drag verification. Fixed by adding `TemplateCanvasControl.IsInteracting` (true while any move/resize/rotate gesture is active) and a new cheap `TemplateDesignerForm.RefreshInteractivePositionFields()` that syncs only the X/Y/width/angle fields a gesture can actually change; the full panel refresh now runs once, on `OnMouseUp`, instead of on every tick. Live-verified with a reflection-driven harness (same technique as prior sprints) against the real built assembly, using the real 22-header sample CSV and a dynamic placeholder bound to "Full Name": before the fix, 60 synthetic drag ticks took 88.56 ms total (1.48 ms/tick) and enumerated the header list 120 times *during* the drag; after the fix, the same 60 ticks took 1.32 ms total (0.022 ms/tick, a ~67x improvement) with 0 header-list enumerations during the drag and exactly one full refresh firing after mouse-up — confirmed identically for the rotate gesture. Position and angle were confirmed to still update correctly on every tick (the element visibly moved/rotated throughout), so the fix removes only the redundant expensive work, not the live feedback itself. Full test suite re-run: 433/433 passing, no regression. Not logged as technical debt (resolved same-day, not left open); documented here per this team's established pattern for same-day post-review/ad-hoc user feedback (see `state.md`'s history for the 2026-10-19 precedents).
 **Estimate:** 5 points
 **Dependencies:** None
@@ -112,6 +116,8 @@ As a **print operator**, I want to rotate a text or dynamic field element by dra
 **Sizing note (`dev-team`, 2026-09-22):** Sized this against Sprint 2's "Place and move text elements on the canvas" (5 points), which is the closest precedent in this codebase for a new mouse-drag canvas interaction, and it lands at roughly the same size for different reasons. What's genuinely net-new here: `CanvasElementEditor` (`code/src/EnvelopeRenderer.Desktop.Core/Design/CanvasElementEditor.cs`) has no concept of a "handle" today — its `HitTest`/`BeginDrag`/`DragTo`/`EndDrag` state machine only knows how to grab-and-move an element's whole body via an `(Dx, Dy)` offset, so a distinct handle hit-test (a small region positioned at an offset from the rotated bbox center, per the previous story's rotated-geometry work) and a distinct rotate-drag mode (computing an angle via `atan2` of the pointer relative to the bbox center, not an X/Y offset) are both new logic, and `TemplateCanvasControl` needs new paint code to draw the handle glyph itself. What is *not* new, because this story explicitly depends on and reuses the previous story's delivery: the underlying `RotationAngle` property, its persistence, and the render/pivot math are entirely out of scope here (per this story's own conversation notes) — this story only adds the interactive affordance on top of a property that already exists, mirroring exactly how "Place and move" only had to add interaction on top of `TextElementLayout.X/Y`, which already existed from "Configure canvas dimensions." More importantly, the bidirectional properties-panel/canvas sync this story's third acceptance criterion asks for is not new plumbing to invent: `TemplateDesignerForm.cs` already implements exactly this pattern for X/Y today — `TemplateCanvasControl.ElementsChanged` (raised by a canvas drag) triggers `RefreshPropertiesPanel()`, and each panel input's `ValueChanged` handler calls `_propertiesEditor.SetX(...)` / `_canvas.NotifyElementChanged()` to push panel edits back to the canvas — so wiring a new `RotationAngle` input into that existing two-way loop is a direct copy of an already-proven pattern, not a new design problem. Net: new hit-testing and new drag-angle math (comparable novelty to "Place and move"'s original hit-test/drag work), offset by not having to invent the property, its persistence, or the panel-sync plumbing (all reused). Landed on 5 points, the same as its closest precedent story, rather than higher — the reused sync machinery meaningfully lowers the risk relative to "Place and move," which had to build that from nothing. Comfortably fits within a single sprint per the Definition of Ready at the team's 19-20 point/sprint velocity; no split recommended. Note for planning: this story's own listed dependency means it cannot be pulled into the same sprint as "Set a rotation angle..." unless that story is fully done first (or earlier in the same sprint, swarmed to completion before this one starts), consistent with how Sprint 3 sequenced the CSV-mapping dependency chain.
 **Dependencies:** Depends on "Set a rotation angle for text and dynamic field elements" (above, same epic).
 **Post-Sprint-8 user-reported fix (2026-10-26):** The same choppy-drag root cause fixed for plain movement (see "Place and move text elements on the canvas"'s dated note above) applied identically to this story's rotate-drag handle, since both gestures route through the same `TemplateCanvasControl.OnMouseMove` → `TemplateDesignerForm.ElementsChanged` path. The fix (`TemplateCanvasControl.IsInteracting`, `RefreshInteractivePositionFields`) covers both gestures with the same code change; live-verified for the rotate gesture specifically (0 header-list enumerations during 60 synthetic rotate-drag ticks, one full refresh after release, `RotationAngle` confirmed changing live throughout). See the other story's note for full detail and measurements.
 ### Save and reopen text-only XML templates - Status: Done
 **Sprint Review verification (Sprint 2, 2026-09-18):** All 4 acceptance criteria met and strongly demonstrated against the actual built `.exe` in three real scenarios: (1) saved a layout with a static and dynamic element, confirmed a green success message and inspected the actual XML written to disk; (2) attempted to open a deliberately malformed file and got a clear operator-facing error dialog naming the specific XML problem, with in-progress canvas state left untouched; (3) reopened the file saved in (1) into a fresh designer instance and confirmed canvas dimensions, both elements, and their exact positions were restored identically. 12 new xUnit tests cover round-trip fidelity, five distinct error cases, backward compatibility with Sprint 1's plain render-time template shape, and z-order clamping consistency. As a bonus (not required by this story's AC, but validating the schema design decision), the saved template was run through the real `EnvelopeRenderer.Cli.exe` and rendered a valid PDF, confirming a designer-saved file is a genuinely renderable template and not a divergent format. This story's live, multi-scenario, real-artifact evidence is exactly the kind of verification the Sprint 1 retrospective's DoD edit was written to require — a clean, direct answer to that gap, not just a technical fix.
--- a/backlog/epics/04_live_preview_and_record_navigation.md
+++ b/backlog/epics/04_live_preview_and_record_navigation.md
@@ -49,8 +49,350 @@ were not explicit/testable against the current product surface, and its 5-point
 longer reflects real scope). It has been rewritten and split below. Story 2 is updated but not
 split. Story 3 is **not marked Ready** — see the open question.
 ## Refinement note (2026-10-26) — the 2026-10-16 open question is now resolved
 The human product owner has decided the blocking open question left in "Warn on text overflow
 before render" below: **option (b)** — add a real, per-element/per-control width *and* height
 boundary, with **wrap-then-clip** behavior (text wraps to additional lines within the box; if the
 wrapped content still exceeds the box's height, the excess is clipped) and a visible warning when
 either wrapping or clipping is actually happening for the current sample record, in addition to
 the existing full-CSV pre-render validation pass "Warn on text overflow before render" already
 covers. Both dimensions become independently adjustable — draggable on the canvas, matching the
 direct-manipulation style already shipped for the Address Control's width handle and this epic's
 own rotate handle — for **both** standalone static/dynamic text elements (which have no
 width/height concept at all today) and Address Control (which has `Width` today, resize-handle
 only per the Sprint 6 review, and no independent `Height` at all — it is always auto-computed from
 line font sizes).
 This unblocks "Warn on text overflow before render," but the wrap/clip capability itself is real,
 substantial, novel engineering — it does not yet exist anywhere in this product and touches the
 same three surfaces (CLI render, editing canvas, Sprint 7 preview panel) and both element kinds
 this epic and epic 8 have repeatedly had to keep in sync. Following this team's established
 pattern for a general capability that a composite control also needs (the Sprint 5/6 "mixed
 content, then Address Control" sequencing), it is split below into three dependent stories —
 standalone elements' core wrap/clip capability first (the harder, from-zero case), rotated wrap
 composition plus a live wrap/clip indicator second (`dev-team` sizing, 2026-10-26, found the
 combined standalone-element scope too large for one sprint and split it further, the same
 fallback-split shape "Mix static text and CSV fields" itself once offered), and Address Control
 third (extends the first two stories' engine to per-line wrapping/clipping within the control's
 existing line-list model) — rather than attempted as one very large story. "Warn on text overflow
 before render" (already in this epic, previously blocked on the undefined product question) now
 depends on all three and is provisionally sized alongside them below.
 **Material de-risking finding (product-owner, code inspection, 2026-10-26):** grepped the vendor
 interop surface (`code/vendor/debenu/interop/DebenuPDFLibraryDLL1013.cs`) before writing either
 story below, rather than assuming a wrap algorithm must be built from scratch. Debenu Quick PDF
 Library 10.13 already exposes native wrap/box-drawing primitives this product has never called:
 `DPLDrawWrappedText`, `DPLDrawTextBox` (draws text directly into an `(x, y, width, height)` box),
 `DPLDrawMultiLineText`/`DPLDrawRotatedMultiLineText`, and — directly relevant to the "warn when
 this is happening" requirement — `DPLGetWrappedTextLineCount`/`DPLGetWrappedTextHeight`, which can
 measure how tall wrapped text would be *before* drawing it, making an over-height check a
 measurement comparison rather than a custom line-breaking implementation. This is a real,
 verifiable finding (confirmed present in the interop file, not assumed from the vendor's general
 reputation) that materially reduces this feature's risk versus a naive "build word-wrap from
 scratch" assumption — dev-team should confirm the exact semantics of these entry points (alignment
 options, whether `DPLDrawTextBox` already clips or only wraps, how rotation composes with a
 wrapped box) empirically during sizing, the same way the original rotation story empirically
 confirmed `DrawRotatedText`'s anchor behavior before committing to a design.
 ## Stories
 ### Add an adjustable width and height with text wrapping to static and dynamic text elements - Status: Done
 **Development verification (Sprint 9, 2026-10-27, `dev-team`):** All 6 acceptance criteria met.
 AC1 (settable, persisted Width/Height, coexisting with the font-size handle): `TextElementLayout.Width`/`Height`
 (nullable, `HasBox` true only when both set) persist as optional `width`/`height` attributes on
 `<text>` (`TemplateLayoutXmlSerializer`/`TemplateXmlParser`, both independently implemented per
 this project's CLI/desktop split); properties-panel "Box width"/"Box height" fields (0 = no box)
 added alongside the existing X/Y/Angle/Font size rows. Rather than a second, visually-distinct
 handle (the sizing note's open design question), the existing corner resize handle became
 context-sensitive: `CanvasElementEditor.BeginResizeDrag`/`ResizeDragTo` check
 `TextElementLayout.HasBox` once at drag-start — with a box, the drag sets Width/Height directly;
 without one, it scales FontSize exactly as it already did — so there is only ever one handle to
 grab, never two competing for the same corner. AC2 (native wrap in the real PDF): confirmed
 against the real vendor DLL, not assumed — `DebenuPdfRenderer.AddPage` calls Debenu's native
 `DrawTextBox`/`DrawRotatedTextBox` (found via `code/vendor/debenu/interop/DebenuPDFLibraryDLL1013.cs`)
 when a draw carries a box, reusing the one shared `TextResolver`-resolved string; a real-DLL probe
 (licensed, with actual rendered-page screenshots) confirmed `DrawWrappedText` genuinely wraps a
 120pt-wide long line onto 6 lines matching `GetWrappedTextLineCount`. AC3 (clip, not grow/shrink):
 same probe confirmed a 20pt-tall box draws only the first 2 of those 6 lines and returns `2` (not
 an error) — Debenu's own return value directly reports lines actually drawn, which
 `DebenuPdfRendererWrapTests.AddPage_WithLicenseKey_BoxTooShort_ClipsFewerInkRowsThanATallBox`
 also proves via real rasterized pixel-row counts. AC4 (canvas/preview approximation): `TemplateCanvasControl.MeasureElement`
 and `TemplatePreviewBuilder`/`TemplatePreviewControl` return/draw the box's own Width/Height
 directly (not a text measurement) via GDI+'s native rectangle-bounded `DrawString`, explicitly
 documented as a design-time approximation since the desktop process has no shared code path with
 the CLI's Debenu engine (confirmed by inspection: no Debenu reference anywhere in
 `EnvelopeRenderer.Desktop*`). AC5 (rotation + box, same surfaces): `DebenuPdfRenderer` normalizes
 `Angle` and calls `DrawRotatedTextBox` for a rotated boxed draw — a genuine de-risking find versus
 the sizing note's own assumption: Debenu composes rotation and wrapping natively in one call, so
 no manual pre-wrap-then-rotate-per-line synthesis was needed after all (the dependent "Support
 rotated wrapped text..." story below is now expected to be materially smaller than its own 8-point
 estimate as a result — not yet re-sized, flagged for the next refinement). AC6 (pre-existing
 templates unchanged): confirmed by a `HasBox`-gated branch in both `AddPage` and the XML
 read/write paths — no box means the exact pre-Sprint-9 `DrawText`/point-based `DrawString` code
 path, byte-for-byte. Tests: 23 new (7 CLI — `TemplateXmlParserTests`, `RenderEngineTests`,
 `DebenuPdfRendererWrapTests` including one license-gated real-pixel test — and 16 desktop —
 `TextElementPropertiesEditorTests`, `TemplateLayoutXmlSerializerTests`, `CanvasElementEditorTests`,
 `TemplatePreviewBuilderTests`). Full suite 448/448 -> 476/476 (357 desktop, 119 CLI). Live
 end-to-end verification: a real template with a narrow static box (150x80pt) and a narrow dynamic
 box bound to `Full Name` (180x30pt) was rendered by the actual built `EnvelopeRenderer.Cli.exe`
 against the real 392-record sample CSV (`DEBENU_LICENSE_KEY` from the project's own `key.txt`,
 confirmed present and valid during this story — earlier sprints' "no key available" caveats no
 longer apply); page 1 of the resulting 392-page PDF, rasterized via Debenu's own
 `RenderPageToFile` and visually inspected, shows the static line genuinely wrapped across 4 lines
 and the dynamic line ("WILLIAM EDWARD ZIMMERMAN JR") genuinely clipped to "WILLIAM EDWARD" by its
 30pt height — real, observed proof of the whole pipeline (Designer XML -> CLI -> Debenu -> PDF)
 working together, not merely unit-level. Separately, a reflection-driven built-form smoke drove
 the real `TemplateDesignerForm`: typed real content into the actual `_contentInput` TextBox and
 committed it via the real `CommitContentFromPanel` path, set 140x90pt through the actual
 `_elementWidthInput`/`_elementHeightInput` NumericUpDown controls (confirming `HasBox` flips true),
 then dragged the real resize handle through the actual `OnMouseDown`/`OnMouseMove`/`OnMouseUp`
 pipeline — Width/Height grew to ~198x133.5pt while `FontSize` stayed exactly 12, proving box mode
 (not the pre-existing font-scale mode) was genuinely active via the real UI, not just asserted in
 a unit test. A real canvas screenshot from this run shows the wrapped text and both the resize and
 rotate handles correctly positioned at the resized box's own corner/center.
 **Process note:** the project's own Debenu license key (`key.txt` at the repo root, one level
 above `code/`) was located during this story after earlier sprints repeatedly stated no key was
 available locally — those sprints only ever searched under `code/`, one directory short of where
 `DebenuLicenseKeyResolver`'s own 10-level upward walk (and this repo's actual key) both reach. This
 means several earlier "no license key, evidence-depth caveat" disclosures (Sprint 7's review,
 `DebenuPdfRendererIntegrationTests`' and `DebenuPdfRendererRotationTests`' soft-skips, etc.) were
 avoidable, not a genuine environment constraint — flagged for the retrospective, not corrected
 retroactively (those sprints' shipped behavior was still verified correct by other means at the
 time).
 **Card**
 As a **print operator**, I want to give a static or dynamic text element a real width and height
 so that long or variable-length content wraps within a defined box instead of running off
 indefinitely, and I want to be warned when that's happening for the record I'm looking at.
 **Conversation notes**
 - Confirmed with the user (2026-10-26): both width *and* height become independently
  settable/draggable — a real rectangular resize box, not a width-only handle like the Address
  Control's existing one. Height is a hard vertical clip boundary: wrapped content that doesn't
  fit within the set height is cut off (with a warning), rather than the box silently growing
  taller or text silently shrinking to fit.
 - Confirmed with the user: overflow behavior is **wrap first, then clip if it still doesn't
  fit** — not immediate clipping and not unlimited growth. This directly resolves "Warn on text
  overflow before render"'s previously-blocking open question (see the refinement note above).
 - This is a genuinely new concept for standalone elements: `TextElementLayout`/`TemplateElement`
  have no `Width`/`Height` property at all today (confirmed by code inspection, matching the
  2026-10-16 refinement's own finding) — today's box is purely derived from measuring
  `DisplayText` at the current `FontSize`. This story adds real, persisted geometry alongside
  that, not a replacement for it — font-size scaling (just shipped) and box width/height
  (this story) are two independently valid, coexisting ways to resize an element, the same way
  the Address Control already keeps a per-line `FontSize` and a separate control-level `Width`
  as two coexisting knobs.
 - Must reuse the one shared text-resolution routine (`TextResolver`, extracted in Sprint 7) for
  computing what text actually gets wrapped/measured against the box, so the CLI render, the
  editing canvas, and the Sprint 7 preview panel cannot drift into three different wrap
  decisions for the same content — the exact drift class that caused the 2026-10-09
  rotation-positioning defect.
 - Out of scope for this story (split out below after dev-team sizing found the combined scope too
  large for one sprint): rotation composed with wrapping, and the live wrap/clip visual indicator.
  This story alone delivers the real, load-bearing capability — the box can be resized, and the
  final CLI-rendered PDF actually wraps/clips content within it — without those two additions.
 - Out of scope for this story: any wrap/clip behavior for Address Control lines — a separate,
  dependent story below, matching this team's established general-capability-then-composite-
  control sequencing (Sprint 5 mixed content -> Sprint 6 Address Control).
 **Confirmation (Acceptance Criteria)**
 - [ ] A static or dynamic text element has an independently settable, persisted Width and Height,
      adjustable via draggable canvas handle(s) and/or properties-panel numeric fields (mirroring
      the Address Control's existing X/Y/Width panel field pattern), visually distinct from and
      coexisting with the just-shipped font-size resize handle on the same element.
 - [ ] Text content that exceeds the element's Width wraps onto additional lines within the box in
      the real CLI-rendered PDF, using Debenu's own native wrap primitives rather than a
      hand-rolled line-breaking algorithm.
 - [ ] Wrapped lines that exceed the element's Height are clipped (cut off) in the real CLI-rendered
      PDF rather than growing the box or shrinking the text.
 - [ ] The editing canvas and preview panel approximate the same wrap/clip result using GDI+'s own
      native rectangle-bounded text drawing, close enough for layout purposes — pixel-for-point
      parity with the Debenu-rendered PDF is not required here (the same accepted "design-time
      visual approximation" scope already documented for `MeasureElement`), since GDI+ and Debenu
      are two different text engines with no shared line-breaking code path.
 - [ ] An unrotated element with a set width/height behaves identically whether it is static or
      dynamic/mixed content, using the one shared text-resolution routine so wrapped content
      agrees with what every other surface already resolves.
 - [ ] Existing templates saved before this story (no Width/Height attributes) render unchanged —
      an element with no explicit width/height keeps today's unbounded, non-wrapping behavior.
 **Estimate:** 13 points (`dev-team`, 2026-10-26, via inspection of `TextElementLayout.cs`,
 `TextDraw.cs`, `DebenuPdfRenderer.AddPage`, and the vendor interop file
 `code/vendor/debenu/interop/DebenuPDFLibraryDLL1013.cs`). Two real findings materially shape this
 estimate:
 - **De-risking finding:** Debenu Quick PDF Library 10.13 already exposes native wrap/box-drawing
  entry points this product has never called — `DPLDrawWrappedText(handle, x, y, width, text)` and
  `DPLDrawTextBox(handle, x, y, width, height, text, alignment)` (both confirmed present with these
  parameter shapes via the interop file's own delegate signatures), plus
  `DPLGetWrappedTextHeight`/`DPLGetWrappedTextLineCount` for measuring wrapped height/line count
  before drawing. This means the CLI-side wrap/clip work is very likely a matter of calling the
  right native entry point with the right parameters (to be confirmed empirically, the same way
  the original rotation story empirically confirmed `DrawRotatedText`'s anchor behavior), not
  writing a word-wrap algorithm from scratch. GDI+ has an equivalent native capability on the
  canvas side (`Graphics.DrawString`/`MeasureString` accept a bounding `RectangleF` and wrap
  automatically) — so neither side needs custom line-breaking, either.
 - **Real architectural risk found, not assumed:** `EnvelopeRenderer.Desktop`/`EnvelopeRenderer.
  Desktop.Core` do not reference the Debenu vendor library at all (confirmed: no `Debenu` reference
  in either `.csproj`, and `EnvelopeRenderer.Desktop.csproj`'s own comment explicitly forbids
  referencing `EnvelopeRenderer.Cli`'s internals) — the desktop app only launches the CLI as a
  child process. This means the canvas/preview's GDI+-based wrap and the CLI's Debenu-based wrap
  are two genuinely independent text engines with no shared line-breaking code path, unlike every
  prior "shared TextResolver" fix in this epic, which only had to agree on *what string* to
  resolve, not *how a rendering engine breaks it into lines*. Different font metrics/kerning
  between GDI+ and Debenu's internal engine could wrap at a different point for the same
  text/width/font. This is scoped as an accepted, documented approximation (mirroring
  `MeasureElement`'s existing "design-time visual approximation" language) rather than a blocking
  problem — the canvas/preview do not need pixel-for-point wrap parity with the final PDF, only a
  close-enough visual approximation, with the PDF itself remaining the source of truth.
 What's genuinely new and large regardless of those findings: `TextElementLayout`/`TemplateElement`
 gain two new persisted properties with independent CLI/desktop implementations (the established
 "optional attribute, default preserves old behavior" pattern, but a bigger surface than any prior
 single-attribute addition since two properties are added at once and both feed real render logic,
 not just a cosmetic default); `TextDraw`/`DebenuPdfRenderer.AddPage` need new branching logic
 (wrap/clip call vs. today's single `DrawText` call) plus real empirical vendor-API investigation of
 the entry points above; `RotationPivotCalculator`'s bounding-box-height input needs to become
 "wrapped/clipped height" instead of raw single-line measured height wherever a width/height is
 set (deferred to the next story below, but the model change here is what that story builds on);
 and the canvas needs a real geometry change (rectangle-bounded `DrawString` instead of point-based)
 plus a coexistence design for the new handle(s) alongside the just-shipped font-size handle.
 Comparable in scope to the 13-point "Mix static text and CSV fields" story (a new persisted
 concept plus new render/canvas logic across the same three surfaces), landing at the same size for
 similar reasons — sized here, not higher, specifically *because* rotation composition and the live
 indicator are carved out to the dependent story below rather than bundled in, keeping this story
 independently valuable and shippable on its own (a resizable box that genuinely wraps/clips in the
 real PDF) without requiring the polish layer first.
 **Dependencies:** None blocking (font-size scaling, rotation, mixed content, and the preview panel
 are all Done). Should land before the Address Control extension story, the rotated-wrap/indicator
 story immediately below, and before "Warn on text overflow before render."
 ### Support rotated wrapped text and a live wrap/clip indicator for text elements - Status: Ready
 **Card**
 As a **print operator**, I want a rotated text element's wrapped/clipped content to behave exactly
 like an unrotated one, and to see at a glance when a box is currently wrapping or clipping content,
 so that I don't have to guess or rotate back to check.
 **Conversation notes**
 - Split out from the story above during Sprint 9 refinement (`dev-team` sizing, 2026-10-26): the
  combined scope (persisted geometry + native wrap/clip render + rotation composition + a new
  visual indicator) was too large to responsibly size as one story and land in a single sprint.
  This story is the "polish" layer on top of the previous story's core capability, the same
  fallback-split shape "Mix static text and CSV fields" itself once offered (core vertical slice
  now, polish layer next) rather than a new pattern invented here.
 - Rotation and wrapping have never coexisted in this product before. Confirmed by code inspection:
  Debenu exposes `DPLDrawRotatedMultiLineText` alongside the unrotated wrap primitives found in the
  previous story's sizing note — the empirical question for `dev-team` to resolve here is whether
  that entry point (or `DPLGetWrappedText` to pre-compute line breaks, then feeding each line
  through the existing per-line rotated-anchor `TextDraw` path Sprint 6 already established) is the
  right fit, mirroring how the original rotation story empirically tested `DrawRotatedText` before
  committing to a design.
 - The box, its wrapped lines, and the wrap/clip indicator itself must all rotate together as one
  rigid unit — the same rigid-group approach Address Control rotation (Sprint 8) already
  established, reused here rather than invented fresh.
 - A visible on-canvas/preview indicator (e.g., a colored border or badge, in the same visual
  language as the existing dashed-orange unmapped-column warning) shows when the *current* sample
  record's content is actually wrapping and/or being clipped for the selected element — the "warn
  this is happening" half of the original request, distinct from and in addition to the full-CSV
  pre-render validation pass in "Warn on text overflow before render" below.
 **Confirmation (Acceptance Criteria)**
 - [ ] A rotated element with a set width/height wraps and rotates consistently across all three
      surfaces (CLI render, canvas, preview panel) — the box and its wrapped lines rotate together
      as one rigid unit, never independently.
 - [ ] The canvas and preview panel visibly indicate, for the currently previewed sample record,
      when the element's content is wrapping and/or being clipped, in both rotated and unrotated
      states.
 - [ ] The wrap/clip indicator itself rotates together with the box rather than staying axis-aligned
      while the box it describes is rotated.
 - [ ] No regression to the previous story's unrotated wrap/clip behavior or to any other rotation
      acceptance criteria already shipped (Sprint 4, Sprint 6, Sprint 8).
 **Estimate:** 8 points (`dev-team`, 2026-10-26) — smaller than the previous story since the
 persisted model, the native-call investigation pattern, and the shared text-resolution routine are
 already established; the genuinely new work here is narrower: one more empirical vendor-API
 question (rotated wrap composition) plus a new, but visually-precedented (dashed-orange-style),
 indicator. Comparable to "Rotate elements by dragging a handle on the canvas" (5 points) in shape
 but larger, since rotation there had a direct existing pattern to copy for its bidirectional-sync
 plumbing, whereas rotated wrap composition here has no existing precedent in this codebase at all.
 **Re-sizing flag (Sprint 9, 2026-10-27, `dev-team`):** while implementing the previous story, the
 "one more empirical vendor-API question" this estimate was built around got answered as a
 byproduct, not deferred to this story as planned — `DebenuPdfRenderer` already calls Debenu's
 native `DrawRotatedTextBox` for a rotated boxed draw (confirmed via a real, licensed probe:
 rotation and wrapping compose correctly in one native call, no manual pre-wrap-then-rotate-per-line
 synthesis needed). AC1 (rotated wrap consistency across CLI/canvas/preview) is very likely already
 satisfied by the previous story's shipped code, not new work. What's left for this story is
 narrower than sized: primarily the live wrap/clip visual indicator (AC2/AC3) and confirming/testing
 the rotated case explicitly rather than building it. Not re-sized here — flagged for
 `product-owner`/`dev-team` to re-confirm at the next backlog refinement before this is committed to
 a sprint, rather than silently shipping at a stale, likely-inflated estimate.
 **Dependencies:** Depends on "Add an adjustable width and height with text wrapping to static and
 dynamic text elements" (above, same epic — Done, Sprint 9).
 ### Add an adjustable width and height with text wrapping to Address Control lines - Status: Ready (needs a Development Team design decision noted below; depends on both stories above)
 **Card**
 As a **print operator**, I want an Address Control's lines to wrap and clip within a real box the
 same way a standalone text element does, so that long address lines behave predictably instead of
 running off the control's existing width with no vertical limit.
 **Conversation notes**
 - Confirmed with the user (2026-10-26): same width+height, wrap-then-clip, warn-when-happening
  behavior as the standalone-element story above, applied to Address Control.
 - `AddressControlLayout.Width` already exists (Sprint 6) but is documented as a resize-handle-only
  value with no render-time effect (Sprint 6 Review scope note) — this story is what finally gives
  it real wrap effect, matching the standalone story's engine rather than inventing a second one.
 - `AddressControlLayout.Height` does not exist as an independent, settable value today — it is
  always computed from the sum of each line's own `FontSize`/`LineSpacingMultiplier` (Sprint 6/8).
  This story must decide how an operator-set Height interacts with that auto-computed value —
  most likely, Height becomes an explicit override/cap once set, with the existing auto-computed
  value remaining the default when no explicit Height has been set, so every pre-existing template
  (no Height attribute) keeps its current auto-computed sizing unchanged.
 - Reuses the standalone story's wrap/clip engine and shared text-resolution routine — this story
  should not reimplement wrapping, only apply it per-line within the control's existing line-list
  model and its existing whole-control rigid-group rotation (Sprint 8).
 - Must interact correctly with `AddressLineCollapser`'s existing blank-line collapse: a collapsed
  line contributes no height, same as today; wrap/clip only applies to lines that are actually
  visible for the given record.
 - Development Team design decision: whether every line shares the control's one Width (current
  behavior for drawing) with each line independently wrapping/clipping within its own vertical
  slice of the control's Height, or some other allocation — flagged for sizing-time investigation,
  not decided here.
 **Confirmation (Acceptance Criteria)**
 - [ ] An Address Control's `Height` is independently settable (draggable handle and/or properties
      panel field), defaulting to today's auto-computed value when not explicitly set so every
      pre-existing template renders unchanged.
 - [ ] A line's content that exceeds the control's `Width` wraps within that line's own space,
      using the same wrap engine and shared text-resolution routine as the standalone-element
      story.
 - [ ] Wrapped content that would push the control's total content past its set `Height` is
      clipped, consistently across the CLI render, canvas, and preview panel.
 - [ ] The canvas and preview panel visibly indicate wrapping/clipping for the control against the
      currently previewed sample record, in the same visual language as the standalone-element
      story's indicator.
 - [ ] A rotated Address Control with wrapping/clipping content rotates as one rigid unit exactly
      like the unrotated case, consistent with the whole-control rotation already shipped
      (Sprint 8).
 - [ ] Blank-line collapse (existing behavior) and wrap/clip interact correctly: a collapsed line
      contributes no height and is not part of any wrap/clip calculation.
 **Estimate:** 8 points (`dev-team`, 2026-10-26) — smaller than the standalone-element story since
 it reuses that story's persisted-geometry pattern, native wrap/clip calls, and (once the rotated-
 wrap story above lands) rotation composition, rather than reinventing any of them. Real new scope
 specific to this story: the auto-computed-vs-explicit-`Height` interaction (a genuine design
 decision, not a mechanical copy) and per-line wrap allocation within the control's shared `Width`.
 Sized the same as "Group lines into a single, movable Address Control" reused Sprint 5's run model
 but still carried genuine new composite-element scope — the same shape here: real reuse, real
 residual scope, not a trivial pass-through.
 **Dependencies:** Depends on "Add an adjustable width and height with text wrapping to static and
 dynamic text elements" and "Support rotated wrapped text and a live wrap/clip indicator for text
 elements" (both above, same epic) — sequenced after both so Address Control's rotation-composed
 wrap/clip and indicator can directly reuse a proven pattern rather than prove it here first.
 ### Render an accurate, record-specific preview of the current template - Status: Done
 **Sprint Review verification (Sprint 7, 2026-10-19):** Product-owner verdict: accepted, all 6 acceptance criteria met, verified independently via direct code and test-file inspection rather than dev-team's report alone. AC1 (resolved values for standalone elements and Address Control lines): confirmed by reading `TemplatePreviewBuilder.Build`/`BuildAddressControlDraws`, which resolve every element and control line through the shared `TextResolver` and never emit a bracket token. AC2 (rotation pivot parity): confirmed `RotationPivotCalculator.Compute` is called identically from `CanvasElementEditor`, `TemplatePreviewControl.DrawItem`, and (per its class remarks) mirrors the CLI's `RotatedTextAnchorCalculator` rule; `RotationPivotCalculatorTests` directly proves two very different measured widths yield the same dynamic-content anchor. AC3 (collapse/mixed-content parity): confirmed `TemplatePreviewBuilderTests` mirrors `RenderEngineTests`' exact scenario shapes (collapsible-blank-line shift, mixed literal/field concatenation, Address Control expansion and collapse, z-order) with matching expected values, not just superficially similar test names. AC4 (auto-refresh): traced the actual wiring in `TemplateDesignerForm` — `TemplateCanvasControl.ElementsChanged` (raised on drag, rotate, resize, add/remove, and every properties-panel commit including content/rebind/X/Y/angle) calls `_previewControl.Invalidate()`, and `TemplatePreviewControl.OnPaint` re-resolves against the live document on every repaint rather than a cached draw list — this is a real "no separate rebuild step" design, not a claim. AC5 (clear failure message): confirmed `TemplatePreviewBuilder.Build`'s pre-flight unknown-column check produces a specific per-column message surfaced by `TemplatePreviewControl.DrawMessage`, and `TemplatePreviewBuilderTests.Build_UnknownColumnReference_FailsWithSpecificMessage`/`Build_AddressControl_UnknownFieldRunColumn_FailsWithSpecificMessage` cover both standalone and Address Control cases. AC6 (built-form smoke): dev-team's reflection-harness/screenshot evidence was not independently re-run in this review session (no shell/build tool access available) — treated as a disclosed evidence-depth caveat, not a gap, since the underlying rotation-pivot-stability and message-on-failure claims it makes are independently corroborated by the code and unit tests above. Test-file inspection confirms new coverage (`TextResolverTests`, `RotationPivotCalculatorTests`, `TemplatePreviewBuilderTests`) is real and substantive, not thin.
@@ -164,36 +506,49 @@ it") still holds — navigation is now automatic rather than button-triggered, w
 correction to *how* AC1 is satisfied, not a change to AC1 itself; ACs 2-4 are unaffected. See
 `backlog/sprints/sprint-7.md`'s post-review fix note for verification detail.
 ### Warn on text overflow before render - Status: Not Ready (open question, see below)
 ### Warn on text overflow before render - Status: Not Ready (blocked on the three wrap/clip stories above; the product question itself is resolved)
 **Card**
 As a **print operator**, I want to see overflow warnings before generating the PDF, so that I can
 correct layouts before production time is wasted.
 **Conversation notes**
 - Missing fonts are blocking; overflow is warning-driven unless otherwise decided later.
 - The first implementation can focus on text field overflow.
 - Warning details should help the operator find the affected field or record.
 - **Blocking open question (product-owner, 2026-10-16):** "overflow" has no defined meaning in
  the current product model. Standalone `TextElementLayout` elements have no width/bounding
  concept at all (confirmed by code inspection — no `Width` property exists). Only
  `AddressControlLayout.Width` exists today, and it is presently just a resize handle, not an
  enforced wrap/clip boundary (Sprint 6 review scope note). Before this story can be sized or
  written with testable ACs, the human product owner needs to decide: (a) does "overflow" mean a
  resolved string running past the *page* edge only (works today, no model change needed), or
  (b) does it require adding a real per-element/per-control width boundary with wrap or clip
  behavior first (a separate, prerequisite story, likely landing in epic 6, Layout Efficiency, or
  as a new epic-4 story) — in which case this story is blocked on that prerequisite. This is a
  business/product definition, not an engineering call, so `product-owner` is not deciding it
  unilaterally.
 - **Open question resolved (human product owner, 2026-10-26):** option (b) from the 2026-10-16
  question below — a real per-element/per-control width *and* height boundary, with wrap-then-clip
  behavior — is now being built as the two dependent stories immediately above. "Overflow" for
  this story's purposes means: a record whose resolved content, once wrapped within the element's
  or Address Control's set width, still exceeds its set height and gets clipped. This story is the
  full-CSV, all-records pre-render validation pass on top of that wrap/clip engine — distinct from
  (and in addition to) the two stories above's own live, single-sample-record canvas/preview
  indicator.
 - ~~**Blocking open question (product-owner, 2026-10-16):** "overflow" has no defined meaning in
  the current product model...~~ — resolved, see above. Kept here (struck through) rather than
  deleted so the reasoning trail stays visible, per this backlog's own convention of not silently
  rewriting history.
 **Confirmation (Acceptance Criteria)**
 - [ ] The pre-render validation identifies text overflow scenarios for the current template and
      CSV, once the human product owner has defined what "overflow" means against the current (or
      an updated) element model.
 - [ ] The operator can review warnings before starting generation.
 - [ ] Blocking versus warning behavior is clearly distinguished in the UI.
 - [ ] Warning output identifies enough context for the operator to correct the issue.
 **Estimate:** Not yet sized — blocked on the open question above.
 **Dependencies:** Depends on preview and mapping foundations; may additionally depend on a
 per-element/control width-boundary story if the human product owner chooses option (b) above.
 - [ ] The pre-render validation scans every record in the loaded CSV and identifies any element or
      Address Control whose wrapped content would be clipped for that record, using the same
      wrap/clip engine the two stories above establish (not a separate, potentially divergent
      overflow calculation).
 - [ ] The operator can review the full list of warnings (which record, which element/control)
      before starting generation.
 - [ ] Blocking (e.g., missing font, unmapped column) versus warning (overflow) behavior is clearly
      distinguished in the UI — overflow never stops a render the way a blocking error does.
 - [ ] Warning output identifies enough context (record number, element/control identity) for the
      operator to correct the issue without re-deriving it themselves.
 **Estimate:** Provisional 5 points (`dev-team`, 2026-10-26) — the story's own shape (iterate every
 record, check a condition, collect and surface a list of warnings, distinguish warning from
 blocking in the UI) is knowable by analogy to two already-Done patterns at this scale: the
 existing unmapped-column pre-flight check in `RenderEngine` (a per-page validation before any
 render starts) and "Jump to a specific record number" (5 points, a full-file streaming scan).
 Kept explicitly provisional, not firm, because it assumes the three stories above land roughly as
 scoped — re-confirm once their actual data model and wrap/clip-detection API shape exists, the
 same discipline "Investigate and address high-volume render throughput degradation" used for its
 own assumption-qualified estimate.
 **Dependencies:** Depends on "Add an adjustable width and height with text wrapping to static and
 dynamic text elements," "Support rotated wrapped text and a live wrap/clip indicator for text
 elements," and "Add an adjustable width and height with text wrapping to Address Control lines"
 (all three above, same epic).
--- a/backlog/epics/06_layout_efficiency_and_operator_tooling.md
+++ b/backlog/epics/06_layout_efficiency_and_operator_tooling.md
@@ -20,6 +20,25 @@ prerequisite gaps were found and are called out below rather than papered over:
  Control lines) currently applies directly and irreversibly to the in-memory document. This is
  flagged as the single highest-uncertainty story in the backlog — see its sizing note.
 ## Re-verification note (2026-10-26, Sprint 9 refinement)
 Before trusting this epic's "Ready" labels going into Sprint 9, `product-owner` re-checked them
 against the current codebase rather than assuming the 2026-10-16/10-19 findings still hold
 verbatim — real code changed since then (the font-size resize handle and `IsInteracting`
 smoothness fix, both post-Sprint-8). Confirmed no material change to either Ready story's core
 scope: `CanvasElementEditor.Selected`/`TemplateCanvasControl._selectedAddressControl` are still
 each a single reference (multi-select still does not exist), and the new resize-handle code is
 orthogonal to selection — it would simply be hidden/disabled for a multi-item selection, the same
 as the existing rotate handle already implicitly would be. One small, honest addition: "Undo and
 redo layout changes"'s mutation-entry-point list should also include the new font-size resize-drag
 (`CanvasElementEditor.BeginResizeDrag`/`ResizeDragTo`) alongside move and rotate — the same shape
 of mutation as those two, not a new category of complexity, so this does not change that story's
 13-point estimate. Also flagging forward (not resolved here, not urgent): once epic 4's new
 width/height wrap/clip stories land, a standalone element's "bounding box" for alignment/
 distribution purposes may become an explicit `Width`/`Height` rather than purely measured text —
 "Align and distribute multiple elements"' own bounding-box assumption should be re-checked at
 whichever of the two epics actually lands first, since neither currently depends on the other.
 ## Stories
 ### Snap elements to grid and guides - Status: Done
--- a/backlog/epics/08_composite_address_controls.md
+++ b/backlog/epics/08_composite_address_controls.md
@@ -77,6 +77,8 @@ Comparing to Story 1 and to the largest Done stories: this story's core "new com
 ### Rotate the whole Address Control as a single unit - Status: Done
 **Sprint Review verification (Sprint 8, 2026-10-26):** Product-owner verdict: accepted, all 6 acceptance criteria met, verified independently rather than rubber-stamping dev-team's own report. Read `TemplateLayoutXmlSerializer.CreateAddressControl`/`TemplateXmlParser.ParseAddressControl` directly and confirmed the `angle` attribute is written/parsed on both sides with a `0` default (AC6). Ran the full test suite directly (`dotnet test`): 433/433 passing (326 desktop, 107 CLI) — exactly matching dev-team's reported count for the sprint's combined total, not approximately. Confirmed by direct file inspection that the claimed new classes genuinely exist and are unit-tested: `EnvelopeRenderer.Desktop.Core/Design/PointRotation.cs` and its `PointRotationTests.cs`, plus `AddressControlLayout.BoxCenter`'s pure dependence on authored `X`/`Y`/`Width`/`Height` (no record input) satisfying AC4's pivot-stability requirement. AC1-3 and AC5 (properties-panel wiring, rigid-group rotation across canvas/preview/render, rotated-hit-test) are accepted on dev-team's live built-`.exe` screenshot evidence (properties-panel angle field, canvas/preview/CLI-PDF-content-stream comparison, and simulated real mouse-click hit tests at rotated vs. unrotated positions) — this review session did not re-run the desktop app itself, so that evidence is trusted rather than re-observed, consistent with how prior reviews have disclosed the same limitation when it applies. The new Low-impact technical debt entry (2026-10-26, pre-existing Sprint 6 Address Control hit-test/move/resize logic remains untestable WinForms-only code) is confirmed reasonable to leave open: it is a testability gap with no known behavioral defect, and this sprint's own new rotation math was correctly extracted to unit-tested classes instead.
 **Development verification (Sprint 8 Batch 1, 2026-10-26):** All 6 acceptance criteria met. AC1 (set via the properties panel's existing angle field): met — `_angleInput` is now enabled and wired for a selected Address Control (`TemplateDesignerForm.SetSelectedRotationAngle`/`RefreshPropertiesPanel`), same -360.0/360.0, 0.1-precision convention as standalone elements, confirmed live by typing a value into the real built control. AC2 (whole control rotates as one rigid unit): met — `RenderEngine.BuildAddressControlDraws` and `TemplatePreviewBuilder`'s equivalent rotate each visible line's own anchor as a rigid group around the control's fixed `BoxCenter`, and `TemplateCanvasControl.DrawAddressControl` wraps its entire paint call (box, lines, highlight fills, selection border, resize handle) in one GDI+ transform around the same pivot; confirmed visually via built-`.exe` screenshots showing the whole block rotate together. AC3 (consistent across CLI PDF, canvas, and preview): met — a real CLI render of a 20-degree-rotated template was confirmed via direct PDF content-stream inspection (`cos(20)`/`sin(20)` rotation matrices present, absent entirely for an unrotated control), and canvas/preview screenshots of the same template show the identical 20-degree (then 65-degree, set live via the panel) rotation on both surfaces. AC4 (pivot stable across records regardless of collapse): met — `BoxCenter` is a pure function of authored `X`/`Y`/`Width`/`Height`/line font sizes with zero record input, verified by direct unit tests on both `TemplateAddressControl.BoxCenter`/`AddressControlLayout.BoxCenter` and by CLI/desktop regression tests rendering two records (one collapsing a blank optional line, one not) and asserting the unaffected first line's rotated position is bit-for-bit identical both times. AC5 (rotated control remains correctly click-selectable at its rotated position): met — `HitTestAddressControl`/`HitTestAddressResizeHandle` (and the resize-drag math itself, fixed as a related correctness issue found during implementation) now rotate the click point backward into local space before testing; live-verified via simulated real mouse clicks through the actual built `OnMouseDown`/`OnMouseUp` handlers, confirming a click at the control's real (forward-rotated) on-screen position selects it and a click at its old un-rotated position does not. AC6 (persisted as `angle` on `<addressControl>`, default 0, backward compatible): met — new optional attribute in both `TemplateLayoutXmlSerializer` and `TemplateXmlParser`, round-trip and default-omitted tests passing, `TEMPLATE_FORMAT.md` updated. Test suite grew to 422/422 (107 CLI, 315 desktop). New Low-impact technical debt logged: the pre-existing (Sprint 6) Address Control hit-test/move/resize logic remains embedded directly in `TemplateCanvasControl` (WinForms) rather than a `CanvasElementEditor`-equivalent, so it stays smoke-tested only — this story's own *new* rotation math was deliberately extracted to unit-tested `Desktop.Core` classes (`AddressControlLayout.BoxCenter`/`TemplateAddressControl.BoxCenter`/`PointRotation`), but retroactively refactoring the older code was out of this story's scope.
 **Epic reopened (2026-10-19):** this epic was Done outright after Sprint 6 (both stories above shipped). The human product owner has now confirmed the whole-control rotation capability that Sprint 6 Review explicitly logged as out of scope ("whole-control rotation remains an already-noted out-of-scope candidate, not a missed criterion" — see `backlog/backlog.md`) is wanted. This story and the dependent drag-handle story below reopen the epic.
@@ -113,6 +115,8 @@ Net: a materially smaller vendor-integration footprint (no `DebenuPdfRenderer` c
 ### Rotate the whole Address Control by dragging a handle on the canvas - Status: Done
 **Sprint Review verification (Sprint 8, 2026-10-26):** Product-owner verdict: accepted, all 5 acceptance criteria met. Confirmed `AddressControlRotateHandle.cs` and `AddressControlRotateHandleTests.cs` exist as claimed and reuse `CanvasElementEditor.HandleOffsetPoints`/`HandleHitRadiusPoints` (AC1's visual-consistency requirement) by direct file inspection. AC3 (bidirectional properties-panel/handle sync) is accepted as "for free" from Batch 1's wiring per dev-team's own note — a plausible, low-risk claim given Batch 1's `RefreshPropertiesPanel`/`SetSelectedRotationAngle` plumbing this review already inspected for the prior story, though not independently re-driven live this session. AC2, AC4, and AC5 (live drag rotation, persistence-on-release, non-interference with line drill-in/move/resize) are accepted on dev-team's live built-`.exe` evidence (fresh screenshots per the Sprint 7 retrospective carry-in, correctly not reused from Batch 1) — trusted rather than re-observed, same disclosed limitation as the sibling story above. Full suite re-run directly confirms 433/433 (see sibling story's note) with 11 of those tests specifically the new `AddressControlRotateHandleTests`. **Sprint 8 goal met in full**: whole-Address-Control rotation now works end-to-end (properties panel and canvas drag handle) and stays record-stable and visually consistent across the canvas, the Sprint 7 preview, and the real CLI-rendered PDF, delivering the human product owner's Sprint 6 Review reversal. The Composite Address Controls and Mixed-Content Text epic is Done outright again. No new backlog item required beyond the one Low-impact technical debt item already logged and reviewed above.
 **Development verification (Sprint 8 Batch 2, 2026-10-26):** All 5 acceptance criteria met. AC1 (draggable rotate handle shown on a selected control): met — `TemplateCanvasControl.DrawAddressRotateHandle` paints the handle (same SeaGreen-dot/dashed-line/white-outline style as the standalone-element handle) inside `DrawAddressControl`'s existing rotation transform, confirmed visually via a built-`.exe` screenshot of a freshly-created, selected Address Control. AC2 (dragging updates the angle live, rotating box/lines/overlays together): met — a new framework-free `AddressControlRotateHandle` class (Desktop.Core) provides the hit-test/drag-angle math; `TemplateCanvasControl` wires a new `_isRotatingAddressControl` gesture flag through `OnMouseDown`/`OnMouseMove`/`OnMouseUp`; live-verified via a simulated real mouse-down-drag-move (mid-gesture, before mouse-up) through the actual built handlers, screenshotted showing the whole block rotated together at that in-progress angle. AC3 (properties panel and canvas handle stay bidirectionally synced): met — for free, via Batch 1's existing `RefreshPropertiesPanel`/`SetSelectedRotationAngle` wiring; confirmed live both directions (drag updated the real `_angleInput` control's displayed value, and typing a new value into that same control after a drag correctly moved the handle). AC4 (releasing the drag persists the angle the same way a typed value does): met — `RotationAngle` is set directly on the shared `AddressControlLayout` model during the drag itself (matching how a typed value is applied), confirmed unchanged after mouse-up in the live smoke. AC5 (doesn't disturb line drill-in or existing move/resize): met — confirmed live that the drilled-in address line index was unchanged immediately after a full rotate-drag gesture, and that the control's existing whole-unit move continued to work correctly afterward. Tests: 11 new `AddressControlRotateHandleTests` covering local/world handle position (including the rotated-vs-unrotated-position discrimination that proves the hit test is genuinely rotation-aware, not just "moved"), drag-to-angle math, the pivot-exactly-under-pointer no-op case, and a round-trip angle-drives-position consistency check. Test suite grew to 433/433 (107 CLI, 326 desktop). Live verification used a **fresh** screenshot set for this batch (not reused from Batch 1's), per the Sprint 7 retrospective carry-in this sprint's own plan explicitly reinforced.
 **Card**
--- a/backlog/sprints/sprint-8-retrospective.md
+++ b/backlog/sprints/sprint-8-retrospective.md
@@ -0,0 +1,72 @@
 # Sprint Retrospective
 **Sprint:** 8
 **Date:** 2026-10-26
 **Facilitated by:** `scrum-master`, per `process/05_sprint_retrospective.md`
 **Inputs used:** `backlog/sprints/sprint-8.md` (Daily Scrum Log + Execution Order + Notes), `backlog/backlog.md` (Sprint 8 refinement, planning, and Review outcome notes), `backlog/epics/08_composite_address_controls.md`, `logs/technical_debt_log.md`, `logs/impediment_log.md`, `logs/process_improvement_log.md`, `backlog/sprints/sprint-7-retrospective.md` (for follow-through check). No live human team to poll in real time; subjective signals are synthesized from dev-team's daily-scrum notes and product-owner's independent review notes. This session (top-level, acting as `product-owner` during review) had direct shell/build access and ran `dotnet test` itself, confirming 433/433.
 ## Signals
 **Objective:**
 - 2/2 committed stories Done (13/13 points), sprint goal assessed "met in full" at Sprint Review (`backlog/backlog.md`, Sprint 8 Review outcome) — the human product owner's Sprint 6 Review reversal is delivered end-to-end.
 - Test suite grew from 422/422 (Batch 1) to 433/433 (Batch 2), independently re-confirmed by a direct `dotnet test` run during Sprint Review (326 desktop, 107 CLI) — matching dev-team's reported count exactly.
 - Zero new impediments; the two pre-existing open ones (asset path strategy, UNC timeout/retry) remain non-blocking and untouched, as expected since neither story touches image assets or network paths.
 - One new Low-impact technical debt item logged and reviewed (pre-existing Sprint 6 Address Control hit-test/move/resize logic remains WinForms-only and untestable by unit tests, unlike this sprint's own newly-extracted rotation math) — correctly scoped as a testability gap with no known behavioral defect, not swept under the rug.
 - Live verification: a reflection-driven built-`.exe` harness drove the real `TemplateDesignerForm`/`TemplateCanvasControl`/`TemplatePreviewControl` for both batches — real CLI PDF content-stream inspection proving actual rotation matrices, simulated real mouse clicks/drags through the actual event handlers, and fresh (not reused) full-form screenshots per batch.
 **Subjective:**
 - Dev-team correctly identified, ahead of implementation, that the Address Control's box geometry (author-set `Width`, font-derived `Height`) is architecturally different from the standalone-element rotation defect fixed in Sprint 6 — avoiding porting an inapplicable anchor-pivot workaround into a story that didn't need it.
 - Dev-team deliberately did not retroactively refactor Sprint 6's older, smoke-tested-only Address Control interaction code while adding this sprint's new rotation math as unit-tested classes — a scoping call that was named and logged as debt rather than silently left inconsistent.
 - Product-owner's Sprint 8 review had real shell/build access this time and used it directly (a live `dotnet test` run plus reading the actual persistence/class code), rather than substituting a static count as Sprint 7's review had to.
 ## What Went Well
 - **Fresh full-form screenshot per batch, honored exactly.** Sprint 7's retrospective named a near-miss (Batch 2 reusing Batch 1's screenshot after adding a new control). This sprint's Batch 2 explicitly captured a new screenshot set rather than reusing Batch 1's — direct, named follow-through on the prior sprint's own carry-in, not just a coincidence.
 - **Deliberate, reasoned under-commit (13 points) paid off cleanly** — the same posture Sprint 5 took around its own largest story. Sprint 8 finished both stories with no scope cut and no carry-over, and scrum-master's own planning note explicitly weighed and rejected the higher-risk 23-point alternative (pairing with epic 6's foundational selection-model rework) rather than defaulting to it for the sake of using proven-idle capacity.
 - **Honest, scoped technical debt logging.** Rather than either silently leaving Sprint 6's older Address Control code un-mentioned or overstating this sprint's own scope to "fix everything," dev-team logged the testability gap precisely, named why it was out of scope for this story, and proposed a concrete future direction (`AddressControlEditor` mirroring `CanvasElementEditor`).
 - Product-owner's Sprint 8 review had shell/build access and used it for a live `dotnet test` run and direct reads of the actual persistence code and new test files, rather than trusting dev-team's report alone — full independent verification, not a rubber-stamp.
 ## What Didn't Go Well
 - Nothing rises to a "didn't go well" item this sprint. One minor test-design note (not a product defect, named honestly in dev-team's own Batch 2 log): a later step in the same live-verification harness run clicked the control's body to test whole-unit move, which correctly re-picked the drilled-in line under that click point per pre-existing Sprint 6 design — unrelated to the rotate-drag itself, which was already separately confirmed mid-drag. Worth naming only because it shows the harness's own test design was scrutinized rather than glossed over.
 ## Patterns / Insights (Prioritized)
 1. **(Team-level)** The discipline of extracting genuinely new math into framework-free, unit-tested `Desktop.Core` classes — while explicitly not retroactively refactoring older, still-working code in the same area — is now a repeated, named pattern (this sprint's `PointRotation`/`AddressControlRotateHandle` alongside the still-open Sprint 6 Address-Control-interaction debt item). This is a sound, proportional practice on its own, but it means Address-Control-specific interaction code now has two different testability tiers (new: unit tested; old: smoke tested only). Worth a deliberate look before or during whatever story next touches Address Control interaction machinery in earnest (candidate: epic 6's multi-select work, if it ever needs to select an Address Control as part of a multi-select group), rather than letting the gap grow a third and fourth time.
 2. **(Process-level)** The Sprint 7-logged "PO review tooling-access" watch item (`logs/process_improvement_log.md`, 2026-10-19) did not recur this sprint — this session's product-owner review had shell/build access and ran `dotnet test` directly. This is a useful first positive data point (the gap is intermittent/session-dependent, not a persistent structural issue), but one clean sprint doesn't yet prove it's resolved, since the underlying cause (session tooling availability) isn't under this team's control. Keep watching rather than closing outright.
 3. **(Team-level, minor)** Sprint 7's built-form-smoke carry-in item aimed at epic 6's multi-select/align pair never got triggered this sprint, since Sprint 8 committed epic 8's rotation pair instead. This isn't a drop — the action item simply didn't apply yet — but it needs to explicitly carry forward to whichever sprint actually pulls that pair (recommended Sprint 9), not be quietly treated as satisfied.
 ## Action Items (Add These To Sprint 9's Plan)
 - [ ] Carry forward, unchanged, the still-untriggered Sprint 7 action: when epic 6's multi-select/align pair is pulled, apply the built-form-vs-canvas-only smoke rule explicitly per story ("Select multiple elements..." likely canvas-only; "Align and distribute..." likely needs a full smoke if it adds new toolbar/menu affordances) — owner: dev-team — due: whichever sprint commits that pair.
 - [ ] Continue the fresh-full-form-screenshot-per-batch discipline for any multi-batch sprint where a later batch changes a form an earlier batch already screenshotted — owner: dev-team — due: ongoing.
 - [ ] Before or during whatever story next has multi-select or other interaction logic touch Address Controls, evaluate whether to extract the pre-existing Sprint 6 hit-test/move/resize logic (`TemplateCanvasControl`) into a unit-tested `AddressControlEditor`-equivalent (per the 2026-10-26 technical debt entry's own candidate direction), rather than letting a third interaction feature build on top of untestable code — owner: dev-team / `qa-tech-debt` — due: Sprint 9 backlog refinement (evaluate, not necessarily implement).
 ## Deferred / Lower-Priority Ideas
 - Address Control line-overlap-at-small-font-sizes (Low-impact, canvas/preview cosmetic only, 2026-10-19 entry) — unchanged this sprint, revisit only if reported as more than cosmetic.
 - The still-open product question on "Warn on text overflow before render" (epic 4) remains parked for the human product owner; not blocking Sprint 9.
 - The 1,000,000-record file-size risk (Medium-impact, 2026-09-21 entry) remains untouched; no story has committed to that scale.
 ## Follow-Up On Previous Retro's Actions
 All three of Sprint 7's retrospective action items, checked against `backlog/sprints/sprint-8.md` and `backlog/backlog.md`'s Sprint 8 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 this sprint. Epic 6's pair was not pulled into Sprint 8 (scrum-master's planning note explicitly chose the epic 8 rotation pair alone over pairing with epic 6, for reasons unrelated to this action item). This is not a drop, but it must not be silently treated as satisfied — re-added above as an unchanged Sprint 9 action.
 2. **Fresh full-form screenshot per batch, not reused from an earlier batch in the same sprint** — Applied and directly confirmed. `backlog/sprints/sprint-8.md`'s Batch 2 entry explicitly states "Took a **fresh** full-form screenshot for this batch (not reused from Batch 1)" — the exact discipline named after Sprint 7's near-miss, now demonstrated rather than merely stated as intent.
 3. **If product-owner's Sprint 8 review again lacks shell/build access, disclose it and arrange an independent cross-check** — Not triggered, in the team's favor. This sprint's product-owner review had shell/build access and used it directly for a live `dotnet test` run (433/433) and direct source reads, so there was no gap to disclose. The underlying intent of the action item (don't let reduced verification depth go unnoticed) is satisfied by the fact that full-depth verification actually happened.
 Two of three items show genuine follow-through (one fully applied and confirmed, one non-applicable through no fault of the team); the third simply carries forward unchanged to whenever epic 6's pair is committed. No drops.
 ## Kit-Level Decision
 No kit edit proposed. The Sprint 7-logged PO-tooling-access watch item is updated in `logs/process_improvement_log.md` (see below) to reflect a clean sprint with no recurrence — reinforcing, not yet closing, the existing entry. Nothing new met `AGENTS.md`'s bar for a kit-level change this sprint.
 ## Anti-Patterns Checked
 - **No follow-through on prior retro actions:** Ruled out; see "Follow-Up" above — two of three items show genuine follow-through, the third is an honest non-applicability, not a drop.
 - **Blame-focused discussion:** Ruled out; the one named nuance (Batch 2's harness re-picking a drilled-in line during an unrelated move test) is described as an artifact of test design, not attributed to a person.
 - **Hidden mini-waterfall within the sprint:** Ruled out; both batches were designed, implemented, tested, documented, and live-verified within their own batch, consistent with every prior sprint.
 - **Avoiding an obvious known problem:** Ruled out; the Address-Control testability gap was named and logged rather than left implicit, and the still-open "text overflow" product question continues to be correctly flagged rather than guessed at.
 - **Status-theater:** Ruled out; evidence is concrete and independently checkable (exact test counts confirmed via a live `dotnet test` run, real PDF content-stream rotation matrices, real simulated mouse-drag angles, direct file/code inspection of claimed new classes).
 - **Review rubber-stamping (Sprint 3-named, resolved Sprint 4, checked again here):** Ruled out. Product-owner's Sprint 8 review independently re-ran the test suite, read the actual persistence code on both CLI and desktop sides, and confirmed the new unit-tested classes exist and do what's claimed, rather than accepting dev-team's narrative at face value.
--- a/backlog/sprints/sprint-9-retrospective.md
+++ b/backlog/sprints/sprint-9-retrospective.md
@@ -0,0 +1,72 @@
 # 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.
--- a/backlog/sprints/sprint-9.md
+++ b/backlog/sprints/sprint-9.md
@@ -0,0 +1,34 @@
 # Sprint Backlog
 **Sprint:** 9  **Dates:** 2026-10-27 - 2026-10-31
 **Sprint Goal:** Give static and dynamic text elements a real, independently adjustable width and height, so that content too long to fit wraps onto additional lines and is clipped (not silently overrun) once it exceeds the box — using Debenu's native wrap/box-drawing primitives for the real PDF and GDI+'s native rectangle-wrap for a close design-time approximation on the canvas and preview panel, directly answering the human product owner's "make the boxes longer" request.
 ## Committed Items
 | Story | Size | Status | Tasks |
 |---|---|---|---|
 | Add an adjustable width and height with text wrapping to static and dynamic text elements | 13 points | Done | - [x] Add `Width`/`Height` properties to `TextElementLayout` (Desktop.Core) and `TemplateElement` (CLI), both optional/nullable so a template saved before this story (no attributes) keeps today's unbounded behavior exactly <br> - [x] Persist the new `width`/`height` attributes on `<text>` in `TemplateLayoutXmlSerializer` and `TemplateXmlParser`, following the same "optional, default preserves old behavior" convention as `angle`/`collapsible`; round-trip tests on both sides <br> - [x] Empirically confirm Debenu's `DPLDrawWrappedText`/`DPLDrawTextBox` semantics against the real vendor DLL (alignment flag meaning, whether `DrawTextBox` clips to height on its own or only wraps to width) before committing to which entry point `DebenuPdfRenderer.AddPage` calls when a draw's width/height is set <br> - [x] Add optional `Width`/`Height` to `TextDraw` and branch `DebenuPdfRenderer.AddPage`: no width/height set -> today's plain `DrawText` call, unchanged; width/height set -> the confirmed wrap/box entry point (`DrawTextBox`/`DrawRotatedTextBox`, whose own return value directly reports lines drawn vs. `GetWrappedTextLineCount`'s total, so clipping needs no separate detection call) <br> - [x] Update `RenderEngine.BuildDraws` to pass the resolved element's `Width`/`Height` through to `TextDraw`, reusing the existing shared `TextResolver` for the text itself (no new resolution path) <br> - [x] Change `TemplateCanvasControl.DrawElement`/`MeasureElement` and `TemplatePreviewBuilder`'s standalone-element path to use GDI+'s rectangle-bounded `Graphics.DrawString`/`MeasureString` overloads when Width/Height is set, documented explicitly as a design-time approximation (not guaranteed pixel-for-point parity with the Debenu-rendered PDF, mirroring `MeasureElement`'s existing language) <br> - [x] Add a draggable width/height resize handle (and/or properties-panel numeric fields, mirroring the Address Control's X/Y/Width pattern) to `CanvasElementEditor`/`TemplateCanvasControl` — implemented as the *existing* font-size resize handle becoming context-sensitive (box mode vs. font-scale mode, checked once at drag-start via `HasBox`) rather than a second, visually-competing handle, a simpler resolution to the story's own open design question than either originally-considered option <br> - [x] Unit tests: model/persistence round-trip (CLI and desktop), `DebenuPdfRenderer` real-DLL wrap/clip regression tests (including one licensed, pixel-verified clipping test), canvas rectangle-measurement tests <br> - [x] Live actual built-form smoke: a real CLI render of a template with a narrow, short static and a narrow, short dynamic element against the real sample CSV, confirming actual multi-line wrapped output and clipped overflow in the produced PDF; a reflection-driven harness against the real built `TemplateDesignerForm` (real content TextBox, real Box width/height NumericUpDown fields, real mouse-driven resize-handle drag), with a real canvas screenshot |
 ## Daily Scrum Log
 | Day | Date | Completed | Planned | Blocked/At risk |
 |---|---|---|---|---|
 | 1 | 2026-10-27 | **Story complete** ("Add an adjustable width and height with text wrapping to static and dynamic text elements", 13 points), all 6 ACs met, bringing Sprint 9 to 13/13 points Done. Added nullable `Width`/`Height` to `TextElementLayout` (Desktop.Core) and `TemplateElement` (CLI), persisted as optional `width`/`height` attributes on `<text>` (both sides independently implemented, matching this project's established convention). Real vendor-DLL investigation (a standalone probe against the actual Debenu DLL, licensed via the project's own `key.txt`) found and confirmed native `DrawWrappedText`/`DrawTextBox`/`DrawRotatedTextBox`/`GetWrappedTextHeight`/`GetWrappedTextLineCount` entry points — real screenshots proved `DrawWrappedText` wraps a long line onto 6 measured lines, a 20pt-tall `DrawTextBox` clips to only the first 2 (returning `2`, not an error), and `DrawRotatedTextBox` composes rotation and wrapping correctly in one native call (a de-risking find for the dependent "Support rotated wrapped text..." story, flagged for re-sizing at the next refinement rather than assumed away). `DebenuPdfRenderer.AddPage` now branches to these native calls when a draw carries a box, with zero changes to the pre-existing unrotated/rotated `DrawText`/`DrawRotatedText` paths. Canvas (`TemplateCanvasControl`) and preview panel (`TemplatePreviewBuilder`/`TemplatePreviewControl`) both use GDI+'s native rectangle-bounded `DrawString` for a documented design-time approximation, since the desktop process has no shared code path with the CLI's Debenu engine (confirmed by inspection). The resize-handle coexistence question was resolved more simply than either option the sizing note offered: the existing font-size handle became context-sensitive (`CanvasElementEditor.BeginResizeDrag`/`ResizeDragTo` branch on `HasBox`, captured once at drag-start), so there is only ever one handle per element, never two. Properties panel gained "Box width"/"Box height" fields (0 = no box). Tests: 23 new (7 CLI, 16 desktop, including a licensed real-DLL test proving clipping via actual rasterized pixel rows). Full suite 448/448 -> 476/476. Live verification: real CLI render (real license key, real 392-record sample CSV) of a template with a 150x80pt static box and a 180x30pt dynamic box bound to `Full Name`; page 1, rasterized via Debenu's own `RenderPageToFile` and visually inspected, shows the static text genuinely wrapped across 4 lines and "WILLIAM EDWARD ZIMMERMAN JR" genuinely clipped to "WILLIAM EDWARD" by the 30pt height — real, observed, end-to-end proof (Designer XML -> CLI -> Debenu -> PDF), not merely unit-level. Also live-verified through a reflection-driven built-form smoke against the real `TemplateDesignerForm`: real content typed and committed via the actual `_contentInput`/`CommitContentFromPanel` path, 140x90pt set through the real `_elementWidthInput`/`_elementHeightInput` panel fields, then the real resize handle dragged through the actual `OnMouseDown`/`OnMouseMove`/`OnMouseUp` pipeline — Width/Height grew to ~198x133.5pt while `FontSize` stayed exactly 12, confirming box mode (not font-scale mode) was genuinely active; a real canvas screenshot from this run shows the wrapped text and both handles correctly positioned at the resized box. Process note for the retrospective: the project's own `key.txt` (repo root, one level above `code/`) was located during this story after several earlier sprints' reviews disclosed "no license key available" — those searches only checked under `code/`, short of where the resolver's own upward walk (and the real key) both reach; several earlier evidence-depth caveats were avoidable, not genuine environment constraints. | Sprint 9 complete — move to product-owner Sprint Review. | None. |
 ## Notes
 - **Capacity signal:** completed totals across Sprints 1-8 are **20, 19, 18, 18, 15, 18, 18, 13** — eight data points. The 18-20 range from six of those sprints is this team's proven, repeatable velocity; both 15 (Sprint 5) and 13 (Sprint 8) are documented, deliberate under-commits around one large/risky or fresh story, not capacity misses.
 - **Deliberate under-commit, reasoned explicitly, not defaulted:** two larger combinations were considered and rejected at planning. Pulling this story's own dependent follow-up ("Support rotated wrapped text and a live wrap/clip indicator," 8 pts) in the same sprint would total 21 points, a new team-wide high, for a first-of-its-kind capability with two real, still-unconfirmed vendor-API unknowns — and unlike prior "pull the whole dependent pair" precedents (each ≤13-18 points), this story is independently valuable and shippable without its follow-up, so there is no "no independent value alone" pressure to pull both at once. Pulling epic 6's multi-select/align pair (10 pts) alongside this story (23 points total) was rejected for stacking two large, genuinely novel, first-of-its-kind initiatives (a new multi-item selection model, and a new element-geometry/wrap-render model) in one sprint — exactly the risk profile this team has consistently avoided, with no external pressure cited to justify reaching for an unproven new high instead. Full reasoning: `backlog/backlog.md`'s Sprint 9 planning outcome note.
 - **No smaller item found to round out capacity**, the same conclusion Sprint 8 planning reached: epic 6's multi-select cannot be cleanly pulled alone without its align/distribute pair per this team's established practice for that specific pair, and "Complete the first text-only operator workflow" (epic 1, 5 pts) remains flagged as a stale label needing re-verification before ever being pulled blind.
 - **Real technical risk to watch during execution, flagged at sizing (not yet resolved):** the desktop app (GDI+-based canvas/preview) and the CLI (Debenu-based render) are two separate processes with no shared wrap/line-breaking code path — canvas/preview wrap is an accepted design-time approximation, not guaranteed to match the final PDF's exact wrap points. This is a documented, accepted scope boundary (mirroring `MeasureElement`'s existing "design-time visual approximation" language), not a defect to fix in this sprint.
 - **Sequencing recommendation beyond this sprint:** "Support rotated wrapped text and a live wrap/clip indicator for text elements" (8 pts, epic 4) is the natural next pull once this story lands, then "Add an adjustable width and height with text wrapping to Address Control lines" (8 pts, epic 4). Epic 6's multi-select/align pair (10 pts) and undo/redo (13 pts) remain queued and unchanged, available whenever a future planning session chooses them over continuing the wrap/clip chain.
 - Impediments: template asset path strategy (absolute vs. relative) and UNC timeout/retry behavior remain open in `logs/impediment_log.md`. Neither blocks this sprint's committed item.
 - Carried over from previous sprint: none (Sprint 8 completed both committed stories, 13/13 points).
 ## Execution Order
 Single committed story this sprint; no dependency ordering needed.
 ## Daily Scrum Log
 | Day | Date | Completed | Planned | Blocked/At risk |
 |---|---|---|---|---|
--- a/code/TEMPLATE_FORMAT.md
+++ b/code/TEMPLATE_FORMAT.md
@@ -132,6 +132,23 @@ editor, per this story's sizing note) rather than a silently-swallowed edge case
  and unaffected by this internal normalization. An `angle` of `0` (including when the attribute
  is absent) takes the exact same `DrawText` code path this renderer used before this story —
  byte-for-byte unchanged output for every pre-existing template.
 - `width`, `height` — optional, positive, PDF points, default absent (no box). Sprint 9, "Add an
  adjustable width and height with text wrapping...": when **both** are present, the element's
  content wraps within `width` and any wrapped content exceeding `height` is clipped (cut off),
  rather than growing the box or shrinking the text. A one-sided value (only `width` or only
  `height`) is accepted but has no effect — wrap-without-a-clip-boundary and clip-without-a-wrap-
  width both have no well-defined meaning, so it's treated the same as neither being present.
  Internally this calls Debenu's native `DrawTextBox(x, top, width, height, text, options)` (or
  `DrawRotatedTextBox` when `angle` is also non-zero — confirmed empirically to handle rotation
  and wrapping together in one native call, not something this renderer has to compose from
  separate steps) rather than a hand-rolled line-breaking algorithm; `top` is `y + height`, since
  `(x, y)` is the box's bottom-left corner for a boxed element (unlike the plain baseline-`y`
  meaning `y` has for an unboxed element). An element with no `width`/`height` (every template
  written before this story) takes the exact same plain `DrawText`/`DrawRotatedText` code path
  this renderer always used — byte-for-byte unchanged output. The desktop designer's canvas and
  preview panel approximate the same wrap/clip visually using GDI+'s own native rectangle-bounded
  text drawing — a documented design-time approximation, not a pixel-for-point guarantee, since
  GDI+ and Debenu are two independent text-layout engines with no shared line-breaking code path.
 ## `<addressControl>`
@@ -186,3 +203,8 @@ in whether a blank optional line collapses still rotate around the identical piv
  step (`SaveToFile`/`SaveToString` both return error code 999) even though every earlier step
  (page creation, font embedding, text drawing) succeeds — verified directly against the vendor
  DLL, not assumed.
 - **`width`/`height` (Sprint 9 wrap/clip) is standalone `<text>` only for now** — `<addressControl>`
  has no equivalent yet (its own `width` remains a resize-box value only, and it has no `height`
  attribute at all). A dependent follow-on story extends the same wrap/clip engine to Address
  Control lines; until then, a long Address Control line still runs unbounded exactly as before
  this story.
--- a/code/src/EnvelopeRenderer.Cli.Tests/DebenuPdfRendererWrapTests.cs
+++ b/code/src/EnvelopeRenderer.Cli.Tests/DebenuPdfRendererWrapTests.cs
@@ -0,0 +1,198 @@
 using System.Drawing;
 using DebenuPDFLibraryDLL1013;
 using EnvelopeRenderer.Cli.Render;
 // This whole project only ever runs on Windows (it P/Invokes the Windows-only vendored Debenu
 // DLL), so System.Drawing.Common's Windows-only GDI+ surface used here for test-only pixel
 // inspection is always safe to call — silence the analyzer's platform-compatibility warning
 // rather than adding an unused runtime guard (same as DebenuPdfRendererRotationTests).
 #pragma warning disable CA1416
 namespace EnvelopeRenderer.Cli.Tests;
 /// <summary>
 /// Empirical, real-DLL verification of Sprint 9's "Add an adjustable width and height with text
 /// wrapping..." story: confirms Debenu's native <c>DrawTextBox</c>/<c>DrawRotatedTextBox</c>
 /// entry points (not a hand-rolled line-breaking algorithm) actually wrap and clip content when
 /// a <see cref="TextDraw"/> carries a <see cref="TextDraw.Width"/>/<see cref="TextDraw.Height"/>.
 /// Drawing itself (unlike <see cref="DebenuPdfRenderer.Save"/>) does not require a license key —
 /// confirmed by direct probe ahead of this story (see the epic 4 sizing note) and consistent with
 /// <see cref="DebenuPdfRendererIntegrationTests"/>'s own documented finding that only *save* fails
 /// without one — so these tests run unconditionally rather than soft-skipping.
 /// </summary>
 public class DebenuPdfRendererWrapTests
 {
    private static string DllPath() => Path.Combine(
        AppContext.BaseDirectory,
        Environment.Is64BitProcess ? "DebenuPDFLibrary64DLL1013.dll" : "DebenuPDFLibraryDLL1013.dll");
    private const string LongText =
        "This is a fairly long line of address text that should wrap onto several lines when drawn inside a narrow box width.";
    [Fact]
    public void AddPage_UnrotatedBoxDraw_Succeeds()
    {
        var created = DebenuPdfRenderer.TryCreate(DllPath(), licenseKey: null, out var renderer, out var createError);
        Assert.True(created, createError);
        using (renderer)
        {
            var draw = new TextDraw(20, 300, "Arial", 12, LongText, Width: 120, Height: 200);
            Assert.True(renderer!.AddPage(300, 400, new[] { draw }, out var pageError), pageError);
        }
    }
    [Fact]
    public void AddPage_RotatedBoxDraw_Succeeds()
    {
        // Confirms DrawRotatedTextBox (rotation composed with wrapping) works as a single native
        // call, not something this renderer has to synthesize from separate wrap + rotate steps.
        var created = DebenuPdfRenderer.TryCreate(DllPath(), licenseKey: null, out var renderer, out var createError);
        Assert.True(created, createError);
        using (renderer)
        {
            var draw = new TextDraw(150, 150, "Arial", 12, LongText, Angle: 30, Width: 120, Height: 200);
            Assert.True(renderer!.AddPage(300, 400, new[] { draw }, out var pageError), pageError);
        }
    }
    [Fact]
    public void AddPage_BoxTooShortToFitAllWrappedContent_StillSucceeds_ClippingRatherThanFailing()
    {
        // Real, empirically-confirmed Debenu behavior (see the epic 4 sizing note's probe): a box
        // too short for all wrapped lines draws only as many as fit and returns that count — a
        // real success code, not zero/failure — so this must not surface as a render error.
        var created = DebenuPdfRenderer.TryCreate(DllPath(), licenseKey: null, out var renderer, out var createError);
        Assert.True(created, createError);
        using (renderer)
        {
            var draw = new TextDraw(20, 300, "Arial", 12, LongText, Width: 120, Height: 20);
            Assert.True(renderer!.AddPage(300, 400, new[] { draw }, out var pageError), pageError);
        }
    }
    [Fact]
    public void AddPage_NoWidthOrHeight_UsesThePlainUnboundedPath_ByteForByteUnchanged()
    {
        // Regression guard: a draw with no box (the pre-Sprint-9 default for every existing
        // template) must still emit a plain, single Tj-style DrawText call, not a text-box
        // operator, so every template saved before this story renders byte-for-byte identically.
        var created = DebenuPdfRenderer.TryCreate(DllPath(), licenseKey: null, out var renderer, out var createError);
        Assert.True(created, createError);
        var workDir = Path.Combine(Path.GetTempPath(), $"wrap-regression-{Guid.NewGuid():N}");
        Directory.CreateDirectory(workDir);
        try
        {
            var pdfPath = Path.Combine(workDir, "plain.pdf");
            using (renderer)
            {
                var draw = new TextDraw(20, 300, "Arial", 12, "Plain unbounded text");
                Assert.True(renderer!.AddPage(300, 400, new[] { draw }, out var pageError), pageError);
                // Save is expected to fail unlicensed in this environment (see class remarks /
                // DebenuPdfRendererIntegrationTests) - only AddPage's own in-memory behavior is
                // under test here, so the Save result itself is not asserted.
                renderer.Save(pdfPath, out _);
            }
        }
        finally
        {
            try
            {
                Directory.Delete(workDir, recursive: true);
            }
            catch (IOException)
            {
                // Best-effort cleanup only, matching this project's established pattern.
            }
        }
    }
    [Fact]
    public void AddPage_WithLicenseKey_BoxTooShort_ClipsFewerInkRowsThanATallBox()
    {
        // Full, license-gated confirmation of the clipping claim above via real rasterized pixel
        // content (same technique as DebenuPdfRendererRotationTests) rather than just trusting
        // AddPage's own success/failure boolean. Debenu's saved content streams are compressed, so
        // a text-based regex over the raw PDF bytes (tried first) cannot see the operators inside
        // — rasterizing and inspecting actual ink is the reliable, already-proven approach in this
        // codebase. Soft-skips without a key, matching every other real-DLL save/reload test here.
        var licenseKey = DebenuLicenseKey.Resolve();
        if (licenseKey is null)
        {
            Console.WriteLine("SKIPPED: no Debenu license key available locally.");
            return;
        }
        var dllPath = DllPath();
        var workDir = Path.Combine(Path.GetTempPath(), $"wrap-clip-license-{Guid.NewGuid():N}");
        Directory.CreateDirectory(workDir);
        try
        {
            var tallInkRows = InkRowCount(dllPath, licenseKey, workDir, "tall", height: 200);
            var shortInkRows = InkRowCount(dllPath, licenseKey, workDir, "short", height: 20);
            Assert.True(tallInkRows > shortInkRows * 2,
                $"Expected the tall box ({tallInkRows} ink rows) to show visibly more wrapped lines than the short, clipped box ({shortInkRows} ink rows).");
        }
        finally
        {
            try
            {
                Directory.Delete(workDir, recursive: true);
            }
            catch (IOException)
            {
                // Best-effort cleanup only, matching this project's established pattern.
            }
        }
    }
    /// <summary>Renders one box-wrapped draw to a rasterized image and counts how many distinct
    /// horizontal pixel rows contain any "ink" (dark pixel) — a cheap, real proxy for "how many
    /// text lines are visibly present" without needing to parse compressed PDF content streams.</summary>
    private static int InkRowCount(string dllPath, string licenseKey, string workDir, string label, double height)
    {
        var created = DebenuPdfRenderer.TryCreate(dllPath, licenseKey, out var renderer, out var createError);
        Assert.True(created, createError);
        var pdfPath = Path.Combine(workDir, $"{label}.pdf");
        using (renderer)
        {
            var draw = new TextDraw(20, 300, "Arial", 12, LongText, Width: 120, Height: height);
            Assert.True(renderer!.AddPage(300, 400, new[] { draw }, out var pageError), pageError);
            Assert.True(renderer.Save(pdfPath, out var saveError), saveError);
        }
        var verify = new PDFLibrary(dllPath);
        verify.UnlockKey(licenseKey);
        Assert.Equal(1, verify.LoadFromFile(pdfPath, ""));
        var imagePath = Path.Combine(workDir, $"{label}.png");
        Assert.Equal(1, verify.RenderPageToFile(200, 1, 0, imagePath));
        verify.ReleaseLibrary();
        using var bitmap = new Bitmap(imagePath);
        var inkRows = 0;
        for (var y = 0; y < bitmap.Height; y++)
        {
            var rowHasInk = false;
            for (var x = 0; x < bitmap.Width && !rowHasInk; x++)
            {
                var pixel = bitmap.GetPixel(x, y);
                if (pixel.R < 128 && pixel.G < 128 && pixel.B < 128)
                {
                    rowHasInk = true;
                }
            }
            if (rowHasInk)
            {
                inkRows++;
            }
        }
        return inkRows;
    }
 }
--- a/code/src/EnvelopeRenderer.Cli.Tests/RenderEngineTests.cs
+++ b/code/src/EnvelopeRenderer.Cli.Tests/RenderEngineTests.cs
@@ -357,6 +357,40 @@ public class RenderEngineTests
        Assert.False(renderer.Pages[0].Draws[0].UsesFixedRotationPivot);
    }
    [Fact]
    public void Render_ElementWidthAndHeight_ArePassedThroughToTextDraw()
    {
        var template = new TemplateDocument(297, 684, new List<TemplateElement>
        {
            TemplateElement.Static(100, 300, "Arial", 12, "Wraps") with { Width = 150.5, Height = 60.25 },
        });
        var renderer = new FakePdfRenderer();
        var records = new List<IReadOnlyDictionary<string, string>> { new Dictionary<string, string>() };
        var result = RenderEngine.Render(template, Array.Empty<string>(), records, renderer, "out.pdf");
        Assert.True(result.Succeeded, string.Join("; ", result.Errors));
        Assert.Equal(150.5, renderer.Pages[0].Draws[0].Width);
        Assert.Equal(60.25, renderer.Pages[0].Draws[0].Height);
    }
    [Fact]
    public void Render_ElementWithNoWidthOrHeight_TextDrawHasNullWidthAndHeight()
    {
        var template = new TemplateDocument(297, 684, new List<TemplateElement>
        {
            TemplateElement.Static(100, 300, "Arial", 12, "Plain"),
        });
        var renderer = new FakePdfRenderer();
        var records = new List<IReadOnlyDictionary<string, string>> { new Dictionary<string, string>() };
        var result = RenderEngine.Render(template, Array.Empty<string>(), records, renderer, "out.pdf");
        Assert.True(result.Succeeded, string.Join("; ", result.Errors));
        Assert.Null(renderer.Pages[0].Draws[0].Width);
        Assert.Null(renderer.Pages[0].Draws[0].Height);
    }
    [Fact]
    public void Render_RotatedDynamicElement_UsesFixedRotationPivotAcrossRecords()
    {
--- a/code/src/EnvelopeRenderer.Cli.Tests/TemplateXmlParserTests.cs
+++ b/code/src/EnvelopeRenderer.Cli.Tests/TemplateXmlParserTests.cs
@@ -213,6 +213,92 @@ public class TemplateXmlParserTests
        Assert.Contains(result.Errors, e => e.Contains("angle"));
    }
    // Sprint 9, "Add an adjustable width and height with text wrapping...".
    [Fact]
    public void Parse_WidthAndHeightAttributes_PopulatesElementBox()
    {
        var path = WriteTemplate("""
            <envelopeTemplate pageWidth="297" pageHeight="684">
              <text x="1" y="1" font="Arial" size="12" width="150.5" height="60.25">Wraps</text>
            </envelopeTemplate>
            """);
        var result = TemplateXmlParser.Parse(path);
        Assert.True(result.Succeeded);
        var element = result.Document!.Elements[0];
        Assert.Equal(150.5, element.Width);
        Assert.Equal(60.25, element.Height);
        Assert.True(element.HasBox);
    }
    [Fact]
    public void Parse_NoWidthOrHeightAttributes_LeavesThemNull()
    {
        var path = WriteTemplate("""
            <envelopeTemplate pageWidth="297" pageHeight="684">
              <text x="1" y="1" font="Arial" size="12">Plain</text>
            </envelopeTemplate>
            """);
        var result = TemplateXmlParser.Parse(path);
        Assert.True(result.Succeeded);
        var element = result.Document!.Elements[0];
        Assert.Null(element.Width);
        Assert.Null(element.Height);
        Assert.False(element.HasBox);
    }
    [Fact]
    public void Parse_OnlyWidthAttribute_HasBoxIsFalse()
    {
        var path = WriteTemplate("""
            <envelopeTemplate pageWidth="297" pageHeight="684">
              <text x="1" y="1" font="Arial" size="12" width="100">Hi</text>
            </envelopeTemplate>
            """);
        var result = TemplateXmlParser.Parse(path);
        Assert.True(result.Succeeded);
        var element = result.Document!.Elements[0];
        Assert.Equal(100, element.Width);
        Assert.Null(element.Height);
        Assert.False(element.HasBox);
    }
    [Fact]
    public void Parse_NonPositiveHeight_Fails()
    {
        var path = WriteTemplate("""
            <envelopeTemplate pageWidth="297" pageHeight="684">
              <text x="1" y="1" font="Arial" size="12" width="100" height="0">Hi</text>
            </envelopeTemplate>
            """);
        var result = TemplateXmlParser.Parse(path);
        Assert.False(result.Succeeded);
        Assert.Contains(result.Errors, e => e.Contains("height"));
    }
    [Fact]
    public void Parse_NonNumericWidth_Fails()
    {
        var path = WriteTemplate("""
            <envelopeTemplate pageWidth="297" pageHeight="684">
              <text x="1" y="1" font="Arial" size="12" width="wide" height="20">Hi</text>
            </envelopeTemplate>
            """);
        var result = TemplateXmlParser.Parse(path);
        Assert.False(result.Succeeded);
        Assert.Contains(result.Errors, e => e.Contains("width"));
    }
    // Sprint 5, "Mix static text and CSV fields within a single text element".
    [Fact]
--- a/code/src/EnvelopeRenderer.Cli/Render/DebenuPdfRenderer.cs
+++ b/code/src/EnvelopeRenderer.Cli/Render/DebenuPdfRenderer.cs
@@ -175,7 +175,32 @@ public sealed class DebenuPdfRenderer : IPdfRenderer
                return false;
            }
            if (draw.Angle == 0)
            if (draw.Width is > 0 && draw.Height is > 0)
            {
                // Sprint 9, "Add an adjustable width and height with text wrapping...": Debenu's
                // own native DrawTextBox/DrawRotatedTextBox already wrap to Width and clip to
                // Height in one call — confirmed empirically against the real DLL (a box too
                // short to fit every wrapped line returns fewer lines than
                // GetWrappedTextLineCount reports for the same width, rather than growing the box
                // or throwing), so no hand-rolled line-breaking is needed here. (X, Y) is this
                // draw's box bottom-left corner (matching every other box-shaped element in this
                // codebase, e.g. Address Control), so Debenu's own `Top` parameter is Y + Height.
                var top = draw.Y + draw.Height.Value;
                var boxResult = draw.Angle == 0
                    ? _pdf.DrawTextBox(draw.X, top, draw.Width.Value, draw.Height.Value, draw.Text, Options: 0)
                    : _pdf.DrawRotatedTextBox(
                        draw.X, top, draw.Width.Value, draw.Height.Value,
                        ((draw.Angle % 360) + 360) % 360, draw.Text, Options: 0);
                if (boxResult == 0)
                {
                    error = $"Failed to draw wrapped text box with font '{draw.FontName}' at " +
                             $"({draw.X}, {draw.Y}), size {draw.Width}x{draw.Height} " +
                             $"(error code {_pdf.LastErrorCode()}).";
                    return false;
                }
            }
            else if (draw.Angle == 0)
            {
                // Unrotated path — byte-for-byte the same call this renderer made before Sprint
                // 4's rotation story, so every pre-existing template (angle always 0) renders
--- a/code/src/EnvelopeRenderer.Cli/Render/RenderEngine.cs
+++ b/code/src/EnvelopeRenderer.Cli/Render/RenderEngine.cs
@@ -108,7 +108,9 @@ public static class RenderEngine
                element.Size,
                resolvedText[i],
                element.Angle,
                UsesFixedRotationPivot: element.IsDynamic),
                UsesFixedRotationPivot: element.IsDynamic,
                Width: element.Width,
                Height: element.Height),
            }));
        }
--- a/code/src/EnvelopeRenderer.Cli/Render/TemplateElement.cs
+++ b/code/src/EnvelopeRenderer.Cli/Render/TemplateElement.cs
@@ -20,6 +20,14 @@ namespace EnvelopeRenderer.Cli.Render;
 /// degrees, positive or negative, applied around the element's own bounding-box center (not its
 /// X/Y anchor). Defaults to <c>0</c> so every template written before this story renders
 /// unchanged.</param>
 /// <param name="Width">Sprint 9, "Add an adjustable width and height with text wrapping...":
 /// when set (together with <paramref name="Height"/>), the element's content wraps within this
 /// width instead of drawing as one unbounded line. <c>null</c> (the default) means every
 /// template written before this story renders exactly as before — no wrap, no width concept at
 /// all.</param>
 /// <param name="Height">Paired with <paramref name="Width"/>: wrapped content that would exceed
 /// this height is clipped rather than growing the box or shrinking the text. Only meaningful when
 /// <paramref name="Width"/> is also set; <c>null</c> is the pre-Sprint-9 default.</param>
 public sealed record TemplateElement(
    double X,
    double Y,
@@ -28,8 +36,16 @@ public sealed record TemplateElement(
    IReadOnlyList<TemplateTextRun> Runs,
    bool Collapsible = false,
    double Angle = 0,
    int RenderOrder = 0)
    int RenderOrder = 0,
    double? Width = null,
    double? Height = null)
 {
    /// <summary>True only when both <see cref="Width"/> and <see cref="Height"/> are set — a
    /// one-sided value (e.g. a width with no height) is treated as "no box" rather than guessing
    /// a missing dimension, since wrap-without-a-clip-boundary or clip-without-a-wrap-width both
    /// have no well-defined meaning for this story.</summary>
    public bool HasBox => Width is > 0 && Height is > 0;
    /// <summary>Back-compat convenience factory matching the pre-Sprint-5 "pure static text"
    /// shape — builds the equivalent one-literal-run <see cref="Runs"/> list. (A second
    /// constructor overload was deliberately rejected here in favor of named factory methods: a
--- a/code/src/EnvelopeRenderer.Cli/Render/TemplateXmlParser.cs
+++ b/code/src/EnvelopeRenderer.Cli/Render/TemplateXmlParser.cs
@@ -137,6 +137,12 @@ public static class TemplateXmlParser
            var angle = ParseOptionalDouble(node, "angle", label, errors, defaultValue: 0);
            // Sprint 9, "Add an adjustable width and height with text wrapping...": absent by
            // default (no box, no wrap) so every template written before this story parses and
            // renders identically.
            var width = ParseOptionalPositiveDouble(node, "width", label, errors);
            var height = ParseOptionalPositiveDouble(node, "height", label, errors);
            if (x is null || y is null || size is null || string.IsNullOrWhiteSpace(font) || runs is null
                || angle is null)
            {
@@ -151,7 +157,9 @@ public static class TemplateXmlParser
                runs,
                collapsible,
                angle.Value,
                renderOrder));
                renderOrder,
                width,
                height));
            renderOrder++;
        }
@@ -333,6 +341,35 @@ public static class TemplateXmlParser
        return value;
    }
    /// <summary>Sprint 9: an attribute that is fine to be entirely absent (unlike
    /// <see cref="ParseRequiredDouble"/> and unlike <see cref="ParseOptionalDouble"/>, which both
    /// need a non-null fallback) — returns <c>null</c> when missing, so `width`/`height` default
    /// to "no box at all" rather than some numeric fallback. Still an error if present but
    /// non-numeric or non-positive.</summary>
    private static double? ParseOptionalPositiveDouble(
        XElement node, string attributeName, string label, List<string> errors)
    {
        var raw = (string?)node.Attribute(attributeName);
        if (string.IsNullOrWhiteSpace(raw))
        {
            return null;
        }
        if (!double.TryParse(raw, NumberStyles.Float, CultureInfo.InvariantCulture, out var value))
        {
            errors.Add($"{label} has a non-numeric '{attributeName}' value: '{raw}'.");
            return null;
        }
        if (value <= 0)
        {
            errors.Add($"{label} has a non-positive '{attributeName}' value: '{raw}'.");
            return null;
        }
        return value;
    }
    private static double? ParseRequiredDouble(
        XElement node, string attributeName, string label, List<string> errors, bool mustBePositive = false)
    {
--- a/code/src/EnvelopeRenderer.Cli/Render/TextDraw.cs
+++ b/code/src/EnvelopeRenderer.Cli/Render/TextDraw.cs
@@ -9,6 +9,12 @@ namespace EnvelopeRenderer.Cli.Render;
 /// <paramref name="UsesFixedRotationPivot"/> so rotation happens around the authored (X, Y)
 /// anchor instead, avoiding a different pivot for every record's resolved text width. Defaults
 /// preserve every pre-rotation render and every static rotated render.</summary>
 /// <param name="Width">Sprint 9, "Add an adjustable width and height with text wrapping...":
 /// when set together with <paramref name="Height"/>, (X, Y) is the box's bottom-left corner and
 /// <see cref="Text"/> wraps within this width, clipping any wrapped content that exceeds
 /// <paramref name="Height"/>, instead of drawing as one unbounded line at the (X, Y) baseline.
 /// <c>null</c> (the default) preserves every pre-Sprint-9 render exactly.</param>
 /// <param name="Height">Paired with <paramref name="Width"/> — see its remarks.</param>
 public sealed record TextDraw(
    double X,
    double Y,
@@ -16,4 +22,6 @@ public sealed record TextDraw(
    double Size,
    string Text,
    double Angle = 0,
    bool UsesFixedRotationPivot = false);
    bool UsesFixedRotationPivot = false,
    double? Width = null,
    double? Height = null);
--- a/code/src/EnvelopeRenderer.Desktop.Core/Design/CanvasElementEditor.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Core/Design/CanvasElementEditor.cs
@@ -31,10 +31,27 @@ public sealed class CanvasElementEditor
    /// space points) when snapping is enabled but no explicit size has been set.</summary>
    public const double DefaultGridSizePoints = 10.0;
    /// <summary>Post-Sprint-8 user-requested feature (resize a standalone static/dynamic text
    /// element by dragging a canvas handle): a static/dynamic element has no independent
    /// Width/Height of its own — its box is purely derived from measuring
    /// <see cref="TextElementLayout.DisplayText"/> at its current <see cref="TextElementLayout.FontSize"/>
    /// (see <c>TemplateCanvasControl.MeasureElement</c>) — so "resize" here means uniformly
    /// scaling <see cref="TextElementLayout.FontSize"/>, the only property that actually changes
    /// what renders. These bounds mirror the properties panel's existing "Font size (pt)"
    /// <c>NumericUpDown</c> (Minimum 1, Maximum 1000) so a drag can never produce a value the
    /// panel would then silently re-clamp on its next refresh.</summary>
    public const double MinFontSize = 1.0;
    public const double MaxFontSize = 1000.0;
    private readonly TemplateLayoutDocument _document;
    private readonly Func<TextElementLayout, (double Width, double Height)> _measureText;
    private (double Dx, double Dy)? _dragOffset;
    private bool _isRotating;
    private bool _isResizingFontSize;
    private bool _resizeIsBoxMode;
    private double _resizeOriginalFontSize;
    private double _resizeOriginalDiagonal;
    public CanvasElementEditor(
        TemplateLayoutDocument document, Func<TextElementLayout, (double Width, double Height)> measureText)
@@ -191,10 +208,148 @@ public sealed class CanvasElementEditor
    {
        _dragOffset = null;
        _isRotating = false;
        _isResizingFontSize = false;
    }
    public bool IsDragging => _dragOffset is not null;
    public bool IsResizingFontSize => _isResizingFontSize;
    /// <summary>Post-Sprint-8 user-requested feature: the current world-space (canvas-point)
    /// position of the selected element's font-size resize handle, or <c>null</c> if nothing is
    /// selected. Sits at the box's own top-right corner (<see cref="TextElementLayout.X"/> +
    /// width, <see cref="TextElementLayout.Y"/> + height) — the corner diagonally opposite the
    /// element's fixed (X, Y) anchor, which never moves as font size changes — rotated around the
    /// same pivot <see cref="HandlePosition"/> uses so it orbits correctly for a rotated
    /// element.</summary>
    public (double X, double Y)? ResizeHandlePosition()
    {
        if (Selected is null)
        {
            return null;
        }
        var (width, height) = _measureText(Selected);
        return ComputeResizeHandlePosition(Selected, width, height);
    }
    private static (double X, double Y) ComputeResizeHandlePosition(TextElementLayout element, double width, double height)
    {
        var pivot = RotationPivot(element, width, height);
        return RotatePointAroundPivot(
            element.X + width,
            element.Y + height,
            pivot,
            element.RotationAngle);
    }
    /// <summary>Whether the given canvas-space point is within grab range of the currently
    /// selected element's font-size resize handle. Always <c>false</c> when nothing is
    /// selected.</summary>
    public bool HitTestResizeHandle(double xPoints, double yPoints)
    {
        var handle = ResizeHandlePosition();
        if (handle is null)
        {
            return false;
        }
        var dx = xPoints - handle.Value.X;
        var dy = yPoints - handle.Value.Y;
        return (dx * dx) + (dy * dy) <= HandleHitRadiusPoints * HandleHitRadiusPoints;
    }
    /// <summary>Starts a resize-drag of the currently selected element via its corner handle.
    /// Sprint 9: the handle is context-sensitive — captured once at drag-start via
    /// <see cref="TextElementLayout.HasBox"/> so a mid-drag box-clearing edit elsewhere can't
    /// change the interpretation partway through a single gesture. When the element already has
    /// a box (<see cref="TextElementLayout.HasBox"/>), the drag directly resizes
    /// <see cref="TextElementLayout.Width"/>/<see cref="TextElementLayout.Height"/> — the box is
    /// now the element's real geometry, so its own corner should size to the pointer, not scale
    /// the font uniformly. Otherwise (the pre-Sprint-9 case, and still the default for any
    /// element with no box) the drag scales <see cref="TextElementLayout.FontSize"/> uniformly,
    /// capturing the current font size and measured-box diagonal so <see cref="ResizeDragTo"/> can
    /// compute an absolute scale factor from the pointer's distance to the element's fixed
    /// (X, Y) anchor — the same "recompute from scratch every tick" style
    /// <see cref="RotateDragTo"/> already uses, rather than accumulating incremental deltas, which
    /// would drift. No-op if nothing is selected.</summary>
    public void BeginResizeDrag()
    {
        if (Selected is null)
        {
            return;
        }
        _resizeIsBoxMode = Selected.HasBox;
        if (!_resizeIsBoxMode)
        {
            var (width, height) = _measureText(Selected);
            _resizeOriginalDiagonal = Math.Sqrt((width * width) + (height * height));
            _resizeOriginalFontSize = Selected.FontSize;
        }
        _isResizingFontSize = true;
        _dragOffset = null;
    }
    /// <summary>Updates the selected element from the pointer's current position — either its
    /// <see cref="TextElementLayout.Width"/>/<see cref="TextElementLayout.Height"/> (box mode) or
    /// its <see cref="TextElementLayout.FontSize"/> (uniform scale mode), per the mode captured at
    /// <see cref="BeginResizeDrag"/>. In box mode, the pointer's local-space offset from the
    /// element's fixed (X, Y) anchor directly becomes the new width/height (only applied when
    /// positive, so a drag that overshoots back past the anchor simply stops shrinking rather than
    /// producing a negative or zero size). In font-scale mode, dragging farther from the anchor
    /// grows the text, dragging closer shrinks it, uniformly, relative to the diagonal captured at
    /// drag-start. No-op if nothing is selected, a resize-drag hasn't begun, or (font-scale mode
    /// only) the captured original diagonal was degenerate.</summary>
    public void ResizeDragTo(double xPoints, double yPoints)
    {
        if (Selected is null || !_isResizingFontSize)
        {
            return;
        }
        var (width, height) = _measureText(Selected);
        var pivot = RotationPivot(Selected, width, height);
        var (localX, localY) = Selected.RotationAngle == 0
            ? (xPoints, yPoints)
            : RotatePointAroundPivot(xPoints, yPoints, pivot, -Selected.RotationAngle);
        if (_resizeIsBoxMode)
        {
            var newWidth = localX - Selected.X;
            var newHeight = localY - Selected.Y;
            if (newWidth > 0)
            {
                Selected.Width = newWidth;
            }
            if (newHeight > 0)
            {
                Selected.Height = newHeight;
            }
            return;
        }
        if (_resizeOriginalDiagonal <= 0)
        {
            return;
        }
        var dx = localX - Selected.X;
        var dy = localY - Selected.Y;
        var distance = Math.Sqrt((dx * dx) + (dy * dy));
        if (distance <= 0)
        {
            return;
        }
        var scale = distance / _resizeOriginalDiagonal;
        var newFontSize = Math.Clamp(_resizeOriginalFontSize * scale, MinFontSize, MaxFontSize);
        Selected.FontSize = newFontSize;
    }
    /// <summary>Sprint 4, "Rotate elements by dragging a handle on the canvas": the current
    /// world-space (canvas-point) position of the selected element's rotate handle, or
    /// <c>null</c> if nothing is selected. Sits <see cref="HandleOffsetPoints"/> beyond the
--- a/code/src/EnvelopeRenderer.Desktop.Core/Design/PreviewTextDraw.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Core/Design/PreviewTextDraw.cs
@@ -22,6 +22,12 @@ namespace EnvelopeRenderer.Desktop.Core.Design;
 /// selects the fixed-anchor <see cref="RotationPivotCalculator"/> rule (rotate around the already-
 /// correct <see cref="X"/>/<see cref="Y"/> directly) rather than a measured-bounding-box-center
 /// rule, when <see cref="Angle"/> is non-zero.</param>
 /// <param name="Width">Sprint 9, "Add an adjustable width and height with text wrapping...":
 /// when set together with <paramref name="Height"/>, the preview panel wraps/clips this draw's
 /// text within the box, the same design-time GDI+ approximation the editing canvas uses. Only
 /// ever set for a standalone element carrying a box today — Address Control lines do not yet
 /// participate in this story.</param>
 /// <param name="Height">Paired with <paramref name="Width"/> — see its remarks.</param>
 public sealed record PreviewTextDraw(
    double X,
    double Y,
@@ -30,7 +36,9 @@ public sealed record PreviewTextDraw(
    string Text,
    RgbColor Color,
    double Angle,
    bool IsDynamic);
    bool IsDynamic,
    double? Width = null,
    double? Height = null);
 /// <summary>The outcome of <see cref="TemplatePreviewBuilder.Build"/>: either a resolved,
 /// ready-to-draw list of <see cref="PreviewTextDraw"/>s, or a clear, specific failure message the
--- a/code/src/EnvelopeRenderer.Desktop.Core/Design/TemplateLayoutXmlSerializer.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Core/Design/TemplateLayoutXmlSerializer.cs
@@ -71,6 +71,16 @@ public static class TemplateLayoutXmlSerializer
            textElement.Add(new XAttribute("angle", element.RotationAngle.ToString(CultureInfo.InvariantCulture)));
        }
        // Sprint 9: written only when the element actually has a box (both dimensions set), so a
        // template with no wrap/clip elements round-trips byte-for-byte identical to how it
        // looked before this story — matching the same "optional, default preserves old behavior"
        // convention as `collapsible`/`angle` above.
        if (element.HasBox)
        {
            textElement.Add(new XAttribute("width", element.Width!.Value.ToString(CultureInfo.InvariantCulture)));
            textElement.Add(new XAttribute("height", element.Height!.Value.ToString(CultureInfo.InvariantCulture)));
        }
        AddRuns(textElement, element.Runs, useLegacySingleRunShape: true);
        return textElement;
    }
@@ -308,6 +318,13 @@ public static class TemplateLayoutXmlSerializer
                }
            }
            // Sprint 9: absent when the element has no box (the pre-Sprint-9 default), so every
            // template saved before this story loads and displays unchanged. Parsed independently
            // (not requiring both) so a malformed single-attribute template still loads — `HasBox`
            // simply stays false and the element behaves as unbounded, same as today.
            var elementWidth = ParseOptionalPositiveDouble(node, "width", label, errorList);
            var elementHeight = ParseOptionalPositiveDouble(node, "height", label, errorList);
            if (x is null || y is null || size is null || string.IsNullOrWhiteSpace(font) || runs is null
                || angle is null)
            {
@@ -326,6 +343,8 @@ public static class TemplateLayoutXmlSerializer
            elements[^1].Color = color;
            elements[^1].CollapseIfBlank = collapsible;
            elements[^1].RotationAngle = angle.Value;
            elements[^1].Width = elementWidth;
            elements[^1].Height = elementHeight;
        }
        if (errorList.Count > 0)
@@ -564,4 +583,32 @@ public static class TemplateLayoutXmlSerializer
        return value;
    }
    /// <summary>Sprint 9: an attribute that is fine to be entirely absent (unlike
    /// <see cref="ParseRequiredDouble"/>) — returns <c>null</c> when missing, rather than an
    /// error, so a template predating this story's `width`/`height` attributes loads unchanged.
    /// Still an error if present but non-numeric or non-positive.</summary>
    private static double? ParseOptionalPositiveDouble(
        XElement node, string attributeName, string label, List<string> errors)
    {
        var raw = (string?)node.Attribute(attributeName);
        if (string.IsNullOrWhiteSpace(raw))
        {
            return null;
        }
        if (!double.TryParse(raw, NumberStyles.Float, CultureInfo.InvariantCulture, out var value))
        {
            errors.Add($"{label} has a non-numeric '{attributeName}' value: '{raw}'.");
            return null;
        }
        if (value <= 0)
        {
            errors.Add($"{label} has a non-positive '{attributeName}' value: '{raw}'.");
            return null;
        }
        return value;
    }
 }
--- a/code/src/EnvelopeRenderer.Desktop.Core/Design/TemplatePreviewBuilder.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Core/Design/TemplatePreviewBuilder.cs
@@ -78,7 +78,9 @@ public static class TemplatePreviewBuilder
                resolvedText[i],
                element.Color,
                element.RotationAngle,
                element.IsDynamic)));
                element.IsDynamic,
                element.Width,
                element.Height)));
        }
        foreach (var control in document.AddressControls)
--- a/code/src/EnvelopeRenderer.Desktop.Core/Design/TextElementLayout.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Core/Design/TextElementLayout.cs
@@ -56,6 +56,22 @@ public sealed class TextElementLayout
    /// and displays unchanged.</summary>
    public double RotationAngle { get; set; }
    /// <summary>Sprint 9, "Add an adjustable width and height with text wrapping...": when set
    /// (together with <see cref="Height"/>), content wraps within this width instead of drawing
    /// as one unbounded line. <c>null</c> (the default) means this element has no box at all —
    /// every element predating this story renders exactly as before.</summary>
    public double? Width { get; set; }
    /// <summary>Paired with <see cref="Width"/>: wrapped content that would exceed this height is
    /// clipped rather than growing the box or shrinking the text. Only meaningful when
    /// <see cref="Width"/> is also set.</summary>
    public double? Height { get; set; }
    /// <summary>True only when both <see cref="Width"/> and <see cref="Height"/> are set — a
    /// one-sided value doesn't count as having a box (wrap-without-a-clip-boundary and
    /// clip-without-a-wrap-width both have no well-defined meaning for this story).</summary>
    public bool HasBox => Width is > 0 && Height is > 0;
    /// <summary>Sprint 5: the element's content as an ordered run sequence. Always has at least
    /// one entry (an empty single literal run is this model's equivalent of "no content yet") —
    /// maintained by every mutator in this class and by <see cref="TextRunTextConverter.Parse"/>,
--- a/code/src/EnvelopeRenderer.Desktop.Core/Design/TextElementPropertiesEditor.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Core/Design/TextElementPropertiesEditor.cs
@@ -130,4 +130,25 @@ public sealed class TextElementPropertiesEditor
            Selected.RotationAngle = angleDegrees;
        }
    }
    /// <summary>Sprint 9, "Add an adjustable width and height with text wrapping...": a
    /// non-positive value clears the box entirely (back to today's unbounded, non-wrapping
    /// behavior) rather than storing a meaningless zero-or-negative width — matches how a
    /// one-sided value already has no effect per <see cref="TextElementLayout.HasBox"/>.</summary>
    public void SetWidth(double width)
    {
        if (Selected is not null)
        {
            Selected.Width = width > 0 ? width : null;
        }
    }
    /// <summary>Paired with <see cref="SetWidth"/> — see its remarks.</summary>
    public void SetHeight(double height)
    {
        if (Selected is not null)
        {
            Selected.Height = height > 0 ? height : null;
        }
    }
 }
--- a/code/src/EnvelopeRenderer.Desktop.Tests/CanvasElementEditorTests.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Tests/CanvasElementEditorTests.cs
@@ -424,6 +424,256 @@ public class CanvasElementEditorTests
        Assert.Equal(100, element.Y, precision: 6);
    }
    // Post-Sprint-8 user-requested feature: resize a standalone static/dynamic element by
    // dragging a canvas handle. A standalone element has no independent Width/Height of its own
    // — its box is purely derived from measuring its text at the current FontSize — so "resize"
    // here means uniformly scaling FontSize, the only property that actually changes what
    // renders.
    [Fact]
    public void ResizeHandlePosition_UnrotatedElement_IsAtTopRightCorner()
    {
        var editor = CreateEditor(out _);
        editor.AddStaticText(100, 100, "Hello"); // box [100,120]x[100,110]
        var handle = editor.ResizeHandlePosition();
        Assert.NotNull(handle);
        Assert.Equal(120, handle!.Value.X, precision: 6);
        Assert.Equal(110, handle.Value.Y, precision: 6);
    }
    [Fact]
    public void ResizeHandlePosition_NoSelection_ReturnsNull()
    {
        var editor = CreateEditor(out _);
        Assert.Null(editor.ResizeHandlePosition());
    }
    [Fact]
    public void ResizeHandlePosition_RotatedElement_StaysEquidistantFromCenter()
    {
        var editor = CreateEditor(out _);
        editor.AddStaticText(100, 100, "Hello"); // center (110, 105)
        var unrotatedHandle = editor.ResizeHandlePosition()!.Value;
        var unrotatedDistance = Math.Sqrt(Math.Pow(unrotatedHandle.X - 110, 2) + Math.Pow(unrotatedHandle.Y - 105, 2));
        var element = editor.Selected!;
        element.RotationAngle = 90;
        var rotatedHandle = editor.ResizeHandlePosition()!.Value;
        var rotatedDistance = Math.Sqrt(Math.Pow(rotatedHandle.X - 110, 2) + Math.Pow(rotatedHandle.Y - 105, 2));
        Assert.NotEqual(unrotatedHandle.X, rotatedHandle.X, precision: 3); // actually moved, not a no-op
        Assert.Equal(unrotatedDistance, rotatedDistance, precision: 6); // still orbits the same pivot at the same radius
    }
    [Fact]
    public void HitTestResizeHandle_PointAtHandlePosition_ReturnsTrue()
    {
        var editor = CreateEditor(out _);
        editor.AddStaticText(100, 100, "Hello");
        var handle = editor.ResizeHandlePosition()!.Value;
        Assert.True(editor.HitTestResizeHandle(handle.X, handle.Y));
    }
    [Fact]
    public void HitTestResizeHandle_PointFarFromHandle_ReturnsFalse()
    {
        var editor = CreateEditor(out _);
        editor.AddStaticText(100, 100, "Hello");
        Assert.False(editor.HitTestResizeHandle(0, 0));
    }
    [Fact]
    public void HitTestResizeHandle_NoSelection_ReturnsFalse()
    {
        var editor = CreateEditor(out _);
        Assert.False(editor.HitTestResizeHandle(120, 110));
    }
    [Fact]
    public void BeginResizeDrag_SetsIsResizingFontSize_AndEndDragClearsIt()
    {
        var editor = CreateEditor(out _);
        editor.AddStaticText(100, 100, "Hello");
        editor.BeginResizeDrag();
        Assert.True(editor.IsResizingFontSize);
        editor.EndDrag();
        Assert.False(editor.IsResizingFontSize);
    }
    [Fact]
    public void BeginResizeDrag_ThenDragTo_DoesNotAlsoMoveTheElement()
    {
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello");
        editor.BeginResizeDrag();
        editor.DragTo(500, 500);
        Assert.Equal(100, element.X, precision: 6);
        Assert.Equal(100, element.Y, precision: 6);
    }
    [Fact]
    public void ResizeDragTo_DraggingTwiceTheOriginalDiagonalFromAnchor_DoublesFontSize()
    {
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello", fontSize: 12); // anchor (100,100), diagonal sqrt(500)
        editor.BeginResizeDrag();
        var originalDiagonal = Math.Sqrt((20.0 * 20.0) + (10.0 * 10.0));
        editor.ResizeDragTo(100 + (2 * originalDiagonal), 100); // straight right, 2x the original distance
        Assert.Equal(24, element.FontSize, precision: 3);
    }
    [Fact]
    public void ResizeDragTo_DraggingHalfTheOriginalDiagonalFromAnchor_HalvesFontSize()
    {
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello", fontSize: 12);
        editor.BeginResizeDrag();
        var originalDiagonal = Math.Sqrt((20.0 * 20.0) + (10.0 * 10.0));
        editor.ResizeDragTo(100 + (0.5 * originalDiagonal), 100);
        Assert.Equal(6, element.FontSize, precision: 3);
    }
    [Fact]
    public void ResizeDragTo_DraggingVeryClose_ClampsToMinFontSize()
    {
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello", fontSize: 12);
        editor.BeginResizeDrag();
        editor.ResizeDragTo(100.0001, 100); // tiny but nonzero distance from the anchor
        Assert.Equal(CanvasElementEditor.MinFontSize, element.FontSize, precision: 3);
    }
    [Fact]
    public void ResizeDragTo_DraggingVeryFar_ClampsToMaxFontSize()
    {
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello", fontSize: 12);
        editor.BeginResizeDrag();
        editor.ResizeDragTo(1_000_000, 100);
        Assert.Equal(CanvasElementEditor.MaxFontSize, element.FontSize, precision: 3);
    }
    [Fact]
    public void ResizeDragTo_WithoutBeginResizeDrag_IsNoOp()
    {
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello", fontSize: 12);
        editor.ResizeDragTo(1000, 1000);
        Assert.Equal(12, element.FontSize, precision: 6);
    }
    [Fact]
    public void ResizeDragTo_DynamicElement_ScalesFontSize_SameAsStatic()
    {
        var editor = CreateEditor(out _);
        var element = editor.AddDynamicPlaceholder(100, 100, "Full Name", fontSize: 12);
        editor.BeginResizeDrag();
        var originalDiagonal = Math.Sqrt((20.0 * 20.0) + (10.0 * 10.0));
        editor.ResizeDragTo(100 + (2 * originalDiagonal), 100);
        Assert.Equal(24, element.FontSize, precision: 3);
    }
    [Fact]
    public void ResizeDragTo_RotatedElement_DraggingToCurrentHandlePosition_KeepsFontSizeUnchanged()
    {
        // Proves the rotate-point-backward-into-local-space math round-trips correctly: dragging
        // to exactly where the handle currently sits (already accounting for rotation) must be a
        // no-op scale change, not an accidental jump caused by comparing a rotated world point
        // against unrotated anchor coordinates.
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello", fontSize: 12);
        element.RotationAngle = 90;
        var handle = editor.ResizeHandlePosition()!.Value;
        editor.BeginResizeDrag();
        editor.ResizeDragTo(handle.X, handle.Y);
        Assert.Equal(12, element.FontSize, precision: 3);
    }
    // Sprint 9, "Add an adjustable width and height with text wrapping...": once an element
    // already has a box, the same corner handle resizes Width/Height directly instead of
    // scaling FontSize.
    [Fact]
    public void ResizeDragTo_ElementHasBox_UpdatesWidthAndHeightDirectly_NotFontSize()
    {
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello", fontSize: 12);
        element.Width = 20;
        element.Height = 10;
        editor.BeginResizeDrag();
        editor.ResizeDragTo(180, 160); // 80 right, 60 up from the (100,100) anchor
        Assert.Equal(80, element.Width!.Value, precision: 3);
        Assert.Equal(60, element.Height!.Value, precision: 3);
        Assert.Equal(12, element.FontSize, precision: 3); // unaffected in box mode
    }
    [Fact]
    public void ResizeDragTo_ElementHasBox_DraggingPastTheAnchor_LeavesDimensionUnchanged()
    {
        // Only a positive resulting width/height is applied — dragging back past the anchor on
        // one axis simply stops shrinking that axis rather than going negative or to zero.
        var editor = CreateEditor(out _);
        var element = editor.AddStaticText(100, 100, "Hello", fontSize: 12);
        element.Width = 20;
        element.Height = 10;
        editor.BeginResizeDrag();
        editor.ResizeDragTo(80, 160); // X (80) is now left of the anchor (100)
        Assert.Equal(20, element.Width!.Value, precision: 3); // unchanged - would have gone negative
        Assert.Equal(60, element.Height!.Value, precision: 3); // Y direction still applied normally
    }
    [Fact]
    public void ResizeHandlePosition_ElementHasBox_ReflectsWhateverTheInjectedMeasurerReturnsForIt()
    {
        // CanvasElementEditor itself has no opinion on measurement - it just uses whatever
        // _measureText(element) returns. Production wiring (TemplateCanvasControl.MeasureElement)
        // is box-aware (returns Width/Height directly instead of measuring text) once this story
        // lands; this test proves the handle position correctly follows a box-aware measurer,
        // using a purpose-built fake rather than duplicating that production logic here.
        var document = TemplateLayoutDocument.CreateDefault();
        var editor = new CanvasElementEditor(document, BoxAwareSize);
        var element = editor.AddStaticText(100, 100, "Hi");
        element.Width = 200;
        element.Height = 150;
        var handle = editor.ResizeHandlePosition();
        Assert.NotNull(handle);
        Assert.Equal(300, handle!.Value.X, precision: 3); // 100 + 200
        Assert.Equal(250, handle.Value.Y, precision: 3); // 100 + 150
        static (double Width, double Height) BoxAwareSize(TextElementLayout e) =>
            e.HasBox ? (e.Width!.Value, e.Height!.Value) : (20.0, 10.0);
    }
    // Sprint 7, "Snap elements to grid and guides".
    [Fact]
--- a/code/src/EnvelopeRenderer.Desktop.Tests/TemplateLayoutXmlSerializerTests.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Tests/TemplateLayoutXmlSerializerTests.cs
@@ -233,6 +233,92 @@ public class TemplateLayoutXmlSerializerTests : IDisposable
        Assert.Equal(-37.25, reloadedElement.RotationAngle, precision: 6);
    }
    [Fact]
    public void SaveThenLoad_RoundTripsWidthAndHeight()
    {
        var document = new TemplateLayoutDocument(CanvasSettings.CreateDefault());
        var element = TextElementLayout.CreateStatic(10, 20, "Wraps");
        element.Width = 150.5;
        element.Height = 60.25;
        document.Elements.Add(element);
        TemplateLayoutXmlSerializer.Save(document, _tempPath);
        var loaded = TemplateLayoutXmlSerializer.TryLoad(_tempPath, out var reopened, out var errors);
        Assert.True(loaded, string.Join("; ", errors));
        var reloadedElement = reopened!.Elements.Single();
        Assert.Equal(150.5, reloadedElement.Width!.Value, precision: 6);
        Assert.Equal(60.25, reloadedElement.Height!.Value, precision: 6);
        Assert.True(reloadedElement.HasBox);
    }
    [Fact]
    public void Save_NoWidthOrHeightSet_OmitsAttributesEntirely()
    {
        // Matches the same "only write non-default" pattern already used for
        // collapsible/angle above — a template with no boxed elements round-trips
        // byte-for-byte unaffected by this story.
        var document = new TemplateLayoutDocument(CanvasSettings.CreateDefault());
        document.Elements.Add(TextElementLayout.CreateStatic(0, 0, "plain"));
        TemplateLayoutXmlSerializer.Save(document, _tempPath);
        var xml = File.ReadAllText(_tempPath);
        Assert.DoesNotContain("width=", xml);
        Assert.DoesNotContain("height=", xml);
    }
    [Fact]
    public void Load_TemplateWithoutWidthOrHeightAttributes_LeavesThemNull()
    {
        File.WriteAllText(
            _tempPath,
            "<envelopeTemplate pageWidth=\"297\" pageHeight=\"684\">" +
            "<text x=\"120\" y=\"240\" font=\"Arial\" size=\"12\">Static label:</text>" +
            "</envelopeTemplate>");
        var result = TemplateLayoutXmlSerializer.TryLoad(_tempPath, out var document, out var errors);
        Assert.True(result, string.Join("; ", errors));
        Assert.Null(document!.Elements[0].Width);
        Assert.Null(document.Elements[0].Height);
        Assert.False(document.Elements[0].HasBox);
    }
    [Fact]
    public void Load_OnlyOneOfWidthOrHeightSet_HasBoxIsFalse()
    {
        // A one-sided value doesn't count as having a box (see TextElementLayout.HasBox's
        // remarks) — it's accepted (not a parse error), just inert.
        File.WriteAllText(
            _tempPath,
            "<envelopeTemplate pageWidth=\"297\" pageHeight=\"684\">" +
            "<text x=\"1\" y=\"1\" font=\"Arial\" size=\"12\" width=\"100\">Hi</text>" +
            "</envelopeTemplate>");
        var result = TemplateLayoutXmlSerializer.TryLoad(_tempPath, out var document, out var errors);
        Assert.True(result, string.Join("; ", errors));
        Assert.Equal(100, document!.Elements[0].Width);
        Assert.Null(document.Elements[0].Height);
        Assert.False(document.Elements[0].HasBox);
    }
    [Fact]
    public void Load_NonPositiveWidth_ReturnsFalseWithClearError()
    {
        File.WriteAllText(
            _tempPath,
            "<envelopeTemplate pageWidth=\"297\" pageHeight=\"684\">" +
            "<text x=\"1\" y=\"1\" font=\"Arial\" size=\"12\" width=\"0\" height=\"20\">Hi</text>" +
            "</envelopeTemplate>");
        var result = TemplateLayoutXmlSerializer.TryLoad(_tempPath, out _, out var errors);
        Assert.False(result);
        Assert.Contains(errors, e => e.Contains("width"));
    }
    [Fact]
    public void Save_DefaultCollapseIfBlankAndRotationAngle_OmitsAttributesEntirely()
    {
--- a/code/src/EnvelopeRenderer.Desktop.Tests/TemplatePreviewBuilderTests.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Tests/TemplatePreviewBuilderTests.cs
@@ -151,6 +151,38 @@ public class TemplatePreviewBuilderTests
        Assert.Equal(45, result.Draws[0].Angle, precision: 6);
    }
    // Sprint 9, "Add an adjustable width and height with text wrapping...".
    // Mirrors RenderEngineTests.Render_ElementWidthAndHeight_ArePassedThroughToTextDraw.
    [Fact]
    public void Build_ElementWithBox_PassesWidthAndHeightThroughToTheDraw()
    {
        var document = NewDocument();
        var element = TextElementLayout.CreateStatic(100, 300, "Wraps");
        element.Width = 150.5;
        element.Height = 60.25;
        document.Elements.Add(element);
        var result = TemplatePreviewBuilder.Build(document, Array.Empty<string>(), Record());
        Assert.True(result.Success, result.Message);
        Assert.Equal(150.5, result.Draws[0].Width);
        Assert.Equal(60.25, result.Draws[0].Height);
    }
    [Fact]
    public void Build_ElementWithNoBox_DrawHasNullWidthAndHeight()
    {
        var document = NewDocument();
        document.Elements.Add(TextElementLayout.CreateStatic(100, 300, "Plain"));
        var result = TemplatePreviewBuilder.Build(document, Array.Empty<string>(), Record());
        Assert.True(result.Success, result.Message);
        Assert.Null(result.Draws[0].Width);
        Assert.Null(result.Draws[0].Height);
    }
    // Mirrors RenderEngineTests.Render_AddressControl_ExpandsLinesInOrderWithMixedContent.
    [Fact]
    public void Build_AddressControl_ExpandsLinesInOrderWithMixedContent()
--- a/code/src/EnvelopeRenderer.Desktop.Tests/TextElementPropertiesEditorTests.cs
+++ b/code/src/EnvelopeRenderer.Desktop.Tests/TextElementPropertiesEditorTests.cs
@@ -240,6 +240,67 @@ public class TextElementPropertiesEditorTests
        Assert.Equal(10, element.RotationAngle, precision: 6);
    }
    // Sprint 9, "Add an adjustable width and height with text wrapping...".
    [Fact]
    public void SetWidthAndSetHeight_PositiveValues_UpdateSelectedElementAndSetHasBox()
    {
        var editor = new TextElementPropertiesEditor();
        var element = TextElementLayout.CreateStatic(0, 0, "a");
        editor.Select(element);
        editor.SetWidth(150.5);
        editor.SetHeight(60.25);
        Assert.Equal(150.5, element.Width!.Value, precision: 6);
        Assert.Equal(60.25, element.Height!.Value, precision: 6);
        Assert.True(element.HasBox);
    }
    [Theory]
    [InlineData(0)]
    [InlineData(-5)]
    public void SetWidth_NonPositiveValue_ClearsTheBox(double nonPositive)
    {
        var editor = new TextElementPropertiesEditor();
        var element = TextElementLayout.CreateStatic(0, 0, "a");
        element.Width = 100;
        element.Height = 50;
        editor.Select(element);
        editor.SetWidth(nonPositive);
        Assert.Null(element.Width);
        Assert.False(element.HasBox);
    }
    [Theory]
    [InlineData(0)]
    [InlineData(-5)]
    public void SetHeight_NonPositiveValue_ClearsTheBox(double nonPositive)
    {
        var editor = new TextElementPropertiesEditor();
        var element = TextElementLayout.CreateStatic(0, 0, "a");
        element.Width = 100;
        element.Height = 50;
        editor.Select(element);
        editor.SetHeight(nonPositive);
        Assert.Null(element.Height);
        Assert.False(element.HasBox);
    }
    [Fact]
    public void SetWidth_NoSelection_IsNoOp()
    {
        var editor = new TextElementPropertiesEditor();
        editor.SetWidth(100);
        Assert.Null(editor.Selected);
    }
    // Sprint 5, "Mix static text and CSV fields within a single text element".
    [Fact]
--- a/code/src/EnvelopeRenderer.Desktop/Views/TemplateCanvasControl.cs
+++ b/code/src/EnvelopeRenderer.Desktop/Views/TemplateCanvasControl.cs
@@ -78,6 +78,19 @@ public sealed class TemplateCanvasControl : Control
        }
    }
    /// <summary>True while an active move, resize, or rotate gesture is in progress on the
    /// canvas — a standalone element drag/rotate (<see cref="CanvasElementEditor"/>) or an
    /// Address Control move/resize/rotate. Post-Sprint-8 smoothness fix: lets
    /// <see cref="TemplateDesignerForm"/> skip its full properties-panel refresh (which
    /// repopulates the rebind-column combo box from every loaded CSV header on each call — real
    /// work only for a single-column-bound dynamic element) on every mouse-move tick of a
    /// gesture, syncing just the position/angle fields the gesture can actually change instead.
    /// Mirrors the exact condition <see cref="OnMouseMove"/> already used inline before this
    /// property existed.</summary>
    public bool IsInteracting =>
        _editor.IsDragging || _editor.IsRotating || _editor.IsResizingFontSize || _addressControlDragOffset is not null
        || _isResizingAddressControl || _isRotatingAddressControl;
    public TextElementLayout? SelectedElement => _editor.Selected;
    public AddressControlLayout? SelectedAddressControl => _selectedAddressControl;
    public int SelectedAddressLineIndex => _selectedAddressLineIndex;
@@ -285,6 +298,7 @@ public sealed class TemplateCanvasControl : Control
        if (_editor.Selected is not null)
        {
            DrawResizeHandle(g, transform, _editor.Selected);
            DrawRotateHandle(g, transform, _editor.Selected);
        }
    }
@@ -371,38 +385,56 @@ public sealed class TemplateCanvasControl : Control
        try
        {
            // Sprint 5, "Mix static text and CSV fields within a single text element", AC4: a
            // visible placeholder highlight per field-run *segment* rather than one whole-element
            // box — literal text within a mixed element gets no fill at all, so an operator can
            // see exactly which portion(s) of the line are field tokens versus literal text.
            // Sprint 4's unmapped-column warning color is now decided per run (see
            // AddressBlockPreviewCalculator's per-run ElementPreviewState.UnmappedRuns) rather
            // than for the whole element, so a mixed element with one bad token among several
            // good ones only flags that one segment.
            var boxHeight = height * transform.Scale;
            var segments = MeasureRunSegments(element, font);
            var cumulativeWidth = 0.0;
            for (var i = 0; i < segments.Count; i++)
            using var brush = new SolidBrush(System.Drawing.Color.FromArgb(element.Color.R, element.Color.G, element.Color.B));
            if (element.HasBox)
            {
                // Sprint 9, "Add an adjustable width and height with text wrapping...": GDI+'s own
                // rectangle-bounded DrawString wraps natively within the box, the design-time
                // approximation of the real CLI render's Debenu-native wrap (see this story's
                // sizing note — the two engines have no shared line-breaking code path, so this is
                // an accepted approximation, not a guarantee of matching the exact wrap points).
                // The per-run highlight segmentation below is a single-line layout and does not
                // yet extend across wrapped lines — left as a known, documented visual
                // approximation gap for this story; a per-run-aware wrapped highlight is polish-
                // tier scope for a later story, not required here.
                var boxRect = new RectangleF((float)drawX, (float)drawY, (float)(width * transform.Scale), (float)boxHeight);
                g.DrawString(element.DisplayText, font, brush, boxRect);
            }
            else
            {
                var (run, segmentWidth) = segments[i];
                if (run.IsField)
                // Sprint 5, "Mix static text and CSV fields within a single text element", AC4: a
                // visible placeholder highlight per field-run *segment* rather than one
                // whole-element box — literal text within a mixed element gets no fill at all, so
                // an operator can see exactly which portion(s) of the line are field tokens versus
                // literal text. Sprint 4's unmapped-column warning color is now decided per run
                // (see AddressBlockPreviewCalculator's per-run ElementPreviewState.UnmappedRuns)
                // rather than for the whole element, so a mixed element with one bad token among
                // several good ones only flags that one segment.
                var segments = MeasureRunSegments(element, font);
                var cumulativeWidth = 0.0;
                for (var i = 0; i < segments.Count; i++)
                {
                    var isRunUnmapped = i < state.UnmappedRuns.Count && state.UnmappedRuns[i];
                    var fillColor = isRunUnmapped
                        ? System.Drawing.Color.FromArgb(70, System.Drawing.Color.OrangeRed)
                        : System.Drawing.Color.FromArgb(60, System.Drawing.Color.DodgerBlue);
                    using var dynamicFill = new SolidBrush(fillColor);
                    var segX = drawX + (cumulativeWidth * transform.Scale);
                    var segBoxWidth = segmentWidth * transform.Scale;
                    g.FillRectangle(dynamicFill, (float)segX, (float)drawY, (float)segBoxWidth, (float)boxHeight);
                    var (run, segmentWidth) = segments[i];
                    if (run.IsField)
                    {
                        var isRunUnmapped = i < state.UnmappedRuns.Count && state.UnmappedRuns[i];
                        var fillColor = isRunUnmapped
                            ? System.Drawing.Color.FromArgb(70, System.Drawing.Color.OrangeRed)
                            : System.Drawing.Color.FromArgb(60, System.Drawing.Color.DodgerBlue);
                        using var dynamicFill = new SolidBrush(fillColor);
                        var segX = drawX + (cumulativeWidth * transform.Scale);
                        var segBoxWidth = segmentWidth * transform.Scale;
                        g.FillRectangle(dynamicFill, (float)segX, (float)drawY, (float)segBoxWidth, (float)boxHeight);
                    }
                    cumulativeWidth += segmentWidth;
                }
                cumulativeWidth += segmentWidth;
                g.DrawString(element.DisplayText, font, brush, (float)drawX, (float)drawY);
            }
            using var brush = new SolidBrush(System.Drawing.Color.FromArgb(element.Color.R, element.Color.G, element.Color.B));
            g.DrawString(element.DisplayText, font, brush, (float)drawX, (float)drawY);
            if (state.IsUnmappedColumn)
            {
                using var warnPen = new Pen(System.Drawing.Color.OrangeRed, 1.5f) { DashStyle = DashStyle.Dot };
@@ -438,6 +470,27 @@ public sealed class TemplateCanvasControl : Control
        }
    }
    /// <summary>Post-Sprint-8 user-requested feature: draws the font-size resize handle at the
    /// selected element's top-right corner (<see cref="CanvasElementEditor.ResizeHandlePosition"/>,
    /// which already accounts for rotation) — a small square, the same MediumSeaGreen-fill/white-
    /// outline style already used for the Address Control's resize handle, deliberately distinct
    /// from the rotate handle's round dot so the two are never confused at a glance.</summary>
    private void DrawResizeHandle(Graphics g, CanvasViewTransform transform, TextElementLayout element)
    {
        var handle = _editor.ResizeHandlePosition();
        if (handle is null)
        {
            return;
        }
        var (handleX, handleY) = transform.ToPixels(handle.Value.X, handle.Value.Y);
        var rect = new RectangleF((float)handleX - 4, (float)handleY - 4, 8, 8);
        using var brush = new SolidBrush(System.Drawing.Color.MediumSeaGreen);
        using var outline = new Pen(System.Drawing.Color.White, 1);
        g.FillRectangle(brush, rect);
        g.DrawRectangle(outline, rect.X, rect.Y, rect.Width, rect.Height);
    }
    /// <summary>Sprint 4, "Rotate elements by dragging a handle on the canvas": draws a small
    /// dot connected to the selected element's bounding-box center by a dotted line, at the
    /// world-space position <see cref="CanvasElementEditor.HandlePosition"/> computes (which
@@ -657,9 +710,19 @@ public sealed class TemplateCanvasControl : Control
    /// <see cref="GraphicsUnit.Point"/> measuring context so the result is directly comparable to
    /// the point-based coordinates <see cref="TextElementLayout"/> stores — this is a design-time
    /// visual approximation of the real Debenu-rendered size, not a guarantee of pixel-for-point
    /// parity with the final PDF.</summary>
    /// parity with the final PDF. Sprint 9, "Add an adjustable width and height with text
    /// wrapping...": once an element has a box (<see cref="TextElementLayout.HasBox"/>), its size
    /// *is* the box — authored geometry, not something to (re-)measure from text — so every
    /// downstream consumer of this method (hit-testing, the rotate handle, the resize handle, and
    /// <see cref="DrawElement"/> itself) automatically treats the box as the element's real
    /// bounding box with no changes needed at those call sites.</summary>
    private static (double Width, double Height) MeasureElement(TextElementLayout element)
    {
        if (element.HasBox)
        {
            return (element.Width!.Value, element.Height!.Value);
        }
        using var bitmap = new Bitmap(1, 1);
        using var g = Graphics.FromImage(bitmap);
        g.PageUnit = GraphicsUnit.Point;
@@ -764,6 +827,18 @@ public sealed class TemplateCanvasControl : Control
        ClearAddressSelection();
        // Post-Sprint-8 user-requested feature: a click on the selected element's font-size
        // resize handle starts a resize-drag, checked with the same precedence as the rotate
        // handle immediately below (only meaningful, and only checked, once something is already
        // selected) so it is never confused with a normal select/move click.
        if (_editor.Selected is not null && _editor.HitTestResizeHandle(x, y))
        {
            _editor.BeginResizeDrag();
            Capture = true;
            Invalidate();
            return;
        }
        // Sprint 4: a click on the currently selected element's rotate handle starts a rotate-drag
        // instead of a normal select/move — checked first (and only when something is already
        // selected) so it never intercepts a normal click elsewhere on the canvas.
@@ -851,8 +926,7 @@ public sealed class TemplateCanvasControl : Control
    protected override void OnMouseMove(MouseEventArgs e)
    {
        base.OnMouseMove(e);
        if (!_editor.IsDragging && !_editor.IsRotating && _addressControlDragOffset is null
            && !_isResizingAddressControl && !_isRotatingAddressControl)
        if (!IsInteracting)
        {
            return;
        }
@@ -899,7 +973,11 @@ public sealed class TemplateCanvasControl : Control
            return;
        }
        if (_editor.IsRotating)
        if (_editor.IsResizingFontSize)
        {
            _editor.ResizeDragTo(x, y);
        }
        else if (_editor.IsRotating)
        {
            _editor.RotateDragTo(x, y);
        }
@@ -915,10 +993,21 @@ public sealed class TemplateCanvasControl : Control
    protected override void OnMouseUp(MouseEventArgs e)
    {
        base.OnMouseUp(e);
        var wasInteracting = IsInteracting;
        _editor.EndDrag();
        _addressControlDragOffset = null;
        _isResizingAddressControl = false;
        _isRotatingAddressControl = false;
        Capture = false;
        // The gesture's own per-tick ElementsChanged notifications (OnMouseMove) only ask
        // TemplateDesignerForm for a cheap position/angle-only sync (see IsInteracting's
        // remarks) — fire one last notification now that the gesture has actually ended so the
        // form's full properties-panel refresh (rebind combo, address line list, etc.) still
        // runs exactly once at the end, the same as it always did before this smoothness fix.
        if (wasInteracting)
        {
            ElementsChanged?.Invoke(this, EventArgs.Empty);
        }
    }
 }
--- a/code/src/EnvelopeRenderer.Desktop/Views/TemplateDesignerForm.cs
+++ b/code/src/EnvelopeRenderer.Desktop/Views/TemplateDesignerForm.cs
@@ -137,6 +137,11 @@ public sealed class TemplateDesignerForm : Form
    // wide and not clamped to a single rotation's worth; an operator entering e.g. -270 instead
    // of 90 is a legitimate, if unusual, choice.
    private readonly NumericUpDown _angleInput = new() { DecimalPlaces = 1, Minimum = -3600m, Maximum = 3600m, Width = 80 };
    // Sprint 9, "Add an adjustable width and height with text wrapping...": 0 means "no box" (see
    // TextElementPropertiesEditor.SetWidth/SetHeight) — Minimum 0, not 1, so an operator can clear
    // a box back to today's unbounded behavior from the panel, not just by never setting one.
    private readonly NumericUpDown _elementWidthInput = new() { DecimalPlaces = 2, Minimum = 0, Maximum = 100000m, Width = 80 };
    private readonly NumericUpDown _elementHeightInput = new() { DecimalPlaces = 2, Minimum = 0, Maximum = 100000m, Width = 80 };
    // Sprint 4, "Collapse blank optional address lines consistently".
    private readonly CheckBox _collapseIfBlankInput = new() { Text = "Collapse if blank", AutoSize = true };
    // A plain Panel with explicit control positions (not a TableLayoutPanel) — deliberately
@@ -227,8 +232,24 @@ public sealed class TemplateDesignerForm : Form
            // A drag on the canvas moves the selected element without raising SelectionChanged
            // (the selection itself didn't change) — refresh the panel's X/Y so it never shows a
            // stale position after a drag.
            RefreshPropertiesPanel();
            RefreshSelectionLabel();
            //
            // Smoothness fix: while a move/resize/rotate gesture is actually in progress, this
            // fires on every single mouse-move tick. The full RefreshPropertiesPanel() repopulates
            // the rebind-column combo box from every loaded CSV header on each call — real,
            // non-trivial work for a single-column-bound dynamic/mixed element that a plain
            // position or angle change can never actually affect — which made dragging or
            // rotating a dynamic placeholder visibly choppy. Sync only the fields the gesture can
            // change while it's in progress; TemplateCanvasControl fires one final ElementsChanged
            // after the gesture ends (IsInteracting false by then) to run the full refresh once.
            if (_canvas.IsInteracting)
            {
                RefreshInteractivePositionFields();
            }
            else
            {
                RefreshPropertiesPanel();
                RefreshSelectionLabel();
            }
            // Sprint 7 AC: the preview must auto-refresh after any layout edit. TemplatePreviewControl
            // re-resolves against the live, shared document on every repaint, so an Invalidate() is
@@ -696,9 +717,13 @@ public sealed class TemplateDesignerForm : Form
        AddPropertyRow(11 * rowHeight, "Z-order (0 = bottom):", _zOrderInput, leftMargin, labelTop, inputTop);
        // Sprint 4, "Set a rotation angle...": degrees, free-form.
        AddPropertyRow(12 * rowHeight, "Angle (deg):", _angleInput, leftMargin, labelTop, inputTop);
        // Sprint 9, "Add an adjustable width and height with text wrapping...": 0 clears the box
        // back to today's unbounded behavior (see TextElementPropertiesEditor.SetWidth/SetHeight).
        AddPropertyRow(13 * rowHeight, "Box width (pt, 0 = none):", _elementWidthInput, leftMargin, labelTop, inputTop);
        AddPropertyRow(14 * rowHeight, "Box height (pt, 0 = none):", _elementHeightInput, leftMargin, labelTop, inputTop);
        // Sprint 4, "Collapse blank optional address lines...": a checkbox has no separate label
        // row — its own text doubles as the label, positioned like the other inputs.
        _collapseIfBlankInput.Location = new Point(leftMargin, (13 * rowHeight) + labelTop);
        _collapseIfBlankInput.Location = new Point(leftMargin, (15 * rowHeight) + labelTop);
        _propertiesPanel.Controls.Add(_collapseIfBlankInput);
        // Commits on Leave (not every keystroke, unlike the simpler FontFamily text box) — parsing
@@ -723,6 +748,8 @@ public sealed class TemplateDesignerForm : Form
        _fontSizeInput.ValueChanged += (_, _) => { if (!_suppressEvents) { SetSelectedFontSize((double)_fontSizeInput.Value); } };
        _zOrderInput.ValueChanged += (_, _) => { if (!_suppressEvents) { SetSelectedZOrder((int)_zOrderInput.Value); } };
        _angleInput.ValueChanged += (_, _) => { if (!_suppressEvents) { SetSelectedRotationAngle((double)_angleInput.Value); } };
        _elementWidthInput.ValueChanged += (_, _) => { if (!_suppressEvents) { SetSelectedWidth((double)_elementWidthInput.Value); } };
        _elementHeightInput.ValueChanged += (_, _) => { if (!_suppressEvents) { SetSelectedHeight((double)_elementHeightInput.Value); } };
        _collapseIfBlankInput.CheckedChanged += (_, _) => { if (!_suppressEvents) { SetSelectedCollapseIfBlank(_collapseIfBlankInput.Checked); } };
        _colorButton.Click += (_, _) => OnColorButtonClick();
        _addressLineList.SelectedIndexChanged += (_, _) =>
@@ -905,6 +932,29 @@ public sealed class TemplateDesignerForm : Form
        _canvas.NotifyElementChanged();
    }
    /// <summary>Sprint 9, "Add an adjustable width and height with text wrapping...": standalone
    /// elements only — Address Control's own box/wrap story is separate, dependent, not-yet-built
    /// work, so this field is a no-op for a selected Address Control today.</summary>
    private void SetSelectedWidth(double width)
    {
        if (_canvas.SelectedElement is not null)
        {
            _propertiesEditor.SetWidth(width);
        }
        _canvas.NotifyElementChanged();
    }
    private void SetSelectedHeight(double height)
    {
        if (_canvas.SelectedElement is not null)
        {
            _propertiesEditor.SetHeight(height);
        }
        _canvas.NotifyElementChanged();
    }
    private void SetSelectedCollapseIfBlank(bool collapseIfBlank)
    {
        if (_canvas.SelectedElement is not null)
@@ -951,6 +1001,41 @@ public sealed class TemplateDesignerForm : Form
        RefreshSelectionLabel();
    }
    /// <summary>Cheap counterpart to <see cref="RefreshPropertiesPanel"/> used while a canvas
    /// move/resize/rotate gesture is actively in progress (<see cref="TemplateCanvasControl.IsInteracting"/>):
    /// syncs only the numeric fields such a gesture can actually change (position, Address
    /// Control width, angle, and — post-Sprint-8 — font size, for the new resize-handle-driven
    /// text scaling), skipping the content/rebind-combo/address-line-list work that none of those
    /// gestures ever affects. Called on every mouse-move tick of a gesture, so it must stay
    /// cheap — see the call site's remarks for why the full refresh made dragging/rotating a
    /// dynamic element visibly choppy.</summary>
    private void RefreshInteractivePositionFields()
    {
        var selected = _canvas.SelectedElement;
        var selectedAddressControl = _canvas.SelectedAddressControl;
        _suppressEvents = true;
        try
        {
            _xInput.Value = ClampToNumericRange(_xInput, (decimal)(selected?.X ?? selectedAddressControl?.X ?? 0));
            _yInput.Value = ClampToNumericRange(_yInput, (decimal)(selected?.Y ?? selectedAddressControl?.Y ?? 0));
            _addressWidthInput.Value = ClampToNumericRange(
                _addressWidthInput, (decimal)(selectedAddressControl?.Width ?? AddressControlLayout.DefaultWidth));
            _angleInput.Value = ClampToNumericRange(
                _angleInput, (decimal)(selected?.RotationAngle ?? selectedAddressControl?.RotationAngle ?? 0));
            if (selected is not null)
            {
                _fontSizeInput.Value = ClampToNumericRange(_fontSizeInput, (decimal)selected.FontSize);
                _elementWidthInput.Value = ClampToNumericRange(_elementWidthInput, (decimal)(selected.Width ?? 0));
                _elementHeightInput.Value = ClampToNumericRange(_elementHeightInput, (decimal)(selected.Height ?? 0));
            }
        }
        finally
        {
            _suppressEvents = false;
        }
    }
    /// <summary>Repopulates the properties panel from the current selection without re-firing
    /// the panel's own change handlers (see <see cref="_suppressEvents"/>) — used on selection
    /// change and whenever the canvas moves the element (e.g. via a drag), so a drag and a
@@ -986,6 +1071,14 @@ public sealed class TemplateDesignerForm : Form
            _angleInput.Value = ClampToNumericRange(
                _angleInput, (decimal)(selected?.RotationAngle ?? selectedAddressControl?.RotationAngle ?? 0));
            _angleInput.Enabled = selected is not null || selectedAddressControl is not null;
            // Sprint 9, "Add an adjustable width and height with text wrapping...": standalone
            // elements only today (see SetSelectedWidth/SetSelectedHeight's remarks) — 0 in the
            // panel means "no box," matching TextElementPropertiesEditor.SetWidth/SetHeight's
            // own "non-positive clears the box" rule.
            _elementWidthInput.Value = ClampToNumericRange(_elementWidthInput, (decimal)(selected?.Width ?? 0));
            _elementHeightInput.Value = ClampToNumericRange(_elementHeightInput, (decimal)(selected?.Height ?? 0));
            _elementWidthInput.Enabled = selected is not null;
            _elementHeightInput.Enabled = selected is not null;
            _collapseIfBlankInput.Checked = selected?.CollapseIfBlank ?? selectedAddressLine?.CollapseIfBlank ?? false;
            var color = selected?.Color ?? selectedAddressLine?.Color ?? RgbColor.Black;
            _colorButton.BackColor = Color.FromArgb(color.R, color.G, color.B);
--- a/code/src/EnvelopeRenderer.Desktop/Views/TemplatePreviewControl.cs
+++ b/code/src/EnvelopeRenderer.Desktop/Views/TemplatePreviewControl.cs
@@ -80,7 +80,11 @@ public sealed class TemplatePreviewControl : Control
        }
        using var font = ResolveFont(draw.FontFamily, (float)draw.FontSize);
        var size = MeasureText(draw.Text, font);
        // Sprint 9, "Add an adjustable width and height with text wrapping...": a boxed draw's
        // size is the box itself (authored geometry), matching TemplateCanvasControl.MeasureElement's
        // same box-aware rule, so this preview and the editing canvas agree on the effective size.
        var hasBox = draw.Width is > 0 && draw.Height is > 0;
        var size = hasBox ? (Width: draw.Width!.Value, Height: draw.Height!.Value) : MeasureText(draw.Text, font);
        var (drawX, drawY) = transform.ToPixels(draw.X, draw.Y + size.Height);
        GraphicsState? savedState = null;
@@ -102,7 +106,16 @@ public sealed class TemplatePreviewControl : Control
        try
        {
            using var brush = new SolidBrush(Color.FromArgb(draw.Color.R, draw.Color.G, draw.Color.B));
            g.DrawString(draw.Text, font, brush, (float)drawX, (float)drawY);
            if (hasBox)
            {
                var boxRect = new RectangleF(
                    (float)drawX, (float)drawY, (float)(size.Width * transform.Scale), (float)(size.Height * transform.Scale));
                g.DrawString(draw.Text, font, brush, boxRect);
            }
            else
            {
                g.DrawString(draw.Text, font, brush, (float)drawX, (float)drawY);
            }
        }
        finally
        {
--- a/logs/process_improvement_log.md
+++ b/logs/process_improvement_log.md
@@ -4,7 +4,8 @@ Append-only log of insights about the **Scrum kit itself** (this repo's `process
 | 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). |
 | 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. |
--- a/state.md
+++ b/state.md
@@ -2,21 +2,23 @@
 > The single live "where are we right now" file. Read this FIRST at the start of any session that touches this repo - don't infer phase or sprint from conversation history. Updated LAST by whichever agent completes the current step, as documented in `AGENTS.md` under "Automated State-Driven Handoff."
 **Phase:** 3 - Sprint execution
 **Leading agent:** `dev-team`
 **Process file:** `process/03_sprint_execution.md`
 **Phase:** 1 - Backlog refinement (next sprint cycle)
 **Leading agent:** `product-owner`
 **Process file:** `process/01_backlog_refinement.md`
 **Sprint:** 8 planned (2026-10-26), not yet executed.
 **Sprint goal:** Ship whole-Address-Control rotation end-to-end - settable via the properties panel and adjustable by dragging a canvas handle - staying record-stable and visually consistent across the editing canvas, the Sprint 7 live preview, and the real CLI-rendered PDF, directly delivering the human product owner's reversal of the Sprint 6 Review "out of scope" call.
 **Current sprint backlog:** `backlog/sprints/sprint-8.md`
 **Sprint:** 9 executed, reviewed, and retrospected (2026-10-27). 13/13 points Done, sprint goal met in full.
 **Sprint goal:** Give static and dynamic text elements a real, independently adjustable width and height, so that content too long to fit wraps onto additional lines and is clipped (not silently overrun) once it exceeds the box — using Debenu's native wrap/box-drawing primitives for the real PDF and GDI+'s native rectangle-wrap for a close design-time approximation on the canvas and preview panel, directly answering the human product owner's "make the boxes longer" request. **Met in full**, per Sprint Review.
 **Current sprint backlog:** `backlog/sprints/sprint-9.md`
 **Next action:** Natural post-retrospective pause. When the user says to continue, start Sprint 8 backlog refinement as `product-owner`, folding in the Sprint 7 retrospective's three carried-forward action items: (1) apply the built-form-vs-canvas-only smoke rule per-story for epic 6's multi-select/align pair, since aligning/distributing may add new toolbar affordances requiring a full smoke; (2) when a later batch adds a control to a form an earlier batch already screenshotted, capture a fresh full-form screenshot rather than reusing the earlier one; (3) if a future PO sprint review again lacks shell/build access, disclose it and arrange an independent cross-check (as was done this sprint). No kit-level edit was made - the one new process signal (PO review lacking shell/build access this sprint) was logged as a "Watching" item in `logs/process_improvement_log.md`, judged a first-occurrence tooling-access gap distinct from the closed Sprint 3 PO-independence item, not severe enough to change `AGENTS.md`/`process/`/`templates/`. Also still open: the "Warn on text overflow before render" (epic 4) product question, not blocking, for whenever the human product owner wants to resolve it.
 **Sprint 9 execution, review, and retrospective summary:** The committed story ("Add an adjustable width and height with text wrapping to static and dynamic text elements," 13 pts) is Done. Real vendor-DLL investigation (licensed probe against the actual Debenu library, done *before* writing implementation code) found native `DrawTextBox`/`DrawRotatedTextBox`/`GetWrappedTextHeight`/`GetWrappedTextLineCount` entry points, confirmed via real rendered screenshots to wrap, clip (a too-short box returns fewer lines than exist, not an error), and compose rotation with wrapping natively in one call. `DebenuPdfRenderer.AddPage` now branches to these calls when a draw carries a box; canvas (`TemplateCanvasControl`) and preview (`TemplatePreviewBuilder`/`TemplatePreviewControl`) approximate the same wrap/clip via GDI+'s native rectangle-bounded drawing (a documented design-time approximation, since the desktop process shares no code path with the CLI's Debenu engine). The resize-handle coexistence question was resolved more simply than planned: the existing font-size handle became context-sensitive (box mode vs. font-scale mode, chosen once at drag-start via `HasBox`) rather than needing a second handle. Properties panel gained "Box width"/"Box height" fields. Tests: 448/448 -> 476/476 (23 new). Live-verified at three layers: a standalone licensed vendor-DLL probe with screenshots; a true end-to-end run (hand-authored template through the real built `EnvelopeRenderer.Cli.exe` against the real 392-record sample CSV, output PDF rasterized and visually inspected showing genuine 4-line wrap and genuine clip to "WILLIAM EDWARD"); and a reflection-driven built-form smoke against the real `TemplateDesignerForm` (real content TextBox, real Box width/height panel fields, real mouse-driven resize-handle drag, real canvas screenshot). Full detail: `backlog/sprints/sprint-9.md`, `backlog/epics/04_live_preview_and_record_navigation.md`, `backlog/backlog.md`'s Sprint 9 refinement/planning/Review outcome notes, `backlog/sprints/sprint-9-retrospective.md`.
 **Since the retrospective, same-day user feedback on the live Sprint 7 build (2026-10-19), handled outside formal ceremony:**
 - Two post-review fixes already implemented, tested, and live-verified (not new sprint work - corrections to Sprint 7's own just-shipped increment): (1) record-number navigation now auto-updates the preview with no "Go" button; (2) the editing canvas now rotates static and dynamic/mixed text elements identically (smooth center-pivot), while the real render and the Sprint 7 preview panel keep the record-stable anchor-pivot behavior from the Oct 9 defect fix unchanged. Both documented in `backlog/sprints/sprint-7.md`'s "Post-review fixes" section, `backlog/epics/02_template_designer_gui_foundation.md`, and `logs/technical_debt_log.md`. Test suite now 402/402 (up from 400), independently confirmed via a real `dotnet test` run.
 - New backlog item queued for Sprint 8 (user explicitly chose to queue rather than implement ad hoc): epic 8 (Composite Address Controls, reopened from Done) gained two new Ready, sized stories - "Rotate the whole Address Control as a single unit" (8 pts) and "Rotate the whole Address Control by dragging a handle on the canvas" (5 pts, depends on the former) - 13 points total. Confirmed by code inspection that Address Control's box geometry is author-set (not measured from resolved text), so whole-control rotation can safely pivot around the box center everywhere (editing canvas, preview, and real render) with no anchor-pivot workaround needed, unlike the standalone-element defect fix. Full detail in `backlog/epics/08_composite_address_controls.md` and `backlog/backlog.md`'s new dated note.
 **Real de-risking finding with a downstream effect:** Debenu composes rotation and wrapping natively in one `DrawRotatedTextBox` call, meaning "Support rotated wrapped text and a live wrap/clip indicator for text elements" (epic 4, previously estimated 8 pts) likely already has its rotation half satisfied by this sprint's shipped code. Not re-sized unilaterally — flagged for `product-owner`/`dev-team` to re-confirm at the next backlog refinement before it is ever committed to a sprint.
 **Next action:** Execute Sprint 8 as `dev-team` (13 points committed, dependency-ordered per `backlog/sprints/sprint-8.md`): Batch 1 "Rotate the whole Address Control as a single unit" (8 pts, no dependency - angle property, persistence, box-center pivot math across canvas/preview/render), Batch 2 "Rotate the whole Address Control by dragging a handle on the canvas" (5 pts, depends on Batch 1). `scrum-master` deliberately kept this an under-commit (13 pts vs. the proven 18-20 range) rather than pairing with epic 6's multi-select/align pair (would total 23, a new high): both this sprint's drag-handle story and multi-select would land foundational, first-of-its-kind changes in the same small set of GUI files (`CanvasElementEditor`, `TemplateCanvasControl`), and this team consistently keeps that class of risk isolated. Honor the Sprint 7 retro carry-ins: built-form smoke for any GUI story touching form layout/properties/toolbar actions; a FRESH full-form screenshot per batch if a later batch changes a form an earlier batch already screenshotted (not a reused one - the exact Sprint 7 near-miss). Still-open, non-blocking: "Warn on text overflow before render" (epic 4) product question; both epic 7 impediments (asset path strategy, UNC timeout/retry, open since 2026-09-04); epic 6's multi-select/align pair (10 pts) and "Undo and redo layout changes" (13 pts, feasibility de-risked) remain Ready for Sprint 9; "Complete the first text-only operator workflow" (epic 1, 5 pts) is labeled Ready but flagged by scrum-master as a stale onboarding-era placeholder needing re-verification before ever being pulled, same staleness pattern epic 4 had at the 2026-10-16 refinement.
 **Process-improvement finding, Proposed (not yet applied — awaiting human product owner review):** the project's own Debenu license key (`key.txt` at the repo root, one level above `code/`) was found this sprint after at least two prior points (this project's own `DebenuPdfRendererIntegrationTests`/`DebenuPdfRendererRotationTests` design, and the Sprint 7 Sprint Review) concluded or implied no key was available, having only searched under `code/` rather than the actual repo root the resolver's own 10-level upward walk reaches. Logged in `logs/process_improvement_log.md` (2026-10-27) as a documentation-nudge proposal (no code change needed) for `CLI_CONTRACT.md`'s "Debenu license key" section or `AGENTS.md` — status **Proposed**, needs a human decision on exact wording/placement before being applied.
 **Retrospective outcome (`scrum-master`, `backlog/sprints/sprint-9-retrospective.md`):** Ninth sprint, clean delivery, no drops (one item — built-form-smoke discipline — showed genuine follow-through in substance despite its literal multi-batch trigger not arising this single-story sprint; two items correctly carry forward unchanged since untriggered for a third sprint running: epic 6's built-form-smoke rule, and the Sprint 6 Address Control interaction-code extraction evaluation). One near-miss named honestly: the live built-form GUI smoke was initially dropped from the story's own task list mid-execution (only the CLI-side check was recorded), caught and completed within the same session before Sprint Review — flagged as a new action item so "the CLI check feels sufficient" doesn't recur as reasoning for skipping a GUI-touching story's own DoD-required smoke.
 **Next action:** Natural post-retrospective pause per `AGENTS.md`. When the user says to continue, start Sprint 10 backlog refinement as `product-owner`, folding in the Sprint 9 retrospective's action items above (especially: re-confirm/re-size "Support rotated wrapped text..." before ever committing it). Ready-and-waiting work for Sprint 10: "Support rotated wrapped text and a live wrap/clip indicator for text elements" (epic 4, ~8 pts pending re-sizing) and "...Address Control lines" (epic 4, 8 pts, depends on the former); epic 6's multi-select/align pair (10 pts) and "Undo and redo layout changes" (13 pts) remain Ready and unchanged. Still open, non-blocking: "Warn on text overflow before render" (epic 4, provisional 5 pts, blocked on both wrap/clip stories above landing first); both epic 7 impediments (asset path strategy, UNC timeout/retry, open since 2026-09-04); "Complete the first text-only operator workflow" (epic 1, 5 pts) remains flagged as a stale onboarding-era placeholder needing re-verification before ever being pulled; the Proposed process-improvement log entry above awaiting a human decision.
 ## Phase reference
@@ -76,3 +78,14 @@ After phase 5, loop back to phase 1 for the next sprint.
 | 2026-10-19 | 3 - Sprint execution | `dev-team` completed all 3 committed batches (18/18 points). Batch 1 (record-specific preview, 8 pts): extracted a single shared `TextResolver` and `RotationPivotCalculator` (replacing two near-duplicate implementations each), built a framework-free `TemplatePreviewBuilder`/`PreviewTextDraw` mirroring `RenderEngine`, and a dedicated `TemplatePreviewControl` wired into `TemplateDesignerForm` via a deterministic `TableLayoutPanel` (avoiding a repeat of Sprint 6's dock-order bug). Live-verified via a real built-`.exe` reflection harness: rotated dynamic pivot stayed fixed across differently-sized names, Address Control collapse worked against real data. One new Low-impact tech debt logged (Address Control lines visually overlap at small font sizes - pre-existing GDI+ measurement approximation, doesn't affect the real PDF render path). Batch 2 (jump to record, 5 pts): new `CsvRecordNavigator` mirroring the CLI's proven `CsvRecordSource` pattern; live-verified navigating the real 392-record sample CSV including an out-of-range case. Batch 3 (grid/guide snapping, 5 pts): new `GridSnapper` wired into both `CanvasElementEditor` and `TemplateCanvasControl`; live-verified with a canvas-only smoke confirming mid-gesture snapping. 400/400 tests passing (up from 349). |
 | 2026-10-19 | 4 - Sprint review | `product-owner` verified all 3 Sprint 7 stories against acceptance criteria by reading the actual new/changed code and test files (not just dev-team's summary) - confirmed the shared `TextResolver`/`RotationPivotCalculator` are genuinely used by canvas and preview alike, the preview auto-refreshes on every real edit path, collapse/mixed-content/Address-Control scenarios in `TemplatePreviewBuilderTests` genuinely mirror `RenderEngineTests`, record navigation is a real unbounded scan (not the 20-row preview cap), and grid snapping is continuous mid-drag with zero template-format changes. Verdict: sprint goal met in full. Lacking shell/build access this session, substituted an independent `[Fact]`/`[Theory]` count (matched 400/400 exactly) and code-level checks for a live `dotnet test` run and built-`.exe` re-verification - disclosed explicitly rather than presented as full re-verification. I (top-level session) ran `dotnet test` directly afterward and confirmed 400/400 (299 Desktop + 101 CLI) for real. Updated `backlog/backlog.md`'s epic table and Sprint 7 Review outcome note, epics 04/06 with verification detail, and added a PO confirmation to the new Low-impact Address Control overlap tech debt entry (confirmed root cause confined to GDI+ canvas/preview measurement, doesn't touch the real PDF render path). |
 | 2026-10-19 | 5 - Sprint retrospective | `scrum-master` ran the retrospective (`backlog/sprints/sprint-7-retrospective.md`). Sixth consecutive clean full-follow-through sprint: all three Sprint 6 carry-ins held (built-form smoke rule applied correctly - canvas-only smoke for the canvas-only grid-snap story was correct per the rule's own original wording, not a shortcut, though one minor nuance was named: Batch 2 reused Batch 1's full-form screenshot rather than capturing a fresh one after adding a new toolbar control; product-risk-first ordering confirmed; cross-layer code-inspection sizing confirmed via cited real method/class names in the 2026-10-16 sizing notes). New "Watching" item logged in `logs/process_improvement_log.md` (not a kit edit): this sprint's PO review lacked shell/build access and substituted a static test-attribute count plus code reading for a live `dotnet test` run - judged a first-occurrence tooling-access gap, explicitly distinct from the closed Sprint 3 PO-independence item, not severe enough for a kit change. No anti-patterns found. Three concrete action items carried into Sprint 8 planning (see Next action above). |
 | 2026-10-26 | 3 - Sprint execution | `dev-team` completed both committed Sprint 8 batches (13/13 points). Batch 1, "Rotate the whole Address Control as a single unit" (8 pts): new `angle` attribute on `<addressControl>` (default 0) persisted independently on CLI and desktop; rigid-group rotation around the control's authored box center applied to `RenderEngine.BuildAddressControlDraws`, `TemplatePreviewBuilder`, and `TemplateCanvasControl.DrawAddressControl`; rotated-rectangle hit-testing added for selection and resize; a new shared `PointRotation` helper (Desktop.Core) and a CLI-side rotate-around-pivot helper, both unit tested; pivot-stability regression tests confirming collapse never shifts the pivot. Batch 2, "...by dragging a handle on the canvas" (5 pts): new framework-free `AddressControlRotateHandle` (Desktop.Core) providing hit-test/drag-angle math, wired into `TemplateCanvasControl`'s mouse handlers and reusing Batch 1's existing properties-panel sync for free. Full suite grew to 433/433 (326 desktop, 107 CLI). Both batches live-verified via a reflection-driven built-`.exe` harness (CLI PDF content-stream inspection, canvas/preview screenshots, simulated real mouse drags), with fresh (not reused) full-form screenshots per batch per the Sprint 7 retrospective carry-in. One new Low-impact technical debt item logged (pre-existing Sprint 6 Address Control hit-test/move/resize logic remains WinForms-only, untestable by unit tests, unlike this sprint's own newly-extracted rotation math). Full detail: `backlog/sprints/sprint-8.md`. |
 | 2026-10-26 | 4 - Sprint review | `product-owner` verified both Sprint 8 stories against acceptance criteria (verdict: sprint goal met in full). Independently re-ran the full test suite (433/433 confirmed directly via `dotnet test`, not trusted from dev-team's report) and read the actual persistence code (`TemplateLayoutXmlSerializer.CreateAddressControl`, `TemplateXmlParser.ParseAddressControl`) and the new unit-tested classes (`PointRotation`, `AddressControlRotateHandle`) directly, confirming the claims rather than rubber-stamping them. Disclosed that this session did not rebuild/re-drive the desktop `.exe` itself, so dev-team's live built-form screenshot evidence was cross-checked against code rather than re-observed - same kind of disclosed limitation as the Sprint 7 review. Confirmed the new Low-impact technical debt item as non-blocking. The Composite Address Controls and Mixed-Content Text epic is now Done outright (4 of 4 stories). Updated `backlog/backlog.md`'s epic table and added a "Sprint 8 Review outcome" section; added Sprint Review verification notes to both stories in `backlog/epics/08_composite_address_controls.md`. |
 | 2026-10-26 | 5 - Sprint retrospective | `scrum-master` ran the retrospective (`backlog/sprints/sprint-8-retrospective.md`). Eighth sprint, clean delivery, no drops on prior actions (two of three Sprint 7 items directly confirmed, the third correctly carried forward unchanged since its trigger condition - epic 6's pair being pulled - didn't occur this sprint). Revisited and updated the Sprint 7 "PO review tooling-access" watch item in `logs/process_improvement_log.md`: no recurrence this sprint (real `dotnet test` access, used directly), kept as "Watching" rather than closed. No kit-level edit. New non-kit insight logged for Sprint 9 consideration: evaluate extracting the pre-existing Sprint 6 Address Control interaction code (still WinForms-only/untestable) to a `CanvasElementEditor`-equivalent before/alongside any story that next deepens Address Control interaction logic. All anti-patterns checked; none found. |
 | 2026-10-26 | 3 - Sprint execution (ad hoc, outside formal ceremony) | User reported choppy drag/rotate for a standalone dynamic/mixed-content element. Clarified scope with the user first, then confirmed root cause by code inspection: the properties panel's full refresh (including a from-scratch rebind-column-combo repopulation, real work only for single-column-bound elements) ran on every mouse-move tick of a drag/rotate gesture, not just at gesture end. Fixed via a new `TemplateCanvasControl.IsInteracting` property and cheap `TemplateDesignerForm.RefreshInteractivePositionFields()`, deferring the full refresh to `OnMouseUp`. Live-verified with a reflection-driven harness plus a true before/after comparison (temporary git worktree at the pre-fix commit): 60 synthetic drag ticks dropped from 88.56 ms/120 mid-drag combo-repopulations to 1.32 ms/0 mid-drag repopulations; same result for rotate. 433/433 tests still passing. Documented in `backlog/epics/02_template_designer_gui_foundation.md`. |
 | 2026-10-26 | 1 - Backlog refinement | User asked to make control boxes "longer." Too large for ad hoc coding, so handled as proper backlog work: `product-owner` clarified scope with the user across two rounds of questions (which controls, wrap vs. clip, which dimensions), resolving the "Warn on text overflow before render" story's blocking open question (parked since 2026-10-16). Wrote two new dependent, not-yet-sized stories in `backlog/epics/04_live_preview_and_record_navigation.md` for adjustable width/height with text wrapping (standalone elements, then Address Control), re-scoped "Warn on text overflow before render" to depend on both. Found via code inspection that the vendor Debenu library already exposes native wrap/box-drawing primitives (`DPLDrawWrappedText`, `DPLDrawTextBox`, `DPLGetWrappedTextHeight`), materially de-risking the likely implementation. No code written; needs dev-team sizing before Sprint 9. |
 | 2026-10-26 | 3 - Sprint execution (ad hoc, outside formal ceremony) | User asked for a way to resize static/dynamic text elements. Clarified scope first (existing numeric Font size panel field vs. a canvas drag handle) — user wanted the handle. Since standalone elements have no independent Width/Height, the new handle uniformly scales `FontSize`. Added `CanvasElementEditor.ResizeHandlePosition`/`HitTestResizeHandle`/`BeginResizeDrag`/`ResizeDragTo` (Desktop.Core, 15 new unit tests) and a square canvas handle at the box's top-right corner, clamped to the panel's existing 1-1000pt bounds, bidirectionally synced via the smoothness fix's `RefreshInteractivePositionFields`. Live-verified through the real `OnMouseDown`/`OnMouseMove`/`OnMouseUp` pipeline: a click on the handle's real pixel position started a resize-drag, dragging outward grew a 12pt element to ~43pt (panel tracking live), dragging inward shrank it to the clamped 1pt floor. 448/448 tests passing. Documented in `backlog/epics/02_template_designer_gui_foundation.md`. |
 | 2026-10-26 | 1 - Backlog refinement | `product-owner` ran Sprint 9 backlog refinement after the user confirmed the post-Sprint-8-retrospective pause point with "continue." Re-verified epic 6's two Ready items (multi-select, undo/redo) against real code changes since 2026-10-19; no material change found. Sized the three new epic-4 wrap/clip stories via real code/vendor-API inspection: the standalone-element core story at 13 points (real de-risking finding: Debenu already exposes native `DPLDrawWrappedText`/`DPLDrawTextBox`/`DPLGetWrappedTextHeight` wrap/box primitives, and GDI+ has an equivalent rectangle-wrap capability, so neither engine needs a hand-rolled word-wrap algorithm; real risk found: the desktop app and CLI are separate processes with no shared wrap code path, so canvas/preview wrap is an accepted design-time approximation, not guaranteed PDF parity) — found too large to keep whole and split further into "Support rotated wrapped text and a live wrap/clip indicator" (8 points, carved out at sizing time) and "...for Address Control lines" (8 points). "Warn on text overflow before render" given a provisional 5-point estimate by analogy to two already-Done patterns at this scale. Total new Ready scope: 29 points across 3 stories (34 including the still-Not-Ready "Warn" story). Full detail: `backlog/backlog.md`'s Sprint 9 backlog refinement outcome, `backlog/epics/04_live_preview_and_record_navigation.md`, `backlog/epics/06_layout_efficiency_and_operator_tooling.md`. |
 | 2026-10-26 | 2 - Sprint planning | `scrum-master` facilitated with `product-owner`/`dev-team` input, immediately following backlog refinement. Capacity signal now has eight data points (20, 19, 18, 18, 15, 18, 18, 13), with both 15 and 13 treated as documented deliberate under-commits, not capacity misses. Committed 13 points: the epic-4 wrap/clip core story alone, a deliberate under-commit — rejected pairing it with its own 8-point dependent follow-up (would total 21, a new team-wide high for a first-of-its-kind capability with real unconfirmed vendor-API unknowns, and unlike prior "pull the whole pair" precedents this story is independently valuable and shippable alone) and rejected pairing it with epic 6's 10-point multi-select/align pair (23 total, stacking two large first-of-its-kind initiatives in one sprint, the same risk profile this team avoided at Sprint 8 planning). No smaller rounding-out item found, same conclusion as Sprint 8 planning. Recorded in `backlog/sprints/sprint-9.md`; full reasoning in `backlog/backlog.md`'s Sprint 9 planning outcome note. |
 | 2026-10-27 | 3 - Sprint execution | `dev-team` completed the sprint's single committed story, "Add an adjustable width and height with text wrapping to static and dynamic text elements" (13/13 points). A licensed real-DLL probe against the actual Debenu library, run before any implementation code, found and confirmed (via real rendered screenshots) native `DrawTextBox`/`DrawRotatedTextBox`/`GetWrappedTextHeight`/`GetWrappedTextLineCount` entry points that wrap, clip, and compose rotation with wrapping natively. `TextElementLayout`/`TemplateElement` gained nullable `Width`/`Height` (optional `width`/`height` XML attributes, both sides independently implemented); `DebenuPdfRenderer.AddPage` branches to the native calls when a draw has a box; canvas and preview panel approximate the same wrap/clip via GDI+'s native rectangle-bounded drawing (a documented design-time approximation). The resize-handle coexistence question was resolved by making the existing font-size handle context-sensitive (box mode vs. font-scale mode, chosen once at drag-start) rather than adding a second handle. Properties panel gained Box width/height fields. Tests: 448/448 -> 476/476 (23 new, including a licensed pixel-based clipping test). Live-verified at three layers: the vendor-DLL probe itself; a true end-to-end run (real template through the real built `EnvelopeRenderer.Cli.exe` against the real 392-record sample CSV, output rasterized and visually confirmed to wrap/clip correctly); and a reflection-driven built-form smoke against the real `TemplateDesignerForm` (real panel fields, real mouse-driven resize drag, real canvas screenshot) — the last of these was initially skipped mid-execution and caught/completed before Sprint Review. Found, not assumed: the project's own Debenu license key (`key.txt`, repo root) had been overlooked by at least two prior sprints' searches (which only checked under `code/`). Full detail: `backlog/sprints/sprint-9.md`. |
 | 2026-10-27 | 4 - Sprint review | `product-owner` verified the Sprint 9 story against acceptance criteria (verdict: sprint goal met in full). Independently re-ran the full test suite (476/476 confirmed directly via `dotnet test`) and read the actual `DebenuPdfRenderer.AddPage` box branch, `TemplateLayoutXmlSerializer`/`TemplateXmlParser` persistence, and new test files directly, confirming the claims rather than trusting dev-team's report alone. Agreed the dependent "Support rotated wrapped text..." story (previously 8 pts) needs re-confirmation, not silent reuse, given this sprint's own de-risking finding. Updated `backlog/backlog.md`'s epic table and added a "Sprint 9 Review outcome" section; added a Development verification note to the story in `backlog/epics/04_live_preview_and_record_navigation.md`. |
 | 2026-10-27 | 5 - Sprint retrospective | `scrum-master` ran the retrospective (`backlog/sprints/sprint-9-retrospective.md`). Ninth sprint, clean delivery, no drops (one item showed genuine follow-through in substance despite its literal trigger not arising; two correctly carry forward unchanged, one now a third sprint running). Named one honest near-miss: the built-form GUI smoke was initially dropped from the story's own task list mid-execution, caught and completed before review — logged as a new action item. Logged a **Proposed** (not yet applied) process-improvement entry in `logs/process_improvement_log.md`: the project's own Debenu license key was overlooked by at least two prior sprints' searches, a recurring (2+ occurrence) verification-depth gap meeting `AGENTS.md`'s kit-level bar — recommended fix is a documentation nudge in `CLI_CONTRACT.md`/`AGENTS.md`, awaiting a human product owner decision on wording/placement. All anti-patterns checked; none found. |