Piper · Coding harness
Log in

Summary / The 27 components

23 Workflow and state machine

Controlling which phase may happen next, instead of letting the model improvise the process.

Latest—not scored
Baseline— 
Live use—last 7 days

Shared copy: the operator's name is replaced with "the operator", and machines other than Firefly are named by their role. Nothing else is changed.

What is built now

driver.py: the Round 1 graph INTAKE → RECON → LOCALIZE → REPAIR×N → VERIFY → [REVIEW] → ACCEPT → MEMORIZE → DONE, with REJECT on budget or no patch. Control is deterministic, model calls happen only inside REPAIR, and every transition writes a ledger row (about 36,000 so far).

What is missing

Artifact freshness (a new commit stales old observations), the graph checker test (every state reaches a terminal, every cycle has a budget), and the full 18-state graph.

Reviewer Claude, 2026-10-04

Reviewer's read: Round 1 graph built

The 09-06 review's biggest systemic finding was that no spec owned the agent loop; four of them claimed it. Settling it (the driver owns the states, pi owns the turn inside one) made everything else buildable. Two of the states (RECON, LOCALIZE) are still stubs, so in practice the graph is "run N workers, verify, accept".

How it is measured built (R1)

Graph checker in the unit tests; ledger completeness audited per bench run.

Adoption rules shared by every arm: How the tests work.

Research & attempts

Score history

No scores yet. The first entry is the baseline for suite v1.

Experimental record

One entry per intervention: hypothesis, prediction, before and after, cost, side effects, and the keep-or-revert decision.

No interventions recorded yet.