feat(miner): synthesize PreToolUse deny-hook rules from the review stack's own per-repo close/blocker finding-category history

[JSONbored]

Context

A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that the miner's PreToolUse deny-hook rules are a static, hand-authored rule set, even though the review stack already has real per-repo history of what actually gets blocked or closed that could keep those rules current automatically.

Evidence

• packages/gittensory-miner/lib/deny-hooks.js:124-141 — DEFAULT_DENY_RULES is a hand-authored, hardcoded array; packages/gittensory-miner/lib/deny-check.js (the CLI wrapper) only ever calls evaluateDenyHooks() with the default rules — no loader for external/dynamic rules exists.
• The taxonomy that actually matters for this synthesis is blockerCodes/scoreBlockers (src/rules/advisory.ts's GateCheckEvaluation, persisted via blocker_codes_json in src/db/schema.ts) — the review stack's own real, per-repo history of what blocks or closes a PR.
• That blocker-code history is already piped to the miner today, but only as display text: src/services/miner-dashboard-recommendations.ts renders it as a human-readable "Rerun after validation blockers change: ..." string for a dashboard, not as a machine-enforceable rule.
• Issue maintainer: PreToolUse-hook-enforced house rules (deny even under bypassPermissions) #2343 ("PreToolUse-hook-enforced house rules," still open) only asks for rules "sourced from a single, auditable list" — no dynamic-derivation requirement — confirming this synthesis job doesn't exist and isn't yet in scope anywhere.

Why this matters for the Autonomous Miner System

Gittensory already classifies every review finding and has per-repo history of what blocks a PR (gate-advisory blockers) and what gets a PR closed. Today there's no path from "this repo's live gate has blocked N PRs for touching CHANGELOG.md" or "for missing a linked issue" to an automatically-refreshed local deny-hook rule the miner's coding agent is bound by before it ever attempts the violating action. This is a differentiator no review-only competitor could build, since it requires controlling both the autonomous submitter's own tool-call interception layer and the PR review side of the same pipeline — gittensory already has both halves, just no synthesis job connecting them.

Deliverables

• Build a job that derives candidate deny-hook rules from a repo's own blocker-code/close-reason history (e.g. "N closes for touching path X" → a path-based deny rule), shaped to match DEFAULT_DENY_RULES's existing rule format
• Feed the synthesized rules into the consumption point maintainer: PreToolUse-hook-enforced house rules (deny even under bypassPermissions) #2343 builds (a refresh mechanism, not a one-time generation), with a clear audit trail for why each rule exists
• Keep this advisory/opt-in and bounded — a bad synthesis shouldn't be able to silently block a miner's legitimate work; consider a maintainer-reviewable proposal step before a synthesized rule takes effect
• Tests: rule synthesis from a synthetic blocker-code history produces sane, correctly-shaped rules; a repo with no history degrades to the existing static defaults

---

Surfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Depends on / feeds into #2343 (PreToolUse-hook-enforced house rules) — this issue is the "keep the rules current automatically" companion to that issue's "enforce a rule list" scope.

[linear-code]

JSO-3349