Stable callable identity
UIDs are optional by default (uid.policy defaults to allowed), and Nuky can analyze code without them. When present, UIDs provide stable callable identity across renames, moves, and refactors, so diffs track the same entity before hash-based comparisons.
With UID vs Without UID
| Without UID | With UID |
|---|---|
| Identity is derived from names and structure. | Identity is pinned to the UID. |
| Formatting-only changes keep hashes stable. | Formatting-only changes keep hashes stable. |
| Logic hash changes → behavior change (if identity is stable). | Logic hash changes → behavior change. |
| Renames change identity (contract change). | Renames preserve identity. |
| Moves can change identity. | Moves keep identity stable. |
| Signature changes update the API hash (contract change). | Signature changes update the API hash (contract change). |
| Refactors can change identity if names or locations shift. | Refactors preserve identity when UIDs stay stable. |
| Long-lived logic can drift as identities change. | Long-lived logic stays anchored to a stable UID. |
| UID policy controls missing UID handling (allowed/disabled). | UID policy can enforce required UIDs in CI. |
When to use UID
UIDs are an explicit governance tool. Use them when you want stable callable identity across refactors and renames, especially in long-lived code paths.
Inject UIDs
Start with a dry run to see what will be injected, then apply for real. The injector is built into the main binary and should be run explicitly on paths.
- 0: Success
- 2: Validation error (invalid, missing, or duplicate UID)
- 3: Filesystem or IO error