The instance layout reference now says which directories the spec library scan skips. Below the built-in specs, $OPENRIG_HOME/specs and the legacy library, it skips any directory named .git, .worktrees, node_modules, dist, build, .turbo or .next (SKIP_DIRS in spec-library-service.ts), so a spec such as specs/build/rig.yaml isn't listed and nothing says why. To list it, rename its directory and run rig specs sync; rig specs add keeps a directory's own name, so it doesn't help for a directory named build, and rig up with a path to the rig.yaml still launches it without the library. Text only; the scan itself is unchanged. Reported in #2333 by @EZotoff.
Settings writes from the CLI config store and the daemon settings store keep the existing file usable when an update fails partway. Each store stages the new content beside the target and renames it into place, preserving owner, group and mode, so a failed staged write or rename (including ENOSPC or EIO) leaves the original byte-identical. An existing target is first opened for writing without truncation, so a read-only settings file is refused as before. Where the directory doesn't allow temporary entries, ownership, mode or rename (EACCES, EPERM, EBUSY), the update falls back to writing in place, as before, with that path's existing partial-write limit. instance-layout.md describes the behaviour, including that a hard-linked second name keeps referring to the previous file after an atomic replace.