# Tech Context — PEDW FrontEnd

## Languages and framework

- JavaScript-first codebase (TypeScript tooling present).
- Next.js `^14.2.28` with Pages Router.
- React `^18.2.0`.

## Core libraries in active use

- Auth: `next-auth` + Prisma adapters.
- Data/state: `redux`, `react-redux`, `next-redux-wrapper`, `redux-persist`, `redux-thunk`, `redux-form`.
- Data access/integration: `axios`, `crypto-js`, `jsonpath-plus`.
- i18n: `next-translate`, locale config in `i18n.js`.
- Storage/infrastructure integrations: `@azure/storage-blob`, `@azure/storage-queue`, `@azure/identity`.
- Notifications/telemetry: `notifications-node-client` (GOV.UK Notify), `applicationinsights`.
- PDF/maps: `@react-pdf/renderer`, `react-pdf`, `leaflet`, `react-leaflet`, `google-map-react`.

## Runtime and configuration

- Standard app start script uses Next runtime (`npm start`).
- Additional custom server entries exist (`server.js`, `server/server.js`) but are currently treated as non-active for the refactor baseline unless deployment evidence indicates otherwise.
- Environment-driven config for auth, relay/API roots, hash key, notify key, and database URL.

### Relay forwarding hardening policy knobs (P2-S3)

- Shared relay middleware now enforces centralized timeout/retry behavior for relay-backed GET flows.
- Supported env knobs:
    - `RELAY_TIMEOUT_MS` (default `8000`, clamped `100..30000`)
    - `RELAY_RETRY_MAX` (default `2`, clamped `0..4`)
    - `RELAY_RETRY_BASE_DELAY_MS` (default `200`, clamped `0..5000`)
    - `RELAY_RETRY_MAX_DELAY_MS` (default `1200`, clamped `0..5000`)
- Retry classification:
    - retryable: `408`, `429`, `5xx`, selected transient transport errors
    - non-retryable: deterministic client/auth statuses (`400`, `401`, `403`, `404`, `422`) and other explicit non-retryable HTTP statuses
- Logging behavior:
    - structured redacted relay events emitted for retry/failure
    - duplicate endpoint-layer error logging suppressed when relay layer already emitted terminal failure log

## Tooling and quality gates

- Linting: `npm run lint` (`next lint`).
- Formatting conventions from `.prettierrc`: 4 spaces, no trailing commas.
- Prisma client generation script available: `npm run prisma:generate`.

## Current domain documentation status

- Representation Participation Availability has now been documented as a first-class technical domain characterization.
- Technical source-of-truth:
    - `docs/representation-participation-availability.md`
- Business validation companion:
    - `docs/representation-participation-business-review.md`
- Current architectural conclusion:
    - representation participation is best understood as one coherent decision model with layered exceptions
    - known consumer divergences and CRM compatibility behaviours are part of the current live contract
    - future technical adoption/expansion work should wait for business validation before changing behaviour or broadening policy boundaries
- CRM Case Progress Display investigation has now been concluded as a technical characterization stream.
- Current technical conclusion:
    - the Case Status tab is a portal-owned journey interpretation layer
    - active inputs are CRM `statuscode`, appeal type, and Rights of Way specialist-process routing only
    - `pinswg_casestage` is not a significant active input to status-tab lifecycle resolution
    - stage catalogues are not raw CRM lifecycle states and not business-policy decision models
    - stage catalogues are best understood as user-facing journey models plus appeal-type interpretation plus presentation-layer progress visualization
    - shared catalogue families (`PLANNING_S78`, `ENFORCEMENT`, `DNS/SIP`, Rights of Way specialist-process variants) reflect a mixture of shared journey semantics, presentation reuse, and historical consolidation
    - this area is not currently a candidate for a new business-policy domain boundary

## CI/CD and deployment artifacts

- `azure-pipelines.yml` exists (legacy-looking Node 10 build pipeline).
- `Jenkinsfile` exists (Node 20 + Docker build/push/deploy flow).
- `Dockerfile` exists (Node 20 Alpine runtime).
- Repository contains mixed deployment artifacts; active production path should be treated as environment-dependent unless confirmed.

## Local development workflow

- `npm install`
- `npm run dev`
- `npm run lint`
- `npm run build && npm start` for production-like verification