Module path 

The stored shape of an operator-configured local filesystem path.

02-target-architecture.md, “Path validation”, splits validation into two layers “so opening the database never depends on current filesystem availability”. This module is the pure layer and nothing else: it decides whether a string is a shape the product is willing to persist, and it does so with no syscall, no probe, and no ambient state. The operational layer — local filesystem identity, writability, canonical containment, overlap with AppPaths — belongs to b1 in crates/platform, runs before a mutation is committed, and is explicitly not run by database load.

Two properties follow from being pure, and both are load-bearing:

1. A corrupt row is refused at load. LocalAbsolutePath is the only way to hold a configured path, so a hand-edited \\nas\builds in SQLite fails closed in the domain rather than becoming a runner root on a network share (D10).
2. The rules are testable off their own platform. Every decision here is taken against an explicit PathPlatform, so the Windows UNC, device, drive-relative and reserved-name cases are covered by a Linux CI leg and the Unix cases by a Windows one. LocalAbsolutePath::new is the native-only entry point that database load, the CLI and the TUI use; LocalAbsolutePath::parse_for is the seam the tests use.

What this module deliberately does not do is resolve ... Lexically collapsing a/../b is wrong in the presence of a symlink, and this layer is forbidden from asking the filesystem which one it has, so a traversal component is rejected outright (LocalPathError::Traversal) rather than normalised away. A . component carries no such ambiguity and is dropped.

Structs

LocalAbsolutePath

An absolute, non-root, normalised local path, validated without touching the filesystem.

Enums

LocalPathError

Why a string is not a storable local absolute path.

PathPlatform

Which platform’s path syntax a string is judged against.