@bonnard/cli 0.2.4 → 0.2.6

package/dist/docs/topics/cli.validate.md

@@ -0,0 +1,125 @@
+# Validate
+
+> Run validation checks on your cubes and views before deploying to catch YAML syntax errors, missing references, circular joins, and other issues. Use `bon validate` from the CLI.
+
+## Overview
+
+The `bon validate` command checks your YAML cubes and views for syntax errors and schema violations. Run this before deploying to catch issues early.
+
+## Usage
+
+```bash
+bon validate
+```
+
+## What Gets Validated
+
+### YAML Syntax
+
+- Valid YAML format
+- Proper indentation
+- Correct quoting
+
+### Schema Compliance
+
+- Required fields present (name, type, sql)
+- Valid field values (known measure types, relationship types)
+- Consistent naming conventions
+
+### Reference Integrity
+
+- Referenced cubes exist
+- Referenced members exist
+- Join relationships are valid
+
+## Example Output
+
+### Success
+
+```
+✓ Validating YAML syntax...
+✓ Checking bonnard/cubes/orders.yaml
+✓ Checking bonnard/cubes/users.yaml
+✓ Checking bonnard/views/orders_overview.yaml
+
+All cubes and views valid.
+```
+
+### Errors
+
+```
+✗ Validating YAML syntax...
+
+bonnard/cubes/orders.yaml:15:5
+  error: Unknown measure type "counts"
+
+  Did you mean "count"?
+
+  14:   measures:
+  15:     - name: order_count
+  16:       type: counts  <-- here
+  17:       sql: id
+
+1 error found.
+```
+
+## Common Errors
+
+### Missing Required Field
+
+```yaml
+# Error: "sql" is required
+measures:
+  - name: count
+    type: count
+    # Missing: sql: id
+```
+
+### Invalid Type
+
+```yaml
+# Error: Unknown dimension type "text"
+dimensions:
+  - name: status
+    type: text    # Should be: string
+    sql: status
+```
+
+### Reference Not Found
+
+```yaml
+# Error: Cube "user" not found (did you mean "users"?)
+joins:
+  - name: user
+    relationship: many_to_one
+    sql: "{CUBE}.user_id = {user.id}"
+```
+
+### YAML Syntax
+
+```yaml
+# Error: Bad indentation
+measures:
+- name: count  # Should be indented
+  type: count
+```
+
+## Exit Codes
+
+| Code | Meaning |
+|------|---------|
+| 0 | All validations passed |
+| 1 | Validation errors found |
+
+## Best Practices
+
+1. **Run before every deploy** — `bon validate && bon deploy`
+2. **Add to CI/CD** — validate on pull requests
+3. **Fix errors first** — don't deploy with validation errors
+4. **Test connections** — connections are tested automatically during `bon deploy`
+
+## See Also
+
+- cli
+- cli.deploy
+- syntax

package/dist/docs/topics/cubes.data-source.md

@@ -89,4 +89,4 @@ Cubes from different data sources cannot be directly joined. Use views or pre-ag
 
 - cubes
 - cubes.sql
-- workflow.deploy
+- cli.deploy

package/dist/docs/topics/features.governance.md

@@ -1,84 +1,83 @@
 # Governance
 
-> User and group-level permissions for your semantic layer.
+> Control who can see which views, columns, and rows in your semantic layer.
 
-Bonnard supports declarative data access policies — define who can see which rows, columns, and views directly in your YAML models. No application code, no database-level workarounds.
+Bonnard provides admin-managed data governance — control which views, columns, and rows each group of users can access. Policies are configured in the web UI and enforced automatically across MCP queries and the API. Changes take effect within one minute.
 
-## Row-level security
+## How It Works
 
