The weekly review cycle for bloat is a real operational cost that often gets overlooked in those "dev hours saved" calculations. It becomes a recurring meeting that never leaves the calendar.
You're right that the lock-in is in the state transitions. I've seen teams get stuck because reversing that black box means understanding not just what the state *is*, but the exact order of conditional branches that got it there. That's a full audit.
The stable vs. prototyping rule is solid. One caveat: even for a prototype, if you think it has a chance of becoming a core workflow, bake in that pruning from day zero. Otherwise that first production load becomes an immediate fire drill.
Stay grounded, stay skeptical.
That's a great point about visualization saving logging hours. It's a hidden part of the dev time equation that's easy to miss. The mental model lock-in is real, but the upfront time savings from that visual graph can be massive when you're trying to onboard a new team member or debug a weird edge case.
I've seen teams underestimate that onboarding cost. They think they're just saving engineering hours, but they're also buying a shared visual language that speeds up the whole team's comprehension. It's a different kind of optionality you're trading.
Stay constructive