Rhythm 2.0 Specifications

Appearance

ATS-PFM-INT-001Publish integration releases for eligible customers: Capability Test Specification

Markdown

ATS-PFM-INT-001

Publish integration releases for eligible customers: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-INT-001

Design

Executed by
TST-PFM-INT-486, TST-PFM-INT-489, TST-PFM-INT-503, TST-PFM-INT-515, TST-PFM-INT-534, TST-PFM-INT-562, TST-PFM-INT-563, TST-PFM-INT-582

KindAcceptance test setProduct areaPlatformModuleIntegration access, customer extensions and shared workflow configurationRevision3

Read atservices-platform ad3f6a65macroservice-libraries 54536a44react-console baf6dae3

Publish integration releases for eligible customers: Capability Test Specification ​

Coverage ​

RuleProved By
BR-CAP-PFM-INT-001-01ATS-PFM-INT-001-01
BR-CAP-PFM-INT-001-02ATS-PFM-INT-001-02, ATS-PFM-INT-001-13
BR-CAP-PFM-INT-001-03ATS-PFM-INT-001-03
BR-CAP-PFM-INT-001-04ATS-PFM-INT-001-04, ATS-PFM-INT-001-13
BR-CAP-PFM-INT-001-05ATS-PFM-INT-001-05
BR-CAP-PFM-INT-001-06ATS-PFM-INT-001-06, ATS-PFM-INT-001-13
BR-CAP-PFM-INT-001-07ATS-PFM-INT-001-07, ATS-PFM-INT-001-15
BR-CAP-PFM-INT-001-08ATS-PFM-INT-001-08
BR-CAP-PFM-INT-001-09ATS-PFM-INT-001-09, ATS-PFM-INT-001-14
BR-CAP-PFM-INT-001-10ATS-PFM-INT-001-10
BR-CAP-PFM-INT-001-11ATS-PFM-INT-001-11
BR-CAP-PFM-INT-001-12ATS-PFM-INT-001-12

Release registration, customer discovery and installation meet at the catalogue boundary. The interaction cases follow a changed offer through existing adoption and a fresh installation attempt, keeping retained customer records separate from eligibility for new use.

The structured scenarios name the capabilities and rules involved. A bound test contributes only the outcomes it asserts; proposed transition matrices and composed interactions still require executable proof.

Coverage

  • Rule covered
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge covered
  • Failure gap: FND-PFM-INT-052
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

15 scenarios proving CAP-PFM-INT-001; 8 bound to an existing test.

