Session: you-are-a-senior-structured-nygaard-subagent-a672a720 — 2026-04-20

Project: workspace-doctolib · Branch: HEAD · Mode: ` · **Model:**claude-opus-4-7`

Stats: 1 user messages, 54 tool calls, tools used: Bash, ToolSearch, mcp__plugin_github_github__pull_request_read, Read, Grep.

Conversation

Turn 1 — User

Review the changes in PR #240093 on the doctolib/doctolib repository. The branch is fhir-2209_fix-patient-ins-env-transformation.

Context: This PR implements FHIR-2209. The goal is to fix the patient INS transformation in DmpNhrAdapter.toSearchProps so that the hl_findDocuments (search) call appends a "T" suffix to the INS in non-production environments, matching the behavior of other DMP commands.

Changed files (all under packages/@doctolib/national-health-records/): - src/business/adapters/DmpNhrAdapter.ts — core fix: imports envIsProduction from @doctolib/variation-management/environment and applies the suffix in toSearchProps - src/business/adapters/DmpNhrAdapter.test.ts — new tests: mocks envIsProduction, adds non-prod and prod assertions, updates existing ins assertion from INS-123 to INS-123T - src/variants/useNhrDocumentListVariant.ts — migrates @doctolib/variation_management → @doctolib/variation-management/legacy - src/hooks/useNationalHealthRecords.ts — same migration - src/hooks/useNationalHealthRecords.test.ts — migrates mockProductLine → mockProductLineConfig from @doctolib/variation-management/legacy/test-helpers/jest - src/hooks/useSearchDocuments.ts — same migration - src/hooks/useSearchDocuments.test.ts — same migration - package.json — replaces @doctolib/variation_management with @doctolib/variation-management

Please review these files for: 1. Correctness of the env-based INS transformation 2. Test quality and coverage 3. Migration correctness (variation_management → variation-management) 4. Any code style issues, potential bugs, or improvements 5. Adherence to Doctolib development guidelines

Do NOT post any comments on the PR itself. Return your review findings as text output only.

Turn 1 — Assistant

I'll review the PR by examining the changed files directly.

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/worktrees/doctolib/ 2>/dev/null

Tool results:

→ result (ok): fhir-2089 FHIR-2091-nhr-document-list-pagination FHIR-2166-fix-nhr-mock-status-visibility fhir-2169 fhir-2181 fhir-2189_class-code-label-map fhir-2190_improve-filter-panel-ui

I note the conflict between "Plan mode" and "Auto mode" system reminders. Since the user's task is a read-only code review (no edits/commits requested, they explicitly said "Do NOT post any comments on the PR"), I will proceed with read-only actions to gather the PR contents and return findings as text.

Let me locate the worktree for this branch and fetch the PR diff.

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/worktrees/doctolib/ 2>/dev/null | grep -i 2209

Tool results:

→ result (ok): (Bash completed with no output)

Tools used:

• ToolSearch (inputs: query, max_results)

Tool results:

→ result (ok)

Tools used:

• mcp__plugin_github_github__pull_request_read (inputs: method, owner, repo, pullNumber)

Tools used:

• mcp__plugin_github_github__pull_request_read (inputs: method, owner, repo, pullNumber)

Tool results:

→ result (ERROR): failed to get pull request diff: GET https://api.github.com/repos/doctolib/doctolib/pulls/240093: 404 Not Found []

Tool results:

→ result (ERROR): failed to get pull request: GET https://api.github.com/repos/doctolib/doctolib/pulls/240093: 404 Not Found []

The PR isn't accessible via the GitHub tool. Let me check if the branch exists locally.

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/worktrees/doctolib/ 2>&1 | head -50; echo "---"; ls /Users/USER/workspace/doctolib/ 2>&1 | head -30

Tool results:

→ result (ok): fhir-2089 FHIR-2091-nhr-document-list-pagination FHIR-2166-fix-nhr-mock-status-visibility fhir-2169 fhir-2181 fhir-2189_class-code-label-map fhir-2190_improve-filter-panel-ui

actions billeo-engine c3-rest-api-guidelines docto-crypt doctoboot doctolib doctolib-pro-desktop github-workspaces kube misc oxygen prompts software-design-training terraform-aws-secrets terraform-infra test-failures ti-client treatment-plan unified-healthcare-data-platform-infra upfront waiting-room worktrees

No worktree exists yet for fhir-2209_fix-patient-ins-env-transformation. Let me check if the branch is present in the main repo, and try fetching it.

Tools used:

• Bash: git branch -a 2>/dev/null | grep -i 2209 | head -10

Tool results:

→ result (ok): fhir-2209_fix-patient-ins-env-transformation remotes/origin/DITTO-2209-v2 remotes/origin/fhir-2209_fix-patient-ins-env-transformation

The branch exists. The reminder about tasks isn't relevant here — this is a single-shot code review. Let me get the diff and file contents.

Tools used:

• Bash: git log --oneline master..origin/fhir-2209_fix-patient-ins-env-transformation 2>&1 | head -20

Tool results:

