merge-guard: substitution-carrier operator class slips per-leg matching — accepted residual (all 4 families), disposition record

[michael-wojcik]

Disposition record — accepted residual, all four per-leg families

Class: shell-substitution/backtick carriers holding a leg operator between a git subcommand and its dangerous flag, e.g.:

git branch $(x && y) -D temp
git push `a || b` --force origin main

_split_into_legs does not parse substitution nesting, so the operator inside $()/backticks splits the command into legs that separate the subcommand from its flag — per-leg literal arms match neither leg, and the form goes ungated. Whole-command matching caught these by accident of .* span.

Why this is accepted, not fixed

• Parity, not regression: empirical sibling probes (PR merge-guard: cure branch-delete cross-leg over-block via per-leg literal arms (v4.4.54) #1102 security review) confirmed the identical class already slips on base for the force-push, close, and API per-leg families (converted v4.4.51–v4.4.53). PR merge-guard: cure branch-delete cross-leg over-block via per-leg literal arms (v4.4.54) #1102 extends the existing residual to the 4th family; it does not open a new channel.
• The only complete re-gates are worse:
  1. whole-command matching — re-creates the cross-leg over-block (cardinal-sin direction under the honest-mistake charter) that the four per-leg conversions exist to cure;
  2. substitution-aware leg parsing — a shell-parser re-architecture requiring its own RFC-grade risk analysis; a per-carrier denylist patch would be the known enumeration anti-pattern (structurally uncompletable).
• Threat model: the merge-guard defends against honest mistakes; an honest agent does not carry a destructive flag past an operator hidden inside a substitution. Severity LOW by the control's own model.

What this issue is for

Audit-trail documentation so future security reviews do not re-litigate the class family-by-family. If a substitution-aware substrate is ever proposed, it must carry a bidirectional certification (no new over-block on ANY faithful single-command click — the PRIMARY inviolable gate — plus the no-new-under-block sweep) across all four families at once.

Surfaced and attributed by the blind security review of PR #1102 (SE-1, LOW).