Challenge 1: Add a Wait Timer to a Production Deploy — Possible Solution
====================================================================

WHAT A 10-MINUTE WAIT TIMER CHANGES ABOUT THE DEPLOYMENT FLOW
--------------------------------------------------------------------
With a wait timer configured on the production environment, once the
deploy-production job becomes eligible to run (after deploy-staging
succeeds, per the needs: deploy-staging dependency), GitHub Actions
does NOT start executing the job's steps immediately. Instead, the job
enters a waiting state for the configured duration — 10 minutes in this
case — and only actually begins running ./deploy.sh production once
that full wait period has elapsed.

WHY THIS IS USEFUL
--------------------
This chapter describes the wait timer's purpose as giving "time to
notice and cancel a bad merge." Concretely: if a developer merges a
change to main that turns out to be broken in some way not caught by
automated tests (perhaps something only visible once staging has been
running it for a few minutes — an unexpected memory leak, a slow
resource exhaustion issue, or simply a team member noticing something
wrong after the fact), the 10-minute window gives a real opportunity
for someone to notice the problem and manually CANCEL the pending
production deployment before it actually happens — something that
would be impossible if production deployment started immediately, with
no delay at all, the moment staging succeeded.

HOW THIS INTERACTS WITH THE EXISTING REQUIRED-REVIEWER RULE
------------------------------------------------------------------
Note this is a SEPARATE, ADDITIONAL layer of protection from the
required-reviewer rule already configured on this chapter's
deploy-production job — a wait timer doesn't require a human to take
any explicit action at all (no one has to click "approve"); it simply
introduces automatic, passive delay. A team could use BOTH a wait timer
AND required reviewers together: the wait timer creates a window during
which a problem might be noticed passively, while required reviewers
still require someone to actively approve the deploy regardless of how
much time has passed.

WHY THIS WORKS AS AN ANSWER
------------------------------
This demonstrates that GitHub Environments' protection rules aren't a
single all-or-nothing setting — they're a set of INDEPENDENT,
COMBINABLE mechanisms (reviewers, branch restrictions, wait timers),
each addressing a slightly different risk. A wait timer specifically
addresses "give time for something to surface" risk, distinct from
required reviewers' "require explicit, informed human judgment" risk.