AI Guide

Use this guide when an AI assistant helps generate, review, or modify VibeFlui schemas.

VibeFlui works best when AI output stays declarative, source-aligned, and organized into predictable files. Ask the AI to generate schema, registry, custom components, and page wiring as separate files.

VibeFlui is UI-only

VibeFlui renders in the browser and never runs on a server. When a prompt or example in this guide says "server mode," "backed by REST endpoints," or similar, it means the UI fetches data from an existing backend you already have over HTTP — using dataMode: "server"/mode: "server" plus provider/endpoint config. VibeFlui does not host, run, or migrate that backend. Any backend route file shown in an example (for instance app/api/orders/route.ts) represents a separate backend implementation the reader owns — it is illustrative context for the prompt, not something VibeFlui generates or executes.

Reading order

1. AI Source Map
2. Output Structure
3. Basic Prompts
4. Intermediate Prompts
5. Migration Prompts
6. Advanced Prompts
7. Review Checklist

If an AI agent crawls the documentation, start with AI Source Map. It maps root schema keys to their purpose and points the agent to the next reference page before generating code.

Core rule

Do not put everything in one React page. A clean VibeFlui result should usually look like this:

app/
  products/
    page.tsx
schemas/
  products/
    product.resource.schema.ts
components/
  vibeflui/
    renderers/
      products/
        ProductStatusBadge.tsx
lib/
  vibeflui/
    registry.tsx
    examples/
      product-crud-actions.ts

What to tell the AI

Use direct instructions:

Generate VibeFlui code as separate files.

Rules:
- Put schema in schemas/<resource>/<resource>.resource.schema.ts.
- Put custom renderers/components in components/vibeflui/... .
- Put registry setup in lib/vibeflui/registry.tsx.
- Put reusable handlers/helpers in lib/vibeflui/examples/... .
- Put only page wiring in app/<resource>/page.tsx.
- Do not inline JSX inside createRegistry.
- Do not inline async handlers inside <FluiKit> or <FluiKitForm>.
- Use only keys available in @vibeflui/core.
- Verify advanced features against the current VibeFlui source before documenting them as available.

Feature verification

Before documenting adapters, plugins, providers, advanced schema keys, or UI behavior, verify that the feature exists in the current VibeFlui package source. If the feature cannot be verified, do not present it as available.

Why separation matters

• Schema stays JSON-friendly and easier to audit.
• Custom UI is reusable and testable.
• Registry remains a wiring layer, not a component dumping ground.
• Page files stay small.
• Live rendered examples can reuse the same schema and fixture data.
• Future AI edits can change one layer without damaging the others.

Response contract

Handlers and endpoints should return a backend-style response object:

lib/vibeflui/registry.tsx

return {
  status: true,
  code: 200,
  message: "Product updated"
};

VibeFlui treats 200..299 as success feedback when no stricter status is present. For expected business or validation responses, return status: false with a 400..499 code so the UI renders warning feedback.