# Feature ideas

Deferred / out-of-scope ideas. Each waits for a real second-consumer pull —
a feature that lives in only one consumer stays consumer-side until a second
consumer asks for it. Shipped features live in `architecture.md`; this file is
only what we have *not* built.

## Dock model — remaining pieces

The movable-sections / floating-panels work shipped (drag-to-reorder, float over
canvas, cross-panel + cross-stage transfer, floating panels; see
`architecture.md`). Still deferred under it:

- **Multi-rect / predicate float regions** — `floatRegion` is a single rect today.
- **Tabbed / stacked dock groups** — sections stack vertically in a dock; no
  tabbed grouping.
- **Dragging side panels themselves** — only floating panels move today; the
  static left/right panels are fixed.

## Split-pane main view

Neither consumer ships this the same way — `3d-model-exporter` brokers two
sibling components through `App.tsx`, with no shared primitive. Greenfield
design driven by the next real consumer.

## Multi-page navigation

`PageSelector` exists only in `osrs-engine-study`. Greenfield in the library.

## Section strip-icon bar

A collapsed `Panel` currently shows only the chevron. Later: a vertical column
of section icons (consumer-provided list), so a collapsed panel becomes an
icon rail. Requires deciding how the consumer supplies the icon list.

This is the collapsed-strip vertical icon column — **not** resolved by
`Section`'s `leadingAction` slot (a chevron override on a floating card) or
`Panel`'s `toggleVariant="edge"` (an edge collapse toggle). Those are separate,
shipped features. Related: the activity-bar view-router research in
`docs/editor-side-navigation-patterns.md` (deferred indefinitely — no consumer
pull yet).

## Rail and panel re-siding

From `docs/editor-panel-docking-patterns.md`, each waiting for a consumer to need it:

- **Rail:** when a consumer has three or more mutually exclusive views on one side. Follows
  the router shape in `docs/editor-side-navigation-patterns.md`.
- **Side flip by setting:** when a consumer wants a panel on the opposite side. Needs no drag.
- **Dragging panels between sides:** far cheaper after a rail, by dragging its icons.

Free split layouts with a guide diamond are a non-goal: we have no layout tree to drop into.

## Trailing slot after the expanded label rule

An expanded field's (and `Fieldset`'s) heading row is `[name][info?][rule]` — the
`.stage-field-rule` is the last child, with nothing after it. A consumer may want
**right-anchored content on the far side of the rule**: a per-group action (a
reset/clear-all button, an enable-all toggle, a count badge) sitting opposite the
caption, the rule filling the gap between them.

Today there's no slot for it — the rule is hard-coded last in `Field`'s expanded
branch and in `Fieldset`'s heading. Adding it means an optional trailing-content
prop (e.g. `headerEnd` / `action`) rendered after `.stage-field-rule`, shared by
both `Field` (expanded) and `Fieldset`. The rule already `flex: 1 1 0`, so a
trailing flex child anchors to the right for free.

Deferred until a real consumer pull (no second consumer asks yet). When built,
do it once on the shared heading row so `Field` expanded + `Fieldset` get it
together.

## Naming pass before v1.0 (breaking)

The public surface is consistently `Stage`-prefixed — `CanvasStage`,
`StageFloatHost`, `StageModalHost`, `StageToastHost`, `stageModal`, `stageToast`,
`stageTooltip`, `StageSize` — with **one outlier: `EditorPanels`**. It's a
holdover: the v0.5.10 taxonomy refactor (`a236e48`) renamed `EditorPanes →
EditorPanels` but never reconsidered the `Editor` prefix, which dates from the
original extraction. The docs already call an `EditorPanels` instance "the stage",
so the prose and the symbol disagree.

Do a single coordinated naming pass for v1.0 (a breaking change, so gate it there
— hence here, not now). It's **not** a clean find-replace: settle the deeper
question first, then rename everything to match in one go.

- **Decide what "stage" canonically means** — the outer shell (what `EditorPanels`
  is) or the canvas viewport (what `CanvasStage` is). Today both claim it.
- **Then name the shell to match.** `StagePanels` is the safe prefix-fix, but
  "Panels" undersells a component that also owns the bars + `center`; `Stage` is
  the most accurate if `CanvasStage` is reframed to clearly be "a canvas you drop
  in the centre" (e.g. it's not *the* stage, it's *a* thing in one).
- **Audit the rest of the surface** while at it for any other convention drift, so
  v1.0 ships one coherent vocabulary.

Provide a deprecation alias for one minor cycle if practical, or just take the
clean break at the major.

## ESLint config

Skipped in v1. `tsc --noEmit` + `vitest` cover what we need.

## Mobile / touch support

The library was built and tested for desktop pointer input, and touch has no deliberate
design beyond section and panel drags, which work from the grip with a finger. Still open:
touch hit-target sizing.