01 Cross-provider release registration is refusedpermissionapinegativetest
Proves
BR-CAP-PFM-INT-001-01
Preconditions
Two adapter principals and a registered non-adapter service are available.
Steps
Attempt registration for another adapter, from a non-adapter service and from Platform in production and development.
Expected
Foreign and non-adapter principals receive access denial, Platform is refused in production and admitted in development, and refused requests save nothing.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/registration/register-integration-version.integration.spec.js#refuses an adapter principal registering another adapter’s key (403), and writes nothing
02 Invalid release descriptions leave no partial registrationvalidationapinegativetest
Proves
BR-CAP-PFM-INT-001-02
Preconditions
Prepare a valid release from the test adapter.
Steps
Alter the fingerprint, capability major, feature, contract-package version and manifest shape independently.
Expected
Each invalid package reports its problem without creating definition, version or capability records.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/registration/register-integration-version.integration.spec.js#refuses a hash that is not the manifest’s, and writes nothing
03 First registration remains internalruleapitest
Proves
BR-CAP-PFM-INT-001-03
Preconditions
The test adapter has no catalogue definition.
Steps
Register its initial release.
Expected
A new internal definition exists and is absent from customer catalogues.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/registration/register-integration-version.integration.spec.js#creates the definition by its key, internal until Rhythm offers it
04 Published manifests survive conflicting registrationinvariantapinegativetest
Proves
BR-CAP-PFM-INT-001-04
Preconditions
The adapter version is already published.
Steps
Register that version with a changed fingerprint, then submit the original manifest.
Expected
The change conflicts and preserves the published fingerprint; the identical version remains the sole unchanged version.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/registration/register-integration-version.integration.spec.js#refuses a published version registered again with another hash (409), and keeps the published hash
05 Replacement deployments drain their predecessorconcurrencyapitest
Proves
BR-CAP-PFM-INT-001-05
Preconditions
A registered release has an active deployment.
Steps
Register another deployment, then attempt a direct second active deployment in that environment.
Expected
Replacement drains the old deployment; the database rejects simultaneous active deployments for the same release and environment.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/registration/register-integration-version.integration.spec.js#drains the deployment it replaces
06 Version lifecycle refuses skipped statestransitionapinegativeproposed
Proves
BR-CAP-PFM-INT-001-06
Preconditions
Begin with a validated release.
Steps
Attempt direct retirement, then publish, deprecate and retire in order.
Expected
Skipped retirement reports the invalid state; permitted transitions save their timestamps.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Source
services-platform:modules/integrations/services/persistence/integration-versions.ts:VERSION_TRANSITIONS
07 Pinned releases remain availableedgeapinegativeproposed
Proves
BR-CAP-PFM-INT-001-07
Preconditions
A deprecated release still serves an active workspace connection.
Steps
Attempt retirement, disconnect the connection and request retirement again.
Expected
Retirement first reports its dependent connection count and succeeds when that count reaches zero.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Source
services-platform:modules/integrations/services/persistence/integration-versions.ts:pinnedConnectionCount
08 Publication updates the current release correctlyruleapiproposed
Proves
BR-CAP-PFM-INT-001-08
Preconditions
An integration has a published earlier release and a validated newer release.
Steps
Publish the newer release, then attempt publication of an older validated release; repeat with the current release deprecated.
Expected
The newer publication becomes current; an older publication does not replace a still-published current release, but can replace a deprecated current release.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Source
services-platform:modules/integrations/services/persistence/integration-versions.ts:moveCurrentVersionIfNewest
09 Availability grants replace the customer audienceboundaryapitest
Proves
BR-CAP-PFM-INT-001-09
Preconditions
A published integration can be offered to customers.
Steps
Restrict it to one workspace, replace that grant list and submit grants with public availability.
Expected
Restricted grants match the replacement list, and public availability refuses a customer grant list.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/catalog/catalog.integration.spec.js#replaces the whole list of grants
10 Staff catalogue rejects customer callerspermissionapinegativetest
Proves
BR-CAP-PFM-INT-001-10
Preconditions
A staff operator and a workspace administrator are authenticated.
Steps
Read the staff catalogue with each identity.
Expected
The operator receives definitions, versions and deployments regardless of availability; the customer receives access denied.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/e2e/integrations.e2e.spec.js#is refused Rhythm HQ’s catalog (403)
11 Staff secrets remain write-onlypermissionapinegativetest
Proves
BR-CAP-PFM-INT-001-11
Preconditions
The integration declares a platform-secret purpose.
Steps
List its secret facts, replace the secret, write an undeclared purpose and repeat as a customer administrator.
Expected
Only purpose and version facts return; a valid write is audited without its value, and undeclared purposes and customer writes refuse.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/e2e/credentials.e2e.spec.js#lists the integration’s declared secrets by name and version, never a value
12 Deployment metadata is validated before registrationvalidationapinegativeproposed
Proves
BR-CAP-PFM-INT-001-12
Preconditions
Prepare a valid adapter manifest and deployment.
Steps
Change its principal, runtime and environment, request external hosting, duplicate a capability and declare an incompatible execution mode.
Expected
Every altered declaration is rejected with its cause and leaves release records unchanged.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Source
services-platform:modules/integrations/services/registration/register-integration-version.ts:registerIntegrationVersion
13 Exercise the complete integration release lifecycletransitionapinegativeproposed
Proves
BR-CAP-PFM-INT-001-02 BR-CAP-PFM-INT-001-04 BR-CAP-PFM-INT-001-06
Preconditions
Prepare one independent record in each starting state, including absent-record cases where the model defines creation.
Steps
Run each listed transition once with its guard satisfied, then repeat it with the guard denied. Inspect the resulting record and listed side effects after commit.
Expected
Each positive case reaches its listed destination and records its defined side effects. Each denied case preserves the starting record and creates no transition side effects.
Data
Run-owned records and principals in an isolated workspace.
Source
rhythm-v2-docs:specs/platform/integrations/design/state-models/STATE-PFM-INT-001-integration-release-lifecycle.md#transitions
14 A changed audience changes discoveryinteractionapiproposed
Proves
BR-CAP-PFM-INT-001-09 BR-CAP-PFM-INT-002-01
Preconditions
A published offer is public and two workspaces can see it.
Steps
Restrict the offer to the first workspace, replace the grant with the second, and read both catalogues after each change.
Expected
Only the currently granted workspace sees the offer; direct reads from the other workspace report absence.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:modules/integrations/tests/integration/services/catalog/catalog.integration.spec.js#replaces the whole list of grants,services-platform:modules/integrations/tests/integration/services/catalog/catalog.integration.spec.js#shows a restricted integration only to the tenant granted it
15 Connection pins constrain release retirementinteractionapiproposed
Proves
BR-CAP-PFM-INT-001-07 BR-CAP-PFM-INT-004-10
Preconditions
A deprecated release has a verified connection pinned to it and a newer published release is available.
Steps
Attempt retirement, verify a move to the newer release, then attempt retirement again.
Expected
The first retirement identifies the dependency; after the successful move the old release can retire.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:modules/integrations/services/persistence/integration-versions.ts:pinnedConnectionCount,services-platform:modules/integrations/services/connections/connection-operations.ts:requestVersionUpdate

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software