deepline-playslisted

# Getting Started With Deepline Plays Deepline GTM work is paid uncertainty reduction. The play is the notebook, stable ids are the cache, datasets are durable row state, getters are the interface, and CSV is an input/output boundary. Start from live Deepline contracts, then run exactly or build a small durable wrapper. Default rule: every user request is fresh unless the user names a project, play file, run id, saved play, or asks to continue prior work. Do not inspect old local `.play.ts`, README, or CSV files for route evidence. Run one Deepline command at a time when you need its output. Avoid `jq`, shell parsing, background jobs, raw `curl`, env spelunking, or local provider probes around Deepline commands. JSON output is for reading directly. ## Core Loop 1. **Preflight:** check auth/health/balance when spend or cloud execution is likely. 2. **Describe before spend:** `plays search` -> `plays describe`; for tools, `tools search` -> `tools describe`. 3. **Choose direct vs build:** direct-run only when the described contract exactly matches input, output, export, freshness, and pricing. Otherwise bootstrap/wrap/fork. 4. **Check before run:** `plays describe` is the gate for prebuilts; `plays check <file>` is mandatory for local, bootstrapped, or forked plays. 5. **Pilot before scale:** run 1-3 rows or a small sample, then inspect/export. 6. **Report reality:** run id, export path, charged credits or why not visible, executed/reused/failed counts when available, and r