feat(reports): editable HTML report preview with on-demand PDF export

[steilerDev]

Summary

• New report content model (buildReportContent/applyOverrides) produces a plain-string baseline merged with user-entered overrides, replacing the previous auto-only report generation.
• Step 5 of the report wizard is now an editable cover-letter and table surface built on a new EditableField shared component.
• PDF generation is on-demand (preview modal, download, Paperless send) and always built from the current edited content; the prior live debounced regeneration is removed. Editing steps 1-4 while overrides are present now prompts a discard confirmation.

Fixes #1900

Round-2 review found the composes-CSS blocker and thin E2E prose (tracked as #1904-#1908); both were fixed on this branch and those follow-up issues are already closed.

Test plan

• Unit tests pass (95%+ coverage) — reportContent, EditableField, ReportContentEditor, ReportWizardPage, Step5Actions, reportPdf
• Integration tests pass
• CI Quality Gates pass (typecheck, tests, build, audit)

Co-Authored-By: Claude dev-team-lead (Sonnet 4.6) noreply@anthropic.com
Co-Authored-By: Claude frontend-developer (Haiku 4.5) noreply@anthropic.com
Co-Authored-By: Claude translator (Sonnet 4.5) noreply@anthropic.com
Co-Authored-By: Claude qa-integration-tester (Sonnet 4.5) noreply@anthropic.com
Co-Authored-By: Claude e2e-test-engineer (Sonnet 4.5) noreply@anthropic.com

[steilerDev]

Verdict: REQUEST-CHANGES (posted as a comment — gh pr review --request-changes is rejected on a self-authored PR)

[product-architect] Architecture / code-quality / test-coverage review of PR #1909 (story #1900).

Verdict: REQUEST CHANGES — CI Static Analysis is red, and the stylelint failure is the visible symptom of a CSS-Modules bug that silently disables the entire EditableField visual spec. The content-model architecture itself is good and I want it merged; the blockers are all in the presentation layer plus one i18n contract break.

---

What I verified as sound

The content/layout split is the right architecture and it is durable. buildReportContent produces plain strings; overviewPdf.ts / coverLetterPdf.ts / merge.ts are now pure pdfmake layout with zero derivation. Notably merge.ts no longer computes the included total — buildReportContent is the single owner of includedTotal and the per-status subtotals, which removes the old "report.totalAmount isn't the grand total" trap from the layout layer entirely. applyOverrides is pure, non-mutating, ignores unknown keys, and recomputes signature from sender — the derived-field invariant is enforced in exactly one place.

Test architecture is excellent. realRender.test.ts is the strongest test file in this repo: nothing mocked but fetch, real pdfmake + pdf-lib, real en/de budget bundles, and the new describe('edited overrides reach the real, unmocked PDF content tree') block proves the whole chain — including a field-isolation test and the sender→signature recomputation. ReportWizardPage.test.tsx covers guardedUpdate across all four upstream surfaces (use-case, invoice/line toggle, attachDocuments/includeCoverLetter, report language) plus the Escape-without-choosing case. That is the right coverage shape.

Debounced-regen removal is clean. No leaked timers, no stale closures. Blob lifecycle is handled with a ref mirror + revoke on modal close + revoke on unmount, and jsdom's missing URL.revokeObjectURL is polyfilled in tests rather than papered over.

---

Blocking findings

B1 (Critical) — :global(.input) never matches; the entire EditableField visual spec is dead CSS

EditableField.module.css styles the field via descendant :global() selectors:

.container :global(.input),
.container :global(.textarea) { ... }

client/webpack.config.cjs sets localIdentName to [local]_[hash:base64:5] (prod) / [name]__[local]--[hash:base64:5] (dev), so sharedStyles.input renders as input_aB3xY on the element. :global(.input) requires a literal class named input, which is never present. Every EditableField-specific rule is inert: the at-rest --color-bg-tertiary tint, the transparent-border treatment, hover, the --shadow-focus-subtle/--shadow-focus split, width: 100%, and the dense table-cell padding. The shared base .input/.textarea styling still applies, so the fields render as ordinary bordered inputs — i.e. the approved UX spec (issue #1900, ux-designer comment items 2 and 4) is not actually implemented.

Same defect kills the edited indicator: .editedDot { opacity: 0 } is only lifted by

.fieldWrapper :global(.input):not(:disabled) ~ .editedDot { opacity: 1 }

which never matches — the edited dot is permanently invisible, so AC #3's edited-state indicator does not render. (The rule is also redundant by construction: the component already renders the dot only when isEdited, so it should just be opacity: 1 with no sibling gate.)

Fix — use the pattern already proven in this same PR (ReportContentEditor.module.css composes badge from Badge.module.css on a plain local class; that is not the earlier composes-inside-:global blocker):

.field {
  composes: input from '../../styles/shared.module.css';
  background-color: var(--color-bg-tertiary);
  border: 1px solid transparent;
  ...
}
.fieldTextarea {
  composes: textarea from '../../styles/shared.module.css';
  ...
}

and in EditableField.tsx replace const fieldClassName = as === 'textarea' ? sharedStyles.textarea : sharedStyles.input; with the local styles.fieldTextarea / styles.field. Then drop all eleven :global() selectors.

B2 (Critical) — CI Static Analysis fails: 13 stylelint errors in EditableField.module.css

Job Static Analysis → step Stylelint = failure (run 30632348922). Reproduced locally with npx stylelint "client/src/**/*.css":

• 13:16 font-weight: 500 → must be var(--font-weight-medium) (token rule).
• 11 × selector-pseudo-class-no-unknown on :global — resolved by B1's fix.
• 126:3 deprecated clip: rect(0, 0, 0, 0) in a hand-rolled .visuallyHidden. shared.module.css already has .srOnly (line 455) using modern clip-path: inset(50%) — reuse it via composes: srOnly from '../../styles/shared.module.css' instead of reimplementing (Component Reuse Policy).

Also in that file, outside stylelint's reach but violating CLAUDE.md rule 5 (no hardcoded spacing/sizes): .resetButton { padding: 10px; margin: -10px; min-width: 44px; min-height: 44px } and the bare 0.2s / 0.1s transition durations (tokens --transition-fast / --transition-base exist).

Per the Local Validation Policy, npm run lint (which chains npm run stylelint) must be clean before handback — it clearly wasn't run on the final commit.

B3 (High) — AC #5 break: the editable surface renders report content in the UI locale, the PDF in the report language

ReportWizardPage.tsx:726 passes the chrome t (useTranslation('budget')) to ReportContentEditor, while generatePdfFromContent passes reportT (i18n.getFixedT(reportLanguage, 'budget')) into generateReportPdf. ReportContentEditor then uses that chrome t for content-bearing strings that appear verbatim in the export:

• table headers — sourceReports.table.{vendor,invoiceNumber,date,status,invoiceAmount,allocatedAmount,usage} (lines 151–159, 241–281)
• status badge labels — sources.lines.invoiceStatus.* (lines 32–48)

So with UI = English and Step-4 report language = German, the "preview" shows Vendor / Paid and the exported PDF shows Lieferant / Bezahlt. AC #5 is explicit: "the chrome follows the UI locale and the report content follows the Step-4 report language."

This also defeats the status / statusText split you asked me to look at. The model does the right thing — status is the raw key for the Badge variant, statusText is the report-language label — but ReportContentEditor never reads statusText. It only uses it as a truthiness guard on line 169 and then renders a label from the chrome-locale variant map. The separation is correct in types.ts and discarded at the only consumer.

Fix: pass reportT to ReportContentEditor for content strings (keep chrome t for the editor's own affordances — editable.* labels, reset/aria strings, headings), and build statusBadgeVariants labels from row.statusText rather than re-translating. A test should pin this: render the editor with UI=en, report language=de, assert a German column header and status label.

B4 (High) — --color-refund-text does not exist; refund highlighting is silently dead

ReportContentEditor.tsx lines 177, 185, 262, 272 use style={{ color: row.isRefund ? 'var(--color-refund-text)' : 'inherit' }}. --color-refund-text is defined nowhere in tokens.css (or anywhere in client/src) — the declaration is invalid at computed-value time and refund amounts render in the normal text colour, while the PDF renders them in REFUND_TEXT_COLOR (#991b1b). Inline styles also bypass stylelint's token enforcement entirely, which is why this shipped.

The sibling component in the same directory already establishes the convention — ReportInvoiceList.module.css:119:

.refund {
  background-color: var(--color-status-blocked-bg);
  color: var(--color-status-blocked-text);
}

Fix: add a .refundAmount class to ReportContentEditor.module.css using real tokens and apply it conditionally; remove all four inline style objects. Confirm the token choice with ux-designer.

B5 (Medium) — untranslated identifiers leak into a screen-reader label

ReportContentEditor.tsx:200-202 and 218-220 pass field: 'usage' / field: 'attachmentsNote' into sourceReports.editable.resetFieldAriaLabel ("{{field}} auf generierten Text zurücksetzen"). A German user hears "attachmentsNote auf generierten Text zurücksetzen." Use t('sourceReports.table.usage') and t('sourceReports.editable.attachmentsNoteLabel') (both exist in en and de).

---

Non-blocking (address in refinement if you prefer)

1. The editable surface omits the source-info block. buildOverviewContent renders Source / Source type / Reference / Generated-at above the table; ReportContentEditor never renders content.sourceInfo. This directly affects the two-references question: coverLetter.reference and sourceInfo.referenceText are correctly independent in the model, but because sourceInfo is invisible in the "preview", a user who edits the letter's Reference has no way to see that the overview block still carries the original. Recommend rendering sourceInfo read-only above the table so the independence is observable rather than surprising.

2. Override key-space — sound, but give it an owner. Record<string, string> with coverLetter.<field> / row.<invoiceId>.<field> is the right call for now: invoiceId is stable, unknown keys are ignored, and guardedUpdate clears the whole map on any upstream change so stale keys can't accumulate. Two hardening asks before Bank report wizard: AI-generated usage descriptions and cover letter #1901 builds on it: (a) the key strings are literals duplicated across types.ts, applyOverrides.ts, and ReportContentEditor.tsx — export key builders (overrideKey.coverLetter.sender, overrideKey.row(id).usageText) from lib/reportContent/ so there is one owner; (b) document the empty-string semantics, which are currently asymmetric — usageText: overrides[k] || '' keeps a blank cell, attachmentsNote: overrides[k] || null makes the whole column disappear. Also note applyOverrides will resurrect a null baseline recipient/reference if a key for it ever exists; harmless today (the editor only emits keys for rendered fields) but worth an explicit guard once overrides can arrive from elsewhere.

3. Forward note for Bank report wizard: AI-generated usage descriptions and cover letter #1901 (AI generation). The model has no provenance concept — there is baseline and there is "user override", nothing in between, and buildReportContent is a closed pure derivation with no injection seam for externally-supplied text. If AI text is written into overrides, then (a) every AI-filled field shows the "edited" dot and offers "reset to generated text" that resets to the non-AI text, and (b) guardedUpdate discards the AI output on any step 1–4 change with a dialog that says "your edits will be lost." I'd design Bank report wizard: AI-generated usage descriptions and cover letter #1901 as either a third layer (baseline → generated → user) or a generatedText parameter on buildReportContent, and decide it explicitly rather than letting it fall into the overrides map by default.

4. Labels live outside the content model. Table headers, source-info label prefixes, Reference:/Subject: prefixes, the page header/footer, and skip-footnote reasons are re-translated independently by each consumer. The PDF side is correct because it receives reportT; the editor side is B3. The durable fix is to hoist these into ReportContent (e.g. a labels sub-object) so there is exactly one translated string set per report and a second consumer cannot drift. Not required for this PR, but it is the structural reason B3 was possible.

5. buildReportContent calls new Date() twice (line 110 for generatedAtText, line 279–281 for dateLine) inside a module documented as a pure derivation. Injecting the clock would make the model deterministic and would remove the (admittedly tiny) midnight-straddle where the two blocks disagree.

6. Fragile status-cell guard. The header renders {content.isOverview && <th>} but the body renders {content.isOverview && row.status && row.statusText && <td>} (line 169). Any falsy status yields a row with fewer cells than the header. Practically unreachable today, but the guards should match.

7. Mobile cards use dangling <label> elements. ReportContentEditor.tsx lines 241/245/249/254/259/269 (read-only rows) and 281/300 (editable rows) render <label> with no htmlFor and no wrapped control. For read-only rows use <span>; for the editable rows pass label={...} to EditableField, which already renders a proper <label htmlFor> and switches off the redundant aria-label. The UX spec asked specifically for a visible, associated label on mobile.

8. Step5Actions uses a literal ⟳ glyph (lines 65, 75, 108) instead of the shared Spinner used by ReportPdfPreview — the UX spec called for the same Spinner treatment, and the glyph is unlabelled and not aria-hidden. Component Reuse Policy applies.

9. Preview-modal edge cases (low). Closing the modal mid-generation leaves the in-flight blob URL alive on modalPreviewUrlRef until the next preview or unmount (not a true leak — unmount revokes — just delayed), and onClose does not reset activeAction, so all action buttons stay disabled until the orphaned generation settles.

10. Test gaps matching the above. No test pins the editor's report-language (B3), no test asserts refund styling (B4), and EditableField.test.tsx:157 asserts only that .editedDot is in the DOM, never that it is visible — which is why B1's permanent opacity: 0 passed 407 green tests. The first two are cheap to add; the third is a genuine jsdom limitation, so the E2E reportWizardEditableContent.spec.ts is the right place for a visible-indicator assertion.

---

Summary

Content model, override application, PDF-builder purity, and the real-render test suite are all approved as designed — this is a good foundation for #1901. Blocking on B1–B5: red CI, a CSS-Modules selector bug that voids the approved visual spec and the edited-state indicator, an undefined design token, and an AC #5 locale break that also strands the status/statusText design. B1 and B2 are one fix; B3 and B4 are each a handful of lines.

[steilerDev]

[ux-designer] Design review against my visual spec on issue #1900 (comment link).

Verdict: CHANGES_REQUIRED (Critical/High — two confirmed rendering bugs make core spec'd features non-functional in the real app, not just style nits)

I read the full diff, client/src/styles/tokens.css, shared.module.css, Modal.tsx, Spinner.tsx, and cross-checked against jest.config.ts and webpack.config.cjs to understand why the test suite didn't catch these. Details below.

---

Critical: EditableField's entire visual cascade is dead code in the real app

EditableField.tsx applies the field's styling via className={sharedStyles.input} / sharedStyles.textarea (the actual class from shared.module.css), then EditableField.module.css tries to layer the at-rest tint / hover / focus-split / edited-dot / dense table padding on top via:

.container :global(.input),
.container :global(.textarea) { background-color: var(--color-bg-tertiary); ... }

:global(.input) matches a literal DOM class named input. But shared.module.css is itself a CSS Module — webpack.config.cjs hashes every class in every .module.css file (localIdentName: '[local]_[hash:base64:5]' in production, '[name]__[local]--[hash:base64:5]' in dev). So sharedStyles.input resolves to something like input_a1b2c, never the literal string "input". The :global(.input) selector can never match that class in a real build.

Practical effect, verified by reading every rule in the file: none of the following ever apply, in any environment except tests:

• at-rest tinted background / transparent border (item 2 of my spec)
• hover fill
• the subtle/strong focus box-shadow split between table cells and letter fields
• dense table-cell padding (--spacing-1 --spacing-2) — table inputs get the full .input padding instead
• the edited-dot indicator itself — its only trigger is .fieldWrapper :global(.input):not(:disabled) ~ .editedDot { opacity: 1; }. Since that selector never matches, the dot's opacity is permanently 0. Item 3 of my spec ("small dot… the sighted-user signal that a field was edited") is completely invisible in production, even though the <div className={styles.editedDot}> element is correctly present in the DOM when isEdited — it just never becomes visible.

Screen-reader users are unaffected (the aria-describedby/aria-label edited-suffix logic is pure JS/props, untouched by CSS), but every sighted user loses the entire visual language this component exists to provide, and the field renders as a plain, undifferentiated shared.module.css input sitting in a dense table row — exactly the "noisy bordered box in every cell" outcome my spec explicitly asked to avoid.

Why the tests pass anyway: jest.config.ts maps .module.css to identity-obj-proxy, which resolves sharedStyles.input to the literal string "input" in JSDOM — so :global(.input) does match in the test environment. This is a real webpack-vs-jest divergence, not a flaky test; EditableField.test.tsx's assertions (className composition, dot presence in DOM) are all correct, they just can't detect that the selector strategy itself is unusable outside Jest.

Fix: use composes instead of :global(), e.g.:

.input {
  composes: input from '../../styles/shared.module.css';
  background-color: var(--color-bg-tertiary);
  ...
}

then apply the local styles.input/styles.textarea class from EditableField.tsx (composition merges the real hashed class list onto the element, unlike the :global() string-match approach). The PR's own ReportContentEditor.module.css already does this correctly for Badge (composes: badge from '../Badge/Badge.module.css') — that's the pattern to copy here. If plain composes: hit a real blocker earlier in this branch's history, that needs to be root-caused and fixed properly — deleting it and hoping :global() would bridge the gap was the wrong fix.

Critical: PDF preview modal never becomes wide

Spec asked for a wide className override on Modal (max-width: 50rem) so the PDF is legible instead of cramped. The implementation defines .previewModalContent { max-width: 50rem; } (ReportWizardPage.module.css) but never passes it as Modal's className prop — it's applied to an inner <div> wrapping the body content instead:

<Modal title={...} onClose={...}>
  <div className={styles.previewModalContent}>...</div>
  ...
</Modal>

Modal's outer dialog width comes from shared.module.css's .modalContent { max-width: 28rem; } (448px), which is never overridden. An inner div's max-width: 50rem can't widen a narrower ancestor. Net effect: the PDF preview renders inside a 448px-wide dialog on every viewport, not the spec'd 50rem — on desktop this is a real, visible regression (an A4-proportioned PDF squeezed into a phone-width dialog). Fix: <Modal className={styles.previewModalContent} ...>.

---

Medium (non-blocking on their own, but fix alongside the above)

1. Discard-confirm modal button order is reversed vs. the mandated AutoItemizePage precedent. My spec said reuse that pattern verbatim: btnPrimary "Discard Changes" first, btnSecondary "Keep Editing" second (confirmed in AutoItemizePage.tsx lines 866–874). The PR renders btnSecondary "Keep Editing" first, btnPrimary "Discard and Continue" second — the two actions are swapped.

2. Step5Actions per-action loading state isn't the shared Spinner. My spec said "same visual treatment ReportPdfPreview's Spinner already uses" — ReportPdfPreview.tsx already imports and uses <Spinner size="md" color="muted" label={...} />. Step5Actions.tsx instead renders a static <span>⟳ </span> Unicode glyph with no aria-hidden, no animation, and no reduced-motion guard — and since it sits inside the <button> before the label text, it becomes part of the button's accessible name (e.g. "⟳ Preview PDF"), which a screen reader may announce oddly. Swap for <Spinner size="sm" color="muted" /> wrapped so it doesn't pollute the button's accessible name (e.g. aria-hidden on a wrapper, or rely on Spinner's own role="img" aria-label).

3. var(--color-refund-text) doesn't exist anywhere in tokens.css (confirmed via grep — this PR doesn't touch tokens.css either, so it was never added). ReportContentEditor.tsx uses it in four places (style={{ color: row.isRefund ? 'var(--color-refund-text)' : 'inherit' }}) to distinguish refund/negative rows. An undefined custom property makes the color declaration invalid, so it silently falls back to the inherited/default text color — the refund-row color accent never renders (the literal "(refund)" text suffix still does, so the "not by color alone" principle isn't violated, just the intended color cue is missing). Use var(--color-danger-text-on-light) — the established token for this exact "negative amount, not a badge" case (see Issue Deposit refunds with negative claim adjustments #1876 precedent: negative deposit-refund amounts use this token, not a bespoke one).

4. Hardcoded transition/spacing values in EditableField.module.css instead of tokens: transition: background-color 0.2s, border-color 0.2s (nearest token is var(--transition-normal), 0.15s — 0.2s matches nothing in tokens.css), .resetButton's transition: color 0.1s (should be var(--transition-fast), which is defined as exactly 0.1s ease), and .resetButton's padding: 10px; margin: -10px; (should be var(--spacing-2-5), which is exactly 0.625rem/10px). min-width/height: 44px is fine as a literal — it's a fixed WCAG target size, not a design-scale multiple. These are moot until finding EPIC-01: Authentication & User Management #1 is fixed (the whole block is currently dead), but fix them in the same pass.

Low / informational

• PDF preview modal has no footer prop, so there's no explicit "Close" button as my spec described — only the header's × (which is properly labelled and keyboard-accessible via Modal's existing focus trap/Escape handling). Functionally fine, just a spec deviation; not blocking.

---

What's implemented correctly

• Label association modes: EditableField.tsx correctly implements both modes from my spec — real <label htmlFor> + aria-describedby visually-hidden edited-hint for letter-block/mobile-card fields, vs. composed aria-label (base + editedSuffix) for dense desktop table cells. Verified against EditableField.test.tsx's dedicated test blocks for both modes — this is the trickiest a11y requirement in the spec and it's done right.
• Focus box-shadow-only (never outline: 2px solid): the intended rule is written correctly (outline: none + box-shadow), and — despite finding EPIC-01: Authentication & User Management #1 — the fallback base .input:focus-visible/.textarea:focus-visible rules already in shared.module.css are themselves box-shadow-only, so focus rings still render correctly today; you just lose the intended subtle/strong split between table cells and letter fields (both currently get --shadow-focus-subtle via the fallback).
• Read-only amount cells: correctly plain <td> with no wrapping control, matching the spec's "no aria-readonly needed since there's no control" reasoning.
• Responsive table/mobile-card split: reuses the 767px breakpoint and visible-label mobile card rows exactly as spec'd.
• Step5Actions button order: Preview PDF is correctly the leftmost/first button, btnSecondary, with Download/Mark Claimed/Finish/Paperless preserving their prior order after it.
• Dark mode: every color in ReportContentEditor.module.css routes through Layer 2 semantic tokens already flipped in [data-theme='dark'] — no issues found there.
• Composition pattern reference: ReportContentEditor.module.css's own Badge classes (composes: badge from '../Badge/Badge.module.css') show the correct cross-module composition technique already exists in this exact PR — it just wasn't applied to EditableField.

Please fix the two Critical items (composes/:global() selector mismatch, and the missing Modal className override) plus the Medium items, then re-request review.

[steilerDev]

[product-owner] Review of PR #1909 against story #1900 acceptance criteria.

Verdict: COMMENT — MUST FIX before merge

No functional acceptance criterion is unmet. The feature genuinely works end to end: Step 5 is an editable HTML surface, edits are overrides on a live baseline, every Step 1–4 change regenerates and clears with a correctly-gated confirmation, and all three export paths generate on demand from the edited content. The gaps below are display/formatting, token-adherence, and translation-correctness — per the verdict matrix those are --comment + MUST FIX, not --request-changes.

Note that Static Analysis is currently red (Stylelint, 13 errors), so this cannot merge regardless of my verdict. Items 1–3 below are exactly those errors.

---

AC Coverage

AC	Criterion	Status	Evidence
1.1	Step 5 shows full report as editable HTML, not a PDF frame	✅	ReportContentEditor.tsx renders cover letter + table + summary + footnotes; E2E Sc.1 asserts iframe count is 0
1.2	One row per included invoice with all report columns	✅	Table + mobile cards render vendor, invoice no., date, status (overview only), amounts, usage, attachments note
1.3	Step-3 exclusions absent from editable content	✅	baselineContent built from applyLineExclusions(report, excludedLineIds) + includedInvoiceIds filter
1.4	Cover letter on → 5 separately editable fields	✅	sender, recipient, reference, subject, body as EditableFields; reference/recipient omitted entirely when absent
1.5	Cover letter off → no fields, none exported	✅	coverLetter: null → editor renders nothing, merge.ts guards on if (reportContent.coverLetter)
1.6	Keyboard reachable, accessible label, visible focus, all viewports	✅	Real <input>/<textarea> in natural tab order; <label htmlFor> for letter fields, composed aria-label for table cells; focus ring survives via shared.module.css .input:focus-visible; E2E Sc.13 asserts box-shadow ring, Sc.11 mobile
1.7	Design tokens only, no hardcoded values, dark mode	❌	Stylelint red — font-weight: 500 hardcoded (item 2). See also item 1
2.1	All wording fields freely editable	✅	usage text, attachments note, all 5 letter blocks
2.2	Amount cells read-only, visually + programmatically	✅	Rendered as plain <td> text — no form control exists at all, so nothing to focus or announce. ReportContentEditor.test.tsx:340 asserts queryByDisplayValue finds no input for the amounts
2.3	Totals/subtotals read-only, derived from Step-3 state	✅	summaryRows plain <td>; recomputed in buildReportContent from included set
2.4	No user input path can alter an exported number	✅	applyOverrides uses a hardcoded 7-key allowlist (coverLetter.{sender,recipient,reference,subject,body}, row.<id>.{usageText,attachmentsNote}); unknown keys silently ignored; summaryRows/footnotes never written. overviewPdf/coverLetterPdf now consume ReportContent only and no longer import SourceReportResponse
3.1	Baseline generated in the Step-4 report language	✅	reportT = i18n.getFixedT(reportLanguage,'budget') + reportFormatters threaded into buildReportContent
3.2	Step 1–4 change regenerates baseline and clears edits	✅	baselineContent useMemo keyed on report/useCase/exclusions/reportT/formatters/includeCoverLetter/household; confirm handler calls setOverrides({})
3.3	Confirmation warning when edits exist, cancellable	✅	guardedUpdate wraps all Step 1–4 mutations: use case, source, invoice toggle, toggle-all, line toggle, report language, attach documents, include cover letter. "Keep Editing" clears pendingChangeRef without applying
3.4	No warning when there are no edits	✅	isDirty = Object.keys(overrides).length > 0; else applyChange() immediately. E2E Sc.5
3.5	After confirm, content matches fresh baseline, no residue	✅	E2E Sc.4
3.6	Untouched fields keep tracking the baseline (not frozen)	✅	effectiveContent = applyOverrides(baselineContent, overrides) recomputed each render — untouched keys are simply absent from the map
4.1	No continuous background regeneration, no live pane	✅	Debounced regeneration effect removed; hasBlob gating dropped from Step5Actions. E2E Sc.1
4.2	"Preview PDF" generates from current edited content	✅	New leftmost btnSecondary → handlePreviewPdf → generatePdfFromContent() → modal
4.3	Download reflects edits	✅	Same single generatePdfFromContent() path; proven at unit level (see 4.6 note)
4.4	Paperless upload reflects edits	✅	Same path; E2E Sc.9
4.5	Mark-claimed PDF reflects edits; #1891 warning unchanged	✅ (vacuous — accepted, see below)	No PDF is generated by claiming; excluded-lines warning block preserved verbatim with role="alert". E2E Sc.10
4.6	Preview asserts rendered content, not just a blob: src	⚠️ Deviation — accepted with justification	See below
4.7	Generation failure surfaced, edited content preserved	✅	Preview → FormError in modal; download → showToast('error', downloadFailed); Paperless → toast. overrides untouched on every failure path
5.1	Every new string from t(), resolves in en + de	❌	21 new keys added with exact en/de parity, but resetFieldAriaLabel is interpolated with raw English literals (item 4)
5.2	Chrome follows UI locale, content follows report language	✅	Editor labels/headers use t; baseline content built with reportT/reportFormatters. Correct split, verified in realRender.test.ts for both en and de

---

Judgment items — rulings

(a) Signature derived from Sender's first line — ACCEPT.
sender.split('\n')[0]?.trim() ?? '', computed in buildReportContent and recomputed by applyOverrides whenever sender is overridden, rendered only when non-empty. This is the right call: the settled decision named exactly five editable fields, a sixth would exceed agreed scope, and deriving it means the signature can never drift from the sender block. Edit Sender to "Jane Doe\n99 New Address" and the signature correctly becomes "Jane Doe". Covered by realRender.test.ts:796.

(b) Mark-claimed generates no PDF — ACCEPT as vacuously satisfied.
The intent behind AC 4.5 is "no export path can bypass the user's edits." Mark-claimed is a state mutation, not an export — it did not produce or persist a PDF before this story either, and adding one would land squarely in the story's own "Out of scope" (persisting reports server-side). Since no PDF is produced, none can fail to reflect edits. The half of the AC that is observable — mark-claimed behaviour unchanged, including the #1891 excluded-lines warning — is verifiably intact.
Condition: this must be recorded as a deliberate interpretation, not left as a silently-green checkbox, so a future reader doesn't conclude the criterion was dropped.

(c) Per-field reset + edited-dot — ACCEPT.
Good affordance and the right answer to "what makes the page-level discard warning tolerable." Dot is aria-hidden with a separate accessible signal (aria-describedby hint in labelled mode, editedSuffix appended to aria-label in dense mode); reset button now meets 44×44. Two nits under Should-fix.

(d) AC 4.6 preview assertion — ACCEPT the deviation, but it must be documented.
The AC explicitly says the assertion must be that the frame renders, "not merely that a blob: URL was assigned." What openPdfPreviewModal() actually asserts is: iframe visible + src starts with blob: + the served CSP frame-src contains 'self' and blob: + zero CSP violation console messages. That is not a rendered-content check.

I'm accepting it because the POM documents both superseded attempts with CI run IDs, and the rejections are correct: Playwright's headless Chromium shell has no PDF viewer plugin so the iframe blanks without navigating (run 30530648400), and an in-page fetch(blobSrc) is blocked by connect-src 'self' — loosening which would weaken production CSP for no product reason (run 30531695763). The substituted frame-src header assertion is a genuine #1891 regression guard: it fails against the pre-fix frameSrc: ["'self'"] config, which is the actual regression class the AC was written to prevent.

Same reasoning for AC 4.3: E2E Sc.8 asserts only filename and file size, never searching the edited string in the bytes (no PDF text-extraction library in the E2E deps). The capability is genuinely proven, one layer down, in realRender.test.ts against real pdfmake/pdf-lib with real locale bundles — asserting the exact table cell position, and that the discarded baseline string is absent from the document entirely. That delegation is acceptable; assuming E2E covered it would not have been.

---

MUST FIX before merge

1. :global(.input) / :global(.textarea) in EditableField.module.css is dead CSS — the entire specified field treatment never applies.
client/webpack.config.cjs sets localIdentName: '[local]_[hash:base64:5]', so sharedStyles.input renders as input_aB3xY. :global(.input) compiles to a literal .input selector, which matches nothing — and there is no global (non-module) .input/.textarea rule anywhere in client/src. This is also 11 of the 13 Stylelint errors (selector-pseudo-class-no-unknown), and EditableField is the only file in the codebase using :global(.

Silently lost: the at-rest --color-bg-tertiary tint (the only idle signal that a table cell is editable, per the UX spec), border: 1px solid transparent, the hover step, the --shadow-focus-subtle/--shadow-focus split, width: 100%; box-sizing: border-box, and the dense table-cell padding. Table-cell inputs therefore fall back to the standalone .input chrome — the heavy bordered box at every cell that the UX spec explicitly rejected as noisy — and won't fill their cell.

Not a functional break (fields stay editable, labelled, and keep a visible focus ring from shared.module.css), but the shipped surface is not the approved design. Fix by applying a local class that does composes: input from '../../styles/shared.module.css'; and targeting that local class, rather than :global().

2. font-weight: 500 (EditableField.module.css:13) — direct AC 1.7 violation, flagged by declaration-property-value-disallowed-list. Use the font-weight token.

3. .visuallyHidden duplicates the existing .srOnly utility and uses the deprecated clip property (property-no-deprecated, line 126). shared.module.css:455 already provides .srOnly with the modern clip-path: inset(50%). Per the Component Reuse Policy this should reuse sharedStyles.srOnly, which resolves the Stylelint error at the same time.

4. resetFieldAriaLabel is interpolated with raw English identifiers — AC 5.1 violation.
ReportContentEditor.tsx passes { field: 'usage' } and { field: 'attachmentsNote' } at four call sites (two desktop, two mobile). In German a screen reader announces "attachmentsNote auf generierten Text zurücksetzen" — an untranslated camelCase identifier read aloud. The five cover-letter fields do this correctly by passing translated labels. Pass t('sourceReports.table.usage') and t('sourceReports.editable.attachmentsNoteLabel') instead.

Worth noting this class of bug is invisible to the current unit tests: ReportContentEditor.test.tsx uses a key-echoing t mock, which happily accepts a raw literal as an interpolation value.

---

In-scope findings #1904–#1908 — all genuinely fixed

Finding	Fix verified in diff
#1904 mobile viewport shows no invoice content	✅ ReportContentEditor.tsx now renders the .mobileCardList / .mobileCard / .mobileCardRow tree with visible labels per row, alongside the desktop table
#1905 reset button 24×24 below WCAG 2.5.5	✅ .resetButton now min-width: 44px; min-height: 44px with padding: 10px; margin: -10px to preserve layout. E2E Sc.12 measures boundingBox() ≥44
#1906 silent download failure + missing i18n keys	✅ Both parts. downloadFailed and loadingPreview added to en and de; handleDownload now routes failure through showToast('error', …), matching the Paperless pattern, so it is visible without the modal
#1907 report-language change bypasses discard guard	✅ onReportLanguageChange={(lang) => guardedUpdate(() => setReportLanguageOverride(lang))} — now consistent with the other two Step-4 controls. E2E Sc.15
#1908 mobile cards duplicated on desktop	✅ Base rule .mobileCardList { display: none; } added outside the media query (line 191), flipped to flex inside @media (max-width: 767px). E2E Sc.1b asserts not visible on desktop

---

Should fix (non-blocking)

5. Reset icon is the Material "close" X, not the undo arrow the UX spec prescribed. An X reads as "clear this field's contents"; the action is "restore the generated text." The aria-label/title disambiguate it for assistive tech, but not visually. ux-designer call.
6. Step5Actions uses a literal ⟳ glyph in a bare <span> rather than the shared Spinner the UX spec called for, and it isn't aria-hidden — screen readers will announce the character.
7. realRender.test.ts leaked-key guard is too narrow: /^sourceReports\.[a-zA-Z.]+$/ misses sources.lines.invoiceStatus.*, which is how status labels resolve. A missing status translation would leak the raw key into the PDF undetected.
8. expect(total.amountText).not.toContain('999999') (realRender.test.ts:367) is vacuous — amountText is formatted currency (€999,999.00), so the bare digit run can never appear. The strong version at line 296 already carries the signal; drop or strengthen this one.
9. Story note now stale: the included total no longer "comes from merge.ts" — that computation was deleted there and moved into buildReportContent.ts, where it feeds both the total row and the cover-letter body interpolation. Better design (the two can no longer drift), but the note should be corrected so the next story doesn't look in the wrong place.
10. Mobile-card visible <label> elements have no htmlFor. The inputs are labelled via aria-label, so AC 1.6 is met, but the visible label isn't programmatically associated with its field.

---

Once items 1–4 are addressed and Static Analysis is green, this has my approval — the content-model architecture is the right shape, and realRender.test.ts (real pdfmake, real pdf-lib, real en/de bundles, nothing mocked but fetch) is the strongest evidence in the PR that edits reach the exported document.

[steilerDev]

[product-owner] Round-2 review of PR #1909 (story #1900 — editable HTML report preview)

Verdict: APPROVED

All four MUST FIX items from my round-1 --comment verdict are resolved. Verified on the branch head, not taken on report.

MUST FIX confirmation

1. :global() dead CSS → local classes — RESOLVED.
client/src/components/EditableField/EditableField.module.css no longer contains any :global() selector (grep clean across EditableField.module.css and ReportContentEditor.module.css). .field and .fieldTextarea now composes: input / composes: textarea from ../../styles/shared.module.css, and EditableField.tsx:44 selects between them (as === 'textarea' ? styles.fieldTextarea : styles.field), so the rules are actually reachable from the rendered element. Hover/focus/box-shadow states hang off the local classes and are live.

2. Raw font-weight: 500 → token — RESOLVED.
.container label uses var(--font-weight-medium). No raw numeric font-weight remains in either stylesheet.

3. .visuallyHidden duplicate → deleted — RESOLVED.
No visuallyHidden identifier anywhere under client/src/. The edited-state hint span now uses sharedStyles.srOnly (EditableField.tsx:84), which is the single canonical definition (shared.module.css:455). One implementation, no drift.

4. resetFieldAriaLabel raw identifiers → translated labels — RESOLVED.
All 9 call sites in ReportContentEditor.tsx (lines 53, 69, 93, 108, 122, 206, 226, 301, 320) interpolate a t() result into field, never a code identifier. Key parity verified directly in both locales:

• resetFieldAriaLabel — EN Reset {{field}} to generated text / DE {{field}} auf generierten Text zurücksetzen
• every interpolated label resolves in en/budget.json and de/budget.json: senderLabel, recipientLabel, referenceLabel, subjectLabel, bodyLabel, attachmentsNoteLabel, sourceReports.table.usage.

The German announcement reads naturally because the DE string puts {{field}} in first position — e.g. "Verwendung auf generierten Text zurücksetzen", not a calqued English word order. Good catch by the translator; that ordering is the reason this fix actually lands for DE users rather than just passing a lint check.

QA's accessible-name regression tests (ReportContentEditor.test.tsx:406-460) pin the behaviour. Note for the record: they run under a key-echoing t mock, so they assert field carries a translation-call result rather than asserting rendered German. That is the right invariant for this defect class (the bug was a raw identifier reaching the accessible name), and I verified the actual EN/DE resolution by hand above — but the mock alone would not have caught a missing DE key. Not a change request.

Additional changes since round 1 — reviewed, no objection

• Report labels moved into ReportContent.labels (built with reportT in buildReportContent.ts:306-319) and consumed by both ReportContentEditor.tsx and reportPdf/overviewPdf.ts. This is the correct fix for the preview/export locale mismatch the architect flagged: one source, so the preview is genuinely WYSIWYG against the PDF rather than merely resembling it. This strengthens AC group 4.
• Read-only sourceInfoBlock added to the preview — correctly non-editable (source, source type, reference, generated-at are provenance, not authored content).
• Status Badge uses report-language statusText — consistent with the labels change.

Static Analysis: npx stylelint "client/src/**/*.css" exits 0 with no output. Repo-wide clean.

Judgment call: mixed-language mobile cards — ACCEPTED, no change required

QA flagged that a mobile card can show report-language captions (content.labels.vendor, invoiceNumber, date, …) alongside UI-language editable-field labels (t('sourceReports.table.usage'), t('...attachmentsNoteLabel')) when report language ≠ UI locale.

I accept this as designed. The two label sets are different kinds of text and correctly follow different locales:

• Captions are artifact content. They are the literal strings that appear in the exported PDF. Rendering them in the report language is precisely what makes the preview faithful — and is the property this PR just added to fix the export mismatch.
• Editable-field labels are edit affordances. They are chrome that never reaches the PDF. They must follow the UI locale, or a user who selects a report language they don't read loses the ability to operate the editor.

Forcing consistency means choosing one of two worse outcomes: UI-language captions (breaks WYSIWYG and reintroduces the exact mismatch the architect flagged), or report-language field labels (renders the editor unusable in an unfamiliar language). The cover-letter card already carries this property by design and I accepted it in round 1; extending the same rule to mobile cards is consistent, not a new deviation. No acceptance criterion on #1900 requires single-language cards.

One follow-up I am recording rather than blocking on: report-language content is rendered without a lang attribute, so a screen reader announces it using the page locale's pronunciation rules. This is not specific to mobile cards — it applies to the entire preview, including the table and cover letter, and predates this PR's mixed-label question. I will file it as a separate accessibility story against the report wizard. It does not gate #1900.

Acceptance criteria

All five AC groups on #1900 confirmed met, including the round-1 judgment rulings I already recorded (signature derived from sender: accepted; mark-claimed generates no PDF: accepted as vacuous; per-field reset: accepted; AC 4.6 rendered-preview assertion: accepted as a documented deviation, since Playwright headless has no PDF viewer plugin and the E2E asserts the CSP frame-src contract instead).

Ready to merge from a product standpoint.

[steilerDev]

[ux-designer]

Round 2 — re-review of both Critical findings + Medium findings from my prior review (issuecomment-5143143659)

Critical 1 — dead CSS via :global() — FIXED

EditableField.module.css no longer targets :global(.input)/:global(.textarea). It now defines local .field/.fieldTextarea classes that composes: input/textarea from '../../styles/shared.module.css' — the same technique ReportContentEditor.module.css already used correctly for its Badge classes in this same PR. EditableField.tsx applies fieldClassName (the local composed class) directly, so the DOM now carries the real hashed input/textarea classes plus the local hashed field/fieldTextarea class in the real webpack build — not just in Jest's identity-obj-proxy shim.

Verified the full spec'd treatment is present and locally scoped (no more :global() anywhere in the file):

• At-rest: background-color: var(--color-bg-tertiary), border: 1px solid transparent
• Hover: background-color: var(--color-bg-secondary)
• Focus: border-color: var(--color-primary) + outline: none, with the subtle/strong split preserved (--shadow-focus-subtle for .field, --shadow-focus for .fieldTextarea)
• .editedDot is now unconditionally opacity: 1 — correct, since EditableField.tsx already gates its render entirely on isEdited (line 80 {isEdited && (...)}), so there's no need for a second CSS-side trigger

Critical 2 — modal width — FIXED

ReportWizardPage.tsx line 881 now passes className={styles.previewModalContent} directly on <Modal>, and the inner wrapping <div> is gone. Confirmed in Modal.tsx line 76: className={[sharedStyles.modalContent, styles.content, className].filter(Boolean).join(' ')} — the passed-in className merges onto the same dialog element that carries .modalContent, so .previewModalContent { max-width: 50rem; } now correctly overrides (later in cascade + more specific via CSS Modules hashing doesn't matter here since it's a distinct property override, not conflicting specificity) the base 28rem. Verified no inner div remains.

Medium findings — all fixed and verified

1. Discard button order — ReportWizardPage.tsx lines 784–804: btnPrimary "Discard Changes" now renders first, btnSecondary "Keep Editing" second. Matches AutoItemizePage precedent.
2. Spinner — Step5Actions.tsx all three call sites (preview, download, paperless) now render <span aria-hidden="true"><Spinner size="sm" color="muted" /></span> ahead of the label text. size="sm"/color="muted" are valid SpinnerProps values. The aria-hidden wrapper correctly keeps the spinner out of the button's accessible name.
3. Refund token — ReportContentEditor.module.css now defines .refundAmount { color: var(--color-danger-text-on-light); }, a real token (confirmed in tokens.css lines 145/700, flips correctly between light/dark). All 4 inline style={{ color: ... }} usages are gone from ReportContentEditor.tsx — grepped clean.
4. Hardcoded values — EditableField.module.css: transition now uses var(--transition-normal) (field/textarea) and var(--transition-fast) (reset button); .resetButton padding/margin now var(--spacing-2-5) / calc(var(--spacing-2-5) * -1). font-weight: var(--font-weight-medium) on the label. 44px WCAG touch-target literals correctly left as-is. .visuallyHidden is deleted; EditableField.tsx now uses sharedStyles.srOnly from the shared library. Ran npx stylelint "client/src/**/*.css" repo-wide — zero errors/warnings.

New since round 1 — sourceInfoBlock + mobile card label split

Reviewed the new read-only sourceInfoBlock card (ReportContentEditor.tsx lines 136–151, .sourceInfoBlock in the module CSS) — plain semantic-token-only card (--color-bg-primary, --color-border, --color-text-muted), no interactive affordances, no a11y concerns (it's static text, correctly not wrapped in any editable control).

The judgment call — mixed-language mobile cards

Accepted, no change required. This is not a one-off inconsistency — it's the same content-vs-chrome split already established for the cover letter card in this same component (content.coverLetter.sender etc. are report-language values, but their EditableField label props are all t('sourceReports.editable.senderLabel') etc. — UI language). The organizing principle: anything that ends up baked into the exported report artifact (table headers/captions sourced from content.labels.*, cell values, cover letter body) stays in report language for document consistency; anything that is purely on-screen editor chrome not present in the artifact (the EditableField label/ariaLabel/reset-button affordances) stays in UI language so the person editing — who may not read the report language — can operate the controls. Applying this consistently: mobile card captions correctly use content.labels.* (report language, since they mirror the printed table headers) while the two editable rows' visible labels correctly use t('sourceReports.table.usage') / t('sourceReports.editable.attachmentsNoteLabel') (UI language, editor chrome). Recommend documenting this as an explicit convention note near ReportContentEditor for future contributors, but that's a low-priority follow-up, not a blocker.

---

Verdict: APPROVED

Both Critical findings are genuinely fixed and verified against the actual composed CSS output (not just Jest's masked behavior) and against Modal.tsx's className-merge logic. All Medium findings are resolved. Stylelint is clean repo-wide. No new Critical/High findings. The E2E computed-style regression guard (reportWizardEditableContent.spec.ts, ~line 1131) closing the Jest-vs-webpack CSS Modules gap is a good structural fix — recommend keeping that pattern in mind for any future composes-based component.

(Per team convention, I cannot use gh pr review --approve on this PR — GitHub blocks self-review approvals at the gh auth-identity level. Posting this as a comment with the explicit verdict line above.)

[steilerDev]

[product-architect] Round-2 architecture / code-quality review of PR #1909 (story #1900).

Verdict: APPROVE (posted as a comment — gh pr review --approve is rejected on a self-authored PR)

All five blockers from round 1 are genuinely fixed, and I verified them against the working tree rather than the stale PR diff. One Medium finding below on the mixed-label question, which I am ruling on rather than leaving open — it is a two-line change and should ride in before commit, not into refinement.

---

Blocker verification

B1 — dead CSS. Fixed, correctly. EditableField.module.css is now built on local composed classes: .field / .fieldTextarea composes input / textarea from shared.module.css, and every state rule (:hover, :focus, the --shadow-focus-subtle / --shadow-focus split) is a local selector. EditableField.tsx:44 applies styles.fieldTextarea / styles.field. All eleven :global() selectors are gone. .editedDot is now unconditional opacity: 1 — correct, since the component already gates rendering on isEdited (EditableField.tsx:80), so the sibling selector was redundant by construction, exactly as flagged.

B2 — stylelint. Fixed. npx stylelint "client/src/**/*.css" exits 0 with no output, repo-wide. font-weight: var(--font-weight-medium), sharedStyles.srOnly reused instead of the hand-rolled .visuallyHidden with deprecated clip, and the transition/spacing literals are now var(--transition-fast) / var(--spacing-2-5). Keeping the bare 44px on min-width/min-height is the right call — that is a WCAG 2.5.5 touch-target constant, not a spacing-scale value, and there is no token for it.

B3 — the i18n contract break. Fixed structurally, which is better than the fix I asked for. Rather than threading reportT into the editor, ReportContentLabels (12 strings) now lives on ReportContent and is built with reportT in buildReportContent.ts:306-318. Both consumers read the same object: ReportContentEditor.tsx:159-168 for the table headers and overviewPdf.ts:53-66 for the pdfmake tableHeader cells. That is the "single translated string set per report" fix from round-1 nit 4, and it closes the drift channel rather than patching this instance of it. The status/statusText split is now actually honoured — Badge takes label: row.statusText with a translation-free STATUS_BADGE_CLASSNAME map (ReportContentEditor.tsx:23-28, 179-187), so the raw key drives the variant and the report-language string drives the label, as the model always intended.

B4 — invalid token. Fixed. .refundAmount { color: var(--color-danger-text-on-light) }, and that token genuinely exists in both themes (tokens.css:145 light → --color-red-700, :700 dark → --color-red-300). Zero style={{ remain in the editor, so stylelint's token enforcement now actually covers this path.

B5 — untranslated identifiers in a11y labels. Fixed at all four sites (ReportContentEditor.tsx:207, 227, 302, 321) — resetFieldAriaLabel now interpolates a translated field name.

Nits. overrideKeys.ts gives the key-space one owner, consumed by both applyOverrides.ts and the editor. buildReportContent has a single new Date() (line 110), removing the midnight-straddle. sourceInfo now renders read-only above the table (ReportContentEditor.tsx:136-151), so the two-references independence is observable. The status-cell guard is now symmetric via row.statusText != null.

Tests. 16 suites / 360 tests green locally across reportContent, reportPdf, ReportContentEditor, and ReportWizardPage. The regression guards are well-aimed — renders the desktop table headers from content.labels.*, not a chrome t() echo and the statusText badge test would both have caught B3, and applies the refundAmount CSS class (not an inline style) pins B4's shape rather than just its effect.

Special credit for the E2E guard at reportWizardEditableContent.spec.ts:1136-1151. It resolves --color-bg-tertiary through a probe element and compares it to the field's computed background-color, so it fails against a dead-CSS build and passes against a live one. That is precisely the class of bug jsdom cannot see, and it is the first test in this repo that would have caught B1. The exact: true fix on getByLabel (ReportWizardPage.ts:818, 889) is the correct root-cause fix for the shard-2 strict-mode failure — substring matching was colliding with the reset-button aria-labels.

---

The mixed-label ruling: switch both mobile editable labels to content.labels

The rule as stated — exported-artifact content = report language; edit affordances = UI language — is the right rule. I am ruling against its application here, because the discriminator is being read as "is this next to an editable control?" when it should be "does this exact string appear in the exported PDF?"

Applying that sharper test to the two labels in question:

• usage is exported. overviewPdf.ts:66 pushes { text: reportContent.labels.usage, style: 'tableHeader' } into the PDF table. So the Usage caption is report-language in the PDF and report-language in the desktop table header (ReportContentEditor.tsx:165), but UI-language in the mobile card (:295). Same semantic label, same field, three renderings, and the language flips at a responsive breakpoint. That is harder to defend than the same-card mixing QA flagged — a user resizing the window watches the label change language.
• attachmentsNote is not exported (there is no attachments column in the PDF — overviewPdf.ts:51-67), so UI language is defensible on its own merits. But its desktop header already renders from content.labels.attachmentsNote (:167), so leaving mobile on chrome t still produces a desktop/mobile split for no reason a user could infer.

The clincher is that the cover-letter card — cited as the precedent for keeping these on chrome t — is not actually analogous. coverLetterPdf.ts renders sender, recipient, dateLine, body, and signature with no label prefix at all. senderLabel / recipientLabel / bodyLabel are UI-language because they are never exported, not because they sit next to an editable control. So the cover-letter card is already obeying the export test, and it should stay exactly as it is. The mobile card is the only place that breaks it.

Concretely, in ReportContentEditor.tsx:

• :295 label={t('sourceReports.table.usage')} → label={content.labels.usage}
• :314 label={t('sourceReports.editable.attachmentsNoteLabel')} → label={content.labels.attachmentsNote}

Deliberately leave the ariaLabel and resetAriaLabel props on chrome t. Those are whole affordance sentences ("Reset Usage to generated text"), and splicing a report-language noun into a UI-language sentence would be worse than either consistent choice. The resulting story is clean and statable in one line: visible captions of exported data follow the report language; screen-reader affordance sentences are wholly UI language. That rule also pre-decides the equivalent questions in #1901.

Cost is two lines plus a test update: ReportContentEditor.test.tsx:731-733 currently pins the present behaviour (getByLabelText('sourceReports.table.usage') and expect(card.queryByText(LABELS.usage)).not.toBeInTheDocument()), so it inverts to assert the content.labels source instead — which makes it a guard rather than a snapshot of an accident. The E2E getByLabel('Usage', { exact: true }) at ReportWizardPage.ts:889 keeps passing as long as that scenario's report language is English; worth a comment noting the coupling.

This is Medium, not blocking — the exported PDF is correct either way, since these labels flow from buildReportContent, not from the editor. It only surfaces when report language ≠ UI locale on a narrow viewport. But the tree is uncommitted and the change is trivial, so it should go in now rather than to refinement.

---

Carried forward (unchanged from round 1, still non-blocking)

• Bank report wizard: AI-generated usage descriptions and cover letter #1901 provenance. Still the item I most want decided before AI generation lands: the model has baseline and user override and nothing between, so AI text written into overrides would mark every field "edited", offer a reset to the non-AI text, and be discarded by guardedUpdate under a dialog reading "your edits will be lost." Design it as a third layer or a generatedText parameter on buildReportContent, explicitly.
• Residual label re-translation. overviewPdf.ts:218 (skip-footnote reasons) and merge.ts:112,115 (page header/footer) still re-translate independently. Correct today because both receive reportT, but they are the remaining un-hoisted strings if you want labels to be the whole story.
• Step5Actions ⟳ glyph (lines 65, 75, 108) — still a bare literal rather than the shared Spinner, and not aria-hidden. Component Reuse Policy.

Wiki: ADR-034 and the API Contract need no change — this PR is entirely client-side and introduces no endpoint or schema surface.

[github-actions]

🎉 This PR is included in version 2.13.0-beta.33 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 2.13.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