Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,7 @@ browser acts as the runtime host for render, lint, and typecheck flows.
`@knighted/develop` lets you:

- write component code in the browser
- manage dynamic workspace tabs with add, rename, remove, and entry-role protection
- switch render mode between DOM and React
- switch style mode between native CSS, CSS Modules, Less, and Sass
- run in-browser lint and type diagnostics
Expand Down
26 changes: 1 addition & 25 deletions docs/next-steps.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,31 +19,7 @@ Focused follow-up work for `@knighted/develop`.
- Suggested implementation prompt:
- "Add a deterministic E2E execution mode for `@knighted/develop` that serves pinned runtime artifacts locally (instead of live CDN fetches) and wire it into CI as a required check on every PR. Keep a separate lightweight CDN-smoke E2E check for real-network coverage. Validate with `npm run lint`, deterministic Playwright PR checks, and one CDN-smoke Playwright run."

4. **Phase 2 UX/UI continuation: fixed editor tabs first pass (Component, Styles, App)**
- Continue the tabs/editor UX work with a constrained first implementation that supports exactly three editor tabs: Component, Styles, and App.
- Do not introduce arbitrary/custom tab names in this pass; treat custom naming as future scope after baseline tab behavior is stable.
- Preserve existing runtime behavior and editor content semantics while adding tab switching, active tab indication, and predictable persistence/reset behavior consistent with current app patterns.
- Ensure assistant/editor integration remains compatible with this model (edits should target one of the fixed tabs) without expanding to dynamic tab metadata yet.
- Suggested implementation prompt:
- "Implement Phase 2 UX/UI tab support in @knighted/develop with a fixed first-pass tab model: Component, Styles, and App only (no arbitrary tab names yet). Add a clear tab UI for switching editor panes, preserve existing editor behavior/content wiring, and keep render/lint/typecheck/diagnostics flows working with the selected tab context where relevant. Keep AI chat feature-flag behavior unchanged while keeping PR/BYOT controls available by default, maintain CDN-first runtime constraints, and do not add dependencies. Add targeted Playwright coverage for tab switching, default/active tab behavior, and interactions with existing render/style-mode flows. Validate with npm run lint and targeted Playwright tests."

5. **Document implicit App strict-flow behavior (auto render)**
- Add a short behavior matrix in docs that explains when implicit App wrapping is allowed versus when users must define `App` explicitly.
- Include concrete Component editor examples for each case so reviewer/user expectations are clear.
- Suggested example cases to document:
- Allowed implicit wrap (standalone top-level JSX, no imports/declarations), for example:
- `(<button type="button">Standalone</button>) as any`
- Requires explicit `App` (top-level JSX with declarations/imports), for example:
- `const label = 'Hello'`
- `const Button = () => <button>{label}</button>`
- `(<Button />) as any`
- Recommended explicit pattern, for example:
- `const Button = () => <button>Hello</button>`
- `const App = () => <Button />`
- Suggested implementation prompt:
- "Document the current implicit App behavior in @knighted/develop for auto-render mode using a compact behavior matrix and concrete component-editor snippets. Clearly distinguish supported implicit wrapping from cases that intentionally require an explicit App (such as top-level JSX mixed with imports/declarations). Keep docs concise, aligned with current runtime behavior, and include at least one positive and one explicit-error example."

6. **Evaluate GitHub file upsert request strategy (metadata-first vs optimistic PUT)**
4. **Evaluate GitHub file upsert request strategy (metadata-first vs optimistic PUT)**
- Revisit the current metadata-first `upsertRepositoryFile` approach and compare it against an optimistic PUT + targeted retry-on-missing-sha flow.
- Measure tradeoffs for latency, GitHub API request count/rate-limit impact, and browser-console signal quality during common PR flows.
- If beneficial, introduce a configurable/hybrid strategy (for example, optimistic default with metadata fallback) without regressing current reliability.
Expand Down
136 changes: 136 additions & 0 deletions docs/render-pipeline-multitab-spec-plan.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,136 @@
# Render Pipeline + Multi-Tab Spec Plan

This document outlines test coverage to add after the render pipeline rewrite is fully integrated with the multi-tab UX.

## Why this plan exists

Current test coverage intentionally removed a subset of specs that were tightly coupled to pre-rewrite assumptions:

1. Legacy assumptions around default-export hydration behavior in preview module assembly.
2. Styles diagnostics behavior that depended on old compile/lint sequencing.
3. PR drawer path validation timing assumptions tied to previous field sync flow.

These should return as updated tests once the new pipeline contract is finalized.

