Decode: workarounds, and when to hold your ground

The last lesson is about the review itself, because the meta-goal here isn't just fixing comments, it's not needing them, and knowing which ones to push back on.

The highest-leverage note (Mustafa, #508, recurring):

"a not-yet-idiomatic foundation is worked around rather than fixed, and the workaround compounds."

Concretely, on the notes PR: a load-then-mutate-then-catch-unique-violation loop guarded a race that the model created. Mustafa's point was that the defensive machinery (catch, retry, ChangeTracker.Clear()) was a smell masking a data-loss footgun, and the real fix was a better model (append-only rows), which made the whole race, and the machinery guarding it, disappear.

"As a foundation, Notes should be immutable rows in their own table ... makes handling things like concurrency or updates easier."

What it means. This is the single habit that removes most review comments before they're written: when you find yourself building defensive machinery, question the model first. A retry loop, a catch-and-clobber, a frozen-key latch, a nullable threaded downstream, these are usually smells pointing at an aggregate, value object, immutability, or layering choice that isn't idiomatic yet. Fix the foundation and the workarounds never need to exist.

Now the other side, because it matters just as much.

Rai holding the line (Mustafa asked for a semantic design token; Rai declined, #508):

"introducing a one-off semantic token for a single component ahead of [the design-system unification] is premature abstraction, so I would rather hold."

The reviewer accepted. And Mustafa's own over-DRY note cut the same way:

"LoadTrackedRow: extracting a one-line query used a few times into its own method is over-DRY (adds indirection for no reuse benefit)."

What it means. Receiving review is a technical conversation, not a chain of command. The move is: verify the principle against the compiler and the codebase, then either fix it (because they were right) or hold with a stated reason (because you are). Blind compliance and blanket refusal are both failures. DRY is "don't duplicate knowledge," not "never repeat a line," and an abstraction should earn itself with a real second use before you build it. Rai already does this well; the course's job is to make the instinct arrive at design time.