Code changes only as a consequence of the specification
Behaviour changes by changing the specification first; the change to the code follows from it. Every commit that changes code names, by its sid, each checked node whose implementation it adds or changes — one whose text has just changed, or an existing one the code contradicted — and every tag on a symbol it adds or changes names a node the message names, or is the tag that names none. The message names no domain's header and no section.
Wanting different behaviour is a reason to change the specification, not the code. A commit that repairs code which contradicted the specification as it stood is the same procedure and not an exception to it: there the specification was already right. The message and the tags name the same nodes so that the message says which nodes the commit serves, and a header or a section is refused because it requires nothing a change could serve.
The links made to it
The decisions taken on it
- Problem
A commit changing a domain's code named the domain's header, which says nothing of what the commit changed, and the check of the message accepted it, since any node that exists was accepted.
- Ruling
The owner: code changes only through the specification. A commit names the checked rules it serves, the tags of the declarations it changes name those rules, and a header or a section never stands in for a rule.
The tests bound to it
- skills/tools/test/unit/gates.test.ts · s-ef93u6cnbs2sevr passes a message naming every node the tags on the changed symbols name
- skills/tools/test/unit/gates.test.ts · s-ef93u6cnbs2sevr refuses a message leaving out a node a changed symbol's tag names
- skills/tools/test/unit/gates.test.ts · s-ef93u6cnbs2sevr refuses a message naming a section or a node that does not exist, its comment lines left out