Exercise 1: Severity Triage — A Help Page Typo vs. Total Checkout Failure — Possible Solution
====================================================================

The help page typo would be triaged as LOW SEVERITY (e.g. Sev4/P4).
The checkout failure would be triaged as the HIGHEST SEVERITY (e.g.
Sev1/P1), requiring immediate, all-hands response.

The dimensions driving this difference, per the chapter's own
framework (impact-based, not raw technical severity):

1. HOW MANY USERS ARE AFFECTED. The help page is described as
   "rarely-visited" -- a small fraction of users would even encounter
   the typo. Checkout failing affects 100% of customers attempting to
   complete a purchase -- essentially the entire active customer base
   trying to transact.

2. IS THERE A WORKAROUND AVAILABLE. A typo has no meaningful
   functional impact at all -- there's nothing to "work around"
   because nothing is actually broken functionally. A broken checkout
   has NO workaround for the affected users -- they simply cannot
   complete their purchase through any available means.

3. IS REVENUE AT RISK. The typo has no revenue impact whatsoever. A
   100%-broken checkout directly stops ALL revenue generation for as
   long as it remains broken -- a direct, ongoing, and quantifiable
   business impact.

4. IS DATA AT RISK. Neither scenario as described suggests a data risk
   specifically, so this dimension doesn't differentiate the two here
   -- but it's worth noting as a dimension that WOULD matter if either
   incident involved exposed or corrupted customer data.

Critically, this is NOT simply "one is obviously worse" as a vague
impression -- it's a structured comparison across the SPECIFIC
dimensions the chapter names (users affected, workaround availability,
revenue/SLA risk, data risk), each of which independently favors
treating checkout failure as far more severe. Notably, the underlying
CODE CHANGE that caused either issue could plausibly have been
similarly small in both cases (a one-line typo fix vs. a one-line bug
in checkout logic) -- severity triage is about IMPACT, not the size or
complexity of the technical change involved.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explicitly walks through each dimension the chapter names rather
than asserting "checkout is worse" as an unexamined conclusion --
directly addressing the exercise's own instruction not to just say
"one is obviously worse," and reinforcing the chapter's core point that
severity is about IMPACT dimensions, independent of how technically
complex or simple the underlying fix might turn out to be.