The example projects under examples/ are part of the public product surface. They are maintained reference repos with automated coverage behind them.
Unless an example README says otherwise, start the bundled demo API once and leave it running:
runmark demo startIf you are new to runmark, this path gives the clearest progression:
examples/getting-started— smallest possible projectexamples/pause-resume— the canonical inspect / pause / resume flowexamples/failure-recovery— expectation failures, runtime evidence, and recovery
After that, pick the example that matches the workflow shape you care about.
| Example | Best for | What it shows |
|---|---|---|
getting-started |
first success | one env, one request, one run |
pause-resume |
understanding the full workflow | login, secret extraction, parallel reads, explicit pause, artifact inspection, and resume |
failure-recovery |
failure handling | failed sessions, artifact history, and re-running after investigation |
multi-env-smoke |
environment reuse | one run reused across multiple env files |
api-key-body-file |
body templates and API-key auth | $ENV auth, request bodies from files, and extracted outputs |
basic-auth-crud |
local-secret auth plus mutation | basic auth, JSON bodies, and sequential CRUD |
ecommerce-checkout |
longer business workflows | cart creation, checkout, extracted IDs, and follow-up verification |
incident-runbook |
operator-style workflows | parallel diagnostics, pause points, and guarded mutation |
When you copy from an example:
- keep
runmark/tracked and keeprunmark/artifacts/Git-ignored - copy the related request, run, body, and block files together
- keep IDs path-derived instead of inventing a second naming system
- rerun
runmark validateafter every structural edit - keep secrets in
runmark/artifacts/secrets.yaml,$ENV:NAME, or an external secret source rather than checked-in YAML
For team and CI usage after the first successful run, continue with ci-and-team-adoption.md.