release(v2.0.2): unify component docs, bump theta-directory/proxy/jump-host (#194)

Unifies the GitHub Pages docs site: the SSO/Proxy/Jump Host pages, their
nav labels, and each component's own README now consistently say Theta
Directory / Theta Proxy / Theta Gateway, drop marketing sections ("Why this
over the alternatives", "Get it", "Related projects") that don't apply to a
suite component, remove every standalone/bare-metal install path, and link
to theta42.github.io/theta-suite/... instead of the old per-repo Pages sites.

Bumps submodules: theta-directory v2.0.2, proxy v2.0.1, jump-host v2.0.1.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

docs/sso/agents.md

@@ -6,7 +6,7 @@ nav_order: 5
 
 # Discovery Agents
 
-The SSO Manager supports a robust agent architecture for auto-discovering devices, hosts, and services across your home lab or data center. Agents run on a scheduled cron and feed their data into a central **Reconciliation Engine** that smartly merges information based on MAC addresses and IPs.
+Theta Directory supports a robust agent architecture for auto-discovering devices, hosts, and services across your home lab or data center. Agents run on a scheduled cron and feed their data into a central **Reconciliation Engine** that smartly merges information based on MAC addresses and IPs.
 
 ## Writing a Custom Agent
 

docs/sso/concepts-accounts.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Accounts, Groups & Managers
-description: A plain-language guide to users, service accounts, personal groups, and managers in SSO Manager.
+description: A plain-language guide to users, service accounts, personal groups, and managers in Theta Directory.
 ---
 
 # Accounts, Groups & Managers
@@ -12,7 +12,7 @@ see the [LDAP reference](ldap.html).
 
 ## What's an account?
 
-Every person (or app) that can sign in through this SSO Manager has an
+Every person (or app) that can sign in through Theta Directory has an
 **account** — a username, a display name, maybe an email address, and a
 password (or, for service accounts, no password at all — see below).
 Accounts live in the directory this app manages, and any other app you've

docs/sso/concepts-api-tokens.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: API Tokens
-description: A plain-language guide to personal access tokens in SSO Manager.
+description: A plain-language guide to personal access tokens in Theta Directory.
 ---
 
 # API Tokens

docs/sso/concepts-oauth-apps.md

@@ -1,20 +1,20 @@
 ---
 layout: default
 title: Connecting Apps (Single Sign-On)
-description: A plain-language guide to OAuth/OIDC clients and single sign-on in SSO Manager.
+description: A plain-language guide to OAuth/OIDC clients and single sign-on in Theta Directory.
 ---
 
 # Connecting Apps (Single Sign-On)
 
 This page explains, in plain language, what happens when you "connect" an
-app to your SSO Manager so people can log into it with their existing
+app to Theta Directory so people can log into it with their existing
 account. For the technical endpoint/token detail, see the
 [OAuth reference](oauth.html).
 
 ## What does "single sign-on" actually mean?
 
 Instead of every app you run having its own separate list of usernames and
-passwords, they all check with this SSO Manager instead. You log in once,
+passwords, they all check with Theta Directory instead. You log in once,
 here, and any connected app trusts that login — no separate password to
 remember or manage for each one. If you ever need to lock someone out
 everywhere at once, you do it in one place (deactivate their account here)
@@ -33,11 +33,11 @@ gives you a **Client ID** and **Client Secret**: think of these like a
 username and password, but for the *app itself* rather than for a person.
 You paste them into the other app's own "Single Sign-On" or "OIDC" setup
 screen, along with the discovery URL shown at the top of this page, and
-that app is now able to ask this SSO Manager to authenticate people on its
+that app is now able to ask Theta Directory to authenticate people on its
 behalf.
 
 **Treat the Client Secret like a password** — anyone who has it can
-impersonate that app when talking to your SSO Manager. If you ever suspect
+impersonate that app when talking to Theta Directory. If you ever suspect
 it's leaked, rotate it from the client's card.
 
 ## What are "scopes"?
@@ -50,13 +50,13 @@ setup instructions; when in doubt, the default set (`openid`, `profile`,
 
 ## "Restrict to Groups"
 
-By default, *any* account with an SSO Manager login can sign into a
+By default, *any* account with a Theta Directory login can sign into a
 connected app. If that's not what you want — say, a home automation
 dashboard that only certain family members should reach — set **Restrict
 to Groups** on that client to one of your [groups](concepts-accounts.html).
 Only members of that group will be allowed to log into that particular
 app; everyone else gets turned away at the login step, even though their
-SSO Manager account still works everywhere else.
+Theta Directory account still works everywhere else.
 
 ## Redirect URIs
 

docs/sso/configuration.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Configuration
-description: SSO Manager's config layers — conf/base.js defaults, secrets.js overrides, and app_* environment variables.
+description: Theta Directory's config layers — conf/base.js defaults, secrets.js overrides, and app_* environment variables.
 ---
 
 # Configuration

docs/sso/directory.md

@@ -6,7 +6,7 @@ description: Managing your Home-Lab infrastructure, services, and LDAP access re
 
 # Directory Management
 
-The SSO Manager ships with a built-in **Directory & Inventory Management** feature. Instead of just managing bare LDAP groups for your homelab, the Directory allows you to map out your infrastructure graph and assign rich metadata to your services.
+Theta Directory ships with a built-in **Directory & Inventory Management** feature. Instead of just managing bare LDAP groups for your homelab, the Directory allows you to map out your infrastructure graph and assign rich metadata to your services.
 
 ## Architecture
 
@@ -18,11 +18,11 @@ There are three primary **Kinds** of resources you can define:
 - **Service (App)**: An application, web service. A Service **must** have a parent Host or another Service.
 - **OAuth Integration**: An OAuth 2.0 / OpenID Connect client application. An OAuth integration **must** have a parent Service.
 
-By defining this hierarchy, the SSO Manager builds a queryable graph of your infrastructure.
+By defining this hierarchy, Theta Directory builds a queryable graph of your infrastructure.
 
 ## Automatic LDAP Group Creation
 
-When you create a new **Host** or **Service** in the Directory via the web UI (or API), the SSO Manager will automatically provision two LDAP groups in your directory to govern access to that resource:
+When you create a new **Host** or **Service** in the Directory via the web UI (or API), Theta Directory will automatically provision two LDAP groups in your directory to govern access to that resource:
 
 1. `<slug>_access` (Member level access)
 2. `<slug>_admin` (Owner level access)
@@ -84,7 +84,7 @@ The Directory Management interface provides a **Tree View** toggle that visually
 
 ## Slug conventions
 
-Slugs are the stable identifiers automation keys off, so the tooling around the SSO Manager follows a shared convention:
+Slugs are the stable identifiers automation keys off, so the tooling around Theta Directory follows a shared convention:
 
 - **Sites**: `site_<name>` — e.g. `site_local`, `site_us-east`
 - **Hosts**: `host_<hostname>` — e.g. `host_pve1`, `host_web01`
@@ -102,7 +102,7 @@ You don't have to build the graph by hand — the theta42 tooling registers itse
 
 - a **site** (name from `CFG_SITE_NAME` in `setup.env`, default `local` → slug `site_local`) marked as the current site
 - the **host** the stack runs on (`host_<hostname>`), with IP, MAC address, OS, and kernel collected from the machine
-- the **services** it composes — SSO Manager, Proxy (management UI), OpenLDAP Directory (the LDAPS endpoint Linux hosts and LDAP-native apps bind to), and OpenResty Edge (the 80/443 data plane) — each with its address, internal port, and git repo
+- the **services** it composes — Theta Directory, Proxy (management UI), OpenLDAP Directory (the LDAPS endpoint Linux hosts and LDAP-native apps bind to), and OpenResty Edge (the 80/443 data plane) — each with its address, internal port, and git repo
 - the proxy's auto-registered **OAuth client**, linked under its service
 
 The seed is idempotent and non-destructive: a resource whose slug already exists is considered operator-owned — the seed only fills in metadata fields you haven't set, and never overwrites your values.

docs/sso/index.md

@@ -1,24 +1,25 @@
 ---
 layout: default
 title: Home
-description: A self-hosted OpenID Connect provider with a bundled OpenLDAP directory and a web management UI. One login for your modern apps, one LDAP directory for the rest, no phone-home.
+description: Theta Directory — the OpenID Connect provider, bundled OpenLDAP directory, and resource inventory at the core of theta-suite. One login for your modern apps, one LDAP directory for the rest, no phone-home.
 ---
 
-# SSO Manager
+# Theta Directory
 
-A self-hosted **OpenID Connect provider** with a bundled **OpenLDAP directory**
-and a web management UI — for home labs and small businesses that want their
-own identity provider instead of a hosted one.
+The identity and directory component of [theta-suite](../): an **OpenID
+Connect provider**, a bundled **OpenLDAP directory**, and a **resource
+inventory & IAM engine**, all behind one web console.
 
 One place to manage your users and groups, one login (OIDC) your modern apps
-can use, and one LDAP directory your older or odder apps can bind to directly.
-Everything runs on your own hardware; no phone-home, no hosted control plane,
-no per-user pricing.
+can use, and one LDAP directory your older or odder apps can bind to directly
+— plus a graph of every site, host, and service you run, with auto-provisioned
+access groups. Everything runs on your own hardware; no phone-home, no hosted
+control plane, no per-user pricing.
 
-Part of the theta42 self-hosted identity stack, alongside
-[Proxy](https://theta42.github.io/proxy/) (an OIDC + LDAP-aware reverse proxy)
-and [theta-env](https://theta42.github.io/theta-env/) (the two composed with
-one command).
+Theta Directory is deployed as part of theta-suite, alongside
+[Proxy](../proxy/) and [Jump Host](../jump-host/) — it isn't installed or run
+on its own. See the [Quickstart](../quickstart.html) to stand up the whole
+stack with one command.
 
 ## Screenshots
 
@@ -27,23 +28,11 @@ one command).
 <a href="images/groups.png" target="_blank"><img src="images/groups.png" alt="Groups" width="49%"></a>
 <a href="images/directory.png" target="_blank"><img src="images/directory.png" alt="Directory & inventory" width="49%"></a>
 <a href="images/oauth-clients.png" target="_blank"><img src="images/oauth-clients.png" alt="OAuth client (edit view)" width="49%"></a>
+<a href="images/agent-capabilities-metrics.png" target="_blank"><img src="images/agent-capabilities-metrics.png" alt="Agent capabilities & metrics" width="49%"></a>
+<a href="images/agent-install-join-key.png" target="_blank"><img src="images/agent-install-join-key.png" alt="Agent install with join key" width="49%"></a>
 
 *(click any screenshot to view full size)*
 
-## Why this over the alternatives
-
-Tools like Keycloak, Authentik, Authelia, or Zitadel are OIDC providers, but
-LDAP is either a paid feature, a federation target you have to run
-separately, or absent. If your stack already has apps that speak LDAP
-directly — or you just want one real directory as the source of truth — you
-end up running *two* identity systems and keeping them in sync.
-
-SSO Manager bundles the OpenLDAP directory with the OIDC provider, so OIDC
-apps and LDAP apps read from the same users and groups. The trade-off is
-scope: it's intentionally small and self-hosted, not an enterprise IAM suite.
-If you want a lightweight, self-contained identity provider with a real LDAP
-backend, that's the niche.
-
 ## Features
 
 - **OpenID Connect / OAuth 2.0 provider** — your own access/refresh/ID
@@ -56,30 +45,7 @@ backend, that's the niche.
 - **Direct LDAP binds** — anything that binds LDAP directly (Linux hosts
   via PAM/SSSD, Gitea, Emby, …) uses LDAPS/StartTLS against the same
   directory.
-- **All-in-one Docker image** — app + OpenLDAP + Redis in one container, or
-  run the pieces separately via `app_*` env config.
 - **Geo-Location Scaling** — built-in support for N-Way Multi-Master OpenLDAP [replication](replication.html) across physical sites.
-- **[Directory & Inventory](directory.html)** — map sites, hosts, and services as a graph with rich metadata (IP/MAC, OS/kernel, ports, git repos), auto-provisioned access groups, and automatic registration from theta-env and ldap-client. Drives directory-aware tools like the [SSH jump host](https://theta42.github.io/jump-host/).
-
-## Get it
-
-```bash
-git clone https://github.com/theta42/sso-manager-node.git
-cd sso-manager-node
-cp secrets.js.example nodejs/conf/secrets.js   # edit it, or use app_* env
-docker compose up -d --build
-```
-
-For the full set of install options
-(Docker, bare-metal, or as part of the combined SSO + proxy stack), the
-`app_*` env reference, and the OAuth/LDAP internals, see the
-**[GitHub repository](https://github.com/theta42/sso-manager-node)**.
-
-## Related projects
-
-- **[Proxy](https://theta42.github.io/proxy/)** — an OIDC + LDAP-aware
-  reverse proxy, designed to sit in front of this SSO.
-- **[Jump Host](https://theta42.github.io/jump-host/)** — an SSH jump host that
-  uses this SSO's directory to decide who may reach which machine.
-- **[theta-env](https://theta42.github.io/theta-env/)** — runs this SSO
-  Manager and the proxy together with one command.
+- **[Directory & Inventory](directory.html)** — map sites, hosts, and services as a graph with rich metadata (IP/MAC, OS/kernel, ports, git repos), auto-provisioned access groups, and automatic registration from theta-suite's agents and discovery plugins. Drives directory-aware tools like the [SSH jump host](../jump-host/).
+- **Subtype metrics & lifecycle drivers** — telemetry, log streaming, and remote control for resources tagged with a `subType` (`systemd`, `docker`, `proxmox`, `wireguard`, `postgresql`, `redis`, `k8s`, …).
+- **OpenBao-backed secrets** — per-resource and per-user secrets with explicit upward inheritance (`Resource → Host → Cluster → Site`).

docs/sso/ldap.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: LDAP
-description: SSO Manager's bundled OpenLDAP directory — schema, service accounts, TLS, and connecting third-party apps directly.
+description: Theta Directory's bundled OpenLDAP directory — schema, service accounts, TLS, and connecting third-party apps directly.
 ---
 
 # LDAP Directory
@@ -12,7 +12,7 @@ description: SSO Manager's bundled OpenLDAP directory — schema, service accoun
 > instead of schema/attribute detail? See
 > [Accounts, Groups & Managers](concepts-accounts.html).
 
-SSO Manager runs an OpenLDAP directory holding your users and groups. The app
+Theta Directory runs an OpenLDAP directory holding your users and groups. The app
 authenticates against it over `localhost:389` (inside the all-in-one container)
 and exposes **LDAPS** (`ldaps://…:636`, TLS) for anything that binds LDAP
 directly — Linux hosts (PAM/SSSD, sudo rules, SSH keys), Gitea, Emby, the
@@ -167,8 +167,8 @@ internal-only patterns and set `conf.ldap.ldapsHost` (or
 
 ### 1. Same Docker / local network host (best for apps on this machine)
 
-If the LDAP client runs on the same Docker network as the SSO Manager (for
-example, the bundled `theta-env` stack), use the internal service name:
+If the LDAP client runs on the same Docker network as Theta Directory (for
+example, the bundled `theta-suite` stack), use the internal service name:
 
 ```
 ldaps://sso-manager:636

docs/sso/oauth.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: OAuth / OIDC
-description: SSO Manager's OpenID Connect / OAuth 2.0 provider — discovery document, client registration, and token endpoints.
+description: Theta Directory's OpenID Connect / OAuth 2.0 provider — discovery document, client registration, and token endpoints.
 ---
 
 # OAuth 2.0 / OpenID Connect
@@ -12,7 +12,7 @@ description: SSO Manager's OpenID Connect / OAuth 2.0 provider — discovery doc
 > of endpoint-level detail? See
 > [Connecting Apps (Single Sign-On)](concepts-oauth-apps.html).
 
-SSO Manager is an **OpenID Connect / OAuth 2.0 provider**: it issues its own
+Theta Directory is an **OpenID Connect / OAuth 2.0 provider**: it issues its own
 access, refresh, and ID tokens that your apps can consume to authenticate
 users and authorize API calls. It also runs a full OpenLDAP directory, so it
 can be both your SSO and your user directory at once.

docs/sso/replication.md

@@ -5,7 +5,7 @@ title: Geo-Location Scaling (Replication)
 
 # Geo-Location Scaling (Replication)
 
-SSO Manager is built to be a self-contained identity provider, but if you have multiple physical sites, you may want a local copy of the directory at each site to ensure low latency and high availability.
+Theta Directory bundles its own identity provider, but if you have multiple physical sites, you may want a local copy of the directory at each site to ensure low latency and high availability.
 
 ## Why and when to use this?
 - **High Availability (HA)**: If your primary site goes completely offline, your other sites can still authenticate users locally without depending on a WAN link.

docs/sso/vault.md

@@ -6,9 +6,9 @@ nav_order: 6
 
 # Secrets Vault
 
-SSO Manager integrates natively with **OpenBao** (a Vault fork) to securely manage and store sensitive data, configuration, and API keys.
+Theta Directory integrates natively with **OpenBao** (a Vault fork) to securely manage and store sensitive data, configuration, and API keys.
 
-The Vault proxy endpoint is exposed directly through SSO Manager at `/api/vault/v1/`, which safely authenticates and authorizes requests before forwarding them to the internal OpenBao container.
+The Vault proxy endpoint is exposed directly through Theta Directory at `/api/vault/v1/`, which safely authenticates and authorizes requests before forwarding them to the internal OpenBao container.
 
 ## Architecture
 
@@ -18,10 +18,10 @@ When the environment is initialized via `setup.sh`, OpenBao is automatically uns
 
 ## Accessing the Vault
 
-The SSO Manager Vault can be accessed in two ways:
+The Theta Directory Vault can be accessed in two ways:
 
-1. **Via the SSO Manager UI**: Go to the **Admin Configuration** page (`/conf`) to edit the application's configuration secrets directly. SMTP and OAuth settings are edited through structured form fields (not a raw JSON blob) and saved to OpenBao at `secret/sso-manager/conf` at runtime, taking effect immediately. Secret fields — the SMTP password and the OAuth JWT secret — are returned masked (`********`); leave the field unchanged (or blank) to keep the stored value, or enter a new value to replace it.
-2. **Via the REST API**: Send requests to `/api/vault/v1/...` with your SSO Manager session or API Token.
+1. **Via the Theta Directory UI**: Go to the **Admin Configuration** page (`/conf`) to edit the application's configuration secrets directly. SMTP and OAuth settings are edited through structured form fields (not a raw JSON blob) and saved to OpenBao at `secret/sso-manager/conf` at runtime, taking effect immediately. Secret fields — the SMTP password and the OAuth JWT secret — are returned masked (`********`); leave the field unchanged (or blank) to keep the stored value, or enter a new value to replace it.
+2. **Via the REST API**: Send requests to `/api/vault/v1/...` with your Theta Directory session or API Token.
 
 ### API Example
 
@@ -32,14 +32,14 @@ Only administrators with `app_sso_admin` or `admin` permissions can query the va
 
 ## Namespaces and Paths
 
-Currently, secrets are maintained at `/v1/secret/data/sso-manager/conf` using the `kv-v2` backend. When configurations are edited via the admin UI, SSO Manager performs a deep-merge so that partial updates don't overwrite unrelated keys (such as SMTP vs OAuth configurations).
+Currently, secrets are maintained at `/v1/secret/data/sso-manager/conf` using the `kv-v2` backend. When configurations are edited via the admin UI, Theta Directory performs a deep-merge so that partial updates don't overwrite unrelated keys (such as SMTP vs OAuth configurations).
 
 ## Plugin Integration
 
 Plugin instances store their per-instance secrets in OpenBao at
 `secret/plugins/<instance-id>/conf` (configured, loaded/unloaded, and run from
 the **Plugins** page — see [Plugins](plugins.html)). The plugin process runs
-in-process, so the SSO Manager reads/writes those secrets server-side through
+in-process, so Theta Directory reads/writes those secrets server-side through
 the `sso-broker` token; the admin UI only ever sees masked values, and external
 apps can retrieve API tokens via the `/api/vault` proxy to keep permissions
 consistently enforced instead of hardcoding them.