---
id: OPEN-QUESTIONS
type: note
status: active
title: Open Questions
created: '2026-09-09'
updated: '2026-09-09'
tags:
- requirements
- open-questions
related:
- SCAN-20260909
- ALERT-20260909-001
- ALERT-20260909-002
source_paths:
- AGENTS.md
- README.md
- inventory/group_vars/external.yml
confidence: confirmed
---

# Open Questions

Reconciliation state after the 2026-09-09 scan (workflow: Open Questions
Reconciliation). Anchors are stable; statuses follow the schema
(`open`, `partially-resolved`, `resolved`, ...).

<a id="oq-001"></a>

## OQ-001 - Who are the stakeholders/owners of this repository?

Status: partially-resolved
Updated: 2026-09-09
Related: [SCAN-20260909]

Resolution (partial): Operators appear to be "Niklas" and "Dennis"
(SSH key comments in `roles/bootstrap/defaults/main.yml`,
`confidence: inferred`). Formal ownership and roles remain undocumented.

Remaining question: Who formally owns and operates the playbooks, and who
approves changes?

<a id="oq-002"></a>

## OQ-002 - What are the explicit success criteria?

Status: partially-resolved
Updated: 2026-09-09
Related: [SCAN-20260909], MOD-005

Resolution (partial): For update runs, success is defined by the
`healthcheck` quality gate (all Docker containers running; fails the play
only when `healthcheck_fail_on_unhealthy` is true). No success criteria for
the overall project are documented.

Remaining question: What defines success beyond a passing update-run gate?

<a id="oq-003"></a>

## OQ-003 - Is `AGENTS.md`/`README.md` stale regarding `inventory/dmc12.yml`?

Status: resolved
Updated: 2026-09-09
Related: [ALERT-20260909-002], SCAN-20260909

Resolution: Yes. Git status shows `D inventory/dmc12.yml` (uncommitted) and
untracked `inventory/cloudlorean.yml`; `dmc12` is now a Proxmox host inside
the `cloudlorean` site. `README.md` (inventory table, examples) and
`AGENTS.md` still reference `dmc12.yml`. Documentation updates and the
commit of the rename are tracked in ALERT-20260909-002.

<a id="oq-004"></a>

## OQ-004 - Is the external site's Zabbix passive server correct?

Status: open
Created: 2026-09-09
Related: [SCAN-20260909], MOD-003

`inventory/group_vars/external.yml` sets
`monitoring_zabbix_passive_servers: ["2a01:4f8:1c1e:62dd::1"]`, which is the
`healthcheck` host's own address. Is a Zabbix server/proxy intentionally
running on that host, or is this a misconfiguration? (`confidence: unknown`)

<a id="oq-005"></a>

## OQ-005 - Which Docker template name exists on the Zabbix server?

Status: open
Created: 2026-09-09
Related: [SCAN-20260909], MOD-003

Role default `monitoring_zabbix_docker_templates: ["Docker by Zabbix agent2"]`
(no space) vs group_vars `["Docker by Zabbix agent 2"]` (with space). One of
the two will fail host linking at registration. Which name does the Zabbix
server actually use? (`confidence: unknown`)

<a id="oq-006"></a>

## OQ-006 - Is the committed `admin_password` hash intended or a policy violation?

Status: resolved
Updated: 2026-09-09
Related: [ALERT-20260909-001], NFR-002

Resolution: Policy violation. Decrypting `vault.yml` during the alert
resolution confirmed it did not define `admin_password` (no override); the
hash existed only as plaintext in role defaults and group_vars. Resolved with
[ALERT-20260909-001]: hash moved into encrypted `vault.yml`, plaintext copies
removed, `bootstrap.yml` loads the vault via `vars_files`.