fix(reports): pageFooter uses injected report-language label instead of ambient locale (#1993)

[steilerDev]

Summary

• Add pageLabel to ReportContentLabels and populate it via reportT in buildReportContent.ts
• Replace t('sourceReports.table.pageLabel') in merge.ts:134 with reportContent.labels.pageLabel so the PDF footer respects the report language, not the UI locale
• Add regression assertion in merge.test.ts that buildPageFooter is called with content.labels.pageLabel
• Update test label helpers in 6 test files to include the new required field

Fixes #1993

Test plan

• Unit tests pass (new regression assertion in merge.test.ts)
• Existing tests in applyAiContent, applyOverrides, overviewPdf, coverLetterPdf, realRender still pass
• Pre-commit hook quality gates pass

🤖 Generated with Claude Code

[steilerDev]

[product-architect] Architecture review of PR #2000 (fix/1993-pagefooter-locale).

The fix itself is the right one — it is byte-for-byte the shape ADR-034 prescribed for this defect. But one ReportContentLabels construction site was missed and CI is red because of it, and the ADR that documents this bug as an open violation was not updated. Both need to land before merge.

VERDICT: CHANGES_REQUIRED

---

CRITICAL 1 — a ReportContentLabels construction site was missed; CI Static Analysis is failing

client/src/components/reports/ReportContentEditor.test.tsx:93 declares const LABELS: ReportContentLabels = { … } with an explicit type annotation, so adding a required field to the interface breaks it. CI confirms:

src/components/reports/ReportContentEditor.test.tsx(93,7): error TS2741:
  Property 'pageLabel' is missing in type '{ vendor: string; … generatedAt: string; }'
  but required in type 'ReportContentLabels'.
Process completed with exit code 2.

(Static Analysis → npm run typecheck, run 30934606820. Note client/tsconfig.json has "include": ["src/**/*.ts", "src/**/*.tsx"], so *.test.tsx is typechecked — the Jest shards can be green while this stays red. This is the recurring "Jest green hides typecheck break" trap: ts-jest does not surface type diagnostics here.)

Required fix. Add the field, but use that file's sentinel convention rather than 'Page'. Its own header comment explains why the values are deliberately REPORT_*_LABEL-shaped: they must be impossible to confuse with the chrome-t mock's echoed dotted keys, so a chrome-t leak into the editor is detectable. Please use:

  generatedAt: 'REPORT_GENERATED_AT_LABEL',
  pageLabel: 'REPORT_PAGE_LABEL',
};

Answer to key question 1 (any other sites?): No — this is the only one. I enumerated every ReportContentLabels / ReportContent['labels'] construction across client/, shared/, and e2e/. The one other candidate, overviewPdf.test.ts:831 makeGermanLabels(), is safe because it spreads ...makeLabels() (already updated by this PR) and only overrides seven fields.

---

HIGH 2 — ADR-034 still documents this bug as an open violation; the wiki must be updated in the same PR

wiki/ADR-034-Client-Side-Report-PDF-Generation.md currently asserts the opposite of what this branch ships, in three places:

1. Line 190 — the **Known open violation.** paragraph, which states merge.ts's footer: "still reads its label from the interface t" and then specifies the fix as "a pageLabel entry on ReportContentLabels". That is precisely what this PR does, so the paragraph is now stale.
2. Line 219 — "merge.ts's page footer is the outstanding exception — see the known open violation above."
3. Deviation Log, row dated 2026-08-04 — "The merge.ts footer violation is a code defect and is NOT fixed by this pass — flagged for a follow-up issue."

Per CLAUDE.md's wiki-ownership rules and the Wiki Update Discipline, a contract page must not be left describing a defect that the same PR closes — a future agent reading line 190 will conclude the bug is still open and either re-fix it or design around it.

Required changes:

• Line 190 — replace the "Known open violation" paragraph with the resolved statement. It should keep the teaching value: both merge.ts's header: (Bug: report PDF running header shows a 'generated at' label with no timestamp on pages 2+ #1938) and its footer: (fix(reports): pageFooter in merge.ts uses ambient locale instead of report language #1993) had the same defect and both now resolve through reportContent.labels.*, and the general rule they instantiate is unchanged — artifact content resolves through reportT/reportFormatters; only edit affordances use the interface t. Two independent instances of the same defect in the same function is worth stating as the reason the rule exists.
• Line 219 — drop the footer from the "still re-translated independently" list; overviewPdf.ts's *N skip-note reasons and coverLetterPdf.ts's prefixes remain, merge.ts's header and footer no longer do.
• Deviation Log — append a new row (do not rewrite the 2026-08-04 row; it was accurate when written) recording that the footer violation was closed by fix(reports): pageFooter in merge.ts uses ambient locale instead of report language #1993 / PR fix(reports): pageFooter uses injected report-language label instead of ambient locale (#1993) #2000 via ReportContentLabels.pageLabel.
• Commit and push the wiki submodule, then bump the submodule ref on this branch (git add wiki) so the PR carries it. The PR's file list currently contains no wiki change.