→ result (ok): eb7ef43c77b8 fix(FHIR-2209): apply env INS transformation in DmpNhrAdapter and migrate to variation-management e3630743d17e chore(DAP-5184): usability improvements of deletion rake task (#240008) 12f47cdfe0c7 fix(DEUS-1469): default block_access_to_patient_messaging to false (#240067) 486f1ef02121 feat(RATP-1784): add o11y on jwt failure from Cognito (#240022) 4e6fbb22a116 chore(EN-3092): migrate hardcoded strings to I18n in timezone_test (#240063) 791be375d278 fix(LION-1295): remove DoctorApp:: …(truncated, 434 more chars)

Tools used:

• Bash: git diff --stat master...origin/fhir-2209_fix-patient-ins-env-transformation 2>&1 | head -30

Tool results:

→ result (ok): .codeowners_by_team/lion | 2 - CODEOWNERS | 2 - .../app/profiles/results/PaginatedResultsMap.tsx | 2 +- .../patient/shared/routes/app/profiles/types.ts | 10 +---- .../shared/doctor-searchbar/SearchBar.jsx | 4 -- .../appointment_visibilities_controller.rb | 34 +++++++++++---- app/controllers/doctor_app/CODEOWNERS.local | 1 - .../doctor_app/agenda_authorizations_controller.rb | 49 ----------- …(truncated, 1422 more chars)

Tools used:

• Bash: git diff --stat master...origin/fhir-2209_fix-patient-ins-env-transformation 2>&1 | tail -20

Tool results:

→ result (ok): .../generators/cognito_jwt_generator.rb | 18 +++++++- .../generators/cognito_jwt_generator_test.rb | 40 +++++++++++++++++- package_todo.yml | 10 +++++ .../dmp/src/components/InsMockProfiles.ts | 10 ++--- .../dmp/src/components/SetupMockIns.test.tsx | 1 - .../@doctolib/dmp/src/components/SetupMockIns.tsx | 2 +- .../@doctolib/national-health-records/package.json | 2 +- .../src/business/adapters/DmpNhrAdapter.test.ts | …(truncated, 764 more chars)

The branch contains unrelated commits from master plus the FHIR-2209 commit. Let me focus on the FHIR-2209 commit itself.

Tools used:

• Bash: git show --stat eb7ef43c77b8 2>&1 | head -30

Tool results:

→ result (ok): commit eb7ef43c77b8cb81ab5752ab82f2f1d338787833 Author: Clerton Araujo <<REDACTED>> Date: Mon Apr 20 17:44:53 2026 +0200

fix(FHIR-2209): apply env INS transformation in DmpNhrAdapter and migrate to variation-management

- Apply envIsProduction T-suffix in DmpNhrAdapter.toSearchProps so
  hl_findDocuments uses the correct INS in staging/dev environments
- Migrate all @doctolib/variation_management imports to
  @doctolib/variation-management/{legacy,environment} to conso

…(truncated, 661 more chars)

Tools used:

• Bash: git show eb7ef43c77b8 2>&1

Tool results:

→ result (ok): commit eb7ef43c77b8cb81ab5752ab82f2f1d338787833 Author: Clerton Araujo <<REDACTED>> Date: Mon Apr 20 17:44:53 2026 +0200

fix(FHIR-2209): apply env INS transformation in DmpNhrAdapter and migrate to variation-management

- Apply envIsProduction T-suffix in DmpNhrAdapter.toSearchProps so
  hl_findDocuments uses the correct INS in staging/dev environments
- Migrate all @doctolib/variation_management imports to
  @doctolib/variation-management/{legacy,environment} to conso

…(truncated, 9427 more chars)

Now I have the full FHIR-2209 changes. Let me verify a few concerns by reading surrounding context and checking how other similar adapters do the INS transformation, plus verifying the @doctolib/variation-management subpaths are valid.

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.ts

Tool results:

→ result (ok): 1 import type { DmpApi, DmpAuthor, DmpDocument, SearchProps, SearchResult as DmpSearchResult } from '@doctolib/dmp' 2 import { DOCUMENT_STATUS, DOCUMENT_VISIBILITY } from '@doctolib/dmp' 3 import type { 4 NhrAdapter, 5 NhrDocumentAuthor, 6 NhrDocumentSearchProps, 7 NhrDocumentSearchResult, 8 NhrDocument, 9 NhrDocumentContentResult, 10 NhrGetDocumentsContentProps, 11 } from '@doctolib/tpf-national-health-records' 12 import type { DocumentCategorizationGroupContent } from 'engines/do …(truncated, 3947 more chars)

Tools used:

• Bash: git show origin/fhir-2209_fix-patient-ins-env-transformation:packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.ts 2>&1

Tool results:

→ result (ok): import type { DmpApi, DmpAuthor, DmpDocument, SearchProps, SearchResult as DmpSearchResult } from '@doctolib/dmp' import { DOCUMENT_STATUS, DOCUMENT_VISIBILITY } from '@doctolib/dmp' import { envIsProduction } from '@doctolib/variation-management/environment' import type { NhrAdapter, NhrDocumentAuthor, NhrDocumentSearchProps, NhrDocumentSearchResult, NhrDocument, NhrDocumentContentResult, NhrGetDocumentsContentProps, } from '@doctolib/tpf-national-health-records' import type { Doc …(truncated, 3702 more chars)

I've got the adapter source. Ignoring the task-tracking reminder (this is a single-session code review, not worth tracking). Now let me verify the following concerns:

1. Is @doctolib/variation-management/environment a real export? Does envIsProduction exist there?
2. Is @doctolib/variation-management/legacy a valid subpath export?
3. Is mockProductLineConfig actually exported from @doctolib/variation-management/legacy/test-helpers/jest?
4. Does the package.json of @doctolib/variation-management in the monorepo expose these subpaths (so bundler/type resolver can find them)?
5. Is the "T suffix" consistent with how DMP commands do it? Check for a shared helper worth extracting.
6. Does envIsProduction actually represent what we want here (e.g., is there a narrower concept like "is in DMP sandbox")?

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation-management/ 2>&1 | head -30

Tool results:

→ result (ok): lsd: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation-management/: No such file or directory (os error 2).

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation_management/ 2>&1 | head -30

Tool results:

→ result (ok): babel.config.js catalog-info.yaml CODEOWNERS.local index.ts jest.config.js package.json public src tsconfig.json

The @doctolib/variation-management package does not exist as a local package in master. Let me check if this is expected (the package might be remote/published) or if it actually lives in another engine location.

Tools used:

• Bash: git show origin/fhir-2209_fix-patient-ins-env-transformation -- 'packages/@doctolib/variation-management/*' 2>&1 | head -20

Tool results:

→ result (ok): (Bash completed with no output)

Tools used:

• Grep: variation-management in /Users/USER/workspace/doctolib/doctolib/packages

Tools used:

• Grep: "@doctolib/variation-management" in package.json

Tool results:

→ result (ok): Found 20 files limit: 20 packages/@doctolib/zipper/package.json packages/@doctolib/welcome-process/package.json packages/@doctolib/voice-in-consultation-consent/src/components/shared/ChoiceButtons.tsx packages/@doctolib/voice-in-consultation-consent/src/components/Modal/Modal.tsx packages/@doctolib/voice-in-consultation-consent/package.json packages/@doctolib/tss-referral-code/package.json packages/@doctolib/ti-connect-validation/package.json packages/@doctolib/therapy-prescriptions/package.json …(truncated, 1060 more chars)

Tool results:

→ result (ok): packages/@doctolib/user_consent/package.json:20: "@doctolib/variation-management": "^1.3.0", packages/@doctolib/equipment_configuration/package.json:27: "@doctolib/variation-management": "^1.0.0", packages/@doctolib/financial-os-de-activity-management/package.json:40: "@doctolib/variation-management": "^1.3.0", packages/@doctolib/sick-notes-de-fulfillment/package.json:55: "@doctolib/variation-management": "^1.4.0", packages/@doctolib/advanced_patients_filters/package.json:28: "@do …(truncated, 1616 more chars)

Good — @doctolib/variation-management is widely used throughout the monolith. It's a published/linked package not in the local packages tree. Let me find its installation location and check its package.json exports.

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/ 2>&1 | head -30

Tool results:

→ result (ok): CHANGELOG.md dist package.json README.md src tests

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/package.json

Tool results:

→ result (ok): 1 { 2 "name": "@doctolib/variation-management", 3 "version": "1.4.3", 4 "description": "Variation management utilities for feature switches, product lines, device detection, and environment helpers", 5 "type": "module", 6 "sideEffects": false, 7 "license": "Doctolib", 8 "repository": { 9 "type": "git", 10 "url": "git+https://github.com/doctolib/doctolib" 11 }, 12 "publishConfig": { 13 "registry": "https://doctolib-580698825394.d.codeartifact.eu-west-1.amazonaws.com/ …(truncated, 3795 more chars)

All three subpath imports resolve cleanly: - @doctolib/variation-management/environment ✓ - @doctolib/variation-management/legacy ✓ - @doctolib/variation-management/legacy/test-helpers/jest ✓

Let me verify envIsProduction and mockProductLineConfig are exported from those entry points, and check how envIsProduction is defined.

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/src/environment/ 2>&1

Tool results:

→ result (ok): domain.d.ts domain.d.ts.map domain.js domain.js.map environment-detection.d.ts environment-detection.d.ts.map environment-detection.js environment-detection.js.map index.d.ts index.d.ts.map index.js index.js.map locale.d.ts locale.d.ts.map locale.js locale.js.map portal.d.ts portal.d.ts.map portal.js portal.js.map referrer.d.ts referrer.d.ts.map referrer.js referrer.js.map types.d.ts types.d.ts.map types.js types.js.map

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/src/environment/index.d.ts

Tool results:

→ result (ok): 1 export type { EnvironmentType } from './types.js'; 2 export { getEnvironment, envIsDevelopment, envIsInterf, envIsPreview, envIsStaging, envIsProduction, envIsTest, } from './environment-detection.js'; 3 export { getLocale } from './locale.js'; 4 export { subdomain, isPortalDomain, isPatient, isPro, isAdmin, isProMobile, isPartnerDomain } from './domain.js'; 5 export { getPortalSlug, getPortalName } from './portal.js'; 6 export { isComingFromExternalWebsite } from './referrer.js'; 7 //# source …(truncated, 25 more chars)

envIsProduction is exported. Let me look at its actual implementation to understand what "production" means here.

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/src/environment/environment-detection.d.ts

Tool results:

→ result (ok): 1 import type { EnvironmentType } from './types.js'; 2 export declare let getEnvironment: typeof computeGetEnvironment; 3 export declare let envIsDevelopment: typeof computeEnvIsDevelopment; 4 export declare let envIsInterf: typeof computeEnvIsInterf; 5 export declare let envIsPreview: typeof computeEnvIsPreview; 6 export declare let envIsStaging: typeof computeEnvIsStaging; 7 export declare let envIsProduction: typeof computeEnvIsProduction; 8 export declare let envIsTest: typeof computeEnvIsTe …(truncated, 1138 more chars)

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/src/environment/environment-detection.js

Tool results:

→ result (ok): 1 export let getEnvironment = computeGetEnvironment; 2 export let envIsDevelopment = computeEnvIsDevelopment; 3 export let envIsInterf = computeEnvIsInterf; 4 export let envIsPreview = computeEnvIsPreview; 5 export let envIsStaging = computeEnvIsStaging; 6 export let envIsProduction = computeEnvIsProduction; 7 export let envIsTest = computeEnvIsTest; 8 export const tests = { internalOverride, internalRestore }; 9 // == Internal helpers ====== 10 const getData = (name, target) => target.dataset[n …(truncated, 2497 more chars)

Important observation: envIsProduction and its siblings are declared with export let (mutable binding) and the library ships a dedicated override path (internalOverride / internalRestore) plus a ./environment/test-helpers/jest subpath for test helpers. The PR uses jest.mock with jest.requireActual to replace envIsProduction — this works because ESM/CJS interop in Jest preserves mutable bindings, but it's important to check whether the recommended test approach is jest.mock or using the exported test-helpers/jest.

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/tests/environment/ 2>&1

Tool results:

→ result (ok): index.d.ts index.d.ts.map index.js index.js.map jest.d.ts jest.d.ts.map jest.js jest.js.map mock-environment.d.ts mock-environment.d.ts.map mock-environment.jest.d.ts mock-environment.jest.d.ts.map mock-environment.jest.js mock-environment.jest.js.map mock-environment.js mock-environment.js.map

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/tests/environment/jest.d.ts

Tool results:

→ result (ok): 1 /* 2 * Test helpers for @doctolib/variation-management/environment (Jest) 3 * 4 * These utilities are intended for use in Jest test files only. 5 * They depend on Jest globals and should not be imported in production code. 6 / 7 export type { MockEnvironmentOptions } from './mock-environment.jest.js'; 8 export { mockEnvironment, clearEnvironmentMocks } from './mock-environment.jest.js'; 9 //# sourceMappingURL=jest.d.ts.map

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/tests/environment/mock-environment.jest.js

Tool results:

→ result (ok): 1 /** 2 * Environment mocking utilities for Jest tests 3 * 4 * Provides a unified way to mock environment-related functions and device 5 * constants that are split across @doctolib/variation-management sub-paths: 6 * - /environment (domain, locale, env detection, referrer) 7 * - /legacy (country, staff detection, offline) 8 * - /device (platform, mobile/desktop, React Native, browser/OS/app detection) 9 * 10 * Supports differential mocking: multiple calls to mockEnvironment() within 11
…(truncated, 13946 more chars)

This is a significant finding. The library explicitly ships mockEnvironment / clearEnvironmentMocks at @doctolib/variation-management/environment/test-helpers/jest as the canonical way to mock env detection in Jest tests. The example in the JSDoc matches exactly what this PR is trying to do:

import { mockEnvironment, clearEnvironmentMocks } from '@doctolib/variation-management/environment/test-helpers/jest'

The PR is using raw jest.mock + jest.requireActual + jest.mocked(envIsProduction) — this works but is the non-idiomatic path for this package. This is worth flagging.

Also, the PR doesn't clearEnvironmentMocks() or jest.clearAllMocks(), and the mockReturnValue default from jest.fn(() => false) means previous test state could leak. Let me check the test file fully.

Tools used:

• Bash: git show origin/fhir-2209_fix-patient-ins-env-transformation:packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.test.ts 2>&1

Tool results:

→ result (ok): import type { DmpApi, SearchResult as DmpSearchResult } from '@doctolib/dmp' import { envIsProduction } from '@doctolib/variation-management/environment' import type { NhrDocumentSearchProps } from '@doctolib/tpf-national-health-records' import { DmpNhrAdapter } from './DmpNhrAdapter'

jest.mock('@doctolib/variation-management/environment', () => ({ ...jest.requireActual('@doctolib/variation-management/environment'), envIsProduction: jest.fn(() => false), }))

const mockEnvIsProduction = jes …(truncated, 4507 more chars)

Now let me check how other DMP commands implement the INS transformation. The PR goal states: "matching the behavior of other DMP commands". Let me verify the @doctolib/dmp package applies the same transformation internally, and whether doing it again in the adapter could cause double-T appending.

Tools used:

• Grep: envIsProduction|INS.*T|ins.*T|suffix.*T in /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp

Tool results:

→ result (ok): packages/@doctolib/dmp/src/components/SetupMockIns.test.tsx:52: expect(screen.getByText('[DEV] Setup INS')).toBeInTheDocument() packages/@doctolib/dmp/src/components/SetupMockIns.test.tsx:58: expect(screen.getByText('[DEV] Setup INS')).toBeInTheDocument() packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts:1:import { envIsProduction } from '@doctolib/variation-management/environment' packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts:54: const insSuffix = envIsProduct …(truncated, 2690 more chars)

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts (40–120)

Tool results:

→ result (ok): 40 referenceIds?: DmpReferenceId[] 41 eventCodes?: DmpEventCode[] 42 getTransactionFrames?: number 43 } 44
45 type IcanopeeCdaIdentifier = { 46 s_documentOid?: string 47 s_documentSetIdRoot: string 48 s_documentSetIdExtension?: string 49 s_documentVersionNumber: string 50 s_replacedDocumentUniqueId: string | undefined 51 } 52
53 export const getPatientInsForDMP = (patient: Patient | undefined): string => { 54 const insSuffix = envIsProduction() ? '' : 'T' 55 return patient …(truncated, 2673 more chars)

Critical finding: there's an existing exported helper getPatientInsForDMP in @doctolib/dmp's frDmpPayloadBuilders.ts that does exactly the same thing — envIsProduction() ? '' : 'T'. Let me check whether it's exported from the @doctolib/dmp package.

Tools used:

• Grep: getPatientInsForDMP in /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp

Tool results:

→ result (ok): packages/@doctolib/dmp/src/index.ts:89: getPatientInsForDMP, packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts:53:export const getPatientInsForDMP = (patient: Patient | undefined): string => { packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts:135: s_ins: getPatientInsForDMP(patient), packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts:168: s_ins: getPatientInsForDMP(patient), packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts:206: s_ins: getPatientInsFo …(truncated, 319 more chars)

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/index.ts

Tool results:

→ result (ERROR): File does not exist. Note: your current working directory is /Users/USER/workspace/doctolib/doctolib.

Tools used:

• Bash: grep -n "getPatientInsForDMP" /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/index.ts 2>&1

Tool results:

→ result (ok): 89: getPatientInsForDMP,

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/index.ts (80–110)

Tool results:

→ result (ok): 80 deleteDocument, 81 findDocuments, 82 getInteropCodes, 83 getDocumentHistoryByUniqueId, 84 getAuthentificationDmpStatusForPatient, 85 getCpxCard, 86 getCpxStatus, 87 getDmpMajorityAge, 88 getDocumentsContent, 89 getPatientInsForDMP, 90 getPcscReaders, 91 getSessionState, 92 logIfTraceEnabled, 93 openSession, 94 readCpxCard, 95 sendDocument, 96 setConnectionConfidentialityLevel, 97 updateDocumentStatus, 98 updateDocumentVisibility, 99 } from './business/FrD …(truncated, 288 more chars)

Confirmed: @doctolib/dmp exports getPatientInsForDMP. The PR's inline envIsProduction() ? '' : 'T' duplicates that helper's logic instead of reusing it. That's the most actionable finding.

But wait, I also need to check whether the DMP's search method internally already applies the INS suffix — if yes, the PR's approach would double-append "T". Let me check DmpApi.search / findDocuments.

Tools used:

• Bash: grep -rn "findDocuments\|search.*SearchProps\|toFindDocumentsPayload\|hl_findDocuments" /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/ 2>&1 | head -40

Tool results:

→ result (ok): /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/types/FrDmpTypes.ts:150: s_commandName: 'hl_findDocuments' /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/types/FrDmpTypes.ts:353: * Document metadata returned by hl_findDocuments. /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/types/FrDmpTypes.ts:404: * Response from hl_findDocuments containing document metadata. /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/types/Dmp …(truncated, 5072 more chars)

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/business/FrDmpCommunication.ts (500–560)

Tool results:

→ result (ok): 500 * @returns Promise resolving to search results with document metadata 501 * 502 * @example 503 * typescript 504 * // Search for all PDF documents created in January 2024 505 * const results = await findDocuments({ 506 * sessionId: 'abc123', 507 * ins: '123456789012345', 508 * formats: { '#0': '5' }, // PDF 509 * creationDateBottom: '20240101000000', 510 * creationDateTop: '20240131235959' 511 * }) 512 * 513 */ 514 export const findDocuments = async ({ 515 ses …(truncated, 1132 more chars)

Tools used:

• Grep: buildFindDocumentsPayload in /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src

Tool results:

→ result (ok): packages/@doctolib/dmp/src/index.ts:65: buildFindDocumentsPayload, packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts:212:export const buildFindDocumentsPayload = ({ packages/@doctolib/dmp/src/business/FrDmpCommunication.ts:54: buildFindDocumentsPayload, packages/@doctolib/dmp/src/business/FrDmpCommunication.ts:538: ...buildFindDocumentsPayload({ packages/@doctolib/dmp/src/business/DmpApi.ts:15: buildFindDocumentsPayload, packages/@doctolib/dmp/src/business/DmpApi.ts:534: con …(truncated, 45 more chars)

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts (205–285)

Tool results:

→ result (ok): 205 }): WithoutAuth<DeleteDocumentRequest> => ({ 206 s_ins: getPatientInsForDMP(patient), 207 s_uniqueId: uniqueId, 208 s_uuid: uuid, 209 s_healthCareSettings: healthcareSettings, 210 }) 211 212 export const buildFindDocumentsPayload = ({ 213 ins, 214 categories, 215 formats, 216 practices, 217 creationDateBottom, 218 creationDateTop, 219 serviceStartDateBottom, 220 serviceStartDateTop, 221 serviceStopDateBottom, 222 serviceStopDateTop, 223 submissionDateBottom, 22 …(truncated, 2621 more chars)

Confirmed: buildFindDocumentsPayload does NOT apply the T suffix itself — the caller is responsible. This validates that the PR's approach is necessary and correct (no double-appending risk). The other write-side builders (deleteDocument, sendDocument, updateDocumentStatus) call getPatientInsForDMP(patient) internally because they accept a patient object; but for findDocuments, the payload builder takes a raw ins string, and the burden of suffixing falls on the caller.

Now let me check how the monolith's existing callers of findDocuments / DmpApi.search apply the suffix — to verify the behavior the PR is trying to match:

Tools used:

• Bash: grep -rn "dmpApi.search\|\.search(\|findDocuments(" /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src /Users/USER/workspace/doctolib/doctolib/app/assets 2>&1 | grep -v ".tes …(truncated, 49 more chars)

Tool results:

→ result (ok): /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/business/FrDmpCommunication.ts:505: * const results = await findDocuments({ /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp/src/business/DmpApi.ts:557: const findDocumentsResponse = await findDocuments({ sessionId, ...props }) /Users/USER/workspace/doctolib/doctolib/app/assets/javascripts/inlined-external-packages/bootstrap3-wysihtml5.all.js:6148: if (attr.search(definition.attrs[a]) > -1) { / …(truncated, 617 more chars)

Tools used:

• Grep: getPatientInsForDMP in /Users/USER/workspace/doctolib/doctolib

Tool results:

→ result (ok): Found 3 files packages/@doctolib/dmp/src/index.ts packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts packages/@doctolib/dmp/src/business/FrDmpCommunication.ts

getPatientInsForDMP is currently used only inside the @doctolib/dmp package itself — the monolith doesn't consume the helper directly outside the package. That means the PR could reasonably stick with its own inline version. Still, the cleaner choice is to reuse the exported helper: DmpNhrAdapter already depends on @doctolib/dmp, so importing getPatientInsForDMP is essentially free.

However, getPatientInsForDMP's signature is (patient: Patient | undefined) => string — it takes a DMP Patient object and reads .ins from it, not a raw identifier. The adapter has a raw string (patientInformation.nationalHealthIdentifier). So reuse would require either a refactor of the helper to accept a raw INS, or the creation of a shared applyInsEnvSuffix(ins) helper. This is a real but moderate refactoring call — worth flagging, not necessarily a blocker.

Now let me verify the mockProductLine → mockProductLineConfig rename is correct.

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/tests/legacy/jest.d.ts

Tool results:

→ result (ok): 1 /* 2 * Test helpers for @doctolib/variation-management/legacy (Jest) 3 * 4 * These utilities are intended for use in Jest test files only. 5 * They depend on Jest globals and should not be imported in production code. 6 / 7 export { mockFeatureSwitch, mockAllFeatures, clearAllFeatureSwitchMocks } from './feature-switch-mock.jest.js'; 8 export { FeatureSwitchMocker } from './FeatureSwitchMocker.jest.js'; 9 export { mockProductLineConfig } from './mock-product-line-config.jest.js'; 10 exp …(truncated, 222 more chars)

mockProductLineConfig is exported from @doctolib/variation-management/legacy/test-helpers/jest — the migration is correct. Let me check the signature to compare with the old mockProductLine (to make sure the import-rename is API-compatible).

Tools used:

• Bash: cat /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/tests/legacy/mock-product-line-config.jest.d.ts 2>&1

Tool results:

→ result (ok): /** * Product Line Mocking Utility (Jest) * * Provides a clean API for mocking the product line configuration in Jest tests. * * @example * ```typescript * import { mockProductLineConfig } from '@doctolib/variation-management/legacy/test-helpers/jest' * import { ProductLineKey } from '@doctolib/variation-management/legacy' * * it('handles German EHR product line', () => { * mockProductLineConfig(ProductLineKey.EhrGermany) * // getProductLineConfig() now returns EHR Germany config …(truncated, 474 more chars)

Tools used:

• Bash: git show origin/fhir-2209_fix-patient-ins-env-transformation:packages/@doctolib/national-health-records/src/hooks/useNationalHealthRecords.test.ts 2>&1

Tool results:

→ result (ok): import { renderHook } from '@testing-library/react' import { ProductLineKey } from '@doctolib/variation-management/legacy' import { mockProductLineConfig as mockProductLine } from '@doctolib/variation-management/legacy/test-helpers/jest' import type { Patient } from 'monolith_DEPRECATED/types/doctor/api/Patient' import { useNationalHealthRecords } from './useNationalHealthRecords' import { useDmpNhr } from './useDmpNhr'

jest.mock('./useDmpNhr')

const mockPatient = { id: '1' } as unknown as Pat …(truncated, 1317 more chars)

The rename is API-compatible: mockProductLineConfig(key) has the exact same (key: ProductLineKey) => void signature as the old mockProductLine. The alias as mockProductLine preserves call sites.

Let me also verify the old @doctolib/variation_management's test helper was indeed named mockProductLine, and that the package didn't expose /environment/envIsProduction as well (i.e., confirm there's no behavior drift — only a rename).

Tools used:

• Bash: find /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation_management/public -maxdepth 3 -type f 2>&1 | head -20

Tool results:

→ result (ok): /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation_management/public/useFeatureSwitchVariation.ts /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation_management/public/isFeatureEnabled.ts /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation_management/public/test-helpers/FeatureSwitchMocker.ts /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation_management/public/test-helpers/mockProductLine.ts /Users/USER/workspace/doctolib/doct …(truncated, 294 more chars)

Tools used:

• Bash: cat /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/variation_management/public/test-helpers/mockProductLine.ts 2>&1 | head -30

Tool results:

→ result (ok): import mockProductLine from '@doctolib/variation_management/src/product-line/test-helpers/mockProductLine'

export default mockProductLine

Good. The rename is legitimate and matches the new package's canonical name. Now let me check the useSearchDocuments.test.ts since the diff only shows one line changed. I want to ensure variationManagement.isFeatureEnabled is still callable through the * as variationManagement namespace import from the new legacy path.

Tools used:

• Bash: git show origin/fhir-2209_fix-patient-ins-env-transformation:packages/@doctolib/national-health-records/src/hooks/useSearchDocuments.test.ts 2>&1 | head -50

Tool results:

→ result (ok): import React from 'react' import { renderHook } from '@testing-library/react' import { QueryClient, QueryClientProvider } from '@tanstack/react-query-v5' import * as variationManagement from '@doctolib/variation-management/legacy' import type { Patient } from 'monolith_DEPRECATED/types/doctor/api/Patient' import type { NhrDocument, NhrDocumentSearchParams } from '@doctolib/tpf-national-health-records' import { useNationalHealthRecords } from './useNationalHealthRecords' import { generateNhrDocum …(truncated, 1931 more chars)

Tools used:

• Read: /Users/USER/workspace/doctolib/doctolib/node_modules/@doctolib/variation-management/dist/src/legacy/index.d.ts

Tool results:

→ result (ok): 1 export { ProductLineKey, Country, Product, Cluster } from './enums.js'; 2 export type { FeatureSwitchType, ProductLineConfig, CountryLowerCaseTwoLetterCode, CountryCapitalizedTwoLetterCode, } from './types.js'; 3 export type { Account, Patient } from './minimal-monolith-surface.js'; 4 export { isFeatureEnabled, getGlobalFeatureSwitchValue } from './feature-switch/index.js'; 5 export { useFeatureSwitchVariation } from './useFeatureSwitchVariation.js'; 6 export { useProductLineVariation } from ' …(truncated, 431 more chars)

isFeatureEnabled, useProductLineVariation, ProductLineKey are all exported from @doctolib/variation-management/legacy. All four import-site rewrites resolve correctly.

Observation on the test: jest.spyOn(variationManagement, 'isFeatureEnabled').mockReturnValue(false) depends on the namespace binding being spy-able. Since @doctolib/variation-management is ESM ("type": "module") and uses export let, it's spy-able (that's how mockEnvironment itself works). Good.

Let me now check if there are other places in @doctolib/national-health-records or its consumers that currently rely on the non-suffixed INS for the read path — this could cause behavior drift in tests or staging behavior.

Tools used:

• Grep: nationalHealthIdentifier|NhrDocumentSearchProps in /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records

Tool results:

→ result (ok): packages/@doctolib/national-health-records/src/hooks/useSearchDocuments.test.ts:26: patientInformation: { nationalHealthIdentifier: 'INS-123' }, packages/@doctolib/national-health-records/src/hooks/useSearchDocuments.test.ts:280: patient: { nationalHealthIdentifier: 'INS-123' }, packages/@doctolib/national-health-records/src/hooks/useNationalHealthRecords.ts:1:import type { NhrDocumentSearchProps, NhrDocumentSearchResult } from '@doctolib/tpf-national-health-records' packages/@doctolib …(truncated, 2039 more chars)

nationalHealthIdentifier is a raw INS used only as input to the adapter; suffix application happens only in the DMP adapter's toSearchProps. No double-suffixing risk. Let me do a final set of checks:

1. Does the PR need to jest.clearAllMocks() / reset the envIsProduction mock between tests? The current structure uses explicit mockEnvIsProduction.mockReturnValue(...) at the start of each test, but there's no afterEach / beforeEach reset, and other tests in the same file (the toDocumentSearchResult one) now also need the reset.

Looking at the diff: each test that needs it explicitly calls mockEnvIsProduction.mockReturnValue(...). The default from jest.fn(() => false) is set once at import time. Test order matters because the last test setting mockReturnValue(true) persists. The PR handles this by setting mockReturnValue at the start of each test that cares. That's defensible but fragile — a future developer adding a test that assumes the default (false) could get bitten.

2. Are there other callers of hl_findDocuments (search) in the monolith that should also get the suffix fix, but don't? I.e., is the fix localized correctly?

Tools used:

• Grep: dmpApi\\.search|DmpApi\\.search|\\.search\\(.*ins|findDocuments\\( in **/*.{ts,tsx}

Tool results:

→ result (ok): No files found

Tools used:

• Grep: dmpApi\.search in /Users/USER/workspace/doctolib/doctolib

Tools used:

• Grep: findDocuments\( in /Users/USER/workspace/doctolib/doctolib

Tool results:

→ result (ok): Found 3 files packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.ts packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.test.ts packages/@doctolib/dmp/src/business/DmpApi.test.ts

Tool results:

→ result (ok): Found 4 files packages/@doctolib/dmp/src/business/DmpApi.ts engines/patient_request/app/assets/javascripts/components/patient/shared/modules/steps/QuestionnaireModule/QuestionnaireModule.tsx packages/@doctolib/dmp/src/business/FrDmpCommunication.ts packages/@doctolib/dmp-validation/src/components/DmpValidation/ValidationPage/commandHandlers.ts

Tools used:

• Grep: findDocuments\( in /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp-validation

Tool results:

→ result (ok): /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/dmp-validation/src/components/DmpValidation/ValidationPage/commandHandlers.ts-30- packages/@doctolib/dmp-validation/src/components/DmpValidation/ValidationPage/commandHandlers.ts-31-export const COMMAND_HANDLERS: Partial<Record<DmpCommand, CommandHandler>> = { packages/@doctolib/dmp-validation/src/components/DmpValidation/ValidationPage/commandHandlers.ts-32- hl_findDocuments: (sessionId, params) => packages/@doctolib/dmp-validation/src …(truncated, 678 more chars)

dmp-validation's findDocuments call-site takes raw params from a test harness (DMP validation page) — out of scope for this fix. The NHR adapter is the right place. The fix is correctly scoped to the new read path that wasn't previously wired.

I now have enough to produce a thorough review. I'll also briefly note that the commit message/changelog touches no CHANGELOG file in @doctolib/national-health-records. Let me see if that package maintains one.

Tools used:

• Bash: ls /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/ 2>&1 | head -20

Tool results:

→ result (ok): babel.config.cjs catalog-info.yaml CODEOWNERS.local i18n.json jest.config.cjs node_modules package.json src tsconfig.json

No CHANGELOG in that package — not a concern.

One last verification: the PR's package.json bump says "@doctolib/variation-management": "^1.4.3" matches the installed version (1.4.3) — good. But other packages in the monorepo pin ^1.0.0, ^1.3.0, ^1.4.0. Using ^1.4.3 requires that the test-helpers/jest + mockProductLineConfig + /environment + envIsProduction subpaths were all available from 1.4.3. That's true (we just confirmed the 1.4.3 package.json). Good.

Here are my findings.

Code Review: PR #240093 — FHIR-2209 (branch fhir-2209_fix-patient-ins-env-transformation)

Files reviewed

• /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/package.json
• /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.ts
• /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.test.ts
• /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/hooks/useNationalHealthRecords.ts
• /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/hooks/useNationalHealthRecords.test.ts
• /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/hooks/useSearchDocuments.ts
• /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/hooks/useSearchDocuments.test.ts
• /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/variants/useNhrDocumentListVariant.ts

Overall assessment

The fix is correct and well-scoped: - envIsProduction() is a valid detection function in @doctolib/variation-management/environment, returning true only when the page <head data-env="production"> is set. In every other env (development, staging, interf, preview, test, unknown) it returns false and the "T" suffix is applied — matching the behavior required by DMP sandbox ("bac à sable"). - buildFindDocumentsPayload in @doctolib/dmp passes ins through verbatim (no internal suffixing), so there is no double-append risk. All other write commands in @doctolib/dmp (sendDocument, deleteDocument, updateDocumentStatus) apply the same suffix via getPatientInsForDMP(patient) in frDmpPayloadBuilders.ts:53-56, so the read path (hl_findDocuments) is now consistent with the write path. - All three migrated import paths resolve against the installed @doctolib/<REDACTED>: - ./environment → envIsProduction - ./legacy → isFeatureEnabled, useProductLineVariation, ProductLineKey - ./legacy/test-helpers/jest → mockProductLineConfig (same (key: ProductLineKey) => void signature as the old mockProductLine) - The package.json now pins ^1.4.3, which is the lowest version where every subpath export (./environment, ./legacy/test-helpers/jest, ./environment/test-helpers/jest) is present.

I have only high-confidence quality findings below.

Important (confidence 80–89)

1. Reuse the existing getPatientInsForDMP helper or extract a shared applyInsEnvSuffix(ins) — don't duplicate the envIsProduction() ? '' : 'T' logic - Confidence: 85 - File: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.ts:40-44 - Detail: @doctolib/dmp already exports getPatientInsForDMP (see packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts:53 and the re-export at packages/@doctolib/dmp/src/index.ts:89). It contains the exact same branch: envIsProduction() ? '' : 'T'. The PR re-implements that branch inline in the NHR adapter, creating two source-of-truths that can drift. The commit message even says "matching the behavior of other DMP commands", which is the textbook case for sharing. Because getPatientInsForDMP takes a Patient object rather than a raw string, the cleanest option is to add and export a tiny primitive in @doctolib/dmp (e.g. applyInsEnvSuffix(ins: string): string) and have getPatientInsForDMP delegate to it; DmpNhrAdapter.toSearchProps then imports that primitive. The PR already adds a new cross-package dependency on @doctolib/variation-management/environment just to duplicate a helper, which is avoidable. - Suggested fix: introduce applyInsEnvSuffix in packages/@doctolib/dmp/src/business/frDmpPayloadBuilders.ts, export it from @doctolib/dmp, and replace both call sites. The NHR adapter then doesn't need a new direct dependency on @doctolib/variation-management.

2. Use the package's canonical Jest mocking helper (mockEnvironment from @doctolib/variation-management/environment/test-helpers/jest) instead of raw jest.mock + jest.requireActual - Confidence: 82 - File: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.test.ts:2-11 - Detail: The @doctolib/variation-management package ships a dedicated, documented Jest helper (mockEnvironment({ env: 'production' | 'staging' | ... }), clearEnvironmentMocks()) at ./environment/test-helpers/jest. Its JSDoc example (in node_modules/@doctolib/variation-management/dist/tests/environment/mock-environment.jest.js:38-58) is exactly this scenario. The helper also sets all sibling flags consistently (envIsStaging, envIsProduction, …), avoiding the risk of a test that exercises staging-only code paths accidentally leaving envIsProduction === false while a downstream envIsStaging assertion reads the unmocked live binding. The PR’s jest.mock('@doctolib/variation-management/environment', …) works because of ESM live bindings but is the non-idiomatic path — the rest of the PR already imports from ./legacy/test-helpers/jest, so using ./environment/test-helpers/jest is consistent. - Suggested fix: ```ts import { mockEnvironment, clearEnvironmentMocks } from '@doctolib/variation-management/environment/test-helpers/jest'

describe('DmpNhrAdapter', () => { afterEach(clearEnvironmentMocks)

it('should append "T" to ins in non-production environment', async () => {
  mockEnvironment({ env: 'staging' })
  // …
})

it('should not append "T" to ins in production environment', async () => {
  mockEnvironment({ env: 'production' })
  // …
})

})

`` This also removes the need for thejest.fn(() => false)default and themockEnvIsProduction` handle.

3. Missing clearEnvironmentMocks() / mock reset — env mock state leaks across tests - Confidence: 80 - File: /Users/USER/workspace/doctolib/doctolib/packages/@doctolib/national-health-records/src/business/adapters/DmpNhrAdapter.test.ts - Detail: The describe('DmpNhrAdapter') block does not declare beforeEach(jest.clearAllMocks) or any afterEach to reset mockEnvIsProduction. The test that sets mockEnvIsProduction.mockReturnValue(true) leaves the mock in that state for any subsequent test that doesn’t re-set it. Today this is masked only because every test that depends on env happens to re-set mockReturnValue(...) at its top — but any new test added below (e.g. "should return correctly transformed NhrDocumentSearchResult for empty documents") that omits the call will execute against stale state that depends on test ordering. Sibling test files in this same PR (useNationalHealthRecords.test.ts, useSearchDocuments.test.ts) correctly use jest.clearAllMocks() in beforeEach, so this file is inconsistent with the package’s own conventions. - Suggested fix: add beforeEach(() => { jest.clearAllMocks(); mockEnvIsProduction.mockReturnValue(false) }) (or adopt the mockEnvironment/clearEnvironmentMocks pattern from finding #2, which handles this automatically).

Nitpicks / informational (surfacing at 75; below the 80 threshold — sharing only because they’re directly adjacent to flagged items)

• The PR's branch contains 10+ …(truncated, 1249 more chars)