Use the web console

The console is the browser version of the passo.build flow. Use it when you want to see each decision, answer questions manually, and approve deploy choices in a normal web UI.

The five steps

Step	What you do	What passo.build produces
1. Repository	Select the repo or repos that make up the product. Add a short product brief if the code alone is not enough.	A project snapshot tied to specific repositories and refs.
2. Product scope	Review what the app appears to be, answer missing questions, and decide which gaps must be fixed before deployment.	A practical implementation plan for the coding agent: backend features, data model, APIs, security fixes, and operational work.
3. Security	Run checks after scope is clear. Do not scan a half-defined product and pretend it is ready.	Evidence about secrets, dependencies, exposed APIs, auth risks, and release blockers.
4. Infrastructure design	Review the proposed shape of the deployment. This should be readable as product infrastructure, not a cloud diagram quiz.	A service plan: frontend host, APIs, database, storage, jobs, auth, secrets, monitoring, sizing assumptions.
5. Compare & deploy	Pick region, provider, sizing, spend cap, and account mode. Then deploy only after the gates are satisfied.	Cost comparison, selected provider, deployment evidence, rollback path.

What should happen before deploy

The console should make these questions explicit:

• What parts of the app are public and what parts are private?
• Where does persistent data live?
• Are files stored correctly?
• Are secrets kept server-side?
• Is login/role/tenant behavior clear?
• Do background jobs need a worker or scheduler?
• Are costs and provider choices understandable?
• Is there enough evidence to deploy and roll back safely?

If any answer is missing, the right next step is usually an implementation task for the coding agent, not a deploy.

Resume and handoff

The wizard state is stored on the project. You can stop at scope, fix code in your agent, come back to security, and later continue to compare/deploy. The same project state is also what the MCP/coding-agent flow is designed to use.

Review the generated plan

A good plan is specific enough that a coding agent can implement it without guessing. It should name:

• the backend features that are missing;
• the data that must be stored durably;
• APIs, GraphQL operations, or REST endpoints the frontend needs;
• auth, roles, tenant, and admin behavior;
• file storage, jobs, webhooks, and external services;
• tests and evidence required before deploy.

If the plan only says "add backend" or "improve security", send it back through scope. That is not yet actionable.