cadrumo.application.user_profile.lifecycle module¶

The sole application writer for committed profile-capsule lifecycle actions.

class ProfileCapsuleLifecycle(*, root=None)[source]¶

Bases: object

Create, restore, select and delete through the custody transaction owner.

The service never builds capsule paths, scans buckets, writes manifests, or handles KDF/recovery state. Its only presentation write is the label projection, which is made visible exclusively after custody commit validation.

Parameters:: root (Path | None)

property root: Path¶: Return the committed profile storage root.

create(*, label, password_envelope, sentinel, data_files, initial_record, record_session, profile_id=None)[source]¶

Create and publish a new profile capsule.

Core types: UserProfileRecord.

Return type:

CommittedProfileView

Parameters:

label (str)
password_envelope (ProfileCustodyEnvelopePort)
sentinel (ProfileCustodySentinelPort)
data_files (Mapping[str, bytes])
initial_record (UserProfileRecord)
record_session (ProfileRecordSession)
profile_id (UUID | None)

restore(*, label, password_envelope, sentinel, data_files, record_session, database_bytes, authority)[source]¶

Publish one restored capsule under a named, proven restore authority.

authority records which door proved the key. It is required and has no default so a restore that does not say what authorised it cannot be audited afterwards. The door proves the DEK before reaching here; it neither mints, rotates, nor replaces a key schedule, and it never installs a recovery wrapper: a restored profile enrolls recovery again explicitly if the operator wants it.

The material agreement below is checked at the primitive rather than trusted from the door, and the reason is asymmetric cost. Publishing a capsule whose password envelope unwraps a key the staged database was not encrypted under produces a profile that authenticates and then decrypts nothing – and it does so silently, at the one moment the operator believes their records were rescued. Proving the session’s key against the committed sentinel is cheap; the failure it prevents is unrecoverable.

Return type:

CommittedProfileView

Parameters:

label (str)
password_envelope (ProfileCustodyEnvelopePort)
sentinel (ProfileCustodySentinelPort)
data_files (Mapping[str, bytes])
record_session (ProfileRecordSession)
database_bytes (bytes)
authority (ProfileRestoreAuthority)

select(value)[source]¶

Select an existing profile as active.

Return type:: CommittedProfileView
Parameters:: value (str)

prepare_delete(*, profile_id, retention_override=None, requires_inactive_target=False)[source]¶

Prepare one local deletion, carrying any operator retention authorisation.

The override is forwarded rather than interpreted here: the custody capability owns the hold decision, and a second opinion at this layer would be a place for the two to disagree.

Return type:

ProfileCustodyTransactionJournal

Parameters: