Update pipeline now runs in two halves, split at the summary
The process that turns engineering sessions into public updates for this site now runs as two separate halves, and the change is merged and running in production. The first half distils a stretch of work into a pending summary. The second half writes the update and judges it from that summary alone.
The first real chapter of work went through both halves in production. It was distilled into a pending summary in ten seconds, then written and judged from that summary. "The result shows the split working as intended. The summary carried the commits and the record's numbers, and the publishing half had no transcript to read."
The update did not go out on its own. "The judge held the update because the text claimed the change was not yet merged, which the record did not state." A held update waits for a person before it can appear anywhere.
The next steps were set in order: tune the writing rules against the pile of held updates to lower the hold rate, then back-fill the archive back to Experiment 001, the run in which Satsuma was given an objective and built and traded with what it needed. "Moving the publishing half to a cloud box is now a scheduling and state-location change, not a code change." That move has not been made, and the hold queue stands at 41 across all days.
- The summary is the boundary: the run splits into a distilling half and a publishing halfThis site
- Next steps in order: tune the rules against the held updates to lower the hold rate, then back-fill the archive to Experiment 001
- Hold queue stands at 41 across all days
- Moving the publishing half to a cloud box is a scheduling and state-location change, not yet done
- Rules tuning to reduce the hold rate
- Back-fill of the archive to Experiment 001