Exercise 3: Why This Capstone Isn't an Ansible Playbook — Possible Solution
====================================================================

Honest answer:

This chapter's own scope note addresses this directly, explaining that
this capstone is "deliberately not what ansible1's own capstone did,
since GRUB's own configuration isn't really automatable the same way
service configuration is." The real distinction is about what kind of
work is actually involved at each step. ansible1's own capstone
(automating ws1's web server hardening) worked specifically because
that task -- installing packages, deploying config files, restarting
services -- is fundamentally about REPEATABLE, IDEMPOTENT state
changes on an already-running, already-installed operating system:
exactly the shape of problem Ansible's own modules are built to check
and converge toward.

Building a triple-boot environment is a genuinely different kind of
task. It involves creating partitions on a disk that doesn't have them
yet, running interactive installers for three separate, entirely
different operating systems (Windows, Fedora, Debian) each with their
own installation process, and deliberately reproducing a real firmware-
level failure through manual boot-order manipulation -- none of which
maps cleanly onto Ansible's own "check current state, converge toward
desired state" model. There's no meaningful sense in which "install
Windows" is an idempotent task the way "ensure this package is
installed" is; it's a one-time, largely interactive, cross-OS process
that doesn't have a natural playbook shape.

So the honest answer isn't "nobody's gotten around to writing it yet"
-- it's that this particular kind of task (multi-OS installation and
low-level partition/firmware work) is a genuinely poor fit for the
automation approach that worked well for ws1's own configuration
management, which is exactly why this capstone was built as a manual,
hands-on lab exercise instead.

WHY THIS WORKS AS AN ANSWER
------------------------------
This gives an honest, reasoned answer rather than deflecting, explaining
the real structural reason (idempotent config management vs. one-time
interactive multi-OS installation) rather than just citing "the chapter
said so," and explicitly contrasts this task against what actually made
ansible1's own capstone a good fit for automation.