Exercise 1: A New Timestamp Style in an Existing Log — Possible Solution
====================================================================

WHAT COULD GO WRONG
------------------------------
Per this chapter, "an application's log file is often already being
read by other tools - dashboards, alerting rules, or simply a
colleague's own habitual grep commands. Writing a new line into it
that doesn't match the existing format (different timestamp style,
missing the usual level tag, fields in a different order) can silently
break every one of those downstream consumers." A dashboard or
alerting rule that parses the log expecting one specific timestamp
format will likely fail to correctly parse - or simply ignore - a line
using a different format, even though a human reading the file would
have no trouble understanding it.

WHY "STILL READABLE TO A HUMAN" DOESN'T MEAN "STILL SAFE"
------------------------------
Per this chapter, the risk specifically described is to automated
downstream consumers (dashboards, alerting rules), not to human
readability. A person can adapt to reading a slightly different
timestamp format on the fly; a parser built to expect one exact format
generally cannot, and may fail silently rather than with an obvious
error - meaning the breakage might not be noticed until something that
depended on it (like an alert) fails to fire.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies which specific consumers of the log (automated
tools, not human readers) are put at risk by a format inconsistency,
and correctly explains why the new line "still being readable" doesn't
address that risk at all.