Clarify pipeline operator membership documentation

This commit is contained in:
2026-09-15 15:00:37 +00:00
parent 608d5be9aa
commit b15fe8dcf5

View File

@@ -198,8 +198,9 @@ inspection shows enabled sources, inferred dependencies, and generated family
members; the diff shows the overlay's profile selections without modifying
managed files.
API keys, Notarius enablement, storage and publishing, operator access,
scheduling, and end-to-end external execution remain deferred.
API keys, Notarius enablement, storage and publishing, operator selection and
group-membership management, scheduling, and end-to-end external execution
remain deferred.
### Shared execution filesystem
@@ -208,12 +209,17 @@ scheduling, and end-to-end external execution remain deferred.
default ACLs retain owner and group write access plus world read/traverse access
for newly created content. The pipeline may run as `narratio` or as a human
account already in the selected runtime group; the production role neither
selects people nor manages their group membership. For example, a consumer can
manage its own operator membership separately:
selects people nor manages their group membership. For example, a consumer
play can manage its selected operator separately:
```yaml
operator_group_members:
- "{{ pipeline_operator }}"
- name: Add the selected operator to the pipeline group
become: true
ansible.builtin.user:
name: "{{ pipeline_operator }}"
groups:
- "{{ dnd_pipeline_runtime_group }}"
append: true
```
Configuration, transcripts, caches, generated artifacts, campaign data,