Inspiration
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
What's next for Decision Memory
Inspiration
Software teams leave decisions in Confluence ADRs, Jira descriptions, and comments. Months later the same debate reopens, or a ticket quietly proposes the opposite. Community threads ask how to keep a decision log; Marketplace tools today are mostly manual registers. We wanted something that harvests decisions where they already are, and surfaces conflicts in the issue you are looking at—and in Rovo chat.
What it does
- Harvests decisions from Jira issues/comments and Confluence pages when content is created or updated (ADF Decision items, plus phrases such as “Decision: …”, “we decided …”, “we agreed …”). Stores them in Forge KVS.
- Jira issue panel lists related earlier decisions and flags strong vs possible conflicts (for example, proposing MongoDB after an ADR chose PostgreSQL).
- Record / supersede from the panel so intentional changes stay honest in the log.
- Rovo agent with actions:
check-issue,scan-page,find-decisions,record-decision,supersede-decision. Heuristics propose candidates; the agent judges and cites sources. Writes only after the user confirms. - One install, one store for Jira (required) + Confluence (optional) via Forge multi-product compatibility. Visibility is checked as the viewing user; no external servers (Runs on Atlassian–eligible).
How we built it
Forge app with UI Kit issue panel, background triggers, and a rovo:agent plus five action modules. Deterministic libraries handle ADF → text, extraction, keyword matching, and conflict hints (src/lib/*). Shared use cases sit in service.js; resolvers, triggers, and Rovo actions call the same paths. Persistence is idempotent KVS keys. Cross-product reads use product REST asUser (UI/Rovo) or asApp (triggers), with on-demand Confluence search from Jira so older pages appear even before a trigger ran.
Challenges we ran into
- Per-installation storage initially split Jira and Confluence decision stores; multi-product
app.compatibilityplus on-demand search fixed that and removed duplicate Rovo agents. - Conflict signal quality without embeddings: needed shared-term thresholds and strong vs possible so the panel does not cry wolf.
- Permissions: every shown or superseded decision is re-checked against the viewer’s access; missing Confluence delete events leave orphaned keys that stay hidden (fail closed).
- Marketplace readiness: multi-product listing rules are still evolving; privacy/partner profile steps need a human in the browser.
Accomplishments that we're proud of
- End-to-end path on live Cloud sites: harvest → panel strong conflict with source citation → Rovo answer with verdict and links.
- Single agent and shared KVS across Jira and Confluence.
- Pure-logic test suite for extract/match behavior; no egress; MIT public repo.
What we learned
- Forge multi-product compatibility is the right model when one logical app spans Jira and Confluence.
- Keep cheap deterministic extraction/matching in code; leave nuanced judgment to the Rovo agent.
- Demo and judge flows need a stable install link from Distribution Sharing, not only
forge installon the builder’s site.
What's next
- Optional embedding or Teamwork Graph signals for better relatedness.
- Marketplace listing (or Jira-only fallback if multi-product listing is blocked).
- Richer supersede / replace UX and cleanup when Confluence pages are deleted.
- Explore MCP exposure only if it stays aligned with the same decision store.
Log in or sign up for Devpost to join the conversation.