What pi-tehas does

pi-tehas turns GitHub issues into reviewed pull requests, using pi-rukas agents on self-hosted models. A person writes the issue, applies one label, and later reviews and merges. Everything in between is tehas. An instance can also give each pull request a running preview; that part belongs to one product so far.

It is a set of shell scripts, two small Deno programs and a few containers on one host. There is no server process of its own and no database of its own: state lives in GitHub labels, in pi-rukas's state files and in plain files under ~/tehas.

Each feature below says how far it has been proven. "Verified" means it was run on a tehas host and the result checked. Unless a row says otherwise, that was the first instance, before settings moved into an instance directory. Nothing here has run for longer than a day.

Queue and dispatch

The work cycle

Staging

Only on an instance with TEHAS_PREVIEWS=1 and TEHAS_CLONES=1. Off by default. See Staging.

Keeping staging out of production

Only with previews.

Visibility

Host management

A second instance

tehas was built for one product. The check that it serves another is the instance on the host tehas-tehas, which works on this repository. Each row is what was seen there or in the tests, with its date. The record is docs/bringup/2026-10-08-tehas-tehas-log.md.

Why no pull request yet: the configured model has one slot on the model endpoint, a request that waits more than 20 seconds for it is refused, and reading a 70,000-token prompt alone takes about 30 seconds. As soon as two conversations want the slot in the same minute, one is refused; pi-rukas retries the step three times and then stops the cycle. In the first attempt the other conversation was another job on the model host. In the second, that job was off, and the other conversation was the cycle's own: pi-rukas's driving session takes model turns of its own while a step's agent is working, and the two starved each other. So a cycle needs a model that serves at least two conversations at once, whatever else is running. Nothing in this was a fault of the instance's setup, and nothing in tehas can fix it: the instance needs a model with two or more slots and enough context (the driving session's prompt reached 81,000 tokens), or a much longer wait at the endpoint. Until a cycle completes, the claim that a second instance works end to end rests on everything above this row.

The local line: a cycle starts from the product's default branch, and this repository's contract files were on a work branch when the instance was set up. TEHAS_BRANCH named that branch on the host until it was merged.

Not built

• Monitoring: availability probes, incident issues, weekly report.
• Electricity price scheduling. tehas:urgent only changes ordering today.
• Model evaluation; every role uses the same model by decision, not by measurement.
• Watching tehas itself: a stuck cycle, a failed refresh, a full disk.
• More than one project per host. See A new project.
• Previews and database clones for any product. What exists is one product's implementation behind two switches.

Known limits

• One host, one project, one cycle at a time.
• The cycle's container holds the bot's token, so agent code can do what that token can. Give each instance its own bot account. See The host.
• Previews are plain HTTP, so features that need a secure context cannot be tested on them.
• Stacks and clones hold real production rows.
• A pull request closed without merging leaves tehas:awaiting-merge on its issue until someone removes it.