cadrumo.application.storage_management.service module

Read and reclaim operations over the declared storage tree.

Answers “where is my data”, “does the tree on disk match its declaration”, and “what may safely be deleted” from the one typed declaration in STORAGE_TAXONOMY, so no answer here can drift from the resolver every writer already uses.

Nothing in this module moves data or relocates the root. Reporting where the tree is and naming the variable that points at it is cheap and reversible; copying an encrypted store is neither, and a copy that succeeds for the records while failing for the key material that opens them is unrecoverable.

See also

storage_path()

The resolver every row is built from.

ensure_storage_tree()

The materialiser init delegates to rather than re-implementing.

RECLAIMABLE_LIFECYCLES: Final[frozenset[StorageLifecycle]]

Declared lifecycle classes whose contents reclaim may delete.

The complement is UNBOUNDED_BY_DESIGN, which is the encrypted substrate, the key material, the audit trail, and the durable filing outputs. Those are not caches that grew too large; their growth is the record. Deriving the permitted set from the declared axis rather than listing categories means a member reclassified in the taxonomy changes what reclaim will touch at the same moment, with no second list to forget.

storage_lifecycle_permits_reclaim(lifecycle)[source]

Return whether lifecycle declares contents a reclaim may delete.

Return type:

bool

Parameters:

lifecycle (StorageLifecycle)

collect_storage_area_inventory(*, settings=None)[source]

Aggregate the internal declaration into the four stable public areas.

Return type:

StorageAreaInventoryReport

Parameters:

settings (Settings | None)

inspect_storage_tree(*, settings=None)[source]

Report where the materialised tree disagrees with its declaration.

Read-only by contract: it names missing directories, nodes whose kind contradicts the declared StorageNodeKind, and root permission drift, and repairs none of them. init is the verb that acts.

Only members the settings actually resolve are checked. A member whose opt-in field is unset names a location the operator has not asked for, and reporting it missing would turn every unused affordance into a finding.

Two of these findings are unreachable from the CLI, and the reason is worth stating rather than leaving to be rediscovered. The command line materialises the declared tree during bootstrap, so by the time a command body runs a missing directory has been created and a directory occupied by a file has already been refused there, naming the same path this would have named. Both findings remain reachable in-process, and the ones the CLI genuinely leaves to this function are a directory sitting where a file-valued member’s leaf belongs – the materialiser creates that member’s parent and deliberately not its leaf – and root permission drift.

Return type:

StorageTreeCheckReport

Parameters:

settings (Settings | None)

materialise_storage_tree(*, settings=None)[source]

Create every declared directory, preserving whatever already exists.

Delegates to ensure_storage_tree() rather than walking the taxonomy again, so the operator verb and the runtime bootstrap cannot materialise different trees. It never removes and recreates a directory to reach a clean state: the tree holds the encrypted substrate, and “clean” would mean deleting it.

Return type:

StorageInitReport

Parameters:

settings (Settings | None)

reclaim_storage_area(area, *, confirmed=False, settings=None)[source]

Reclaim all safe roots in area after one complete preflight.

Selection, lifecycle admission, scope admission, and containment are all derived from the taxonomy. No target is touched until every target passes.

Return type:

StorageReclaimReport

Parameters: