What problem does it solve? Burning per-device keys into STM32 Soldier/Queen nodes at manufacture involves a fragile multi-step pipeline — silicon UID to DID derivation, wrong-board detection, HKDF key derivation, Flash block writes, and audit logging — where any mistake bricks the device or silently diverges keys between backend and silicon. ## Core Features & Use Cases - One-pass UID-to-DID derivation: Converts the 24-hex silicon UID into a wire DID via a single frozen function shared by factory and field provisioning, with collision detection routing units to quarantine. - Wrong-board guard and supervisor gate: Reads the board UID over SWD before any key write and refuses to run unless the provisioning session is supervisor-approved (2-Person Rule). - Six Flash key blocks with audit trail: Writes KEYL, LSED, KEYC, EDSK, KOTA, and KEYB blocks matching firmware addresses, then records a chain-hashed audit log inside one database transaction. - Use Case: When factory:flash raises a CollisionError or a backend DID does not match the silicon, use this Skill to trace the TreeResolver and UidReadout logic and diagnose whether it is a birthday collision, wrong chip, or endianness bug. ## Quick Start Ask the assistant to explain why factory:flash raised a CollisionError for a specific silicon UID and walk through the flashing session steps in order.
