@docyrus/docyrus 0.0.19 → 0.0.20

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@docyrus/docyrus",
-  "version": "0.0.19",
+  "version": "0.0.20",
   "private": false,
   "description": "Docyrus API CLI",
   "main": "./main.js",
@@ -9,8 +9,8 @@
   },
   "dependencies": {
     "@clack/prompts": "^0.11.0",
-    "@mariozechner/pi-ai": "0.60.0",
-    "@mariozechner/pi-coding-agent": "0.60.0",
+    "@mariozechner/pi-ai": "0.61.0",
+    "@mariozechner/pi-coding-agent": "0.61.0",
     "@opentui/core": "^0.1.85",
     "@opentui/react": "^0.1.85",
     "incur": "^0.1.6",

package/resources/pi-agent/prompts/coder-system.md

@@ -0,0 +1,106 @@
+You are the Docyrus coding agent running inside the local `docyrus` CLI and the current working directory.
+
+Your primary domain is Docyrus application development. Unless the user clearly asks about something else, assume the task is about building or modifying a Docyrus-backed app, mobile client, schema, query, integration, or local codebase that works with the Docyrus platform.
+
+You are responsible for both code work and Docyrus platform verification.
+
+Primary build target:
+
+- Default to client-rendered React TypeScript SPA web apps and React Native mobile apps.
+- Default to Docyrus as the backend for auth, data, schema, and API access.
+- For frontend auth, prefer `@docyrus/signin`.
+- For frontend and service-layer API access, prefer `@docyrus/api-client`.
+- If the repo already has generated Docyrus collection hooks, prefer those over hand-written endpoint wrappers.
+- If a custom backend is required, prefer a thin backend with TanStack Start or Hono that serves the SPA/mobile app and integrates with Docyrus APIs.
+- Do not default to SSR app architecture unless the user explicitly asks for SSR or clearly requires it.
+
+Core behavior:
+
+- Use repository files and coding tools for implementation work.
+- Use the local `docyrus` CLI for Docyrus platform state, tenant context, schema inspection, app and data-source operations, API discovery, and data verification.
+- Prefer `--json` whenever command output needs to be parsed, compared, or fed back into reasoning.
+- Start from real state before making claims about apps, data sources, users, fields, enums, environments, auth state, API shape, or deployment context.
+- Distinguish clearly between local code changes and remote Docyrus platform mutations.
+- Avoid guessing undocumented HTTP endpoints when `docyrus discover`, generated collections, or `@docyrus/api-client` can answer the question or perform the mutation safely.
+- Treat `.docyrus`, tokens, auth files, session files, generated env-backed provider settings, and runtime settings as sensitive.
+- When platform capability is uncertain, verify against the active tenant context, the local CLI, and the discovered OpenAPI spec before making claims.
+
+Docyrus platform model you should understand and use accurately:
+
+- apps as top-level containers for product surface area
+- data sources as the main structured backend building block
+- fields as schema definitions for data sources, including relations and select-style fields
+- enumerations for select, multi-select, status, and tag-like options
+- records as the runtime data inside data sources
+- custom queries for analytics or specialized backend querying
+- user and tenant auth context
+- discover commands and tenant OpenAPI inspection
+- raw API access through the CLI when needed
+
+Docyrus backend and API capability summary:
+
+- Data sources can represent internal tables, advanced structured tables, external connected resources, or system-provided resources, but they are consumed through a unified CRUD and query model.
+- Data source schemas can include text, numeric, date/time, boolean, relation, user, enum, file, nested JSON-like, and computed field types.
+- Querying supports column selection, aliases, relation expansion, spread syntax, filtering, sorting, pagination, keyword search, aggregations, formulas, pivots, child queries, and full-count responses.
+- Formula design can include inline block expressions and correlated child subqueries.
+- Tenant-specific OpenAPI specs describe the currently available backend API surface and must be treated as the source of truth for dynamic endpoints.
+- The CLI, `@docyrus/api-client`, `@docyrus/signin`, and generated collection hooks are first-class developer tools for building against the platform.
+- Automations, AI agents, and other higher-level platform features may exist, but do not assume CRUD or developer workflows are available unless the current CLI, OpenAPI spec, or local code confirms them.
+
+Implementation defaults for Docyrus-backed frontend work:
+
+- In React web apps, prefer `DocyrusAuthProvider`, `useDocyrusAuth`, `useDocyrusClient`, and `SignInButton` from `@docyrus/signin`.
+- In React and React Native clients, prefer authenticated API calls through `@docyrus/api-client` or generated collection hooks instead of ad hoc fetch wrappers.
+- Prefer TanStack Query style query and mutation patterns around collection hooks or `RestApiClient` calls when the surrounding codebase uses them.
+- Always send `columns` in Docyrus list and get calls. Without `columns`, many list and get responses are incomplete or reduced to identifiers.
+- If a query uses `formulas`, include the formula keys in `columns`.
+- If a query uses `childQueries`, include the child query keys in `columns`.
+- Use `id` for count-style calculations and real field slugs for sum, avg, min, and max calculations.
+- Prefer relation expansion or spread syntax when building UI-facing queries so the frontend gets directly usable shapes.
+- Do not hand-wave enum IDs, field slugs, relation names, or endpoint shapes. Inspect them first.
+
+Schema-first workflow for new Docyrus-backed apps and major features:
+
+- Inspect the current app, data sources, fields, enums, and tenant auth context before implementing UI.
+- If the required backend schema does not exist yet, use `docyrus studio` commands to create or update data sources, fields, relations, and enums before wiring the frontend.
+- Prefer `docyrus studio` over manual backend guessing when provisioning app schema.
+- After schema changes, verify the resulting metadata and runtime behavior with `docyrus ds get`, `docyrus ds list`, and `docyrus discover`.
+- When the project uses generated collections or codegen from the OpenAPI spec, resync or regenerate those artifacts after schema changes if the repo workflow requires it.
+
+Docyrus CLI workflows you should rely on:
+
+- Use `docyrus auth who`, `docyrus auth accounts ...`, `docyrus auth tenants ...`, and `docyrus env ...` to confirm active identity, tenant, and environment.
+- Use `docyrus apps list` to inspect available apps.
+- Use `docyrus ds get` to inspect data-source metadata and fields.
+- Use `docyrus ds list` to validate filters, columns, expansions, formulas, calculations, child queries, pivots, and real data responses.
+- Use `docyrus ds create`, `update`, and `delete` for data verification or seeded test data when appropriate.
+- Use `docyrus studio list-data-sources`, `get-data-source`, `create-data-source`, `list-fields`, `create-field`, `update-field`, `create-enums`, and related batch commands for schema work.
+- Use `docyrus discover api`, `namespaces`, `path`, `endpoint`, `entity`, and `search` to inspect the active backend API before implementing client code.
+- Use `docyrus curl` when raw endpoint testing is needed.
+
+Package guidance:
+
+- `@docyrus/signin` is the default choice for Docyrus OAuth2 integration in React apps.
+- `@docyrus/api-client` is the default choice for Docyrus REST access, OAuth2-aware clients, interceptors, streaming, and file operations.
+- If the repo already includes generated Docyrus collection hooks, use them as the highest-level integration layer for CRUD and query operations.
+- When a task can be solved with Docyrus-backed frontend code plus schema changes, do not invent an unnecessary custom backend.
+- When a custom backend really is required, keep it thin and treat Docyrus as an upstream platform dependency rather than rebuilding the same domain model from scratch.
+
+When editing code:
+
+- Inspect the current repository state first.
+- Make precise, minimal changes that match surrounding project patterns.
+- Verify behavior with relevant tests, type checks, builds, or targeted CLI/API validation when possible.
+- Keep the user informed when a step mutates tenant state versus only changing local code.
+
+Authoritative references to read when you need exact syntax or payload details:
+
+- `apps/api-cli/resources/pi-agent/skills/docyrus-platform/references/formula-design-guide-llm.md`
+- `apps/api-cli/resources/pi-agent/skills/docyrus-platform/references/data-source-query-guide.md`
+- `apps/api-cli/resources/pi-agent/skills/docyrus-platform/references/docyrus-cli-usage.md`
+
+Additional Docyrus references that are often useful for implementation details:
+
+- `apps/api-cli/resources/pi-agent/skills/docyrus-platform/SKILL.md`
+
+You are not a generic coding agent first. You are a Docyrus-first coding agent optimized for shipping Docyrus-backed SPA web apps and React Native apps, using the local `docyrus` CLI plus repository code tools to verify real backend state while implementing correct frontend behavior.

package/resources/pi-agent/skills/docyrus-platform/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: docyrus-platform
+description: Comprehensive reference for Docyrus platform capabilities, building blocks, features, and API coverage. Use when the user asks about what Docyrus can do, what features are available, how the platform works, or needs context about platform capabilities to design solutions.
+---
+
+# Docyrus Platform
+
+Docyrus is an AI-native Backend Platform as a Service (BPaaS) that enables businesses to build B2B web apps, mobile apps, client portals, internal tools, AI agents, chatbots, and integrations — without building backend infrastructure from scratch.
+
+## Core Building Blocks
+
+The platform is composed of six core building blocks that work together:
+
+- **Apps** — Top-level containers that group data sources, automations, and custom queries into a deployable unit.
+- **Data Sources** — Structured collections of records with defined schemas. Support simple, advanced, external (connected databases/APIs), and system (pre-built) types. Every data source — internal or external — is exposed through a single, unified CRUD endpoint.
+- **Fields** — 45+ field types that define the schema of each data source, covering text, numbers, dates, selections, relations, files, formulas, nested data, and more.
+- **Enumerations** — Reusable option sets for selection fields, with color, icon, and ordering support.
+- **Custom Queries** — SQL-based analytics templates with dynamic variable interpolation, runtime filters, and multi-database targeting.
+- **Automations** — Event-driven workflows with triggers (record changes, time-based, webhooks, buttons) and action chains (email, notifications, HTTP requests, AI prompts, record operations).
+
+For detailed specifications of each building block, see [references/core-building-blocks.md](references/core-building-blocks.md).
+
+## Key Feature Areas
+
+### Querying & Data Operations
+
+Unified query engine with column selection, 50+ filter operators, aggregations, formulas, pivots, child queries, and full-text search. Full CRUD with bulk operations.
+
+See [references/querying-and-data-operations.md](references/querying-and-data-operations.md).
+
+For complete query payload reference with examples, see [references/data-source-query-guide.md](references/data-source-query-guide.md).
+
+For block formula design (inline expressions and subqueries), see [references/formula-design-guide-llm.md](references/formula-design-guide-llm.md).
+
+### AI Capabilities
+
+AI agent builder with tool binding, knowledge bases, MCP servers, 18+ model providers, agent chaining, task scheduling, persistent memory, chat integrations, and evaluation metrics.
+
+See [references/ai-capabilities.md](references/ai-capabilities.md).
+
+### Automation & Workflows
+
+Event-driven automation engine with six trigger types and eleven action types. Supports conditional flows, action chains, and archiving.
+
+See [references/automation-and-workflows.md](references/automation-and-workflows.md).
+
+### Authentication & Multi-Tenancy
+
+OAuth2 flows (PKCE, Client Credentials, Device Code), scope-based permissions, tenant isolation, role-based and record-level ACL, and client portal system.
+
+See [references/auth-and-multi-tenancy.md](references/auth-and-multi-tenancy.md).
+
+### Integrations & Events
+
+Connector framework for HTTP and SQL providers, webhook management, collaborative document editing, in-app messaging, notifications, and email.
+
+See [references/integrations-and-events.md](references/integrations-and-events.md).
+
+### Platform Services
+
+App templates, data import/export, webforms, reporting & analytics, deployment, localization, audit logging, and billing.
+
+See [references/platform-services.md](references/platform-services.md).
+
+### Developer Tools
+
+Auto-generated OpenAPI specs, MCP server, full-featured CLI, REST API client libraries, React auth provider, and auto-generated collection hooks.
+
+See [references/developer-tools.md](references/developer-tools.md).
+
+For full CLI command reference (all commands, options, and flags), see [references/docyrus-cli-usage.md](references/docyrus-cli-usage.md).

package/resources/pi-agent/skills/docyrus-platform/references/ai-capabilities.md

@@ -0,0 +1,43 @@
+# AI Capabilities
+
+## AI Agent Builder
+
+Create and manage AI agents with:
+
+- **Tool binding** — Attach external functions and APIs as agent tools
+- **Data source access** — Grant agents read/write access to specific data sources
+- **Knowledge base** — Upload documents for RAG-powered context
+- **MCP servers** — Connect Model Context Protocol servers for extended tool discovery
+- **Multi-model support** — Choose from 18+ AI providers: OpenAI, Anthropic, Google (AI Studio & Vertex), AWS Bedrock, Groq, Replicate, Together, Mistral, Cohere, Azure, Fireworks, xAI, Portkey, Alibaba, DeepSeek, HuggingFace, OpenRouter, Nebius, Perplexity, Cerebras
+- **Agent connections** — Chain agents as sub-agents or forward requests between agents
+- **Workflow steps** — Define multi-step agent workflows with conditional logic
+
+## AI Task Scheduling
+
+- Immediate, scheduled, and recurring (cron-based) agent task execution
+- Task status tracking and result persistence
+
+## AI Memory
+
+Persistent memory system with scoping levels: user, thread, agent, workspace, and global. Vector embeddings for semantic retrieval.
+
+## AI Chat Integrations
+
+- Microsoft Teams and Google Chat installation and message mapping
+- Thread-level conversation tracking across platforms
+
+## Generative Features
+
+- Content enhancement and completion
+- Design generation (logos, banners)
+- Audio transcription (speech-to-text)
+- Semantic search across records and documents
+- AI-powered data import and field recommendations
+
+## AI Evaluation
+
+17 evaluation metrics including toxicity, hallucination, and faithfulness tracking for agent quality monitoring.
+
+## AI Usage Tracking
+
+Per-model token usage and cost tracking for billing and optimization.

package/resources/pi-agent/skills/docyrus-platform/references/auth-and-multi-tenancy.md

@@ -0,0 +1,35 @@
+# Authentication & Multi-Tenancy
+
+## Authentication Methods
+
+- **OAuth2 Authorization Code (PKCE)** — Browser-based apps
+- **OAuth2 Client Credentials** — Server-to-server
+- **OAuth2 Device Code** — CLI and headless environments
+- **Automatic token refresh** — Transparent renewal with refresh tokens
+
+## Access Control
+
+- **Scope-based permissions** — ReadWrite.All, User.Read, Architect.ReadWrite.All, AI.ReadWrite.All, MCP.Connect, and more
+- **Tenant isolation** — Enforced data separation between tenants on every query
+- **Role-based access** — Roles with granular permission sets
+- **Record-level ACL** — Per-record ownership and sharing rules (private, read-only, read/update, full access)
+- **Field-level ACL** — Restrict visibility or editability of individual fields per role
+
+## User Management
+
+- User signup with email verification, profile management, avatar, preferences
+- Password change/reset, email change workflows
+- Multi-device support with device registration for push notifications
+- Per-user AI feature access control
+
+## Multi-Tenancy
+
+- Fully isolated data per tenant
+- Multiple apps per tenant, each with scoped data sources
+- Tenant-specific configurations, branding, and translations
+- Organizational hierarchy with teams, roles, and user scoping
+
+## Portal System
+
+- Client portal configuration with dedicated portal users, organizations, roles, and sessions
+- Separate authentication and access control for external users

package/resources/pi-agent/skills/docyrus-platform/references/automation-and-workflows.md

@@ -0,0 +1,30 @@
+# Automation & Workflows
+
+## Automation Engine
+
+Define event-driven workflows with triggers and action chains:
+
+**Triggers:**
+
+- Record created, modified, or deleted
+- Time-based (after a period, recurring interval)
+- Webhook (external event)
+- Button activation (user action)
+- Previous action (chaining)
+- AI agent (agent-triggered)
+
+**Actions:**
+
+- Send email
+- Send notification
+- Create record
+- Update records
+- Request input
+- Request approval
+- Trigger HTTP request
+- AI prompt
+- AI agent execution
+- Data source query
+- Custom query execution
+
+Automations support conditional flows, action chains, and soft-delete (archiving).

package/resources/pi-agent/skills/docyrus-platform/references/core-building-blocks.md

@@ -0,0 +1,53 @@
+# Core Building Blocks
+
+## Data Sources
+
+Data sources are the fundamental building block. Each data source represents a structured collection of records with a defined schema. Every data source — whether backed by an internal database table or a connected external REST API — is exposed through a single, unified CRUD endpoint. This means consumers interact with all data sources the same way regardless of where the data lives.
+
+**Types:**
+
+- **Simple** — Schema-flexible records. Quick to set up, ideal for lightweight or rapidly evolving data.
+- **Advanced** — Fully structured data sources with dedicated columns per field. Supports base data sources (shared field inheritance across variants) and high-performance querying.
+- **External** — Connected external REST API resources or databases mapped as data sources. External resources are accessed through the same unified API as internal data sources, abstracting away the underlying connection.
+- **System** — Pre-built templates for common entities: documents, threads, messages, contacts, organizations, activities, tasks, events, calendars, time entries, projects, and sections.
+
+**Ownership models:** App-scoped, tenant-custom, product-provided, system-built-in, or user-specific.
+
+## Fields
+
+Every data source is composed of fields. 45+ field types cover all data modeling needs:
+
+| Category | Field Types |
+|---|---|
+| **Text** | text, textarea, email, phone, URL, color, icon, display |
+| **Rich content** | document editor, HTML editor, email editor, code editor |
+| **Numeric** | number, money, currency, duration, rating, autonumber, identity |
+| **Date & time** | date, dateTime, time, dateRange |
+| **Boolean** | checkbox, switch |
+| **Selection** | select, multiSelect, tagSelect, status, radioGroup |
+| **Users** | userSelect, userMultiSelect |
+| **Relations** | relation (lookup to another data source), list (virtual related records) |
+| **Nested data** | inlineData (nested JSON arrays), inlineForm (nested objects) |
+| **Files** | file, image, fileStorageFolder |
+| **Computed** | formula (JSONata expressions), display (read-only computed) |
+| **Workflow** | approvalStatus, taskList, todo |
+| **Advanced** | json, queryBuilder, dynamic, schema, schemaRepeater, locationSelect |
+| **System** | systemEnum, systemBuffer, systemVector, systemTextArray, systemUuidArray |
+
+## Enumerations
+
+Multi-option fields (select, multiSelect, status, tagSelect) support enumerations with color, icon, and ordering. Enum sets allow sharing option lists across multiple fields.
+
+## Apps
+
+Apps are the top-level container that groups data sources, views, forms, pages, navigation, and configurations into a deployable unit.
+
+**Supported app types:** web, mobile, AI agent, integration, inline (embedded), client portal (web & mobile), Chrome extension, MS Office add-in, MS Outlook add-in, external (white-label), website, and website widget.
+
+**App lifecycle:** draft → design → development → active → inactive, with archiving and permanent deletion.
+
+**Customization layers:** Apps support per-tenant overrides for pages, views, menus, fields, and enums — allowing product apps to be tailored without forking.
+
+## Custom Queries
+
+SQL-based analytics templates with variable interpolation. Support dynamic runtime filters, pagination, and multiple database targets. Built-in variables include tenant context, user identity, and custom filter expressions.

package/resources/pi-agent/skills/{docyrus-api-dev → docyrus-platform}/references/data-source-query-guide.md

@@ -74,7 +74,7 @@ interface ISelectQueryParams {
 
   // --- Aggregation ---
   calculations?: ISelectQueryCalculationRule[] | null;
-  showGroupSummaries?: boolean;
+  groupSummaries?: boolean;
 
   // --- Sorting ---
   orderBy?: string | ISelectQueryOrderBy | ISelectQueryOrderBy[];
@@ -94,7 +94,7 @@ interface ISelectQueryParams {
   cursorDateEnd?: string | null;
 
   // --- Advanced ---
-  childQueries?: Record<string, IQueryChildQueryParams> | null;
+  childQueries?: ISelectQueryChildQueryParams[] | null;
   pivot?: {
     matrix: ISelectPivotMatrixQuery[];
     hideEmptyRows?: boolean;
@@ -700,7 +700,7 @@ Count unique emails:
 }
 ```
 
-### `showGroupSummaries`
+### `groupSummaries`
 
 **Type:** `boolean`
 **Default:** `false`
@@ -837,16 +837,14 @@ Block subquery formulas can also be wrapped under an `expression` key:
 {
   "formulas": {
     "children_count": {
-      "expression": {
-        "from": "app_child_table",
-        "with": "parent_field",
-        "inputs": [{
-          "kind": "aggregate",
-          "name": "count",
-          "distinct": true,
-          "inputs": [{ "kind": "column", "name": "id" }]
-        }]
-      }
+      "from": "app_child_table",
+      "with": "parent_field",
+      "inputs": [{
+        "kind": "aggregate",
+        "name": "count",
+        "distinct": true,
+        "inputs": [{ "kind": "column", "name": "id" }]
+      }]
     }
   }
 }
@@ -1294,14 +1292,15 @@ interface ISelectPivotMatrixQuery {
 
 ## Child Queries
 
-**Parameter:** `childQueries` — `Record<string, IQueryChildQueryParams> | null`
+**Parameter:** `childQueries` — `ISelectQueryChildQueryParams[] | null`
 
 Use `childQueries` to fetch related records from a child data source as a nested JSON array for each parent record. This is similar to a `LEFT JOIN` but returns results as an aggregated JSON array in a single column.
 
 ### Child Query Structure
 
 ```typescript
-interface IQueryChildQueryParams {
+interface ISelectQueryChildQueryParams {
+  alias: string;                    // alias for the child query
   from: string;                    // child data source slug in "appSlug_slug" format
   using: string;                   // field in the child DS that references the parent record
   columns?: string | null;         // comma-separated columns to select from child
@@ -1317,8 +1316,9 @@ interface IQueryChildQueryParams {
 ```json
 {
   "columns": "id, name, matters",
-  "childQueries": {
-    "matters": {
+  "childQueries": [
+    {
+      "alias": "matters",
       "from": "attornaid_matter",
       "using": "client",
       "columns": "name",
@@ -1328,7 +1328,7 @@ interface IQueryChildQueryParams {
         ]
       }
     }
-  }
+  ]
 }
 ```
 
@@ -1359,8 +1359,9 @@ interface IQueryChildQueryParams {
 ```json
 {
   "columns": "id, product_name, recent_orders",
-  "childQueries": {
-    "recent_orders": {
+  "childQueries": [
+    {
+      "alias": "recent_orders",
       "from": "shop_order_item",
       "using": "product",
       "columns": "order_date, quantity, total_price",
@@ -1372,7 +1373,7 @@ interface IQueryChildQueryParams {
         ]
       }
     }
-  }
+  ]
 }
 ```
 
@@ -1381,8 +1382,9 @@ interface IQueryChildQueryParams {
 ```json
 {
   "columns": "id, name, order_stats",
-  "childQueries": {
-    "order_stats": {
+  "childQueries": [
+    {
+      "alias": "order_stats",
       "from": "shop_order",
       "using": "customer",
       "calculations": [
@@ -1390,7 +1392,7 @@ interface IQueryChildQueryParams {
         { "field": "amount", "func": "sum", "name": "total_spent" }
       ]
     }
-  }
+  ]
 }
 ```
 
@@ -1769,8 +1771,9 @@ Monthly sales report grouped by category:
 {
   "dataSourceFullSlug": "crm_customer",
   "columns": "id, name, email, recent_orders, open_tickets",
-  "childQueries": {
-    "recent_orders": {
+  "childQueries": [
+    {
+      "alias": "recent_orders",
       "from": "shop_order",
       "using": "customer",
       "columns": "id, order_date, total_amount, ...status(status_label:name)",
@@ -1782,7 +1785,8 @@ Monthly sales report grouped by category:
         ]
       }
     },
-    "open_tickets": {
+    {
+      "alias": "open_tickets",
       "from": "support_ticket",
       "using": "customer",
       "columns": "id, subject, priority, created_on",
@@ -1794,7 +1798,7 @@ Monthly sales report grouped by category:
         ]
       }
     }
-  },
+  ],
   "filters": {
     "rules": [
       { "field": "status", "operator": "=", "value": "active" }

package/resources/pi-agent/skills/docyrus-platform/references/developer-tools.md

@@ -0,0 +1,28 @@
+# Developer Tools
+
+## OpenAPI Specification
+
+- Auto-generated, tenant-specific OpenAPI specs reflecting all configured data sources and fields
+- Regeneratable on-demand after schema changes
+- Powers client SDK generation and API discovery
+
+## MCP Server (Model Context Protocol)
+
+- Built-in MCP server exposing platform capabilities as AI-consumable tools
+- Discovery, CRUD, querying, enum management, custom query execution, and JSONata evaluation — all accessible via MCP transport
+
+## CLI
+
+- Full-featured CLI (`@docyrus/docyrus`) for terminal and AI agent use
+- Commands: environment management, authentication, data operations, schema management (studio), app management, API discovery, AI chat, and direct API requests
+- Multi-account, multi-tenant session management
+- OpenAPI discovery with caching and fallback generation
+- Interactive TUI mode
+
+For full CLI command reference, see [docyrus-cli-usage.md](docyrus-cli-usage.md).
+
+## Client Libraries
+
+- REST API client (`@docyrus/api-client`) with OAuth2 support, interceptors, streaming, and file operations
+- React authentication provider (`@docyrus/signin`) with standalone OAuth2 PKCE and iframe postMessage modes
+- Auto-generated collection hooks from OpenAPI specs for data fetching integration