---
id: TST-PFM-ELG-435
title: Eligibility publish 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/services/governance/publish.integration.spec.js
implements:
  - ATS-PFM-ELG-004-02
  - ATS-PFM-ELG-004-03
  - ATS-PFM-ELG-004-08
  - ATS-PFM-ELG-004-09
  - ATS-PFM-ELG-004-12
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/services/governance/publish.integration.spec.js
    cases:
      - >-
        answers the first publish as version 1, published, superseding nothing
        and with no diff
      - publishes the next draft as version 2 and supersedes version 1
      - names version 2 as the definition’s published version
      - >-
        records the condition type the version uses, with the declaration’s
        version
      - 'records a follower’s reference by the definition’s id, following'
      - 'answers the diff against the version it replaced, as sentences'
      - >-
        answers how many plans the publish removed: the definition’s and its
        follower’s
      - removes the plan of the superseded version
      - removes the plan of a definition that follows the published version
      - >-
        keeps the plan of a definition that pins a version, which still names
        that version
      - records the publish with its versions and the size of its diff
      - >-
        names the actor, the tenant and the instant of the publish, from the
        execution
      - >-
        records every write to the definition in order: the create, the publish,
        the draft and the second publish
      - 'refuses a draft with a problem, naming its code, and leaves it a draft'
      - >-
        refuses a reference that follows a definition never published, as
        reference_missing
      - >-
        refuses a condition type of an application the tenant is not licensed
        for
      - refuses a definition with no draft
      - 'refuses a definition the tenant does not have, 404'
      - >-
        publishes version 1’s rule as version 3 with the rollback note,
        superseding version 2
      - answers the dependencies copied from version 1
      - records the rollback in the audit trail
      - publishes it once
      - >-
        refuses the loser with StaleObject naming the winner’s version and when
        it was published, not IllegalOperation
      - >-
        refuses a publish that read the draft before another person published
        it, inside its transaction, naming the winner
      - lets a draft that is still a draft through (negative control)
      - >-
        still says a definition has no draft when the last publish was this
        person’s own
  - provenance: documented
    source: >-
      services-platform:modules/eligibility/tests/integration/services/governance/publish.integration.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 publish 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.