Examples charter: the portfolio is the product demo, and it must not be only CI

The examples directory is where the system's power and ergonomics have to be self-evident — from authoring, to reading, to running flow for the first time and getting the feel of the whole thing in minutes. Right now the portfolio under-demonstrates: partly because some plugins and built-ins are still landing, but also because it skews toward developer/CI shapes when the system is designed for much more.

Principles

1. An example is a product surface, not a test fixture. Each one earns its place by making a reader think "I have exactly that problem" — and its Flowfile should read as the obvious way to express it. If expressing a real use case feels awkward, that's a language finding to fix, not something to paper over in the example (the "capability isn't done until reachable from a Flowfile" rule, applied to ergonomics).
2. Breadth across domains, not variations on CI. Development workflows stay (release pipelines, the git/github/codex plugins will make those shine) but the portfolio must also cover operations (incident runbooks, scheduled health checks with escalation), business processes (approvals via durable signals, onboarding, invoice/order flows with compensation), data work (fan-out enrichment with bounded parallelism, tolerated partial failure), and agentic graphs (multi-agent loops with signals, once repeat_until and the codex plugin land).
3. Each example demonstrates durability as the point, not a footnote. The reason these aren't shell scripts: a wait that survives a restart, a saga that takes back what it did, a retry policy that matches production, an approval that arrives three days later. Every example's README should name the one durability property it shows off.
4. Runnable in CI, honest in CI. Examples run through the local driver in CI (and flow fix --check covers them). Waits use timeouts so CI completes; READMEs show the durable variant beside it.
5. The protobuf IR is the client-neutral layer. YAML+CEL is one authoring client. A future visual/low-code builder (explicitly not now) authors the same Workflow message and gains everything — validation, both drivers, policy, LSP-grade diagnostics via the same RPCs. The examples' job today is to keep the IR honest: nothing an example needs should exist only as a YAML-parser trick, because that would orphan every other future client. This is a design constraint the portfolio silently enforces.
6. Meets people where they are. A first-run path (flow run local examples/...) that works with zero infrastructure, no Temporal, no server — then the same file, unchanged, run durably. That contrast is the pitch, and every README should make it in two commands.

Acceptance shape

• Every example: workflow.yaml + README (what real problem, which durability property, the two-command local→durable contrast), passes flow validate and flow fix --check, runs in CI via the local driver.
• Portfolio-level test: a table-of-contents test that fails when an example directory and the top-level examples README disagree (the drift-pin mechanism, pointed at the portfolio).
• A reader who knows nothing about flowstate can go from git clone to a successful durable-feeling run in under five minutes following only the top-level examples README.

Near-term slices

1. Now (capabilities on main): approval-gate via wait_for_signal + timeout escalation; scheduled ops check with tolerated failure + structured outputs; data fan-out with bounded parallel + continue_on_error + declared run outputs; provisioning saga narrative polish (undo already shipped).
2. After call: lands: a library workflow called from two different callers — the composition/reuse story (teams/modules per the collaboration thread).
3. After git/github/codex plugins land: release pipeline; agentic patch loop with run-to-run signals (#162).
4. After repeat_until (#157): polling/convergence shapes.

Start with the existing examples directory and its top-level README, then review the acceptance shape and the near-term slices. Add the specified workflow.yaml and README coverage, including the local-to-durable path, and use flow validate plus flow fix --check before checking the local-driver CI behavior. Done means the portfolio test prevents README drift and a new reader can complete the documented run in under five minutes.