symfonic.capabilities.memory.write_stages¶
write_stages ¶
The handlers behind the write and finalize stages.
Lifted out of :mod:symfonic.capabilities.memory.capability so that module
stays inside the 300-line budget. They are one concept -- what happens to a
turn's records after the model answered -- and the capability declares the
stages while these answer them.
The pairing is not decoration. write stages a record as pending, and
:class:MemoryWritePort's own contract says a pending memory is not
retrievable until flush. So a deployment that ran the first and not the
second recorded into a void: the turn answered, rows accumulated, and nothing
could ever be recalled. TA8.71 is the task that found exactly that shipped.
consolidation_handler ¶
Extract semantic/profile candidates once, after the final model round.
A failed extraction never fails the turn. By the time this runs the
model has answered and the user is owed that answer; a handler that raised
would end the turn (require_no_crashed_stage) and throw away a correct
response because a side effect could not complete. So an operational
failure is reported as a no-change carrying its reason, which is the same
channel the stage trace publishes -- degraded and observable, rather
than degraded and silent.
The two cases stay apart. NOTHING_TO_KEEP means the extractor ran and
found nothing; EXTRACTION_DEGRADED means it could not run. Collapsing
them is how "memory stopped working" reads as "nobody said anything
memorable" for as long as it takes someone to notice.
Source code in src/symfonic/capabilities/memory/write_stages.py
lifecycle_handler ¶
Publish what this turn staged, for this turn's scope only.
Source code in src/symfonic/capabilities/memory/write_stages.py
write_handler ¶
File what the round produced, under the turn's own scope.