docs(sqlite-studio): bootstrap docs app

apps/docs/.gitignore

@@ -0,0 +1,14 @@
+node_modules
+.env*
+!.env.example
+.next
+.nuxt
+.output
+.svelte-kit
+.astro
+dist
+build
+.vercel
+app/api/docs
+app/docs/layout.tsx
+mdx-components.tsx

apps/docs/app/docs/api/page.mdx

@@ -0,0 +1,20 @@
+---
+title: "API Reference"
+description: "Concrete developer-facing surfaces: commands, exports, adapters, routes, and type contracts."
+order: 70
+---
+
+# API Reference
+
+These pages cover API reference for SQL Studio.
+
+## When to Use This Section
+The API reference collects the concrete developer surface of SQL Studio: terminal commands, import paths, route handlers, adapters, configuration helpers, and type contracts. Start with the page that matches what you are trying to call or run, then move to setup and configuration pages when you need the surrounding runtime context.
+
+## Available Pages
+- [API Routes](/docs/api/routes) - API routes explain how requests enter the application and reach runtime behavior.
+
+## Reading Order
+- Choose CLI pages when you need commands, flags, or terminal workflows.
+- Choose export or adapter pages when you need import paths, package entrypoints, or framework integration contracts.
+- Use configuration pages alongside API pages when an API depends on environment values, secrets, or runtime options.

apps/docs/app/docs/api/routes/page.mdx

@@ -0,0 +1,34 @@
+---
+title: "API Routes"
+description: "API routes explain how requests enter the application and reach runtime behavior."
+order: 80
+---
+
+# API Routes
+
+API routes explain how requests enter the application and reach runtime behavior.
+## Contract
+HTTP route documentation explains how requests enter the application, which handlers own the behavior, and what runtime configuration or environment each route depends on.
+## Key Ideas
+- HTTP routes
+- request handlers
+- controllers
+- routing
+- runtime behavior
+## Import Surface
+Use the source files listed below to confirm the import path before publishing examples.
+## API Mental Model
+Utility APIs are best understood through the behavior they support, not only through exported names.
+## Related Exports
+- `AllDbs`
+- `Args`
+- `autocomplete`
+- `ClickhouseCount`
+- `ColumnInfo`
+- `Command`
+- `Count`
+- `Database`
+- `Db`
+- `duckdb_value_to_json`
+- `erd`
+- `Erd`

apps/docs/app/docs/architecture/overview/page.mdx

@@ -0,0 +1,26 @@
+---
+title: "Architecture Overview"
+description: "The architecture page explains the repository as a set of real subsystems so readers can orient themselves before diving into commands, exports, or implementation files."
+order: 120
+---
+
+# Architecture Overview
+
+The architecture page explains the repository as a set of real subsystems so readers can orient themselves before diving into commands, exports, or implementation files.
+## Purpose and Scope
+SQL Studio is easiest to understand when the major subsystems are visible first. This page explains the real runtime areas in the repository, how they connect, and which reader-facing docs pages to use next.
+## Primary Subsystems
+- [Core Backend Systems](/docs/backend/systems) - The backend page explains request handling, runtime configuration, data-facing services, and the server-side workflow behind the product.
+- [Build System and Package Structure](/docs/build/package-structure) - The build page explains how the repository is packaged, built, exported, and prepared for local development or distribution.
+## Runtime Surfaces
+- Frameworks and runtimes appear in this repository through Next.js.
+- Request or route handling is grounded in 1 source file.
+## How The Pieces Fit Together
+- The frontend explains what users or operators see first and which task flows are available in the product.
+- The backend explains how requests, jobs, and integrations turn those UI or API actions into real behavior.
+- The CLI explains how maintainers bootstrap, run, and verify the system locally.
+- The build and deployment surface explains how those pieces are packaged, shipped, and run outside development.
+## Reading Guide
+- Start with the subsystem page that matches the workflow you care about most.
+- Use configuration and API pages only after the subsystem boundary is clear.
+- Keep supporting files grounded in the runtime behavior they explain.

apps/docs/app/docs/architecture/page.mdx

