"An edit is a new version, not a mutation"

This lesson follows directly from the last. Once the flight note became a value object (Lesson 1), a chain of consequences fell out, and Mustafa walked you through them across several threads on #508.

The first consequence hit the domain object's surface. You had a mutable Body property and an UpdateBody(...) method. The comment:

This is Module 1, Lesson 3 again: value objects are immutable. A value object has no identity, so the idea of "changing" one is incoherent, there's no persistent thing to change, only values to replace. A mutable setter or an UpdateBody() on a value object is a category error. If a user "edits" a note, that's not a mutation of the existing note, it's a new note that replaces the old one in the reader's view.

That drove the whole persistence strategy. The framing comment tied it together:

And it even reshaped "clear a note." Your instinct was a hard delete when the body was empty. The reviewer's:

Clearing is a fact that happened, so you record it (append an empty-body row) rather than erasing history with a DELETE. Under append-only, nothing is ever destroyed; every state the note was ever in is preserved by construction.

Here's the part worth internalising, because it's how you spot good modelling. Watch how one decision satisfied a requirement that looked unrelated. You classified the note as a value object for identity reasons. Value objects are immutable. Immutable things must be persisted append-only. And append-only persistence is an audit trail: every version is kept, for free. The auditing epic's requirement got satisfied not by building an audit feature, but as a side effect of getting the domain classification right.

The next lesson is the concurrency bug this dissolved, and it's the clearest example in your whole review history of "the model choice created the problem, and a better model deleted it."