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](https://developer.atlassian.com/cloud/jira/service-desk-ops/rest/v2/intro/).
Atlassian documents [Forge demo development sites](https://developer.atlassian.com/platform/forge/provision-a-demo-development-site/) with Enterprise editions including JSM, one active site per developer and a default 90-day lifetime. Provisioning does not require installing an app first:
```sh
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](https://support.atlassian.com/organization-administration/docs/what-data-is-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](testing.md) for the provider acceptance contract.
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.