Worth adding while you are in there (optional but valuable): the grep guard at line 183 could not have caught either #1938 or #1993, because both leaks came through a t that arrives as a function parameter — there is no import, no useTranslation, no Intl. to match. The ADR already says "nothing in the type system distinguishes reportT from the interface t"; it would be stronger to state explicitly that invariant 1 is guarded mechanically only for the import channel, and that the parameter channel has review and per-locale render tests as its only defence. Two escapes in the same function is the evidence for that claim.

---

MEDIUM 3 — the per-locale real-render harness forks the docDefinition and still uses the pre-fix forms (pre-existing, non-blocking)

client/src/lib/reportPdf/realRender.test.ts:139-158 — renderOverviewPdfContent() hand-builds its own pdfmake docDefinition rather than going through generateReportPdf, and its header/footer construction has drifted from production:

      return buildPageHeader(
        header.tableTitle,
        header.sourceName,
        t('sourceReports.table.generatedAt'),   // pre-#1938 bare-key form
      );
    },
    footer: buildPageFooter(t('sourceReports.table.pageLabel')),  // pre-#1993 form

Production merge.ts now passes `${reportContent.labels.generatedAt}: ${reportContent.sourceInfo.generatedAtText}` for the header and reportContent.labels.pageLabel for the footer. The harness's own comment claims the render uses "the production pageMargins/defaultStyle/styles config … never hand-copied" — true for the geometry, but the header/footer are hand-copied and have now drifted twice.

This matters because ADR-034 names "per-locale real-render tests" as one of the three defences against exactly this class of leak, and this harness structurally cannot catch a merge.ts header/footer locale leak — it never calls the code under test. It is not introduced by this PR and does not block it, but this PR is the natural place to re-couple the two lines (pass content.labels.pageLabel and the composed label: value header string through), and it is cheap. If you would rather not touch it here, please file a follow-up issue so the gap is tracked rather than rediscovered on the third occurrence.

---

Verified and correct

Key question 2 — consistent with ADR-034's locale-decoupling contract: Yes, exactly. pageLabel is populated by reportT('sourceReports.table.pageLabel') inside buildReportContent (buildReportContent.ts:299), which is the single place reportT is applied — satisfying invariant 1 (no module under reportPdf//reportContent/ reaches the ambient locale) and invariant 2 (bare key, resolved against the budget namespace fixed at getFixedT time). The key exists at the same path in both locale bundles (client/src/i18n/en/budget.json:1245 → "Page", client/src/i18n/de/budget.json:1245 → "Seite"), so no translator work is required. t remains a live parameter in merge.ts (passed to buildCoverLetterContent and buildOverviewContent), so no unused-parameter fallout. Placing the label on ReportContentLabels rather than on sourceInfo is the right call — it is a caption, and it follows the "when adding a label, it goes on ReportContentLabels" rule at ADR-034 line 217.

Key question 3 — does the regression assertion actually verify the fix? Yes, and it has a genuine negative control, which is the part that usually fails this bar. merge.test.ts:44 mocks the injected t as a bare key-echo ((key: string) => key), and makeContent() sets labels.pageLabel = 'Page'. So on pre-fix code the call is buildPageFooter('sourceReports.table.pageLabel') and on post-fix code it is buildPageFooter('Page') — the two are distinguishable, and expect(sharedModule.buildPageFooter).toHaveBeenCalledWith('Page') fails if the fix is reverted. buildPageFooter is a real jest.fn in the ./shared.js module factory (line 80), so the spy resolves. The inline comment correctly records why the specific string matters.

Also checked: buildPageFooter's signature in shared.ts:51 is unchanged (pageLabel: string), so no ripple. The types.ts JSDoc on the new field states both the rendered shape and the report-language constraint. Naming is consistent (camelCase TS field, bare i18n key). Trailer Check and Docker are green.

---

Once CRITICAL 1 and HIGH 2 are addressed and Static Analysis plus the six test shards are green, re-request review and I will approve.

[steilerDev]

[product-owner] Requirements & acceptance-criteria review of #1993.

VERDICT: CHANGES_REQUIRED

_{Posted as a comment because GitHub refuses a formal --request-changes review on a PR under the same account (Review Can not request changes on your own pull request). Treat this as a blocking product-owner verdict, not an advisory note.}

The code change in merge.ts is correct and satisfies the "Expected behavior" clause of #1993, and I verified the regression test genuinely discriminates. But the PR is currently unmergeable (red required gate), and the issue's stated problem is materially misdescribed — which affects how #1993 should be closed. Details below.

---

What I verified as met

#	Acceptance criterion (from #1993)	Result
1	buildPageFooter no longer reads the label through the ambient-capable t at merge.ts:134	PASS — now buildPageFooter(reportContent.labels.pageLabel)
2	The label comes from the same injected report-language source as the rest of the report	PASS — pageLabel is populated by reportT('sourceReports.table.pageLabel') in buildReportContent.ts:299, and reportT is i18n.getFixedT(reportLanguage, 'budget') (ReportWizardPage.tsx:254)
3	The pageLabel key resolves in both locales	PASS — en/budget.json:1245 = "Page", de/budget.json:1245 = "Seite"; namespace matches reportT's bound budget namespace, so no key/namespace mismatch was introduced
4	Regression protection exists	PASS, and verified by mutation, not by reading — see below
5	Scope discipline	PASS — 9 files, +14/−1, nothing beyond the fix and the mechanical test-helper updates

