# 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.