Remap reviewers filters through user mappings

[SIkebe]

Background

The filter-mapping work completed in #13 maps assignee: and author: user qualifiers, but Projects uses the plural reviewers: qualifier. ProjectFilterTransformer currently marks it unsupported and leaves the source login unchanged. In EMU/cross-account migrations, the filter can point to a nonexistent source login while textual verification still passes.

Confirmed API capability (2026-08-19)

This is an API-supported string transformation, not a browser feature.

• GraphQL reads and writes the complete filter through ProjectV2View.filter and UpdateProjectV2ViewInput.filter.
• REST view creation also accepts a filter string.
• GitHub officially documents reviewers:USERNAME and reviewers:@me filter behavior.
• Browser automation is not required.

Implementation scope

• Add plural reviewers to the existing user-qualifier allowlist.
• Reuse the existing structural handling for quoted values, comma-separated users, negation, mixed qualifier case, optional @ prefixes, and the special @me value.
• Include reviewer logins in user-mapping template extraction.
• Treat unresolved reviewer identities exactly like unresolved assignees and stop before writes under the existing strict preflight.
• Apply user mapping to the source expectation before verify so unchanged source text cannot produce a false Match.
• Do not add reviewer grouping/slicing support; GitHub explicitly does not allow Reviewers for those operations.

Test strategy

• Extend ProjectFilterTransformerTests using the existing assignee/author cases for quoted, comma-separated, negated, mixed-case, @login, and @me values.
• Extend MappingTemplatesTests, preflight tests, and ProjectVerifierTests.
• Extend ProjectViewImporterIntegrationTests to persist a mapped reviewers: filter through GraphQL, re-export it, and verify the exact value.
• No Browser E2E is required.
• 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 GEI/fixture-seed flow with reviewed-PR prerequisites and assertions.

Extend the existing ghpmv-e2e-validation browser-e2e flow to validate mapped reviewers: filters and displayed PR results, even though filter import is GraphQL-only.

• Extend fixture preparation to create a source PR/review and a target PR/review with matching PR numbers and mapped reviewer identities. Use GEI for number preservation, or a documented deterministic fixture-seed path; do not imply arbitrary PR numbers can be assigned manually.
• When a target review must be created by a separate mapped reviewer, model that browser login/profile as an explicit non-secret existing-flow prerequisite and guide it one identity at a time.
• Before import, verify target PR number, review presence, user mapping, and token/browser access.
• Require Step 6 snapshot/mapping inspection, then import/verify and observe both target filter text and displayed PRs.
• Add @me, multiple-reviewer where available, missing-mapping preflight, deliberate drift, rerun, and final result checks.
• Inventory Projects/repositories/PR fixtures and request cleanup consent; do not delete shared migrated repositories without explicit approval.
• Update fixture builders, Integration tests, skill state/settings, GEI guidance, and manual-plan instructions 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 GEI + ghpmv browser-assisted flow in docs/MANUAL_TEST_PLAN.md with these checkpoints:

1. Prepare a source pull request reviewed by a source user and a saved Project view using reviewers:SOURCE_LOGIN. Use GEI to preserve the PR number, or use the documented deterministic number-alignment fixture path. Before import, verify the corresponding target PR number, target review, and mapped target login. If the target review requires a separate reviewer account, prepare it explicitly through the existing flow's browser-profile prerequisite.
2. Export, fill user-mappings.csv, import, and verify.
3. Confirm the target view filter contains reviewers:TARGET_LOGIN and displays the expected reviewed pull request.
4. Test quoted/comma-separated reviewers when the fixture has multiple reviewers, plus reviewers:@me with the authenticated target user; @me must remain unchanged.
5. Replace the target filter with the source login and rerun verify; mapped filter drift must be reported.
6. Remove the required mapping in a fresh disposable run and confirm strict preflight fails before Project writes.
7. Rerun the successful import and confirm idempotency.
8. Record PR URLs, reviewer identities, mapping rows, commands, filter text, displayed items, and verify output.
9. Delete the disposable target Project; retain/remove repository fixtures according to the standard GEI cleanup policy.

The existing flow must not claim Reviewers grouping or slicing support, which GitHub does not provide.

Acceptance criteria

• ghpmv-e2e-validation can provision or validate number-aligned reviewed PR fixtures and mapped identities, inspect snapshot/mappings, validate displayed results/drift/preflight, and clean up safely.

• docs/MANUAL_TEST_PLAN.md covers mapped reviewer filters, displayed-result validation, @me, multiple reviewers where available, unmapped preflight failure, drift, rerun, and cleanup.

• reviewers: values use --user-mapping.

• @me remains unchanged.

• Mapping templates include reviewer identities.

• Unresolved reviewers fail before writes under strict preflight.

• Verify compares the mapped expectation.

• Real GraphQL persistence is covered by Integration tests.

• Documentation lists reviewers: as supported and does not claim grouping/slicing support.

References

• https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/filtering-projects

  reviewers:octocat will show items that have been reviewed by @octocat.

• https://docs.github.com/en/graphql/reference/objects#projectv2view
• https://docs.github.com/en/graphql/reference/input-objects#updateprojectv2viewinput
• https://docs.github.com/en/rest/projects/views

Follow-up to #13.