@@ -0,0 +1,20 @@
+---
+title: "Architecture"
+description: "How major subsystems, runtime surfaces, and workflow boundaries fit together."
+order: 90
+---
+
+# Architecture
+
+These pages cover architecture for SQL Studio.
+
+## When to Use This Section
+Architecture is the starting point for related workflows in SQL Studio. Choose the page that matches the workflow, integration, or reference surface you need, then follow its setup and verification guidance.
+
+## Available Pages
+- [Architecture Overview](/docs/architecture/overview) - The architecture page explains the repository as a set of real subsystems so readers can orient themselves before diving into commands, exports, or implementation files.
+
+## Reading Order
+- Start with the page closest to the workflow you are trying to complete.
+- Use setup and configuration pages before running commands in a new environment.
+- Use reference pages when you already know the concept and need exact commands, imports, or options.

apps/docs/app/docs/backend/page.mdx

@@ -0,0 +1,20 @@
+---
+title: "Backend"
+description: "Server-side systems, request handling, runtime behavior, and data-facing workflows."
+order: 100
+---
+
+# Backend
+
+These pages cover backend for SQL Studio.
+
+## When to Use This Section
+Backend is the starting point for related workflows in SQL Studio. Choose the page that matches the workflow, integration, or reference surface you need, then follow its setup and verification guidance.
+
+## Available Pages
+- [Core Backend Systems](/docs/backend/systems) - The backend page explains request handling, runtime configuration, data-facing services, and the server-side workflow behind the product.
+
+## Reading Order
+- Start with the page closest to the workflow you are trying to complete.
+- Use setup and configuration pages before running commands in a new environment.
+- Use reference pages when you already know the concept and need exact commands, imports, or options.

apps/docs/app/docs/backend/systems/page.mdx

@@ -0,0 +1,18 @@
+---
+title: "Core Backend Systems"
+description: "The backend page explains request handling, runtime configuration, data-facing services, and the server-side workflow behind the product."
+order: 130
+---
+
+# Core Backend Systems
+
+The backend page explains request handling, runtime configuration, data-facing services, and the server-side workflow behind the product.
+## Purpose and Scope
+This area owns request handling, runtime configuration, integrations, and data-facing behavior. It is where the product turns input into persistent state, external calls, or responses.
+## What Lives Here
+- `src/main.rs` - Package or runtime entrypoint that pulls the main system together.
+## Operational Shape
+- Route or API entrypoints are detected in 1 file.
+- `RUST_LOG`
+## Related Areas
+- [Build System and Package Structure](/docs/build/package-structure) - The build page explains how the repository is packaged, built, exported, and prepared for local development or distribution.

apps/docs/app/docs/build/package-structure/page.mdx

@@ -0,0 +1,20 @@
+---
+title: "Build System and Package Structure"
+description: "The build page explains how the repository is packaged, built, exported, and prepared for local development or distribution."
+order: 140
+---
+
+# Build System and Package Structure
+
+The build page explains how the repository is packaged, built, exported, and prepared for local development or distribution.
+## Purpose and Scope
+This area explains how the repository is built, packaged, and exposed to consumers. It covers scripts, config files, package entrypoints, and the delivery shape readers need before they publish or self-host the project.
+## What Lives Here
+- `Cargo.lock` - Repository file related to this page.
+- `Cargo.toml` - Repository file related to this page.
+- `ui/package.json` - Repository file related to this page.
+- `ui/vite.config.ts` - Build or framework configuration that shapes the generated app, package output, or developer workflow.
+## Build Inputs
+No build-related scripts were detected.
+## Related Areas
+- [Core Backend Systems](/docs/backend/systems) - The backend page explains request handling, runtime configuration, data-facing services, and the server-side workflow behind the product.

apps/docs/app/docs/build/page.mdx

@@ -0,0 +1,20 @@
+---
+title: "Build"
+description: "Build pipeline, package structure, scripts, and delivery surfaces for the repository."
+order: 110
+---
+
+# Build
+
+These pages cover build for SQL Studio.
+
+## When to Use This Section
+Build is the starting point for related workflows in SQL Studio. Choose the page that matches the workflow, integration, or reference surface you need, then follow its setup and verification guidance.
+
+## Available Pages
+- [Build System and Package Structure](/docs/build/package-structure) - The build page explains how the repository is packaged, built, exported, and prepared for local development or distribution.
+
+## Reading Order
+- Start with the page closest to the workflow you are trying to complete.
+- Use setup and configuration pages before running commands in a new environment.
+- Use reference pages when you already know the concept and need exact commands, imports, or options.

