--- id: FAS-PFM-INT-01 title: Integration offers and adoption acceptance feature: FEAT-PFM-INT-01 product_area: platform module: integrations revision: 2 status: proposed product_intent: proposed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f capabilities: - CAP-PFM-INT-001 - CAP-PFM-INT-002 - CAP-PFM-INT-003 scenarios: - id: FAS-PFM-INT-01-01 title: Discover and adopt an eligible offer kind: behaviour exercises: - CAP-PFM-INT-001 - CAP-PFM-INT-002 - CAP-PFM-INT-003 relies_on: - ATS-PFM-INT-001-03 - ATS-PFM-INT-002-01 - ATS-PFM-INT-003-02 preconditions: A validated provider can publish and a workspace administrator can adopt it. steps: 'Publish and offer the release, inspect provider detail, choose declared access and install.' expected: The visible offer becomes one enabled installation with the selected access. negative: false data_needs: 'Run-owned declarations, records and role fixtures in an isolated workspace.' bound_to: [] provenance: proposed 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 - >- services-platform:modules/integrations/tests/integration/services/catalog/catalog.integration.spec.js#shows a restricted integration only to the tenant granted it - >- services-platform:modules/integrations/tests/integration/services/installations/installation-lifecycle.integration.spec.js#refuses an acceptance wider than the manifest declares, naming it, and writes nothing - id: FAS-PFM-INT-01-02 title: Audience changes preserve existing adoption kind: interaction exercises: - CAP-PFM-INT-001 - CAP-PFM-INT-002 - CAP-PFM-INT-003 relies_on: - ATS-PFM-INT-001-09 - ATS-PFM-INT-002-04 - ATS-PFM-INT-003-01 preconditions: Two workspaces can see a public offer and one already adopts it. steps: >- Restrict the offer away from that workspace, read its saved installation and attempt adoption from an ungranted workspace. expected: The saved installation remains readable while new adoption is refused. negative: false data_needs: 'Run-owned declarations, records and role fixtures in an isolated workspace.' bound_to: [] provenance: proposed 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/installations/narrowed-availability.integration.spec.js#stays readable to the tenant that holds it: the installation, the connection and their lists answer, and the catalog entry stays hidden - >- services-platform:modules/integrations/tests/integration/services/installations/installation-lifecycle.integration.spec.js#refuses an integration installed already, and writes no second - id: FAS-PFM-INT-01-03 title: Release governance and retained adoption kind: lifecycle exercises: - CAP-PFM-INT-001 - CAP-PFM-INT-002 - CAP-PFM-INT-003 relies_on: - ATS-PFM-INT-001-06 - ATS-PFM-INT-003-07 preconditions: The installation has no connected accounts and its release is published. steps: 'Uninstall, deprecate and retire the unused release, then read adoption history and the catalogue.' expected: The installation history remains and the retired release is not offered for a new installation. negative: false data_needs: 'Run-owned declarations, records and role fixtures in an isolated workspace.' bound_to: [] provenance: proposed source: - >- services-platform:modules/integrations/services/persistence/integration-versions.ts:VERSION_TRANSITIONS - >- services-platform:modules/integrations/tests/integration/services/connections/disconnect-discard-uninstall.integration.spec.js#is refused while a connection is not disconnected, naming each by id, name and status - id: FAS-PFM-INT-01-04 title: Readers and staff have distinct acceptance boundaries kind: permission exercises: - CAP-PFM-INT-001 - CAP-PFM-INT-002 - CAP-PFM-INT-003 relies_on: - ATS-PFM-INT-001-10 - ATS-PFM-INT-002-05 - ATS-PFM-INT-003-11 preconditions: 'A reader, manager, Rhythm operator and unrelated workspace administrator are available.' steps: >- Inspect customer and staff catalogues and attempt installation changes with each appropriate and inappropriate identity. expected: >- Readers can inspect, managers can adopt, staff access remains separate and foreign workspace writes are refused. negative: true data_needs: 'Run-owned declarations, records and role fixtures in an isolated workspace.' bound_to: [] provenance: proposed source: - >- services-platform:modules/integrations/tests/e2e/integrations.e2e.spec.js#is refused Rhythm HQ’s catalog (403) - >- react-console:lib/integrations/access.test.ts#shows a reader every screen, with no change control and no secret - >- services-platform:modules/integrations/tests/e2e/reader-access.e2e.spec.js#is refused every tenant route of this tenant, by id as by list (403) - id: FAS-PFM-INT-01-05 title: Install from reviewed provider detail kind: regression exercises: - CAP-PFM-INT-002 - CAP-PFM-INT-003 relies_on: - ATS-PFM-INT-002-03 - ATS-PFM-INT-003-02 preconditions: An eligible Dummy offer is not installed in the run-owned workspace. steps: >- Open provider detail, clear two capability choices, enter valid settings and install through the console. expected: The saved adoption has exactly the chosen access and settings and allows account setup. negative: true data_needs: 'Run-owned declarations, records and role fixtures in an isolated workspace.' bound_to: [] provenance: proposed source: - >- services-platform:modules/integrations/tests/integration/services/catalog/catalog.integration.spec.js#answers the contracts the version implements, with their schemas and feature meanings - >- services-platform:modules/integrations/tests/integration/services/installations/installation-lifecycle.integration.spec.js#refuses an acceptance wider than the manifest declares, naming it, and writes nothing evidence: - >- The feature, its capabilities and the detailed scenarios listed in each reliance are examined at the pinned revisions. --- # Integration offers and adoption: Feature Acceptance Suite ## What the Feature Must Do as a Whole The suite follows an integration from a provider release to a customer’s reviewed installation. Acceptance checks the complete handoff between offering, discovery and adoption, with the selected access and settings inspected on the saved installation. ## Interactions Between Capabilities Changes to availability must be checked against both existing adoption and a new installation attempt. The lifecycle and permission cases then revisit the offer and retained history under customer and Rhythm identities. The reliance links identify detailed capability scenarios. None of these composed acceptance sequences has a verified executable binding at the pinned revisions; the corresponding coverage finding remains open. ## Regression Record | Revision | Change | Scenarios | Reason | |---|---|---|---| | 1 | Initial | All | Establish the cumulative acceptance sequences and initial regression cases. | | 2 | Testing examination continuation | All | Clarify the feature boundary and preserve proposed status for unbound composed sequences. |