One prompt in.
One running system out.
One review.

The argument

A developer reading the always-on agent launches put it in one line: my throughput is limited by my approval. If that is true, a faster agent does not help you. A second does not help. Fifty do not help. They deepen the queue in front of the same bottleneck.

Every approval point is a wake-up you scheduled for yourself. Eleven of them in a routine is eleven interruptions, and by the tenth you are clicking without reading — including the one that mattered.

So DOTS does not compete on speed. It produces one artifact worth exactly one review, and it is built so that review can be short: the contract is explicit, the assumptions are listed, the bounds are enforced, and the result is reproducible enough that reading the diff is the whole job.

What you get back

• spec.lock — the frozen contract, carrying its own digest. Edit it by hand and the next command refuses it.
• A running tree — entrypoint, capability modules, config frozen from the spec, a manifest, and its own acceptance tests.
• An assumption list — every default the resolver filled, named, with its reason.
• One review queue — batched, with the full diff, once.
• A replayable digest — same prompt, same lock, same bytes, or the run is not sealed.

The pipeline

prompt
  │
  ├─ RESOLVE  sentence → typed, frozen, self-hashing contract
  ├─ PLAN     DAG of nodes, each declaring what it may touch
  ├─ GATE     one pass over the plan, before the first write
  ├─ BUILD    content-addressed, every write checked
  ├─ VERIFY   against the spec, never against the plan
  └─ LEDGER   append-only, hash-chained, replayable

Each stage is a separate object, a separate command and a separate failure class, because the interesting failures happen between stages.

The ceiling nobody configures

An approval list has a hard limit before it stops working as one. Past a handful of prompts per run, people approve on reflex — so DOTS reports its own overuse rather than waiting to be noticed:

! 5 approval points in one run (ceiling 3). Move the routine
  ones to allow or to handoff — a long queue gets approved
  on reflex.

Pick the two or three moments where human judgement changes the outcome. Everything else goes up into allow or down into handoff. A gate you actually obey beats a gate you merely have.

Policy, in the repo

# dots.toml
[gate]
ceiling     = 3
preapproved = ["secrets.read"]

[policy]
"fs.write"        = "allow"
"net.http"        = "allow"
"notify.outbound" = "ask"
"shell.exec"      = "ask"
"secrets.rotate"  = "handoff"   # pinned
"funds.transfer"  = "handoff"   # pinned

Try to move a pinned class and the config is rejected at load time, not ignored at run time.

Modules

Exit codes

Distinct per failure class so CI branches on what went wrong instead of grepping stderr.

Install and run

# no dependencies, no keys, no build step
git clone https://github.com/0xwast3/dots.git
cd dots && pip install -e .

dots build "poll the odds api every 5 minutes
            and alert me on a 10% swing"

●●●●  odds-watch
  run     a0eaf93ee021
  spec    e67b2937a40b
  plan    bb533e6d12f1  (9 nodes, 0 cached)
  tree    c43ae69ed5ef
  checks  pass  8/8
  review  ask 1 · handoff 0
  sealed  reproducible

# the only honest test of determinism
dots replay a0eaf93ee021
  recorded  c43ae69ed5ef
  replayed  c43ae69ed5ef
  identical

Guarantees

What this is not

• Not an always-on agent. No inbox, no calendar, no browser that stays logged in. A run starts when you start it.
• Not a model. Swapping the model must not change the guarantees — that is the whole point of the boundary.
• Not magic on a vague prompt. Garbage in, assumptions out: listed, hashed, and yours to read before you accept them.
• Not a reason to stop reading diffs. It is an argument about how many deserve your attention, not a claim that none do.