Skip to main content

Module lifecycle

Module lifecycle 

Source
Expand description

The profile lifecycle: materializing and deleting what an adapter owns for a profile (SP5a design §3).

Like config::link and config::unlink, the logic is a pure function over the application root that returns an outcome value; the CLI layer renders it and decides the exit code.

Structs§

Listing
What list and profiles show (SP5a design §3): one row per valid profile directory, plus the count of entries that were skipped as unrecognized.

Enums§

CreateOutcome
What create did (SP5a design §3).
DeleteOutcome
What delete did (SP5a design §3).
Presence
What <agent> status and the status document report for a profile (SP3 design §7.5).

Functions§

blocking_label 🔒
Text for one blocking reference: the stored key for a repository-wide profile field, the stored key with the agent table for an agents.<id> field, and the literal default_profile for the global default (SP5a design §3).
blocking_references
Every mapping field and the global default that names profile for agent, ignoring ASCII case, in the order the mapping fields are read and with default_profile last. An empty result means nothing stands in the way of deleting the profile’s directory for agent.
create
Ensures the paths adapter owns for profile under root exactly once: an already materialized profile is left untouched, so a user’s hand-edited configuration file is never overwritten. The returned path is the first of the adapter’s paths, the profile directory; the function is the same kind of pure, outcome-returning function as config::link.
delete
Removes the profile directory for agent under the same exclusive lock link and update take (spec §18), re-checking delete_target and blocking_references inside it: the advisory checks outside the lock can be seconds stale, and a deletion that never leaves a mapping or the global default pointing at nothing is the invariant this function exists to hold (SP5a design §3).
delete_target
The profile directory delete would remove: <root>/profiles/<P>/<agent>, shown to the user un-canonicalized (SP5a design §3). None when nothing is there. Error::ProfileReferenced is not consulted here; blocking_references is the caller’s advisory or locked check.
list_profiles
Reads what exists on disk, human-readable: each valid profile directory under <root>/profiles becomes a row naming every adapter that is materialized for it, in adapters order. Purely read-only: nothing is created, and a missing profiles directory is simply an empty listing.
presence
The presence of profile for agent; a case-only twin is reported before the adapter is asked.
symlink_refusal 🔒
The refusal for a symlinked entry, with the fixed message the tests anchor on.
symlinked 🔒
Whether the entry at path is itself a symlink (or, on Windows, a junction). Ok(false) when the entry is missing, so the caller’s symlink check never fires on NotFound.
unrecognized_children 🔒
The number of child directories of a listed profile directory that are not known agent ids: each one is an unrecognized entry and the caller’s ignored grows by one per child. A child file is never counted — only child directories can be unrecognized — and a child entry whose name starts with . is skipped without counting, mirroring the profiles-directory rule: the same OS litter (*.swp, .DS_Store) must behave the same one level deeper.