Thursday, 15 October 2026

Satsuma is an autonomous system: a language model proposes products, votes on them, builds them and runs them on its own blockchain, and the whole loop is tested in numbered runs. Run 7 started from the main line of the code, which holds every fix made so far, including one that moves the stored address of a product when it is redeployed. It runs on a Claude Code subscription with no API key, its first model call completed, and it has its own new product registry. Run 6 was archived and its repositories deleted.

Run 7 is there to see two behaviours live for the first time: whether products that depend on the exchange get an alert when the exchange (a trading contract the system built and deployed earlier) moves to a new address, and whether the operator follows a migration of a mandate that happens in the middle of an operation, within one cycle. "Neither one can be forced. Each depends on what the reviews find and on the timing."

Around 15:40 UTC the subscription reached its session limit, which resets at 17:50 UTC. "Until then, every model call in run 7 fails. The daemon keeps retrying each cycle and nothing is lost; earlier runs got through the same thing." The Claude Code session overseeing the run then reached its own usage limit and stopped, while the run kept going.

The watch set on the run ignores the limit errors but expires after 30 minutes and cannot be renewed while the session is stopped. Following run 7 to its end, archiving it and deleting its repositories are still open, and both behaviours remain untested.

Satsuma's engineering site and its block explorer are built and checked by GitHub Actions on every change, and the engineering site's CI kept failing on storage. The cause was found: "Each CI run was uploading the whole built site, and nothing ever downloaded it; the deploys build the site themselves." "Those uploads used up October's free storage allowance, which is why engineering's CI kept failing."

Two changes were opened that remove the whole-site upload step: one in the satsuma-engineering repository and one in satsuma-explorer. Both pass CI and are not merged. The decision was to remove the upload rather than raise limits; the explorer's Lighthouse check stays in place.

A second limit is close. About 1,854 of 2,000 free Actions minutes for October have been used, and at the current pace they run out within a day or two. If they do, site deploys and the 30-minute off-site status check stop until 1 November.

Still open: merging the two changes, and choosing between a small GitHub spending budget or making CI skip the long satsuma-node and satsuma builds when only docs or infra files change. The session stopped when its usage limit was reached.

A Mac app built for this site reads engineering work sessions and has Claude draft, judge and edit posts from them, with a Review screen to publish, set aside or rewrite, and a searchable Library. Claude, working in Claude Code, audited it two ways: a click-through of every surface driven only by accessibility actions, and three independent reviews covering architecture and the use of Apple's on-device model, privacy and liability, and product and design.

The click-through found no crashes across the sidebar, the update detail view, Review (Publish, Set Aside, and Rewrite opened and cancelled), Library search, filters and Ask, Studio, every Settings tab, the Engine window, the menu bar panel and onboarding. Five checks failed, and those were attributed to the test script rather than the app.

The first fixes make the privacy modes binding. Claude now writes, judges and edits only in Claude mode with explicit consent; the Private and Apple modes send nothing to Claude. There is no silent fallback either: a session Apple's model cannot read stays on the Mac unless a setting to let Claude read it is switched on, and that setting is off by default. Every call to Claude is redacted first. Settings now show consent switches and display formats as read-only, and Review uses one verb consistently. The existing install keeps Claude mode with consent, as it had been running.

The work is on a branch, and the latest build is running in the menu bar. The fixes stopped partway, with the session's own note reading "Your usage limit has been reached, so I've stopped partway through the audit fixes." The remaining findings from the three reviews, including those on missing product features and the design system, are still open.

Satsuma runs its own blockchain, and how far back anyone can look up its blocks and balances depends on how much history the chain's nodes keep. After the operator said the budget for this work was not available, Claude in Claude Code proposed a three-part plan at $0 a month on existing hardware: "Yes. There's a way to get most of the benefit for $0 a month, on hardware you already pay for."

One part keeps permanent history in a free-tier indexer behind the explorer; the record cuts off partway through that part, so its details are unknown. Nothing has been changed: no configuration, no restart, no commit. One node's data is about 10 GB on a 50 GB volume, per the assistant. The operator has not approved or applied any step.

Satsuma's three public websites, satsuma.one, the block explorer and engineering.satsuma.one, carry a small status dot in their footer that reports whether Satsuma's chain is running normally. The session set out to merge and deploy the three changes that add the dot. All three had already been merged, between 15:32 and 15:33 UTC, before the session acted.

Each site's deploy to Cloudflare Pages succeeded. A check of the live sites found the footer dot reading Chain status: operational on satsuma.one, the explorer and engineering.satsuma.one.

The check turned up something else. "The engineering repo's CI shows red on main, but its build passes." "The failure is the final step that stores the build output: the organization has run out of GitHub storage for these files." That step has failed on the last five engineering runs, and the explorer repository has the same storage problem. It is unrelated to the status dot.

Two fixes were named: delete old stored build files, or drop the storing step from the workflow. Neither has been applied.

Satsuma's main site, its block explorer and this engineering site now each carry a small status indicator, a dot that reads a status response. The change to each of the three sites was squash-merged and deployed, and all three deploys succeeded.

On the explorer, the dot now reads the response with the explorer's existing status parser instead of keeping its own copy. The explorer change had to be rebased first, after other changes merged ahead of it and caused conflicts, and it was re-checked in a browser at phone width before merging. Its status link sits after the new network and satsuma.one links. The explorer's check, build and tests pass.

The engineering site's change merged with a red CI check. "Its CI check was red, but only because the GitHub org's artifact storage is full. The build itself passed, and the deploy job doesn't upload artifacts." The local worktrees and branches used for the work were removed afterwards.

The live pages on all three sites include the dot, confirmed from the deployed HTML rather than by opening each site in a browser. The full artifact storage is still open and still turns the engineering site's CI red.

Satsuma's three public websites, the main site (satsuma-website), the block explorer (satsuma-explorer) and this engineering site (satsuma-engineering), each got a footer link to a status page with a coloured dot. Nothing is merged or deployed; all three changes are open and ready for operator review. The website and engineering themes gained amber and red colours for the dot.

The explorer's dot got its own 60 s check rather than reusing a check from a separate open change to the explorer. Until the two checks are unified, the explorer would call the same endpoint twice, and whichever of the two changes merges second will hit a one-line conflict. On phones, the longer explorer footer broke mid-item and pushed the dot onto its own line, so whole footer items now wrap instead. The operator said they trust these calls, and all three changes stay as they are.

The engineering site, engineering.satsuma.one, runs a live YouTube broadcast of its work, kept on air by a long-running broadcast job. That job was restarted on new code. It went off air cleanly at 22:23:47 and back on four seconds later as a new YouTube broadcast.

The job log now reads "Composition sends the feed and pulse; written locally only". Per that log line, the Composition app is now the only one sending the feed and pulse; the broadcast job writes them locally only.

The broadcast job is running on the new code after a clean restart.

The status page for Satsuma, built in the satsuma-status repository, now serves a live badge and a social preview card in production. The change was merged and deployed, and with it all four phases of the plan for status.satsuma.one are in production.

The badge, at status.satsuma.one/badge.svg, reports Satsuma as operational and refreshes every 30 s. The same status is served at /badge.json in the shields.io format, so standard badge tooling can read it. For sharing, the page now serves a 1200×630 preview image along with Open Graph and Twitter card tags.

Small status dots for three other sites, satsuma.one, the explorer and this engineering site, were prepared in their own repositories. Those changes are open, not merged or deployed. The session that built them reports checking each at desktop and phone width.

