meguri/docs/jsm-acceptance.md

JSM test environment and acceptance preparation

Research date: 2026-09-24. No external tenant was provisioned or contacted with credentials during this research.

Environment

No separate public mock/test Operations API host was found in the official reference. Use a dedicated test site's cloud ID with the ordinary Operations API. Basic authentication examples use https://api.atlassian.com/jsm/ops/api/{cloudId}/v1; OAuth 3LO uses a different gateway path. The existing adapter uses email/API-token basic authentication. Validate token type, scopes and both Operations and Jira directory access on the chosen site before writes. See the Operations API introduction.

Atlassian documents Forge demo development sites with Enterprise editions including JSM, one active site per developer and a default 90-day lifetime. Provisioning does not require installing an app first:

npm install -g @forge/cli@latest
forge login
forge site provision

These sites are intended for development/testing; availability can be limited. Verify that Operations can be enabled and the required test people can be added before adopting one for acceptance. Meguri remains an external Rust service, not a Forge application. A separately provisioned JSM test site is the fallback.

Do not assume an organization's sandbox copies its on-call configuration: Atlassian lists Operations among data not copied to sandboxes. This does not by itself establish that Operations cannot be configured there manually.

Existing implementation and remaining evidence

src/providers/jsm.rs already implements schedule, escalation and routing publication, identity resolution, checkpoint recovery and read-back. The integration suite exercises it against a local fake HTTP server. These are implementation checks, not proof of compatibility with the live service.

1. Create a dedicated Operations team and two or three test users. Record site/cloud ID, team ID, account IDs and subscription capabilities. Keep credentials in deployment secrets.
2. Start a separate non-demo Meguri instance with a disposable database; application demo mode deliberately rejects real provider writes.
3. Verify read access to schedules and exact identity resolution. A person's email is a lookup key, not proof that JSM can notify them; their Atlassian account and notification settings must exist.
4. Publish a small weekly schedule and a partial replacement. Read the provider's final timeline and compare exact half-open assignments, including a DST boundary, against Meguri's publication.
5. Exercise immediate escalation, repeat settings, recipient variants and routing order on the actual subscription. Existing documentation/schema discrepancies (notably delay zero) remain acceptance gates, not permission to change scheduling semantics silently.
6. Repeat unchanged, simulate partial publication recovery, change a managed remote resource, verify drift blocking and explicit overwrite, then remove only resources created by this test.

Record redacted requests/responses, API dates, plan and observed limits. Keep ordinary CI on the local fake; live acceptance must be explicit and restricted to the dedicated test destination. See testing.md for the provider acceptance contract.

Live compatibility observations, 2026-09-28

User-authorized checks confirmed that this destination requires the og- prefix on its team ID (prefixed routing GET: 200; bare UUID: 404). Schedule listing rejects size=100 with Field: size, error: must be less than or equal to 50; pages of 50 and 20 succeed.

A temporary disabled schedule, unconnected to routing and deleted after inspection, exposed the native-rotation precision limitation. Rotation starts submitted as 10:01:05.053868Z and 10:17:05.053Z returned as 10:00:05.053Z and 10:30:05.053Z. Starts at 10:30:00Z and 10:00:00Z were preserved. The returned rotation array also differed in order. Do not treat arbitrary exact intervals as verified or relax drift checks to accept these shifted boundaries. A subsequent disabled-schedule probe confirmed arbitrary future override boundaries and millisecond precision in the final timeline over a noone base. Creating an override with a past start returned HTTP 400. The adapter therefore uses the current assignee as the base and future overrides for exact transitions. A further disabled-schedule probe verified the current-user base followed by a future noone override in the final timeline at the exact millisecond boundary. A roughly 90-day override and an overlapping replacement were accepted; the older override retained its boundaries and could be deleted after replacement. All temporary probes were deleted. Full application-level acceptance, including ongoing override replacement, remains necessary on the dedicated test team; individual endpoint probes do not certify production reconciliation.

Readable resource names and legacy-name recovery are covered locally. They do not resolve this time-boundary mismatch: a resource left behind by a failed read-back remains protected by drift checks.

Compact recurring rotations use the documented daily/weekly rotation API with ordered participants and a finite end date. Local regression coverage includes calendar-day phase selection across both DST changes and in-place conversion from per-shift rotations. Compare the real provider timeline across a handover and DST boundary during the next explicitly requested live publication; no live provider writes were made for this optimization.