[patch] Reconcile managed release claims

Makefile

@@ -1,10 +1,13 @@
-.PHONY: docs-check task-agent-catalog-check
+.PHONY: docs-check managed-release-claims-check task-agent-catalog-check
 
 MINT_VERSION ?= 4.2.687
 
 task-agent-catalog-check:
 	python3 scripts/check-task-agent-catalog.py
 
-docs-check: task-agent-catalog-check
+managed-release-claims-check:
+	python3 scripts/check-managed-release-claims.py
+
+docs-check: task-agent-catalog-check managed-release-claims-check
 	npx --yes mint@$(MINT_VERSION) validate
 	npx --yes mint@$(MINT_VERSION) broken-links --check-anchors --check-redirects --check-snippets

index.mdx

@@ -21,15 +21,15 @@ LibOps starts with portable Docker Compose templates that can run on a laptop, a
     Provision the VM, persistent volumes, and sitectl context for self-hosted deployments on supported clouds.
   </Card>
   <Card title="Use the managed platform" icon="cloud" href="/platform/managed-platform">
-    Let LibOps handle hosting, firewall rules, Vault-backed secrets, preview environments, membership, and support.
+    Request an evaluated managed-beta engagement whose exact capabilities have passed their release gates.
   </Card>
 </CardGroup>
 
 ## Start here
 
 <CardGroup cols={2}>
   <Card title="Quickstart" icon="rocket" href="/quickstart">
-    Create your first organization, project, and site.
+    Choose an operating model and prepare a supported application Site.
   </Card>
   <Card title="CLI reference" icon="terminal" href="https://sitectl.libops.io">
     Manage sites and local environments with `sitectl`.
@@ -60,7 +60,7 @@ LibOps starts with portable Docker Compose templates that can run on a laptop, a
 
 <CardGroup cols={2}>
   <Card title="Managed platform" icon="cloud" href="/platform/managed-platform">
-    Secure compute, single-tenant sites, and repeatable production hosting.
+    Target architecture, ownership boundaries, and current managed-beta availability.
   </Card>
   <Card title="Security & operations" icon="shield" href="/platform/security-operations">
     Ingress, secrets, updates, and role-based access control.
@@ -77,5 +77,5 @@ LibOps starts with portable Docker Compose templates that can run on a laptop, a
 </CardGroup>
 
 <Note>
