Skip to content

Verify draft issue assignees and title identity explicitly #71

Description

@SIkebe

Background

Draft issue assignees are migrated through user mappings, but ProjectVerifier.CompareItemPair does not compare them. Draft titles currently contribute indirectly to item identity, so title drift can appear only as generic missing/extra items and duplicate-title pairing is not explicit.

Confirmed API capability (2026-08-19)

This is a GraphQL verifier gap, not an API limitation.

  • DraftIssue exposes both title and assignees.
  • AddProjectV2DraftIssueInput and UpdateProjectV2DraftIssueInput accept both title and assigneeIds.
  • The Projects REST draft endpoint accepts only title and body, and its draft representation does not expose assignees. The existing GraphQL path must remain authoritative for this feature.
  • Browser automation is not required.

Implementation scope

  • Compare draft assignee sets after applying --user-mapping to the source expectation.
  • Report missing, extra, and incorrectly mapped assignees with draft-specific diagnostics.
  • Make title comparison/pairing explicit, including deterministic handling of duplicate-title drafts.
  • Preserve the existing body comparison that strips the import attribution note.
  • Continue treating original creator and creation timestamp as intentionally lossy metadata; this issue does not claim they can be preserved.

Test strategy

  • Extend ProjectVerifierTests for exact matches, missing/extra assignees, mapped logins, duplicate titles, and title drift.
  • Extend live item/verify Integration tests using GraphQL-created drafts with resolvable assignees.
  • Add a live drift case that updates the target draft assignee/title through GraphQL and confirms verify fails with a precise diagnostic.
  • 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 API/browser-assisted migration flow and its standard draft fixture.

Extend the existing ghpmv-e2e-validation flow with draft-assignee/title verification checkpoints.

  • Extend the API fixture builder/setup --fixture path to create mapped draft assignees and duplicate-title drafts with distinguishable bodies/assignee sets.
  • Teach the skill to verify required source/target user identities and mapping rows before import; do not ask for token values outside the terminal workflow.
  • Require Step 6 snapshot inspection for draft titles, bodies, creators/timestamps, and assignee lists.
  • Run import/verify, then use a controlled target mutation or UI action to remove an assignee and rename one duplicate-title draft.
  • Require precise verifier diagnostics, restore/rerun according to documented importer semantics, and require final Match where restoration is supported.
  • Keep creator/timestamp checks explicitly lossy.
  • Inventory created drafts/Projects and request cleanup consent.
  • Update fixture tests, Integration verify tests, skill state/settings, 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 browser-assisted migration flow in docs/MANUAL_TEST_PLAN.md with these checkpoints:

  1. Prepare source draft items with mapped assignees, including two drafts with the same title but different body/assignee combinations.
  2. Export, fill user-mappings.csv where source and target logins differ, import into a disposable target, and run verify.
  3. Confirm target draft titles, bodies, and mapped assignees in the UI/API and confirm verify reports Match.
  4. Remove one target assignee and rename one duplicate-title draft, then rerun verify; diagnostics must identify the assignee and title/identity drift without pairing the wrong draft.
  5. Restore by rerunning import where supported, or restore manually when import intentionally does not update an already-complete draft, and rerun verify to confirm the documented behavior.
  6. Remove a required user mapping in a fresh disposable run and confirm the expected warning/preflight/verification outcome is explicit rather than a false Match.
  7. Record mapping rows, commands, draft identities, assignee sets, and verify output.
  8. Delete disposable target Projects/drafts.

The existing flow must continue treating original creator/timestamp as lossy attribution metadata, not an exact assertion.

Acceptance criteria

  • ghpmv-e2e-validation can create mapped/duplicate draft fixtures, inspect snapshot identity and assignees, inject drift, validate diagnostics/restoration, and clean up.

  • docs/MANUAL_TEST_PLAN.md covers mapped assignees, duplicate titles, deliberate assignee/title drift, missing mapping behavior, rerun/restoration, and cleanup.

  • Draft assignees are compared after user mapping.

  • Missing and extra assignees are reported precisely.

  • Duplicate-title drafts are paired deterministically.

  • Title drift receives a draft-specific diagnostic.

  • Creator/timestamp loss remains documented and excluded from exact comparison.

  • Real GraphQL draft read/write/verify behavior is covered by Integration tests.

  • No REST fallback drops assignee verification.

References

Follow-up to #12.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions