Step 5 re-audit. Both were verified live earlier this session but
never shown - the strategy breakdown backs the doc's own headline
stat directly, and the mariadb-latest entry proves the specific
shared-mirror mechanism rather than just describing it.
Live-checked docker_stacks.yml directly. Total/dockerfile-strategy
counts (41/36) and the pinned_manual holdouts were already accurate.
But docker-socket-proxy and kodi's mariadb service were wrongly listed
as still hitting Docker Hub directly - both actually float a :latest
pull against a dedicated in-fleet mirror stack (docker-socket-proxy-
mirror, mariadb-latest) built via the normal dockerfile pattern. Fixed
the table and documented the real mechanism. Same gap existed in the
KB note, fixed there too.
Live-verified the container_update role's strategy_dockerfile.yml
task file exists at the exact path the KB names, stamped the source
note. Replaced the mermaid cheap-check flowchart with a real
branch-shaped Nextcloud diagram. Added: the real Vault-backed push
auth mechanism (Gitea PAT -> Vault Agent -> docker login
--password-stdin, same pattern as everywhere else in the fleet), the
real docker manifest inspect command instead of a vague "digest
check", real app names in the holdouts table instead of generic
descriptions (matching how the rest of this repo already names real
apps), the anonymous-volume-pruning detail, and a real (redacted)
screenshot of the actual Gitea package registry showing genuine
self-built container images.
Same treatment as the security batch - real tech names, 'why this vs
the alternative' reasoning, heavy cross-linking, ranked/specific
tradeoffs instead of generic hedges.
Completes the orchestration/registry/content batch - Kestra's
check-pause-approve-apply pattern, the self-hosted build pipeline,
the SOC dashboard's 14-source aggregation, the cron heatmap, and the
in-progress content pipeline, all in the diagram+callout+table style.
thesabear