On AC 4 — I did not take the assertion on faith. I reverted merge.ts:134 to the beta form locally and re-ran the suite:

Expected: "Page"
Received: "sourceReports.table.pageLabel"
  at client/src/lib/reportPdf/merge.test.ts:720

Then reverted the mutation: 21/21 pass. The test's t is a key-echoing mock while makeContent() sets pageLabel: 'Page', so the two paths produce provably different strings. This is a real regression test, not an assertion that would pass on nothing.

---

CRITICAL 1 — typecheck is red; the PR cannot merge as-is

Static Analysis has already failed:

src/components/reports/ReportContentEditor.test.tsx(93,7): error TS2741:
Property 'pageLabel' is missing in type '{ vendor: string; ... generatedAt: string; }'
but required in type 'ReportContentLabels'.

Six test files were updated for the new required field; a seventh construction site was missed. ReportContentEditor.test.tsx:93 declares an explicitly-typed const LABELS: ReportContentLabels, so adding a required field to the interface breaks it.

Note why this got through: ts-jest does not emit type diagnostics in this repo, so every Jest suite goes green on this branch while npm run typecheck fails. A passing local test run is not evidence that a new required interface field is fully wired.

Fix: add the field to that object literal. Please follow the file's own convention — its header comment states the sentinel values are deliberately not sourceReports.*-prefixed so the mock can't be confused with an echoed i18n key, so use a sentinel, not 'Page':

  generatedAt: 'REPORT_GENERATED_AT_LABEL',
  pageLabel: 'REPORT_PAGE_LABEL',

That file is a *.test.tsx, so the re-commit needs the qa-integration-tester trailer (already present on the current commit — just keep it).

---

MEDIUM 2 — #1993's stated symptom is not reproducible; the issue is hardening, not a live user-facing bug

This does not make the change wrong, but it changes the basis on which #1993 can be closed, so it must be on the record before anyone UATs it.

#1993 claims: "a German-UI user exporting an English report sees Seite 2 / 5 instead of Page 2 / 5." On origin/beta, generateReportPdf has exactly one production caller, and it already passes the report-language function:

ReportWizardPage.tsx:254   const reportT = useMemo(() => i18n.getFixedT(reportLanguage, 'budget'), [reportLanguage]);
ReportWizardPage.tsx:313   const result = await generateReportPdf(report, includedInvoiceIds, effectiveContent,
ReportWizardPage.tsx:318                                          { attachDocuments }, reportT);

merge.ts's t is a parameter, and the injected argument is reportT — not the ambient useTranslation() t. So German UI + English report override already rendered Page 2 / 5 on beta. The described symptom did not occur.

Consequence: if #1993 is validated by "export an English report from a German UI and check the footer", that check passes — but it passed before this PR too, so it proves nothing about the change. Do not close #1993 on that scenario.

What the PR does deliver is real and worth shipping: it removes the latent hazard that any future caller passing an ambient t silently gets a mislocalised footer, and it moves the label into the single ReportContentLabels bag where every other report-language string already lives — consistent with #1938's pattern. That is the correct reading of ADR-034's locale-decoupling contract, and it is a legitimate reason to merge. I'll post a dated correction on #1993 so the issue's framing matches reality rather than silently rewriting it.

The hazard is not theoretical, incidentally: ReportWizardPage.tsx has both t and reportT in scope in the same component (t appears in the dependency array at line 573), so the two are one character apart at every call site.

---

LOW 3 — non-blocking follow-up: three sibling call sites remain

The same shape survives this PR in three places on beta:

Location	Key
coverLetterPdf.ts:46	sourceReports.coverLetter.reference
coverLetterPdf.ts:54	sourceReports.coverLetter.subjectLabel
overviewPdf.ts:844	sourceReports.table.${reason} (skip-footnote reason, dynamic key)

