tarigato
GitHub

The CLI flow.

Give it a task in your terminal. One agent changes the code. Another tries to break it with a test. You review the patch.

Docs

How it works

tarigato "Reject expired sessions"



Example simulation. No agents run here.






Inspect the code and tests


Explore the run






Your checkout
Unchanged
session.go
return expiresAt >= now
TestValid
One existing test. Two cases.
Valid(99, 100)
false
Valid(101, 100)
true
Valid(100, 100)Missing
Agents work in separate copies. Your checkout stays untouched.


Agent 1 · Builder
session.go


Agent 2 · Challenger
tarigato_challenge_test.go
+1
One proposed test. Not accepted yet.
If a repair is allowed, this test stays fixed.




Original tests
Must pass before the challenger runs.
Same candidate. Same test. Two runs.
RunOriginal testsChallenge test
Final checks
On the final source, with any accepted test.


00
Task
The code accepts a session at its exact expiry time. The task is to reject it.
Your task




Interactive illustration. The expression runs in JavaScript; the agent sessions and Go checks are simulated.
The passing path follows the recorded example. Repair and unstable-test paths are illustrative.


When does it repair or stop?
The roles run in order, in separate sessions. Both use Codex by default.
go test -json -count=1 ./...


View the full source


View the full run log
session-expiry / tarigatoBrowser simulation
$ tarigato "Reject sessions when expiry is at or before now"
tarigato
BUILDER codex  / CHALLENGER codex
›READYPress play to explore the run.
0 / 8
Illustrative timing · real workflow






Explore the expression separately
Test the missing boundary.
The original expression matches the requirement except at equality. At exact expiry, the session must be rejected.




expiresAt100
ExpressionAccepts



now100
RequirementRejects




100 >= 100




At exact expiry, the candidate accepts an expired session.




This expression is evaluated locally in JavaScript. It is separate from the agent simulation.
Run this example locally




Review the patch and the test.
Read the source patch, the test expectation, and the recorded checks. Replay the evidence before applying a change.
Illustrative file previews. The local CLI creates the actual run files.
candidate.patchSource presented to the challenger
changes.patchLatest source patch; final checks are shown separately
tests.patchThe admitted challenge test
report.mdRecorded outcomes and artifact locations
~/.tarigato/runs/<id>/
Passing checks provide evidence about tested behavior. You decide whether the test expectation is right and the patch should ship.


Inside the harness
The rules
Two roles, one controller, and at most one repair.
A stable failing challenge permits one repair. An invalid result stops the run.
The game-theory mechanism is the opposition between the two roles. Their objectives come from instructions; there are no numerical rewards or equilibrium calculations.
Passing checks are evidence about the tested behavior. They do not prove correctness.
Inspect the protocol
Source and rules are available on GitHub under AGPL-3.0-only.


Documentation
Read the docs
Install
Build the CLI, choose your project, and give it a task.
Rules
Protected files, test admission, and the one-repair limit.
Limitations
Trusted repositories, provider access, and what checks cannot prove.
Build from the Tarigato source checkout:
go build -o tarigato ./cmd/tarigato