[pending ParakhAI-frontend#441] Sort AI model / evaluation domain dropdowns

[saqibmanan]

Pending: covers open CivicDataLab/ParakhAI-frontend#441 (head acbf053512e5a2bfa7a87136d2105f74eb5e95c9). Skipped in CI until it merges. Safe to merge before it.

Source PR

CivicDataLab/ParakhAI-frontend#441 — open since 2026-07-31, base dev.

What changed (from the diff, not the title)

ModelSelectionModal.tsx and NewEvaluationContent.tsx both used to render dropdown options in whatever order the API returned them:

• the "Select AI Model" <select name="modelSelect"> (New Evaluation flow, and the Model Selection modal), and
• the "Evaluation Domain" <select name="evaluationDomain"> (modal step 2, parseDomainOptions) / evaluation-scope options (NewEvaluationContent.tsx).

Both are now sorted by visible label via localeCompare. The PR also flags one side effect worth a look on review: ModelSelectionModal.tsx:367 falls back to options[0] when the previously-selected domain isn't in a newly fetched list — sorting changes which option that is.

Categories added, and why

• e2e — this is a UI-behavior change (rendering order of two dropdowns), not an API/schema change, so e2e is the right category per this repo's table. No smoke — it's not a critical-path happy-flow test, it's specific to this fix.

Tests added

tests/e2e/test_new_evaluation_dropdown_sort.py:

1. test_model_dropdown_options_sorted_alphabetically — opens the New Evaluation modal, reads every "Select AI Model" option label, asserts the list equals itself sorted case-insensitively.
2. test_evaluation_domain_dropdown_options_sorted_alphabetically — advances to modal step 2, tries up to 5 valid models until one renders an "Evaluation Domain" dropdown (it's conditional on the model having a domain with non-empty backend options), then does the same sorted-order assertion.

Both skip cleanly (not a false pass) when there's too little live data to distinguish sorted from unsorted (<2 options), or when no candidate model renders the domain dropdown at all.

Page Object gap filled

Nothing previously read the "Evaluation Domain" select's options, so I added:

• locators/evaluations_locators.py: MODAL_EVALUATION_DOMAIN_DROPDOWN = "select[name='evaluationDomain']"
• pages/new_evaluation_page.py: is_modal_evaluation_domain_dropdown_visible(), get_modal_evaluation_domain_options()

No raw selectors in the test file — both new locators/methods follow the existing MODAL_MODEL_DROPDOWN / get_modal_model_options() pattern.

Why this approach catches the actual regression, not just a flipped assertion

The assertion is labels == sorted(labels, key=casefold), not is_sorted-with-a-flip. Against the pre-fix code (API order), this only passes by coincidence if the live API response happens to already be alphabetical — which is the same limitation any "order" test built on live dev data has (noted honestly below), but it is still a real behavioral check, not a tautology.

Red/green proof — UNVERIFIED, no credentials in this environment

This is the cloud routine's sweep run; it has no TEST_EMAIL_1/TEST_PASSWORD_1, so it cannot reach the AI Maker dashboard behind Keycloak login at all (both the modal and the dropdowns are behind authenticated_page). Collection and the pending_pr gate ARE verified locally:

$ pytest tests/e2e/test_new_evaluation_dropdown_sort.py --collect-only -q
collected 2 items  (no --strict-markers failure)

$ pytest tests/e2e/test_new_evaluation_dropdown_sort.py -m "e2e" -rs -v
SKIPPED [2] tests/e2e/test_new_evaluation_dropdown_sort.py: pending_pr ParakhAI-frontend#441: not merged yet

(That skip reason came from a real, unauthenticated call to the GitHub API confirming #441 is still open — the hook itself is verified working, not just mocked.)

What a human with credentials must run to get the actual red/green proof:

1. Temporarily remove the pending_pr marker, run against dev now → expect FAIL on whichever assertion doesn't hold under current (unsorted) API order.
2. gh pr checkout 441 on ParakhAI-frontend, serve locally against the dev API per CivicDataSpace-test's pr-test-sync SKILL.md §6 local-serve recipe, point BASE_URL/HOME_URL_DEV at the local port → expect PASS.
3. Restore the marker, confirm the skip reason shown above.

Label on both tests: UNVERIFIED — not executed, no credentials in this cloud sandbox.

Gaps / follow-ups

• If #441's head moves before merge (it's been open since 2026-07-31), re-diff before relying on this.
• readonly/prod-gate concerns (§7 of the skill) don't apply yet — this only runs once dev ships it, and ParakhAI_test has no readonly prod-gate pattern like CivicDataSpace-test.
• Not covered: the ModelSelectionModal.tsx:367 fallback-selection side effect the PR author flagged — that needs a specific model whose previously-selected domain is no longer first after sorting, which isn't reliably reproducible against live dev data. Flagging as a gap rather than faking it.

[saqibmanan]

Flagging ahead of time: this PR's E2E Tests job (3 shards) ran against the same dev environment as PR #18, which hit 12 pre-existing E2E failures unrelated to either diff (worker crash in test_add_model_flow.py, navigation timeouts in test_evaluations.py, and 9 assertion failures in test_prompt_libraries.py — none in files either PR touches). If Test Summary comes back red here too once E2E finishes, it's very likely the same pre-existing failures, not this PR's new tests/e2e/test_new_evaluation_dropdown_sort.py. No fix exists yet for those failures; test_prompt_libraries.py's failures in particular look like a real regression on dev worth its own investigation.

---

Generated by Claude Code