The commands
sheriff validate, sheriff binding, sheriff citations, sheriff guard, sheriff message and sheriff review implement the checks as the table of how each check is made describes them (§s-4kd2pave7vm4hmd).
sheriff init sets a repository up for the SpecSheriff tools, and sheriff remove takes SpecSheriff out of it (§s-7unxytshhc4md54).
sheriff reindex gives a sid to every node that has none, computes every node's address from where it stands, empties every incoming list and rebuilds it from the outgoing ones, rebuilds the index in every domain's header from the domain's sections, and empties the status of every checked node outside the SpecSheriff guidelines the project takes unless the latest line for its wording's fingerprint is a confirmation by the node's owner; it is run after every change to the specification.
Before anything else, sheriff reindex merges, in every file it rewrites, the values an object holds under one key, each into those written before it: two lists into one holding the members of the first and then those of the second that the first does not hold, two objects key by key in the same way with each key where it was first written, and two values JSON Schema holds equal into one. It names every key it merged, with the file and each value's line, and refuses any other two, naming the file, the key and each one's line and value, and then writes no file.
sheriff confirm records an owner's confirmation (§s-v4qus7raqnwzneb).
sheriff export writes the readable export in markdown, one file for each file of the specification, each node as §s-k4nqjr96ux7a5m7 says.
sheriff render writes the map, the mindmap of the specification's structure drawn from its nodes (§s-rpv4fkdqqguptqd).
sheriff guide prints every node of the guidelines — the base, the appendix of the tools and the project's own — as §s-k4nqjr96ux7a5m7 says, and the figures counted off the model as it prints: how many nodes each part holds and how many of them are checked.
sheriff show prints a node, found by its sid or its address, as §s-k4nqjr96ux7a5m7 says.
sheriff types generates, from the data record nodes, the types and the runtime checks of the system's code, where the technical appendix says they stand. It writes a file only where the file is missing or holds, line endings aside, anything other than what it generates, and names each file it writes; where the check of generated copies refuses the list of those files or a data record node (§s-4kd2pave7vm4hmd), it names each refusal and writes no file; while a data record node is unchecked, it writes no file and names each such node.
The reindex rewrites whole the files written by hand, so it keeps everything they hold: two values written under one key are each somebody's intent, kept together where both can stand and refused where keeping one would drop the other, since nothing says which was meant; and every merge is named, because one of them may have been written to replace the other.
sheriff types runs after every edit an agent makes and at every commit, where the pre-commit hook copies each file it names into the working tree for its author to stage (§s-477gtdrkw34dzxw): the files it names are then exactly those its author has to stage, and a file whose content no edit changed keeps its modification time, so that nothing watching the files takes it for changed. Line endings are set aside because git may check a file out with endings other than those committed, which would make every file differ at every run.
Where anything is refused, no file is written, so that the files never disagree, one generated from the nodes as they stand beside another left behind them; and each refusal is named, so that whoever runs it, by hand or through a hook, learns which node or list to change.
The links it makes
- implements → Where an agent writes, the checks run at each of its edits
- implements → What is checked, when, and what a failure costs
- implements → A procedure that writes the specification is idempotent
- implements → Outgoing links are written, incoming links are built
- implements → The nodes are the specification
- implements → Data structures are described in the specification
- cites → How a confirmation is recorded
- implements → Checked means its owner confirmed its present wording
- cites → How each check is made
- cites → The hooks
- cites → Building the map
- cites → What the export, the guide and
sheriff showwrite of a node - cites → Setting a repository up and taking SpecSheriff out of it
- cites → A link may cross a domain line
The decisions taken on it
- Problem
The types and runtime checks generated from the data record nodes had no command.
- Ruling
The owner: a command of their own generates them.
- Problem
The reindex read every file through a parser that keeps the last of two values under one key and drops the first, and wrote back what it read: a ruling written under a second decisions key of a node's metadata hid two earlier rulings on the same rule from every tool, and the next reindex would have deleted them.
- Ruling
The owner: the reindex merges the two values, names each merge, and refuses two it cannot merge, naming both.
- Problem
A command reported a citation as a candidate for a link nobody typed, and the citation check, which a commit runs, was named by no rule.
- Ruling
Following the owner's rulings on citations (§s-bpdqd9v72wg7vsz, §s-hr7j7scmfkkjnws): the command reporting candidates goes, and the citation check is named among the commands.
- Problem
The commands were one repository's package scripts.
- Ruling
The owner: they are the commands of the SpecSheriff tools, described in the appendix of the tools.
- Problem
The first sentence gave
sheriff bindingevery check between the specification and the code, though the table of how each check is made gives some of them to other commands.- Ruling
The owner: the sentence names the commands that check and leaves to that table which check each makes, so that it is said in one place.
- Problem
The rule on sheriff types said neither which files it writes nor what it refuses, and the tool rewrote every listed file at every run, though it now runs after every edit an agent makes and at every commit; the rule read as one block of text, and named the map without saying what it is.
- Ruling
The owner: sheriff types writes a file only where its content changes, names each file it writes, and writes nothing where anything is refused; the checks are implemented as the table describes them; the map is named as the mindmap of the specification's structure; each command stands in a paragraph of its own, sheriff init before sheriff reindex.
- Problem
sheriff types wrote the types and runtime checks from data record nodes whether or not they were checked.
- Ruling
Following the owner's ruling on §s-kh8qcd5kxgh9z3j: code generated from the nodes waits until every node it is generated from is checked, no commit changing it meanwhile, and its lag is reported.
The tests bound to it
- skills/tools/test/e2e/cli.test.ts · s-f5rz6b7dhxejjts an unknown command is refused, naming it
- skills/tools/test/e2e/cli.test.ts · s-f5rz6b7dhxejjts sheriff --version prints the version of the SpecSheriff tools
- skills/tools/test/e2e/cli.test.ts · s-f5rz6b7dhxejjts sheriff with no command lists the commands
- skills/tools/test/e2e/commands.test.ts · s-f5rz6b7dhxejjts sheriff export, render and guide write the export and the map and print the guidelines
- skills/tools/test/e2e/commands.test.ts · s-f5rz6b7dhxejjts sheriff reindex rewrites the files it changed and reports it
- skills/tools/test/e2e/commands.test.ts · s-f5rz6b7dhxejjts sheriff show prints a node by its sid or its address
- skills/tools/test/e2e/commands.test.ts · s-f5rz6b7dhxejjts sheriff types writes the types where the technical appendix lists them, and refuses what cannot be generated
- skills/tools/test/e2e/commands.test.ts · s-f5rz6b7dhxejjts sheriff validate passes what holds together and refuses what does not, naming where
- skills/tools/test/unit/generated.test.ts · s-f5rz6b7dhxejjts sheriff guide prints the SpecSheriff guidelines of this repository whole
- skills/tools/test/unit/json-text.test.ts · s-f5rz6b7dhxejjts keeps text it does not merge exactly as JSON.parse reads it
- skills/tools/test/unit/json-text.test.ts · s-f5rz6b7dhxejjts merges two lists into one holding the first's members, then the second's the first lacks
- skills/tools/test/unit/json-text.test.ts · s-f5rz6b7dhxejjts merges two objects key by key, each key where it was first written
- skills/tools/test/unit/json-text.test.ts · s-f5rz6b7dhxejjts merges two values JSON Schema holds equal into one
- skills/tools/test/unit/json-text.test.ts · s-f5rz6b7dhxejjts refuses two values it cannot merge, naming the key and each one's line and value
- skills/tools/test/unit/reindex.test.ts · s-f5rz6b7dhxejjts gives a sid to a node that has none, its address and sid first
- skills/tools/test/unit/reindex.test.ts · s-f5rz6b7dhxejjts merges the values an object holds under one key and names every merge
- skills/tools/test/unit/reindex.test.ts · s-f5rz6b7dhxejjts refuses two values it cannot merge and then writes no file
- skills/tools/test/unit/show.test.ts · s-f5rz6b7dhxejjts refuses a key no node holds
- skills/tools/test/unit/show.test.ts · s-f5rz6b7dhxejjts shows a node found by its address the same as by its sid
- skills/tools/test/unit/types.test.ts · s-f5rz6b7dhxejjts sheriff types writes no file while a data record node is unchecked, and names each such node
- skills/tools/test/unit/types.test.ts · s-f5rz6b7dhxejjts sheriff types writes only a file that is missing or holds, line endings aside, anything else than it generates, and names each