VERIFYFIRST // log-output
Logs and stdout — You read the output and it looked normal.

WHAT IT CAPTURES
  What the program chose to say about itself, in the branches that say anything.

WHAT IT CANNOT SEE
  - Silent branches, which by construction produce no line to read.
  - Failures attributed to the wrong actor, where the reported victim is not the cause.
  - Anything killed before it could flush a buffer.

KNOWN FAILURES (3)

  NS-011  The OOM killer names the fattest process, not the one that leaked
    reads as   A long-running session dies mid-task. The log records that session being killed. Conclusion drawn: that session was the problem.
    actually   A different process had leaked for hours — 193 browser instances spawned by automation and never closed, 27 still resident. The OOM killer selects by current footprint, so it shot the largest process, which was an unrelated session whose context had simply grown. The leak and the casualty were different processes.
    check      Rank every process by RSS at the time of death, not just the one named: ps -eo rss,comm --sort=-rss | head -20, and count instances of anything spawned in a loop. A single fat process is a victim; a hundred medium ones are the cause.

  NS-028  A rotated log leaves the daemon writing to a file that no longer has a name
    reads as   app.log exists, is zero bytes, and gains no lines. Conclusion drawn: the service is idle, or has stopped working.
    actually   logrotate renamed or removed the file the process had open. The process still holds the old inode and keeps appending to it. The logrotate man page names the case in its description of copytruncate: it exists for programs that cannot be told to close their logfile and thus might continue writing to the previous log file forever.
    check      Ask the process which file it is writing to: `ls -l /proc/$(pidof app)/fd | grep -i log`. A healthy process points at the live path; a stranded one points at a path marked `(deleted)`.

  NS-029  Python discards records below WARNING when no logging is configured
    reads as   A script instrumented with logger.info() at every step produces no output at all. Conclusion drawn: the code path never ran.
    actually   With no configuration, the root logger has no handlers and the internal last-resort handler is set at WARNING. INFO and DEBUG records are created and then dropped; WARNING and above go to stderr. The code ran, and said so, into nothing.
    check      `logging.getLogger(__name__).isEnabledFor(logging.INFO)` — False while records are being dropped, True once a handler and level are configured. Observed on 3.12: root handlers `[]`, lastResort `<_StderrHandler <stderr> (WARNING)>`, isEnabledFor(INFO) False.

---
Full registry: https://verifyfirst.dev/registry.json
This page:     https://verifyfirst.dev/log-output/
CC0-1.0. Every entry observed, none hypothetical.