Challenge 1: Choose Stages for Two Triggers — Possible Solution
====================================================================

(a) Pull request trigger
    -> Build + Test (no Deploy)

    Per this chapter's own trigger table: "Pull request: Build + test
    only — nothing is merged yet, so nothing deploys." The code hasn't
    actually landed on any branch that would be released, so there's
    nothing meaningful to deploy — the purpose of running the pipeline
    here is purely to VERIFY the proposed change (does it build, do the
    tests still pass) before a human decides whether to merge it.

(b) Push to main trigger
    -> Build + Test + Deploy

    Per the same table: "Push to main: Build + test + deploy — a merge
    has actually happened." At this point the code is genuinely part of
    the project's main history, which is exactly the trigger this
    chapter describes as warranting the full pipeline including the
    deploy stage.

THE ONE KEY DIFFERENCE
--------------------------
The presence (or absence) of the DEPLOY stage. Both triggers reasonably
run identical build and test stages — verifying the code is exactly as
important either way — but only the push-to-main trigger includes
deploy, because only at that point has the code actually reached a
state (merged into main) where shipping it makes sense. Running deploy
on every PR would be nonsensical: PRs get opened, updated, and
sometimes abandoned entirely, none of which should ever result in
something actually reaching users.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly mirrors the chapter's own reasoning: different triggers
represent fundamentally different MOMENTS in a change's lifecycle (a
proposed, unmerged change vs an accepted, merged one), and the stages
that make sense to run should reflect that difference — verification
makes sense at both moments, but shipping only makes sense once the
change has actually been accepted into the codebase.