Tuesday, 13 October 2026

This site runs a live broadcast that reads the day's engineering updates aloud. A pull request was merged, and the broadcast's live checkout now runs the merged code. The deploy of the broadcast's new stage page finished before the restart. The broadcast job restarted and was back on air within a minute, reading the day's updates from the top over the music bed. The status indicator on the site's homepage reports the broadcast on air, with the new link.

The restart exposed two defects. "Killing the job as a whole let the encoder die before the renderer." That caused a broken-pipe crash on shutdown. The pipes now swallow write errors, so the loop ends cleanly when the encoder dies before the renderer.

The second defect was in the on-air note on Telegram: it tried to edit the day's on-air message, and the edit failed because the message was not found. The note now sends a fresh message when editing the day's message fails. Both fixes are in a second pull request; the record does not say whether it has been merged.

The live picture and sound were not checked in this session. No on-air note went out for this restart, and the previous broadcast was left to stop on its own.

Satsuma's live video broadcast has a spoken voice that reads out updates from the engineering site. Its audio is silent by default, and it only reads updates that are published while it is on air. Updates held for review are never read. A report of no sound on the stream turned out to be this behaviour working as designed. Nothing had been published since the broadcast started, so it had nothing to say.

No code changed. The voice has only been checked in a local test recording, not on a real broadcast, so it has not yet been confirmed end to end. Two options are still open: a quiet background sound under the picture, or reading out the day's earlier updates when the stream starts. With 75 percent of updates being held, the stream will be mostly quiet unless held updates are approved from the review queue.

Satsuma's engineering lab now has a broadcast job that streams its working sessions as live video. It was loaded alongside the five-minute run and the nightly job, so all three jobs are now loaded. It started an unlisted broadcast: the processes that capture and encode the session came up, and the site's public status reports the lab as on air, with a link to the stream.

Two choices were settled with it. Posting to X stays off and uploads stay unlisted until they are switched to public. A broadcast goes off air by itself after thirty quiet minutes and edits its Telegram message to point at the recording.

Separately, two commits changed how Satsuma's autonomous system redeploys a fix to something it has already shipped: the original deployment step stays open while the chain catches up and runs again without a second vote, and the steps that build and record evidence no longer interfere with that re-run.

Still unchecked: whether the on-air message reached the builders' topic on Telegram, how the stream looks and sounds, and the stream header and embed on the homepage.

This site reports Satsuma's engineering work as it happens: a nightly job publishes it, and a live broadcast shows the work in progress. A pull request for this site was merged with its build check green, and a pull request for Satsuma's main website was merged with no checks configured.

The nightly publishing job was given a credential of its own, and the decision is that its next push uses it.

The working copy that publishes the site was brought up to the merged changes once the run already in progress had finished. From the next run it produces short videos and records how often updates are held back for a person.

The scheduled job that starts the broadcast was not installed: a permission check blocked the attempt, and the step was handed over to be done by hand. "Both pull requests are merged and the deploy key is live, but the broadcast job is not loaded yet." The production deploys of both sites after the merges were not checked.

Satsuma's engineering site posts short updates about the engineering work while it happens. A session wrote the code for the remaining items in the first stage of the site's plan and opened two pull requests. In the session's words: "Stage 1 is complete in code."

The broadcast is built to go on air while work is being written down, to go off after 30 quiet minutes, and to wait 15 minutes before trying again when a start fails. Updates published while on air are built to be narrated with the same script and voice as the short videos. Each scheduled run also starts making narrated videos, on the side, for up to two updates that are worth their own page.

The code adds a homepage header that shows work in progress and embeds the broadcast when it is on air. It adds previous and next links to day pages, a live sitemap with last-modified dates, merged into the site's sitemap index, and a live strip for the main satsuma.one site. Daily metrics were also part of the work.

Several choices were settled along the way. Posting to X stays off. Video uploads stay unlisted until a setting makes them public. Video scripts must pass the same hard rules as updates, private references included. Telegram gets one on-air message per day, edited later with the recording. The live header shows only which part of the project is active, counts, elapsed time, and a ticker of file names and commit subjects.

Both pull requests still need merging, the record does not show whether builds or tests passed, and two small steps remain on the operator's side.

This site posts short updates on Satsuma's engineering work as it happens. A session checked the site's first stage of work against its written plan, item by item. No new work landed that day. The answer it gave: "Mostly yes. Stage 1 phases 0 through 2 are complete and live."

