Appmint - AI That Builds & Runs Your Entire Business

Vibe Studio supports several frameworks out of the box. The active framework lives in .vibe/project.json under the framework field — null by default, set when the agent or a scaffolding step recognises one. Detection drives the build pipeline at deploy time.

Detected frameworks

Framework	Detected from	Build pipeline
`vanilla-html`	An `index.html` at the workspace root with no framework markers	No build — files served as-is
`vite-react`	`vite.config.{js,ts}` + a React import in `package.json`	`npm install && npm run build`, output from `dist/`
`next`	`next.config.{js,ts,mjs}` or `next` in `package.json`	`npm install && npm run build`, output a Next standalone build
`astro`	`astro.config.{js,ts,mjs}` or `astro` in `package.json`	`npm install && npm run build`, output from `dist/`
`vue`	`vue.config.{js,ts}` or `@vue/cli` in `package.json`	`npm install && npm run build`, output from `dist/`
`svelte-kit`	`svelte.config.{js,ts}` or `@sveltejs/kit` in `package.json`	`npm install && npm run build`, output from `.svelte-kit/output/client/`

The detector is deliberately simple: file presence + package.json keywords. Edge cases (e.g., a non-React Vite project) fall through to vite-react because the build step is the same — they just won't have React-specific dev tooling.

How detection runs

Two paths to set framework:

At scaffold time — when POST /api/dev-envs creates a workspace with a description, the AI scaffolds the right framework and updates .vibe/project.json with the chosen value.
On the fly — the agent re-detects whenever it adds a framework-marker file (a vite.config.ts, a next.config.js). It calls projectIdentityService.update(...) to persist the new value.

You can manually update the field by editing .vibe/project.json and saving. session-manager picks up the change next time it reads the file.

Skipping the scaffold

If you provide a description when creating the dev env, the scaffold step is skipped:

curl -X POST "$SESSION_MANAGER_URL/api/dev-envs" \
  -H "Authorization: Bearer $APPMINT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "orgId":"my-org",
    "projectName":"storefront",
    "description":"A Next.js storefront with Tailwind"
  }'

session-manager checks for a non-empty description and sets skipScaffold: true automatically. The agent then picks the right framework based on what you asked for.

If you don't supply a description (or pass skipScaffold: false), session-manager initialises the workspace with a basic HTML scaffold — index.html, main.js, and a CLAUDE.md rules file.

The HTML scaffold

The default vanilla-html scaffold is what fileService.initializeWorkspace(...) produces:

{/* index.html */}
<!DOCTYPE html>
<html>
<head><title>My App</title></head>
<body>
  <script src="main.js"></script>
</body>
</html>

// main.js
console.log("App loaded");

# Project Rules

- Every HTML element must have a unique, descriptive `id` attribute.
- When modifying existing elements, preserve their `id` attributes.
- When creating new elements, always add a meaningful `id`.

The CLAUDE.md rules above feed into the agent's selector script (/api/vs-selector.js), which lets the studio's preview pane wire up element selection — clicking an element in the preview tells the editor which file/line to jump to. The id-required rule keeps the selector stable across edits.

Switching frameworks mid-project

Tell the agent:

"Convert this project from vanilla HTML to Vite + React. Update .vibe/project.json framework field too."

The agent will:

Add package.json, vite.config.ts, tsconfig.json.
Convert index.html to the Vite entry shape.
Move main.js to src/main.tsx.
Update the framework field via projectIdentityService.update(...).

After the switch, redeploy so the build pipeline runs the new framework's commands.

Custom framework registration

For frameworks not in the table — Remix, Qwik, Solid Start, etc. — register at the deploy layer, not at the workspace layer. The build pipeline lives in session-manager/src/services/deploy.service.ts. To add a framework:

Add a detector function that inspects the workspace.
Add a build step that runs the framework's build command.
Add an output-dir path the package step uploads.

The agent will pick up the new framework as a valid framework value once it's in the detector list. Until then, the workspace just falls through to vite-react or vanilla-html.

In production

The current detector is conservative — most apps falling through to vite-react are fine because npm run build works for nearly any modern bundler. Adding a custom framework definition is mostly cosmetic (so the planner / studio shows the right name).

What deploys uses framework for

Three things at deploy time:

The build command. SpinForge expects pre-built static output for non-Node frameworks; for Node frameworks it expects a runtime config.
The output directory uploaded.
The site type — static vs node vs next — sent to SpinForge so it routes traffic correctly.

If framework is null and there's no detection match, deploys fall through to "treat as static" — useful for plain HTML apps but wrong for anything that needs a build step. Set the field correctly to avoid this trap.