80 lines
4.3 KiB
Markdown
80 lines
4.3 KiB
Markdown
# 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
|