` — is the field panel. Read it in full before extracting.
- [ ] **Step 2: Extract it**
Move that branch's JSX into `src/builder/components/FieldPanel.tsx`, wrapped in `EditorPanelShell`. It needs the same values the branch uses today: `items`, `selectedItem`, `selectedGroup` (from `styleGroupFor(selectedItem.type, brand)`), `ruleCtx`, and the update/remove callbacks. Recompute them inside `FieldPanel` from `popup` and `itemId` rather than threading them in — the derivations are three lines each and are already written at the top of `ContentItemsEditor` (lines 86-98).
The panel's title is the item's type name, which `ContentItemsEditor`'s existing header already builds; reuse that expression rather than inventing a new label.
Replace the extracted branch in `ContentItemsEditor` with a render of `
` so the fields tab keeps working identically. The two surfaces render the same component from this point on.
- [ ] **Step 3: Route canvas clicks on a field to the panel**
In `EditingView.tsx`, add to the `tab-panel` block, beside the card panel from Task 3:
```tsx
{panel.kind === 'field' && (
dispatchPanel({ type: 'close' })}
/>
)}
```
and import `FieldPanel`.
- [ ] **Step 4: Verify by hand**
Click a field in the canvas: its panel takes the column. Click a different field: the panel switches without closing. Press Esc: back to the tab. The fields tab still lists fields and still opens the same panel when a row is clicked.
- [ ] **Step 5: Verify and commit**
```bash
npm run typecheck && npm test 2>&1 | grep -E "^ℹ (tests|pass|fail)"
git add src/builder/components/FieldPanel.tsx src/builder/components/ContentItemsEditor.tsx src/builder/components/EditingView.tsx
git commit -m "feat(builder): clicking a field opens its settings and design"
```
---
### Task 5: Add opens the picker in the column
**Files:**
- Modify: `src/builder/components/EditingView.tsx`
- Modify: `src/builder/components/PreviewPane.tsx`
- Modify: `src/builder/components/FieldPicker.tsx`
- Delete: `src/builder/components/AddMenu.tsx`
**Interfaces:**
- Consumes: `panelReducer` action `openPicker`.
- Produces: nothing new.
- [ ] **Step 1: Understand why this matters before changing it**
`FieldPicker.tsx:142` reads `const drag = variant === 'panel' ? insert : null;`. The comment above it explains: the popover hangs over the canvas, so a drag would start on top of its own target. The file's own docblock calls that drag *"the only way to say 'this field goes there', and the only way to put two fields on one row from here."* Moving Add into the column is what keeps that capability once the fields tab is gone.
- [ ] **Step 2: Render the picker as a panel**
In `EditingView.tsx`, add beside the other panels:
```tsx
{panel.kind === 'picker' && (
dispatchPanel({ type: 'close' })}
>
dispatchPanel({ type: 'close' })}
/>
)}
```
Check the actual title key with `grep -n "title" src/builder/i18n/en.ts | sed -n '1,20p'` and use the existing picker heading rather than adding a string. `FieldPicker`'s default `variant` is `'panel'`, so drag is on with no prop needed.
- [ ] **Step 3: Point the toolbar button at it**
`PreviewPane.tsx:232` renders ``. Replace `AddMenu` with a plain toolbar button that calls a new `onOpenPicker` prop, and have `EditingView` pass `() => dispatchPanel({ type: 'openPicker' })`. Model the button on the `toolbar-btn` beside it (the mode toggle at `PreviewPane.tsx:236`), reusing `AddMenu`'s existing label and icon so the bar looks unchanged.
- [ ] **Step 4: Delete the dead code**
```bash
rm src/builder/components/AddMenu.tsx
```
In `FieldPicker.tsx`, remove the `variant` prop, the `in-popover` class it toggles, the `variant === 'popover'` branch in the header (around line 183), and simplify `const drag = variant === 'panel' ? insert : null;` to `const drag = insert;`. Then confirm nothing still refers to the removed things:
```bash
grep -rn "AddMenu\|in-popover\|variant" src/builder/components/FieldPicker.tsx src/builder --include=*.tsx | grep -i "popover\|addmenu"
```
Expected: no hits outside `PublishPopover`, which is unrelated.
- [ ] **Step 5: Verify by hand**
Press `+ הוספה`. The picker fills the settings column. Drag a row onto the canvas and drop it beside an existing field: it lands there, on the same row. Click a row instead: it appends. Both should work.
- [ ] **Step 6: Verify and commit**
```bash
npm run typecheck && npm test 2>&1 | grep -E "^ℹ (tests|pass|fail)"
git add -A
git commit -m "feat(builder): Add opens the picker in the column, where rows can be dragged"
```
---
### Task 6: Split SettingsEditor and drop to three tabs
Every panel is now reachable from the canvas, so the two tabs can go.
**Files:**
- Create: `src/builder/components/FormTypeEditor.tsx`
- Modify: `src/builder/components/SettingsEditor.tsx`
- Modify: `src/builder/components/EditingView.tsx`
- Modify: `src/builder/i18n/en.ts`, `src/builder/i18n/he.ts`
- [ ] **Step 1: Split the component**
`SettingsEditor` (line 99) renders, in order: the form-name row, the Delivery `Accordion`, `` (line 250), and the Submission `Accordion` (line 252 to the end of its return).
Move the form-name row and the Delivery accordion into `src/builder/components/FormTypeEditor.tsx` as `export function FormTypeEditor({ popup, onChange }: Props)`. Take with them only the helpers they use: `inline`, `setTrigger`, `setPlacement`, and the `TRIGGER_TYPES` / `PLACEMENTS` constants they read.
Leave `StepsSection` and the Submission accordion in `SettingsEditor`, which keeps its name and its `showEndpoint` prop and is now the `הגדרות` tab.
- [ ] **Step 2: Rename the tab strings**
In `src/builder/i18n/en.ts` (lines 34-37): delete `tabDesign`, and change `tabFields: 'Fields'` to `tabSettings: 'Settings'`.
In `src/builder/i18n/he.ts` (lines 31-34): delete `tabDesign`, and change `tabFields: "שדות"` to `tabSettings: "הגדרות"`.
- [ ] **Step 3: Cut the tab list to three**
In `EditingView.tsx`, replace the `Tab` type (line 41) and `TABS` (lines 49-54):
```tsx
type Tab = 'formType' | 'settings' | 'automations';
// Text-only tabs: the row reads as an underlined rail, so a glyph per tab would
// only add noise. `labelKey` resolves against `t.edit` at render so tabs stay
// translated.
//
// Three, not four. Design left the rail because it is reached by pointing at
// the thing being designed, and the field list left with it: both are panels
// the canvas opens. What is left is configuration, in the order it is decided:
// what kind of form this is, how it is wired up, and what happens after.
const TABS: { id: Tab; labelKey: keyof Strings['edit'] }[] = [
{ id: 'formType', labelKey: 'tabFormType' },
{ id: 'settings', labelKey: 'tabSettings' },
{ id: 'automations', labelKey: 'tabAutomations' },
];
```
Replace the four render lines (261-274) with:
```tsx
{tab === 'formType' && }
{tab === 'settings' && }
{tab === 'automations' && }
```
Remove the `design` and `fields` cases, the `ContentItemsEditor` import and its render, and the `DesignEditor` import (the card panel imports it now, not this file).
In `selectItem`, drop `if (id !== null) setTab('fields');` — there is no fields tab to switch to, and `dispatchPanel` already opens the panel.
- [ ] **Step 4: Verify by hand**
Three tabs. `סוג טופס` shows the form name and Delivery. `הגדרות` shows Steps and Submission. `אוטומציות` is unchanged. Clicking a field or the card still opens its panel from any tab.
- [ ] **Step 5: Verify and commit**
```bash
npm run typecheck && npm test 2>&1 | grep -E "^ℹ (tests|pass|fail)"
git add -A
git commit -m "feat(builder): three tabs, split along what is configured and what is designed"
```
---
### Task 7: The field outline, in the card panel
`ContentItemsEditor` is now unused as a tab, and its third state — the outline of every item — is the piece worth keeping.
**Files:**
- Modify: `src/builder/components/CardPanel.tsx`
- Modify or delete: `src/builder/components/ContentItemsEditor.tsx`
- Modify: `src/builder/components/EditingView.tsx`
- [ ] **Step 1: Reduce ContentItemsEditor to the outline**
Its picker state moved to Task 5 and its selected-item state to Task 4, so only the list remains. Strip the other two branches and the `picking` state, and rename the export to `FieldOutline`. It keeps the list's own affordances — reorder and remove — since those are what make it an alternative to pointing rather than a picture of the form. Its `onSelect` now opens the field panel.
If what remains is small enough, move it into `CardPanel.tsx` and delete the file; if it is still substantial, keep it as `src/builder/components/FieldOutline.tsx`. Judge by whether the outline reads clearly beside the card panel's own body.
- [ ] **Step 2: Render it under card design**
In `CardPanel.tsx`, add the `onSelectField` prop promised in Task 3 and render the outline beneath `` inside its own `Accordion` (imported from `./Accordion`), titled `t.edit.panelFields`, so the panel opens on design and the outline is one click away rather than competing for the top:
```tsx
```
- [ ] **Step 3: Pass the handler**
In `EditingView.tsx`, give `CardPanel` its new prop:
```tsx
onSelectField={(id) => dispatchPanel({ type: 'canvasClick', id })}
```
- [ ] **Step 4: Verify by hand**
Click the card. Below the design groups, a collapsible group lists every item, private ones included. Clicking one opens its field panel. Reordering from the list still moves it in the canvas.
- [ ] **Step 5: Verify and commit**
```bash
npm run typecheck && npm test 2>&1 | grep -E "^ℹ (tests|pass|fail)"
git add -A
git commit -m "feat(builder): the field outline lives under card design"
```
---
### Task 8: Step switching on the canvas
Step *configuration* is in `הגדרות`, but *switching* which step the canvas shows cannot be: an author editing step 2's fields must not be sent to another tab to get there.
**Files:**
- Modify: `src/builder/components/PreviewPane.tsx`
- Modify: `src/builder/components/EditingView.tsx`
- [ ] **Step 1: Move the switcher**
`EditingView` already owns `activeStep`, `setStep`, `addNewStep` and `dropStep`, and already passes `activeStep` and `onStepChange` into `ContentItemsEditor`. Pass them to `PreviewPane` instead and render the switcher in the toolbar's first `toolbar-group`, beside the Add button, separated by the existing ``.
Reuse the step rail markup from whatever `ContentItemsEditor` rendered for it rather than designing a new control.
- [ ] **Step 2: Show it only when there is a choice**
Guard on `stepsEnabled(popup) && stepCount(popup.contentItems) > 1`. A one-step form has nothing to switch between and the control would be noise.
- [ ] **Step 3: Verify by hand**
Turn steps on in `הגדרות` and add a step. The switcher appears in the canvas toolbar; changing it changes what the canvas shows. Turn steps off: it disappears.
- [ ] **Step 4: Verify and commit**
```bash
npm run typecheck && npm test 2>&1 | grep -E "^ℹ (tests|pass|fail)"
git add -A
git commit -m "feat(builder): switch steps from the canvas, where the fields are"
```
---
### Task 9: Closing, and reaching the card by keyboard
**Files:**
- Modify: `src/builder/components/PreviewPane.tsx`
- Modify: `src/builder/components/EditingView.tsx`
- [ ] **Step 1: Close on a click outside the card**
The renderer's own handler sits on `.pm-body` and never fires for the canvas area around the card, so this is a new handler in the builder. Add an `onClick` to the canvas wrapper in `PreviewPane` that dispatches `close` when the click's `composedPath()` does not include the card element. `composedPath()` rather than `e.target`, because the builder is in a shadow root and targets are retargeted at the host — `Select.tsx` and `SettingsEditor`'s `useDismissable` both do this already; copy their approach.
- [ ] **Step 2: Give the card a keyboard route**
Card design used to be reachable through a tab and now is not, so removing the tab must not remove the capability. The card needs a focusable, named affordance that dispatches `{ type: 'canvasClick', id: null }` on Enter or Space.
Prefer adding it in the builder's canvas wrapper over changing the renderer: the renderer ships to visitors, and a control that only the editor needs does not belong in it. If that proves impossible, a builder-only affordance gated on the existing `editable` flag is acceptable — but check first.
- [ ] **Step 3: Verify by hand**
Tab through the editor: the card is reachable and announces itself, and Enter opens its panel. Click the checkered area outside the card: any open panel closes. Click a field: its panel opens rather than closing.
- [ ] **Step 4: Verify and commit**
```bash
npm run typecheck && npm test 2>&1 | grep -E "^ℹ (tests|pass|fail)"
git add -A
git commit -m "feat(builder): close a panel by clicking away, and reach the card by keyboard"
```
---
### Task 10: Whole-flow check and PR
- [ ] **Step 1: Full verification**
```bash
npm run typecheck
npm test
npm run build:all
```
All three must pass. `npm test` should report `fail 0` with at least 143 tests (132 before this plan, plus Task 1's 11).
- [ ] **Step 2: Walk the editor end to end**
With `npm run dev`, in one sitting: create a form, add a field by clicking a picker row, add another by dragging a row onto the canvas beside the first, style one of them from its panel, restyle the card from the card panel, find a field through the outline, turn on steps and switch between them from the canvas, add an automation, and publish. Nothing should be unreachable and nothing should need a tab that no longer exists.
- [ ] **Step 3: Confirm the JSON did not move**
The global constraint is that a host's JSON is unchanged. Press "הצג JSON" in the dev page before and after a no-op edit and confirm the shape matches what `main` produces for the same form.
- [ ] **Step 4: Open the PR**
```bash
git push -u origin feat/editor-tabs-restructure
gh pr create --base main --title "feat(builder): three tabs, and design where the design is"
```
Note in the PR body that this branch was cut from `fix/default-layout-image` (PR #16) and should merge after it.
---
## Self-review notes
- **Spec coverage.** Three tabs (Task 6), field panel (4), card panel (3), outline (7), Add as panel (5), step switcher (8), navigation and a11y (9). The spec's URL line under `סוג טופס` is corrected above rather than implemented, because URLs are not in a tab.
- **Tasks 4, 7, 8 and 9 describe moves rather than quoting code.** That is deliberate: they relocate blocks of 40 to 200 lines that already exist and are already commented, and transcribing them into this plan would produce a copy that drifts from the original before anyone reads it. Each names the exact file, the exact block, and how to find it. Read the source, then move it.
- **Ordering is load-bearing.** Panels become reachable (3, 4, 5) before tabs are removed (6). Do not reorder those.