question: v0.10.2 claude-args asymmetry — review lane lost inline-comment tool, security lane kept it

[kyle-sexton]

In v0.10.2, the review reusable's claude-args default REPLACED --allowedTools "mcp__github_inline_comment__create_inline_comment" with --allowedTools "Bash(gh pr diff:*)", while the security reusable's default ADDED the Bash grant alongside the inline-comment tool ("mcp__github_inline_comment__create_inline_comment,Bash(gh pr diff:*)").

Consequence: consumers inheriting defaults (all of them — claude-args is not caller-passable; allowedInputs excludes it) now have a review lane that cannot post inline comments while the security lane still can. If the asymmetry is intentional per the #355 decision, close this with a pointer; if not, the review lane default likely wants the inline-comment tool restored alongside the Bash grant.

Observed by the fresh-context merge verifier on melodic-software/claude-code-plugins#1990 during the fleet repin (sandbox, standards, and claude-code-plugins callers all inherit this now).

[kyle-sexton]

Closing: the premise does not hold. The review lane never lost inline-comment capability at v0.10.2 — its "Compose Claude CLI arguments" step appends --allowedTools mcp__github_inline_comment__create_inline_comment unconditionally after caller/default args, and both invocations consume the composed output, so no caller value can drop the grant. The observation in this issue read the caller-replaceable claude-args default alone, which is exactly the surface the compose step exists to make non-load-bearing (its own input description says so).

The REAL asymmetry was the mirror image: the SECURITY lane carried both grants only in its replaceable default, so a caller overriding claude-args could silently drop the inline-comment tool there. Hardened in PR #395 (merge ee96bd2): the security lane now has the same drop-proof compose shape, and a new test pins the compose contract in BOTH lanes so this asymmetry class cannot silently return. Union semantics of repeated --allowedTools flags were verified empirically on that PR's own run (both grants present in the resolved tool set).

Closed by an AI agent under the operator's standing authorization (goal directive 2026-08-08/09).