That reads like the same pain from higher up, yeah. It's the org forgetting instead of the person, but same essence. I've seen hints of this myself, and I have found no tractable solutions other than packing up and leaving when the winds change direction in high management. Thanks for sharing.
I'm with you on the usage half: it's planning's job, and analytics/A-B play an important part there.
But I think we're talking past the point that a lot of what you learn building something never show up in any dashboard, because it isn't about what users did, it's what you worked out in the code. That "oh, this whole subsystem quietly assumes X, and the thing I'm adding will break that" moment. By default it lives in the heads of whoever worked on the code and I think is often gone by the next cycle.
I didn't mean to get into who should own what, but I'm trying to ask: the last time you had an insight you felt should be considered next time, did you have a place to put it? Do thoughts like that reach planning, or just dissolve?
I like the "check it into the tree" instinct. I've tried tracking observations and lessons in README files across a monorepo, but I felt they went stale almost immediately. Maybe your more focused files would work better. But checked in or not: have you found yourself reopening those earlier notes when you start the next feature? Or do they mostly just sit there?
The framing of preconditions that dissolve a class of mistakes is intriguing. I keep re-reading it, trying to picture how it actually exists day to day: is it something you run in your head when you're in the code, or is it structured into something your team shares (e.g. a checklist or similar)? I haven't had much success closing that gap.