-LibOps is currently in **Beta** and serves GLAM institutions, colleges, and universities in the United States and Canada. Review the [Terms of Service](https://www.libops.io/terms/) for details on supported workloads and availability.
+LibOps is currently in **Beta** and serves GLAM institutions, colleges, and universities in the United States and Canada. No managed capability is generally available in the [August 29, 2026 candidate](/infrastructure/current-release-status). Review the [Terms of Service](https://www.libops.io/terms/) for details on supported workloads and availability.
 </Note>

infrastructure/current-release-status.mdx

@@ -7,7 +7,26 @@ description: "A dated availability record for the independently released artifac
 There is not yet a published, platform-wide known-good release set for the managed shared-router and private-PPB request path. The architecture pages describe the target contract, but they are not evidence that this integration is generally available. Do not change production DNS or infrastructure for that path until a later status record identifies every immutable artifact and its green end-to-end release gate.
 </Warning>
 
-This snapshot was reviewed on **August 10, 2026**. It is a release record, not a moving "latest" lookup. A later tag does not silently update the compatibility claims on this page. Older dated references below remain evidence for those exact artifacts; they are not claims that the referenced version is the newest release.
+## Managed-platform candidate status — August 29, 2026
+
+No customer-facing managed capability is generally available in this candidate. Source-complete work remains blocked until the exact deployed revision passes its hosted release gates. Managed hosting remains request-only; LibOps has no self-service managed offer or public managed price book at this stage.
+
+| Capability | Status | Gate that remains |
+| --- | --- | --- |
+| First-customer onboarding and organization/site provisioning | Recovery in progress | Complete the canonical deployment, prove one durable first-customer flow from payment through an operations-ready Site, and retain rollback evidence. Closing the browser must not cancel the durable operation. |
+| GitHub App connection and repository discovery | Blocked | The source fixes for the install URL, repository discovery, and fail-closed permission/event validation are on API `main`. The production App registration still needs the required organization-member read permission and pull-request event, followed by a selected-repository install and webhook canary against the exact deployed API revision. |
+| Slack workspace connection | Blocked | The authenticated install/callback source fix is on API `main`, but the exact revision must be deployed before a Slack Workspace Owner installs the app. Login, resource discovery, task admission, and a threaded completion reply must then pass end to end. |
+| Customer organization Vault | Blocked | Complete the organization deployment and Vault workload routes, then retain initialization, secret round-trip, restart, and recovery evidence for the exact three-image runtime. KMS and GCS supply the recovery material; synthetic custodian keys are not part of this design. |
+| Managed and custom-domain edge routing | Blocked | Supply scoped Cloudflare authority for the active `libops.io` zone, finish the canonical rollout, and pass DNS, certificate, route, authorization-preservation, rollback, and teardown canaries. |
+| Operational reconciliation | Blocked | Restore required hosted API CI for the exact candidate, complete deployment canaries, and prove the worker/fencing and MariaDB recovery gates. Source validation alone is insufficient. |
+| LibOps Task Agent | Blocked | Publish and verify the hardened sandbox and embedded skills artifacts, deploy the complete GitHub/Slack/runtime path, and pass one task-to-reviewable-pull-request canary. |
+| Managed application families | Compatibility candidates only | Promote exact immutable tuples and hosted evidence for Drupal, Islandora, WordPress, Open Journal Systems, Omeka Classic, Omeka S, and ArchivesSpace. A released template does not prove aggregate managed availability. |
+| Availability and recovery | Single-zone preview | Complete MariaDB and customer-Vault restore drills against the approved one-hour MariaDB RPO/RTO and one-hour/two-hour Vault RPO/RTO objectives. There is no managed SLA or automatic failover claim. |
+| Returning-customer and additional-project billing | Planned | Keep this out of the first-customer release claim until its independent billing and provisioning gates pass. |
+
+The source references above include API pull requests [#93](https://github.com/libops/api/pull/93), [#95](https://github.com/libops/api/pull/95), [#96](https://github.com/libops/api/pull/96), and [#97](https://github.com/libops/api/pull/97), all merged into candidate commit [`0df01d0`](https://github.com/libops/api/commit/0df01d09786dcb5a235559c71be63b556f36ce6d). They prove reviewed source changes, not production promotion.
+
+The published-foundation snapshot below was reviewed on **August 10, 2026**. It is a release record, not a moving "latest" lookup. A later tag does not silently update the compatibility claims on this page. Older dated references remain evidence for those exact artifacts; they are not claims that the referenced version is the newest release.
 
 ## Status meanings
 

platform/github.mdx

@@ -5,6 +5,10 @@ description: 'How LibOps uses GitHub repositories, the LibOps GitHub App, and ma
 
 LibOps uses GitHub repositories as the source of truth for site code, deployment configuration, branches, and pull requests. A site can use a LibOps-managed repository by default, or it can use a repository in your own GitHub organization after you install the LibOps GitHub App.
 
+<Warning>
+GitHub App connection is not generally available in the [August 29, 2026 candidate](/infrastructure/current-release-status). Do not install the App for a customer repository until LibOps supplies the install link for an accepted managed-beta deployment and confirms the production App registration, deployed API revision, and selected-repository webhook canary have passed. The workflow below is the operating contract after that release gate.
+</Warning>
+
 ## Repository Options
 
 ### LibOps Managed

platform/managed-platform.mdx

@@ -7,6 +7,10 @@ LibOps gives institutions a managed platform for operating open-source applicati
 
 The platform combines Google Cloud DNS, load balancing, Certificate Manager and Cloud Armor with single-tenant virtual machines, Vault-backed secret management, GitHub review, and Docker Compose templates.
 
+<Warning>
+This page describes the managed-platform target contract. No customer-facing managed capability is generally available in the [August 29, 2026 release candidate](/infrastructure/current-release-status). Managed access is request-only and limited to an accepted beta scope whose exact deployed revision has passed its release gates.
+</Warning>
+
 <Info>
 **Who this page is for:** institutional leaders, IT directors, and procurement evaluators. For day-to-day operators see the [Site Manager Guide](/platform/site-manager-guide). For developers see the [Engineer Guide](/platform/engineer-guide).
 </Info>
@@ -36,9 +40,9 @@ LibOps is designed for organizations that want the flexibility of open-source so
   </Card>
 </CardGroup>
 
-## What every managed site gets
+## Target foundation for an accepted managed site
 
-Instead of asking every project to solve basic operations on its own, LibOps gives every managed site the same foundation:
+When the exact capability set has passed its release gates, an accepted managed-beta scope can provide this common foundation:
 
 <CardGroup cols={3}>
   <Card title="Managed Cloud" icon="cloud">

platform/slack.mdx

@@ -5,19 +5,13 @@ description: "How to use the LibOps Task Agent directly from your Slack workspac
 
 The LibOps Slack integration lets your team use the **LibOps Task Agent** without leaving Slack.
 
+<Warning>
+Slack connection and Task Agent are not generally available in the [August 29, 2026 candidate](/infrastructure/current-release-status). A Slack Workspace Owner should install the app only from the authenticated install page LibOps supplies for an accepted managed-beta deployment after the exact API revision is released. The workflow below is the operating contract after that gate.
+</Warning>
+
 ## Connect Your Slack Workspace
 
-To connect Slack:
-
-<a href="https://api.libops.io/integrations/slack/install">
-  <img
-    alt="Add to Slack"
-    height="40"
-    width="139"
-    src="https://platform.slack-edge.com/img/add_to_slack.png"
-    srcSet="https://platform.slack-edge.com/img/add_to_slack.png 1x, https://platform.slack-edge.com/img/add_to_slack@2x.png 2x"
-  />
-</a>
+For an accepted deployment, open the authenticated Slack install page supplied by LibOps. Do not reuse or bookmark a raw API callback URL.
 
 1. Have a Slack Workspace Owner select **Add to Slack** and approve the LibOps app.
 2. In Slack, run `/libops login` and follow the link to connect your LibOps account.

quickstart.mdx

@@ -30,7 +30,7 @@ Managed resources are organized as:
 2. **Project** — related Sites and configuration that share an application purpose.
 3. **Site** — one runtime environment, such as production, staging, or review.
 
-The first managed onboarding flow creates or selects the Organization and then creates its Project and production Site. Existing customers can select an existing Organization and Project when adding another Site. Keep shared settings at the highest appropriate scope and use Site-level overrides only when one environment must differ. See [Resource Hierarchy](/platform/resource-hierarchy) for membership, firewall, setting, and secret inheritance.
+The first managed onboarding flow creates or selects the Organization and then creates its Project and production Site. Returning-customer and additional-project onboarding is a separate planned release path; do not assume it is available from first-customer evidence. Keep shared settings at the highest appropriate scope and use Site-level overrides only when one environment must differ. See [Resource Hierarchy](/platform/resource-hierarchy) for membership, firewall, setting, and secret inheritance.
 
 Self-hosted operators should establish the same environment boundaries in repository, DNS, credential, and backup naming even when they do not use the managed API.
 

scripts/check-managed-release-claims.py

@@ -0,0 +1,44 @@
+#!/usr/bin/env python3
+"""Keep managed-platform availability claims aligned with the release record."""
+
+from pathlib import Path
+
+
+ROOT = Path(__file__).resolve().parent.parent
+
+
+def read(relative: str) -> str:
+    return (ROOT / relative).read_text()
+
+
+def require(relative: str, expected: str) -> None:
+    if expected not in read(relative):
+        raise SystemExit(f"{relative} is missing the release boundary: {expected}")
+
+
+def reject(relative: str, forbidden: str) -> None:
+    if forbidden in read(relative):
+        raise SystemExit(f"{relative} contains an unreleased managed claim: {forbidden}")
+
+
+def main() -> None:
+    require(
+        "infrastructure/current-release-status.mdx",
+        "No customer-facing managed capability is generally available in this candidate.",
+    )
+    for relative in [
+        "index.mdx",
+        "platform/github.mdx",
+        "platform/managed-platform.mdx",
+        "platform/slack.mdx",
+    ]:
+        require(relative, "/infrastructure/current-release-status")
+
+    reject("platform/slack.mdx", "https://api.libops.io/integrations/slack/install")
+    reject("quickstart.mdx", "Existing customers can select")
+
+    print("Managed release claim validation passed.")
+
+
+if __name__ == "__main__":
+    main()