Checkpoint: Smaller Context Must Still Be Trustworthy

RTK's hook, rewrite registry, and shell-aware boundaries now point to one practical question: when is a shorter result a trustworthy result? This checkpoint connects authorization, command semantics, and output usefulness into a single test. The goal is not to repeat how each component works, but to give readers a way to evaluate an RTK path they encounter in practice and to identify the evidence that a later filter must preserve.

The path needs three independent tests

A command can be recognized by RTK without being safe to rewrite. It can be safe to rewrite without producing a useful summary. It can produce a compact summary without being authorized to change the host's command. Treating these as one question is the source of many misleading intuitions about command proxies. RTK's design is easier to understand when the path is tested in three layers: authorization, command semantics, and output usefulness.

flowchart LR A["Agent command"] --> P["Host permission gate"] P -->|"allow"| S["Shell-safe classification"] P -->|"ask"| Q["Host prompt"] P -->|"deny"| R["Raw command path"] Q -->|"approved"| S Q -->|"declined"| R S -->|"safe rewrite"| X["Execute RTK form"] S -->|"defer or unsupported"| R X --> O["Filter output"] O -->|"compact and useful"| C["LLM context"] O -->|"no advantage or unsafe"| R R --> C U["User exclusion or bypass"] --> R

Authorization comes first. The host's permission model answers whether a command may be changed and whether the change may be approved automatically. RTK's decision logic gives deny rules precedence over ask, explicit allow, and the default. A recognizable git status is not thereby authorized. When no permission rule matches, the default remains ask rather than becoming an implicit allow. For a compound command, every non-empty segment must independently satisfy an explicit allow condition before the request can be auto-approved. This prevents a harmless-looking first segment from lending authority to a second segment that the host has not examined.

Authorization is about who may cause the command to run, not about how much text the result will contain. A host can ask a user to approve a rewritten command even when the output filter is known to be reliable. Conversely, a filter can be perfectly good at summarizing a test run but still be inappropriate to apply if the host's deny rule says the original command must be stopped. Keeping the two decisions separate is what allows RTK to reduce context without taking over native command control.

Command semantics come next. The registry must establish that inserting the RTK route does not change what the shell or underlying tool will do. That is why RTK tokenizes operators, redirects, quoted text, and arguments instead of treating the command as a single string prefix. A chain joined by && can be considered segment by segment while the shell retains responsibility for sequencing.