{
  "name": "SQLStyle documentation",
  "status": "available",
  "llms_txt": "https://sqlstyle.com/llms.txt",
  "llms_full_txt": "https://sqlstyle.com/llms-full.txt",
  "documents": [
    {
      "id": "getting-started",
      "title": "Getting started",
      "description": "Create an account, configure the SQLStyle CLI, and open a local database through the SDK.",
      "section": "Start",
      "summary": "Create an account and open a local SQLite database with replication, writer coordination, and recovery managed around it.",
      "html_url": "https://sqlstyle.com/docs/getting-started",
      "markdown_url": "https://sqlstyle.com/docs/getting-started.md"
    },
    {
      "id": "architecture",
      "title": "Architecture overview",
      "description": "See where SQLStyle runs, what capture publishes, and how replication, backup history, and controller authority fit together.",
      "section": "Architecture",
      "summary": "SQLStyle runs with the Bedrock SQLite/WAL2 database core in each application node. Bedrock publishes committed WAL2 pages into a bounded capture ring, whose records feed direct replication and DBH recovery history. A hosted controller assigns primary authority and fences accepted recovery progress without carrying queries, replication traffic, or backup objects.",
      "html_url": "https://sqlstyle.com/docs/architecture",
      "markdown_url": "https://sqlstyle.com/docs/architecture.md"
    },
    {
      "id": "database-cores-and-capture",
      "title": "Database core and capture",
      "description": "Understand how the Bedrock database core feeds capture for WAL2 retention, page encoding, ring publication, and DBH handoff.",
      "section": "Architecture",
      "summary": "The Bedrock build adapts patched SQLite and WAL2 to SQLStyle's transaction model. Commits publish a requested WAL2 frontier without compression or network work. Capture retains the required WAL2 bytes, encodes pages as predecessor-based differences or complete LZ4 pages, and publishes recoverable records to the shared ring before advancing capture completion.",
      "html_url": "https://sqlstyle.com/docs/database-cores-and-capture",
      "markdown_url": "https://sqlstyle.com/docs/database-cores-and-capture.md"
    },
    {
      "id": "replication",
      "title": "Replication and catch-up",
      "description": "Follow a replica from live page delivery through local DBH catch-up, ring-pressure eviction, and rsync replacement.",
      "section": "Architecture",
      "summary": "The current primary sends captured physical transactions directly to each replica. A replica acknowledges only after committing locally, while the primary does not wait for that acknowledgement. Sessions resume from the capture ring, then local DBH, and perform one exact rsync replacement when neither source covers the requested transaction.",
      "html_url": "https://sqlstyle.com/docs/replication",
      "markdown_url": "https://sqlstyle.com/docs/replication.md"
    },
    {
      "id": "backup-and-recovery-history",
      "title": "Backup and recovery history",
      "description": "Follow captured transactions from local DBH segments through object storage, controller acceptance, retention, and restore planning.",
      "section": "Architecture",
      "summary": "DBH workers turn the capture ring into append-only local history. Finalized segments are validated and cataloged before asynchronous upload; failures remain retryable without stopping capture. Full snapshots provide recovery bases, while the controller fences the contiguous uploaded frontier that readers may treat as authoritative.",
      "html_url": "https://sqlstyle.com/docs/backup-and-recovery-history",
      "markdown_url": "https://sqlstyle.com/docs/backup-and-recovery-history.md"
    },
    {
      "id": "application-stored-procedures",
      "title": "Application Stored Procedures",
      "description": "Define typed application operations that SQLStyle runs with the current database primary.",
      "section": "Concepts",
      "summary": "An Application Stored Procedure is a named, typed database operation whose handler is application code and whose execution follows the database primary. Defining one with the Go SDK returns a typed function; defining one with the Rust SDK returns a typed Procedure. Invoking the function or calling Procedure.call runs the handler directly when local or routes the invocation to the primary. If no writable primary is ready, the SDK waits up to the configured primary wait timeout, eight seconds by default, before returning primary-unavailable. IASP gives SQLStyle ownership of the transaction and idempotent remote execution; ASP leaves transaction and duplicate handling to the application.",
      "html_url": "https://sqlstyle.com/docs/application-stored-procedures",
      "markdown_url": "https://sqlstyle.com/docs/application-stored-procedures.md"
    },
    {
      "id": "multi-process",
      "title": "Multi-process operation",
      "description": "Understand how application processes share one database, assign capture ownership, and continue after the capture host exits.",
      "section": "Architecture",
      "summary": "Every process opens SQLite directly, while a per-database shared memory coordinates one capture host and independent presence leases. The operating system releases capture ownership when its process exits. A same-boot successor validates the shared ring, WAL frontiers, DBH prefix, and controller grant before resuming; a companion can finish recovery when no application process remains.",
      "html_url": "https://sqlstyle.com/docs/multi-process",
      "markdown_url": "https://sqlstyle.com/docs/multi-process.md"
    },
    {
      "id": "lightspeed",
      "title": "Standard, Permissive, and Lightspeed integrity modes",
      "description": "Choose user-connection, live-replication, and local-image integrity policy independently on each SQLStyle node.",
      "section": "Architecture",
      "summary": "Standard starts managed user connections at synchronous=NORMAL, restricts later values to NORMAL or FULL, and applies live replication at NORMAL. Permissive preserves the database core's user-connection default, permits every supported synchronous value, and applies live replication at NORMAL. Lightspeed starts user connections and applies live replication at OFF, then requires authoritative recovery when an enrolled local image lacks the required clean-close SHA-256 proof. Each node selects its own mode, and attached processes follow the active owner's coherent policy.",
      "html_url": "https://sqlstyle.com/docs/lightspeed",
      "markdown_url": "https://sqlstyle.com/docs/lightspeed.md"
    },
    {
      "id": "primary-and-failover",
      "title": "Primary authority and failover",
      "description": "Understand direct peer health, controller confirmation, recoverable candidate selection, and fenced transfer to a new primary.",
      "section": "Architecture",
      "summary": "Capture owners detect broken holder connections through direct health streams, while the controller alone can end an authority grant. Fast failover uses the live holder and connected vote-capable connections. A promotable runtime must cover the required recovery transaction before receiving a newer fencing token.",
      "html_url": "https://sqlstyle.com/docs/primary-and-failover",
      "markdown_url": "https://sqlstyle.com/docs/primary-and-failover.md"
    },
    {
      "id": "node-roles",
      "title": "Node capabilities",
      "description": "Configure controller permissions, capture ownership, and capture-loss recovery independently.",
      "section": "Concepts",
      "summary": "SQLStyle has no node roles; five independent capabilities describe what each connection may do.",
      "html_url": "https://sqlstyle.com/docs/node-roles",
      "markdown_url": "https://sqlstyle.com/docs/node-roles.md"
    },
    {
      "id": "object-storage",
      "title": "Object storage",
      "description": "Store backups and recovery history in your S3-compatible object storage.",
      "section": "Guides",
      "summary": "SQLStyle stores backups in your S3-compatible bucket, keeps the secret local, and preserves a verified recovery path during retention.",
      "html_url": "https://sqlstyle.com/docs/object-storage",
      "markdown_url": "https://sqlstyle.com/docs/object-storage.md"
    },
    {
      "id": "restore-and-recovery",
      "title": "Point-in-time recovery",
      "description": "Build recovery history in your object storage, verify it, and restore SQLite to the latest accepted state or an earlier point in time.",
      "section": "Guides",
      "summary": "Embedded SQLStyle writes snapshots and incremental history to customer-owned object storage; database recovery commands verify the accepted chain and restore the latest state or a selected point in time without requiring a surviving node.",
      "html_url": "https://sqlstyle.com/docs/restore-and-recovery",
      "markdown_url": "https://sqlstyle.com/docs/restore-and-recovery.md"
    },
    {
      "id": "status-and-sql-surfaces",
      "title": "Status and SQL surfaces",
      "description": "Query authority, topology, backup, and durability state through the managed SQLite connection.",
      "section": "Reference",
      "summary": "SQLStyle exposes operational state as SQLite tables and functions; applications should use sqlstyle_status and write only while authority is held.",
      "html_url": "https://sqlstyle.com/docs/status-and-sql-surfaces",
      "markdown_url": "https://sqlstyle.com/docs/status-and-sql-surfaces.md"
    },
    {
      "id": "controller-state-writes",
      "title": "What consumes controller-state writes",
      "description": "See which database, account, and runtime actions consume the controller-state write allowance.",
      "section": "Reference",
      "summary": "Creating a database normally consumes four controller-state writes. Creating or revoking a database-scoped key consumes one write per affected controller, while deleting a database removes its controllers without adding writes. Analytics collections use the database controller, and changing database TLS consumes one write per active controller. Authority assignment, release, reconnect, and failover also consume writes when authority state changes. Restore commands, analytics exports, and promotable runtime startup consume one only when their fenced read advances the accepted recovery frontier. SQL transactions, replication, backup uploads, and ordinary heartbeats do not count.",
      "html_url": "https://sqlstyle.com/docs/controller-state-writes",
      "markdown_url": "https://sqlstyle.com/docs/controller-state-writes.md"
    },
    {
      "id": "cli-reference",
      "title": "CLI reference",
      "description": "Manage accounts, databases, keys, storage, recovery, and analytics from the CLI.",
      "section": "Reference",
      "summary": "Use the SQLStyle CLI for databases and recovery; use the web dashboard for accounts and billing.",
      "html_url": "https://sqlstyle.com/docs/cli-reference",
      "markdown_url": "https://sqlstyle.com/docs/cli-reference.md"
    }
  ]
}