---
id: TST-PFM-SEC-196
title: Registry manifest 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-manifest.spec.ts
implements:
  - ATS-PFM-SEC-015-05
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-manifest.spec.ts#the API
      registry manifest
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#accepts the
      manifest the fixtures publish
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#the
      checksum is over the canonical JSON and ignores the status, so staging and activating agree
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      checksum that does not match the content
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      document that is not a manifest at all
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      document for another service or stage
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses the
      same (method, path) twice
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      route key the manifest’s own catalog does not define, whichever app it belongs to
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      catalog key of an app the service does not ship, when the caller states which apps it ships
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#accepts a
      catalog of two apps the service ships, which is what a staff application is
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#accepts
      another app’s key where the route only evaluates it, which is how a handler asks about that
      app
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses
      another app’s key in the any list, which the route would be allowed by
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses
      another app’s evaluated key that is not a permission key at all
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses
      this app’s own evaluated key when the catalog does not declare it
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#scopes a
      route by its required keys alone, so an evaluated key of another resource type is no mix
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      route key the catalog does not declare
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      catalog key without a tier, which is what makes a sensitive key a reviewed decision
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      route that mixes resource types
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      protected route that requires nothing, and a public route that requires something
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      staffOnly key below a system route
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      system route required by an ordinary key, which a customer administrator could hold
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#accepts an
      EVALUATED ordinary key on a system route, which the route is not allowed by
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a
      resource declaration no key is scoped by
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#collects
      every problem at once, so a deploy is told all of them
  - provenance: test
    source: 'services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#helpers'
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#requirementKeys
      unions the all, any and evaluates lists without duplicates
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#permissionMatches
      matches a whole segment at a time and never part of one
  - provenance: test
    source: >-
      services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#the fixture
      catalog is itself valid
dependency_evidence: >-
  The production decision runs in-process. The suite substitutes message delivery where its
  dependency setup supplies them; those boundaries have no live-service proof here.
evidence:
  - 'services-platform:modules/security/tests/unit/authorizer/registry-manifest.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-manifest.spec.ts'
  explicit_no_doubles: false
  identified_double_boundaries:
    - message delivery
---
# Registry manifest unit checks

## Verification Boundary

The file evaluates production helpers with controlled inputs in-process. The assertion references identify the source checks for registry manifest.

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