---
id: TST-PFM-ELG-421
title: Eligibility definitions table checks
kind: integration
product_area: platform
module: eligibility
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/eligibility/tests/integration/db/eligibility-definitions.table.integration.spec.js
implements: []
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/integration/db/eligibility-definitions.table.integration.spec.js
    cases:
      - modules/eligibility/db/eligibility-definitions.table.ts
      - >-
        accepts a well-formed row with its defaults, so each refusal below is
        about the column it spoils
      - >-
        refuses a second definition with the same id in the tenant, by the
        primary key
      - accepts the same id in another tenant
      - 'refuses an id with a capital letter, by the configuration id check'
      - 'refuses an id with a hyphen, by the configuration id check'
      - 'refuses a UUID as an id, by the configuration id check'
      - >-
        refuses a reserved id and the system prefix, by the configuration id
        check
      - accepts a one-character id (negative control for the refusals above)
      - 'refuses a reuse scope outside the three, by the reuse check'
      - 'refuses a status outside the three, by the status check'
      - 'refuses a name longer than two hundred characters, by the name check'
      - 'refuses more than twenty tags, by the tags check'
      - 'refuses a definition that replaces itself, by the replacement check'
      - >-
        clears only the replacement, never the tenant, when the definition that
        replaces it is deleted
      - 'refuses a replacement in another tenant, by the replacement foreign key'
      - >-
        refuses a published version that does not exist, by the published
        version foreign key
      - 'refuses a tenant that does not exist, by the tenant foreign key'
      - >-
        refuses a blank name: the trigger nulls it and the column refuses the
        null
      - trims the text it stores and drops blank tags
      - sets the published version to null when that version is deleted
      - >-
        holds both tenants’ rows, read as the owner, so the confinement below is
        the policy’s doing
      - reads only the acting tenant’s definition
      - >-
        reads nothing at all with no tenant, so a statement outside a tenant
        fails closed
      - >-
        refuses a write for another tenant, by the policy rather than a
        predicate of ours
  - provenance: documented
    source: >-
      services-platform:modules/eligibility/tests/integration/db/eligibility-definitions.table.integration.spec.js:suite
      header
    note: >-
      The source header describes the verification boundary and declared
      substitutions.
proof_limit: >-
  No complete capability or feature scenario is mapped to this file; case-level
  ownership remains a coverage finding.
---

# Eligibility definitions table 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 file contains executable checks, but no complete scenario mapping is established here. Its source test titles identify the remaining mapping work.

## 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 exercises its real module dependencies and declares no test doubles. Its source header and imports identify the database, transaction and service boundaries it uses.

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