cadrumo.application.user_profile.fact_write module

Shared profile-fact write door.

The interactive wizard, the config profile manager screens and the capability and descendiente verbs all publish exact profile-fact replacements through one shared writer, and each names itself with one closed ProfileFactWriteDoor member. The door is a payload descriptor, never an event type: every write emits exactly one PROFILE_VALUES_UPDATED bucket event, and the surface identity travels beside the change in the event payload.

class ProfileFactWriteDoor(*values)[source]

Bases: StrEnum

Which operator surface published a profile-fact change.

The door is a payload descriptor, never an event type. A profile-fact write emits exactly one bucket event, that event’s id becomes the record row’s lineage witness, and the event names the DATA CHANGE: PROFILE_VALUES_UPDATED. Which operator surface collected the answers is a separate axis, so it travels beside the change rather than displacing its identity — a history query asking “when did these values last change” reads the event type, and one asking “which surface changed them” reads this key.

Encoding the door in the event type instead is what broke the edit path: every wizard write stamped a surface-shaped string that the closed BucketEventType does not contain, and the capsule writer refused the whole command rather than recording anything.

The taxonomy spans every surface that writes profile facts, not only the wizard: the command-line manager screens and the config profile verbs publish through this same writer, so their identities belong in the same closed set rather than in a second one beside it. CLI_DESCENDIENTE is deliberately distinct from DESCENDANTS – the interactive wizard’s repeating group and the non-interactive descendiente verbs are two surfaces an operator can tell apart, and a history query asking which of them last rewrote the set would be unable to answer if they shared one value.

ANSWERS
PATCH
DESCENDANTS
MANAGER_FIELD
MANAGER_ROW
CLI_CAPACIDAD
CLI_DESCENDIENTE
apply_profile_fact_changes(*, profile_id, changes, door, expected_record=None, profile_decode_context)[source]

Publish an exact fact replacement through the active session.

The writer never touches an aggregate or a generic profile row. It loads the authenticated current record, replaces only the paths the validated command names, and asks the record repository to CAS-publish the complete resulting sequence with one command event. A value=None change is retained deliberately: it is the explicit current-record representation of clearing an answer.

This is not the only door onto profile facts – registration opens the initial record and the cotejo censal adopts certificate values – so what is shared is not the door but the JUDGE: every one of them refuses through reject_invalid_profile_facts() before publishing. An engine-derived path, an unknown path and a value of the wrong shape are refused at whichever write reaches them rather than at the surface that happened to collect the answer: a check living only in the manager’s edit dialog binds nobody who writes through the wizard, the CLI or a later surface, and a stored value at a derived path silently displaces the computation that owns it.

Every door publishes the same lifecycle event – the write IS a profile value change, whichever surface collected it – and distinguishes itself through door in the event payload. See ProfileFactWriteDoor for why the surface identity cannot live in the event type.

Return type:

UserProfileRecord

Returns:

The published UserProfileRecord carrying the replacement.

Parameters:
apply_manager_profile_field_mutation(*, profile_id, path, value, profile_decode_context)[source]

Apply the manager’s one-field trim-or-clear policy through the sole write door.

Return type:

UserProfileRecord

Parameters: