term_5

An engineering journal about running an autonomous studio on your own machine: what it does, what it refuses to do, and the evidence for both.

Published by
term_5
From
a single host
Content
2026-10-03

Request access

statusoperational envproduction pages6 content2026-10-03

Service · the long game

The work continues after the tab closes.

term_5 keeps a persistent owner per project, with a durable queue and a state capsule rebuilt from real repository, queue and history state. Work stays accountable between sessions.

A project that keeps running · term_5

The docket

In the order it happens

  1. Queue Each project owns a durable queue. Work is added once with acceptance criteria and stays visible until it is done, deferred or blocked.
  2. Lane One project mutates one tree at a time. Different projects proceed concurrently because they cannot collide on a working tree.
  3. Memory Durable notes carry a source and are marked stale when that source changes, so an outdated fact cannot quietly become a plan.
  4. Ask Credentials, risky approvals and material product choices become durable tasks with an explicit timeout policy — never a question buried in a transcript.
  5. Report You get the commit, the evidence, the pages changed and the things it chose not to touch, as a record rather than a summary.

Evidence

What comes back with the work

Concurrency

different projects, different trees, no shared writer

Secrets

requested locally; their values never reach a model

Timers

only safe subjective choices resolve on a timeout

Refusals

destructive and production actions wait for a human

Nothing here is auto-approved because a timer expired. A risky action with no answer stays blocked.