After a user reports a bug, it should be read, grouped with matching reports, reproduced, traced to a cause, fixed, approved by a person, checked and then answered. This is what each step looks like in SylvieSI.
It starts with a message
A user writes that an export downloaded twice. The message might come from inside your product, from a Slack channel or from a support inbox in Gmail. Mobius reads it, works out who sent it, and labels it as a bug, a feature request, a question or feedback.
The sender's own words stay attached to everything that follows. An engineer who picks up the work a week later reads exactly what was written.
Many messages, one bug
Rarely does only one person notice. Others write about the same thing in other channels and in other words. Mobius groups the messages that appear to describe the same bug and keeps every original.
A group is a suggestion, and a person can split it. Two senders who both mention exports may be describing different bugs, so every group can be undone.
Finding the cause
Before it looks for a cause, SylvieSI tries to reproduce the bug. It runs the steps the sender described and watches what happens. It then reads error data from Sentry and the recent changes to your code to find where to look.
The result is a root cause assessment with one of four states: Verified, Probable, Insufficient evidence or Unable to determine. A model can reach Probable at most. Verified needs a passed reproduction or a direct match in the error trace, and a person confirms it. When there is not enough to go on, the assessment lists what is missing and what to check next.
The fix, and who approves it
With a likely cause in hand, Ouroboros prepares the work. That is either a Linear issue with the reproduction, the cause and a test plan, or a branch and a draft pull request with a fix and a test.
A person reviews the exact change and approves it. A person merges it. SylvieSI never merges on its own, and deployment stays a human decision.
Telling the sender
After the fix is in place, SylvieSI re-runs the step that failed on staging and confirms that the fixed build is the one deployed. It then watches for the error for a set period. When every check has passed and an Owner or Admin confirms, the Communication agent drafts an update for each person who reported the bug. A person, or your reply policy, sends it on the channel each person used.
If a check fails, nobody is told the bug is fixed. If the bug returns after the Case closes, a new matching message proposes a re-open, and the earlier outcome stays on the Case.