Skip to content

Phase 4B: Multi-Tab PR Mapping UX + Open PR Context Binding + Local Workspace Cleanup #74

@knightedcodemonkey

Description

@knightedcodemonkey

Summary

Implement Phase 4B for @knighted/develop: the user-facing sync controls for mapping arbitrary workspace tabs to GitHub file paths, selecting already-open PRs, and self-cleaning stored local workspaces.

This issue delivers the UX/workflow layer on top of Phase 4A sync metadata, while keeping local-first behavior as the primary product model.

Context

  1. Arbitrary Dynamic Editor Tabs (vNext): Named Multi-File Workspace Model for @knighted/develop #53 defines multi-tab PR/file mapping as part of Phase 4.
  2. Multi-Tab Workspace (Dynamic Tabs, Local IndexedDB Persistence, and Modular Preview Architecture) #62 delivered phases 1-3 local-first multi-tab foundations.
  3. Phase 4A introduces per-tab sync metadata and dirty/reconcile state.
  4. Phase 4B now adds the user controls and context workflows needed before bulk push orchestration.

Goals

  1. Allow users to map any tab to a repository-relative target file path.
  2. Allow users to select and bind to already-open PRs for a selected repository.
  3. Provide local workspace management so users can search/select/delete IndexedDB entries.
  4. Keep sync status and errors in PR drawer status text (no app-level toast expansion).
  5. Keep implementation modular and composable.

In Scope

  1. PR drawer UI for tab-to-file mapping:
  2. search/select tab
  3. set/edit/remove target path
  4. mapped/unmapped and dirty indicators
  5. Open PR selection flow:
  6. list open PRs for selected repo
  7. choose one PR and bind current workspace context
  8. restore mapped tab metadata when switching contexts
  9. Local workspace cleanup controls:
  10. search/filter stored local contexts
  11. select one or many entries
  12. delete with confirmation
  13. Persist and restore mapping/config state using established storage boundaries:
  14. IndexedDB for workspace/mapping state
  15. localStorage only for lightweight preferences/form state

Out of Scope

  1. GitHub bulk commit implementation details (Phase 4C).
  2. AI apply/undo tab routing (Phase 5).
  3. Full fixed-assumption cleanup (Phase 6), except minimal compatibility glue.

UX Requirements

  1. Mapping flow is explicit and reversible.
  2. Search is available for tabs and/or contexts (dropdown/select is acceptable baseline).
  3. Open PR binding is repository-scoped and does not destroy unsynced local data silently.
  4. Cleanup flow is user-controlled, discoverable, and guarded with confirmation.
  5. Status channel remains inside PR drawer.

Acceptance Criteria

  1. User can map multiple tabs to repository-relative file paths and persist mappings across reload.
  2. User can view open PRs for selected repo and bind current workspace to chosen PR.
  3. Switching bound PR context restores associated mappings and sync metadata.
  4. User can search/filter local stored contexts and delete selected entries.
  5. Deletion removes only selected IndexedDB records and does not wipe unrelated preferences.
  6. Dirty/mapped indicators render consistently from Phase 4A metadata.
  7. Lint/build/tests pass.

Verification

  1. Automated:
  2. Playwright coverage for mapping create/edit/remove and reload persistence
  3. Playwright coverage for open PR selection and context switching restore
  4. Playwright coverage for search/filter/select/delete cleanup flow
  5. integration tests for mapping state hydration and context binding behavior
  6. Manual:
  7. map 3+ tabs, reload, verify mappings persist
  8. bind to an existing open PR, switch contexts, verify correct restore
  9. delete selected local contexts, verify only targeted records are removed
  10. confirm status/errors appear in PR drawer text only

Dependencies

  1. Depends on: Phase 4A issue, Arbitrary Dynamic Editor Tabs (vNext): Named Multi-File Workspace Model for @knighted/develop #53, Multi-Tab Workspace (Dynamic Tabs, Local IndexedDB Persistence, and Modular Preview Architecture) #62
  2. Blocks: Phase 4C bulk push issue and contributes prerequisites for Phase 6 cleanup

Suggested Follow-up

  1. Phase 4C: Git Database API atomic multi-file push + fallback orchestration
  2. Phase 6: remove fixed component/styles sync assumptions end-to-end

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