-Filter data based on user attributes. A sales manager only sees their region's data:
+```
+Admin configures in web UI:
+  Groups → Views → Field/Row restrictions
 
-```yaml
-cubes:
-  - name: orders
-    access_policy:
-      - role: sales_manager
-        row_level:
-          filters:
-            - member: region
-              operator: equals
-              values: ["{ securityContext.region }"]
+Enforced automatically:
+  MCP queries + API → only see what policies allow
 ```
 
-Every query from that user automatically includes the filter — no way to bypass it.
+Governance uses **groups** as the unit of access. Each group has a set of **policies** that define which views its members can see, and optionally restrict specific columns or rows within those views.
 
-## Member-level security
+## Groups
 
-Control which measures and dimensions each role can access. Hide sensitive fields from non-privileged users:
+Groups represent teams or roles in your organization — "Sales Team", "Finance", "Executive". Create and manage groups from the **Governance** page in the Bonnard dashboard.
 
-```yaml
-cubes:
-  - name: orders
-    access_policy:
-      - role: analyst
-        member_level:
-          includes:
-            - count
-            - total_revenue
-            - status
-            - created_at
+Each group has:
+- **Name** and optional description
+- **Color** for visual identification
+- **View access** — which views the group can query
+- **Members** — which users belong to the group
 
-      - role: admin
-        member_level:
-          includes: "*"
-```
+Users can belong to multiple groups. Their effective access is the **union** of all group policies.
 
-Roles without a matching policy see nothing.
+## View-Level Access (Level 1)
 
-## View-based governance
+The simplest control: toggle which views a group can see. Unchecked views are completely invisible to group members — they won't appear in `explore_schema` or be queryable.
 
-Keep cubes private. Expose only curated views to consumers:
+From the group detail page, check the views you want to grant access to and click **Save changes**. New policies default to "All fields" with no row filters.
 
-```yaml
-cubes:
-  - name: raw_orders
-    public: false
+## Field-Level Access (Level 2)
 
