Defect Twin Finder
Before anyone starts work, the mission says whether this fault has been seen before — and what was learned the last time it was.
What it does
Polls the tracker for every issue, oldest first, and records each one along with any cause the tracker already holds. It reduces each report to a stable signature, looks that signature up in everything it has already stored, and brings back the prior occurrences that carry a cause. A person then calls it a recurrence, calls it new, or asks for the one piece of evidence that would settle it.
How it works
Before anyone starts work, this mission asks whether the defect in front of them has been seen before. It reduces every report to a stable signature, looks that signature up in everything it has already recorded, and where a past occurrence was understood, brings back what was learned. A person then calls it a recurrence or genuinely new — so the second time something breaks, the first time counts for something.
How it's wired
One poll watcher on the tracker's search, storing into `defects`. The Signature Analyst produces the signature from rules it carries as knowledge; two `lookup` compute steps read the mission's own history — a count of prior occurrences and the ones that recorded a cause; a third enrichment judges recurrence. One human gate writes the call and what to check first. The Twin desk leads with signature frequency.
The team
Reduces a defect report to a stable key, and judges whether what the mission already knows amounts to a recurrence.
Connects to
What it watches
Polls the tracker every two minutes for every issue, OLDEST FIRST, so what was resolved months ago is remembered before today's report arrives.
Human approval
One consequential step waits for a person's approval before it acts.
What it already knows (4)
Data it carries
1 table
What it shows a human
Ask it
“Give me the signature for this report: "Refunding a subscription returns a 500. at PaymentMapper.map(PaymentMapper.java:88)"”
“Give me the signature for this report: "Export returns an empty CSV when a date filter is applied."”
“Give me the signature for this report: "App is slow."”
“Two reports share a signature but one is in payments and one is in reporting. Is that a recurrence?”
“Why is a stack frame a better key for the same fault than a summary line?”
Before it runs, you'll
- 1Confirm the Issue Tracker server at import. It is credential-free and works as-is; replace the URL with your own tracker and nothing else changes — the mission only calls search_issues.
- 2Provision the Signature Analyst. Its signature rules upload with it, and they are worth editing on the Knowledge tab to match how your stack traces actually read.
- 3Enable the observation and let it work through the backlog once. It needs history behind it before it can find anything — the first pass IS the memory being built.
Import into StudioX
- Download the
.sxmfile. - In StudioX → Missions → Import, drop the file.
- Review, finalize, and it's live — chat to it or enable the observation.
Reviews
No reviews yet. If you’ve run this mission, yours will be the first — what it handled well, and what you had to wire up, is what the next person needs to know.
More in Engineering
Bug Intake Gate
Every bug report is read before it reaches the backlog — and the ones that can't be worked are named, not silently queued.
Triage Analyst
Close-Out Gate
A fix isn't finished until somebody can say what went wrong — and the answer is written down where it can be found again.
RCA Analyst
Change Impact Planner
Every commit is read as the files it actually changed — and what was decided about that area last time is on the screen when you scope this one.
Impact Analyst