examples

// The PRD's illustrative example, completed into a full valid plan.
# project: build-mvp-example
# summary: Ship an MVP in evidence-bounded iterations — three attempts to move the metrics, a human launch gate, and a forced pivot-or-kill decision instead of a fourth quiet retry.
# prompt: """
We keep polishing instead of shipping. Plan an MVP loop with teeth:

- ship the smallest slice that can produce real usage data
- iterate only on what the metrics say, three attempts max
- I decide when it goes to the beta cohort, and I decide whether we
  pivot or kill — that call must never happen by inertia
"""
VAR iteration = 0

-> build_mvp

=== build_mvp ===
Ship the smallest testable slice.
Cut scope until one user-visible outcome can ship this iteration, then release
it to real users behind the cheapest guard available. Done means it is live,
the activation/retention funnel is collecting, and a week of data is in —
"metrics green" is judged against the targets in the brief, not gut feel.
~ iteration += 1
* [Metrics green] @human -> beta_launch
+ {iteration < 3} [Learnings, go again] ~loop~ -> build_mvp
* {iteration >= 3} [Three strikes] -> pivot_or_kill

=== beta_launch ===
Launch to the beta cohort and monitor.
Open the flag to the full beta list, announce it, and watch error rates plus
the same funnel for two weeks. Done means the cohort is live with no
regression worth a rollback; after that, ordinary product work takes over.
-> END

=== pivot_or_kill ===
Three iterations without green metrics: decide whether to pivot or stop.
Write the one-page account of the three attempts — what shipped, what the
metrics did, what was learned. That document, not optimism, is the input to
this decision.
+ [Pivot: new angle, fresh loop] @human ~loop~ -> build_mvp
* [Kill it] @human -> END

# project: marionette-docs-site
# summary: Rewrite the README around captured reality and ship a Cloudflare docs site whose terminal demos are byte-faithful replays of the real CLI.
# prompt: """
Let's do two things and use marionette itself to plan it out:

1. updating the readme to describe what marionette is and does, with
   (brief but illustrative) examples
2. creating a doc site to be hosted on cloudflare that does similar but
   with realistic interactive demonstrations (these have to be true to how
   it would actually appear in a terminal) along with examples of the
   output and what it looks like end to end, and how to use it in practice.

The latter requires a design system: full viewport terminal aesthetic, but
don't compromise accessibility. This isn't a SaaS but a tool — no
marketing bumf, just what really helps understand and visualise what this
does, plus a syntax reference, examples, use-cases, and the usual doc
faire.
"""
# github:repo: leemeichin/marionette
# delivery: single-pr
# delivery:branch: claude/marionette-docs-site-zm5vzp
# report: at-checkpoints

VAR readme_passes = 0
VAR demo_passes = 0

-> capture_reality

=== capture_reality ===
Run the real CLI against the worked examples and capture verbatim transcripts:
validate (clean and failing), compile, render, summarize, state init/choose,
and brief. These transcripts are the single source of truth — every terminal
snippet in the README and every interactive demo on the site must match them
byte-for-byte.
-> rewrite_readme

=== rewrite_readme ===
Rewrite README.md to say what Marionette is and does: the one-line thesis,
why it exists, the authoring-to-execution flow, with brief but illustrative
examples whose output is checked against the captured transcripts.
~ readme_passes += 1
* [Reads clean, examples verified] -> design_system
+ {readme_passes < 3} [Tighten prose and examples] ~loop~ -> rewrite_readme
* {readme_passes >= 3} [Not landing after three passes] @human -> design_system

=== design_system ===
Define the site's design system: full-viewport terminal aesthetic with
design tokens (monospace type scale, phosphor palette at WCAG AA contrast,
spacing grid), semantic HTML rules, keyboard focus and reduced-motion
behaviour. Accessibility is a constraint, not a variant.
-> scaffold_site

=== scaffold_site ===
Scaffold the static site under docs-site/: dependency-free HTML/CSS/JS,
a Wrangler config for Cloudflare (static assets), and a local preview path.
Done means the shell page deploy-ready and the design tokens rendering.
-> write_content

=== write_content ===
Write the documentation pages: what-it-is overview, getting started, DSL
syntax reference, worked examples, use-cases, and the execution/state
workflow in practice. Content is distilled from docs/ and verified against
the real CLI, not paraphrased from memory.
-> build_demos

=== build_demos ===
Build the interactive terminal demonstrations: replayable sessions that
type and stream the captured transcripts end-to-end (author, validate with
errors, fix, compile, traverse, escalate at @human). Fidelity rule: every
frame shown is a captured byte, not a mock-up.
~ demo_passes += 1
* [Demos faithful and interactive] -> accessibility_pass
+ {demo_passes < 3} [Fidelity or interaction gaps] ~loop~ -> build_demos
* {demo_passes >= 3} [Demos not converging] @human -> accessibility_pass

=== accessibility_pass ===
Audit the whole site: AA contrast on the terminal palette, full keyboard
operability of the demos, visible focus, prefers-reduced-motion honoured,
landmarks and skip links, sensible screen-reader output for animated
terminals.
* [Audit clean] -> integrate_runtime
+ [Issues found — fix and re-audit] ~loop~ -> accessibility_pass

=== integrate_runtime ===
Main merged a local runtime mid-traversal (docs/RUNTIME.md: start/stop
lifecycle, NDJSON protocol, run store). Capture real runtime sessions with
the same fidelity rule, fold the runtime into the README and the site
(execution, reference, getting-started), and re-run every gate.
* [Runtime folded in, gates green] -> ship_review

=== ship_review ===
Everything committed on the delivery branch and pushed, draft PR open with
the site preview story and deployment instructions. A human reviews the
README and the site before anything merges or deploys.
* [Approved — merge and deploy] @human -> END
+ [Changes requested] @human ~loop~ -> address_feedback

=== address_feedback ===
Apply the review feedback across README, site or demos, re-verify affected
output against the transcripts, and return for review.
-> ship_review