feat(audit): hot-key custody rule — the deploy key deploys and holds NOTHING (#81) - #82

No actionable comments were generated in the recent review. 🎉

Walkthrough

The audit skill moves to version 0.34.0. It adds hot-key custody rules for governance ownership, per-chain handoff checks, and negative role assertions. The plugin manifests use the same version.

Changes

Audit skill rules

Estimated code review effort: 2 (Simple) | ~5 minutes

Possibly related PRs

• rainlanguage/claude-audit-skills#1: This PR also updates skills/audit/SKILL.md and plugin metadata in the same area.
• rainlanguage/claude-audit-skills#26: This PR also updates audit skill and plugin version fields in the same three files.

Suggested labels: ai:ready

Suggested reviewers: claude

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Reviewed 3935673: ready

Verified before merge: version-hygiene SUCCESS, CodeRabbit SUCCESS reading Review completed (not Review rate limited, so the zero-threads is real coverage), 0 unresolved threads, all three version strings at 0.34.0. I read the final rule in the tree rather than relaying the reports.

The rule carries the human's ruling — "the deployer should generally be considered hot wallet, so it shouldn't be in the middle of auth dances, it just needs to deploy and that's it" — as three flags plus non-findings, grounded throughout in the live instance: the ~18 days st0x.deploy's hot key held all seven _ADMIN roles, the grant/renounce batch decoded from the key's own tx history, and #250 as the reference implementation.

TEN defects were fixed on this branch, all one class: a concrete clause narrower or looser than the rule it serves. Two found by CodeRabbit, one by me, seven by sweeping for more of the same. In order: "passed as an init argument" citing a sibling rule that FORBIDS constructor args; the CREATE/CREATE2 non-finding exempting the rule's own primary example; the single-key-governance non-finding not excluding the BROADCASTING key itself; the negative assertion enumerating AccessControl roles only; its diagnostic still saying "roles" after the requirement widened; the opening and a worked example still saying "role graph"; the first non-finding RESTATING the seating requirements instead of deferring to them; msg.sender named as the tell when inside a factory-deployed clone msg.sender is the FACTORY; "Three flags, all shapes of the one defect" over-claiming once the opening became normative on atomicity; and "structurally inert" being wider than the rule's own boundary word EXPOSE.

Two of those are worth calling out because they changed the shape rather than the wording. The seventh was fixed at the CAUSE: the non-finding now DEFERS ("deploy transactions meeting the seating requirements above") instead of re-listing, so a requirement added upstream cannot fall out of it — there is no list left to fall behind. And the ninth was fixed by PROPERTY rather than token: initialAdmin/owner "taken from the calling context instead of an explicit governance argument", with msg.sender and tx.origin as the greppable examples of it rather than the definition.

The introduction now states what the structure actually is — "Everything above is normative on its own; the three flags below are the shapes the hot-key defect takes, not a checklist that exhausts the rule — an instance a stranger can still initialize trips it with no key compromised and no flag matched." A fourth flag was declined three times, finally on the strongest ground: it would carry a SECOND COPY of the atomicity requirement and its fix, reintroducing by construction the restatement hazard the seventh fix had just cured.

A requirement-by-clause matrix (governance principal / from-block-one / atomic-with-creation / holds-no-authority-exposed, against all three flags and all three non-findings) was run over the final text; the one intentionally partial cell is flag 1's atomicity coverage, which is exactly what the softened introduction exists to disclose.

Cross-rule coherence checked rather than assumed: no contradiction with Deterministic production deployments (the instance/implementation partition is that rule's own), Deploy-pin completeness & release historicals (flag 2's per-chain fork assertion is its item-(b) shape, and it borrows its network-set convention verbatim), or State-changing scripts carry a pranked fork test (flag 1 states precedence explicitly). Length balance holds and the opening is not the longest element.

Still +9/-3 after ten fixes — the rule absorbed all of them without growing.