-views:
-  - name: sales_overview
-    public: true
-    cubes:
-      - join_path: raw_orders
-        includes:
-          - revenue
-          - order_count
-          - status
-```
+Fine-tune which measures and dimensions a group can see within a view. Click the gear icon on any granted view to open the fine-tune dialog.
 
-Business users, AI agents, and SDK consumers only see the views you choose to expose — with clean names and descriptions.
+Three modes:
+- **All fields** — full access to every measure and dimension (default)
+- **Only these** — whitelist specific fields; everything else is hidden
+- **All except** — blacklist specific fields; everything else is visible
 
-## Dynamic visibility
+Hidden fields are removed from the schema — they don't appear in `explore_schema` and can't be used in queries.
 
-Use context variables to show or hide entire cubes based on the user's role:
+## Row-Level Filters (Level 2)
 
-```yaml
-cubes:
-  - name: executive_metrics
-    public: "{{ 'true' if COMPILE_CONTEXT.role == 'executive' else 'false' }}"
-```
+Restrict which rows a group can see. Add row filters in the fine-tune dialog to limit data by dimension values.
+
+For example, filter `traffic_source` to `equals B2B, Organic` so the group only sees rows where traffic_source is B2B or Organic. Multiple values in a single filter are OR'd (any match). Multiple separate filters are AND'd (all must match).
+
+Row filters are applied server-side on every query — users cannot bypass them.
+
+## Members
+
+Assign users to groups from the **Members** tab. Each user shows which groups they belong to and a preview of their effective access (which views they can query, any field or row restrictions).
+
+Users without any group assignment see nothing — they must be added to at least one group to query governed views.
+
+## How Policies Are Enforced
+
+Policies configured in the web UI are stored in Supabase and injected into the query engine at runtime. When a user queries via MCP or the API:
+
+1. Their JWT is enriched with group memberships
+2. The query engine loads policies for those groups
+3. View visibility, field restrictions, and row filters are applied automatically
+4. The user only sees data their policies allow
+
+No YAML changes are needed — governance is fully managed through the dashboard.
+
+## Best Practices
+
+1. **Start with broad access, then restrict** — give groups all views first, then fine-tune as needed
+2. **Use groups for teams, not individuals** — easier to manage and audit
+3. **Test with MCP** — after changing policies, query via MCP to verify the restrictions work as expected
+4. **Review after schema deploys** — new views need to be added to group policies to become visible
 
 ## See Also
 
-- [cubes.public](cubes.public) — Visibility controls reference
+- [features.mcp](features.mcp) — How AI agents query your semantic layer
 - [views](views) — Creating curated data views
-- [syntax.context-variables](syntax.context-variables) — Context variable reference

package/dist/docs/topics/features.semantic-layer.md

@@ -9,6 +9,7 @@ Bonnard hosts your semantic layer so you don't have to. Define cubes and views i
 Connect any combination of warehouses through a single semantic layer:
 
 - **PostgreSQL** — Direct TCP connection
+- **Redshift** — Cluster or serverless endpoint
 - **Snowflake** — Account-based authentication
 - **BigQuery** — GCP service account
 - **Databricks** — Token-based workspace connection
@@ -43,8 +44,13 @@ Your models are stored securely and served from Bonnard's infrastructure. Each o
 
 Deploy in seconds. Query in milliseconds.
 
+## Built for AI agents
+
+Views and descriptions are the discovery API for AI agents. When an agent calls `explore_schema`, it sees view names and descriptions — that's all it has to decide where to query. Well-written descriptions with scope, disambiguation, and dimension values make agents accurate. See the design guide principles in the CLI (`/bonnard-design-guide`) for details.
+
 ## See Also
 
 - [workflow.query](workflow.query) — Query format reference
 - [cubes](cubes) — Cube modeling guide
 - [views](views) — View modeling guide
+- [features.governance](features.governance) — Access control for views and data

package/dist/docs/topics/getting-started.md

@@ -12,5 +12,5 @@ Bonnard is a semantic layer platform that sits between your data warehouse and y
 
 - Learn about [cubes](/docs/modeling/cubes) — measures, dimensions, joins
 - Learn about [views](/docs/modeling/views) — curated interfaces for consumers
-- Set up [MCP](/docs/workflow/mcp) — connect AI agents to your semantic layer
-- Read the full [workflow guide](/docs/workflow) — validate, deploy, query
+- Set up [MCP](/docs/querying/mcp) — connect AI agents to your semantic layer
+- Read the [CLI guide](/docs/cli) — validate, deploy, query

package/dist/docs/topics/governance.md

@@ -0,0 +1,83 @@
+# Governance
+
+> Control who can see which views, columns, and rows in your semantic layer.
+
+Bonnard provides admin-managed data governance — control which views, columns, and rows each group of users can access. Policies are configured in the web UI and enforced automatically across MCP queries and the API. Changes take effect within one minute.
+
+## How It Works
+
+```
+Admin configures in web UI:
+  Groups → Views → Field/Row restrictions
+
+Enforced automatically:
+  MCP queries + API → only see what policies allow
+```
+
+Governance uses **groups** as the unit of access. Each group has a set of **policies** that define which views its members can see, and optionally restrict specific columns or rows within those views.
+
+## Groups
+
+Groups represent teams or roles in your organization — "Sales Team", "Finance", "Executive". Create and manage groups from the **Governance** page in the Bonnard dashboard.
+
+Each group has:
+- **Name** and optional description
+- **Color** for visual identification
+- **View access** — which views the group can query
+- **Members** — which users belong to the group
+
+Users can belong to multiple groups. Their effective access is the **union** of all group policies.
+
+## View-Level Access (Level 1)
+
+The simplest control: toggle which views a group can see. Unchecked views are completely invisible to group members — they won't appear in `explore_schema` or be queryable.
+
+From the group detail page, check the views you want to grant access to and click **Save changes**. New policies default to "All fields" with no row filters.
+
+## Field-Level Access (Level 2)
+
+Fine-tune which measures and dimensions a group can see within a view. Click the gear icon on any granted view to open the fine-tune dialog.
+
+Three modes:
+- **All fields** — full access to every measure and dimension (default)
+- **Only these** — whitelist specific fields; everything else is hidden
+- **All except** — blacklist specific fields; everything else is visible
+
+Hidden fields are removed from the schema — they don't appear in `explore_schema` and can't be used in queries.
+
+## Row-Level Filters (Level 2)
+
+Restrict which rows a group can see. Add row filters in the fine-tune dialog to limit data by dimension values.
+
+For example, filter `traffic_source` to `equals B2B, Organic` so the group only sees rows where traffic_source is B2B or Organic. Multiple values in a single filter are OR'd (any match). Multiple separate filters are AND'd (all must match).
+
+Row filters are applied server-side on every query — users cannot bypass them.
+
+## Members
+
+Assign users to groups from the **Members** tab. Each user shows which groups they belong to and a preview of their effective access (which views they can query, any field or row restrictions).
+
+Users without any group assignment see nothing — they must be added to at least one group to query governed views.
+
+## How Policies Are Enforced
+
+Policies configured in the web UI are stored in Supabase and injected into the query engine at runtime. When a user queries via MCP or the API:
+
+1. Their JWT is enriched with group memberships
+2. The query engine loads policies for those groups
+3. View visibility, field restrictions, and row filters are applied automatically
+4. The user only sees data their policies allow
+
+No YAML changes are needed — governance is fully managed through the dashboard.
+
+## Best Practices
+
+1. **Start with broad access, then restrict** — give groups all views first, then fine-tune as needed
+2. **Use groups for teams, not individuals** — easier to manage and audit
+3. **Test with MCP** — after changing policies, query via MCP to verify the restrictions work as expected
+4. **Review after schema deploys** — new views need to be added to group policies to become visible
+
+## See Also
+
+- [querying.mcp](querying.mcp) — How AI agents query your semantic layer
+- [views](views) — Creating curated data views

package/dist/docs/topics/overview.md

@@ -0,0 +1,49 @@
+# Overview
+
+> Define your metrics once. Query governed data from any AI tool, dashboard, or application.
+
+Bonnard is a semantic layer platform. Your data team defines metrics once, and everyone else gets reliable answers from the AI tools they already use — Claude, ChatGPT, Cursor, Copilot — in whatever form they need. No new interface to learn.
+
+## Architecture
+
+```
+Data Warehouse → Cubes (metrics) → Views (interfaces) → Query Surfaces
+                                                          ├── MCP (AI agents)
+                                                          ├── REST API
+                                                          └── SDK (custom apps)
+```
+
+**Cubes** map to your database tables and define measures (revenue, count) and dimensions (status, date). **Views** compose cubes into focused interfaces for specific teams or use cases. Once deployed, your semantic layer is queryable through MCP, REST API, or the TypeScript SDK.
+
+## Multi-warehouse
+
+Connect any combination of warehouses through a single semantic layer:
+
+- **PostgreSQL** — Direct TCP connection
+- **Redshift** — Cluster or serverless endpoint
+- **Snowflake** — Account-based authentication
+- **BigQuery** — GCP service account
+- **Databricks** — Token-based workspace connection
+
+Metrics from different warehouses are queried through the same API. Your consumers never need to know where the data lives.
+
+## One source of truth for every AI
+
+Bonnard exposes your semantic layer as a remote MCP server. Add one URL to any MCP-compatible client — Claude, ChatGPT, Cursor, VS Code, Windsurf, Gemini — and it can explore your data model, run queries, and render charts. Every query is governed and scoped to the user's permissions automatically.
+
+## Governed by default
+
+Metrics are version-controlled and deployed from the terminal. Access, roles, and row-level security are managed by admins from the dashboard. Every query — whether from an AI agent, the API, or the SDK — is scoped to the user's permissions. No ungoverned access.
+
+## Your data stays where it is
+
+Your data stays in your warehouse. Bonnard adds a governed semantic layer on top — hosted, queryable, and managed. Each organization gets isolated query execution. Deploy from your terminal in minutes, not quarters.
+
+## Where to go next
+
+- **[Getting Started](/docs/getting-started)** — Install the CLI and build your first semantic layer
+- **[Modeling](/docs/modeling)** — Define cubes, views, and pre-aggregations
+- **[Querying](/docs/querying)** — Query via MCP, REST API, or SDK
+- **[CLI](/docs/cli)** — Commands, deployment, and validation
+- **[Governance](/docs/governance)** — Control access to views, columns, and rows
+- **[Catalog](/docs/catalog)** — Browse your data model in the browser

package/dist/docs/topics/querying.mcp.md

@@ -0,0 +1,200 @@
+# MCP
+
+> Connect AI agents like Claude, ChatGPT, and Cursor to your semantic layer using the Model Context Protocol. One URL, governed access to your metrics and dimensions.
+
+Bonnard exposes your semantic layer as a remote MCP server. Add one URL to your agent platform and it can explore your data model, run queries, and render charts — all through the Model Context Protocol.
+
+![MCP chat with visualisations](/images/mcp-chat-demo.gif)
+
+## MCP URL
+
+```
+https://mcp.bonnard.dev/mcp
+```
+
+On first use, your browser opens to sign in — the agent receives a 30-day token automatically. No API keys, no config files, no secrets to rotate.
+
+## Connect your agent
+
+Bonnard works with any MCP-compatible client:
+
+- **Claude Desktop** — Add as a custom connector
+- **ChatGPT** — Add via Settings > Apps (Pro/Plus)
+- **Cursor** — Add via Settings > MCP or `.cursor/mcp.json`
+- **Microsoft Copilot Studio** — Add as an MCP tool with OAuth 2.0 authentication
+- **VS Code / GitHub Copilot** — Add via Command Palette or `.vscode/mcp.json`
+- **Claude Code** — Add via `claude mcp add` or `.mcp.json`
+- **Windsurf** — Add via MCP config
+- **Gemini CLI** — Add via `.gemini/settings.json`
+
+## Setup
+
+### Claude Desktop
+
+1. Click the **+** button in the chat input, then select **Connectors > Manage connectors**
+
+![Claude Desktop — Connectors menu in chat](/images/claude-chat-connectors.png)
+
+2. Click **Add custom connector**
+3. Enter a name (e.g. "Bonnard MCP") and the MCP URL: `https://mcp.bonnard.dev/mcp`
+4. Click **Add**
+
+![Claude Desktop — Add custom connector dialog](/images/claude-add-connector.png)
+
+Once added, enable the Bonnard connector in any chat via the **Connectors** menu.
+
+Remote MCP servers in Claude Desktop must be added through the Connectors UI, not the JSON config file.
+
+### ChatGPT
+
+Custom MCP servers must be added in the browser at [chatgpt.com](https://chatgpt.com) — the desktop app does not support this.
+
+1. Go to [chatgpt.com](https://chatgpt.com) in your browser
+2. Open **Settings > Apps**
+
+![ChatGPT — Settings > Apps](/images/chatgpt-apps.png)
+
+3. Click **Advanced settings**, enable **Developer mode**, then click **Create app**
+
+![ChatGPT — Advanced settings with Developer mode and Create app](/images/advanced-create-app-chatgpt.png)
+
+4. Enter a name (e.g. "Bonnard MCP"), the MCP URL `https://mcp.bonnard.dev/mcp`, and select **OAuth** for authentication
+5. Check the acknowledgement box and click **Create**
+
+![ChatGPT — Create new app with MCP URL](/images/chatgpt-new-app.png)
+
+Once created, the Bonnard connector appears under **Enabled apps**:
+
+![ChatGPT — Bonnard MCP available in chat](/images/chatgpt-chat-apps.png)
+
+Available on Pro and Plus plans.
+
+### Cursor
+
+Open **Settings > MCP** and add the server URL, or add to `.cursor/mcp.json` in your project:
+
+```json
+{
+  "mcpServers": {
+    "bonnard": {
+      "url": "https://mcp.bonnard.dev/mcp"
+    }
+  }
+}
+```
+
+On first use, your browser will open to sign in and authorize the connection.
+
+### VS Code / GitHub Copilot
+
+Open the Command Palette and run **MCP: Add Server**, or add to `.vscode/mcp.json` in your project:
+
+```json
+{
+  "servers": {
+    "bonnard": {
+      "type": "http",
+      "url": "https://mcp.bonnard.dev/mcp"
+    }
+  }
+}
+```
+
+On first use, your browser will open to sign in and authorize the connection.
+
+### Claude Code
+
+Run in your terminal:
+
+```bash
+claude mcp add --transport http bonnard https://mcp.bonnard.dev/mcp
+```
+
+Or add to `.mcp.json` in your project:
+
+```json
+{
+  "mcpServers": {
+    "bonnard": {
+      "type": "http",
+      "url": "https://mcp.bonnard.dev/mcp"
+    }
+  }
+}
+```
+
+### Windsurf
+
+Open **Settings > Plugins > Manage plugins > View raw config**, or edit `~/.codeium/windsurf/mcp_config.json`:
+
+```json
+{
+  "mcpServers": {
+    "bonnard": {
+      "serverUrl": "https://mcp.bonnard.dev/mcp"
+    }
+  }
+}
+```
+
+### Gemini CLI
+
+Add to `.gemini/settings.json` in your project or `~/.gemini/settings.json` globally:
+
+```json
+{
+  "mcpServers": {
+    "bonnard": {
+      "url": "https://mcp.bonnard.dev/mcp"
+    }
+  }
+}
+```
+
+## Authentication
+
+MCP uses OAuth 2.0 with PKCE. When an agent first connects:
+
+1. Agent discovers OAuth endpoints automatically
+2. You are redirected to Bonnard to sign in and authorize
+3. Agent receives an access token (valid for 30 days)
+
+No API keys or manual token management needed.
+
+## Available Tools
+
+Once connected, AI agents can use these MCP tools:
+
+| Tool | Description |
+|------|-------------|
+| `explore_schema` | Discover views and cubes, list their measures, dimensions, and segments. Supports browsing a specific source by name or searching across all fields by keyword. |
+| `query` | Query the semantic layer with measures, dimensions, time dimensions, filters, segments, and pagination. |
+| `sql_query` | Execute raw SQL against the semantic layer using Cube SQL syntax with `MEASURE()` for aggregations. Use for CTEs, UNIONs, and custom calculations. |
+| `describe_field` | Get detailed metadata for a field — SQL expression, type, format, origin cube, and referenced fields. |
+| `visualize` | Render line, bar, pie, and KPI charts directly inside the conversation. |
+
+## Charts in chat
+
+The `visualize` tool renders interactive charts inline — auto-detected from your query shape. Charts support dark mode, currency and percentage formatting, and multi-series data.
+
+Ask "show me revenue by region this quarter" and get a formatted chart in your conversation, not a data dump.
+
+## Testing
+
+```bash
+# Verify the MCP server is reachable
+bon mcp test
+
+# View connection info
+bon mcp
+```
+
+## Managing Connections
+
+Active MCP connections can be viewed and revoked in the Bonnard dashboard under **MCP**.
+
+## See Also
+
+- [querying.rest-api](querying.rest-api) — Query format reference
+- [querying.sdk](querying.sdk) — TypeScript SDK for custom apps
+- [cli.deploy](cli.deploy) — Deploy before querying

package/dist/docs/topics/querying.md

@@ -0,0 +1,11 @@
+# Querying
+
+> Once deployed, query your semantic layer three ways: MCP for AI agents, REST API for structured queries, and SDK for custom applications.
+
+Once your semantic layer is deployed, it's queryable through three interfaces:
+
+- **[MCP](querying.mcp)** — Connect AI agents like Claude, ChatGPT, and Cursor to explore and query your data model through the Model Context Protocol
+- **[REST API](querying.rest-api)** — Send JSON query objects or SQL strings for structured, programmatic access
+- **[SDK](querying.sdk)** — Build custom dashboards, embedded analytics, and data pipelines with the TypeScript client
+
+All three interfaces query the same governed semantic layer — same metrics, same access controls, same results.