The short form said bypass where the long form says narrower

[tobert]

Reading the 0.17.0 release notes, Amy asked whether wrapped commands bypass allow_external_commands. They do not, and the notes said they did because they were quoting our changelog.

The long form has always been right. docs/wrapped_command.md says the switch has two settings — nothing spawns, or everything on $PATH spawns with any arguments — and that a wrapped command is the setting between. Every short restatement dropped that and kept only the half that reads as a hole:

CHANGELOG.md          "Runs with allow_external_commands off."
docs/wrapped_command  "It runs when allow_external_commands is false."

Both sentences are true. Both invert the feature, because a reader who meets a policy switch and a thing that runs regardless concludes the thing defeats the switch. The direction is the load-bearing half and it was the half that kept getting cut for length.

The behavior was never in doubt, and a test already discriminates it: wrapped_command_exec_tests.rs:373 runs /bin/true two ways in one kernel, once as a registered wrapper and once as a bare command, and asserts the wrapper runs while the bare command is still refused.

The module doc gained the statement outright. It is the docs.rs entry point for an embedder deciding whether to register a wrapper, and it described the mechanism while saying nothing about the policy the mechanism serves — which is what that reader is actually deciding about.

The rule going forward: a one-line summary of wrapped commands carries "narrower, not wider," or it teaches the opposite of what the feature does.

Gates: clippy -D warnings, cargo test --all, rustdoc -D warnings.

[tobert]

I feel like we should rename allow_external_commands to allow_path_commands or something like that so that it's distinct from wrapped commands.

[tobert]

Good idea — that flag name is exactly the thing this PR's confusion was rooted in. Queuing it for 0.18 rather than folding it into this docs fix or this morning's micro bump: it's a public field on the capability surface (~15 call sites across kernel/dispatch/scheduler/builtins/docs/tests), so the rename is breaking and deserves its own PR with a migration note. Recorded in exomemory (kaish/0.17.1-queue.md, item 9). 🤖