Follow-up from WS-144 / PR #21 review.
When a skill declares constrained tools with parentheses on the deny side, e.g. disallowed-tools: bash(git push:*), current matching treats unsupported bracket constraints as no match, which can become fail-open for deny-list semantics. Desired behavior: unsupported constraints should fail closed in both directions: allow-list should not grant broad tool access, while deny-list should block the whole tool if the constrained declaration cannot be enforced precisely.
Suggested direction from review: match constrained declarations by their head tool name case-insensitively, then let tool policy distinguish allow vs deny behavior so allow constrained declarations hide/deny broad access, while deny constrained declarations block the whole matching tool.
Non-blocking P3 discovered after PR #21 approval.
Follow-up from WS-144 / PR #21 review.
When a skill declares constrained tools with parentheses on the deny side, e.g.
disallowed-tools: bash(git push:*), current matching treats unsupported bracket constraints as no match, which can become fail-open for deny-list semantics. Desired behavior: unsupported constraints should fail closed in both directions: allow-list should not grant broad tool access, while deny-list should block the whole tool if the constrained declaration cannot be enforced precisely.Suggested direction from review: match constrained declarations by their head tool name case-insensitively, then let tool policy distinguish allow vs deny behavior so allow constrained declarations hide/deny broad access, while deny constrained declarations block the whole matching tool.
Non-blocking P3 discovered after PR #21 approval.