Rhythm 2.0 Specifications

Appearance

ATS-PFM-OPS-006Investigate platform jobs in Rhythm HQ: Capability Test Specification

Markdown

ATS-PFM-OPS-006

Investigate platform jobs in Rhythm HQ: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-OPS-006

Design

Executed by
TST-PFM-OPS-054, TST-PFM-OPS-067, TST-PFM-OPS-075

KindAcceptance test setProduct areaPlatformModuleOperational RecordsRevision2

Read atservices-platform ad3f6a65react-console baf6dae3macroservice-libraries 54536a44

Investigate platform jobs in Rhythm HQ: Capability Test Specification ​

Coverage ​

The category map distinguishes authored scenarios from unresolved proof obligations. A bound scenario names an existing executable suite; its recorded result remains unrun.

RuleProof status
BR-CAP-PFM-OPS-006-01ATS-PFM-OPS-006-01
BR-CAP-PFM-OPS-006-03ATS-PFM-OPS-006-02
BR-CAP-PFM-OPS-006-07ATS-PFM-OPS-006-03
BR-CAP-PFM-OPS-006-08ATS-PFM-OPS-006-04

Confirm recovery from the inspected failure. The page follows the newly started attempt while the earlier failure remains inspectable.

Compare customer and staff views of one run. Both audiences see the same run outcome; only the staff view includes staff enrichment.

Evidence and Boundaries ​

Pinned assertion sources support the listed executable bindings. Proposed cases retain the proof required beyond those boundaries. Structured obligations name incomplete object, transition and permission trace; row-level concurrency proof does not establish complete workflow serialization.

Coverage

  • Rule covered
  • Transition not-applicable
  • Validation gap: FND-PFM-OPS-058
  • Permission covered
  • Edge covered
  • Failure gap: FND-PFM-OPS-003
  • Boundary gap: FND-PFM-OPS-058
  • Concurrency gap: FND-PFM-OPS-058
  • Invariant gap: FND-PFM-OPS-058
  • Interaction covered

Test Scenarios

6 scenarios proving CAP-PFM-OPS-006; 3 bound to an existing test.

01 Keep the HQ monitor staff-onlypermissionapinegativetest
Proves
BR-CAP-PFM-OPS-006-01
Preconditions
HQ staff and a customer administrator know customer job identities.
Steps
Request HQ snapshots through both contexts.
Expected
Authorized staff can read across customers while customer context is refused.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/jobs/tests/e2e/jobs.e2e.spec.js#refuses a console caller of the job’s own customer the HQ route as 403
02 Resolve subjects without requiring related recordsedgeapitest
Proves
BR-CAP-PFM-OPS-006-03
Preconditions
Jobs name workspace, customer, no subject and a deleted workspace.
Steps
Resolve their subjects and requesters.
Expected
Workspace takes precedence over customer and unavailable names remain null without losing the job.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
services-platform:modules/jobs/tests/integration/services/subjects/job-subject.integration.spec.js#names the subject null, and still answers it, for a tenant that no longer reads
03 Present queued and missing jobs correctlyrulebrowsertest
Proves
BR-CAP-PFM-OPS-006-07
Preconditions
One job has not started and another identity is unknown.
Steps
Open their HQ detail pages.
Expected
The first is Queued and the second displays Job Not Found.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Bound to
Source
react-console:e2e/mock/hq-ops.mock.spec.ts#calls a job that has not started Queued, never Cancelled
04 Warn about silent workfailurebrowserproposed
Proves
BR-CAP-PFM-OPS-006-08
Preconditions
A running job exceeds the inactivity threshold.
Steps
Open its HQ detail page.
Expected
The intended warning provides a Check Again action.
Data
Controlled records and caller contexts matching this scenario’s preconditions.
Source
FND-PFM-OPS-003
05 Confirm recovery from the inspected failureinteractionapiproposed
Proves
BR-CAP-PFM-OPS-004-08 BR-CAP-PFM-OPS-006-06
Preconditions
Staff can inspect a failed provisioning run and hold both required action permissions.
Steps
Open the failure, confirm retry, and inspect the successor.
Expected
The page follows the newly started attempt while the earlier failure remains inspectable.
Data
Isolated workspace records and caller contexts for both sides of the interaction.
Source
react-console:e2e/mock/hq-ops.mock.spec.ts#shows a failed job's reason and retries its provisioning; react-console:e2e/mock/hq-ops.mock.spec.ts#shows a running job's step, its timeline and its event log; CAP-PFM-OPS-004; WF-PFM-OPS-005; WF-PFM-OPS-007
06 Compare customer and staff views of one runinteractionapiproposed
Proves
BR-CAP-PFM-OPS-005-02 BR-CAP-PFM-OPS-006-04
Preconditions
A customer run has a requester and a workspace subject.
Steps
Read it through the authorized customer monitor and through HQ.
Expected
Both audiences see the same run outcome; only the staff view includes staff enrichment.
Data
Isolated workspace records and caller contexts for both sides of the interaction.
Source
services-platform:modules/jobs/tests/e2e/jobs.e2e.spec.js#says of another customer's job exactly what it says of an unknown one; services-platform:modules/jobs/tests/e2e/jobs.e2e.spec.js#carries neither on the customer's own snapshot, which has nothing to say; CAP-PFM-OPS-005; WF-PFM-OPS-005; WF-PFM-OPS-007

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