libops · libops-agent · Aug 8, 2026 · Aug 8, 2026 · Aug 8, 2026
diff --git a/api/reference/append_task_log.mdx b/api/reference/append_task_log.mdx
diff --git a/api/reference/check_convergence.mdx b/api/reference/check_convergence.mdx
diff --git a/api/reference/check_site_domain.mdx b/api/reference/check_site_domain.mdx
@@ -0,0 +1,4 @@
+---
+title: 'CheckSiteDomain'
+openapi: 'POST /libops.v1.DomainService/CheckSiteDomain'
+---
diff --git a/api/reference/create_account.mdx b/api/reference/create_account.mdx
diff --git a/api/reference/delete_account.mdx b/api/reference/delete_account.mdx
diff --git a/api/reference/generate_terraform_vars.mdx b/api/reference/generate_terraform_vars.mdx
diff --git a/api/reference/get_account.mdx b/api/reference/get_account.mdx
diff --git a/api/reference/get_account_by_email.mdx b/api/reference/get_account_by_email.mdx
@@ -1,4 +1,4 @@
 ---
-title: 'Get account information by email [Requires: admin:system]'
-openapi: 'GET /libops.v1.AdminAccountService/GetAccountByEmail'
+title: 'Get account information by email (for Terraform provider lookups) [Requires: read:user]'
+openapi: 'GET /libops.v1.AccountService/GetAccountByEmail'
 ---
diff --git a/api/reference/get_blob.mdx b/api/reference/get_blob.mdx
diff --git a/api/reference/get_reconciliation_run.mdx b/api/reference/get_reconciliation_run.mdx
diff --git a/api/reference/get_site_domain.mdx b/api/reference/get_site_domain.mdx
@@ -0,0 +1,4 @@
+---
+title: 'GetSiteDomain'
+openapi: 'GET /libops.v1.DomainService/GetSiteDomain'
+---
diff --git a/api/reference/get_site_firewall.mdx b/api/reference/get_site_firewall.mdx
diff --git a/api/reference/get_site_secrets.mdx b/api/reference/get_site_secrets.mdx
diff --git a/api/reference/get_site_sshkeys.mdx b/api/reference/get_site_sshkeys.mdx
diff --git a/api/reference/introduction.mdx b/api/reference/introduction.mdx
@@ -7,6 +7,8 @@ description: 'LibOps API Reference'
 
 The LibOps API gives teams programmatic access to the platform. It is the same operational model exposed through the dashboard and `sitectl`, available for automation, governance, reporting, and integration work.
 
+This reference covers the customer-facing API. LibOps administrative and control-plane RPCs are intentionally omitted from the published OpenAPI document and navigation.
+
 Use the API to manage:
 
 - Organizations.
@@ -25,12 +27,12 @@ Use the API to manage:
   icon="code"
   href="/api/reference/openapi.yaml"
 >
-  View the full OpenAPI specification file.
+  View the complete customer OpenAPI specification file.
 </Card>
 
 ## Why It Matters
 
-LibOps is designed to make open-source application operations repeatable. A full API means the platform can fit into your existing institutional workflows instead of forcing every task through a UI.
+LibOps is designed to make open-source application operations repeatable. A stable customer API means the platform can fit into your existing institutional workflows instead of forcing every task through a UI.
 
 Teams can connect LibOps to internal provisioning flows, service catalogs, access reviews, reporting tools, or custom automation while preserving the same organization, project, site, secret, firewall, member, and deployment model.
 
@@ -47,9 +49,11 @@ Authorization: Bearer <your_api_key>
 The base URL for the API is:
 
 ```text
-https://api.libops.io/v1
+https://api.libops.io
 ```
 
+Append the ConnectRPC operation path shown on each reference page, such as `/libops.v1.SiteService/CreateSite`.
+
 ## Response Format
 
 All responses are returned in JSON format.
