pedwfrontend/memory-bank/productContext.md

Product Context — PEDW FrontEnd

Primary user workflows

1. Public discovery

   • Search planning cases (basic, advanced, address, DNS).
   • Open case summary pages and review documents/history.

2. Authenticated portal (/myportal/**)

   • Sign in via magic-link email.
   • View dashboards/worklists (my cases, watched cases, awaiting submission, representations).
   • Start or continue appeal/representation submission flows.

3. Role-shaped behavior

   • General users can create appeals and representations.
   • LPA users get authority-scoped views and representation actions; raise-appeal behavior is restricted.

Core domain concepts

• Case / Incident: core planning entity shown in search, detail, and portal journeys.
• Appeal type: controls collection/field behavior and some UI logic.
• Representation window: date-gated period controlling whether representation actions are available.
• Watched case / email notifications: user subscriptions to case changes.
• DNS: Developments of National Significance-specific journey and pages.

Business logic patterns visible in code

• Case summary UI varies by appeal type and case attributes.
• Case status/progress display is portal-shaped rather than a raw CRM passthrough: the portal selects a journey catalogue from CRM statuscode, appeal type, and limited Rights of Way specialist-process input to present user-facing progress.
• Representation actions are conditionally shown by appeal type, role, and date windows.
• Representation participation now appears to form one broader business decision model: whether a participant can engage in representation or consultation activity for a case at that point in the process.
• Locale-sensitive behavior affects links, routes, labels, and email template choice.
• New-case-reference notifications include preferred-language checks before template selection.

Current representation participation state

• Technical discovery/documentation for Representation Participation Availability is complete.
• The current behaviour is best understood as a coherent participation-availability policy with layered appeal-type, process-type, participant-type, consultation, and date-window exceptions.
• Business validation is still required before any further representation-policy adoption, expansion, or behavioural change work.
• Reference documents:
  • docs/representation-participation-availability.md
  • docs/representation-participation-business-review.md

Current case progress display state

• Technical investigation for CRM Case Progress Display is complete.
• Current behaviour is best understood as a user-facing journey representation, not a business-policy decision model.
• The Case Status tab is driven by:
  • CRM statuscode
  • appeal type
  • specialist process for Rights of Way variants only
• pinswg_casestage should not currently be treated as a significant input to status-tab lifecycle behaviour.
• Shared catalogue families exist and reflect a mixture of:
  • genuine shared journey structures
  • presentation reuse
  • historical consolidation

Likely next discovery candidate

• No immediate successor discovery candidate is implied by the completed CRM Case Progress Display stream.
• If reopened later, work should focus on business validation or future behavioural change questions rather than first-pass technical characterization.

Important user-facing behaviors

• Welsh route aliases are mapped in next.config.js and must remain in sync with page behavior.
• Breadcrumb/back-navigation behavior is actively maintained across search -> case -> portal routes.
• Document visibility/download flows are central to case transparency and must remain stable.