Skip to content

Design notes

One note per idea, in the order they came up. Each carries a status, and the status is the whole point: accepted means it is how the factory works or is ticketed to be, proposed means it has a shape but no decision, open means the shape itself is still being argued. Nothing here is sorted into a bin before it has to be.

The standing decisions predate these notes and remain in force; new ones land here as notes.

# Note Status
1 SQLite stays the store; Convex is an optional second one accepted
2 One machine first; the tailnet is an operator choice accepted
3 Branch prefix is configurable accepted
4 The loop starts its own supervisor accepted
5 Frontend before the Rust port; v0 served by the daemon accepted
6 Docs on Cloudflare Workers accepted
7 Merge modes: local or PR, with a round cap accepted
8 Human approval, manual checks, and a checker role accepted
9 The ledger lives in the store accepted
10 Learning from recurring findings proposed
11 Per-ticket leases and parallel loops proposed
12 A second board behind the provider protocol accepted
13 The console's shape accepted

Standing decisions

  1. KISS / evidence-first. No mechanism without a demonstrated consumer: config knobs, plugin seams and supervisor features alike.
  2. Pluggable by shape, not by system. Hardcoded behavior moves to module-level seams (callables, lists, config) as tickets touch it; a plugin or registry mechanism waits for a second consumer's evidence.
  3. Tickets are atoms. Narrow leaves within the scope caps, 90 minutes at most; parents are tracking-only and unclaimable; the claimed ticket body is a frozen contract.
  4. Every failure becomes a mechanical gate. Each failure class gets a gate; the failure lineage lists them.
  5. The factory never pushes main. Pushing main is the operator's call; under [merge] mode = "pr" the loop pushes its own task and evidence branches and opens a pull request (note 7).

Writing one

Copy the shape below. Keep it under a screen; link the tickets that carry it out rather than restating them. Change the status line when the status changes and say why in one sentence under it.

# Title

**Status:** proposed · 2026-09-04

## Context
## Decision (or Proposal)
## Consequences
## Tickets