# tehas

> Tehas is a software factory: a GitHub issue goes in, a reviewed pull request
> with a running preview comes out, built by sandboxed agents on self-hosted
> models. GitHub issues and labels are the only control plane. A human merges;
> tehas never merges, deploys or touches production. This host is one running
> factory and its operating manual.

You are probably here for one of two things. Pick the section that fits.

Every manual page is also served as Markdown: add `.md` to its address.
Everything on this host is read-only. Nothing here changes a ticket or the
factory.

## Get work built by this factory

1. Read `repo` in https://tehas.app/live/status.json: that is the product repository
   this factory serves. Issues go there.
2. Write an issue with one outcome small enough for one pull request, a
   `## Acceptance criteria` section with checkable items, and the files or area
   involved. The cycle reads the issue body and nothing else.
3. The label `tehas:ready` authorizes the work, and only counts when a person
   on the factory's allow list applies it. If you are not that person, stop
   here and ask them. Use `tehas:prototype` for an idea that is not ready.
4. Follow the labels on the issue: `tehas:running`, then
   `tehas:awaiting-merge` with a pull request, or `needs-human-attention` with
   a comment saying where it stopped.

- [Operating](https://tehas.app/operating.md): writing an issue, labels, review, pause, retry
- [Overview](https://tehas.app/overview.md): how an issue flows through the factory
- [Troubleshooting](https://tehas.app/troubleshooting.md): what each stop means and what to do
- [Staging](https://tehas.app/staging.md): reaching the preview of a pull request

## Set tehas up for another repository

The source is at https://github.com/janit/tehas. Be honest with your human
about its state: tehas was extracted from one project and installing it for a
second one means setting variables and editing scripts, and has not been tried.

1. Read [A new project](https://tehas.app/new-project.md) in full. It is the
   install guide, in three levels; level 1 (issue to pull request) is settings
   plus a sandbox image.
2. In the product repository, add the contract tehas reads: `AGENTS.md`,
   `.pi/verify-cmd`, `.pi/settings.json` and the `.gitignore` entries, then the
   recommended gates. Prove the gates by hand in a clean checkout first.
3. On the host, follow level 1 step by step. Secrets, the bot account and the
   allow list are your human's decisions: ask, do not invent them.

- [A new project](https://tehas.app/new-project.md): the contract, the host, the three levels
- [Features](https://tehas.app/features.md): what exists and how far each part is proven
- [The host](https://tehas.app/host.md): layout on the machine and the sandbox contract test
- [Commands](https://tehas.app/tools.md): every `tehas-*` command

## Live data

- [Health](https://tehas.app/health): JSON, 200 when the factory is healthy and 503 when it is not
- [Queue snapshot](https://tehas.app/live/status.json): the repository, open issues by state, whether the factory is paused, staging stacks
- [Current cycle](https://tehas.app/live/running.json): the issue being worked on and its status; its console is `/live/console-<issue>.txt`

## Optional

- [For agents](https://tehas.app/agents.md): this file as a manual page, with a prompt a person can paste
- [Factory floor](https://tehas.app/): the dashboard people look at