Remap parent-issue filters through repository mappings

[SIkebe]

Background

Projects supports filters such as parent-issue:"OWNER/REPO#123". ProjectFilterTransformer does not recognize parent-issue, so repository/organization renames are not applied. Import warns but writes the unchanged source value, and verify can pass because it compares the same unchanged text.

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.
• No special parent-issue API object is required for the view setting; ghpmv must parse and rewrite the repository identity inside the filter string.

Implementation scope

• Add a dedicated parser for parent-issue values in the form OWNER/REPO#NUMBER.
• Map only OWNER/REPO through --repo-mapping; preserve #NUMBER, quotes, whitespace, negation, parentheses, and qualifier case.
• Do not implement this as a substring replacement or by adding parent-issue to the existing simple identity set.
• Include referenced repositories in mapping-template generation and import capability analysis.
• Treat missing and ambiguous repository mappings as unresolved identities and stop before the first Project write.
• Apply the same transformation to source expectations during verify so unchanged source text cannot produce a false Match.

Test strategy

• Extend ProjectFilterTransformerTests for quoted/unquoted values, negation, parentheses, mixed case, invalid syntax, same-number preservation, and ambiguous mappings.
• Extend MappingTemplatesTests and capability-analysis tests for parent-issue repositories.
• Extend ProjectVerifierTests to prove that an unmapped source reference cannot pass.
• Extend ProjectViewImporterIntegrationTests with live source/target repositories and issues, persist the mapped filter through GraphQL, re-export it, and verify the exact target string.
• No Browser E2E is required because the filter is fully readable/writable through GraphQL.
• 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 parent-issue prerequisites and assertions.

Extend the existing ghpmv-e2e-validation browser-e2e flow to validate mapped parent-issue: filters and displayed results, even though the implementation itself is API-only.

• Extend source fixture creation to create a parent/sub-issue relationship and save the parent-issue: view.
• Use GEI to guarantee number preservation, or add a documented fixture-seed path that deterministically creates matching target Issue numbers. Do not describe ad hoc Issue creation as equivalent.
• Add a target relationship preflight: before import, the skill must verify both matching Issue numbers and the parent/sub-issue relationship. If GEI does not preserve the relationship, the fixture path must recreate it explicitly and record that this is fixture preparation, not ghpmv migration.
• Require the skill to inspect mapping CSV and snapshot.json, then run import/verify and observe both target filter text and displayed sub-issues.
• Add missing-mapping and deliberate-filter-drift checkpoints, each against disposable targets, and require pre-write failure/Mismatch respectively.
• Track Project/repository/Issue resources and request cleanup consent.
• Update fixture builders, Integration tests, skill state/settings, GEI/fixture-seed guidance, and manual-plan steps 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. In the source repository, create a parent Issue and a sub-issue, add the sub-issue to the source Project, and save a view using parent-issue:"SOURCE_ORG/SOURCE_REPO#NUMBER".
2. Use GEI to preserve the source Issue numbers in a renamed target repository, or use the documented deterministic number-alignment fixture path. Before import, verify the target parent and sub-issue numbers. Separately verify whether GEI preserved the relationship; if it did not, recreate the relationship as an explicit fixture-preparation step and record that it was not migrated by ghpmv.
3. Export, fill repository-mappings.csv, import, and verify.
4. Confirm the saved target filter contains TARGET_ORG/TARGET_REPO#NUMBER and the expected sub-issue appears in the view.
5. Replace the target filter with the source repository identity and rerun verify; the mapped filter drift must be reported.
6. Remove the required mapping and rerun import against a disposable target; preflight must fail before Project writes.
7. Rerun the successful import and confirm idempotency.
8. Record source/target Issue URLs and numbers, mapping rows, commands, filter text, displayed items, and verify output.
9. Delete the disposable target Project; retain or remove migrated repository fixtures according to the standard GEI cleanup policy.

The existing flow must explicitly distinguish ghpmv filter migration from migration of the parent/sub-issue relationship itself.

Acceptance criteria

• ghpmv-e2e-validation can provision or validate number-aligned parent/sub-issue fixtures, distinguish relationship preparation from ghpmv migration, inspect mappings/snapshot, validate displayed results/drift, and clean up.

• docs/MANUAL_TEST_PLAN.md covers renamed repositories, displayed-result validation, unmapped preflight failure, filter drift, rerun, and cleanup.

• Repository mappings are applied inside every supported parent-issue: token.

• Issue numbers and filter syntax are preserved exactly.

• Mapping templates include referenced repositories.

• Missing/ambiguous mappings fail before writes.

• Verify compares the mapped target expectation.

• Real GraphQL persistence is covered by Integration tests.

• Documentation lists parent-issue: as a supported mapped qualifier.

References

• https://docs.github.com/en/issues/planning-and-tracking-with-projects/understanding-fields/about-parent-issue-and-sub-issue-progress-fields

  parent-issue:"/#"

• 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.