apps/docs/app/docs/configuration/environment/page.mdx

@@ -0,0 +1,24 @@
+---
+title: "Environment Variables"
+description: "Environment variables provide runtime secrets, URLs, provider settings, and deployment values."
+order: 60
+---
+
+# Environment Variables
+
+Environment variables provide runtime secrets, URLs, provider settings, and deployment values.
+## What This Controls
+Environment variable documentation explains which runtime values the project expects, where those values are read, what each variable controls, and what developers should verify before running previews, workers, or production deployments.
+## Key Ideas
+- environment variables
+- runtime secrets
+- configuration files
+- deployment values
+## How To Think About Settings
+Configuration is useful only when readers can connect each value to behavior. Start by deciding whether the value affects credentials, persistence, routing, framework integration, output, or developer convenience.
+## Environment Variables
+- `RUST_LOG`
+## How To Verify Changes
+- Identify whether the option affects security, runtime mounting, data access, or presentation.
+- Prefer examples that use the same names and defaults found in the project.
+- Call out adapter-specific behavior instead of implying every setting applies to every framework.

apps/docs/app/docs/configuration/page.mdx

@@ -0,0 +1,20 @@
+---
+title: "Configuration"
+description: "Runtime values, environment variables, deployment settings, and framework configuration."
+order: 50
+---
+
+# Configuration
+
+These pages cover configuration for SQL Studio.
+
+## When to Use This Section
+Configuration pages explain what needs to exist before SQL Studio runs in a new environment, what each value controls, and how to reason about credentials, defaults, deployment settings, and scale controls.
+
+## Available Pages
+- [Environment Variables](/docs/configuration/environment) - Environment variables provide runtime secrets, URLs, provider settings, and deployment values.
+
+## Reading Order
+- Identify which values are required for every run and which are optional overrides.
+- Treat credentials and destructive scale controls as production-sensitive settings.
+- After changing configuration, rerun the smallest workflow that proves the new value is being used.

apps/docs/app/docs/features/dashboard-overview/page.mdx

@@ -0,0 +1,24 @@
+---
+title: "Dashboard Overview"
+description: "Dashboard pages give operators a clear view of users, activity, and system health."
+order: 40
+---
+
+# Dashboard Overview
+
+Dashboard pages give operators a clear view of users, activity, and system health.
+## What You Can Do
+This area gives operators a high-level view of the system before they drill into individual records. It usually brings together counts, recent activity, database state, and health signals so an admin can understand whether the product is working as expected.
+## Key Ideas
+- workspace status
+- operational metrics
+- recent activity
+- dashboard widgets
+## Where You'll See It
+This page starts from the parts of the product a reader can actually recognize.
+
+- The README already calls out related context in **Features**, **Overview Page**.
+## How It Works
+1. Open the dashboard to see the current state of the product.
+2. Use summary widgets to identify the area that needs attention.
+3. Navigate from a widget into the detailed feature page or record list.

apps/docs/app/docs/features/page.mdx

@@ -0,0 +1,20 @@
+---
+title: "Features"
+description: "Product capabilities and workflows readers can use or operate."
+order: 30
+---
+
+# Features
+
+These pages cover features for SQL Studio.
+
+## When to Use This Section
+Feature pages explain the capabilities SQL Studio exposes to users, operators, or application developers. Each page starts with the outcome, then links that behavior to setup and reference details.
+
+## Available Pages
+- [Dashboard Overview](/docs/features/dashboard-overview) - Dashboard pages give operators a clear view of users, activity, and system health.
+
+## Reading Order
+- Start with the page closest to the workflow you are trying to complete.
+- Use setup and configuration pages before running commands in a new environment.
+- Use reference pages when you already know the concept and need exact commands, imports, or options.

apps/docs/app/docs/installation/page.mdx

