Add latency-tuner example loop and measurement infrastructure

[mboss37]

Summary

This PR adds a complete second example of a self-improving loop — the latency tuner — alongside the existing prompt-technique-tournament example. The latency tuner optimizes a running service's retry policy (timeout, retries, backoff) against replayed production traffic, demonstrating the "optimize-a-running-system" flavor of the framework with time-based holdout validation and operational safety floors.

Key Changes

New latency-tuner example (examples/latency-tuner/):

• Measurement harness (sim/run_eval.py): Deterministic replay of retry policies against fixed traffic traces, scoring effective latency (per-request elapsed time including errors as penalties)
• Fixed traffic traces (traces/train.jsonl, traces/holdout.jsonl): 600 holdout requests and ~1000 training requests with pre-drawn upstream latencies and failure modes; checksummed to prevent mid-campaign regeneration
• Test corpus (sim/test_run_eval.py, sim/test_guardrail.py): Proves trace integrity, replay determinism, and the planted reward-hacking trap (timeout-fast-fail-cheap) that the metric must resist
• Loop agents and commands: Evaluator, proposer, implementer, gate, and meta-improver agents; /iterate command orchestrating the full cycle
• Safety infrastructure: Guardrail hook blocking destructive operations and trace regeneration; hard error-rate floor (2%) enforced mechanically
• Methodology documentation (GOAL.md, METHODOLOGY.md, PERSONA.md): Defines the optimization target, window discipline (train/holdout split), and the skeptical reliability engineer persona

Shared tooling (copied to all three locations: template, prompt-technique-tournament, latency-tuner):

• verdict.py: Mechanical gate for statistical certification — implements screen, reproduce, confirm, compare, floor, and self-test modes; fails closed on undeclared search size
• metric-contract.sh: Pre-loop validation that the metric is numeric, deterministic, and able to distinguish good from bad
• metric-contract.env: Configuration for metric contract validation

Template and CI updates:

• Updated root README.md with ASCII art, clearer positioning, and quick-start instructions
• Extended template/INSTANTIATE.md with Step 0 (prove your metric) and clarified gate methodology
• Added sandbox infrastructure (template/sandbox/): Dockerfile, macOS Seatbelt profile, systemd service/timer, and run-sandboxed.sh wrapper for OS-level jailing
• Updated .github/workflows/ci.yml to run tests for both examples in parallel

Notable Implementation Details

• Deterministic replay: Same config on the same trace window produces identical scores byte-for-byte, making gate arithmetic trustworthy
• Planted trap: The metric teaches reward-hacking — timing out fast and failing cheap improves latency percentiles while users see errors; the effective-latency metric (elapsed time with error penalties) resists this
• Checksum-pinned traces: SHA256 hashes in test assertions prevent accidental or malicious trace regeneration mid-campaign
• Fail-closed verdict: verdict.py refuses to certify without an explicitly declared search budget (Bonferroni deflation), preventing p-hacking
• Holdout as out-of-time: Unlike the tournament's out-of-sample holdout, this uses a later time window (degraded upstream) to validate generalization to future conditions
• Write-tool gating: The guardrail hook blocks edits to protected paths (traces/, guardrail.sh itself) so the loop cannot weaken its own safeguards

The latency tuner runs fully offline and deterministic — no API key, no network — making it ideal for testing the framework's measurement and gating machinery before deploying to a live domain.

https://claude.ai/code/session_011t5gmHpHh68Jcigy5uPPEx