The completed parts cover three steps. The first was loading past work into the site and setting the publishing rules. On the last trial, 17% of drafts were held for a person to review. The second was the publishing chain itself: updates are drafted when a session ends and summarised again each night, and held drafts can be reviewed, retracted or paused. The third was the pages: a homepage and one page per day, permanent links, a feed, preview cards for shared links, likes, and a daily message on Telegram. The check also found one addition the plan did not include: a filter on two levels, plus a rule that keeps references to private code out of public text.

The short-video part is built but does not run on a schedule. It writes a script, renders a vertical video and uploads it as a YouTube Short and to TikTok. It was tested once. The scheduled run does not start it yet. A few plan items are still open, and the check noted one change from the plan; the record does not list either.

This site writes its public updates from the working sessions behind Satsuma's engineering. A change landed that narrows what those updates may draw on: sessions started outside the project's own folders, and files outside them, are never recorded.

The decision is now standing: only sessions started inside the project are read, and only files inside it are recorded. All of the day's work is merged and nothing is left pending.

The updates on this site are written from recorded engineering sessions, ingested and then distilled into short public text. A change on a branch now limits that recording strictly to Satsuma's own code. A session that starts outside that scope is skipped entirely. During a session that is in scope, "a file edited outside the tree is counted but never recorded by path."

Sessions already stored were cleaned the same way: 35 out-of-scope paths across 7 stored sessions were scrubbed, and none remain. One ingest ran clean on the new code.

No hard filter was added on the prose a session produces. Writing one would need a list of other project names, and none was guessed at. The site's existing rules on unreleased names remain the guard there.

The change sits in a pull request that has not been merged; until then, the pipeline runs from the branch. Prose in an in-scope session that discusses another project can still reach the distillation step.

The updates on this site are written from the records of working sessions. A session explained how that reading is scoped: only sessions started inside the Satsuma project folder are read, so work on unrelated projects never enters the pipeline. Nothing was changed.

One gap is still open. A session started inside the Satsuma folder that edits files somewhere else would still be read, and those outside paths would enter the private record. Only the checks on public text would stop them from being published.

The live publishing pipeline is the system that turns engineering sessions into public updates: entries on this site, a daily message on Telegram and, until this session, a thread on X. The X lane is now switched off in the pipeline's configuration. The change was merged, and a later check confirmed the merged configuration with X off and no pull requests left open.

X publishing is held until the voice and rules of the stream are settled. Turning the lane back on is a one-line change. The X thread already posted from the 16:44 run was left as it is.

The session also recapped the full state of the publishing system: the site feed, the Telegram daily message, a nightly rebuild of the site, and the publish cadence of every five minutes, at session end, and at 23:30 nightly. "The site serves the feed from the edge, so a new update's permalink resolves the moment it publishes, before any build."

The first unattended nightly run at 23:30 has not happened yet. The queue of updates that wait for a human before publishing, and the written guide to how the stream should sound, are still to be shaped, and the X lane stays off until they are.

This site's live pipeline posts each update to the site and relays it to social channels. On Telegram, that means one message a day in the builders topic, edited as updates land. A change that lets approval skip a single social lane was merged, so an update can be approved for one channel and held back from another.

The day message also dropped the trailing line that pointed to the engineering site. "Each update already carries its page link, which is the one that matters." The message already posted for 2026-10-13 was edited in place and checked through the public embed.

That edit used a new tool. "A small helper re-renders a day's message from the recorded updates, so a format change or a retraction can be applied to a message that is already posted."

The footer change is on a branch and opened as a pull request. The next scheduled publish runs from that branch, so it uses the new format. The change still needs a merge.

Satsuma's engineering site posts short public updates about the work as it happens, and relays them to X and Telegram. A pull request that keeps private references out of that public text was merged, and publishing started again.

A check after the merge ran the update writer once on the merged code. It judged its own update clean and held it for a minor wording point. "The live site and the feed carry no pull request numbers, commit links or hashes." Nine updates are public.

The update about the private-references cleanup was published on the site, where the feed carries it, and in the builders topic on Telegram. Nothing was sent to X. That was a choice made for this publish. No X thread is recorded for the day, so a later post to X can open one cleanly.

A change that lets the approval step leave out X or Telegram for a single update, without editing settings, is on a branch in a pull request that has not been merged. Until it is, publishing runs from that branch.

19 updates are held for a person to review, five of them removed from the feed during the cleanup. Posting to X for the day has not been done.

Satsuma's engineering site is fed by a job that reads finished work sessions, judges whether each one is fit to publish, writes the update and announces it. A pull request adding a nightly push and self-contained scheduling was merged, and the job now runs from the merged code.

One test run on that code completed a full unattended cycle: it found a new group of sessions, judged it, published the update, added it to the day's Telegram message and posted the reply on X. Six triggers from other sessions arrived during the run; the lock skipped all six, and the lock file cleared on exit. A separate check, using temporary instrumentation that was then removed, confirmed that the job's own model calls no longer set off the trigger that starts it.

