OpsGuardian Forge

Review incident context from a resolved Jira Service Management work item before writing an internal note.

Comment

Inspiration & The Problem

During incident response, relevant history is often scattered across Jira issues. Service desk agents often need to check a previous resolved issue before making a decision, obtaining useful context without assuming that a past fix is the cause of a current incident or creating duplicate internal notes.

What it does

OpsGuardian Forge adds an incident context review panel to Jira Service Management. An agent selects a previous resolved work item. The app reads both items using the agent's Jira permissions and compares available components, labels, priority, and issue type. It identifies explicitly marked resolution or fix comments as source-attributed reported evidence for human review.

After reviewing the comparison, the agent can explicitly confirm a generic internal acknowledgement note. The app rechecks current access and source data before writing, and uses an installation-bound HMAC marker (og3) together with an atomic Forge KVS claim to prevent duplicate internal notes. Repeating a confirmation reconciles and returns the existing receipt rather than posting a duplicate.

This demonstration uses fictional issues and shows:

  • Selecting a resolved reference issue and comparing available fields.
  • A warning when no explicit resolution comment is found.
  • Reconciling an existing internal note without creating a duplicate.
  • Rejecting a self-comparison.

How we built it

Built on Atlassian Forge (Node.js 24 runtime) using:

  • Jira Service Management / Jira Issue Panel (UI Kit) for the agent review workflow.
  • Forge KVS (@forge/kvs) for atomic write claims, deduplication, and indexed personal-data lifecycle tracking.
  • Jira & Jira Service Management REST APIs (asUser) to enforce the acting agent's permissions on both source and target issues.
  • Scheduled Trigger (scheduled-privacy.privacySchedule) for hourly privacy lifecycle checks and fail-closed personal data reporting.

Challenges we ran into & Limitations

  • Human-in-the-loop boundary: The comparison is evidence for a human decision, not an automated diagnosis. OpsGuardian Forge does not establish causation or execute a fix.
  • Idempotency under uncertain outcomes: If a network or platform write returns an ambiguous result, the claim is retained for reconciliation rather than blindly retried.
  • Privacy & data lifecycle: Current production release is 3.7.0 (125 local unit tests and forge lint PASS, hourly scheduler verified on 2/2 production installations and 2/2 staging 2.32.0 installations). Confirmed closed and updated privacy actions are applied immediately even if the response clock is invalid or a non-default Cycle-Period header is present, while preserving the erasedThrough watermark across subsequent reports. Historical unindexed legacy coverage (coverageVerified = false) and non-null Cycle-Period units (CYCLE_PERIOD_UNIT_CONFIRMED = false) remain gated for manual review.

Accomplishments that we're proud of

  • Strict asUser permission enforcement and zero-copy generic internal notes (no restricted reference text is copied into the target issue).
  • Deterministic 125-test suite covering concurrency conflicts, token tampering, clock regression, and per-account privacy failure isolation.
  • Eligible for the Runs on Atlassian program (Forge production 3.7.0).

Built With

Share this project:

Updates

Submission history