Module random_id 

Random identifiers in the layout of the incumbent’s randomUUID. What: Random identifiers in the layout of the incumbent’s randomUUID: lock tokens and the unique names of worktree-copy and auto-push scratch files, and the check for that layout. Why: A lock token must be unguessable and unique per acquisition, and the startup step recognizes the directories an earlier release named with a transaction ID in the same canonical layout (is_canonical_uuid, startup_gate.rs).

In TS you’d write (pseudocode):

import { randomUUID } from 'node:crypto'; const token = randomUUID();

Structs

RandomSourceError

What: Why no identifier could be made: the operating system’s random source failed. Why: Without randomness no unguessable token exists, so the caller must stop.

Functions

format_uuid_v4

What: Format 16 bytes as a version-4 UUID in canonical lowercase layout. [u8; 16] is a fixed array of sixteen bytes. Why: RFC 9562 version 4: the version nibble is 4 and the variant bits are 10, exactly what randomUUID produces; the formatting is pure so tests can fix the input.

is_canonical_uuid

What: Whether a name is exactly one canonical lowercase UUID, as randomUUID prints it. Why: The scratch directories of a commit are named by such an identifier, and a path is recognized as one of them only by that layout.

random_uuid

What: A fresh random version-4 UUID from the operating system’s source. Result<String, RandomSourceError> is “the identifier, or why not”. Why: Tokens and transaction IDs must not be predictable or collide between processes.