The Limits of the Boundary: Trust, Privacy, and Missed Coverage

RTK's compression is only as dependable as the boundary around it. When savings are missing, the cause may be a hook that is absent, an agent that can only follow instructions, an unsupported command, an intentional bypass, or a filter that needs review. This chapter separates those causes and then examines two less visible questions: who is allowed to define what an agent sees, and what information stays local versus leaving the machine. The result is a practical way to control RTK without treating its reduction percentage as the only outcome that matters.

Diagnose coverage before changing the filter

The first symptom of a coverage problem is simple: an agent runs cargo test or git status and the result looks like ordinary raw tool output. That symptom does not identify the cause. A missing or outdated hook can leave every supported command untouched. A rules-only integration may be installed correctly but still depend on the agent choosing the rtk prefix. A command may be outside RTK's registry, or a supported command may have been excluded, bypassed with RTK_DISABLED=1, or deliberately left raw because its arguments or shell context were unsafe.

The diagnosis should therefore proceed from the boundary inward. First verify that the right RTK binary is installed and that its command surface is available. Then inspect the agent integration status rather than assuming that a successful installation command registered a live hook. Finally, compare what the agent actually ran with what RTK recognizes. The project's installation and analytics commands serve different parts of this check: an initialization display can show whether a hook is present, while savings and missed-savings views reveal whether commands are reaching it in practice.

A command that appears in a missed-savings report is not automatically evidence of a broken filter. If RTK does not support that command, there is no existing compact route to apply. If the command is listed as a bypass or an exclusion, the raw result may be exactly what the user requested. If the command is supported but the hook did not rewrite it, the remedy is likely integration or configuration rather than a new output parser. Keeping these cases separate prevents a user from weakening a good filter to compensate for a hook that never ran.

The integration tier changes the confidence of the diagnosis. A full hook receives a pre-execution event and can return an updated command before the host launches it. A plugin can mutate the terminal command through the host's plugin API. A rules-only installation can only tell the agent to type the RTK form itself. The first two provide a mechanism that can be observed at the command boundary; the third provides guidance whose success depends on agent behavior. A low coverage result is therefore more informative when paired with the tier: it tells the operator whether to inspect hook registration or the agent's adherence to instructions.

The failure behavior makes this distinction easy to miss. RTK's hooks are intended to fail open.