app-builder

Build ONE app: either a durable data model with a stlite frontend that reads it, or a live result pipeline with a frontend that presents it. Your job is done when submit_app succeeds.

Everything you need is inline below — do NOT go looking for other files first. A component catalog exists as an OPTIONAL reference (${CLAUDE_PLUGIN_ROOT}/examples/); if you can reach it, great, but never block on it.

App directory: /tmp/mewbo/apps/${SESSION_ID}/<app_id>/ — create it, write your frontend files inside, then submit. <app_id> is a short slug you pick (e.g. email-organizer); it names the directory AND is the app_id you pass to submit_app. Always brace ${SESSION_ID} — an unbraced $SESSION_ID renders empty and your files land in the wrong place.

Choose the app archetype before you build

There are two valid shapes:

• Collections tier (tier="materialize", the default) — a pipeline writes a periodic snapshot into named collections and the frontend reads it. Use it when the user wants a digest, a daily rollup, or another answer that is correct as a refresh-time snapshot.
• Live tier (tier="render") — a mode="code" pipeline computes a declared result for the caller when it is requested, without writing collections. Use it when the answer must be current at the moment someone looks: a forge search, a status board over a CLI, or a query with caller-supplied parameters.

Choose from the user's need for freshness, not from the implementation that feels easier. A daily digest does not become better by running at render time; a current search cannot become truthful by showing the last periodic snapshot.

Build sequence

1. Choose the archetype. For the collections tier, design the collections first. For the live tier, declare the result first; it is the contract the caller receives.
2. Pick each pipeline's mode. mode="code" is the DEFAULT for a deterministic transform — file parsing, CSV ingestion, filtering, dedup, anything with no judgment call. The platform EXECUTES your entrypoint file directly: no LLM call, no wake_prompt reasoning, no burned turn. Reserve mode="agentic" for a flow that genuinely needs judgment (a triage rubric, free-form summarization). A deterministic transform running agentically is pure waste — 45 LLM-minutes per fire for what a function does in milliseconds.
3. Code pipelines: discover sources by GLOB, never a hardcoded file enumeration. Call ctx.glob(pattern) every run — don't name individual files. A hardcoded list only ever reads the files that existed at build time, so every file added later is silently dropped.
4. Declare each pipeline's schedule — schedule (cron or one-shot) or on_demand: true. You never arm anything yourself; the platform does it at submit time.
5. Write the frontend — reads via the mewbo_app SDK only.
6. Verify — python -m py_compile every .py file before calling submit_app; a syntax slip costs a whole reask cycle otherwise.
7. Submit once — this registers your app + its pipelines (even a first-draft pipeline body counts; run_pipeline can only test a pipeline that already exists on your app).
8. Dry-run test each code pipeline, then ship. run_pipeline(pipeline=<name>, dry_run=true) executes the SAME code path with no durable write — inspect docs_written/output, fix the pipeline file, submit_app again with the SAME app_id to ship the fix, dry-run again. Repeat until clean before trusting a schedule to fire it unattended.