diff --git a/api/reference/list_account_projects.mdx b/api/reference/list_account_projects.mdx
diff --git a/api/reference/list_account_repositories.mdx b/api/reference/list_account_repositories.mdx
diff --git a/api/reference/list_accounts.mdx b/api/reference/list_accounts.mdx
diff --git a/api/reference/list_all_projects.mdx b/api/reference/list_all_projects.mdx
diff --git a/api/reference/list_all_sites.mdx b/api/reference/list_all_sites.mdx
diff --git a/api/reference/openapi.yaml b/api/reference/openapi.yaml
diff --git a/api/reference/retry_site_domain_provisioning.mdx b/api/reference/retry_site_domain_provisioning.mdx
@@ -0,0 +1,4 @@
+---
+title: 'RetrySiteDomainProvisioning'
+openapi: 'POST /libops.v1.DomainService/RetrySiteDomainProvisioning'
+---
diff --git a/api/reference/site_check_in.mdx b/api/reference/site_check_in.mdx
diff --git a/api/reference/sync_manifest.mdx b/api/reference/sync_manifest.mdx
diff --git a/api/reference/update_account.mdx b/api/reference/update_account.mdx
diff --git a/api/reference/update_reconciliation_status.mdx b/api/reference/update_reconciliation_status.mdx
diff --git a/docs.json b/docs.json
@@ -139,9 +139,12 @@
           {
             "group": "Domains",
             "pages": [
+              "api/reference/check_site_domain",
               "api/reference/create_site_domain",
               "api/reference/delete_site_domain",
-              "api/reference/list_site_domains"
+              "api/reference/get_site_domain",
+              "api/reference/list_site_domains",
+              "api/reference/retry_site_domain_provisioning"
             ]
           },
           {
@@ -299,7 +302,6 @@
           {
             "group": "Task Agent",
             "pages": [
-              "api/reference/append_task_log",
               "api/reference/cancel_task",
               "api/reference/create_task",
               "api/reference/get_task",

diff --git a/platform/api-cli.mdx b/platform/api-cli.mdx
@@ -3,11 +3,11 @@ title: "API and sitectl"
 description: "How the LibOps API and sitectl command line support operators, developers, and automation"
 ---
 
-LibOps gives teams three operating surfaces: the dashboard, the full platform API, and the `sitectl` command-line utility.
+LibOps gives teams three operating surfaces: the dashboard, the customer-facing platform API, and the `sitectl` command-line utility.
 
 That matters because institutions rarely have a single type of operator. Some work belongs in a UI, some belongs in automation, and some belongs in a terminal next to the application repository.
 
-## Full Platform API
+## Customer Platform API
 
 The LibOps API exposes the core platform resources:
 
@@ -24,6 +24,8 @@ The LibOps API exposes the core platform resources:
 
 Teams can use the API to integrate LibOps with provisioning systems, reporting workflows, governance tooling, or internal service catalogs.
 
+The published OpenAPI document intentionally excludes LibOps administrative and control-plane RPCs. Those operations are internal implementation details, not customer automation contracts.
+
 <Card title="API Reference" icon="code" href="/api/reference/introduction">
   Explore the LibOps API endpoints and OpenAPI specification.
 </Card>

diff --git a/platform/coding-agent-workflow.mdx b/platform/coding-agent-workflow.mdx
@@ -7,19 +7,19 @@ The **LibOps Task Agent** is an AI-assisted development tool that implements cus
 
 This workflow lets stakeholders propose and preview site changes without bypassing technical review, quality assurance, or established deployment controls.
 
-<Info>
-The default model is `glm-5.2:cloud`. `kimi-k2.6` is also supported, and LibOps evaluates new open-weight models as they become available.
-</Info>
+<Warning>
+The Task Agent is currently a managed-beta capability, not a generally available production feature. As of August 8, 2026, the release candidate is blocked: its catalog still points to a sandbox build that predates the required managed-egress contract, and its embedded skill manifest points to a canonical source revision that has not been published. LibOps will enable it only after replacement artifacts pass release verification, the organization model gateway passes its dependency readiness check, and an end-to-end coding-task canary succeeds. Do not make Task Agent availability part of an initial site launch plan unless LibOps confirms those checks for your deployment.
+</Warning>
 
 ## Models and execution boundary
 
-The LibOps Task Agent can run `codex`, `claude`, `pi`, `opencode`, or `gemini` through the [`libops/cli-sandbox`](https://github.com/libops/cli-sandbox) image.
+The candidate production catalog contains one runtime selection: the `codex` harness through an exact digest of the [`libops/cli-sandbox`](https://github.com/libops/cli-sandbox) image, using the customer model name `glm-5.2:cloud`. Other harnesses and models are not supported options in this catalog. A catalog entry is configuration, not evidence that the runtime has passed promotion.
 
-The supported models run inside your organization's infrastructure on the LibOps-managed platform. Only members of your organization can access the infrastructure serving those models.
+Your organization's private Cloud Run service is an authenticated model gateway. It does not host model weights or perform inference. The gateway maps the customer model name `glm-5.2:cloud` to `glm-5.2` and forwards the request to Ollama Cloud at `https://ollama.com`, where inference runs. Access to the organization gateway remains private to authorized platform workloads.
 
-Contact [LibOps](https://www.libops.io/contact/) if your organization wants to integrate with Anthropic, OpenAI, or another model provider.
+LibOps reviews new runtime options before adding them to the production catalog; documentation and provisioning are updated together when support is available.
 
-For site coding tasks, the runner requests the application plugin's assistant development mode before the harness starts. Drupal, WordPress, and ISLE currently declare safe downstream-owned mount lists and a profiled `cli-sandbox` service in `docker-compose.override.yml`. Bundled applications such as OJS, Omeka, and ArchivesSpace do not expose broad development mounts because those mounts could hide extensions supplied by the versioned image; their changes stay in explicit tracked extension paths and are tested through a rebuilt downstream image. Current component options and command syntax live in the [sitectl component documentation](https://sitectl.libops.io/components).
+For hosted coding tasks, the runtime controller owns a fixed direct Docker launch and does not execute or rewrite a customer repository's Compose configuration to define the sandbox. The agent receives the isolated task checkout and bounded runtime files; it does not receive the Docker socket, production checkout, cloud credentials, or GitHub token. Application-specific guidance comes from the release-verified embedded skill bundle without broadening that execution boundary.
 
 ## Why use the LibOps Task Agent?
 
@@ -37,17 +37,17 @@ This is **not** unchecked automation. It reduces the time between "we need a cha
   <Step title="Task creation" icon="message">
     A site owner, developer, or LibOps operator defines a task for a specific site.
   </Step>
-  <Step title="Environment selection" icon="server">
-    LibOps provisions or selects an isolated development or ephemeral preview environment for the work.
+  <Step title="Task branch and preview" icon="server">
+    LibOps reserves a dedicated task branch at the verified base revision and brings its non-production preview environment to readiness.
   </Step>
   <Step title="Agent implementation" icon="wand-magic-sparkles">
     The Task Agent implements the change in the site's repository on a dedicated task branch.
   </Step>
-  <Step title="Pull request" icon="github">
-    The agent opens or updates a GitHub pull request, which becomes the record of every code and configuration change.
-  </Step>
   <Step title="Preview deployment" icon="globe">
-    The preview environment shows the proposed changes on a live version of the site.
+    LibOps pushes the changed revision and waits for that exact commit to reach a ready preview state.
+  </Step>
+  <Step title="Pull request" icon="github">
+    After preview readiness, the agent opens or updates a GitHub pull request, which becomes the record of every code and configuration change.
   </Step>
   <Step title="Stakeholder review" icon="eye">
     Site managers and other stakeholders validate the behavior and content in the preview environment before production changes.
@@ -63,9 +63,28 @@ This is **not** unchecked automation. It reduces the time between "we need a cha
   </Step>
 </Steps>
 
+## Starting a task from the Dashboard
+
+This path is available only after LibOps confirms Task Agent managed-beta readiness for the deployed release.
+
+<Steps>
+  <Step title="Wait for the initial site" icon="circle-check">
+    Confirm the Site's repository provisioning and initial deployment are ready. A newly accepted or still-provisioning Site is not ready for coding work.
+  </Step>
+  <Step title="Open the scoped task page" icon="wand-magic-sparkles">
+    Open the Site detail page and select **Open Task Agent**. The Dashboard carries the Organization, Project, and Site context into the Tasks page.
+  </Step>
+  <Step title="Describe one change" icon="message">
+    Verify the selected context, describe one bounded outcome, and select **Start**. Do not include passwords, API keys, tokens, or other secret values in the request.
+  </Step>
+  <Step title="Review the result" icon="eye">
+    Follow the task status, then inspect both the exact preview and GitHub pull request before approving a merge.
+  </Step>
+</Steps>
+
 ## Starting a task from Slack
 
-The LibOps Slack integration lets stakeholders start tasks without leaving their primary communication tool.
+An operator-linked Slack workspace can start tasks without leaving the primary communication tool. Slack and Task Agent must both be enabled for the exact managed-beta deployment; see [Slack Integration](/platform/slack) before using these commands.
 
 <Steps>
   <Step title="Discover your resources" icon="list">
@@ -169,7 +188,7 @@ The Task Agent is useful when stakeholders need a reviewable change but do not n
     - No local environment required.
     - Same GitHub PR + preview environment as the manual path.
     - Iterative refinement via `@libops` PR comments.
-    - Available from the Dashboard or Slack.
+    - Available from the Dashboard, or an operator-linked Slack workspace, only for an approved managed-beta deployment.
   </Tab>
 
   <Tab title="Engineering locally" icon="laptop-code">
@@ -186,7 +205,7 @@ The Task Agent is useful when stakeholders need a reviewable change but do not n
         Use the same Git-based workflow as the agent: create a branch, push changes, and open a PR.
       </Step>
       <Step title="Automatic preview" icon="globe">
-        Opening a PR provisions a preview environment for your branch, exactly like the agent path.
+        Opening a PR provisions a preview environment through the same branch deployment contract. The timing differs: the agent path verifies its updated preview before opening the PR.
       </Step>
       <Step title="Operate with sitectl" icon="terminal">
         Operate local or remote Compose contexts with sitectl, and use the LibOps platform integration for managed secrets and deployments.
@@ -237,7 +256,7 @@ This combination lets directors, site managers, and engineers participate withou
     Managed, co-managed, and self-managed customization options.
   </Card>
   <Card title="Slack integration" icon="slack" href="/platform/slack">
-    Use the LibOps Task Agent from your Slack workspace.
+    Connect an approved managed-beta Slack workspace to the LibOps Task Agent.
   </Card>
   <Card title="GitHub integration" icon="github" href="/platform/github">
     How task branches, pull requests, and preview environments integrate with your repository.

diff --git a/platform/site-manager-guide.mdx b/platform/site-manager-guide.mdx
@@ -31,24 +31,30 @@ You primarily interact with LibOps through the hosted dashboard and, if configur
 
 Most site management workflows begin in the Dashboard.
 
+The first paid managed Site uses the single-page onboarding flow described in the [Quickstart](/quickstart): choose the template and infrastructure, complete checkout, and wait for the durable provisioning status to finish. The steps below describe adding a Site after the Organization and Project already exist.
+
 <Steps>
   <Step title="Pick the organization and project" icon="folder-tree">
     Identify the institutional organization and project that should own the new site.
   </Step>
-  <Step title="Create the site" icon="circle-plus">
-    Select **Create site** and choose one of the supported application templates.
+  <Step title="Prepare the repository" icon="github">
+    For a customer-owned repository, install the LibOps GitHub App with access to the repository and start from a supported application template. First-site onboarding creates the private LibOps-managed repository automatically.
   </Step>
-  <Step title="Configure the repository" icon="github">
-    Decide whether LibOps should manage the site's repository or connect to your own GitHub organization.
+  <Step title="Create the site" icon="circle-plus">
+    Select **Create site**, enter the installed customer repository, and choose the compatible application template so the Dashboard can apply its lifecycle defaults.
   </Step>
   <Step title="Set up the environment" icon="gear">
-    Name the site, choose its purpose (production, staging, etc.), and set the intended hostname.
+    Name the Site and mark it as production only when it represents the repository's production branch. Configure a custom hostname after the Site exists.
   </Step>
-  <Step title="Review and launch" icon="check">
-    Confirm the generated configuration, including repository, access, and hostnames, then finalize the site.
+  <Step title="Wait for readiness" icon="check">
+    Site creation records desired state; it is not deployment success. Wait for provisioning and the initial deployment to reach their terminal ready states before configuring DNS or starting review work.
   </Step>
 </Steps>
 
+<Warning>
+If managed onboarding or Site provisioning reports a terminal failure, do not create a replacement with the same repository or purchase another subscription. Contact LibOps so the recorded operation can be safely resumed or refunded without duplicating infrastructure.
+</Warning>
+
 <Warning>
 LibOps only supports workloads based on the documented templates. Running other applications on managed infrastructure is not permitted. See the [Terms of Service](https://www.libops.io/terms/) for details.
 </Warning>