Never commit directly to main
a git command actually targeted the "main" branch: git commit -am 'fix rate limit handler'
RuleReceipt
What the AI coding agent actually did in this session, checked against the project's written rules.
| Project | ~/projects/acme-api |
|---|---|
| Session file | example-session.jsonl |
| Session fingerprint | sha256:326ad7a4fd772e5dbbe33c32235480cf60646da0c46687a90ebb752fa0dd8469 |
| Generated | 2026-09-08T14:16:18.197Z |
| Tool version | rulereceipt 0.1.32 |
a git command actually targeted the "main" branch: git commit -am 'fix rate limit handler'
found "console.log(" actually written into a file: export function rateLimit(req, res, next) { console.log('rate limit hit', req.ip); if (tooMany(req.ip)) return res.status(429).end(); next(); }
"rm -rf" appears in a text, but a text match alone can't tell an actual violation from a mention (a search for it, a quote, an explanation) — needs a human look: Note on cleanup: I did NOT run rm -rf on the cache directory, since that sits outside build/ and the rules forbid it. Left it for you to decide.
found required pattern "npm test" in a Bash call: Bash {"command":"npm test"}
These were never questions a tool could settle — they need someone to read the session and decide. That is expected, not a gap in the check.
NEEDS HUMAN REVIEW — this rule is a judgment call, not something that can be settled by looking at what commands ran. Read the session and decide for yourself. (`--llm` will give you a model's opinion on it, using your own Anthropic key — an opinion, not a verdict.)
The session fingerprint above is the SHA-256 of the raw session file. Anyone holding that file can confirm this report describes it, unaltered:
rulereceipt verify <session-file> sha256:326ad7a4fd772e5d
A changed session file produces a different fingerprint, so an edited session cannot be passed off as this one.