Hand the user a working thing they can call
- Dominant language
- JavaScript
- Stars
- 400
- Forks
- 89
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 146
Description
The plan is approved, the Expert has built the flows, and the user is sitting in an editor looking at nodes they didn't write. This is the part that turns that into something they can actually use.
Two pieces:
* **Ask the user to deploy, and point at the button.** Deploying is theirs to do, so the Expert has to ask for it clearly and show them where.
* **End onboarding with working instructions for calling what was built.** Real connection details, not a description.
### Worth knowing
Deploying stays a human action deliberately. Deploy means immediate execution of whatever is on the canvas, so an agent that could deploy could run arbitrary code with the instance's credentials and reach anything that instance can reach. The user reviews what was built and presses Deploy themselves. That's a security boundary, not a missing feature.
Which does create a wrinkle worth being honest about. The whole point of this flow is that the user never has to learn platform vocabulary before something works, and "press Deploy" is platform vocabulary arriving at the last possible moment, right before the payoff. So how it's asked matters more than usual, and pointing at the actual button rather than describing it is most of the fix.
The instructions at the end are the payoff for the entire epic. Everything upstream is in service of the user ending up with a URL they can curl or a page they can open. If that last message is vague, none of the rest lands.
Blueprint-seeded flows are the exception to all of this, since they're live from the moment the instance boots and need no deploy step. So a user whose setup came entirely from a blueprint skips the deploy ask, and the Expert needs to know which situation it's in rather than always asking.
Contributor guide
Assessment
This issue has not been assessed yet.