0 0 0 Subscribe

Satsuma Engineering · day

Thursday, 22 October 2026

The lab

Three display bugs fixed and live on the books site

Three display bugs on books.satsuma.one, the website that presents books with a library page and a light or dark colour scheme, were fixed in a session with Claude in Claude Code, merged and deployed. The live HTML no longer carries the stray Language label, and the live stylesheet has the new button colour rule.

The first bug was a Language label showing up in the header. The diagnosis, in the session's words: "The \"Language\" label reuses the skip-link class, so it gets pulled back on screen. The <select> already has an aria-label, so the extra span can go." The span was removed rather than restyled, since the language menu already names itself for screen readers.

The second was the Buy the book button: its text vanished on hover because the header's link styles overrode the button's text colour. Those link styles are now scoped so they no longer touch buttons. The third was the Get Chapter 8 free box, which stayed light on the dark scheme; it now uses the same dark card style and border as the other panels.

Dark mode was checked in headless Chrome on the library page and the Will Never DM You First page: the header shows only the logo, the theme toggle and the language menu, and the Chapter 8 box is dark. The hover state itself was not tested in the session; a hard refresh in a browser is the remaining check.

explored
  • Diagnosed three header and theme bugs from screenshots
  • Checked dark-mode rendering of the library page and the Will Never DM You First page in headless Chrome
  • Attempted to test the button hover state; it could not be tested directly in the session
decided
  • Remove the extra Language span rather than restyle it, since the language menu already has its own aria-label
  • Scope the header's link styles so they no longer touch buttons
open
  • The button hover behaviour was not directly tested; a hard refresh in a browser is needed to confirm it
The lab

Power watch set up before a 12–16 hour run on a Mac

Before a long run on a Mac, expected to take 12–16 hours, the AI assistant working in Claude Code started a power watch. It reports any change of power source and sends the operator a push notification if the Mac drops to 30% on battery. A rule to check the power source before every long run was saved to the assistant's memory, so the check happens again without being asked.

The run is the fourth attempt, and it survives an unplug only as long as the battery lasts. As the assistant put it: "If you unplug the Mac during the next 12–16 hours, attempt 4 will survive only as long as the battery does. Plugging it back in before it runs low is enough."

explored
  • Started a power watch that reports any change of power source and sends the operator a push notification if the Mac drops to 30% on battery
decided
  • Check the power source before every long run (saved to the assistant's memory)
open
  • Attempt 4 is expected to run 12–16 hours and survives an unplug only as long as the battery lasts; the Mac needs to stay plugged in or be plugged back in before it runs low
The lab

Run E attempt 3 lost to a machine outage; attempt 4 started

A fourth attempt at run E, a long governed run in which Satsuma proposes, votes on and operates its own products, has been live since 01:50Z on 2026-10-22, on the same launch settings and the same code as the third. The records of attempt 3 were kept in the experiments repository, with the intervention noted.

Attempt 3 died at 04:54Z on 2026-10-21, when the Mac running it went down and every process stopped at once; the machine booted again at 06:00Z. The run was about 2.7 hours in, with two of its products open: a token exchange and a vault, and it had got through adoption. The session found nothing pointing at the run itself: "No log shows an error, and disk is fine (59 GB free), so the machine went down, not the run."

Two bookkeeping commits in the exchange's repository are carried into the new run as history. The session treats this as the designed behaviour, because the run's records are keyed to the chain.

Nothing past adoption was exercised in attempt 3, and attempt 4 has to get through adoption again before the first real milestone is reached: "Adoption alone takes about 3 hours per attempt now — three milestone votes per product, each with the 6-minute window."

explored
  • Run E attempt 3 reached about 2.7 hours in and got through adoption before the machine stopped at 04:54Z on 2026-10-21
decided
  • Attempt 4 reuses the same launch settings and code as attempt 3
  • The two bookkeeping commits in the exchange's repository are carried as history in the new run, as designed, since the run's records are keyed to the chain
open
  • Attempt 4 has to get through adoption, about 3 hours per attempt, before the first real milestone is exercised
  • Nothing past adoption was exercised in attempt 3