---
id: TST-PFM-ELG-413
title: Eligibility governance repairs checks
kind: api-lifecycle
product_area: platform
module: eligibility
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - modules/eligibility/tests/e2e/eligibility-governance-repairs.e2e.spec.js
implements:
  - ATS-PFM-ELG-001-08
  - ATS-PFM-ELG-004-05
  - ATS-PFM-ELG-007-10
  - ATS-PFM-ELG-007-12
  - ATS-PFM-ELG-009-04
environment: local
implementation_state: implemented
latest_result: not-run
conformance: not-verified
estimated_minutes: 5
isolation: Prepared local test database with suite-owned fixture keys and cleanup.
evidence:
  - provenance: test
    source: >-
      services-platform:modules/eligibility/tests/e2e/eligibility-governance-repairs.e2e.spec.js
    cases:
      - answers an ETag with the plan
      - >-
        answers 304 to its own tag while nothing changed (premise of the cases
        below)
      - >-
        answers a new tag, 200, when a definition the rule references is
        published
      - 'answers a new tag, 200, when the binding’s fail policy changes'
      - 'answers a new tag, 200, when the definition’s portal message changes'
      - 'refuses a draft with effective_from 2027-02-31, 400, naming the field'
      - 'accepts 2028-02-29, a day that exists (negative control)'
      - 'refuses a publish with effective_until 2027-04-31, 400, naming the field'
      - answers 400 InvalidRequest for a text
      - answers 400 InvalidRequest for a number
      - answers 400 InvalidRequest for a boolean
      - answers 400 InvalidRequest for a list
      - >-
        still reads an object: the one with no binding is refused in the
        evaluator’s own words (negative control)
      - >-
        lists them all when no limit is given (premise: there are at least
        three)
      - honours limit=2 and answers next_cursor
      - 'answers the following page from the cursor, without repeating a record'
      - pages a definition’s bindings narrowed to a consumer application as well
      - >-
        lists the bindings of exactly the records named, comma-separated, on the
        console route
      - lists them on the service-principal route too
      - pages a list of records with the keyset cursor
      - >-
        still lists one record named alone (negative control: the fourth record
        is not in the three)
      - 'answers 400 naming the limit for more than 100 values, on both routes'
      - accepts exactly 100 values (the boundary)
      - >-
        answers 404 for an unknown binding alone (premise: the case that already
        did)
      - >-
        answers 404 for an unknown binding with a definition_key, not an empty
        page
      - >-
        still answers an empty page for a definition with no decisions (negative
        control)
      - 'answers "consumer_ref is required" for a blank consumer_ref, 400'
      - 'answers "consumer_app is required" for a blank consumer_app, 400'
      - 'refuses min above max, naming the parameter'
      - 'refuses a default of the wrong type, naming the parameter'
      - 'refuses a default outside min and max, naming the parameter'
      - accepts a declaration that agrees with itself (negative control)
      - >-
        says "label is required" for a group label of spaces, not
        grammar_unsupported
      - says "label is required" for a subject slot label of spaces
      - accepts a label that has text (negative control)
      - 'says "name: is required" for a definition named with spaces, 400'
  - provenance: documented
    source: >-
      services-platform:modules/eligibility/tests/e2e/eligibility-governance-repairs.e2e.spec.js:suite
      header
    note: >-
      The source header describes the verification boundary and declared
      substitutions.
proof_limit: >-
  Only the named scenario checkpoints have a verified source binding; execution
  has not been attempted.
---

# Eligibility governance repairs checks

## Verification Boundary

This suite checks the module through real local service and database code at the entry points used by its test cases.

## What This Suite Proves

The mapped scenarios identify the capability and feature checkpoints this file exercises. The source test titles preserve the assertion-level evidence.

## What It Does Not Prove

Registration supplies no execution result or conformance decision. Checks beyond the file’s reachable assertions remain unverified, including production configuration.

## Real Dependencies and Test Doubles

The suite uses local integration fixtures. Signing, caches, provider responses or outbound delivery may be supplied by fixtures where the source declares a substitution. The source imports and suite header identify the exact dependencies.

## Must Not Be Doubled

The module behavior under assertion, transaction boundary and database constraint being checked remain real. Fixture setup cannot stand in for the asserted write or refusal.