Arbitrary Dynamic Editor Tabs (vNext): Named Multi-File Workspace Model for @knighted/develop

[knightedcodemonkey]

Summary

Introduce a new editor model in @knighted/develop that supports arbitrary, user-defined editor tabs with dynamic names and per-tab file mapping, replacing the current fixed Component/Styles assumptions as the primary workflow.

This is intended as a vNext milestone and architectural foundation for future UX and PR-context features.

Problem

Current editor behavior is optimized around a small fixed set of editors and file paths. That model makes advanced workflows difficult, especially when users need:

1. More than two source files.
2. Named workspace organization by intent.
3. Reliable mapping between editor tabs, file paths, and GitHub PR context.
4. Reusable context switching across repositories and PRs without losing editor intent.

Goals

1. Support user-created tabs with dynamic names.
2. Persist tab metadata and editor content state in localStorage with a stable schema.
3. Support explicit file-path mapping per tab for GitHub commit/PR workflows.
4. Preserve current render, lint, typecheck, diagnostics, and AI/BYOT behavior during migration.
5. Enable future multi-PR context switching using tab-aware file mappings.
6. Keep browser-first, CDN-first, no new dependency requirements unless explicitly approved.

Non-Goals

1. No immediate redesign of AI model providers or auth flow.
2. No server-side persistence.
3. No change to CDN strategy.
4. No mandatory migration of historical data without backward-compatibility logic.

Proposed UX (v1 of this issue)

1. Users can create, rename, reorder, and close editor tabs.
2. Each tab has:
   • Display name.
   • Content type (for example JSX, CSS, TS, JSON, Markdown).
   • Optional repository-relative file path mapping.
3. Active-tab indication and predictable restore behavior on reload.
4. Safe handling for invalid or duplicate tab names.
5. Clear behavior when mapped files are missing in selected branch/PR.

Data Model Requirements

1. Introduce a versioned localStorage schema for tab workspaces.
2. Store tabs as first-class objects with stable IDs.
3. Persist per-tab:
   • Name.
   • Language/type.
   • Content.
   • File path mapping.
   • Last active timestamp.
4. Keep compatibility reader for legacy fixed-editor keys.
5. Include migration path from legacy storage to new workspace schema.

PR/GitHub Integration Requirements

1. Commit and PR flows must consume mapped files from current workspace tabs.
2. Active PR context should record enough metadata to restore tab mappings correctly.
3. Future issue work (multi-open-PR switching) should build on this schema without another storage overhaul.

AI/Assistant Integration Requirements

1. Assistant edit proposals must target tab IDs (not hardcoded Component/Styles).
2. Apply/undo should work per tab.
3. Existing feature-flag and BYOT constraints must remain unchanged.

Acceptance Criteria

1. User can create at least 5 tabs with arbitrary names and persist them across reload.
2. User can assign file mappings to tabs and commit mapped files through existing PR flow.
3. Legacy users load without data loss via migration or compatibility fallback.
4. Existing diagnostics/typecheck/lint flows still function for active tab context.
5. Existing active PR flows continue to work with tab-aware mappings.
6. Playwright coverage added for:
   • Tab create/rename/reorder/close.
   • Persistence and restore.
   • File-path mapping and commit behavior.
   • AI apply/undo targeting named tabs.
7. Lint and build pass.

Suggested Implementation Phases

1. Phase 1: Schema and compatibility layer.
2. Phase 2: Tab UI and core interactions.
3. Phase 3: Runtime toolchain integration (render/lint/typecheck/diagnostics).
4. Phase 4: GitHub PR/file mapping integration.
5. Phase 5: AI apply/undo integration by tab ID.
6. Phase 6: Cleanup of deprecated fixed-editor assumptions.

Risks

1. Migration regressions for existing localStorage users.
2. UI complexity increase for first-time users.
3. Tight coupling between tab state and PR context if not normalized early.

Open Questions

1. Should there be a reserved system tab concept, or are all tabs user-defined?
2. Should tab language auto-detect from file extension when mapping changes?
3. Should tab reorder persist globally or per repository?
4. What is the maximum tab count before UX degrades?
5. Should we allow unmapped scratch tabs in PR workflows, and if so, how are they excluded?