In-IDE build surface
A developer portal with a built-in IDE: a build prompt, a single-document code editor, device previews, a runtime console, and a virtual filesystem inspector.
Developer IDE workspace
Technical overview / App Center
Document: VT-APP-01Revision: 1.0 Implemented architecture
App Center AI Integration Architecture
A developer marketplace whose in-IDE assistant turns a written request into a complete, sandboxed VibeOS app — through a bounded model contract, a validation gate, and a reviewed publication path.
01
AI Integration Architecture
IDE, orchestration, access controls, model, runtime, and catalog boundaries
App Center AI integration architecture Implemented architecture
App Center IDE
Developer-facing build surface with a prompt box, single-document code editor, device previews, and a virtual filesystem inspector
Build promptCode editorDevice previewsRuntime console
Access, Plan & Quota Controls
Session, plan, and token-budget checks sit between the IDE and the orchestration layer so unauthorized or unaffordable builds stop before model work
Session checkPlan authorizationToken budgetAccess probe
Orchestration & Translation Layer
Turns a build request into a bounded model contract and turns the model answer back into a runnable app plus a validated manifest
Prompt contractModel tieringDocument extractionManifest mapping
AI Model
An approved Gemini-class model returns one self-contained app document and a trailing metadata block, and nothing else
Pro tierFlash tierLite tierOutput cap
Sandboxed .vibe Runtime
The generated document runs in a cross-origin sandboxed frame with a VibeOS runtime shim, a virtual filesystem, and an allow-listed network surface
Sandboxed framevos.fsvos.ai bridgeNetwork allow-list
Catalog & Review Records
Saved apps become versioned manifests in the marketplace catalog and move through submission, review, and publication states
AppsVersionsReviewsPublication state
Runtime boundary. The model writes an app document. It does not install, publish, or gain runtime authority — the sandbox and the review state machine decide what ships.
02
Generation services & runtime surfaces
Implemented components behind App Center's app builder
Prompt contract
Build rules are assembled server-side from a fixed core rule set plus only the topic rules that match the request, keeping the contract tight and predictable.
Core rules plus matched topics
AI model
An approved Gemini-class model produces the app. The request is placed through a governed model boundary that enforces access, plan, and token budget before generation.
Approved model boundary
Single-document output
Each app is one self-contained document with inline styling and scripting — no frameworks, imports, remote assets, or build step.
One .vibe app document
Sandboxed runtime
Generated apps execute in a cross-origin sandboxed frame with a VibeOS runtime shim providing a virtual filesystem, an AI bridge, and an allow-listed network surface.
Sandboxed VibeOS shim
Catalog & review
Saving writes a schema-validated versioned manifest into the marketplace catalog; submission moves the app through manual and automated review toward publication.
Versioned marketplace records
03
App generation lifecycle
From written request to reviewed marketplace app
- 01
Request
The developer describes the app, optionally with the current document and attached images, inside the IDE build prompt.
- 02
Authorize
The build runs as a verified server call; session, AI access, plan, and remaining token budget are resolved before any generation.
- 03
Constrain
The orchestration layer assembles the build contract: core app rules, matched topic rules, the existing document, and asset placeholders.
- 04
Fit
A model tier and output budget are chosen to fit the available allowance, stepping down tiers and refusing below a usable floor.
- 05
Generate
The model returns one complete app document followed by a single metadata object, with no prose or partial file listings.
- 06
Validate
Extraction strips wrappers, cuts at the closing tag, and rejects truncated or malformed output instead of repairing it.
- 07
Retry
A rejected answer gets one bounded, explicitly smaller rebuild attempt on a lighter tier rather than an open retry loop.
- 08
Preview
The accepted document runs immediately in the sandboxed frame across mobile, tablet, and desktop viewports with runtime errors captured.
- 09
Review
Deterministic checks flag interaction, audio, and layout issues for the developer, who remains the author of record.
- 10
Publish
Saving validates the manifest and stores a versioned catalog record; submission advances review state until the app is published.
04
App generation network
Detailed flow inside App Center's orchestration and translation layer
App generation network Prompt-to-published-app path
Build Request Capture
The developer's request, the current app document, the app name, and any attached images are collected and length-bounded in the IDE
Prompt inputCurrent documentImage attachments
Session Verification
The build runs as a server call that verifies the signed developer session before any model work begins
Server functionSigned sessionUnauthenticated stop
Prompt Contract Assembly
Core build rules are combined with only the topic rules matched by the request, then paired with a user turn carrying the existing document and attachment placeholders
Core rulesMatched topic rulesAsset placeholders
Access, Plan & Quota Gate
AI availability, plan authorization, and remaining token budget are resolved first, so blocked or unaffordable builds never reach the model
Access probePlan stateQuota state
Model Tier & Output Budget Fitting
The request asks for a large output budget and steps down through model tiers when the available budget is smaller, refusing below a usable floor
Budget fitTier step-downUsable floor
Single-Document Generation
The model returns one complete app document followed by a metadata marker and a single JSON object — no file tree, no prose, no fences
One HTML documentMetadata markerInline CSS and JS
Extraction & Completeness Gate
Fences are stripped and the document is cut at its closing tag; a truncated or malformed answer is rejected rather than repaired
Fence stripClosing-tag cutNo silent repair
Bounded Retry
A rejected or cut-off answer gets one smaller, explicitly concise rebuild attempt on a lighter model instead of an open retry loop
Single retryLighter tierConcise rebuild
Manifest & Metadata Mapping
The trailing metadata block supplies name, description, icon, genre, window size, declared permissions, and a change summary for the app form
Declared permissionsIcon and genreChange summary
Sandboxed Preview Execution
The document runs immediately in a sandboxed frame with the VibeOS runtime shim at mobile, tablet, and desktop viewports
Sandboxed frameRuntime shimThree viewports
Deterministic Quality Checks
Rule-based checks and captured runtime errors flag input, audio, and layout problems for the developer without rewriting the app
Static findingsRuntime consoleDeveloper decision
Save, Submit & Review
Saving validates the manifest against its schema and writes a versioned catalog record; submission advances the review state machine toward publication
Schema validationVersioned manifestReview states
Runtime boundary. Every generated app is a single self-contained document. Incomplete output is rejected, execution is sandboxed, and publication requires an explicit review pass.
05
Responsibility & trust boundaries
Authority by implementation component
ComponentResponsible forNot responsible for
App Center IDE
Responsible for
Build prompts, document editing, device previews, runtime console output, and the save and submit decisions
Not responsible for
Not responsible for granting a generated app any authority outside its sandbox
AI model
Responsible for
Writing one self-contained app document and its declared metadata from the supplied contract
Not responsible for
Not responsible for installing, publishing, reading catalog data, or reaching real user files
Orchestration & translation
Responsible for
Contract assembly, model tiering, budget fitting, output extraction, completeness checks, and manifest mapping
Not responsible for
Not responsible for repairing incomplete model output or approving an app for the marketplace
Access, plan & quota controls
Responsible for
Session verification, AI availability, plan authorization, and token budget enforcement ahead of generation
Not responsible for
Not responsible for altering the model's answer once a build is approved
Sandboxed runtime
Responsible for
Executing the app document, the virtual filesystem, the app AI bridge, and the allow-listed network surface
Not responsible for
Not responsible for giving apps host page access, real credentials, or unrestricted network reach
Marketplace catalog
Responsible for
Versioned manifests, submission states, ratings, review records, and what is publicly visible
Not responsible for
Not responsible for treating an unreviewed draft as a published app
06
Generation & release controls
Implemented safeguards around generated app code
Pre-generation gating
Access, plan, and quota state are checked before the model is called, so blocked or unaffordable builds fail clearly instead of half-running.
Access, plan, quota
Budget fitting
Output budget and model tier are matched to the remaining allowance, with an explicit refusal below a minimum usable size.
Tier step-down
Completeness gate
Output must be a complete document. Truncated or malformed answers are rejected rather than silently patched into a broken app.
No silent repair
Bounded retry
One concise rebuild attempt follows a rejected answer, keeping cost and behavior predictable.
Single retry attempt
Execution sandbox
Generated code runs without host-page access; filesystem, AI, and network capabilities are mediated by the runtime shim and declared permissions.
Cross-origin sandbox
Review before publication
Apps advance through submission, manual and automated review, and change requests before they can reach the public catalog.
Submission state machine
Failure behavior: unavailable AI access, exhausted budgets, truncated documents, and failed manifest validation return explicit developer-facing errors instead of saving a broken app or publishing an unreviewed one.
07
Persistent marketplace records
What App Center stores once an app is saved
Apps
The catalog record for each app: slug, name, type, genre, icon, owner, submission status, and the pointer to its live version
App versions
One record per version holding the app manifest — including the app document itself — plus its changelog
Reviews
Manual and automated review decisions, summaries, and findings, readable only by server-side review code
Ratings
One rating and comment per developer account per app, with moderation status
Genres
The marketplace category list used to place and browse apps
Profiles
Public developer profile details shown alongside published apps
Note: the app document itself is stored inside the version manifest rather than as a separate file bundle, and review records stay server-side rather than being publicly readable.