The problem
Every Jira issue speaks with two voices. The summary is what humans read in standups, boards, release notes and stakeholder reports. The workflow status is what the process believes. Over a project's life these two voices quietly drift apart:
- "Fixed crash on PDF export" — still sitting in To Do.
- "Investigating the login timeout" — already Done; the summary was never updated.
- "Cannot reproduce on staging" — sitting in In Progress, where nobody can act on it.
- "Payments revamp due 2026-11-01" — still open in December.
No dashboard warns about any of this, because every tool trusts both fields. The result is not a crash — it is a slow tax on every standup, every report and every planning session: people act on summaries that are no longer true. It is the classic broken bridge between what a team said (the tracker text — the "incident" record) and what is actually happening (the workflow state).
The solution
IncidentBridge is a Forge app that continuously checks the bridge between summary and status:
Deterministic consistency engine. A pure-function rule engine compares what a summary claims against the issue's status category (
new/indeterminate/done— stable across every workflow, unlike status names). Seven defensible rules: completion claims, progress claims, blocked claims, not-reproducible claims, reopened claims, empty/placeholder summaries, and date promises that have already passed. No LLM, no guessing: the same issue always produces the same verdict, which is exactly what a trust tool needs.A verdict where the work happens. A Jira issue panel shows the verdict on the issue itself, with every finding explained in one sentence — and the fix attached to it.
One-click fixes, human-confirmed. Each finding offers its safe repair, executed only on an explicit click:
- Transition the issue to the status category its summary claims (chosen from the workflow's real transitions — if the workflow offers no path, the app says so instead of failing silently);
- Rewrite the summary — the engine proposes a corrected summary (claim wording stripped, or drafted from the description for empty summaries) that the user can edit before applying;
- Create a linked JSM follow-up — a Jira Service Management request is created and linked to the issue, so drift that needs a service team becomes tracked work instead of a comment thread.
A project-wide drift scan. A project page lists every drifted issue in the project in one table — the pre-standup truth check a lead can run in ten seconds.
The same brain, as a Rovo agent. IncidentBridge ships a Rovo agent plus three reusable actions (
check-issue-consistency,fix-issue-consistency,scan-project-drift). Ask in chat: "Scan the PAYMENTS project for drift" or "Fix the drift on PROJ-123". Because the actions are standard Forge actions, any other agent — including customer-built ones — can invoke the same check as a tool. The fix action is safe by construction: it re-runs the check and only applies a fix the engine currently offers, so a stale or hallucinated request fails safely instead of writing bad data.
How it is built (Forge modules used)
| Surface | Forge module | What it does |
|---|---|---|
| Issue panel | jira:issuePanel (UI Kit) |
Verdict + findings + fix buttons on the issue |
| Project page | jira:projectPage (UI Kit) |
Whole-project drift table (DynamicTable) |
| Agent | rovo:agent |
IncidentBridge agent with three jobs: check, scan, fix |
| Agent tools | action × 3 |
check-issue-consistency (GET), fix-issue-consistency (UPDATE), scan-project-drift (GET) |
| Backend | function (resolvers + action handlers) |
Shared engine, fix executor, REST client |
All product calls go through one client (src/lib/jiraClient.js) using api.asUser().requestJira(...), so Jira's own permission checks gate every read and write; the app never acts with broader rights than the person using it. The engine (src/lib/consistency.js) is a pure module with a 44-case test suite (rules, REST client over a fake transport, fix executor) that runs with npm test — no site needed.
Why this matters
Summary/status drift is invisible precisely because it is mundane: no error is thrown, nobody is paged, the board just slowly stops meaning what it says. IncidentBridge makes that drift visible at the moment and place it can be fixed — on the issue, in the project, or in a chat with an agent — and removes the toil of repairing it. It is deliberately deterministic: teams will only trust an automated consistency checker if it never cries wolf, and every rule here can be explained in one sentence.
Built With
- atlassian-forge
- forge-api
- forge-bridge
- forge-react
- forge-resolver
- forge-ui-kit
- jira-cloud-rest-api
- jira-service-management-rest-api
- node-js-24
- rovo