Still open: real link previews on X and Telegram were not checked, and the cards will appear when those services next fetch the page. The website and explorer changes report no CI checks, and the engineering site's check was still running.

Three pull requests were opened, one each in satsuma-website, satsuma-explorer and satsuma-engineering, adding a small live dot next to a Status link in each site's footer. The dot shows the health of Satsuma's chain, read from Satsuma's status page. None of the three are merged or deployed; all three await review.

Each site asks the status page once when the page loads, then every 60 s while the tab is visible. It reads only one field, the state, and a 503 response reporting down turns the dot red. If the request fails or the answer is not what was expected, no dot is shown at all rather than an error. Pages that the browser prerenders in the background wait until they are actually opened before asking.

The dot's colours come from each site's own colour variables; amber and red were added to the website and engineering themes. The explorer and the engineering site had no Status link in their footers, so one was added alongside the dot.

The changes sit on a branch in each repository and wait for review before anything is merged or deployed.

A status check in Claude Code found the program that runs this site steady, with a fresh heartbeat at 22:20:15 Bangkok time. That program writes the site's updates and short videos. The site's status signal went out about every five minutes, showing the session as active and on air, and the separate video lane of the older Node pipeline had not started since 21:52, so the handover between the two is holding. Today's count stood at 55 updates published, 51 held and 2 dropped. Of the 8 shorts the program made, all are on the reel and none are on YouTube yet.

An older broadcast job, the process that keeps the site's live YouTube broadcast on air, has been running since 13:09 on old code and keeps sending the site's status signal alongside the publishing program. Still open is whether to restart it now, or wait until it next goes off air on its own, so the YouTube broadcast is not cut.

Engineering.satsuma.one, this site, is produced by an automated pipeline that writes short updates about the work, checks them before posting and cuts short videos of them. That pipeline is moving from an older Node.js version to a new app. A change was committed and pushed that puts the app's heartbeat on its own timer from launch, refreshing every 30 seconds. The heartbeat is the signal the Node pipeline watches to decide whether to take a job back. At 22:17 Bangkok time the app was running three of the four jobs, with the Node pipeline as fallback for each, and the heartbeat was fresh.

The app now handles the site feed and the pulse; the pulse at 22:10 came from the app. Since the handover it has made 6 shorts, each 24 to 27 seconds long, all on the reel. None are on YouTube yet, because the Node pipeline had already used today's two YouTube upload slots. Writing and judging the updates still run on the Node pipeline while comparisons are collected.

Restarting components during the handover caused a heartbeat gap around 21:49, and the Node pipeline took the jobs back for a while; that was handled. A second incident occurred during the handover; it has not been described yet. Every scheduled job and running process was also checked to find what was starting runs with old code against the live state. The work session doing the handover had not run the pipeline itself, which pointed to a separate cause: "That session never ran the pipeline itself. So something else is starting runs with old code against the live state." No source has been named yet.

The Node pipeline stays as fallback for each job the app runs. From 05:00 tomorrow the app handles the daily digest, and the Node pipeline posts it if nothing has gone out by 06:00. The count for today so far: 53 updates published, 47 held, 2 dropped.

The last part of the plan for Satsuma's public status service was committed in a Claude Code session. The service reports whether Satsuma's chain is operational, degraded or down. This work adds a live status badge at /badge.svg that shows one of those three states, and /badge.json, a shields.io-compatible endpoint for pages that draw their own badges.

It also adds a social preview image, the picture that appears under a link to the service when it is shared on X or Telegram. The README and AGENTS.md were updated in the same change; both still described the old incidents.json workflow.

The preview image is kept static by decision. "The card is static on purpose: those networks cache preview images for days, so a live one would show stale status." The badge and the /api/status endpoint are the live parts.

A separate task remains open: showing a live status dot on satsuma.one, the explorer and this engineering site.

Claude, working in Claude Code, tried to add a TXT record to the DNS of satsuma.one through Cloudflare's Add record dialog in Chrome. The record was not added, and nothing in DNS changed.

The TXT record still needs to be added; Cloudflare's dialog needs Chrome in the foreground to finish drawing.

Satsuma's status page, a public web page that shows whether its chain and the sites around it are working, was deployed to production from the satsuma-status repository. Its trend charts now open with the last hour of data. A new Services section runs minute-by-minute checks of four services, Public RPC, Explorer, satsuma.one and Engineering, and all four showed up.

After the deploy, the history feed behind the charts was 4 s old with a full hour of points, and the page logged no errors. The per-site strips had filled about 14 of their 60 minutes.

A change in satsuma-node, the repository for the chain's node software, was also merged while its Clippy check was red; its code was already running, so the merge brought the repository in line with it. The same Clippy failure has been on that repository's main line since an earlier change to its README and is unrelated to this work. A fix that clears stale cached files before Clippy runs is open and not merged, with its checks still running, so the main line stays red until it lands.

Still open from the plan: a status badge for the other sites and a social preview image. The work was done with Claude in Claude Code.

The Clippy check in satsuma-node, the node software that runs Satsuma's chain, had been failing on the main line of code and on every proposed change for some time. The cause is now found, and it was checked against the WASM builder's source: the saved build cache points at a deleted file.

An earlier change added build settings that feed the cache key, so the cache was rebuilt. The new cache holds a wasm_binary.rs file left behind by a test runtime during the test step, but not the compiled .wasm file it embeds. Clippy runs with a build setting that skips compiling the runtime to WebAssembly, and in that mode the WASM builder writes its placeholder file only when wasm_binary.rs is missing. Clippy keeps the stale file, and compilation fails.

The fix stays in the CI workflow rather than in the dependencies: one new step, placed before Clippy, deletes any cached wasm_binary.rs files. It is on a branch and proposed for review, not yet merged. An unrelated change was merged earlier despite the red check, since the failure predated it and had nothing to do with it.

The fix's own CI run was still going at the end of the session, so a green check is not yet confirmed.

Experiment 003 is a governed trading test, following the published Experiments 001 and 002, in which Satsuma runs a trading operation under limits it set for itself. Its sixth run finished, was archived, and is the first to meet all four key results: 10 swaps against a target of 10, 3 mandate refusals against a target of at least 1, 22 failures reconciled against a target of at least 2, and holdings in balance at the end. "The operation closed itself once it met its objective: 10 swaps, nothing pending, and holdings at 46–54% tUSD both on paper and in tangerine's live balances." Every drill passed: a relayer outage, a pool pull, a key compromise, and over-cap and low-floor requests.

Two things went wrong during the run, and both were recovered. A false halt came from mis-pinned measurement IDs; after one manual stop of the loop to fix the bug, two votes on chain re-pinned the measurements and resumed the operation. The second was a failed deployment: "The mandate's successor failed to deploy because the exchange's fix had replaced WTANG. The loop recorded the failure, kept the fix open, sent the log back to the builder, and the retry deployed." In run 4 the same kind of failure needed a hand edit.

Two fixes went through governance. An issue filed against the exchange was fixed by a redeploy and resolved in the same vote. An issue in the mandate, where the operator could block a migration, was resolved on chain through a migration vote. The migration to the new account was confirmed from balances, because this build exposes migratedTo() rather than migrated(). The results were written up, committed and pushed.

Still open: deleting run 6's two repositories waits on the operator, a further mandate issue was filed for investigation with no outcome recorded, and the balance watch expired after the run was archived and was not restarted.

Satsuma's code is spread across a set of GitHub repositories, and an audit checks them for unmerged branches that have gone stale. 25 such branches were renamed to sit under an archive prefix, with every commit kept, so the audit skips them. After the rename the audit passed cleanly for all 14 active repositories.

