[WP9] Dead Ordered/getOrder resolver contract #203

此內容由 AI 產生（specification-mapper 全庫審查 2026-07-16．執行圖）。

Work package WP9 · findings: MAINT-01 · worst severity: medium · effort: M

From the 2026-07-16 whole-codebase review of branch jakarta (snapshot 7de4a33; modules mapper/ + starter/). Every finding below is CONFIRMED by independent adversarial verification. File:line coordinates are from the snapshot and may have drifted.

Findings

MAINT-01 — Ordered/getOrder contract is documented but never honored; resolver order is purely insertion order (maintainability, medium)

• File: mapper/src/main/java/tw/com/softleader/data/jpa/spec/SpecificationResolver.java:73
• Evidence: SpecificationResolver documents an Ordered/getOrder contract for resolver precedence, but the resolver chain is applied in insertion order and getOrder is never consulted anywhere. Consumers who implement getOrder to influence precedence get no effect — a silent no-op contract.

Design decision needed

The whole finding is a fork the maintainer owns — there is no single "correct" fix:

• (a) Honor the contract: sort resolvers by getOrder before applying them. Restores the documented behavior, but changes resolution order for any existing consumer that added resolvers relying on the current insertion-order behavior — a potentially breaking change.
• (b) Remove the dead contract: drop the Ordered/getOrder documentation and any implements Ordered, and document that resolver precedence is insertion order. No behavior change, but abandons the extensibility hook.

Once the direction is chosen, add a Plan and swap status: pending-design-work for status: ready-for-agent.

Acceptance criteria (target)

• The Ordered/getOrder contract and the actual resolution order agree — either getOrder demonstrably governs precedence (option a, with a test), or the dead contract is gone and insertion-order is documented (option b).
• Regression: make test green.