## Proposed Test Areas

## 1. Entry Resolution and Execution Semantics

Goal: Validate how preview entry is resolved from workspace tabs under the `role: entry` model.

Add specs for:

1. Entry selection prefers explicit `role: entry`, with documented fallback behavior only when no explicit entry is present.
2. Entry rename between `App.tsx` and `App.js` keeps execution stable.
3. Entry path updates preserve directory while enforcing filename convention.
4. Reload restores same entry tab and executes same source.

## 2. Default Export Handling in New Hydration Pipeline

Goal: Reintroduce export-default tests against the final module assembly support matrix.

Add specs for:

1. `export default () => ...` in entry tab with manual render.
2. `export default class ...` in React mode.
3. `function App() { ... } export default App` compatibility.
4. `const Button = ...; export default Button` behavior when App wrapper is implicit or explicit.
5. Negative cases: unsupported default-export combinations produce deterministic diagnostics.

## 3. Cross-Tab Import Graph Hydration

Goal: Ensure workspace graph resolution works across multiple component and style tabs.

Add specs for:

1. Entry imports sibling component tab by relative specifier.
2. Nested dependency chain (A imports B imports C) hydrates in stable order.
3. Missing module path reports actionable preview error including unresolved specifier.
4. Circular import emits stable error (or supported behavior) without hanging.
5. Windows-style and POSIX-style separators normalize consistently in lookup keys.

## 4. Styles Pipeline and Diagnostics Contract

Goal: Lock down expected diagnostics and status transitions for style dialects.

Add specs for:

1. Sass compilation error sets diagnostics state to error with styles-scope detail.
2. Less error path behavior parity with Sass.
3. Switching style mode clears stale diagnostics according to final pipeline contract.
4. Styles lint diagnostics and compile diagnostics coexist or prioritize per contract.
5. Clearing style diagnostics does not clear unrelated component diagnostics.

## 5. Status and Diagnostics State Machine

Goal: Ensure app status text/class and diagnostics toggle class remain consistent.

Add specs for:

1. Pending to error to neutral transitions for typecheck + lint + render.
2. Multiple error sources aggregate counts correctly.
3. Clearing one scope updates only corresponding status/diagnostics indicators.
4. Auto-render off path keeps status stable until explicit render.

## 6. Multi-Tab Tool Visibility and Actionability

Goal: Guarantee controls are actionable only for active editor tab and panel.

Add specs for:

1. Component controls hidden/inert when styles tab is active.
2. Styles controls hidden/inert when component tab is active.
3. Keyboard interactions in inactive panel do not mutate source.
4. Tab switches maintain tool visibility state and collapse state correctly.

## 7. Persistence and Isolation Guarantees

Goal: Verify deterministic startup and no stale state bleed between sessions.

Add specs for:

1. IndexedDB workspace restore across reload preserves tabs, active tab, entry role, and paths.
2. PR drawer saved config does not unexpectedly overwrite active workspace tab paths.
3. New session starts clean when storage is reset in tests.
4. Repository switch behavior isolates per-repo local context and config.

## 8. PR Drawer Path Validation and Sync

Goal: Revisit path validation behavior after final field sync implementation.

Add specs for:

1. Reject traversal (`../`) for component and styles paths.
2. Reject trailing slash paths for component and styles fields.
3. Allow dotted segments that are not traversal.
4. Entry-specific filename rule enforcement (`App.tsx` or `App.js`) reflected in drawer path values.

## 9. Test Infrastructure Improvements

Goal: Keep suites stable as UX evolves.

Actions:

1. Add helper APIs for tab activation before control interactions.
2. Add one reset helper per suite to clear localStorage, sessionStorage, and IndexedDB.
3. Prefer role/name selectors that match active-tab semantics.
4. Avoid assertions that require hidden panel controls to be clickable.

## Suggested Rollout Order

1. Entry resolution + default-export support matrix.
2. Cross-tab import graph hydration.
3. Styles diagnostics contract.
4. Status state machine.
5. PR drawer path validation synchronization.
6. Persistence/isolation hardening.

## Definition of Done for this plan

Before reintroducing removed specs, the render pipeline implementation should provide a written behavior contract for:

1. Entry tab selection.
2. Default export support matrix.
3. Style compile + lint diagnostics precedence.
4. Status/diagnostics state transitions.
5. Path normalization and validation across workspace tabs and PR drawer fields.
144 changes: 0 additions & 144 deletions docs/webkit-open-pr-drawer-triage.md

This file was deleted.

Loading
Loading