The agentic pipeline

Fixtureframe is driven from the terminal your coding agent already lives in. You describe a walkthrough; the agent writes a Playwright script and a confirmed brief; the CLI checks both, runs the script, and the recorder turns what happened into a flow.

The whole design rests on one sentence:

The agent never writes the flow definition.

Why that sentence exists

The obvious approach is to have a model write the flow directly — steps, targets, capture policy — from a one-line description. We built that. It produced flows that failed after repair, and the canonical failure is worth stating plainly:

A branding walkthrough recorded a circle. Five steps, lint clean, schema valid, published as version 1 — with nine of thirteen beats matching nothing.

Every static gate passed. That is what a model produces when it goes wrong: a plausible account of work that did not happen, indistinguishable from success until somebody watches it.

What changed

The model moved off the artifact that has to be correct.

A Playwright action raises the same DOM events a hand does, so a script drives the product while the same recorder that watches a person writes the flow. The steps go through the same canonicalisation, the same schema, and the same publishing route as a hand-made recording. Nothing about the result differs — only who did the clicking.

The loop

Follow From sign-in to a published flow for copyable commands and prompts. Set up once with a Studio API key, ff init, ff session init and ff agent install. Survey the app, organize its knowledge with /ff-context, and inspect missing detail views before choosing the proof for a flow. Adapters and catalogue suggestions are optional routes when you need them.

ff brief and ff lint are free and meant to be run constantly. ff script and ff publish are the two that need your approval, because one opens a browser and spends, and the other changes what other people see. A failed capture goes to ff diagnose and comes back as an edit to the script — not as a re-run to see whether it passes this time.

flowchart TD
  confirm{"Confirm the beats"} --> write["Agent writes brief.yaml<br/>and the Playwright script"]
  write --> checks["ff brief · ff lint<br/>free"]
  checks --> script["ff script --session --local-only<br/>authorized capture"]
  script --> review["Inspect frames and replay<br/>with the configured authentication"]
  review --> publish["Publish selected profile and flow<br/>within your authorization"]
  script -. "a step failed" .-> diagnose["ff diagnose"]
  diagnose -. "edit the script" .-> checks

Beats are the input that matters

A beat is one step of the walkthrough in the author's own words. "Open Settings → Environments. Add an environment. Name it and give it a base URL. Save."

Beats come from a person, or from named evidence a person then agreed to — a test file, a help article, a catalogue entry. They are never invented. This is enforced rather than asked for: the brief schema refuses inferred beats outright, and ff script refuses to open a browser when nobody has confirmed them.

That refusal is the point. Capturing from beats nobody agreed to spends a vendor call and leaves state behind in a real tenant, in service of a story nobody has read.

What the CLI guarantees, whatever agent is driving

The gates are not the agent's good behaviour, and they are not your host's permission settings either. They are in the CLI:

• ff brief exits non-zero on beats nobody confirmed
• ff lint refuses to run without a survey, rather than printing a green tick that means nothing
• a flow in which a credential survived redaction is never written at all
• authenticated captures use a saved session or configured adapter; login details do not belong in the brief

For saved-session workflows, ff script --session and ff run --session reuse authentication earned through interactive sign-in; username/password variables are not required. The CLI's static checks establish structure and execution prerequisites, not whether a story teaches its goal. Review actual screenshots and declared outputs against the agreed viewer questions.

Start here