Пісочниця: пояснити нуль в аудиті й додати пробу, яка щось доводить

«журнал аудиту 0 → 0 ok» читалось як доказ роботи журналу. Насправді
установник робить рівно три речі, і всі три — у переліку сліпих зон
(store.AuditBlindSpots): власник, строки зберігання, локальний зонд. Дані
пісочниця наливає прямим SQL, повз API. Нуль тут очікуваний.

Пробу лишено (покаже, якщо колись почнуть писати), але поруч тепер
сказано, що правило min на нулі не доводить нічого. І додано пробу, яка
доводить: спроби входу — самоперевірка заходить у продукт, порожня
таблиця означала б, що записування входів відвалилось.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

netpulse

@@ -2902,6 +2902,20 @@ SQL
 # звуження вона потрапила б у ті самі лічильники. Алерти рахуються по
 # ДВОХ таблицях одразу — фоновий такт переносить погашені в
 # alr.alerts_history, і рядок, що переїхав, це не втрачений рядок.
+# ЧОМУ «журнал аудиту» тут ЗАВЖДИ НУЛЬ, і це не поломка.
+#
+# Установник робить рівно три речі, і всі три — у переліку сліпих зон
+# журналу (store.AuditBlindSpots): заводить власника (склад команди),
+# ставить строки зберігання й підключає локальний зонд (дії системи).
+# Дані пісочниця наливає прямим SQL, повз API. Тобто нуль — очікуваний
+# результат, а не ознака, що аудит зламався.
+#
+# Проба лишена навмисно: якщо колись хтось почне писати аудит на
+# установці, рядок це покаже. Але читати «0 → 0 ok» як доказ роботи
+# журналу не можна — правило min на нулі не доводить нічого.
+#
+# А от «спроби входу» — доводять: самоперевірка заходить у продукт, і
+# порожня таблиця тут означала б, що записування входів відвалилось.
 sandbox_up_probes() {
   cat <<'EOF'
 хости_пісочниці|exact|SELECT count(*) FROM inv.devices WHERE name LIKE 'sb-sw-%'
@@ -2921,6 +2935,7 @@ sandbox_up_probes() {
 типи_перевірок|min|SELECT count(*) FROM core.check_types
 права|min|SELECT count(*) FROM core.permissions
 журнал_аудиту|min|SELECT count(*) FROM core.audit_log
+спроби_входу|min|SELECT count(*) FROM core.login_attempts
 EOF
 }