Exercise 1: Why "The App Is Broken" Fails Even With the Same Bug — Possible Solution
====================================================================

WHAT THE BAD TICKET IS MISSING
------------------------------
Per this chapter, a good ticket includes "steps to reproduce, expected
vs. actual behavior, scope, exact timestamp, correlation ID or exact
error text, environment." "The app is broken, please fix ASAP"
contains none of these six elements - it doesn't say what was clicked,
what should have happened, who's affected, when it happened, or any
identifying error information.

WHY THIS COSTS REAL TIME EVEN WITH AN IDENTICAL BUG
------------------------------
Per this chapter, "a well-written ticket essentially pre-loads the
evidence this whole subject's technical courses spend entire chapters
teaching you how to gather. A poorly-written one means the first thing
whoever picks it up has to do is go re-derive information the reporter
already had in front of them." The underlying bug being identical
doesn't help, because none of the information needed to actually start
diagnosing it (per this course's earlier technical courses) is present
in the ticket at all - whoever picks it up has to first track down the
reporter and re-ask every one of these questions before any real
diagnosis can begin.

WHAT THE GOOD VERSION PROVIDES INSTEAD
------------------------------
Per this chapter's own good-ticket example, the rewritten version
includes an exact timestamp and a correlation ID (request_id:
a1b2c3d4) - per this chapter, this "hands them a correlation ID and a
specific timestamp ready to grep directly," letting the investigation
start immediately rather than after a round of clarifying questions.

WHY THIS WORKS AS AN ANSWER
------------------------------
It identifies specifically which of the chapter's own six core
elements are missing from the bad ticket, and explains the concrete
time cost this creates regardless of the underlying bug being
identical in both versions.