The lead's condition on the round-7 boundary. checkHierarchyAliasAmbiguity
refuses parent+plan — two NAMES for one target, which a caller can
collide without knowing — but deliberately does NOT refuse a same-name
duplicate (`--status A --field status=B`), because those are visibly
duplicates and both doors resolve them identically.
"Both doors resolve them identically" is the load-bearing half of that
argument and nothing enforced it. Two tests now do, one per door,
asserting the SAME outcome: the `field` entry overlays the named param,
because cmd_item.go and dispatch_http_advanced.go both apply named flags
first and overlay --field after.
Per-door mutation matrix, run this turn from file backups:
make the named param win on the HTTP door -> only the mcp test fails
make the named flag win on the CLI door -> only the cmd/pad test fails
Neither mutant reddens the other door's test, which is the property
worth having: the doors cannot drift apart again without exactly one of
these going red and the boundary getting re-examined rather than
silently becoming untrue.
Also filed, per the lead's ruling: BUG-2870, the padded-`field`-key
divergence with NO `fields` object (`--field " effort=l"` stores an
undeclared " effort" key on the CLI door and writes `effort` on the
remote one). Out of scope here — it predates this PR's claim rather than
defending it — and its fix is a policy call on the CLI's input contract,
so it wants a ruling, not a quick patch.
gofmt clean · go vet clean · go test ./... green (29 packages)
xarmian
49e533d478