The choice was to keep the stale work rather than delete it. Renaming moves it out of the audit's way while leaving the history readable for anyone who needs it later.

One side effect stays open: "Renaming on GitHub doesn't update your local checkouts." Local copies of the affected repositories, satsuma-website among them, still track the old branch names and each needs to be pruned and pointed at the archived name.

The audit does not yet run on its own each week; it is waiting on a credential. Other organisation housekeeping is still open: renaming the default branch of satsuma-book, setting the organisation's email and X handle, and verifying the satsuma.one domain.

Satsuma's code lives in private repositories on GitHub, grouped under one organisation. In the lab's work on that organisation, all 14 open pull requests from a round of housekeeping were squash-merged, and their branches were deleted.

The satsuma-mini repository was permanently deleted from GitHub. The deletion was deliberate: the repository is not to be pushed or recreated. It was private and up for only a few hours. The repository and its preview image were also removed from the members' page kept in .github-private. The local copy keeps its full history, with its GitHub remote removed, and nothing of satsuma-mini was pushed anywhere.

A second session was doing cleanup work across the other repositories at the same time. It was told to drop the satsuma-mini item, discard its copy and carry on with the rest. That message was queued and has not been confirmed as read, and a reply to a question from that session is queued until its current turn finishes.

Still open: whether the 25 unmerged stale branches should be moved under an archive prefix or deleted.

Satsuma's status site is a small web app that pages the operator when something on Satsuma needs attention, and it can be added to an iPhone Home Screen. A change adding a Home Screen badge for open pages and a richer web app manifest was merged and is now live on the status site.

The site now serves the new manifest, a maskable icon, two screenshots and the service worker that sets the badge. Each of those files was checked and confirmed to load.

The session that did the work, in Claude Code, put the state plainly: "I checked that each file loads; I haven't tested the badge on a real iPhone."

That test is still open. The operator is to open the alerts page from the Home Screen icon so the new service worker takes over, send a test page and expect a badge, then acknowledge it and expect the badge to clear.

Satsuma's status page, status.satsuma.one, is a public web page that reports the health of Satsuma's chain in a grid of tiles, including one for how fast the chain answers requests. A set of changes to its code was merged and deployed to production with vercel deploy --prod.

The production server moved to Frankfurt, close to the RPC node the page reads from. RPC latency dropped from about 350 ms to between 12 and 90 ms, and the page now starts in about 0.6 s against 1.2 s before. "/api/status is now served from Vercel's cache, so RPC load no longer grows with the number of visitors."

The limits that decide when a reading counts as healthy now live in one shared thresholds file, covered by 10 tests that run in CI. The production page was checked after the deploy: no console errors, tiles fill whole rows, and the latency tile says it is measured from Frankfurt. The path that shows a slow chain as still checking was tested locally, not in production.

Upgrades that make the page a better PWA, a Home Screen badge for open alerts, manifest fixes, shortcuts and screenshots, were prepared as a separate change with CI passing; following the operator's instruction, the speed work went out first and these were deferred, so they are not merged or deployed. The badge has not been checked on a real iPhone, and later phases of the plan remain. "The repo has no Vercel Git integration, so merging doesn't deploy anything." The work was done with Claude in Claude Code.

engineering.satsuma.one posts a morning digest of the engineering work to its Telegram channel and turns each published update into a short video on YouTube. Both jobs have run on a Node pipeline. This work hands them to a new app, called Composition in the commits, and keeps the Node pipeline as a fallback for each. In a Claude Code session, Claude made the changes as commits on a branch and opened them for review in the satsuma-engineering repository.

For the digest, the app writes and posts the message itself. "It records the post in the same file the Node pipeline checks, so a day is never posted twice." For the shorts, the app makes the script, the render, the reel copy and the YouTube upload. All four destinations sign in from the app through connection checks that send nothing.

Running the app's shorts lane once for real on today's newest update was considered and dropped: the Node pipeline had already made a short for every update published today, so a run would have duplicated one on YouTube. The first real test is the next published update getting its short from the app. The order of handover was also settled: the Telegram digest first, then the shorts uploads, then the writing and judging of updates once agreement on those builds.

Both changes were opened for review, with the merge left to the operator. Still open is when to merge the digest change relative to 05:00 tomorrow, since a merge before then would have the app post tomorrow's digest. The handover of writing and judging has not started.

Claude, working in Claude Code, audited the satsumaxyz GitHub organization, where Satsuma's repositories live: their descriptions, homepages, topics, licenses and READMEs, and the organization's own profile page. Several repositories, among them satsuma, satsuma-website and satsuma-codex, have no description; none has a homepage, topics or a license GitHub recognises; and the satsuma-website README is still the Astro starter text.

The cleanup plan was drafted but stops partway through its README findings, and no changes to the repositories or the organization are recorded as applied.

This site's updates are written by software running on a Mac and sent to engineering.satsuma.one. Sending the feed of updates and the live pulse has moved from the older Node pipeline to a Mac app, and that change is merged. The site is serving the app's feed, 105 updates, and a fresh pulse; the Node pipeline now logs that the app does the sending and writes only locally.

The switch has a way back built in: "If the app stops for 15 minutes, the Node pipeline takes over again by itself; to undo the switch, remove the delivery line from pipeline/config.json."

The app also gained an ambient field, an abstract, translucent background of topographic contour lines in violet, warm light and window glass, behind the main window and the onboarding screens, replacing Claude's characters there. Apple's Metal toolchain, about 700 MB, is not installed on the Mac, so the small shader that draws the field is compiled when the app starts; the shipped app works the same way.

The app's branch was then merged into the main line of Composition, the repository where the app is built: 14 commits, merged with their history kept, as earlier Composition merges were. The app running in the menu bar is the merged build. A local copy of Composition was left as it was because it holds an uncommitted change; the Node pipeline still renders short videos from that copy, which does not need the update.

The engine that turns engineering sessions into the updates on this site has so far been written in Node. A Swift port of its four steps (capture, distill, write and judge) now runs inside the Mac app in shadow mode: it writes only to its own tables and publishes nothing. The decision was to compare it with the Node engine on the same chapters before anything switches over.

The distill step has two backends. The default is Apple's on-device model, which works on a session in chunks; on this Mac it took 3 to 57 seconds per group. The second is Claude, given the reference engine's exact schema so its output can be checked for parity. When Apple's model refuses a session, the engine falls back to Claude; that happened once, on a session containing Spanish and Korean.

The menu bar panel was closing right after it opened. The diagnosis: "The bug: your click made the app active, and the app's other open window took focus away from the panel, so the panel closed." SwiftUI's menu bar item was replaced with a custom status item and a non-activating floating panel that closes on an outside click or Escape. The fix is pushed and running, and in a test with the app activating itself while the panel was open, the panel stayed up. The main, Engine and Settings windows now open from the panel; ⌘, opens Settings and ⌘0 the main window.

Only one decision so far is a fair comparison with the Node engine, and it agrees. The other four grouped a whole day into one summary, so the Swift engine was changed to use the Node engine's chapter groups for a one-to-one comparison; those results are still to come. The panel fix is still waiting on a confirmation that it holds in everyday use.

Satsuma's trading test is running again after a false halt was cleared through its own governance. In the sixth run of this test, about 3¾ hours in at 13:05Z, the mandate's false halt had been fixed by two votes, a re-pin and then a resume, with no hand edits. The two products Satsuma built for this run have been taken into operation and are running, and the trading operator is running again on the original mandate. Since the restart it has run 9 cycles with no model usage-limit errors.

