Oblive Docs

Frontend Development

Add organization-scoped product behavior with complete loading, error, empty, and durable-state handling.

Ownership

The frontend presents backend-owned state and submits typed user intent. It does not invent task identifiers, infer authorization, or become the canonical owner of lifecycle state.

Add a Product Route

  1. Keep the organization ID in the route and query scope.
  2. Define typed loader/query behavior.
  3. Render loading, empty, partial, failure, and success states.
  4. Keep mutations explicit and refresh or reconcile affected data.
  5. Preserve actionable backend validation messages without leaking raw internal errors.
  6. Add route and helper tests.

Add an Integration Card

Managed provider name, description, URLs, icon, setup Markdown, categories, departments, and grants should remain catalog-driven. Add provider-specific UI only for behavior that cannot be expressed by the generic credential, access-mode, tool-selection, and status components.

OAuth providers usually need:

  • service selection;
  • connect and callback states;
  • redacted identity;
  • missing-scope handling;
  • same-account reauthorization; and
  • disconnect confirmation.

Human Inbox

Keep Questions, Approvals, and Reconciliation visibly distinct. A user should know whether they are providing information, authorizing a future effect, or recording the result of a possibly completed effect.

Context Rendering

Render source Markdown through the safe product boundary, preview PDFs without treating them as trusted executable content, and keep citations linked to retained source identity.

Product Theme

Use the shared Oblive color language: Geist, neutral surfaces, green primary, restrained shadows, and accessible light/dark states. This documentation site mirrors those tokens without importing frontend CSS directly.

Documentation Impact

When UI changes alter a documented flow, replace the affected screenshot and update the operator steps in the same commit.