Found and verified during the overengineering plugin discovery pass (topic: docs/topics/overengineering-detection-skill/PLAN.md).
Finding. A hook script can sit checked-in under .claude/hooks/ with documentation claiming enforcement while .claude/settings.json no longer wires it — and nothing notices. All 38 ci.yml jobs were checked: none asserts wiring liveness for repo-local hook scripts. The live specimen is #2959 (pr-linkage-mcp-gate.sh, unwired since #2188 with a stale header), which survived undetected across many subsequent PRs.
This is one of three independent liveness questions the discovery pass established for any enforcement artifact — source posture (what the code says it does), wiring (whether anything invokes it), and runtime enforcement (whether invocations actually complete — cf. ADR 0004's D-12 errata, tracked via #1379/#1403). The wiring question is the one with zero current coverage.
Deliberately filed as a finding, not a prescriptive "add a CI gate." Per this repo's enforcement-hierarchy doctrine (/claude-config:audit-automation-gaps default-REJECT; docs/PLUGIN-PHILOSOPHY.md instruction economy), a new standing check must earn its place. Candidate resolutions for triage, cheapest first:
- Cover it via the planned
overengineering:audit skill's liveness dimension (on-demand, no standing CI cost) — the plugin's Brief already treats wiring as a first-class audit question.
- A one-line assertion inside an existing lane (e.g. the hygiene lane greps
.claude/hooks/*.sh against settings.json hook commands) — near-zero marginal cost, but adds to the surface this whole effort exists to shrink.
- Accept the risk and rely on periodic audits — defensible given the class has produced one known instance with a safe outcome (the plugin copy still enforced the policy).
Recommend option 1 with option 3 in the interim, i.e. no new standing enforcement until the audit skill exists and its evidence says otherwise.
Found and verified during the
overengineeringplugin discovery pass (topic:docs/topics/overengineering-detection-skill/PLAN.md).Finding. A hook script can sit checked-in under
.claude/hooks/with documentation claiming enforcement while.claude/settings.jsonno longer wires it — and nothing notices. All 38ci.ymljobs were checked: none asserts wiring liveness for repo-local hook scripts. The live specimen is #2959 (pr-linkage-mcp-gate.sh, unwired since #2188 with a stale header), which survived undetected across many subsequent PRs.This is one of three independent liveness questions the discovery pass established for any enforcement artifact — source posture (what the code says it does), wiring (whether anything invokes it), and runtime enforcement (whether invocations actually complete — cf. ADR 0004's D-12 errata, tracked via #1379/#1403). The wiring question is the one with zero current coverage.
Deliberately filed as a finding, not a prescriptive "add a CI gate." Per this repo's enforcement-hierarchy doctrine (
/claude-config:audit-automation-gapsdefault-REJECT;docs/PLUGIN-PHILOSOPHY.mdinstruction economy), a new standing check must earn its place. Candidate resolutions for triage, cheapest first:overengineering:auditskill's liveness dimension (on-demand, no standing CI cost) — the plugin's Brief already treats wiring as a first-class audit question..claude/hooks/*.shagainstsettings.jsonhook commands) — near-zero marginal cost, but adds to the surface this whole effort exists to shrink.Recommend option 1 with option 3 in the interim, i.e. no new standing enforcement until the audit skill exists and its evidence says otherwise.