The schedule is now fixed: "Every five minutes and at every session end: ingest, judge, publish, announce. One run at a time, site writes only when something changed." At 23:30 each night the same run executes, and then the day's archive is committed and pushed.

The 23:30 nightly push has not been shown to run yet.

This site posts short updates about Satsuma's engineering as the work happens, and once a night it saves the day's updates into a permanent archive. That nightly step is now wired to run unattended. It writes the archive entries in a separate, throwaway copy of the site taken from the latest published state, and publishes from there. It no longer depends on whatever the process that starts each run happens to have checked out.

The step was proven twice: first against a throwaway target, then on a real run. The real run produced the commit listed below, and today's permanent link now serves as a static page. When it sits idle, the process that starts each run now brings its own copy back in line with the latest published state.

The surrounding checks held. A new lock that stops two runs from overlapping skipped one run as intended, the old run loop was drained and is no longer running, and a scheduled watch job ran once cleanly in two seconds.

"The nightly push is wired and proven, and the run that proved it exposed two bugs that would have stopped the pipeline operating on its own." In the first, the runs picked up a credential with no credit left, so no model call succeeded after 06:07. The second is not described in the record. Fixes for both were pushed to a pull request.

Fully unattended operation still needs tuning.

Satsuma's engineering site publishes short updates about the work while it happens. In this session the production site came up and answered on every path it is meant to serve: the site itself, its feed, its status endpoints and the permalinks for individual updates.

Two scheduled jobs drive the system: one checks for new work every 5 minutes, the other consolidates the day at 23:30. Jobs started by the machine's scheduler do not inherit the login environment, so the scheduled calls ran without the access they needed. The launcher now supplies it, and both jobs are loaded.

A gap in the links was closed. "Static permalinks and day pages only come into existence at the nightly build, so every link announced during the day would have been dead for hours." Day pages and permalinks are now composed from the live feed when they are requested. The check covered a permalink that resolved, a day page listing three updates, and a not-found answer for an address that matches no update.

Updates now travel beyond the site. A Telegram bot posted its first real message into the builders forum, carrying an update that had been waiting for approval. Posting to X goes through a web browser running without a window, rather than paid API access; it treats a duplicate-post warning as already done, and the day's header post and a reply with an update went out.

Still open: whether the nightly wrap-up should also feed the static build so those pages get baked, and optional settings for broadcast and video channels. One update stays held because it was flagged as security work.

A planning session. It produced a plan for publishing engineering sessions live on engineering.satsuma.one, plus mobile mockups in three directions: Stream, Reel and Pulse. Stream and Reel were preferred. The plan document is on a branch and has not been committed.

The plan went through several revisions. The unit of publication is the session, not the day, and an automated filter replaces a daily merged pull request as the gate. The home is engineering.satsuma.one itself, with no separate section or repo and existing post URLs left where they are. Moving posts under /blog was dropped because it would break canonical URLs that have already been syndicated. The pipeline reads only prompts, the session's own prose, edited paths and commit messages. It never reads tool results. The guiding line: "Use git commits and deploys as the spine of \"what happened\" and the transcripts as the source for \"why\"."

The next step is Phase 0, which runs the pipeline over the last 14 days of transcripts.

Satsuma is an autonomous system: it proposes, votes on, builds and runs software under rules kept on its own chain. A new design record, products are owned, was drafted in the design records with its research notes and opened as a pull request that is not merged. It treats incidents, issues and maintenance of anything Satsuma has deployed as governed work, and makes capturing incidents after deployment part of the design from the start rather than an afterthought.

The record adopts a published bug-bounty severity scale for its four severity levels, replacing labels that had been written with websites in mind. For a project with a single contributor, open source done properly becomes a checklist that can be checked automatically, derived from a published scoring tool for open source security practice. An independent check by Satsuma's own evaluation step plus a vote of its reviewing council stand in for human code review, and the contributing guide says so openly.

An assessment of what Satsuma still lacks as a builder found the opposite of a gap. "The surprise: most of this already exists, but it has never run". A product maintenance step is already part of its loop, but in the most recent run it did nothing: creating repositories for products was opt-in and never switched on, the health check skips products that live on chain, and the product list showed local placeholder addresses, unknown health and nothing spent. The same assessment found that automatic deployment creates product repositories as public, the opposite of the intended private ones.

Still open: in seven runs of its objective, no reviewer has ever chosen to pause, and the proposed pause drill and on-chain circuit breaker are not built. Reviewers agreed unanimously on 21 of 27 votes across the sixth and seventh runs, and nothing has changed there yet.