Structuring a larger plugin

Once a plugin grows beyond a handful of handlers, split its setup by concern instead of letting index.tsx accumulate everything. The reference layout is plugins/notes-tsx:

packages/notes-core/        pure model + logic — no kernel, no React
  note-file.ts              file format (parse/serialize, migrations)
  task-store.ts             task/status/precedence transitions
  history.ts                undo/redo stacks per document
  content-store.ts          in-memory text store

plugins/notes-tsx/src/
  env.ts                    session stores + shared helpers + a `NotesEnv`
                            object passed to every module
  bindings.ts               the whole `ctx.ui.define` (states, values,
                            tables, graph nodes/edges/lanes, tree items)
  handlers/
    documents.ts            note lifecycle: create, open, save, close…
    tasks.ts                task selection, editing, moves, precedences
    statuses.ts             swimlane add/edit/move/resize
    history.ts              onTransaction, undo/redo, two-phase commit demo
  index.tsx                 thin orchestrator: value types, `ctx.ui.load`,
                            module wiring, views, public API, dispose

Why this shape:

packages/<name> holds everything testable without a shell: pure functions over plain data. bun test covers it without booting the app.
env.ts is the single place that owns session state (in-memory stores that must never be persisted) and the helpers several handlers share, so handlers never import each other.
bindings.ts keeps all reactive UI wiring together — when a ui.json reference breaks, there is exactly one file to check.
handlers/<domain>.ts groups ctx.registerHandler calls by business domain. Each module receives the env object and registers its own handlers; adding a feature means adding one file, not editing a monolith.
index.tsx stays an orchestrator you can read in one screen: what the plugin declares, in what order, and nothing else.

A small plugin does not need this: start with a single index.tsx, and split out handlers/ first when it grows, then env.ts/bindings.ts, and finally extract a packages/<name> core when the logic becomes worth testing on its own.