Step 4: Confirm Spec
Phase: spec
Context
You have app_description, matched_template_or_null, and feature_answers. Time to confirm everything with the user before building.
What to do
Summarize what you're going to build in plain, friendly language. Present it as a short description the user can confirm.
Example format to present to the user:
"Here's what I'll build for you:
Your App Name — A [brief description].
- People [will/won't] need to sign in
- It'll include [feature 1], [feature 2], [feature 3]
- It'll work on [phones and computers / computers only]
- [Any other key features]
Sound good? Anything you want to add or change?"
If the user wants changes, go back to the relevant question and update. Then re-confirm.
Guardrail verification (mandatory)
Before confirming, scan every feature in your summary against the capability guardrails. For each feature, verify it is buildable on run402. If you find a feature that slipped through (not flagged in Step 3), stop and address it with the user now — do not proceed to planning with impossible features in the spec.
Once confirmed, build the internal app_spec — this is a structured document for YOUR use (not shown to the user). It translates the user's plain-language answers into the technical details you'll need for building.
Internal app_spec format
{
"app_name": "User's app name or a generated name",
"description": "Plain-language summary",
"template": "template_name or null",
"features": {
"auth": true/false,
"auth_type": "email_password",
"data_types": ["list of things stored"],
"multiplayer": true/false,
"polling_needed": true/false,
"file_uploads": true/false,
"search": true/false,
"categories": true/false
},
"ui": {
"mobile_friendly": true/false,
"color_scheme": "description or null"
},
"guardrail_notes": "Any limitations flagged and accepted alternatives"
}
This spec stays in your memory. The user never sees this technical version.
Expected output
app_spec— The structured app spec (JSON format above), stored in memory. Confirmed by the user.