bend-spec

Bring an existing Bend project (or a large area of one) under a machine-checked spec, the way ez and bolt were. Audit what its laws, tests and docs actually prove against the code and the real binary, write the RFC and SPEC.md with two levels (Proved and Trusted), settle the behavior changes with the maintainer, then roll out quantified laws across many PRs, fixing the real bugs found along the way, until bolt's `trace` checks SPEC.md against the laws and the headline guarantees are proved. Use this whenever the spec, the laws and the behavior of a repo disagree or nobody knows what is proved, for requests like "bring eztoml under spec", "audit the laws in snap", "our tests don't catch anything", "fix this repo's spec", "make shake's guarantees provable", "spec overhaul", "most of these laws are closed", "write an RFC for what X guarantees", or "put the rest of ez's commands in planner form". For adding one feature to a project that already has a trustworthy SPEC.md, use spec-first-feature instead.

Add or change behavior in a Bend project that keeps a SPEC.md traced by bolt (ez, bolt, and siblings such as eztoml, ezhttp, ezjson, snap, shake) the spec-first way. The SPEC.md requirement row comes first, then a quantified law in LAWS.bend, the proof in PROOF.bend, the tag and status flip, and a clean proof gate plus bolt `trace` run. Use this whenever the task is a new command, flag, lint rule, library function or guarantee, a change to what an existing one does, or a fix for a bug where the program decided the wrong thing, in any repo with SPEC.md and LAWS.bend/PROOF.bend files. Use it even when the user only says "add X to ez", "new bolt rule for Y" or "fix ez add fetching a relative path from the wrong directory", without mentioning specs or laws.