Checkout rewrite epic — CHK-210
The scope and acceptance criteria.
A single feature spans the spec, the threads that shaped it, the tickets that scoped it, and the PRs that shipped it. Virgo assembles that connected history on demand. You start with the whole picture instead of reconstructing it tool by tool.
One checkout rewrite lives in the spec, the threads that shaped it, the tickets that scoped it, and the PRs that shipped it. To understand it, you open every tool and rebuild the picture by hand.
The scope and acceptance criteria.
Where idempotency keys were decided.
What was tried before, and why it was reverted.
Every piece is here. It is just spread across six tools.
The original requirements.
How the service fits together.
Where the rewrite was scoped.
Virgo connects those same six tools into one reasoning graph. Ask it about the checkout rewrite and it queries every source, pulls the piece each one holds, and returns the connected context, instead of leaving you six tabs to reconcile by hand.
Behind one question, Virgo walks the reasoning graph and returns the connected context behind it, already assembled.
Assembled once, it serves the engineer reading the change and the agent acting on it.
The spec, the discussion, the tickets, and the code arrive connected. You see how a change came to be and why it works the way it does before you touch it.
An agent handed a snippet writes against the snippet. Hand it the assembled context (the decision, the constraint, the reverted attempt) and it reasons about the real change. Virgo retrieves across the graph at query time, over MCP, so any agent works from the connected work history.
Up to 97% in early evaluations, versus about 68% for baseline RAG or hybrid search.