pick-harness
Pick Harness
Friction-driven judge for which guardrail to add next — then scaffolds it. Sibling of /pick-model (the model) and /pick-workflow (the topology). Grows a harness one guardrail at a time to fit the real failure; never designs a full harness upfront. When: an agent keeps failing at X · you want to stop it doing Y · you're starting a task and want a minimal starter set.
Extends the repo's
HARNESS-ENGINEERING.md(Böckeler/Fowler guides⏩ vs sensors⏪, computational⚙️ vs inferential🧠) with 2 axes (latency, timing) +🧱 containment. Single source of truth for the which-guardrail call — don't re-derive the grid elsewhere. Worked examples, sandbox detail, drive-templates →reference.md.
Decision grid — 4 axes + 1 orthogonal
| Axis | Ask | Values |
|---|---|---|
| Role | Orient or inspect? | 🪧 guide (persuades, bypassable) · 🚨 sensor (observes, returns a verdict) |
| Nature | Deterministic or judgment? | ⚙️ computational (code/regex/exit code) · 🧠 inferential (an LLM judges) |
| Timing | Before or after damage? | ⏩ feedforward (preventive) · ⏪ feedback (corrective) |
| Latency | Tokens burned before the catch? | ⚡ immediate (before generation) · 🐌 deferred (after the fact) |
| 🧱 Containment (orthogonal) | — | Makes the action impossible. Neither guides nor inspects — the 4 questions don't apply. |
Feedback ladder (by latency): self-correction⚡ (test/lint, pre-commit) → human-review🧑 (at the PR) → pipeline🐌 (E2E agent-browser / LLM-judge, post-integration).
CORE PRINCIPLE — classify by LATENCY, not sophistication. Prescribe the earliest catch that fits, not the fanciest. The best sensor makes the bug unrepresentable (
newtype Seconds ≠ Millis→ a whole bug class becomes a compile error, free forever). A cheap ⚡ guard beats a clever 🐌 one.