Silent duplicate IDs caused a correct-looking failure three steps from the source

A work-tracking register allowed a second entry to be created with an already-existing ID, because the uniqueness rule was documented in prose but never enforced in code. When the system processed a landing command, it acted on the older row sharing that ID, leaving the newer one stranded without any error being raised. The fault only surfaced later when an unrelated operation was blocked by a conflict check that was technically accurate against the register but incorrect about real-world project state. The author argues that ID uniqueness must be checked at the point of insertion and across all row states, not just open ones, since state-filtered uniqueness is not true uniqueness. A constraint enforced only by memory and convention will fail silently, and when it does, the visible symptom will point nowhere near the actual cause.