> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stage.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# The edit notch

> Edit mode never changes the page's layout or presentation. Structural actions live in a tab on the section's right edge, and components meet a small contract to support it.

## The constraint

<Warning>
  **Edit mode keeps the site's layout exactly the same.** Nothing is injected into the page flow: no add tiles, no insert rails, no placeholders, no edit-only layouts. A carousel stays a carousel while editing.
</Warning>

The only chrome allowed on the page is hover-revealed overlays anchored to items that already exist: the remove control and the drag handle. Everything else lives in the **notch**, a tab the admin draws over the canvas, flush to the right edge and centred on its section. What the user sees is in [Guides: Adding, reordering and removing](/editing/structure).

## Entries

| Entry             | Source                                                                                                           |
| ----------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Add**           | One per addable list in the schema's `arrays`                                                                    |
| **Settings cog**  | The component's `form`. On a stateful component it acts on the `data-e-current` item, falling back to index 0    |
| **Custom action** | A `{ event }` entry. The button dispatches a `CustomEvent` into the frame; the component's own script handles it |
| **Reorder grip**  | A `{ reorder: "<arrayPath>" }` entry, explicit or derived from a `reorderable: "strip"` list                     |

A component with no explicit `notch` gets one entry per addable list. `notch: []` opts out; form questions do this because their add is a ghost row in the flow of the question list.

## Item notches

Items can carry their own notch, revealed on hover, for nested lists and per-item settings. The rule:

> Every list's add lives in the notch of its owning container.

A section owns its top-level lists. An item that owns a nested list shows that list's add in its own notch. It scales to any depth and answers "which parent?" by which item is hovered, the same targeting model as drag and remove.

## The component contract

<Steps>
  <Step title="Render identically in edit mode">
    No expanded editable state, no rack. The design is intact.
  </Step>

  <Step title="Stamp data-e-current on the active item">
    Stateful components only. It tells the cog and inline edits which item is showing.
  </Step>

  <Step title="Handle the custom events you declare">
    A `{ event: "next" }` notch entry dispatches an event into the frame. The component's script advances so every item becomes reachable in its real frame.
  </Step>

  <Step title="Declare insert: 'reload' if the DOM derives from the list">
    Pagination dots, counters, a select's options. Otherwise a new item grafts in place: an optimistic clone of the last sibling appears, then the server render with correct anchors swaps in.
  </Step>

  <Step title="Choose reorderable: 'strip' for one-at-a-time components">
    Nothing on the page can be dragged past anything, so the grip opens a vertical filmstrip of thumbnails beside the notch. Thumbnails come from the page's own images via the array's `thumb`. Delivery is a staged reload plus a `goto` event that pages back to the held item.
  </Step>
</Steps>

## Next steps

<CardGroup cols={2}>
  <Card title="Page schemas" href="/developers/structure/schemas">
    Where notch entries are declared.
  </Card>

  <Card title="Components" href="/developers/editing/components">
    The renderer side.
  </Card>
</CardGroup>