Exercise 1: Why notesapp.service Uses Both Wants= and After= — Possible Solution
====================================================================

Explanation:

This directly applies systemd1-4's own central lesson, which this
chapter explicitly names as "the concrete payoff of that chapter's
whole warning." Wants= and After= control two genuinely separate
axes: Wants= controls WHETHER network-online.target actually gets
started at all, while After= controls only the ORDER, with zero effect
on whether anything starts.

If notesapp.service used only After=network-online.target, per
systemd1-4's own core warning, there would be no guarantee that
network-online.target ever actually starts as a result of
notesapp.service being started -- After= alone only says "if
network-online.target is going to start anyway, for some other
reason, start after it." If nothing else on the system happened to
independently want network-online.target, notesapp could start with
no functioning network at all, silently -- a genuinely serious problem
for a network-facing service like notesapp, which needs real
connectivity to actually function.

By including Wants=network-online.target alongside After=
network-online.target, notesapp.service genuinely guarantees BOTH
that the network target actually gets started (via Wants=) AND that
it starts in the correct order relative to notesapp itself (via
After=) -- exactly the "real, common pattern" systemd1-4 names for
any unit that has a genuine dependency it also needs correctly
ordered, rather than a dependency-free ordering preference.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly reuses systemd1-4's own central axis distinction
(whether vs. when) and explains the specific real-world risk of using
only After= for a network-dependent app, rather than treating the
paired lines as boilerplate without justification.