Summary
Two precedence gaps introduced by the (correct) resolution rework in PR #131, both in src/core/resolution/resolve.ts, both turning previously-deterministic resolutions into hard ambiguous failures (exit 5):
1. No exact-match tie-break after eqIgnoreCase (team :67, user :116, label :185)
In 0.6.x, --team Ops with teams "Ops" and "OPS" resolved exactly via eq. Now eqIgnoreCase matches both and the resolver throws ResolutionError("ambiguous"). Users are worse: the or across email/name/displayName with eqIgnoreCase means a value matching one user's name and another's displayName now hard-fails where exact eq previously disambiguated. The project resolver got an exact>prefix>substring tie-break (resolve.ts:337-341); team/user/label got none.
2. Team label vs same-named workspace label (resolve.ts:186-189)
Including workspace labels under --team was the intended fix for #116, but with no precedence: team label bug + workspace label bug now returns 2 nodes -> ambiguous. In 0.6.x, --label bug --team X deterministically resolved to the team's label. Breaks existing scripted invocations in workspaces with shadowed label names.
Suggested fix
Within the case-insensitive result set: prefer case-sensitive exact matches; for users, prefer email matches; for labels under a team scope, prefer the team-scoped label over the workspace label. Only declare ambiguity when ties survive those preferences. Mirror the project resolver's existing tie-break pattern.
Summary
Two precedence gaps introduced by the (correct) resolution rework in PR #131, both in
src/core/resolution/resolve.ts, both turning previously-deterministic resolutions into hardambiguousfailures (exit 5):1. No exact-match tie-break after eqIgnoreCase (team :67, user :116, label :185)
In 0.6.x,
--team Opswith teams "Ops" and "OPS" resolved exactly viaeq. NoweqIgnoreCasematches both and the resolver throws ResolutionError("ambiguous"). Users are worse: theoracross email/name/displayName witheqIgnoreCasemeans a value matching one user's name and another's displayName now hard-fails where exacteqpreviously disambiguated. The project resolver got an exact>prefix>substring tie-break (resolve.ts:337-341); team/user/label got none.2. Team label vs same-named workspace label (resolve.ts:186-189)
Including workspace labels under
--teamwas the intended fix for #116, but with no precedence: team labelbug+ workspace labelbugnow returns 2 nodes -> ambiguous. In 0.6.x,--label bug --team Xdeterministically resolved to the team's label. Breaks existing scripted invocations in workspaces with shadowed label names.Suggested fix
Within the case-insensitive result set: prefer case-sensitive exact matches; for users, prefer email matches; for labels under a team scope, prefer the team-scoped label over the workspace label. Only declare ambiguity when ties survive those preferences. Mirror the project resolver's existing tie-break pattern.