Apply all saved view sort keys

[SIkebe]

Background

GitHub Projects supports multiple ordered sort criteria. ProjectExporter already reads all ProjectV2View.sortByFields, but ViewUiImporter applies only SortByFields[0].

Confirmed API capability (2026-08-19)

Read and write capabilities are asymmetric:

• GraphQL read: ProjectV2View.sortByFields returns all ordered sort criteria.
• GraphQL write: CreateProjectV2ViewInput and UpdateProjectV2ViewInput have no sort input; their configuration accepts only visibleFieldIds.
• REST write on creation: POST /orgs/{org}/projectsV2/{project_number}/views and the user equivalent accept sort_by, an ordered array of [field_id, direction], and explicitly support multiple criteria.
• REST update: no PATCH/update endpoint exists for Project views.

Therefore new views can receive all sort keys through REST creation, while reused/default/existing views still require Playwright to replace their saved sort configuration.

Implementation scope

• Add REST Project-view creation support using API version 2026-03-10 for newly created views when target numeric field IDs can be resolved.
• Emit an explicit progress/diagnostic event identifying the selected write path as REST create, browser update, or browser fallback; the Skill and manual E2E must observe this event rather than infer the path.
• Preserve existing durable create/reconciliation semantics when replacing the GraphQL create path.
• Continue using GraphQL for authoritative read-back and verification.
• For reused/default/existing views, use Playwright to remove target-only keys and apply every source key in order and direction.
• For target hosts that do not expose the 2026-03-10 REST Project-view creation endpoint, fall back to Playwright for all sort keys and emit a capability warning; never silently apply only the first key.
• Remove the current “only the first sort key is applied” warning after full handling exists.

Test strategy

• Add deterministic planning tests for new-vs-reused views, field-ID resolution, fallback, zero/one/multiple keys, and target-only removal.
• Extend ProjectViewImporterIntegrationTests with a real REST-created view containing multiple sort_by entries, then re-export it through GraphQL and assert order/direction.
• Add Playwright E2E for updating a reused view, replacing target-only sorts, and browser-assisted drift detection.
• Test REST and GraphQL base-URL/version handling for GitHub.com and supported GHE.com targets.
• Live tests must use cancellation tokens and finally cleanup.

ghpmv-e2e-validation skill integration

Do not add a separate user-facing scenario selector for this issue. Extend the existing browser-e2e flow with fresh-target and existing-target checkpoints in the same validation run.

Extend the existing ghpmv-e2e-validation browser-e2e flow to validate both REST creation and browser update paths.

• Extend fixture setup to create a source view with two observable sort keys and an existing target view with conflicting/extra keys; the existing flow needs both a fresh target and an additional existing target.
• Add an explicit CLI progress/diagnostic event identifying REST create, browser update, or browser fallback; the skill must observe this rather than infer the path from the final state.
• Require Step 6 to inspect all ordered source sort keys in snapshot.json.
• Drive the fresh REST-create path and the existing-view browser-update path as separate owned checkpoints, then re-export/verify each.
• Introduce secondary-direction drift, require detection, rerun, and require final Match.
• Treat the “REST endpoint unavailable” fallback as conditional: exercise it only on a configured host that lacks the endpoint; otherwise record NotApplicable and rely on deterministic fallback tests, not a false manual pass.
• Inventory both target Projects and request cleanup consent.
• Update REST Integration tests, Browser E2E tests, fixture creation, skill instructions/state, and settings validation together.

Existing manual E2E flow additions

E2E runtime consolidation: Do not add a standalone feature scenario or repeat the full fixture/export/import/verify/cleanup sequence. Fold fixture setup into the existing fixture step, snapshot assertions into the existing export result, target assertions into the existing import/verify and visual checklist, deliberate drift into the existing negative-test phase, and repair into the single idempotence re-import. Reuse the same snapshot, mappings, and target Project. Add another disposable target or native command only when a distinct code path cannot be proven otherwise; document why and include every added resource in the existing inventory and cleanup.

Extend the existing browser-assisted migration flow in docs/MANUAL_TEST_PLAN.md with two path checkpoints:

Fresh target / REST creation path

1. Prepare a source view with at least two sort keys using different directions and values that make the secondary ordering visible.
2. Export and import into a disposable fresh target.
3. Confirm the CLI reports the REST creation path, GraphQL re-export returns the same ordered keys/directions, browser-assisted verify passes, and the UI item order matches.

Existing target / browser update path

1. Prepare an existing target Project/view with conflicting and target-only sort keys.
2. Import with --project-number and browser automation enabled.
3. Confirm all source keys replace the target configuration in order.
4. Reverse the secondary direction on the target and rerun verify; the exact key/direction drift must be reported.
5. Rerun import and confirm restoration/idempotency.

Record API/browser path selection, commands, source/target sort order, verify output, and UI observations. Delete all disposable targets under the standard cleanup section. If the target host lacks the 2026-03-10 REST endpoint, record and validate the explicit Playwright fallback instead of silently accepting first-key loss.

Acceptance criteria

• ghpmv-e2e-validation can create both sort targets, observe the selected REST/browser path, inspect snapshot order, validate drift/restoration, handle fallback as conditional, and clean up.

• docs/MANUAL_TEST_PLAN.md covers both fresh REST creation and existing-view browser update, including fallback, UI ordering, drift, rerun, and cleanup.

• New views receive all sort keys via REST creation.

• GraphQL re-export returns the same ordered keys and directions.

• Reused/existing views receive all keys through browser automation.

• Target-only keys are removed.

• Targets without the 2026-03-10 REST view endpoint use the explicit Playwright fallback, never silent first-key loss.

• REST creation has real Integration coverage.

• Existing-view updates have Browser E2E coverage.

• Documentation describes the REST-create/browser-update split.

References

• https://docs.github.com/en/rest/projects/views

  sort_by ... Supports multiple sort criteria applied in order.

• https://docs.github.com/en/graphql/reference/objects#projectv2view
• https://docs.github.com/en/graphql/reference/input-objects#createprojectv2viewinput
• https://docs.github.com/en/graphql/reference/input-objects#updateprojectv2viewinput
• https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-board-layout#sorting-by-field-values