The rule behind the fix is now a commit: a mandate rule tied to the wrong measurement is re-pointed by a vote instead of being used to judge the operation, and adoptions are handled one at a time. The fix is committed and awaits merge.

The trading itself has not worked yet. Every swap attempt has failed: 0 executed against a target of 10, a failure rate of 10000 basis points. The first operation review recommends AMEND, at 72%. The cause of the failures is not confirmed. The session watching the run did not step in on the failures: "I'm not intervening, because diagnosing failed swaps is what the reviewer–amendment loop is for."

Still open is the vote by Satsuma's governing council on the AMEND recommendation, after which Satsuma rewrites its own policy. In this test, code reviews and any migration begin only after 3 successful swaps, so they depend on the amended policy getting swaps through. No issues have been filed yet.

A fix was committed for a false halt during a governed run of the autonomous system. In that run, called run 6, Satsuma works toward an objective by proposing, voting on, building and operating products on its own chain. One of them, the mandate (an account that holds the limits its trading must stay within), was halted by a breach that was not real: some of its invariants were pinned to the wrong KPI. From the session: "Nothing was actually wrong, and no issue was filed before I stopped it."

The fix changes two things. Invariants pinned to the wrong KPI are now re-pinned by vote rather than judged, by name with the same manifest and bounds, and products are adopted one at a time. 15 tests pass and the code typechecks. The rule it adds: "Before judging any breach, the loop now checks that each pinned KPI is the one the manifest names. If one doesn't match, it isn't measured."

The loop was stopped and run 6 restarted with the fix at 12:56Z. It found 4 of the mandate's invariants pinned one KPI too low and put a re-pin to the council; the 5 counter invariants were correctly pinned. Two votes, a re-pin and then a resume, recovered the halt. The mandate is operating again and the trading operation is Active.

Earlier in the run, the exchange scored 97, 98 and 98 on its three milestones and was deployed. At 11:59Z the mandate's deploy-script milestone and its deployment were still ahead, and the trading operation was waiting on it. Run 6 still has to check whether the trading operation follows a migration, check a migration by balances if the mandate build has no migrated() view, and raise an issue to the mandate if a fix to the exchange moves it.

The Mac app used to review and publish updates for engineering.satsuma.one no longer crashes when a card with a short is opened. Its detail view now uses AppKit's own video player instead of SwiftUI's built-in one, and cards with shorts were opened several times without a crash. The work was done with Claude in Claude Code, and the fixes are pushed to a branch.

The windows also moved to Apple's Liquid Glass style. They now blur what is behind them and stay translucent when the app is not in front. The cards, the live card, the review reason, Ask, the checks and the menu bar panel all use glass. Window captures cannot show translucency, so this part has not been checked by eye.

The fixes came from a scripted audit of every surface of the app: the main window, Ask, Settings, the onboarding steps and the menu bar panel, with a screenshot after each step. Early on, a full-screen capture showed the operator working in another app. From then on the real mouse and keyboard were left alone, the rest of the audit drove the app through accessibility actions while it ran in the background, and that capture was deleted. Publish was never pressed. Adding a command to the audit tool that opens Settings through the app menu was also tried.

Still open: the glass has to be seen live on screen, and it may still not be glassy enough.

The Web3 Book is sold on Leanpub in English, Spanish and Korean, and an email course sends its readers lessons over several days. A coupon code, COURSE30, is now live on all three editions. It lowers the $19 minimum price to $13.30, has no end date and can be used any number of times. Each edition's public coupon link was checked and shows $13.30. The work sits in the satsuma-book repository and was done with Claude in Claude Code.

Lesson 7 of the course and the day-10 reminder email now carry the coupon link. That change is deployed and pushed on a branch.

The first attempt did not get as far as a coupon. The browser Claude was connected to still showed Leanpub's sign-in page, and the session reported: "I couldn't create the coupons yet. In the Chrome window I control, Leanpub still shows its sign-in page, so your sign-in probably happened in a different Chrome profile than the one connected to me." After the sign-in was sorted out, one coupon was created on both translations at the same time, because all three editions have the same $19 minimum price.

One reward is still missing. Readers who invite five others are promised a free copy, which needs single-use 100%-off codes stored in the site's database, and none exist yet. A reader who reaches five invites today is told the code will arrive within a day, so it would have to be sent by hand; no one has reached five so far. The codes can be made in a batch on Leanpub, either by hand or by Claude in the same browser, which is now signed in.

The Web3 Book has a sign-up site at book.satsuma.one, and an email course now runs behind it: a series of emails sent to readers who have confirmed their sign-up. The site and the course sender were deployed live in a session with Claude in Claude Code. Sign-up confirmation emails arrived for both book sites. The first deploy of the site failed with a Cloudflare server error during upload; the retry succeeded.

Checks on the live site showed an invalid email address is still rejected, one-click unsubscribe works, and the sign-up text mentions the course. The course database change was applied in production. Course email now goes out through Cloudflare, with no Resend code left. Two commits added a shared mailer Worker for it and pass custom headers through to it. The course code itself is on a branch in a private repository.

The course was meant to hand each reader a personal Leanpub discount code, which needs Leanpub Pro; that plan was dropped. "Without Leanpub Pro, the course will use one shared 30%-off coupon per edition (English, Spanish and Korean) instead of a code for each reader." Shared codes also changed the copy: "A shared code can't expire on each reader's own deadline, so I've asked the course session to remove the \"72 hours\" wording from the day-7 and day-10 emails rather than claim a deadline that doesn't exist." The course went live without coupons for now: the day-7 email links to the regular book page, and the day-10 reminder is skipped until coupons exist.

The sender is scheduled for 14:00 UTC for English and Spanish and 00:00 UTC for Korean, and sends only to confirmed subscribers, of whom there are none yet; the one sign-up is a test still awaiting confirmation. The three coupon codes still need creating, an attempt through Chrome stopped because the browser was not signed in to Leanpub. Replies to the book addresses currently reach nobody, and sending from the new book.satsuma.one domain is capped at 200 emails per day.

Some of the updates and short videos that Satsuma publishes about its engineering work are held until a person approves them. A Mac app for that work was built, and it runs with real data from Satsuma. It sits in the menu bar, starts at login and does its work in the background, and it is aimed at being good enough for Apple to feature. It has five parts: a Today screen, a Review screen for held pieces, a Studio where a short video is edited, a Library, and a five-step onboarding. The work is in three commits on a branch, and the commits are not pushed.

Two independent design reviews followed, and the fixes from the second were applied. Counts now match across the toolbar, the sidebar and the menu bar panel. Each screen has one primary action, and each colour has one meaning. The copy is plainer, the Studio gallery shows real poster frames, and Library search also answers questions on-device. A cut-off in the onboarding text was fixed, the mark inside the app was matched to the new icon, and debug logging was removed. The review verdict moved from not featuring the app to shortlisting it.

Three decisions were made. Every action, whether publish, set aside, rewrite or pause, goes through one command type, the same one a later iPhone companion is meant to send. The Dock icon shows only while a window is open. The count of pieces to review includes every held piece, everywhere. The Studio was tested with an instruction to Claude to cut a short to 20 seconds and make its opening lead with the AI model being named; the edit came back and passed all six checks. The work was done with Claude in Claude Code.

Some things are still open. The Studio preview has not yet been seen at full quality, and the icon still needs its Icon Composer variants. Publish, drop and rewrite were not clicked in testing, because they publish for real. The second review listed things that stood in the way of being featured, and the record does not say they were all cleared. The iPhone companion is to be built later.

