trust

This is a human-invoked setup command. Agreeing to run a repository's shell command is a human act: no other skill or agent - flow explicitly, and /harmonia:onboard in particular - runs it or bash ${CLAUDE_PLUGIN_ROOT}/bin/trust.sh record on the developer's behalf. Onboarding proposes a coverage: value; this command is what makes it runnable, and only the developer types it.

Run the recorder against the repository the developer is in and surface its output verbatim:

bash ${CLAUDE_PLUGIN_ROOT}/bin/trust.sh record --repo .

It prints the exact command it is about to make executable, on its own line and byte for byte, before writing. Read that line and decide. It is a shell command the coverage gate will run from the repository root at every implement round, at review and in the quick lane, so read it the way you would read a Makefile target or a package.json script.

Consent covers that string, and no file. The record holds the tree's path, the sha256 of the command exactly as the gate will run it, and the date. Change one byte of the command and the gate refuses until a human agrees again. Change anything else and it does not.

So pointing coverage: at a script means trusting that script's contents on every future run, including contents that arrive after you agreed. sh .harmonia/cov.sh && echo cov.xml is consent to run whatever .harmonia/cov.sh holds at the moment the gate runs it - and a repository you clone can change that script with an ordinary commit, with the coverage: line you read left exactly as you read it. A git pull, an npm ci and a rebuilt virtualenv all do the same thing without a commit. Nothing in the gate looks at any file's contents; only the string is watched.

Earlier versions of this file promised more: that the record covered the contents of the scripts the command ran, so a rewritten script refused. The promise could not be kept and is withdrawn rather than restated. .harmonia/cov.sh's whole job is to run the repository's test suite - hundreds of files no record ever covered - so the digest stopped a rewrite of one file and nothing behind it, and getting past it took no attacker and no skill.

What you do get is that nothing runs unread. The exact string was printed and agreed to; it is short enough and plain enough to read; its first word per part is the program; a word where a file belongs is a file rather than an option; no word reaches through a .. path component; and any edit to it stops the gate until a human agrees again.

Most commands cannot be recorded, and that is the point. The recorder refuses the value outright, with the offending word and the remedy, while you are there to read it: a value nobody can read honestly is worse than one nobody can run.

interpreters: sh bash dash python python3 node
inert: echo true
bytes: 1024
words-per-part: 64
byte-class: 0x20-0x7e

That card is one block carried identically by this file, SECURITY.md, skills/onboard/SKILL.md, skills/onboard/CERTIFY.md and bin/trust.sh, and checked against what the recorder admits. Around it: a recordable value is bytes from the card's byte class, up to the byte cap, split by ;, &&, || and | into parts of at most the word cap, every word made of letters, digits and _ . , : = + @ / - (or that inside one matching pair of quotes) and none of them carrying a .. path component - --out=../x and a..b are ordinary words and are fine; ../x and src/../lib are not. Every part starts with one of:

• an interpreter from the card, bare and exact - sh, not /bin/sh and not ./sh. Its next word is the script it runs, must carry a /, must not begin with - or +, and must not sit under /dev/ or /proc/ (sh /dev/stdin hands the interpreter the pipe beside it instead of a file). Later words go to that script.
• cd <dir> - first part only, one operand, followed by &&, <dir> relative. An absolute one is refused because it is the one cd shape decidable from the string alone and costs a single rule; where a relative name leads is a fact about your tree, and nothing here asks the tree anything.
• an inert word from the card.