And merge.ts still threads t into both builders (lines 114, 118), so TFunction remains a parameter of all three reportPdf/* modules. Like the footer, these are safe today only because the sole caller injects reportT — they are the same latent hazard, not live bugs.

Correctly out of scope for this PR — #1993 named merge.ts:134 and buildPageFooter specifically, and the PR stayed in its lane, which is the right call. I am filing a separate follow-up rather than expanding this one. My recommendation for that follow-up is to finish the job structurally instead of one call site at a time: move those three strings into ReportContentLabels and drop the TFunction parameter from generateReportPdf / buildCoverLetterContent / buildOverviewContent entirely. With no TFunction in reportPdf/*, ADR-034's "must never reach the ambient locale" becomes compiler-enforced rather than convention-enforced, and this class of issue cannot recur.

---

Re-review

Push the one-line ReportContentEditor.test.tsx fix and get Quality Gates green; I'll flip to approve on that alone — no other changes needed. Findings 2 and 3 are record-keeping and backlog items, not code changes for this PR.

[steilerDev]

[product-owner] Round-2 re-review of PR #2000 (#1993).

VERDICT: CHANGES_REQUIRED

_{Posted as a comment because GitHub refuses a formal review on a PR under the same account. This is a blocking product-owner verdict, not an advisory note.}

Both round-1 blockers are resolved. The new blocker is in scope the round-2 commit added: the ADR-034 rewrite writes a symptom that never occurred into the wiki's permanent Deviation Log, and leaves the page self-contradictory. It is a ~4-line prose fix and I've written the replacement text below.

---

Round-1 blockers: both cleared

Round-1 finding	Status
CRITICAL 1 — TS2741, 7th ReportContentLabels site missed	RESOLVED. ReportContentEditor.test.tsx:109 adds pageLabel: 'REPORT_PAGE_LABEL' — correctly using the REPORT_* sentinel per that file's header comment, not 'Page'. Static Analysis green; all 6 test shards, Trailer Check, and Docker green on 0ba4bef5.
MEDIUM 2 — issue premise corrected on the record	Comment posted on #1993.
LOW 3 — sibling call sites	#2001 filed, Backlog, blocked-by #1993.

The code change is unchanged from round 1 and remains correct. I re-confirmed nothing regressed: merge.ts:134 reads reportContent.labels.pageLabel, and the regression test still discriminates (verified in round 1 by mutation).

---

HIGH 1 (blocking) — the new Deviation Log row states a defect that never existed, as fact

The row added at the bottom of ADR-034 reads:

merge.ts page-footer used the ambient UI locale (buildPageFooter(t('sourceReports.table.pageLabel'))). A German-UI user exporting an English report saw Seite 2 / 5 instead of Page 2 / 5.

That never happened at any commit. I traced the argument across the full history of the call site:

$ git log -L '/await generateReportPdf(/,+8:client/src/pages/ReportWizardPage/ReportWizardPage.tsx'
db496765  feat(reports): wizard settings step with report language selection (#1903)
+        reportT,
bd3f7a62  feat(reports): add bank report wizard with client-side PDF pipeline
+        t,

reportT has been the injected argument since #1903 — the commit that introduced report-language selection. Before #1903 there was no report-language override, so report language always equalled UI language and no mismatch was possible. There is no commit at which a German UI could produce Seite on an English report. t in merge.ts is a parameter; the pre-existing "Known open violation" paragraph mistook a parameter for ambient access, #1993 inherited that mistake from the wiki, and this row now canonizes it.

Three independent confirmations, all on this page:

1. The page's own invariant 1 says: "Every locale-dependent value arrives as a parameter: reportT for text." The old footer code did exactly that. It was never a violation of invariant 1.
2. The page's own grep guard matches useTranslation|/i18n/|Intl\.|toLocale. A t() call on an injected parameter trips none of them — the pre-fix code passed the stated guard. A "known violation" that the page's own guard declares compliant is a contradiction that should have been the tell.
3. This same commit contradicts the row directly. The line at ~219 says the surviving siblings are "correct today only because each receives reportT." The footer received the same reportT. Both statements cannot be true.

Why this is blocking rather than a follow-up: the Deviation Log is the wiki's authoritative append-only record, this PR authors the row, and the falsity was already established on this PR's own thread in round 1. Merging canonizes an error that future agents will cite as evidence that an ambient-locale leak shipped — and per this repo's Wiki Accuracy rule I can't wave through a known code/wiki divergence.

Replacement text for the Deviation column (the fix is real and worth recording — just not as a rendered-output bug):

merge.ts's page footer resolved its label through the injected t parameter rather than ReportContentLabels. Not a rendered-output defect: the sole caller (ReportWizardPage.tsx) has passed reportT since #1903, so the footer always matched the report language, and the code satisfied invariant 1 and the grep guard. The defect was fragility — correctness depended on every caller remembering to pass reportT rather than the interface t, and ReportWizardPage.tsx holds both in scope one character apart. The 2026-08-04 locale-decoupling row above overstated this as a live Seite 2 / 5 symptom; that symptom was never reachable.

And in the rewritten paragraph at ~190, drop the contrast clause "A German-UI user exporting an English report sees 'Page 2 / 5', not 'Seite 2 / 5'" — it's true but implies the Seite state existed. Replace with: "The label is now correct by construction rather than by caller discipline."

---

MEDIUM 2 (blocking, same edit) — "all six test files" was seven

The same row claims the fix "fixed all six test files that construct ReportContentLabels literals." There were seven, and the seventh (ReportContentEditor.test.tsx) is exactly what broke Static Analysis in round 1 — fixed by the very commit that wrote "six". Change to seven, and please append the reusable lesson, because it is the most transferable thing in this PR:

Adding a required field to ReportContentLabels breaks every explicitly-typed construction site. ts-jest emits no type diagnostics here, so every Jest suite goes green while npm run typecheck fails — a green local test run is not evidence the field is wired. Enumerate the construction sites before committing.

---

MEDIUM 3 (blocking, same edit) — the ~219 cross-reference list is wrong in both directions

"Still re-translated independently, and correct today only because each receives reportT: overviewPdf.ts's *N skip-note reasons and merge.ts's page header."

• merge.ts's page header does not belong on this list. Bug: report PDF running header shows a 'generated at' label with no timestamp on pages 2+ #1938 already fixed it; on this branch it composes `${reportContent.labels.generatedAt}: ${reportContent.sourceInfo.generatedAtText}` (merge.ts:131) — no independent translation. The paragraph directly above even says Bug: report PDF running header shows a 'generated at' label with no timestamp on pages 2+ #1938 fixed it.
• coverLetterPdf.ts is missing. Two live t() calls survive this PR: :46 (sourceReports.coverLetter.reference) and :54 (sourceReports.coverLetter.subjectLabel).

Corrected list: overviewPdf.ts's *N skip-note reasons (:844) and coverLetterPdf.ts's reference and subject labels (:46, :54) — tracked in #2001.

---

LOW 4 (non-blocking) — worth one line while you're in the file

The grep guard cannot catch this class at all, which is why it went unnoticed through #1938 and #1993. Consider noting that invariant 1's guard covers ambient access only, and that the structural guard for injected-but-independently-resolved strings is grep -rn "TFunction" client/src/lib/reportPdf/ --include=*.ts | grep -v test returning nothing — the AC of #2001. No blocker; #2001 can add it.

---

Re-review

Fix the two prose blocks and the numeral in the wiki submodule; no code changes needed and CI is already green on the code. I'll approve on the corrected wiki commit. Findings 4 is #2001's.

[steilerDev]

[product-architect] Re-review of PR #2000 (fix/1993-pagefooter-locale) — head fca4673e (rounds 2 and 3).

Both round-1 blockers are resolved, and round 3 (fca4673e) additionally corrects a factual error that my own round-1 review propagated. Verified independently against the code and the published submodule, not from the fix summaries.

VERDICT: APPROVED

_{Posted as a comment because GitHub refuses a formal --approve review on a PR under the same account. Treat this as the product-architect approval.}

---

Round-1 blockers — verified closed

CRITICAL 1 (missed ReportContentLabels site, CI red) — FIXED.
ReportContentEditor.test.tsx:109 now carries pageLabel: 'REPORT_PAGE_LABEL', placed last in the annotated LABELS literal and using the file's REPORT_*_LABEL sentinel convention rather than a plausible-looking 'Page'. That is not cosmetic: the file's header comment explains the values must be impossible to confuse with the chrome-t mock's echoed dotted keys, so a chrome-t leak into the editor stays detectable. On 0ba4bef5 this took Static Analysis, all six Test shards, Coverage Report, Docker, Trailer Check, and the aggregate Quality Gates green.

HIGH 2 (ADR-034 documented the bug as open) — FIXED.
Verified against the actual submodule commit rather than the PR file list: git ls-tree <head> wiki → 85db017c, and git -C wiki ls-remote origin master → 85db017c. The content is genuinely published and the ref is committed on this branch. (Worth doing this way every time — git -C wiki log shows an unpushed commit as HEAD and looks identical.)

• Line 190 — the **Known open violation.** paragraph is replaced by **Locale-decoupling invariant — footer fixed (#1993).**, stating the resolved mechanism, keeping the concrete symptom so the invariant stays falsifiable, and retaining the general rule plus the Bug: report PDF running header shows a 'generated at' label with no timestamp on pages 2+ #1938 header pairing. That preserves the teaching value I asked for: two independent instances of the same defect in the same function is the evidence the rule needs.
• Deviation Log — the new row was appended, not substituted. The 2026-08-04 locale-decoupling row still reads "is NOT fixed by this pass", which was what was believed when written, and the new row cross-references and corrects it. This is the right handling and worth stating as the convention: a Deviation Log row records what was believed at the time; a factual error in one gets corrected by a later row that cites it, never silently rewritten — otherwise the log stops being an audit trail.

---

Round-3 verification (fca4673e) — the reframing is correct, and it corrects my round-1 review

Checked each of the three claims in 85db017c:

1. The reframing from "live mislocalisation bug" to "fragile caller contract" is CORRECT — and materially so.

The round-2 row said "A German-UI user exporting an English report saw Seite 2 / 5". That is false, and so is the same claim in the older locale-decoupling row (interface t, so an English report gets a Seite 2 / 5 footer under a German UI) — which I quoted approvingly in my round-1 review without tracing the injection. I traced it this round. There is exactly one production call site of generateReportPdf: ReportWizardPage.tsx:318, and it passes reportT (i18n.getFixedT(reportLanguage, 'budget'), line 254), not the ambient t from useTranslation('budget') at line 63. This PR does not touch ReportWizardPage.tsx, so the pre-fix call site is byte-identical to beta's. Therefore merge.ts's t parameter was already reportT, the footer was already report-language-correct, and no mislocalised footer ever shipped.

The defect was real but different in kind: generateReportPdf accepted a bare TFunction, so correctness depended on every future caller picking reportT over t — two identifiers one character apart in the same component, with no type-system distinction and no grep guard that can see a t() call on an injected parameter. The new row says exactly this, and names why the fix is a hardening ("makes the locale contract impossible to violate from the call site") rather than a bug fix. That framing is more accurate and more useful than the one it replaces, because the transferable lesson is about the parameter channel, not about a user-visible symptom that never occurred.

2. "all seven test files" — CORRECT. I counted: ReportContentEditor.test.tsx, applyAiContent.test.ts, applyOverrides.test.ts, coverLetterPdf.test.ts, merge.test.ts, overviewPdf.test.ts, realRender.test.ts — seven, all of which now reference pageLabel. The round-2 "six" was off by one.

3. Line 219 — coverLetterPdf.ts correctly added; one wrong entry remains (see MEDIUM A).

---

Non-blocking follow-ups

MEDIUM A — line 219 still lists merge.ts's page header as re-translating independently

Round 3's commit message says it corrected this reference, but the shipped text does not. It now reads:

Still re-translated independently, and correct only because each receives reportT: overviewPdf.ts's *N skip-note reasons, coverLetterPdf.ts's cover-letter field derivations (lines 46 and 54), and merge.ts's page header.

Adding coverLetterPdf.ts:46 / :54 is right — I enumerated every direct t() call under client/src/lib/reportPdf/ and those two (sourceReports.coverLetter.reference, sourceReports.coverLetter.subjectLabel) are the live members that were missing, and they are correct today for precisely the stated reason, since merge.ts threads reportT into buildCoverLetterContent. overviewPdf.ts:844 (t(`sourceReports.table.${reason}`)) is also correct to list.

But merge.ts's page header fails the bullet's own membership test. Since #1938 it is:

return buildPageHeader(
  reportContent.tableTitle,
  reportContent.sourceInfo.sourceName,
  `${reportContent.labels.generatedAt}: ${reportContent.sourceInfo.generatedAtText}`,
);

No t(), and buildPageHeader (shared.ts:25) takes three pre-resolved strings — there is no TFunction anywhere in that path. So it is not "correct only because it receives reportT"; it is correct because it reads the model, which is the same category as the footer after this PR. Keeping it on the list points future readers at an already-hardened site while the genuinely parameter-dependent ones are what need watching.

Suggested edit — drop the header clause and let the footer sentence cover both:

…: overviewPdf.ts's *N skip-note reasons and coverLetterPdf.ts's cover-letter field derivations (lines 46 and 54). merge.ts's page header and page footer both went through this channel and are both now on ReportContentLabels (#1938 and #1993) — two escapes from the same function, which is why this list exists.

There is a real duplication near the header worth keeping separately if you want it: that composed label: value string is byte-identical to the page-1 block in overviewPdf.ts. But that is a composition duplication, not an independent translation, and it belongs in a different sentence.

Cheapest to land while the wiki commit is in flight; not holding the merge.

MEDIUM B — round-1 MEDIUM 3 is still neither fixed nor tracked

realRender.test.ts:139-158 still hand-builds its own docDefinition using both pre-fix forms — t('sourceReports.table.generatedAt') (pre-#1938) and buildPageFooter(t('sourceReports.table.pageLabel')) (pre-#1993) — while production merge.ts uses reportContent.labels.* for both. I offered "re-couple it here, or file a follow-up issue"; neither happened, and I searched open issues and found nothing tracking it.

The hazard is sharper given round 3's reframing: ADR-034 now correctly identifies the parameter channel as the one with no mechanical guard, and names per-locale real-render tests as one of its only two defences — yet this harness structurally cannot catch a merge.ts header/footer parameter leak, because it never calls the code under test. A fork that neutralises the very defence the ADR credits it with. Please file the follow-up so occurrence three isn't rediscovered at review cost.

INFORMATIONAL C — the new Deviation Log row is prettier-unformatted

npx prettier --check flags the ADR-034 page on the new row (trailing cell padding). Net-neutral versus the round-1 baseline — the insertion incidentally normalized the previously-offending LLM-gateway row, so the count of unformatted rows is unchanged at one — and Prettier is not CI-gated for wiki/. Flagged only so a future repo-wide npm run format doesn't surface it as mystery drift. Note wiki/ is not in .prettierignore while the format script globs **/*.md.

