hivehouse: bubble-review

Run hh-resolve rules and hh-resolve role reviewer and read the files they print first (the project's or the user's own custom/ file when there is one, else the plugin's). A bubble is anything in a diff that fits one of the nine categories in ${CLAUDE_SKILL_DIR}/categories.md; read that file before a standard or full review. You are read-only: you change no code in any worktree.

Call every hh-* executable and every git command on its own, never inside a compound command. No git rule is pre-approved, so each git call asks. Test runs go through hh-slot run, which is not pre-approved and will ask; that is intended.

Depth

The orchestrator states the depth in the request. You may raise it with a reason; never lower it.

If no depth is stated, ask; if you cannot ask, take standard and say so.

Procedure

1. Task and diff. Read the task first, then git log <base>..<tip> and git diff <base>..<tip>. Note every file and function changed and whether it is the right place.
2. Scratch copy. Work in a scratch directory, never the builder's worktree or the main tree: git archive -o <scratch>.tar <tip>, then tar -x -f <scratch>.tar -C <scratch> (two commands, no pipe). Save a copy of any file before you break it and restore it with cp, never git checkout.
3. Gate log. For a log hh-gate wrote: hh-gate-verify log <file> --commit <tip>. For a project's own headerless log: hh-gate-verify log <file> --expect <steps> instead, never with --commit (that is always RED), and say in the verdict that the log names no commit. Then the commit rules with hh-gate-verify commits <base>..<tip> --style <style> --attribution <allow|deny>, each value from hh-settings resolve, so a project cannot loosen the owner's.
4. Changed tests only, through hh-slot run --wait <label> -- <command>. Do not run the whole suite unless asked.
5. Break each new guard with one change: count that the change matched exactly once, confirm the test fails, restore by copy. A break that matched twice or not at all is not evidence.
6. Scan the nine categories against the diff (full bubble: probe each with a concrete input). Look also at what consumes each changed thing (callers, other services, exports), not only the changed lines.
7. Second opinion (a read-only Codex run or a Fable subagent) only when the orchestrator relays the owner's request for one. Treat its findings as claims to verify, not verdicts.

Verdict

First line: PASS or FAIL, the depth, and the tip hash reviewed. Then findings grouped by category, each with file:line and the evidence, as:

• REQUIRED: blocks landing;
• SHOULD: fix soon, does not block;
• NOTE: information.

Then what you did not run and why (unrun checks are never implied). FAIL if any REQUIRED exists.