The two websites for the book, targa.dev and book.satsuma.one, send a confirmation email when someone signs up. Both now send it through Cloudflare's email sending, by way of a shared Worker called book-mailer that has no public URL, and the Resend step was removed from both sites. The work was done by Claude in Claude Code.

targa.dev was enabled to send as book@targa.dev, with Cloudflare's bounce and signing records and a reject policy for unsigned mail. For the other site, sending was enabled on the book.satsuma.one subdomain, as book@book.satsuma.one, and the root satsuma.one was left unchanged. The session gave its reason: "Root satsuma.one already has a DMARC policy used by your Proton Mail, and this setup would replace it. To leave your existing email untouched, I'll send from the book.satsuma.one subdomain instead."

A test signup with the operator's Gmail on each site produced a confirmation email, and Cloudflare accepted both for delivery. That address stays a pending subscriber on both sites until a confirmation link is clicked. The account was already on Cloudflare's Workers Paid plan, which includes 3,000 emails a month, and each new sending domain starts with a limit of 200 emails a day.

book-mailer was updated and redeployed so that emails from the book's email course can carry a one-click unsubscribe link. The course is deployed on Cloudflare but sends nothing yet: its daily sender still expects a Resend key. A separate session owns that move, onto book-mailer and off Resend, and it will make the single next deploy of book.satsuma.one.

Still open: whether both test emails landed in the inbox or in spam, whether replies to book@targa.dev should be forwarded, and whether Cloudflare will refuse the one-click unsubscribe header. Until the course session's deploy, the live book.satsuma.one lacks the one-click unsubscribe and the reworded signup text.

Satsuma has a website for a book, kept in the satsuma-book repository: the book reads in three languages, and signing up by email unlocks Part III. The site is now live at book.satsuma.one. In a Claude Code session, Claude set up its Cloudflare side: a D1 database, a Cloudflare Pages project to host it, and a DNS record for the book address.

Checks on the live site showed the pages in all three languages and the sitemap loading, the server rejecting a bad email address, and the chapter text of Part III not reachable as a public file. The change pointing the site at the production database was left for a parallel session working on an email course in the same repository to commit, rather than committing over that session's work.

A second book site, book.targa.dev, was built from the same code in a new repository, targa-book, with its own content and a dark look with a red-orange accent. Both sites are live.

Signup will report a failure on both until outgoing email is set up, since the confirmation email is what opens Part III. There is no mailbox on targa.dev, and none is needed: "You don't need a targa.dev mailbox to send email. Sending only needs a few DNS records on the domain to prove the mail is legitimate, and I can add those in Cloudflare the same way I added the book records." The recommendation was Cloudflare Email Sending, sending from a book address on each domain with replies going to a personal inbox, pending confirmation that it can be wired into these sites.

The provider is still open: Cloudflare Email Sending, Resend, or sending both sites' mail from satsuma.one.

Satsuma is an autonomous system: a language model proposes products, votes on them, builds them and runs them on its own blockchain. Its code is exercised in numbered runs. A commit closing the items left open by run 5 was merged into main: migrations are now confirmed by balances, the operator follows a moved mandate, and the relocation pass is tested. The merge landed, and the experiment environment was updated to that commit.

Two things were deliberately left as they were. The working branch for the fix was kept, and the main checkout was not switched, because run 6's daemon is running from that checkout. The code there is identical to what is now on main, so run 6 is not affected.

Still open: deleting the branch and moving the checkout back to main, both after run 6 is archived.

A section titled Shipping a full Mac product was added to the product specification for Composition, a Mac app that works with Claude. A Claude Code session wrote it after being asked what separates the current app from a full macOS product that could reach rank 1 on the App Store.

"The finding that matters most: the App Store version of the app can't use a Claude Code login." The reason is the sandbox: "The App Store requires apps to run sandboxed, and that blocks the app from launching the claude command-line tool."

The section recommends two builds of the same app: one for the App Store, and one for direct download that also allows the Claude Code login. This is recorded in the document as a new decision, as a recommendation, not yet settled. In the App Store build, Claude would connect through an API key, or through Apple's planned Anthropic connection once that ships. Apple Intelligence needs an Apple silicon Mac, macOS 26, and a supported region and language, so other users need a path that uses Claude only.

The section also lists Mac features the app is missing: a menu bar item, desktop widgets, Shortcuts and Siri, sending items in from other apps, approving a piece of work the app is holding for review, straight from its notification, and starting at login. Part of the session's text was cut off, so the full list may be longer.

The operator has written a book about Web3 and sells it on Leanpub; it has sold one copy, per the operator. The operator asked for a marketing funnel and SEO plan for the book. The plan landed as a private claude.ai document, which the operator has to share from the page before anyone else can see it.

The plan starts from a diagnosis: "The main reason for one sale is that nothing outside Leanpub sends readers to the book, and Leanpub's store doesn't put new titles in front of people searching Google." Its answer: "The fix is to give the book its own site that people can find through search, and use Leanpub only as the checkout." It proposes a standalone site at book.satsuma.one in English, Spanish and Korean.

That site would carry about 460 searchable pages built from content already in the book's repository: a 100-term glossary, 35 chapter summaries, the full Chapter 1, a timeline and question pages. The full book stays paid. The search targets are specific concept questions, such as what a DAO is, rather than the broad question of what Web3 is, with Spanish and Korean versions of each, plus registration with Naver for readers in Korea.

The plan is not implemented and the site does not exist yet. Its keywords are untested: "The keyword list is a starting guess: I haven't pulled search volume data, and Google Search Console will show real demand a few weeks after launch." A request to move the book's Leanpub publish date to today was also made; the record shows no outcome.

One change landed in the software that runs the nodes of Satsuma's chain. That software is built with the Polkadot SDK, and every change to it is compiled and tested automatically by CI before it is accepted. The change makes the CI job free disk space on its runner and drop debug info from the build. It was squash-merged into main in a Claude Code session.

The same fix passed CI on its branch before the merge. After the merge the branch was deleted and the local copy of main was updated.

"Merging started a new CI run on main, which takes about 30 minutes." That run had not reported a result when the session ended.

satsuma-node is the software that runs Satsuma's chain, a standalone chain built with the Polkadot SDK. Each change to it is compiled and tested automatically by continuous integration on a GitHub-hosted runner. Those builds had been failing on the main line of work and on recent changes, and a fix to the build configuration was committed.

The session, run in Claude Code with Claude, traced the cause. "The CI failure on main and the last few PRs comes from the build itself." "The GitHub runner runs out of disk while compiling the node and the WASM runtime." The conclusion was short: "Nothing is wrong with the code."

The fix does two things. It frees about 25 GB by deleting tools the runner has preinstalled but the build never uses, among them .NET, the Android tools, GHC and CodeQL. And it compiles the whole dependency tree without debug info.

The first test run of the fix had just started when the session ended; a full run takes about 25 to 30 minutes. Whether the fix turns the main build green is not yet known.

The code behind this site now tells git to ignore the saved videocast scripts and timings for each short, instead of listing them as untracked files. The change is one line in the ignore file. Tested before committing: git lists no untracked files, and the hand-made video script for the Introduction to Satsuma post is still tracked.

The work started as a request to delete untracked folders. Before deleting anything, the session, run with Claude in Claude Code, checked what the folders held and found the saved scripts and timings that the broadcast reads while on air. Deleting them would have meant regenerating the scripts with new model calls and breaking the match between captions and the shorts already published, and the files would have come back with every new short.

The diagnosis was short: "The real problem is that git doesn't ignore them." The ignore line was proposed in place of the deletion, and the operator confirmed it. "Nothing was deleted, so the broadcast still has them."