INFORMATIONAL D — the optional grep-guard note is now more clearly worth adding

Round 3's fragility framing supplies the argument for it. The invariant-1 grep guard at line 183 could not have caught #1938 or #1993, because both arrived through a t that is a function parameter — no import, no useTranslation, no Intl. to match. Stating that invariant 1 is mechanically guarded only for the import channel, and that the parameter channel has review plus per-locale render tests as its only defence (with MEDIUM B being the reason that second defence is currently weaker than it looks), would close the loop. Still optional.

---

CI status

Quality Gates was green on 0ba4bef5. On fca4673e the shards are still in_progress at the time of writing; Trailer Check is already green. fca4673e changes only the wiki submodule pointer (wiki | 2 +-, no source files), so it cannot affect typecheck, tests, or the build — but please confirm Quality Gates green on fca4673e via bash scripts/ci-wait.sh 2000 before merging, since that is the head the branch protection evaluates.

E2E — red, but not from this diff. E2E Tests (Shard 8/16) failed on 0ba4bef5 with 3 failures, all in e2e/tests/navigation/dashboard.spec.ts (lines 1130, 1164, 1192 — the Add-dropdown "New Invoice" shortcuts, #1735). Not attributable to this PR: the diff touches only reportContent/, reportPdf/, their tests, and the wiki — nothing the dashboard Add dropdown exercises — and the one non-test interface change is a required-field addition that would have failed the green typecheck if it had rippled. Confirmed pre-existing: the same shard fails on PR #1999 and PR #1998.

Does not block this merge (E2E Gates is a main-only required check). It does block beta → main, and no open issue tracks it — three consecutive PRs now carry the same red shard. Recommend filing it before the next promotion attempt.

---

Re-verified as still correct

pageLabel is populated only in buildReportContent.ts:299 via reportT, satisfying invariant 1 (no module under reportPdf//reportContent/ reaches the ambient locale) and invariant 2 (bare key against the budget namespace fixed at getFixedT time). The key exists at the same path in en/budget.json and de/budget.json, so no translator work is required. buildPageFooter's signature (shared.ts:51, pageLabel: string) is unchanged, so no ripple. The label correctly lives on ReportContentLabels rather than sourceInfo — it is a caption, per the "when adding a label, it goes on ReportContentLabels" rule. t remains a live parameter in merge.ts (threaded to buildCoverLetterContent and buildOverviewContent), so no unused-parameter fallout. And the merge.test.ts regression assertion retains a genuine negative control: a key-echoing t mock against labels.pageLabel = 'Page', so the two paths are provably distinguishable and reverting the fix fails the test.

Approved. Items A and B are worth landing or filing; neither holds the merge.

[steilerDev]

[product-owner] Round-3 re-review of PR #2000 (#1993).

VERDICT: APPROVED

Two MUST FIX documentation items below — both medium/low, non-blocking per my verdict matrix, and both two-line edits in the wiki submodule. Please land them before merge; they need no CI cycle of their own beyond the wiki push.

One of the three fixes reported as complete did not land. Details in MUST FIX 1.

---

Round-2 blockers

Round-2 finding	Status
HIGH 1 — Deviation Log row asserted a symptom that never occurred	RESOLVED, and handled better than I asked. See below.
MEDIUM 2 — "all six test files"	RESOLVED — now "seven".
MEDIUM 3 — ~219 cross-reference wrong in both directions	HALF resolved — omission fixed, incorrect inclusion still present. See MUST FIX 1.

On HIGH 1 — the supersession handling is exactly right, and I want it on the record as the pattern to repeat. The new row states the defect as a fragile caller contract, says plainly that "no mislocalised footer was ever observable", names the real hazard (t and reportT one character apart in the same component, no type-system enforcement, no grep guard that catches a t()-on-injected-parameter call), and then does the thing that matters: it leaves the earlier 2026-08-04 locale-decoupling row intact and records that it "was re-characterised as fragility rather than a live defect in the PR #2000 review". That preserves the history rather than rewriting it, and leaves a pointer to where the correction was argued. That is the correct treatment for an append-only log.

Also verified: the wiki commit 85db017 is genuinely pushed to origin/master, so the submodule pointer is not dangling.

---

MUST FIX 1 (medium) — merge.ts's page header is still listed as re-translated independently

Reported as "Fixed the merge.ts page-header reference", but the line is unchanged in that respect. Line 219 currently reads:

Still re-translated independently, and correct only because each receives reportT: overviewPdf.ts's *N skip-note reasons, coverLetterPdf.ts's cover-letter field derivations (lines 46 and 54), and merge.ts's page header.

The coverLetterPdf.ts omission is fixed — thank you, that was the more important half. But merge.ts's page header does not belong in that list and both of its claims are false for it:

• "re-translated independently" — there is no t() call anywhere in the header path. merge.ts:128-132 is buildPageHeader(reportContent.tableTitle, reportContent.sourceInfo.sourceName, `${reportContent.labels.generatedAt}: ${reportContent.sourceInfo.generatedAtText}` ). I grepped the block: zero t( occurrences.
• "correct only because each receives reportT" — the header is correct because it reads from ReportContentLabels, which is the fixed state, not the fragile one. Bug: report PDF running header shows a 'generated at' label with no timestamp on pages 2+ #1938 moved it there, and the paragraph at ~190 plus your own new Deviation Log row both say so.

So the page still contradicts itself, just more narrowly than in round 2: the header is simultaneously "fixed by #1938" and "still re-translated independently".

This is worth the edit rather than leaving as debt because #2001's scope derives from this list. An agent picking up #2001 will go looking for a t() call in merge.ts's header that does not exist, and may conclude the issue is mis-specified.

Fix — delete two words and the trailing clause:

Still re-translated independently, and correct only because each receives reportT: overviewPdf.ts's *N skip-note reasons (line 844) and coverLetterPdf.ts's cover-letter field derivations (lines 46 and 54). merge.ts's page header (#1938) and page footer (#1993) are both on ReportContentLabels.

---

MUST FIX 2 (low) — drop the counterfactual clause at ~190

Still present, unchanged from round 2:

A German-UI user exporting an English report sees "Page 2 / 5", not "Seite 2 / 5".

Literally true as a statement of current behaviour, but the "not X" construction implies the Seite state once existed — the exact claim the new Deviation Log row now explicitly retracts. A reader who reaches the log is corrected; a reader who stops at this paragraph is not.

Fix: replace that sentence with "The label is now correct by construction rather than by caller discipline."

---

Informational — no action needed

The Deviation Log row says the sole caller "always passed reportT". Strictly, the original wizard commit bd3f7a62 passed the ambient t; reportT arrived with db496765 (#1903). But #1903 is the commit that introduced report-language selection, so before it report language always equalled UI language and no mismatch was possible. The row's load-bearing claim — "no mislocalised footer was ever observable" — holds across all of history. Only worth tightening to "always passed reportT since report-language selection existed (#1903)" if you're editing the row anyway for MUST FIX 1.

The ts-jest lesson I suggested appending wasn't added; no need — #2001 AC 8 carries it, which is the better home since that's the issue that will next add required fields to ReportContentLabels.

---

CI

Static Analysis, Trailer Check, and Docker are green on fca4673e. The six unit shards are still in flight, but git diff 0ba4bef5..fca4673e touches only the wiki submodule pointer — the code tree is byte-identical to round 2, where all six shards passed. Please still confirm they land green before merging rather than taking that on inference.

Approval basis for #1993

All five acceptance criteria from my correction comment on the issue are now met: no t() call for the page label in merge.ts; pageLabel populated via reportT in the budget namespace; the key resolves in en and de; the regression test verified discriminating by mutation in round 1; and gates green. Once the shards land, #1993 can go to Done on that statically-verifiable basis — not on the phantom Seite 2 / 5 scenario, which would pass identically on beta.

[steilerDev]

[product-owner] Round-4 confirmation — PR #2000 (#1993).

VERDICT: APPROVED (unchanged) — both MUST FIX items verified resolved

06e98d21 addresses both documentation items from my round-3 review. No further findings; nothing outstanding from my side.

MUST FIX 1 — stale merge.ts page header removed from the hazard list

Line 219 now reads:

Still re-translated independently, and correct only because each receives reportT: overviewPdf.ts's *N skip-note reasons and coverLetterPdf.ts's cover-letter field derivations (lines 46 and 54). merge.ts's page footer and header are both now on ReportContentLabels (footer fixed in #1993; header in #1938).

Verified against the code rather than accepted on the commit message — the list is now exactly the set of surviving call sites, no more and no less:

$ git grep -n 't(.sourceReports' -- client/src/lib/reportPdf/
coverLetterPdf.ts:46   ${t('sourceReports.coverLetter.reference')}
coverLetterPdf.ts:54   ${t('sourceReports.coverLetter.subjectLabel')}
overviewPdf.ts:844     ${t(`sourceReports.table.${reason}`)}
merge.ts               (none)

Three sites, two files, merge.ts clean. That is exactly #2001's scope, which was the reason this mattered — an agent picking up #2001 now reads a list that matches what they will find.

MUST FIX 2 — counterfactual clause dropped at ~190

A German-UI user exporting an English report sees "Page 2 / 5", not "Seite 2 / 5" is gone, replaced with a statement of the structural property: "The page footer now follows the same injection-only path as every other ReportContentLabels field, so the locale contract cannot be violated from the call site." The heading also went from "footer fixed" to "footer hardened", which I didn't ask for and which is the right call — it aligns the section title with the reclassification instead of leaving the two in tension.

The Seite 2 / 5 phantom now appears nowhere in ADR-034 except the original pre-#1993 row, which is correctly preserved with a pointer to its re-characterisation. That is the outcome I was after across rounds 2–4.

Also confirmed: wiki commit 18dc0988 is pushed to origin/master, so the submodule pointer resolves for everyone. Trailer is Claude product-architect, correct for an ADR-page edit.

CI — merge condition

Trailer Check green; Static Analysis, Docker, and the six unit shards are in flight on 06e98d21. The code tree has been byte-identical since 0ba4bef5 (rounds 3 and 4 changed only the wiki submodule pointer), and every gate passed on that tree, so I expect green — but please confirm on this head before merging rather than inferring it. Earlier note for whoever merges: scripts/ci-wait.sh timed out at its 300s budget on the previous head because the unit shards outlast it; that is a non-result, not a failure, and re-running it or polling the check-runs API directly is the right follow-up.

#1993 → Done

Once the gates are green, #1993 can close on the five statically-verifiable criteria recorded in my correction comment on the issue: no t() call for the page label in merge.ts; pageLabel populated via reportT in the budget namespace; the key resolving in both en and de; a regression test proven to discriminate by mutation; and gates green. Not on a "German UI shows Page not Seite" walkthrough — that passes identically on beta and would certify nothing.

#2001 remains open and Backlog for the three sites above.

[github-actions]

🎉 This PR is included in version 2.14.0-beta.8 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 2.14.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