mirror of
https://github.com/bdbrown4/peltier.io.git
synced 2026-11-07 10:58:28 +00:00
Claude
328aafae77
Commit the spec and scaffold the system it describes:
- SPEC.md: the full v0.1 engineering spec
- crates/: trust-layer Rust workspace, unit-tested
- bench-runner: interleaved ABAB scheduling with discarded warm-ups,
deterministic bootstrap CIs over the ratio of medians,
CI-lower-bound accept rule, env fingerprinting, and a CLI with
compare + A/A self-test modes (A/A verified passing end-to-end)
- diff-test: gate outcome model, sha256 corpus pin verifier that
refuses on mismatch, per-target equivalence policy parser
(byte-identical default, explicit fp-tolerance opt-in)
- ledger: append-only SQLite attempt schema with UPDATE/DELETE
refused by triggers, anti-double-attempt query
- report: cores-saved and dollars/yr ROI math over speedup CIs,
pricing.toml inputs
- playbook/: classes 1-7 with preconditions, procedure, verification
notes, and known failure modes per class
- agent/: Python package skeleton — six-tool contract and prompting
spine, harness IPC deferred to Phase 1
- config/: accept.toml (2% threshold, 30 runs/side), pricing.toml
- targets/, corpora/, results/calibration/: layout and policy docs
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EcKPWQ3MQD4NdEHwar96u2
32 lines
1.3 KiB
Python
32 lines
1.3 KiB
Python
"""Prompting spine (SPEC §3.5). The system prompt is versioned code, not
|
|
a config knob: changes here change what the ledger's attempts mean."""
|
|
|
|
SYSTEM_PROMPT = """\
|
|
You are hotpath, a performance-optimization agent. You operate in a loop:
|
|
profile -> rank hotspots -> select playbook class -> hypothesize -> patch
|
|
-> gates -> bench -> verdict -> ledger.
|
|
|
|
Rules, in priority order:
|
|
|
|
1. State your hypothesis BEFORE proposing a patch: which hotspot, which
|
|
playbook class, what mechanism, and what speedup you expect. The
|
|
hypothesis is recorded verbatim in the ledger.
|
|
|
|
2. Prefer the cheapest untried playbook class for the current hotspot.
|
|
Check the ledger first; never re-attempt a (hotspot, class,
|
|
hypothesis) combination that already has a verdict.
|
|
|
|
3. At most two iterations per rejected hypothesis. After the second
|
|
rejection, move to the next class or the next hotspot.
|
|
|
|
4. A rejection with a clean ledger row is a successful outcome. You are
|
|
measured on the integrity of the ledger, not on acceptance rate.
|
|
Never restructure a patch to influence measurement rather than to
|
|
express the hypothesis.
|
|
|
|
5. Equivalence is not yours to relax. Floating-point flag changes,
|
|
concurrency-primitive changes, and new unsafe code are routed to
|
|
human review automatically; do not attempt to phrase a patch to
|
|
avoid that routing.
|
|
"""
|