Satsuma is an autonomous system: a language model proposes products, votes on them, builds them and runs them, and its own blockchain records each step. Three fixes for gaps found in its fourth test run were merged into main in the satsuma repository. Fixes to a product are now opened in that product's own repository, counters carry across a migration, and a product is told when something it depends on moves.

The two test repositories from run 5, satsuma-mandate-account-r5 and satsuma-tangerine-dex-r5, were deleted. No repositories built by Satsuma are left in its code organisation. The main satsuma checkout and satsuma-exp01 are both on the merged commit.

Run 5 left work of its own: "Three gaps from run 5 are still open: 1. Confirming a migration by checking the balances when a build has no migrated() view. 2. Finding out why the rule that restarts the operator when its mandate moves didn't trigger. 3. A live test of the issue that tells a dependent product another product has moved." A later commit, Run 5's open items: migrations confirmed by balances, the operator follows a moved mandate, the relocation pass is tested, targets all three.

A status check of this site at 14:22 Bangkok time found nothing stuck: the broadcast job was running, the nightly and watch jobs were loaded and running on schedule, and the live session panel showed the current session with the broadcast on air, reading through the updates from 14 October. Of 126 updates tracked, 88 were published, 36 held and 2 dropped; today 26 were published and 17 held. There are 61 vertical shorts, and new ones still upload.

Two broadcasts ran this morning, one of 9 minutes reading 13 updates and one of 1 minute, each with at most 1 viewer. Still open: one overnight backfill failure for a short, reported as made on a later run, and the digest for 15 October, due to post to Telegram at 05:00 tomorrow.

This site publishes short updates about Satsuma's engineering work, each written from a record of the session and checked by an automated judge before it appears. Two updates written under the new transparency rules, which name the model and the stack behind the work, are now live. One says the site now names the AI model behind the work and will say more about its stack. It was published after a rewrite that used the judge's suggested fix.

The other reports that CI build artifacts are now kept 3 days instead of 90 in two repositories, and it took a manual step. "The judge passed the CI update at 0.85, but a hard rule still held it." The rule keeps private references such as pull request numbers out of public text, and one of the update's commit messages ended in the pull request number GitHub appends during a squash merge. "No rewrite could fix it, because commit messages are kept word for word." The suffix was stripped from that commit message by hand to release the update.

A commit now makes the site's update pipeline drop GitHub's pull request suffix from commit titles before an update is written from them. That fixes the cause in the pipeline instead of relying on stripping by hand. The work was done with Claude in Claude Code.

A status check found Satsuma's chain healthy: best block 4,776,228, a finality lag of 2 blocks and 30 blocks per minute. The summary of the check put it in one line: "The chain is healthy and every monitoring layer is running with nothing firing."

The monitoring behind that line was set up the same day. Watchdogs on each of the three nodes run with 0 failing checks each. A separate monitor box watches 8 of 8 targets as up, with no alerts firing, and runs jobs for an RPC probe, a dry run of the write path that moves no funds, chain-event alerts, uptime and a daily digest. Push alerts come from the public status page, which is live with an empty incident list, and reach 2 subscribed devices; a dead man's switch raises an alarm if the monitoring itself goes quiet.

Around it, the explorer now decodes transaction inputs and event logs, the website links the status page, and a parking wildcard record was removed from DNS. For this site, the CI build artifact is now kept for 3 days instead of 90, and the stored artifacts were cleared.

A separate runtime experiment sits on a branch, parked. The first daily digest is scheduled for 09:00 UTC.

An unfinished research article about Sei, another blockchain, was deleted along with the glossary terms and video script written for it. The draft was about 4,900 words long and was waiting for a fact-check. It sat on a local branch of the engineering repository and nowhere else. In the session's own words: "It only ever existed on your machine: no copy on GitHub, no pull request, nothing on main." A memory note that pointed to the draft was removed too.

The session first explained what the draft contained, and then the operator chose to delete it. Separate uncommitted video work was handled after that: video folders for three posts and an edit to the visuals they share. Moving it onto a fresh branch from main failed, because the shared visuals edit conflicted with a newer version already on main. The work was stashed. The operator then decided it was not needed, and the stash was dropped.

The engineering repository's local checkout is now on an up-to-date main with a clean working tree and no stashes. The deleted draft can still be restored from git for a few weeks if the operator changes their mind.

engineering.satsuma.one is the public, live record of Satsuma's engineering work, written up as it happens. Two changes to the site's code were merged, and the site is deployed with both. Together they make the site say which AI model and which tool did the work, and they open the way for updates that name the stack.

Each change started its own deploy. Both show as cancelled, but no build failed. A later change to the same code, not made by the assistant, deployed successfully and includes both.

The live pulse now carries a model block: Claude Opus 5.5, Claude Code 2.1.299, effort medium. The broadcast was restarted on the new code, so its on-air view names the model too. All 40 shorts on the reel were remade silently, with no failures.

The rule behind the change: updates, shorts and the daily digest may name the model, Claude Code, the Polkadot SDK stack and the repositories, and should be more technical. Credentials, hosts, IP addresses and open security problems stay out of public output. The record stops partway through the first update written under the new rule, so how that update turned out is still unknown.

The code behind this engineering site, in the satsuma-engineering repository, and the code behind Satsuma's public block explorer, in satsuma-explorer, both run through continuous integration: every push is built and checked automatically, and the finished build is uploaded as an artifact. Two changes merged today cut how long those artifacts are kept, from 90 days to 3 days, one in each repository.

The aim was to stop the artifacts from filling the storage quota. Uploads were kept rather than switched off: "The builds still upload, so the last few days remain downloadable for debugging." On size, the record is plain: "At about 40 MB per push, 3 days of builds stays far under the quota."

Both changes were made in temporary worktrees taken from the main line of each repository, so a separate checkout with uncommitted work in progress was left untouched. The temporary worktrees were removed afterwards.

Still open: the explorer's continuous integration is expected to pass on its next run once GitHub recalculates the storage used, which the session put at within 6 to 12 hours.

Every change pushed to Satsuma's repositories triggers CI, automated checks that build and test the code, and those runs can save their output on GitHub as artifacts. All 139 old artifacts were deleted, about 5.35 GB in total: 137 in satsuma-engineering, the repository behind this site, which came to 5.3 GB of dist build output at about 40 MB each and had been kept since July, and 2 small ones in satsuma-explorer, the repository behind the public block explorer. None remain in either repository. The work was done with Claude in Claude Code.

Nothing depended on the deleted files, since no workflow reads them back.

The session also named the cause: "This will fill up again. The engineering CI uploads a 40 MB build on every push to main, including the nightly pipeline pushes, and keeps each for GitHub's default 90 days." A commit changes CI to keep the build artifact for 3 days instead of 90. Whether to keep that upload at all, or drop it, stayed open.

The explorer's CI is not yet confirmed green. GitHub recalculates storage usage every 6 to 12 hours, and a re-run before then may still hit the old quota.

Decoded transaction inputs and event logs are live on explorer.satsuma.one, the public block explorer for Satsuma's chain. A transaction page now shows the named function it called with its arguments, and the events it emitted as named logs, covering both standard events and Satsuma's own. Events the explorer cannot match are shown raw with a note saying so, and the raw hex stays on the page alongside the decoded view.

The same session changed the canary, a recurring check that the chain can still accept transactions, not only produce blocks. "A chain can look perfectly healthy on all of those while nobody can actually transact." "Since Satsuma is permissioned and has little traffic, this is the only signal that the write path works." The check now simulates a zero-value transfer from an operations account every 5 minutes through the chain's public Ethereum JSON-RPC endpoint; nothing is signed, sent or spent. It runs in 0.2 seconds and appears on the status views as a dry-run write-path check. That change is live.

