Exercise 2: Why Cleanup Is a Separate oneshot Service, Not Built Into notesapp — Possible Solution
====================================================================

Explanation:

Per systemd1-7's own core reasoning for the .timer/.service split, "the
'what' (a real, independently-runnable systemd service) [is] cleanly
separated from the 'when.'" Making notesapp-cleanup its own separate
Type=oneshot service, rather than folding the cleanup logic somehow
into notesapp.service's own ExecStart=, preserves this exact
separation and its real practical benefits, applied specifically to
this capstone's own app.

First, testability: per systemd1-7's own opening point, the standalone
cleanup service can be run directly at any time with systemctl start
notesapp-cleanup, completely independent of whatever schedule the
paired timer defines -- genuinely useful for verifying the cleanup
logic works correctly before ever trusting it to run unattended at
3am. If cleanup logic were somehow baked into notesapp.service's own
long-running process instead, there would be no equivalent way to
trigger just the cleanup step in isolation for testing.

Second, correctness of Type=. notesapp.service is Type=simple -- a
long-running process that IS the service, per systemd1-3's own
definition. The cleanup task is fundamentally a run-once-and-exit
operation, exactly matching systemd1-3's own Type=oneshot definition,
not a long-running daemon at all. Mixing these two fundamentally
different shapes of work into one unit would misrepresent what
"started" and "finished" mean for each piece to systemd itself.

Third, independent scheduling and restart behavior: the cleanup job
needs its own OnCalendar=daily schedule via a dedicated timer, and its
own success/failure tracked separately from notesapp's own uptime and
Restart=on-failure behavior -- keeping them as separate units means a
cleanup failure doesn't affect notesapp's own running status, and vice
versa.

WHY THIS WORKS AS AN ANSWER
------------------------------
This gives three distinct, concrete reasons (testability, Type=
correctness, independent scheduling/failure tracking) grounded
directly in systemd1-3's and systemd1-7's own stated material, rather
than a single vague "it's cleaner this way."