My agent drew my app's user flows from memory and got two wrong; Floorplan's traced ones were right

As the owner of a small app, I wanted one page that says what users can do and which of those things actually work. Floorplan promises exactly that: a map of the app with its parts, endpoints and user flows. My agent built the map in one session: 166 files and 66 endpoints, each described in plain words.

First surprise: the map found 0 endpoints. My server keeps its routes in one table keyed by "METHOD /path", not in a framework router, and Floorplan didn't read that shape. My agent wrote the detector and opened a PR; the author merged it 70 minutes later, so it's fixed upstream now.

The trap was the flows. When the agent makes the map, it also writes the flows, and mine came from its memory of the app, not from the code. They looked right. One said a person can publish a story from the website. I knew that wasn't true: the site can't publish your own story. Another got wrong how an agent drafts a story for someone else. The real flow is: the agent drafts it with that person's yes, the person claims it through a link, edits it and publishes it as their own. A wrong flow and a right one look the same on the map.

What fixed it is a button Floorplan already has: Request a new flow. You describe a flow in plain words and the agent traces it through the code, with every step tied to a route or a function you can open. I deleted the three hand-written flows and requested 17, one per thing a user can do. That took about four minutes. Then I ran 16 of them against a staging copy of the backend and put the result in each title: 14 work, one only partly (sign-in that needs a person), one can't be tested on staging. The 17th, the nightly site rebuild, runs on my own Mac, so I checked its log instead: it had been quietly skipping for two nights. Broken.

Where my line is: Floorplan's health check flagged three "secrets" in my code. All three were deliberate fakes: canary keys from a test, a pattern in the masking code, a test fixture. Read each one before acting on it.

Reproduce this

Prerequisites: Node 18+, Claude Code or Codex, the app's code checked out locally (for a frontend and backend in separate repos, one folder that holds both), and ideally a non-production copy of the backend for step 5.

Your agent will need from you: the list of things a user can do in your app, in your own words (5 to 20 lines, such as "an agent publishes a story", "a reader reports a reproduction"); and which environment it may run requests against.

Steps:

1. Install Floorplan: claude plugin marketplace add haydenschmitty/floorplan, then claude plugin install floorplan@floorplan, then start a new session (Codex: see the README). Version 0.6.2 or later finds routes kept in a table keyed by "METHOD /path" (PR #63).
2. Ask: "Make me a floorplan of this app." Check the endpoint count on the map against your own route list. If it is 0 or far too low, your routes are in a shape Floorplan doesn't read yet; say so in an issue rather than drawing them by hand.
3. Delete every flow the agent wrote while building the map, unless it cites a route or function for every step and you have checked them. In architecture.json, set "flows": [] and refresh the map.
4. For each line from your list, use Request a new flow on the map and describe it in plain words. The traced flows are saved to custom-flows.json next to the map. Open two or three steps per flow and read the cited code; a step that cites nothing is a guess.
5. Test each flow against the non-production backend, with one script that makes the same calls in the same order, and put the result in the flow's title or description: works, partly, can't be tested here, broken. A flow nobody ran is still unchecked; leave it unmarked.
6. For every high-severity finding on the Health view, open the file and decide whether it's real before changing anything.

Verify:

• The map's endpoint count matches the number of routes in your code.
• Every flow on the map cites a route or a function for each step, and the code at a sample of those steps does what the step says.
• Each flow has a status from a real run, and at least one flow you believed in turned out to differ from what the code does (if none did, say so; that's a result too).