@@ -0,0 +1,28 @@
+---
+title: "Installation"
+description: "Install and configure SQL Studio."
+order: 20
+---
+
+# Installation
+
+This page explains how to get SQL Studio into a runnable state. It separates the setup model from command lists so readers understand what each step is preparing.
+## Setup Model
+Installation has two jobs: install the package dependencies and verify the command or package entrypoint that exercises the main workflow.
+## What Gets Configured
+- Dependencies provide the framework, CLI, adapters, and runtime libraries used by the project.
+- Scripts provide repeatable entrypoints for local development, production builds, tests, and release tasks.
+## Successful Setup Looks Like
+- Dependencies install with the package manager already used by the project.
+- The primary command starts, builds, or verifies the project without needing undocumented manual steps.
+## Install Dependencies
+Run `cargo build` from the project root.
+## Review Runtime Configuration
+Review the project files and scripts before running the project.
+No reader-facing environment contract was found in README or example environment files.
+## Verify the Build or Runtime Command
+No primary runtime command was found, so review the current package scripts before running the project.
+## Framework and Adapter Coverage
+- Next.js
+## Useful Commands
+No package scripts were found for setup workflows.

apps/docs/app/docs/page.mdx

@@ -0,0 +1,44 @@
+---
+title: "SQL Studio"
+description: "Overview for SQL Studio."
+order: 0
+---
+
+# SQL Studio
+
+Single binary, single command SQL database explorer. SQL studio supports SQLite , libSQL , PostgreSQL , MySQL , DuckDB , ClickHouse , Microsoft SQL Server , Parquet and CSV .
+## Product Story
+SQL Studio is documented as a product with capabilities, workflows, configuration decisions, and integration surfaces. These pages are organized so a reader can understand the purpose of the project before they need to inspect source files.
+## Reader Paths
+- Start with the overview, quickstart, and installation pages to understand the product before moving into deeper setup details.
+- Use feature pages to understand product capabilities surfaced by the README, routes, UI, or domain files.
+- Use configuration pages for runtime settings, environment files, deployment files, database files, or product config.
+- Use API reference pages after the mental model is clear and you need routes, commands, adapters, exports, or type contracts.
+## How These Docs Help
+Each page starts with the reader's goal, then moves into the workflow, configuration, and verification details needed to use or operate the project. File paths and exports are supporting context, not the main explanation.
+## Documentation Map
+- Get Started: [SQL Studio](/docs) - Overview for SQL Studio.
+- Get Started: [Quickstart](/docs/quickstart) - Run SQL Studio for the first time.
+- Get Started: [Installation](/docs/installation) - Install and configure SQL Studio.
+- Core Features: [Features](/docs/features) - Product capabilities and workflows readers can use or operate.
+- Core Features: [Dashboard Overview](/docs/features/dashboard-overview) - Dashboard pages give operators a clear view of users, activity, and system health.
+- Configuration: [Configuration](/docs/configuration) - Runtime values, environment variables, deployment settings, and framework configuration.
+- Configuration: [Environment Variables](/docs/configuration/environment) - Environment variables provide runtime secrets, URLs, provider settings, and deployment values.
+- API Reference: [API Reference](/docs/api) - Concrete developer-facing surfaces: commands, exports, adapters, routes, and type contracts.
+- API Reference: [API Routes](/docs/api/routes) - API routes explain how requests enter the application and reach runtime behavior.
+- Architecture: [Architecture](/docs/architecture) - How major subsystems, runtime surfaces, and workflow boundaries fit together.
+- Backend: [Backend](/docs/backend) - Server-side systems, request handling, runtime behavior, and data-facing workflows.
+- Build: [Build](/docs/build) - Build pipeline, package structure, scripts, and delivery surfaces for the repository.
+- Architecture: [Architecture Overview](/docs/architecture/overview) - The architecture page explains the repository as a set of real subsystems so readers can orient themselves before diving into commands, exports, or implementation files.
+- Backend: [Core Backend Systems](/docs/backend/systems) - The backend page explains request handling, runtime configuration, data-facing services, and the server-side workflow behind the product.
+- Build: [Build System and Package Structure](/docs/build/package-structure) - The build page explains how the repository is packaged, built, exported, and prepared for local development or distribution.
+## At A Glance
+- Runtime and adapter coverage: Next.js
+## Core Capabilities
+- Dashboard Overview: This area gives operators a high-level view of the system before they drill into individual records. It usually brings together counts, recent activity, database state, and health signals so an admin can understand whether the product is working as expected. Key concepts: workspace status, operational metrics, recent activity, dashboard widgets.
+## Runtime and Adapter Coverage
+- Next.js
+## Common Commands
+No package scripts were found for common workflows.
+## Configuration You May Need
+No reader-facing environment contract was found in README or example environment files.