[Paul-AUB]

🤔 What

Use Node 24.22.1 for development, builds and CI. The root engines.node
defines supported release lines; .nvmrc pins the exact version used by CI.

🤷‍♂️ Why

The October Node.js security release
fixes vulnerabilities affecting the repository's development and build runtimes.
Azure previously built with Node 24.13.0, and cached CI / Cypress action runtimes
could also select older Node versions. The deployed application is a static SPA.

🔍 How

• Use .nvmrc in every Node workflow, including before release-version
  computation with npx. Keep the compatibility range in the root package only;
  the private web-app workspace no longer duplicates it.
• Remove the single-version lint and translation matrices. Preserve their check
  names and document their relationship to develop branch protection.
• Build Azure assets with the selected Node version, the repository's Yarn
  configuration and dependency cache, then upload dist/ with
  skip_app_build: true. Preserve the app-version and Turnstile build variables.
• Launch Cypress with npx --no-install under the selected Node runtime while
  retaining the existing browser / spec matrix.
• Document the update procedure and the separately maintained GitHub Actions
  and Cypress/Electron runtimes. Link version references to .nvmrc instead of
  duplicating the patch number in the README and badge.

🧪 Testing

• Node 24.22.1 immutable dependency installation; lockfile unchanged.
• Production build, including embedded version, PWA files and copied Azure
  configuration; built configuration matches the source.
• actionlint on the modified workflows.
• yarn lint --ignore-pattern '**/*.local/**': no errors. The exclusion
  skips existing local generated E2E builds. The CI lint job also passes.
• Full unit suite in CI. The initial run passed 225 files / 1,756 tests;
  the follow-up commit's unit job also passes.
• Initial Chrome and Firefox E2E matrix passed; Chrome passed all 114 tests
  and used Node 24.22.1. A local Cypress configuration/task smoke test also
  confirmed Node 24.22.1.
• Follow-up commit's full Chrome / Firefox E2E matrix.
• Azure deployment
  succeeds with Oryx build skipped and staticwebapp.config.json recognized.
• Live-preview HTTP assertions: HTML and direct-route fallback, nosniff,
  index / service-worker cache headers, immutable JS assets and manifest.
• Headless Firefox against the deployed preview: direct access to
  /ui/entrances, rendered page heading and successful reload. API calls
  mocked to avoid requests to the production backend.

📸 Previews

Azure preview

[ClemRz]

Suggestions (Should Consider)

• .github/workflows/azure-static-web-apps-orange-rock-0d4f87503.yml Merging into develop is a production release, and this changes the deploy from an Oryx build to a prebuilt upload (skip_app_build: true). The PR notes the Azure preview deployment is still unchecked. Consider confirming that the preview serves the app, that staticwebapp.config.json (navigationFallback, headers) is present in dist/, and that refreshing a client-side route works before merging.
• .github/workflows/azure-static-web-apps-orange-rock-0d4f87503.yml The install and build steps do not use cache: 'yarn' in setup-node, unlike the other workflows. This is correct but slower; consider adding it if deploy time matters.
• .github/workflows/test.yml command-prefix: '--no-install' relies on how cypress-io/github-action composes the npx command. The PR reports a headless Firefox smoke test, so this looks verified. Consider also checking the first CI E2E run in Chrome to confirm that Cypress resolves from the installed dependencies.
• package.json / packages/web-app/package.json The engines.node range ^24.22.1 || >=26.12.1 is now duplicated in two files and .nvmrc. The README documents this, which helps. Optionally, a small CI check could keep the three in sync.

Nitpicks (Optional)

• .github/workflows/lint.yml, translations.yml Hardcoding name: build (24) and check-translations (24) keeps the required-check names stable. A short note in the repo docs that they must match branch protection might help future edits.
• README.md The badge now reads 24.22.1_LTS and will need a manual update with each .nvmrc bump. Consider adding it to the update checklist in the new paragraph.

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://orange-rock-0d4f87503-1583.westeurope.azurestaticapps.net

[Paul-AUB]

Addressed the review in 7da0847:

• ✅ Fixed — Azure preview verification: the deployment succeeds, skips the Oryx build and recognizes staticwebapp.config.json. The built configuration matches the source. Live HTTP assertions verify the app HTML, navigation fallback, nosniff, index/service-worker cache headers and immutable JS assets. A headless Firefox smoke test renders /ui/entrances and successfully reloads it, with API calls mocked. Preview.
• ✅ Fixed — Azure now uses setup-node's Yarn cache and standard yarn install --immutable / yarn build commands. The repository's existing Yarn configuration selects its version; the workflow no longer repeats the release-file path.
• ✅ Fixed — Cypress verification: the initial CI run passed Chrome's 114 tests and the Firefox matrix with Node 24.22.1. The follow-up commit's full test workflow also passes.
• ✅ Fixed — Removed the duplicate engines.node from the private web-app workspace. The root package is the monorepo's compatibility declaration; .nvmrc is the exact CI/development pin. README documents the two files to update.
• ⏭️ Not fixed — No additional synchronization job was added: the duplicated workspace constraint has been removed, and the root compatibility range and exact .nvmrc pin intentionally serve different purposes. Keeping the existing configuration avoids another script/check to maintain.
• ✅ Fixed — README explains why build (24) and check-translations (24) stay stable and that renaming them requires coordinating the required checks on develop.
• ✅ Fixed — The Node badge and installation instructions link to .nvmrc instead of repeating its patch version. The update procedure no longer needs a separate badge edit.

The PR description now reflects the final implementation and completed validation. No additional dependencies or CI jobs were introduced.