pedwfrontend/lib/domain/representation-policy

Representation Entry Policy Boundary

Purpose

This directory contains a narrow representation entry policy boundary.

It currently owns only behaviour-preserving extracted entry-policy helpers.

It is not a full representation domain model.

This boundary should be treated as a small refactor seam for read-only entry-policy interpretation, not as a place to redesign representation behaviour.

Current ownership

resolveRepresentationWindow(...)

• current general representation window resolution
• preserves current start/end field usage for the extracted general window path
• does not define full representation entry policy

isRepresentationWindowOpen(...)

• current inclusive date-window open check
• preserves current date semantics used by extracted consumers

isRepresentationWindowClosed(...)

• current date-window closed check
• preserves current date > start && date > end semantics

canShowRepresentationButtonForAppealType(...)

• current appeal-type exclusion list only
• preserves current excluded IDs
• preserves current permissive unknown behaviour
• preserves current string/number coercion behaviour

canStartHouseholderRepresentation(...)

• current Householder LPA-only entry rule only
• preserves current truthy/falsy LPA handling
• does not infer LPA from CRM fields

canStartCpoRepresentation(...)

• current CPO entry rule only
• preserves current pinswg_startdate → pinswg_statementduedate behaviour
• does not broaden to other start-date variants

Explicit non-goals

This boundary does not currently own:

• ROW entry extraction
• Advert entry extraction
• blocked-message rendering
• CTA label selection
• consultation entry policy
• representation type options
• capacity rules
• submission/finalisation rules
• upload logic
• dashboard/worklist grouping
• CRM/OData queries
• API routes
• Redux state
• translations / EN-CY text

CRM compatibility requirements

Both specialist-process fields may exist and must be handled carefully:

• pinswg_specialistcaseprocess
• pinswg_speacialistcaseprocess

The misspelled field exists because of historical CRM schema/data and must not be removed casually.

Start-date variants also exist and must not be normalized unless explicitly characterized:

• pinswg_startdate
• pinswg_startdates
• pinswg_applicationacceptedasvalid

Future slices must treat field compatibility as behavior-sensitive.

Known divergences

ROW 846040015

Summary consumer (components/case/summary/utils/representationEntry.js):

• uses only pinswg_specialistcaseprocess in the ROW branch
• if only pinswg_speacialistcaseprocess exists, it falls through to non-hearing behaviour
• result can be allowed where search would be date-gated

Search consumer (components/search/repsonresults.js):

• uses normalized canonical/misspelled specialist-process fallback
• if misspelled field contains hearing value 846040001, hearing/date gate applies

Also:

• ROW hearing uses pinswg_startdate → pinswg_finalcommentsduedate
• ROW does not currently use pinswg_startdates or pinswg_applicationacceptedasvalid
• string appeal type "846040015" falls through to default allowed behaviour

Advert 846040018

Summary consumer (components/case/summary/utils/representationEntry.js):

• reads only pinswg_speacialistcaseprocess
• ignores canonical-only specialist process values in the Advert branch

Search consumer (components/search/repsonresults.js):

• uses normalized specialist process fallback
• canonical field takes precedence when both fields exist

Also:

• written reps 846040000 is LPA-only
• hearing 846040001 is allowed for LPA and non-LPA
• other specialist process values are blocked
• Advert is not date-gated today
• string appeal type "846040018" falls through to default allowed behaviour

Behaviour-preservation invariants

Future slices must preserve:

• current consumer-specific divergence unless an explicit behaviour-change decision is made
• current string/number appeal type handling
• current specialist-process field precedence where present
• current start-date field usage
• current permissive unknown behaviour
• current CTA/rendering behaviour

Future extraction guidance

Do not extract ROW or Advert helpers until product/CRM decision confirms whether to preserve divergence or standardize behaviour.

If preserving divergence:

• helper contracts must support consumer-specific mode explicitly

If standardizing behaviour:

• it must be treated as a behaviour change, not a refactor

The next safe work is likely blocked/suppression rendering characterization, not extraction.