Preserve project template provenance

[SIkebe]

Background

GitHub records which template a Project was created from and displays that provenance in Project settings. ghpmv currently preserves only ProjectV2.template, which means “this Project is a template,” not “this Project was created from template X.”

Confirmed API capability (2026-08-19)

Template provenance is browser-only and creation-time dependent.

• GraphQL ProjectV2 exposes only the Boolean template flag; it has no source-template reference.
• CreateProjectV2Input has no template parameter.
• copyProjectV2 copies a Project but does not expose or set template provenance.
• The Projects REST Project schema exposes only is_template, and REST has no Project creation endpoint.
• GitHub's product documentation states that the source template can be found in Project settings, so the provenance exists in UI state even though public APIs omit it.

A provenance relationship likely must be established by creating the target through the UI's “create from template” flow; it cannot be attached to an already-created Project through a public API.

Discovery gate

Before changing the snapshot or creation pipeline, document from the live UI:

• how the source template reference is displayed and uniquely identified;
• how an organization/user selects a template during Project creation;
• whether provenance survives rename/copy operations;
• whether provenance can be changed after creation;
• exact selectors, navigation, confirmation, and failure behavior;
• what content the template creation flow pre-populates and how that interacts with normal ghpmv import.

If provenance cannot be recreated reliably, the outcome must be an explicit NotMigratable capability with documented evidence, not a silent approximation via copyProjectV2.

Implementation scope after successful discovery

• Add a nullable logical source-template identity without persisting node IDs.
• Define an explicit template mapping input for cross-owner migrations.
• Use browser-based creation from the mapped target template as an alternative target-creation path.
• Reconcile template-created fields/views/drafts/workflows with the normal importer without duplicating state.
• Keep the existing project.template flag handling independent.
• Verify provenance through the browser settings page.

Test strategy

• Add deterministic schema/mapping/compatibility tests only after the discovery contract is fixed.
• Add Playwright E2E for source provenance export, mapped template creation, normal import reconciliation, and browser-assisted verification.
• Do not add Integration tests for provenance itself because REST/GraphQL cannot read or write it; retain existing Integration coverage for the API stages that run after browser creation.
• Browser tests must use cancellation tokens and delete created Projects/templates in finally.

ghpmv-e2e-validation skill integration

Do not add a separate user-facing scenario selector for this issue. After discovery, extend the existing browser-e2e flow conditionally with template fixtures and provenance checkpoints.

After discovery proves a reliable UI path, extend the existing ghpmv-e2e-validation browser-e2e flow to validate template provenance.

• Add feature-specific template fixture helpers that the existing flow invokes conditionally that create uniquely named source and target templates plus a source Project created from the source template. Do not overload the shared standard fixture silently.
• Extend non-secret E2E settings with template identities/mapping only if required; validate that mapped templates exist before resource creation.
• Have the skill announce every template/Project it will create and use the same owned operation/resume rules as other fixture creation.
• Require source Settings provenance observation, snapshot/mapping inspection, browser-based target creation from the mapped template, and normal import reconciliation.
• Have the fixture command emit expected counts and logical identities for template-copied fields/views/drafts/workflows. The skill must compare before/after counts and fail on duplicates.
• Define ambiguous draft reconciliation behavior explicitly: adopt a uniquely matched draft, otherwise stop with a named warning/error before creating another duplicate.
• Require browser-assisted provenance verification, missing-mapping NotMigratable, rerun/no-duplicate checks, and cleanup consent for Projects/templates.
• Update fixture tests, Browser E2E tests, skill instructions/state/settings, and cleanup logic 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.

After the discovery gate establishes a reliable creation path, extend the existing browser-assisted migration flow in docs/MANUAL_TEST_PLAN.md with these checkpoints:

1. Create uniquely named source and target organization templates with distinguishable views, fields, drafts, workflows, and other copied configuration.
2. Create the source Project from the source template and confirm the source Settings page displays that provenance.
3. Export with browser automation, provide the explicit source-to-target template mapping, and import into a new target through the confirmed “create from template” browser path.
4. Before normal import, record the exact field/view/draft/workflow counts and logical identities emitted by fixture setup. After import, require the same expected multiset plus only source-intended additions. Duplicate names/titles are failures unless the source intentionally contains that multiplicity. For draft matches that are not unique, stop with an explicit reconciliation error instead of creating another draft.
5. Run browser-assisted verify and confirm the target Settings page displays the mapped target template as provenance.
6. Change/omit the template mapping in a separate disposable run and confirm import stops with NotMigratable before creating or mutating a target Project.
7. Rerun the successful migration and confirm no duplicate Project/configuration is created.
8. Record template/Project URLs, mapping input, commands, provenance display, object counts, and verify output.
9. Delete all disposable Projects and templates in finally/manual cleanup order.

If discovery proves provenance cannot be recreated, replace these checkpoints with a documented negative checkpoint proving NotMigratable before writes; do not claim a successful round-trip.

Acceptance criteria

• After discovery, ghpmv-e2e-validation can create mapped template fixtures, validate expected object inventories, reconcile without duplication/ambiguity, verify provenance, test NotMigratable, and clean up.

• docs/MANUAL_TEST_PLAN.md contains either the proven provenance round-trip scenario or the evidence-backed negative NotMigratable checkpoint, including reconciliation, rerun, and cleanup.

• Current UI read/create semantics are documented before implementation.

• template status and source-template provenance remain distinct.

• A mapped target template establishes provenance when the UI supports it reliably.

• Template-created content is reconciled without duplication.

• Browser-assisted verify checks the displayed source template.

• Unsupported cases produce NotMigratable, not a false success.

• Migration and browser documentation describe the capability and constraints.

References

• https://docs.github.com/en/issues/planning-and-tracking-with-projects/managing-your-project/managing-project-templates-in-your-organization

  You can find the template that a project used from the project's settings page, under the "Templates" section.

• https://docs.github.com/en/graphql/reference/objects#projectv2
• https://docs.github.com/en/graphql/reference/mutations#copyprojectv2
• https://docs.github.com/en/rest/projects/projects