fix(workflows): state the equal-priority tie-break in workflow resolve output

[jawwad-ali]

Problem

workflow resolve prints the layer list under a bare header:

console.print("Layers (highest precedence first):")

collect_all_layers sorts by (priority, source) ascending, which puts the winning layer first only while priorities differ. On a tie the sort is alphabetical by source, while the merge gives the conflict to the last id — exactly as documented:

Equal-priority overlays are applied alphabetically by ID, with the last ID winning conflicts. — docs/reference/workflows.md:126

So on a tie the header states the opposite of the outcome printed directly beneath it, in the one command whose documented purpose is explaining which overlay contributed or overrode a step.

Reproduction on current main (c173bf1)

DIFFERENT priorities (alpha=5, beta=10)
   listed first : project:alpha
   actual winner: echo FROM-ALPHA
   header correct? YES

EQUAL priorities (both 10)
   listed first : project:alpha
   actual winner: echo FROM-BETA
   header correct? NO  <-- inverted

The full output contradicted itself two lines apart:

Layers (highest precedence first):
  • [project-overlay] project:alpha (priority=10)
  • [project-overlay] project:beta (priority=10)
Step attribution:
  • build: project:beta          <-- beta won, alpha was labelled highest

Fix — the label, not the order

The ordering is deliberate: test_workflow_resolve_equal_priority_layers_sort_by_source pins it, and its own comment acknowledges that the alphabetically-last layer is the one that wins. Reordering the list would fight a decision the maintainers made on purpose, so this spells the tie-break out instead:

Layers (highest precedence first; on equal priority the last ID wins):
  • [project-overlay] project:alpha (priority=10)
  • [project-overlay] project:beta (priority=10)
Step attribution:
  • build: project:beta

Now self-consistent, and the behaviour is untouched.

Verification

• Fail-before / pass-after: 1 new-vs-baseline failure with the source reverted to upstream/main → 26 passed with the fix.
• The new test asserts the header and the attribution together, so it pins the label against the real outcome rather than against a hard-coded string alone.
• No existing test asserts the old header text (checked: git grep "highest precedence first" -- tests/ is empty), and test_workflow_resolve_equal_priority_layers_sort_by_source passes unchanged.
• uvx ruff@0.15.0 check src tests → clean

No behaviour change — output text only.

Note on overlap: this touches overlays/_commands.py, as does my #4141, but a different function (workflow_resolve vs workflow_overlay_add). Happy to rebase whichever lands second.

---

Written with assistance from Claude Code. Bug found, reproduced, and verified by me on current main.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The output-only fix is focused and regression-tested; the remaining wording precision note is non-blocking.

Pull request overview

Clarifies equal-priority overlay resolution without changing behavior.

Changes:

• Expands the layer-order header with the tie-break rule.
• Adds regression coverage linking the header to actual attribution.

File summaries

File	Description
tests/workflows/test_overlay_commands.py	Tests equal-priority header and attribution consistency.
src/specify_cli/workflows/overlays/_commands.py	Clarifies equal-priority resolution output.

Review details

Suppressed comments (1)

src/specify_cli/workflows/overlays/_commands.py:436

• The tie-break is still underspecified here: “last ID” does not say that equal-priority IDs are applied alphabetically, and “wins” can imply that the last overlay replaces earlier overlays rather than only winning conflicting edits. Match the documented contract at docs/reference/workflows.md:126, for example: “on equal priority, IDs are applied alphabetically and the last ID wins conflicts,” and update the test assertion to match.

        "Layers (highest precedence first; on equal priority the last ID wins):"

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mnriem]

Please resolve conflicts