Preserve board column limits

[SIkebe]

Background

GitHub Projects Board views can store a separate soft card limit for each displayed column. Column limits are view-specific. ViewSnapshot and ViewUiSnapshot currently have no per-column limit model.

Confirmed API capability (2026-08-19)

Column limits are browser-only.

• GitHub.com GraphQL exposes the Board column field through verticalGroupByFields but no limit value on ProjectV2View, its configuration, or the create/update inputs.
• The REST view create endpoint supports vertical_group_by but has no per-column limit parameter.

The implementation must use Playwright for reading, writing, clearing, and verification. No REST/GraphQL integration test applies to this setting itself.

Implementation scope

• Add a backward-compatible nullable collection of (column logical identity, limit) entries.
• Identify a column by the Board column field plus Single-select option name or Iteration title; never persist source IDs.
• Export only explicitly configured limits and distinguish uncaptured state from a captured view with no limits.
• Apply or clear limits after the target column field and values exist.
• Handle missing target columns with precise warnings.
• Verify each captured limit through the browser stage.

Test strategy

• Add serialization, compatibility, logical identity, missing-column, and verifier tests.
• Add Playwright E2E coverage for Single-select and Iteration boards, multiple columns with different limits, no-limit columns, clearing a limit, and target drift.
• Do not add Integration tests for limit state because no public API exposes it.
• Browser 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 and standard fixture.

Extend the existing ghpmv-e2e-validation browser-e2e flow with column-limit checkpoints.

• Extend the fixture builders and setup --fixture --fixture-ui to create Single-select and Iteration Boards with stable named columns, multiple limits, an unlimited column, and enough items to exceed one limit.
• Require the skill to record expected logical column identities/limits during fixture creation.
• Require Step 6 to inspect the snapshot and stop if a configured limit is missing.
• Require browser-assisted import/verify plus direct target UI observation of numeric, unlimited, and over-limit states.
• Introduce a changed and cleared limit, verify both mismatches, rerun import, and require final Match without item movement.
• Inventory created Projects/repositories and require cleanup consent.
• Ship fixture logic tests, Browser E2E tests, skill changes, 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 these checkpoints:

1. Prepare source Single-select and Iteration Board views with at least two different column limits and one column with no limit. Put enough items in one column to exceed its limit so the visual warning is observable.
2. Run browser-assisted export and inspect the captured limits.
3. Import into a disposable fresh target Project and run browser-assisted verify.
4. Reload each target Board and visually confirm each numeric limit, the unlimited column, and the exceeded-limit indication.
5. Change one limit and clear another on the target, then rerun verify; both drifts must identify the correct column.
6. Rerun import and confirm the limits are restored without moving items or changing column values.
7. Record commands, limits, verify output, and UI observations.
8. Delete the disposable target Project.

Fixture setup must create stable named options/iterations and enough items for the exceeded-limit check, or the manual plan must document exact preparation steps.

Acceptance criteria

• ghpmv-e2e-validation can create the limit fixture and over-limit state, inspect snapshot limits, validate target UI/drift/restoration, and clean up.

• docs/MANUAL_TEST_PLAN.md covers Single-select and Iteration limits, unlimited/over-limit states, drift, rerun, and cleanup.

• Multiple per-column limits round-trip.

• Limit removal round-trips.

• Single-select and Iteration columns are supported.

• Target ID changes do not affect mapping.

• Missing target values produce a warning without modifying another column.

• Browser-assisted verify detects limit drift.

• API-only/legacy snapshots retain existing behavior.

• UI selectors and save semantics are documented.

References

• https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-board-layout#setting-a-limit-on-the-number-of-items-in-a-column

  You can set a limit for the number of cards in a particular column in a board layout. Column limits are unique to each view in your project.

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