--- id: TST-PFM-SEC-197 title: Registry publish unit checks kind: unit product_area: platform module: security revision: 2 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - modules/security/tests/unit/authorizer/registry-publish.spec.ts implements: - ATS-PFM-SEC-013-10 environment: mock implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 1 isolation: The suite owns its input fixtures and installed doubles. assertion_evidence: - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#publishing to the API registry - provenance: test source: 'services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#check' - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#passes a sound manifest, naming the release and what activation would change - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#reports the catalog’s own problems, which are blocking too - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#a manifest problem stops the check before the catalog is prepared - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#refuses a release already published with another checksum: a release is immutable - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#accepts the same release again when it is byte-for-byte the one published, so a re-run is safe - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#RegistryCheckFailed lists every problem in its message, for the deploy log - provenance: test source: 'services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#stage' - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#writes the row staged, with the checksum and the document’s own status set to staged - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#refuses a manifest that does not validate, before any write - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#answers a restage of the release that is already active as the success it is - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#writes nothing when the release that is already active is staged again, so it stays active - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#refuses to restage an active release whose manifest changed, because a release is immutable - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#refuses a release published with another checksum - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#staging twice is idempotent - provenance: test source: 'services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#activate' - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#commits the catalog first, then the active row, then flushes the authorizer cache - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#demotes the release that was active, so the partition never holds two - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#a failed catalog commit writes no active row: the deploy is not ready and the old release still rules - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#a failed flush is reported, not rolled back: cached slices expire within the authorizer’s TTL - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#refuses to activate a release that was never staged, and commits no catalog for it - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#refuses to activate a superseded release: publish it again instead - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#activating the release that is already active is idempotent - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#writes no row when the release is already the active one - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#flushes no authorizer cache when the release was already active, because nothing changed - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#a partition larger than one page - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#activates a release that sorts onto the third page, which one page of the query never reached - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#demotes the active release when it sorts below the first page, so the partition never holds two - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#liveRows answers every staged and active row of the partition, not the first page of them - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#the loader finds the active manifest where it sorts last in the partition - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#a stage the deploy never activated - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#supersedes every stage staged before the release being activated - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#leaves a stage staged after it alone, because that deploy is in flight - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#leaves the authorizer deciding on the active release and the stage in flight, and on nothing older - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#ignores a stage older than the active release before any activation has retired it - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#the partition’s limit - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#keeps the newest 20 superseded releases by when they were written, and deletes the rest - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#never deletes the active row or a staged one, however old - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#prunes a partition that takes several pages to read - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#activates the release even when every deletion fails: the deploy is not failed for a history row - provenance: test source: >- services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts#deletes nothing when the history is within the limit dependency_evidence: >- The production decision runs in-process. The suite substitutes registry reads where its dependency setup supplies them; those boundaries have no live-service proof here. evidence: - 'services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts' - >- Static review at the recorded source revision; executable results remain not-run and conformance remains not-verified. binding_note: >- Each binding names the scenario to which this file contributes assertions. A binding is not a recorded pass and does not extend the file’s dependency boundary. examiner: codex examined_at: '2026-10-23' final_text: OpenAI dependency_review: provenance: test source: 'services-platform:modules/security/tests/unit/authorizer/registry-publish.spec.ts' explicit_no_doubles: false identified_double_boundaries: - registry reads --- # Registry publish unit checks ## Verification Boundary The file evaluates production helpers with controlled inputs in-process. The assertion references identify the source checks for registry publish. ## What This Suite Proves The source assertions support the observations named in the bound scenarios. A scenario spanning multiple files must retain the other files’ contributions. ## What It Does Not Prove This examination does not run the suite. Passing behavior, deployed conformance and the behavior of substituted dependencies require separate execution evidence. ## Real Dependencies and Test Doubles The production decision runs in-process. The suite substitutes registry reads where its dependency setup supplies them; those boundaries have no live-service proof here. ## Must Not Be Doubled Keep the production helper, schema, matcher or declaration under examination real. Substituting the decision itself would remove the behavior the assertions exercise.