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.