Hooks, Harnesses, and the Cost of Feedback
A detector finding becomes useful at a different moment depending on the host that receives it. Impeccable's hooks turn part of the rule registry into edit-time feedback, but the project does not pretend that Claude Code, Cursor, Codex, GitHub Copilot, and other harnesses expose the same control surface. This chapter compares those delivery choices and the engineering work behind them. The practical judgment is not which harness is best in the abstract, but how much interruption, blocking, and manual follow-up a particular installation can support.
Immediate feedback is deliberately narrow
The hook's immediate tier contains problems that are mechanical, unambiguous, and cheap to correct at the edit site. Broken images, text overflow, clipped positioned children, low contrast, gray text on color, tiny text, gradient text, glow shadows, and design-system drift fit that description. The hook can surface them after a write because the finding does not require a long debate about the product's visual direction.
Other rules wait. Copy cadence, palette taste, typography character, and broader layout rhythm can be important, but interrupting every edit to argue about them would make the feedback loop unusable. A hook that reports five subjective concerns after every small change trains the agent to ignore the whole message. Impeccable therefore separates immediate checks from a deeper pass. Claude Code, Codex, and GitHub Copilot can run a full Stop-time pass where supported. Cursor's pre-write path evaluates the proposed content before the write lands. Harnesses without a documented hook surface receive a manual-detector instruction instead.
The distinction is about timing, not seriousness. A copy rule deferred to a deep pass is not necessarily less important than a broken image. It is simply less useful before the agent has finished a coherent edit. Conversely, a blocked write in Cursor is not proof that the design itself is wrong. It is a mechanical signal that the proposed content violated a configured rule. The agent still needs to inspect the context and decide whether to repair, ask, or record a narrow exception.
Blocking and non-blocking feedback create different costs. Cursor can deny a proposed write and show the finding before it lands. That gives the agent an immediate chance to reconsider, but it can also interrupt a deliberate fixture or a sanctioned visual exception. Claude Code, Codex, and GitHub Copilot generally let the edit land and add context afterward. That preserves momentum and makes the hook a reviewer at the boundary rather than a gate in front of every write. The right behavior depends on whether a team values prevention before the file changes or a lower-friction stream of corrections after the change.
Imagine an agent editing a component that contains both a real product button and a deliberately bad example used to teach the detector. A pre-write block may stop the whole proposed file even though only the fixture is meant to violate a rule. A post-edit hook can let the change land, identify the finding, and let the project use a narrow file or value exception. Neither behavior is universally correct.