docs: group naming matches docs/GROUPS.md; roll up sso v1.27.0 (v1.37.0)

- GROUPS.md: per-resource groups are {site}_{kind}_{name}_{level}; site carries god + site-wide only
- gitlink: sso-manager-node e8d0420 (v1.27.0)

CHANGELOG.md

@@ -8,6 +8,12 @@ orchestration code; see each submodule's own `CHANGELOG.md`
 [sso-manager-node](https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md))
 for what changed inside the apps it composes.
 
+## [v1.37.0] - 2026-08-04
+
+### Changed
+- **Group naming corrected to match docs/GROUPS.md** — per-resource groups are `{site}_{kind}_{name}_{level}` (kind always present; a host `host_theta-env` → `site_local_host_theta-env_access`, a service → `site_local_app_sso-manager_access`). The spec's §3 text was updated to state this explicitly.
+- **Roll up sso v1.27.0** — group names match the docs, a site carries only god + site-wide groups, duplicate group links removed, `/api/agent/*` no longer 404s, shared-secrets POST/GET fixed, Vault Apps tab lists minted tokens, discovery promote + plugin run logs fixed. See the [sso changelog](https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md).
+
 ## [v1.36.1] - 2026-08-04
 
 ### Fixed

docs/GROUPS.md

@@ -76,17 +76,15 @@ enumerated as LDAP members, and cannot be used as Unix groups.
 
 - The **structural delimiter is `_`**. It appears only between the fixed segments
   of a group name.
-- **The `S` site segment is the site resource's slug verbatim.** In the SSO
+- **The `S` site segment is the site resource's slug verbatim** (`site_local`),
-  Directory, site/host resource slugs carry a kind prefix (`site_local`,
+  NOT re-slugified (which would corrupt the delimiter: `site_local` → `site-local`).
-  `host_theta-env`); the group builders keep them verbatim rather than
+- **Per-resource groups are `{S}_{kind}_{name}_{level}`.** `kind` is `host` or
-  re-slugifying (which would corrupt the delimiter: `site_local` → `site-local`)
+  `app`; `name` is the resource's **name slug with the kind prefix stripped** — a
-  or inserting a separate kind segment. So a host resource `host_theta-env` under
+  host resource `host_theta-env` has name `theta-env`, so its groups are
-  site `site_local` yields `site_local_host_theta-env_access` (the `host_` is part
+  `site_local_host_theta-env_access` / `_admin`. A service (the group model's
-  of the resource slug), and the site's own admin group is `site_local_super_admin`.
+  `app`, docs §11) `sso-manager` gives `site_local_app_sso-manager_access`. The
-  Services are stored without a prefix, giving `site_local_sso-manager_access`.
+  kind segment is always present, which is what makes a resource's name
-  The kind (`host`/`app`) is used only to pick the **aggregate** the resource's
+  unambiguous even if a host and a service share a name.
-  group nests into (`{site}_hosts_*` / `{site}_apps_*`), not the resource's own
-  group name.
 - **Within a segment, normalize to lowercase** — spaces and stray `_` → `-`; strip
   other non-`[a-z0-9-]`. A host named `Web 01` and a site `Main Office` (resource
   slugs `host_web-01` and `site_main-office`) yield groups `site_main-office_host_web-01_*`.
@@ -150,7 +148,9 @@ def effective(resource, level_or_cap, site):
     if level_or_cap in ("admin","access"):
         agg = f"{site}_{resource.kind}s_{level_or_cap}"
         if user in agg:                      return True
-    specific = f"{site}_{resource.slug}_{level_or_cap}"   # slug carries its kind
+    # resource.name is the resource's name slug (kind prefix stripped); the kind
+    # is its own segment. A host `host_theta-env` has name `theta-env`, kind `host`.
+    specific = f"{site}_{resource.kind}_{resource.name}_{level_or_cap}"
     if user in specific:                     return True
     if level_or_cap == "access":             return effective(resource, "admin", site)
     if level_or_cap == "admin":              return False          # access does not imply admin