Robert Bond
0de9268255
## Summary This PR merges the completed new-appeal refactor stream (Slices 1–8) into SIPS-Development. This refactor was executed in controlled slices with regression validation at each step. ## Scope Structural and readability improvements only: - XML/form derivation extraction - payload and file helper extraction - side-effect facade introduction - BuildSection and BuildCheckSection decomposition - BuildCheckRow formatter map refactor - nested prop boundary cleanup - start-flow cleanup (CreateCase / AboutYou) ## Behaviour No intended behavioural changes. The following were explicitly preserved: - S78 journey behaviour - payload shapes and field names/ids - HASCAS mapping logic - appellant/agent branching - validation rules and messages - redirect/query parameters (`lpa`, `apt`, `id`) - navigation and side-effect sequencing - EN/CY output parity ## Validation Full regression has been performed on: - start flow (CreateCase / AboutYou) - save and resume flows - file upload handling - check answers rendering - submit/finalisation sequence - confirmation flow - CRM insertion path - EN/CY parity Additional checks: - docsOffline branch behaviour - completion and partial-save email paths - negative-path validation scenarios - lint (warnings baseline unchanged) ## Risk Low: - changes are structural only - no business logic changes - no contract changes ## Rollback Safe rollback via reverting this merge commit. ## Notes This refactor reduces coupling and prepares the new-appeal flow for future appeal-type expansion. Related work items: #22570, #22576, #22577, #22583, #22586, #22587, #22588, #22590
2.3 KiB
2.3 KiB
AI Context — PEDW FrontEnd
Overview
PEDW FrontEnd is a Next.js 14 (Pages Router) bilingual (EN/CY) public-service portal for planning case search, case detail/document viewing, and authenticated portal workflows (appeals, representations, watchlists, dashboard views).
Architecture
- Monorepo-style Next.js app with UI routes in
pages/and API handlers inpages/api/**. - Redux (
next-redux-wrapper+redux-persist) for shared client/server state. next-authfor auth/session with Prisma adapter.- Integration-heavy BFF pattern: API routes proxy to relay/CRM and storage/notify services.
Key components
components/breadcrumbs.js: central breadcrumb/back-link behavior.components/case/summary.js: case-detail tabs, representation eligibility logic, watch/email actions.actions/index.js: shared API utilities, token/header/hash helpers, many side-effect wrappers.pages/api/endpoint/**: relay-backed business-data APIs.pages/api/file/**: blob/document/PDF/upload endpoints.
Data model boundaries
- Prisma (
prisma/schema.prisma) stores auth/session entities only (User,Account,Session,VerificationToken) on SQL Server. - Business/case data is external (Dynamics/relay path), not persisted as Prisma domain models here.
API/integration patterns
- Many endpoint handlers compute HMAC hash query params (
hash) for relay-bound requests. - Token acquisition + OData headers are reused across proxy handlers.
- File endpoints often validate request hash for sensitive blob actions.
- GOV.UK Notify used for email, including language-specific template selection in some flows.
Infrastructure/tooling
- Scripts:
npm run dev,npm run build,npm start,npm run lint. - CI/CD artifacts present:
azure-pipelines.yml,Jenkinsfile,Dockerfile(active production source-of-truth not explicit in repo). - Security controls:
middleware.jsCSP/runtime headers +next.config.jssecurity headers.
Development constraints
- Preserve auth/session behavior in
pages/api/auth/[...nextauth].js. - Do not weaken CSP/security headers in
middleware.jsornext.config.js. - Keep EN/CY parity across routes and locale resources (
i18n.js,locales/**, rewrites). - Treat relay hash behavior as security-sensitive; keep path/hash compatibility stable.
- Avoid logging secrets/personal data in auth/email/file/account flows.