The decision was to stop sending real transactions so that no real funds are used; the earlier version was never funded either. The trade-off is stated plainly: "What it gives up: proof that a real transaction gets included in a block, which only a fee-paying transaction can show."

The live page on this site shows an engineering session as it runs: a status bar pinned to the top of the screen and a session panel describing the work in progress. A commit reworked both for phones. The status bar now measures the header and sticks directly beneath it, with a solid band behind so nothing scrolls through the gap. Measured mid-scroll on a phone, the header ends at 63 px and the bar starts at 63; in the session's words, "The measurement shows the bar now sits exactly at the header's bottom edge, 63 of 63, with no gap."

The bar is now a single full-width row. On phones the subscribe button becomes an icon, and the counts carry quiet dotted underlines that still open the sheet explaining what each one means.

The session panel was rebuilt to lead with the model at work. It shows a live indicator with elapsed time, a card naming the model with its identifier, the version of the tool running it and its reasoning effort, a grid of stats, recent activity newest first with file names only, and the broadcast fitted to its frame. The broadcast stage also names the model, and an empty waveform strip was removed. These details are read at ingest from per-reply metadata in the session records, never from the content of the replies.

Naming the model is a decision scoped to the live session panel. Updates like this one, short videos and the daily digest keep the earlier rule of not naming the assistant, the model or its vendor. The work is in a pull request that is open and ready to merge; whether to relax that rule elsewhere is still open.

Each update on this site now explains its own hard words. Whoever writes the update picks the terms a newcomer might stumble on and explains each one in plain sentences next to the text. The change was merged in a pull request and is live, so every new update arrives with its terms.

A one-time pass then went back over the archive. All 77 updates already published now have explained terms, and the archive with those terms was pushed to the site.

The short videos made from earlier updates are being remade quietly in the background. The decision was to keep each video at the address it already has: "It rewrites the same video addresses, so the reel picks up each new version without another push."

That remake is still running, 16 of 40 through with no failures so far.

Satsuma's chain is watched by a monitoring service: it checks that blocks keep coming, that finality holds and that the public endpoints answer, and it pages the operator's phone when they do not. A set of improvements to that service, chosen by the operator, was built, merged and deployed, and the live checks passed.

The biggest change guards the guard. A dead man's switch now has a chain node check the monitoring machine and page if it stops responding; a simulated outage tested it, and it paged on the third miss. A daily digest at 09:00 UTC replaces the bare heartbeat, with blocks against expected, finality, endpoint uptime and latency, canary results, alerts, chain events and disk; misleading figures in the first day's version were fixed. The public status page gained an uptime section with daily bars, updated every 6 hours through an authenticated endpoint.

Repeating pages were reworked. A loop that re-sent an unacknowledged page every minute would have used up the hosting plan's free storage operations within a day and broken push alerts for 30 days, so it was dropped. Pages now repeat every 30 minutes, are skipped for 2 hours after an acknowledgement, and clear when the problem resolves. Every notification carries a unique tag so the phone alerts on each repeat instead of quietly replacing the last one. After the loop stopped, about 1,700 of the month's 2,000 storage operations were left; the cost reasoning is now written down in the code.

The status page shows 100% uptime today, while the new uptime section stays hidden until data is posted. The original uptime formula was found to be wrong while checking that figure. Turning on the canary is the one remaining step, left to the operator.

A pull request was merged and is live that starts a silent remake of the 40 short videos already published on the site. The shorts are the site's short videos. The remake removes their old intro and sign-off and adds visuals, and it is running now.

A check on the live site showed the tappable explanations at work. The 14 October day page has 29 updates; the terms autonomous system, governance, migration and commit became tappable 17 times, and the glossary sheet is present.

Those words came from a fixed list of 15 terms. That list was dropped in favour of a different approach: "Each time it writes an update, the writer picks up to five words or short phrases from its own text that a newcomer to Satsuma, blockchains or software would not know." "The explanations go through the same hard rules and judge as the update itself." Tried on one real update, it picked migration, mandate account, ownership drill, product registry and finding, each with a specific explanation. The explanations for Active, sessions, updates and commits on the status bar stay as they are.

The change is in a pull request, opened and ready to be merged.

The site's two views for following the work as it happens, the reel and the live page, got a round of fixes in one commit, made while using them on a phone.

On the reel, the commit moves the video above the caption so subtitles no longer run under the description, which expands on tap. The handle changes to @Satsuma, and the Read icon changes from a speech bubble to a page. "Read opens instantly: each update's page loads in the background as its slide comes on screen." A second tap on the heart removes a like, and the count on the server goes down with it.

On the live page, the commit removes the On air · watch button. "The green dot next to Active already says it." The Active, sessions, updates and commits headers open the glossary sheet that blog articles already use, and the first mention of a term a newcomer may not know becomes tappable in update text, including on pages that are built when they are requested. The session panel shows file names instead of internal paths and drops empty lines for pushes and pull requests, and the ticker columns and the broadcast embed were tidied.

Satsuma builds and runs products: sets of smart contracts on its own chain, some of which hold funds. When a problem is found in one, the fix travels a governed path: a rebuild, a deploy, and a vote that marks the problem resolved. For a product that holds money, the fix is a migration: a successor contract is deployed and the position moves to it. Two changes to that path landed in the system.

The first: only a successful deploy closes a fix. A failed deploy is now recorded as failed, and the issue stays open. In a governed run, a successor deploy failed on a check in the builder's own script, and the process wrongly cleared the migration anyway. The migration record was restored by hand.

The second: the rebuild that returns the deploy log to the builder keeps the instructions for the migration and the contract sources already deployed.

Both changes were merged. Still open: fixes do not yet arrive as pull requests against the products' own code, a swap count resets to zero after a migration, and a change of address in one product is not passed on to the products that depend on it.

This site turns its engineering updates into short videos, collected in a reel and played on a live stream. A pull request that makes those shorts without calling the voice service was merged: the shorts and the stream now carry the words in captions instead of speech.

The three of today's updates whose shorts had failed when the voice service ran out of quota now have silent, captioned shorts, uploaded to the reel. The stream was restarted and is back on air. "Updates that were voiced before the quota ran out still play with their voice. New ones play silently with subtitles under the visual."

Today has 8 shorts across 12 updates; the other four were too small for their own page and never get a short.

The voice stays off until the operator says otherwise. Turning it back on is one configuration value, once the voice account has credit again.

Satsuma's engineering site publishes short written updates about the work and turns each one into a spoken video short, using an outside voice service. A remake of all the shorts got through six before the service's monthly allowance of 30,000 credits reached zero. Another 63 failed, and the remake has stopped. "The voice account has run out, and that is blocking more than the remake."

New updates cannot be voiced, so they get no short and no place on the reel of shorts. Older updates stay text-only until they are voiced. The 34 updates that already had shorts still play on the reel. The broadcast is on air: the stream keeps reading updates that were voiced before and logs a failure for the rest.

Updates are still being written and published: 71 published so far, 28 held for a person to review. The daily digest is set for 05:00 tomorrow. One of today's updates has been marked failed twice and would be skipped for good; it is to be reset once voicing works again.

What stays open is a decision on the voice; raising the narration plan is one option.

Satsuma's chain has two monitoring views, and a check today confirmed both are live: the public status page at status.satsuma.one, open to anyone, and an internal monitoring dashboard reachable only from a private network. On the internal side the certificate is valid, 16 panels show live data, and all 8 of the sources it collects measurements from are up.

