RUL-023 — A feature request means the thing is WIRED, not that code exists

Ruling

"when I ask for a feature that means wiring the damn thing not just code vomit" (verbatim, 2026-07-27).

When Mohamed asks for a feature, the deliverable is the feature working in production, not a module that would work if something called it. Specifically, none of the following is a delivery:

• a module that nothing imports from a production entrypoint;
• a hook file that is not registered in .claude/settings.json;
• a git hook that is not installed (core.hooksPath not pointing at it);
• a gate script that no runner, hook or health_check.py check invokes;
• a capability that exists only on an unmerged branch or inside a worktree;
• an installer written but never run.

"Built but not activated" is an unfinished task, and reporting it as complete with an activation step left for the user is the failure this ruling names. If activation is genuinely blocked — a shared config another branch owns, a credential only the human holds — the work stays open, the blocker is stated plainly, and it is not counted as done.

This sharpens RUL-012 from a definition of done into a rule about what a request means: the wiring is not a follow-up task to be logged, it is part of the thing that was asked for.

Evidence

2026-07-27, in a single session, three capabilities were built and reported while inert:

• scripts/hooks/pre-push — a guard that refuses to run the suite on a protected branch, written and tested, but core.hooksPath still pointed at the old untracked hook. The guard could not fire.
• .claude/hooks/require-design-before-build.sh (RUL-022) — built in a worktree's tracked .claude/settings.json, so the live dispatcher never loaded it.
• scripts/check_worktree_envs.py (RUL-021) — wired into health_check.py correctly, and reported at the same time as the two above, which is precisely why "wired" and "written" must not be reported in the same voice.

Prior art in the same repo: SPEC-110's codemod engine is unwired by design, and plans/spec-110-merge-plan.md records that its import errors "can hide" because nothing imports it — an unwired module does not even fail loudly when it breaks.

Enforcement

• gate scripts/health_check.py check_wiring

Verification

scripts/health_check.py's check_wiring fails when, for the current branch's diff against master:

• a new .py module under src/ is imported by nothing reachable from a production entrypoint (the existing orphan-module analysis);
• a file added under .claude/hooks/ is not referenced by .claude/settings.json;
• a file added under scripts/hooks/ is not referenced by scripts/hooks/install-git-hooks.sh;
• a scripts/*.py gate declared as a mechanism by any ruling is invoked by no hook, runner or health check.

Each failure names the artifact and the wiring site it is missing. The check is branch-scoped so it grades what this change added, not the whole tree's history.