The abcd guard coverage prose in three user-facing places still describes the pre-gh-312 backtick limitation: guard.go's 'guard check --help' string and the generated docs/reference/cli/commands.md say the top-level backtick substitution is not followed (a disclosed v1 limit, iss-148), and commands/guard.md lists 'one inside a backtick substitution' among what an allow does not see. The gh-312 fix now follows top-level backticks into command position like the dollar-paren form, which the v0.6.7 Security changelog advertises — so the shipped help and docs contradict the release's own changelog and under-report a security capability.

Frontmatter

.abcd/work/issues/resolved/iss-2608271140346423-the-abcd-guard-coverage-prose-in-three.md
open on GitHub ↗ · commit history ↗

mentions1

• iss-148guard registry coverage gaps found while wiring itd-103 (registry content, not matching semantics): a push whose refspec carries a leading plus is a force in disguise and no entry describes it; xargs, timeout and exec are absent from the matcher's wrappers set, so a hazard launched through one of them is not seen; a backtick command substitution is not followed, while the dollar-paren form is; and a wrapper that IS in the set defangs an entry the moment it carries its own flags, because only the wrapper name is stepped over — `sudo <hazard>` is seen, `sudo -u bob <hazard>` is not, and the same holds for `env -i` and `time -p`. That last one is the sharpest: it turns an entry the registry does describe into an allow with one extra token, and it is the only item here that a facilitator would reasonably assume was covered. Candidates for the admission gate as the registry grows from reality; the wrapper-flag item is matcher-side (`commandOf` in internal/core/guard/match.go), not registry content.