Rhythm 2.0 Specifications

Appearance

CAP-PFM-INT-001Publish integration releases for eligible customers

Markdown

CAP-PFM-INT-001

Publish integration releases for eligible customers

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-INT-01
Exercised by
FAS-PFM-INT-01-01, FAS-PFM-INT-01-02, FAS-PFM-INT-01-03, FAS-PFM-INT-01-04
Key concepts
CON-PFM-INT-001
Actors
ACT-PFM-019, ACT-PFM-021
Related
CAP-PFM-INT-002, CAP-PFM-INT-004
Proved by
ATS-PFM-INT-001

Implementation

Executable suites
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

KindCapabilityProduct areaPlatformModuleIntegration access, customer extensions and shared workflow configurationRevision1

Read atservices-platform ad3f6a65macroservice-libraries 54536a44

Publish integration releases for eligible customers ​

Purpose ​

Rhythm makes validated provider releases available to the customers eligible to use them.

How It Works ​

An adapter pipeline submits a release and the place where it runs. Rhythm validates the package before adding its catalogue records. Staff decide which releases and customers are ready for the offer. Administrators then discover that offer through the Library. Published manifests give existing connections a stable description of provider behaviour. Corrections arrive as another release rather than a rewrite of that description. Provider accounts held by Rhythm use separate staff-managed secrets. Publication and availability are operated through direct requests while staff screens await their later milestone. The product should keep the distinction between validating a release and accepting it for customer use visible.

Relationships ​

  • Connects with explore the integrations available to a workspace through shared integration records.
  • Connects with maintain a verified provider account connection through shared integration records.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Contract validation precedes a release’s admission to the catalogue.Customers keep the published manifest their connection uses.Availability distinguishes public offers, named customers and Rhythm’s internal use.
Surfaces
apijob
Intent sources
services-platform:docs/milestones/INTG-M1-find-install-connect.md#D3services-platform:docs/milestones/INTG-M1-find-install-connect.plan.md#A5

Controls

38 controls apply, from the corpus control catalogue.

TC-AVL-001 TC-AVL-005 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-CHG-001 TC-CHG-002 TC-CHG-003 TC-CHG-004 TC-CHG-005 TC-CHG-006 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-CRY-004 TC-DAT-004 TC-IAM-001 TC-IAM-003 TC-IAM-006 TC-LOG-001 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-003 TC-PI-005 TC-SEC-001 TC-SEC-002 TC-SEC-003 TC-SEC-004 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
hq.integrations.publishapiglobal
hq.integrations.operateapiglobal

Business Rules

12 rules, 12 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Only an adapter’s own principal may register its integration key, except that Platform may register any key outside production; unauthorized registration is refused without writes.
proved by ATS-PFM-INT-001-01, TST-PFM-INT-563, TST-PFM-INT-582
permissionservicetest
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
02must prove
Proposed
Registration accepts a release only if its manifest fits the shared schemas, declares known capability majors and features, uses no newer contract package and matches its recomputed fingerprint; invalid releases leave no records.
proved by ATS-PFM-INT-001-02, ATS-PFM-INT-001-13, TST-PFM-INT-563, TST-PFM-INT-582
validationservicetest
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
03must prove
Proposed
First registration gives an integration internal availability until Rhythm changes the offer.
origin: services-platform:docs/milestones/INTG-M1-find-install-connect.md#D3
proved by ATS-PFM-INT-001-03, TST-PFM-INT-563
policyservicetest
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
04must prove
Proposed
Publication freezes a version’s manifest through deprecation and retirement; a changed fingerprint is refused, while identical registration preserves the version and may replace its deployment.
proved by ATS-PFM-INT-001-04, ATS-PFM-INT-001-13, TST-PFM-INT-562, TST-PFM-INT-563
invariantserviceobserved
services-platform:modules/integrations/services/persistence/integration-versions.ts:writeRegisteredVersion
05must prove
Proposed
Registration records deployment location, permits one active deployment per release and environment, and drains the deployment being replaced.
proved by ATS-PFM-INT-001-05, TST-PFM-INT-503, TST-PFM-INT-563
invariantservice, databasetest
services-platform:modules/integrations/tests/integration/services/registration/register-integration-version.integration.spec.js#drains the deployment it replaces
06must prove
Proposed
Authorized Rhythm staff move a validated version to published, a published version to deprecated and a deprecated version to retired, with every other transition refused.
proved by ATS-PFM-INT-001-06, ATS-PFM-INT-001-13
lifecycleapi, serviceobserved
services-platform:modules/integrations/services/persistence/integration-versions.ts:VERSION_TRANSITIONS
07must prove
Proposed
Retirement is refused while any customer has a non-disconnected connection pinned to that version.
proved by ATS-PFM-INT-001-07, ATS-PFM-INT-001-15
policyserviceobserved
services-platform:modules/integrations/services/persistence/integration-versions.ts:pinnedConnectionCount
08must prove
Proposed
A published release becomes current if it is newer than the current published release, or if the current release is absent or no longer published.
proved by ATS-PFM-INT-001-08
calculationserviceobserved
services-platform:modules/integrations/services/persistence/integration-versions.ts:moveCurrentVersionIfNewest
09must prove
Proposed
Rhythm staff choose public, internal or restricted availability; restricted grants replace the whole customer list, and supplying grants for another availability is refused.
origin: services-platform:docs/milestones/INTG-M1-find-install-connect.md#D3
proved by ATS-PFM-INT-001-09, ATS-PFM-INT-001-14, TST-PFM-INT-515
policyapi, servicetest
services-platform:modules/integrations/tests/integration/services/catalog/catalog.integration.spec.js#replaces the whole list of grants
10must prove
Proposed
The staff catalogue includes integrations of every availability with their versions, deployments and release notes; customer callers cannot read it.
proved by ATS-PFM-INT-001-10, TST-PFM-INT-489, TST-PFM-INT-515
permissionapitest
services-platform:modules/integrations/tests/e2e/integrations.e2e.spec.js#is refused Rhythm HQ’s catalog (403)
11must prove
Proposed
Rhythm staff list declared platform-secret purposes and versions without values, write only declared purposes and leave a security record for each write; customer administrators are refused.
proved by ATS-PFM-INT-001-11, TST-PFM-INT-486, TST-PFM-INT-534
permissionapi, servicetest
services-platform:modules/integrations/tests/e2e/credentials.e2e.spec.js#lists the integration’s declared secrets by name and version, never a value
12must prove
Proposed
Registration rejects external hosting, mismatched deployment principal, runtime or environment, duplicate capabilities and unsupported execution modes before saving the release.
proved by ATS-PFM-INT-001-12
validationserviceobserved
services-platform:modules/integrations/services/registration/register-integration-version.ts:registerIntegrationVersion

Scenarios

IdGivenWhenThenProvenance
01A test adapter release is deployed to development.Its pipeline registers a releasable version.The published version becomes current and its replacement deployment drains the earlier one.test
services-platform:modules/integrations/tests/integration/services/registration/register-integration-version.integration.spec.js#publishes the version
02A principal belongs to one provider adapter.It registers a different provider’s integration key.Registration refuses the request and saves no release records.test
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

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