Estigia MCP server

estigIA — workflow authority for AI coding agents

Your agent says it claimed the issue, that the review passed, that the branch is current. Estigia turns those sentences into things that were checked: the claim lives in a local store (~/.estigia/state.db), every later write is measured against it, every step that cannot be undone re-verifies it, and a review verdict is bound to exact bytes, so a push invalidates it.

One binary, under whatever agent you already use; it does not run your model. Its only detached processes are a reviewer CLI and the declared checks (which).

El río del juramento. Lo que un agente promete, queda ligado a unos bytes exactos.

Leteo is the river of forgetting. Estigia is the river of the oath — the gods swore by its waters, and perjury cost nine years outside Olympus. Two rivers of the same underworld, opposite jobs: one makes you forget, the other holds you to it.

What it feels like

Mostly, nothing: a run that has claimed nothing works as before. When it refuses, it says what it read and what to do about it:

$ git push origin HEAD
estigia: git push: gh issue view failed (1): none of the git remotes ... (read-failed)
  [world-action] the tracker could not be read; write nothing and retry the read
error: failed to push some refs

The tracker could not be read is a different answer from you may not push, and Estigia will not turn the first into the second. That distinction is most of the design.

FLOW — Fast, Lean, Outcome-driven Workflow

FLOW is Estigia's own methodology: how a run takes a piece of work from an issue to a merge.

• Fast: small work stays small. Understood work is done directly, not planned.
• Lean: one writer, the smallest topology that works, and review only as heavy as the risk.
• Outcome-driven: done means the issue's acceptance criteria hold, with evidence, merged and verified.

It rests on two pillars: the claimed issue is the record of the work, and the publication is the review candidate. Four principles follow from them: small work stays small; review is sized by risk; a review lineage gets a bounded number of corrections (Corrections per lineage, default 3); and the heavyweight two-judge review (Judgment Day) runs only when asked for.

You start it with flow (analyse and build, choosing the next issue from the tracker), flow dev [issue] (build) or flow triage (analyse and file at most one evidenced issue). A run then goes through five steps, which may merge or repeat:

flowchart LR
    understand["Understand"] --> route["Route"] --> execute["Execute"] --> verify["Verify"] --> deliver["Deliver"]
    verify -->|"finding"| execute

Shortened. The full README is on GitHub.