Challenge 3: Why "What's the Ctrl+S Equivalent?" Is the Wrong Question — Solution Walkthrough

Why the question is based on a mental model that doesn't quite apply:

Ctrl+S exists in Word because Word's own document lives primarily as
a local file that only becomes durably stored the moment you
explicitly commit it — the whole reason Ctrl+S matters so much is that
there's a real risk of losing unsaved work between commits. Google
Docs has no equivalent risk to protect against in the first place:
there's no separate "unsaved" state sitting only in the browser,
waiting for a save command, because every keystroke is already synced
continuously to the one live copy on Google's own servers. Asking "what's
the Ctrl+S equivalent" assumes a save-then-commit cycle that simply
isn't how the underlying system works here.

What actually protects their work instead:

The continuous, automatic sync itself — the same behaviour demonstrated
in Exercise 1, where closing a tab immediately after typing lost
nothing at all. There's no keyboard shortcut to teach them because
there's no manual step to replace; the protection already happened by
the time they finished typing each word. (Chapter 4's own Version
History, covered later in this course, adds a further safety net on
top of this — the ability to browse and restore earlier states — but
that's a different, additional feature, not the answer to "how do I
avoid losing unsaved work" in the first place.)

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise tests whether the colleague's underlying assumption —
"there must be an unsaved state I need to manually commit, the way
there always has been" — was correctly identified and addressed,
rather than just supplying a technically-true but conceptually
misleading answer like "there isn't one, don't worry about it."