Challenge 2: Decide What Belongs in CI — Possible Solution
====================================================================

SHOULD RUN IN CI:

- Postman collection via Newman — this is specifically designed to run
  headlessly, with no Postman application UI needed at all, and
  produces a pass/fail exit code CI can gate on directly (Chapter 4).
- cURL scripts — plain shell commands run identically whether typed by
  a human or executed by a CI runner; nothing about them requires
  interactivity.

SHOULD NOT RUN IN CI:

- Browser-based testing (fetch()/Network tab/forms) — this fundamentally
  requires an actual browser rendering an actual page with a human (or
  at minimum a full browser-automation tool, which is a different thing
  entirely) driving it. A CI runner has no open browser tab to paste a
  fetch() call into, and "Copy as cURL" requires a human to have first
  triggered and inspected a real request in DevTools. This tool's value
  is specifically in manual, interactive exploration and verification —
  not something meant to run unattended on every commit.
- The VS Code .http file itself, similarly, is edited and triggered by
  a developer in an editor — while its underlying HTTP calls COULD be
  extracted and re-run by another tool, the file format and "Send
  Request" CodeLens are an editor-integrated, human-facing workflow,
  not a CI-runnable artifact on their own.

THE PRINCIPLE: this maps directly onto Chapter 1's manual-vs-automated
distinction — tools that were always about repeatable, scriptable
execution (Postman via Newman, cURL) belong in CI; tools that were
always about a human directly interacting with a live browser session
don't, no matter how useful they are for day-to-day debugging.