In a Cypress proof-of-concept, which flows do you spike first to expose a misfit?

## Why the happy path proves nothing Every browser runner demos well. Point any of them at a list page, click a row, assert some text, and it will be green in twenty minutes. That result carries almost no information, because no serious tool fails there. The decision you are actually making is whether **this application** fits **this tool's boundaries**, and boundaries only show up where the application pushes against them. So invert the usual instinct. A Cypress proof-of-concept should start with the flows you are most afraid of, and it should be judged on what it *discovers*, not on how green it is. ## Rank the flows by what would kill the decision 1. **The journey that leaves your superdomain.** A test is bound to one superdomain, so a hop into an identity provider or a hosted payment page has to be written inside `cy.origin()`. Spike it to learn how often it appears and how readable the result is - once at sign-in is a seam; six times in one journey is a signal. 2. **The journey that opens a second tab or window.** Cypress drives one browser at a time. If the flow's assertion genuinely lives in the second tab, you are into the `@cypress/puppeteer` plugin, whose handlers run in Node. Find that out in week one, not in month three. 3. **Anything your sign-off list names that Cypress cannot launch.** It launches Chrome-family, Firefox and experimental WebKit. Safari itself and real mobile devices are not on that list, and `experimentalWebKitSupport` gives you the engine, not the browser. 4. **A flow that cannot start without back-end state.** Prove that `cy.task()` or `cy.request()` can seed it, and that somebody will own that seam, because a suite that cannot create its own data will be run manually within a quarter. 5. **The longest, most timing-sensitive flow you have.** This is where retry-ability either does the work or does not, and where an honest wall-clock number comes from. ## Run the spike the way CI will run it - Run `cypress run` headless on the image CI will use, not only `cypress open` on a developer laptop. Open mode is the tool at its most flattering, and it is not what the pipeline will do at 3am. - Point it at a real staging environment with real data volumes, not a fixture-only sandbox. - Pick the browser the pipeline will actually use with `--browser`, rather than accepting a default. - Record wall-clock time per spec, so the parallelisation conversation later has a number in it. ## What counts as a pass Green is not the bar. The bar is **green, readable, and repeatable**, with every misfit named. - Did each hostile flow pass without a workaround, with a first-party workaround, or not at all? - Would a new engineer read the resulting spec and understand it, or does it now carry two execution models - commands in the browser and handler code in Node? - Did it pass ten runs in a row on the CI image, or did it need retries nobody can explain? - How long did the spike take relative to what you predicted? That ratio is the most honest input you will get into the size of the real migration. - Did anyone outside the person running it read a spec and understand what it asserted? A suite one enthusiast can maintain is not a suite the team has adopted. Record a *worked with a workaround* result as its own outcome rather than folding it into a pass. The distinction between "Cypress did this" and "Cypress did this once we dropped into a plugin handler running in Node" is the whole content of the evaluation. ## Time-box it, and write down the verdict Give the spike a fixed budget - a few days, a named person - and end it with a short written verdict per flow rather than a demo. The useful artefact is a table of *flow, worked / worked with a workaround / did not work, and what the workaround costs*, because that table is what the adoption decision is actually made from, and it survives the person who ran the spike leaving the team. The failure mode to avoid is the spike that quietly becomes the suite. Spike code is written to answer a question, not to be maintained; if it is going to survive, it gets rewritten with the conventions the real suite will use. Otherwise the first thing a new team inherits is four specs written by someone who was still learning the tool.