Compose a notebook from a catalog

Answer a question by composing existing catalog helpers in a live marimo kernel, not by writing a pipeline from scratch and checking it headless. The live kernel - driven by the marimo-pair skill - is where you compose and look; the .py on disk is the durable artifact you commit. The headless validate-notebook.sh is the final gate, not the feedback loop.

Why compose instead of writing fresh

• Catalog over library. The catalog's reusable logic lives as top-level @app.function cells in numbered notebooks, not a package. Reuse them by importing; do not re-implement what a vignette already does, and do not reach for a src/ package.
• Vignettes vs composed notebooks. The catalog's curated notebooks (vignettes) each teach one move and earn their place. What you produce here is a composed notebook - it only has to answer the question. Most composed notebooks stay composed; few become vignettes. This keeps the catalog small and high-signal.
• Compose in the kernel, not against it. Build the notebook by editing the .py and running each changed cell in the live kernel, looking at the output as it lands. Static checks pass on notebooks that return empty tables, wrong-signed correlations, or plots that render but say nothing; only a cell you have run and looked at is trustworthy. Discovering what your outputs say is the kernel's job, not the headless gate's.

Procedure

1. Ensure a live kernel. You compose against a running marimo kernel driven by the marimo-pair skill. If none is running - no marimo-pair session, no port you can post cells to - run getting-started first: it installs marimo-pair, launches the catalog's first notebook under --sandbox, runs its cells, and hands back a live kernel on a known port. Keep that port; every "run a cell" below targets it.