Two things stay open: the internal dashboard stacks into a single column on a phone held upright, and an internal page styled like the public status page was offered but not started.

Satsuma's daily message to its public Telegram channel, which lists the day's engineering work, has a new layout; the change was merged and is live. The 14 October message was rewritten in place and is still one message for that day. It now opens with that day's headline, on fixes to products that hold data becoming migrations, followed by a collapsed New here? paragraph for newcomers and four numbered highlights.

The rewrite edited the existing message instead of sending a second one, though the log line still reports it as posted.

From tomorrow at 05:00, every daily message, update and short video is written from one shared text that describes Satsuma as an autonomous system with its own EVM-compatible layer-1 chain.

A remake of all the short videos is still running in the background. Once it finishes, the new narrations still have to be copied to the site and the archive pushed, so that older updates' videos appear on the site's page of short videos.

The Telegram channel now gets a single daily digest of the engineering updates instead of a message for each one. The first went out for 14 October: 29 updates, five highlights and a collapsed list of the rest, with buttons to the day's page, its shorts (short narrated videos of updates) and the day's video. The pull request behind it was merged, and per-update posts and on-air notes to the channel have stopped.

Feedback on that first digest led to a second change, about how Satsuma is described. A primer was researched from the project's own founding material: the product vision, the overview, the design record that defines Satsuma, and the litepaper. The digest, the writer of these updates and the scripts for the shorts all read it before writing. Of the primer, the record says: "It says Satsuma is an autonomous system: a language model that proposes products, votes on them, builds them and runs them, within limits it can only change through its own governance."

The digest also gets guardrails. "The digest is now refused if it calls Satsuma a blockchain or uses a body word for its parts." It sees the last five days' headlines so it does not repeat itself, and its welcome paragraph for newcomers is taken word for word from the primer. The primer and the new digest layout are in a pull request on this site, open and waiting for merge.

The next digest, covering today, is scheduled for 05:00 Bangkok time. A remake of all the shorts is still running; once it finishes, the new narrations go to the live site so older updates' shorts show on the reel.

A session planned how the chain's monitoring will reach a phone, then started building it, with no result recorded yet. The plan is a single web page with one layout that resizes to fit any screen, no device detection and no native app. It can be added to an iPhone home screen like an app, and it sends web push notifications as a second free alert channel. The existing paging service stays the pager for urgent alerts because web push cannot break through Focus or Do Not Disturb; web push carries warnings and recoveries.

The build is planned in three steps: a new version of the watchdog script that checks the chain's health, a status page checked from outside the chain's own machines, and a separate monitoring machine for metrics and dashboards. The watchdog script was edited and a deploy was logged, but whether it works is not recorded. Separately, a commit described the chain's third validator, the machine that helps produce and finalize blocks, along with live settings that had been brought into line by hand.

Satsuma's status page and glance dashboard show the health of the chain in a few numbers, and a session explored how they could be laid out on a folding phone, closed and open. The starting point was screen shape: both screens are about 1.4:1, against about 2.2:1 on a typical phone, so a tall single-column dashboard does not fit either one well. The suggestion was two levels of detail rather than two separate designs: "Two densities, not two layouts. Folded shows the five numbers that matter: best, finalized, lag, cadence, RPC up."

No code was written, and which of these ideas reach the status page or the glance dashboard is still open.

Nothing shipped. Two decisions were written down about how Satsuma's chain is run. First, two pending patch releases of the chain's node software will be skipped in favour of one planned jump to the next release line. That jump waits for the new line's first or second monthly patch, around December, and must finish before the current line's support ends in March 2027. The reasoning: "Against that, every rollout costs three restarts, and each restart pauses finality until the node is back. Two rollouts carry more risk than one. Waiting is the better trade."

Second, a survey of monitoring options concluded: "Verdict: don't build a monitoring service from scratch. You already have one." The existing watchdog, a 111-line script that checks the chain every minute and pushes alerts, will be hardened instead. The plan adds the checks it is missing, keeps a history, and makes alerts reach the operator through Do Not Disturb and allows them to be acknowledged. The upgrade itself still needs to be planned as a project, and there is no disk-space alert yet.

The site that reports Satsuma's engineering work turns each session into a short public update, and then cuts that update into a short video. A pull request that sends those videos to public storage and attaches each one to its slide on the site's reel was merged, and the live copy of the site now holds the address of that storage.

Two changes make up the work. One gives the reel its public storage address and lets uploads run under a command-line login. The other lets a slide that is already built pick up its short as soon as the feed of updates carries it, instead of waiting for the site to be rebuilt.

With the merge in place, the loop is described as complete: a session ends, an update is written and checked before publication, posted to Telegram, read on the live stream, cut into a short for the reel and for video channels, and folded into the nightly recap video.

What stays open is the first real run. The expected behaviour is that every new short is rendered, uploaded and attached to its slide within minutes, with no further step; the record states that as expected, not yet observed.

The reel is a page on this site that shows the engineering updates as a vertical feed of slides, oldest first. It is now live with 63 slides. Twenty-three of them carry a short video that plays muted, with captions.

The short videos are served from a new public storage bucket, and all 23 were uploaded to it. The site's archive was updated with each short's address, so the built page carries the videos. A commit also makes the reel attach a short to an already-built slide as soon as the video feed has one.

Playback was checked in a headless browser sized like a phone. A short starts on its own with the sound off, and a sound control, a like button and a share button sit on the side rail. The slide title sits just under the video's caption line.

The upload runs under a command-line login because the workspace's access token has no permission to write to the storage. A pull request puts the bucket's address in the site's configuration and moves the upload onto that login.

One thing is still open. The bucket's public address is a development address, and the storage provider limits how fast it can be read. A custom domain is the production fix and a small follow-up.

Nothing landed today. A session compared the library versions behind the node software that Satsuma's validators run in production against the latest upstream releases. It recommended staying on the current release line, applying two pending patch fixes, and not moving to either of the two newer releases yet. Both fixes affect only the node software and leave the chain's on-chain logic untouched, so applying them would need no on-chain upgrade. Whether to apply them and roll out a rebuilt validator binary is still open.

Satsuma runs an autonomous AI that proposes, builds and operates its own work, and it is tested in repeated runs. While one run kept going, a session in the system changed no code itself; it planned the next changes and put them in order.

First came the checker that confirms account balances at the end of a run. It currently reads one account, the account that holds the AI's trading funds and limits, by a fixed name. The proposal makes it follow whatever addresses the on-chain ledger currently records, and report balances for both a previous and a replacement account. It went first because it is needed before the current run ends.

Two smaller fixes concern the AI's review cycle. Reviews should wait while a deployed product that has been paused is in use, and a test of handing control between accounts should end when such a product does not resume. The step that judges each review also gets the exact grammar for calls and their arguments. The running cycle already has its code loaded, so these were kept off it and set aside for a later run.

The planned changes were committed later the same day.

Nothing landed. The site's reel plays short videos about the work, and those videos need online file storage. A session set up a storage service for them as far as its checkout page. That page showed nothing due now and nothing monthly within a free allowance of 10 GB. "For scale: a short is about 4 MB, so the free 10 GB holds about 2,500 shorts, roughly a year at today's pace, before any charge."

The service is not active yet. The last step, agreeing to the billing terms and authorising charges, was left for a person to do by hand, because payment steps are blocked for automation. Still open: activation, then creating the storage space, giving it a public address and adding that address to the site's settings. Until then the reel stays on text cards.