Advanced Prompts

Create an advanced VibeFlui orders page that fetches, creates, updates, and deletes orders through an existing backend's REST endpoints.

Return separate files with path labels:
- schemas/orders/order.resource.schema.ts
- components/vibeflui/renderers/orders/OrderStatusBadge.tsx
- components/vibeflui/renderers/orders/OrderTotalCell.tsx
- lib/vibeflui/registry.tsx
- app/orders/page.tsx

Requirements:
- resource: orders
- mode: server
- provider.type: rest
- identity key id and param id
- endpoint map:
  - list GET /api/orders
  - create POST /api/orders
  - update PATCH /api/orders/:id
  - delete DELETE /api/orders/:id
- table columns: orderNo, customer, status, total, createdAt
- status uses OrderStatusBadge
- total uses OrderTotalCell
- search enabled
- filters include status select with paid, pending, failed
- sorting default createdAt desc
- pagination enabled with pageSize 10
- rowSelection enabled with mode multiple
- table export enables csv and columnVisibility
- actions: create, edit, delete with confirm
- row action invoice uses handler orders.invoice
- bulk action bulk-export uses handler orders.bulkExport
- permissions: orders.write and orders.delete
- registry registers renderers, actionHandlers, permissionResolvers
- renderer components are separate files
- registry does not contain JSX
- page does not inline async functions in <FluiKit> or <FluiKitForm>

Add permission-based UI to the orders schema.

Rules:
- edit requires permission orders.write
- delete requires permission orders.delete
- registry has permissionResolvers for both keys
- page passes permissionContext through FluiKitProvider
- explain that backend authorization is still required

Create a VibeFlui table with complex row actions.

Goal:
- Use VibeFlui's built-in row action buttons and action column.
- Do not recreate table action buttons manually in the page.
- When a row action needs custom behavior, replace the action execution with a registry action handler.

Return separate files with path labels:
- schemas/orders/order.resource.schema.ts
- lib/vibeflui/registry.tsx
- lib/vibeflui/actions/order-row-actions.ts
- app/orders/page.tsx

Requirements:
- resource: orders
- table columns: orderNo, customer, status, total, createdAt
- keep built-in view/detail, edit, and delete actions when they are needed
- add custom actions through actions.row
- each custom row action must have key, label, icon, variant, optional confirm, and handler
- register every handler key in registry.actionHandlers
- declare every handler key in schema.registry.actionHandlers
- put handler functions in lib/vibeflui/actions/order-row-actions.ts
- registry only imports and wires handler functions
- page only wires FluiKitProvider, schema, registry, and data/provider
- do not inline async functions inside <FluiKit> or <FluiKitForm>
- do not put JSX inside createRegistry unless registering a component or renderer import

Example action pattern:
- actions.row item: { key: "approve", label: "Approve", handler: "orders.approve" }
- registry.actionHandlers["orders.approve"] executes the custom approve flow

Explain:
- VibeFlui still owns visibility, permission checks, confirm dialog, grouping, feedback, and action events.
- The registry handler only replaces the execution logic for that action.
- If an existing built-in action already fits the need, use the built-in action instead of creating a duplicate custom button.

Generate action handler responses for VibeFlui.

Rules:
- success returns { status: true, code: 200, message }
- expected business rejection returns { status: false, code: 409, message }
- server failure returns { status: false, code: 500, message }
- explain that false status with 4xx code maps to warning feedback
- do not document business rejection as a FluiKitFeedbackStatus

Wire the create-order handler against this exact backend response for POST /api/orders.
Do not change the response shape; adapt the handler to it.

Backend response on success:
{
  "ok": true,
  "http_status": 201,
  "detail": "Order created successfully",
  "payload": { "id": "ord_9001" }
}

Backend response on business rejection (e.g. out of stock):
{
  "ok": false,
  "http_status": 409,
  "detail": "Item is out of stock"
}

Requirements:
- identify which backend key is the success/failure flag and which is the human-readable message
- the registry.actionHandlers["orders.create"] function must call the backend, then return VibeFlui's response contract by mapping:
  - backend "ok" -> VibeFlui "status"
  - backend "http_status" -> VibeFlui "code"
  - backend "detail" -> VibeFlui "message"
  - backend "payload" -> VibeFlui "data"
- do not assume the backend already returns { status, code, message, data } — show the mapping explicitly in the handler function body
- explain that status: false with a 409 code resolves to warning feedback, not error feedback

// lib/vibeflui/registry.tsx (handler body, illustrative)
actionHandlers: {
  "orders.create": async ({ values }) => {
    const response = await fetch("/api/orders", {
      method: "POST",
      body: JSON.stringify(values)
    });
    const backend = await response.json();
    // Map the backend's own field names to VibeFlui's response contract.
    return {
      status: backend.ok,
      code: backend.http_status,
      message: backend.detail,
      data: backend.payload
    };
  }
}

Add React Select to a VibeFlui product tags field.

Return separate files:
- schemas/products/product.form.schema.ts
- app/providers.tsx
- app/products/page.tsx

Rules:
- install @vibeflui/react-select and react-select
- create plugin with createReactSelectPlugin
- register plugin in FluiKitProvider
- form field uses adapter react-select
- use static options or optionLoader
- do not use table filter adapter syntax; table filters need filter.type custom plus a registry component
- do not claim the adapter is available unless the @vibeflui/react-select package and export exist in the current source

Audit this VibeFlui example.

Check:
- schema keys exist in current FluiKitConfig types
- form keys exist in FluiKitFormConfig
- table keys exist in FluiKitTableConfig
- action keys exist in FluiKitActionConfig
- adapter/plugin behavior exists in the current package source before being documented
- custom renderers/components are separate files
- registry only wires imports and functions
- page does not inline async handlers in FluiKit or FluiKitForm
- response status false with 4xx code is described as warning feedback
- no backend security claim is made by frontend permissions