Confirm the bug.
Group the bug reports and reproduce it.
Ouroboros finds the cause and prepares the fix
Ouroboros, also called O.B., is the engineering chamber of SylvieSI, a product of THE SHRIKS. It takes a confirmed bug or an approved feature request and carries it through. It finds the cause, prepares the change, asks a person to approve it, tests it on staging and saves the outcome.
Follow the work ↓
OUROBOROS
What Ouroboros does, and what it does not
Ouroboros starts where Mobius stops. When a bug is confirmed, Ouroboros opens a Case. It reproduces the bug, reads error data and code, and writes a root cause assessment that says how certain the cause is. It then prepares the change as a Linear issue with a full handoff, a draft pull request with a test, or an approved component for your staging site.
Ouroboros never merges a pull request, never deploys on its own and never changes anything a person has not approved. If it cannot find the cause, it says so and lists what is missing.
Five steps from a confirmed bug to a checked fix
Every step stays linked to the messages that started it.
“The export downloaded twice.”
Find the cause.
Read error data and code, and state how certain the result is.
Prepare the fix.
A Linear issue, or a draft pull request with a test.
A person approves.
Review the exact change.
Check and tell.
Re-run the failing step on staging, then update the sender.
Each step is linked to the one before it. A person approves before anything changes.
What a Case shows
A Case moves from reported, to supported by evidence, to a verified bug. A label from the classifier alone never verifies a Case.
Overview
The bug, the senders, how many accounts are affected and the current state.
Evidence
Every finding with its source, its age and the gaps.
Root cause assessment
A hypothesis, its state, the evidence for and against, what is missing and the next step.
Work
Steps, owners, attempts and blockers.
Changes
The handoff, the draft pull request or the component, with test results.
Outcome
The checks that passed and the reply sent.
Timeline
Every event on the Case, in order.
Two kinds of change, both approved first.
Ouroboros builds on what SylvieSI knows about your product.
An approved component
For a simple read-only feature such as a search filter, SylvieSI picks an approved, versioned component, tests it in a browser and delivers it to staging after approval.
An engineering change
Anything else becomes a Linear issue or a draft pull request with a full specification. If a request cannot be done safely, SylvieSI says why.
Engineers get a full handoff
Each handoff holds what an engineer needs to start. It goes to Linear as an issue, and the issue’s status syncs back to the Case.
The bug
What was reported, how to reproduce it and which accounts are affected.
The cause
The likely cause, how certain it is, what supports it and what is unknown.
The work
Owner, steps, blockers and a test plan.
The change
The exact change, its risk and the approval that allowed it.
Choose the path the change needs
Approved components go to staging first. Everything else goes to engineering.
Approved components (LiveLayer)
LiveLayer delivers approved, versioned components to your staging site. A signed bundle loads only for the audience you choose.
Engineering changes
Requests that need a database change, a new API or a write action go to engineering with the full specification.
Switching a change off
A delivered change can be disabled. SylvieSI checks in a real browser that the original page is back before it reports the change as removed.
How a fix is verified
SylvieSI marks an outcome verified only when every configured check passes. It runs the step that failed on the fixed build, confirms that the fixed build is the one deployed, and watches for repeats. A person confirms, and only then does SylvieSI write to the sender. A Linear issue marked Done is never enough.
Outcomes have six states
An outcome is awaiting, measuring, verified, not achieved, inconclusive or regressed. Only measurements, or a person’s confirmation, change it. An agent’s wording never does.
- Awaiting
- Measuring
- Verified
- Not achieved
- Inconclusive
- Regressed
When a bug comes back
If a matching message arrives after a Case closes, Ouroboros proposes to re-open it. A person confirms. The earlier outcome stays on the Case.
Request access to the pilot
Describe the bugs and requests your engineers handle each week.
Request access ↗