feat: pending group_role domains (#106), Bereiche + security levels as managed resources (#108/#110), commentViewer refs (#102), and an audit that can see past OpenAPI (#111)

docs/README.md

@@ -48,9 +48,9 @@ A page with no code behaviour to track declares `sources: []` plus a
 
 ## Everything else — developer- and operator-facing, unpublished
 
-| Page                                                     | About                                                                 |
-| -------------------------------------------------------- | --------------------------------------------------------------------- |
-| [`api-coverage.md`](api-coverage.md)                     | Which ChurchTools endpoints support which CRUD verbs                  |
-| [`group-field-decisions.md`](group-field-decisions.md)   | Which group fields are managed vs. left to the CT UI, and why         |
-| [`runbook-manual-surface.md`](runbook-manual-surface.md) | What `ct` cannot automate — API gaps and the manual steps around them |
-| `superpowers/`                                           | Historical implementation plans; kept as a record, never published    |
+| Page                                                     | About                                                                                             |
+| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
+| [`api-coverage.md`](api-coverage.md)                     | Which ChurchTools endpoints support which CRUD verbs                                              |
+| [`group-field-decisions.md`](group-field-decisions.md)   | Which group fields are managed vs. left to the CT UI, and why                                     |
+| [`runbook-manual-surface.md`](runbook-manual-surface.md) | What `ct` cannot automate today — where the write path is missing, and the manual steps around it |
+| `superpowers/`                                           | Historical implementation plans; kept as a record, never published                                |

docs/handbuch/blueprints.md

@@ -4,7 +4,7 @@ sources:
   - src/config/context.ts
   - src/engine/graph.ts
   - src/engine/hierarchy.ts
-sources_hash: 0124644b70452450
+sources_hash: bbadf1a728820f5c
 reviewed: 2026-08-13
 ---
 

docs/handbuch/field-definitions.md

@@ -3,7 +3,7 @@ title: Field definitions & security levels
 sources:
   - src/commands/get.ts
   - src/api/ctClient.ts
-sources_hash: 16a6283b7ce1d982
+sources_hash: 047a27a2bd82b120
 reviewed: 2026-08-13
 ---
 
@@ -40,16 +40,25 @@ _definitions only_; none of them read or write a per-record field value.
 
 ```bash
 ct get person-masterdata   # the person master-data model incl. the security-level enumeration
+ct get security-levels     # just the security levels, as a flat list
 ct get data-fields         # all data-field definitions (person + group), one row per field
 ```
 
 - `ct get person-masterdata` → `GET /person/masterdata`. A single object (not a
   paged list) — the versionable person master-data model. It carries the
   security-level enumeration (`securityLevels`), which is the model the churchdb
   permission scopes reference (`cc_securitylevel`; see [`permissions.md`](permissions.md)).
-  This is where **security levels** are surfaced — ChurchTools has no dedicated
-  standalone security-levels REST resource; the Persons/Groups master-data module
-  is where they are defined, and `/person/masterdata` is its download.
+- `ct get security-levels` → `GET /securitylevels` (#110). The same levels as a
+  flat `[{id, name, sortKey}]` list — the catalog a
+  `scope: [{ securityLevel: "<name-slug>" }]` reference resolves against. (An
+  earlier version of this page said no standalone security-levels resource
+  existed; it does, live-verified 2026-08-13 on CT 3.135.2.) Reading it per host
+  is also how you check whether the usual ids `1..4` really hold there — they are
+  editable master-data rows, not protocol constants. **Security levels are the
+  one item on this page that is _not_ read-only in ChurchTools:**
+  `/securitylevels/{id}` takes `POST`/`PATCH`/`DELETE` (probed 2026-08-14), and
+  since #110 they are a **managed resource** — `ct.securityLevel({ key, id, name })`,
+  `ct adopt security-level <id>`. See [`permissions.md`](permissions.md).
 - `ct get data-fields` → `GET /dbfields` (auto-paginated). The **unified**
   data-field definition catalog. Person master-data fields **and** group custom
   fields live in the same list, discriminated per-row by `fieldCategory`
@@ -100,13 +109,20 @@ out of bounds. If a future CT release adds REST write endpoints on `/dbfields`
 resource then — add a `src/resources/registry.ts` entry + DSL + tests — and move
 the row out of the read-only section here and in the runbook.
 
+Note that "never write the legacy surface" is a **decision**, not a capability
+limit, and [#109](https://github.com/eqrm/ct-cli/issues/109) reopens it for the
+master-data registry specifically (a self-describing set of editable tables the
+admin UI writes through `saveMasterData`). If that lands, this paragraph needs
+re-deciding rather than merely re-reading.
+
 ## Endpoint reference
 
-| Purpose                                    | Path                                                                           | Methods (this CT) | `ct` surface               |
-| ------------------------------------------ | ------------------------------------------------------------------------------ | ----------------- | -------------------------- |
-| Person master-data model + security levels | `/person/masterdata`                                                           | GET (read-only)   | `ct get person-masterdata` |
-| Data-field definitions (person + group)    | `/dbfields`, `/dbfields/{id}`                                                  | GET (read-only)   | `ct get data-fields`       |
-| Field-definition **mutation**              | legacy `churchdb` AJAX (`db_insertfields`/`db_updatefields`/`db_deletefields`) | non-REST          | **not managed — manual**   |
+| Purpose                                    | Path                                                                           | Methods (this CT)                       | `ct` surface                                        |
+| ------------------------------------------ | ------------------------------------------------------------------------------ | --------------------------------------- | --------------------------------------------------- |
+| Person master-data model + security levels | `/person/masterdata`                                                           | GET (read-only)                         | `ct get person-masterdata`                          |
+| Security levels, standalone                | `/securitylevels`, `/securitylevels/{id}`                                      | GET; POST/PATCH/DELETE on the item path | `ct get security-levels`, `ct.securityLevel` (#110) |
+| Data-field definitions (person + group)    | `/dbfields`, `/dbfields/{id}`                                                  | GET (read-only)                         | `ct get data-fields`                                |
+| Field-definition **mutation**              | legacy `churchdb` AJAX (`db_insertfields`/`db_updatefields`/`db_deletefields`) | non-REST                                | **not managed — manual**                            |
 
 All paths verified against public CT client libraries + CT Academy docs, **not**
 against this repo's (git-ignored, ungenerated) `src/api/schema.d.ts`.