A task graph across every repo.
Flow holds the part an issue tracker structurally cannot. Your agent reads and writes it over MCP, and answers in whatever client you are already in.
No token to paste. The server registers your client and asks for your consent on first connect.
Terezinha, who the product is named after. Her glasses are a graph: two milestones and the blocks edge between them, which is the one drawing that is both.
The problem
A tracker holds one relation.
Everything else becomes prose: depends on 01, supersedes #3123, regression of #2299. A plan written that way drifts from the state the day it is written.
Measured across three repositories on 2026-08-28, 287 open issues: one epic keeps its dependency plan in a hand-typed table and then warns the reader not to trust it. The same production error is open twice. One feature flag was filed as ready three separate times, because a hand-applied label rots and nothing computed it.
What it holds
Four things a tracker cannot.
Typed edges between work
No sub-task, only the dependency — many to many, because waiting is not owning. Where a piece belongs is a tag, and a tag holds nothing up.
One task spanning repositories
A PRD moves through three issues and a pull request. That is one unit of intent and four references on it, not four tasks.
An open decision that holds work up
A decision is a task, and closing it is the act that unblocks what it held. There is no second step to remember.
What is actionable now, as a query
Readiness is computed on every read, never stored and never labelled. A derived answer cannot rot.
What an answer looks like
Readiness is derived, and says what it rests on.
The rail is the computed state; the chip beside it is the status somebody wrote down. They never look alike, so a stale label cannot pass for a live answer. The age on the right is the oldest evidence the row rests on — Flow reads no GitHub and reconciles nothing, so it says how old its evidence is rather than implying it is current.
Connect it
One endpoint, and your client does the rest.
Flow is a remote MCP server. There is no package to install and no key to generate first: the authorization server registers your client dynamically, and signing in is a code mailed to your address.
claude mcp add --transport http flow https://flow.ttoss.dev/mcp{
"mcpServers": {
"flow": { "url": "https://flow.ttoss.dev/mcp" }
}
}How it is used
Through your agent, and the flows are the documentation.
Every flow in the documentation is an end-to-end test, run against a listening server on every pull request. Click a step and the graph becomes what it was after that step — so what the page shows is what the run executed, not a drawing of it.
The reference is generated the same way, from the specs every operation is implemented against: the REST call and the MCP tool named together, so the two cannot disagree.
Status
The graph is served. The console is young.
The MCP server runs and the OAuth 2.1 authorization server is live, with dynamic client registration and discovery at/.well-known/oauth-authorization-server. Signing in is a code mailed to your address — there is no password and no sign-up, because redeeming a code creates the account.
Every /api/v1 route requires a token, so a client acts as you only once you have consented to it. What is not built is the rest of the console: it signs you in and shows the consent screen, and the graph, your keys and the people in your projects are still to come. Open it.
Terezinha Flow is a ttoss product. Green is hers alone: everywhere a graph is drawn it means ready, and nothing else on this page may borrow it.
