0 0 0 Subscribe

Satsuma Engineering · day

Saturday, 10 October 2026

The system

Operation reviews pass the dry run; two-chain run 3 retires by vote

Operation reviews and the locked objective passed their dev-chain dry run on the third attempt: all 35 acceptance tests pass, 26 of 26 unauthorized-write checks were refused, five reviews were exercised, and the daemon rebuilt its state from the chain after being killed. The work is committed on a branch and a pull request is open; it is not merged and awaits a go-ahead.

The first two attempts did not get that far. Attempt 1 failed on a wrong deploy RPC port. Attempt 2 appeared to show a hole in the objective lock, and it was not one: the driver's fast-forwarded clock had run past the end of the one-day objective's cycle, so deactivating it was legitimate. The contract already refused both deactivateObjective and setKPIRegistry mid-cycle, so the planned contract change was dropped. A test now pins that deactivateObjective reverts mid-cycle for the privileged account, and the dry run uses a four-year objective.

Run 3 of the Experiment 002 two-chain local run then completed with no interventions. The operation was retired by vote, all four key results were met, and the verification script passed on both chains, in about 4h20 against 5h26 for run 2. One thing it showed: a retirement proposal came from the proposer outside a final review.

A fix followed that makes the final review mandatory once an operator closes: the registry refuses state changes and amendments until the final review is closed, and the daemon opens due reviews before intake and accepts no action on a closed operation until then. A dev-chain dry run with the fix completed cleanly, and the contract suite stands at 727 passing with the one known failure. The harness gained a VARIANT switch for a longer objective, so that the reviewer and council face a real amend or pause decision. Run 4 started at 21:22 on the long variant, 25 swaps with a suggested failure rate of at most 10%, and no result is recorded yet.

commits
  • Harness: VARIANT selects an alternative objective and briefThe system
  • OperationsRegistry: once the operator has closed, setState and amend revert until the final review is closedThe system
  • Daemon: due reviews are opened before intake; no action is accepted on an operation that has closed until its final review is closed; prompts say soThe system
explored
  • Dry run attempt 1 failed on a wrong deploy RPC port
  • Dry run attempt 2 appeared to show a hole in the objective lock; the driver's clock had passed the end of the one-day objective
  • A contract change to block deactivateObjective and setKPIRegistry mid-cycle was abandoned: the contract already refused both mid-cycle
decided
  • No contract change for the attempt 2 result: it was not a contract bug
  • Fix the final-review path and run again
  • Add a VARIANT switch to the harness for the longer objective so the reviewer and council face a real amend or pause decision
open
  • Run 4 is in progress. Its first review is expected after about four hours of building, and no result is recorded yet
  • The operation reviews pull request is not merged and awaits a go-ahead
  • The Phase6Autodev All Tasks Completed test is still failing, as it was before this work
  • Retiring an operation returns little SUMA because escrow is released in proportion to the milestone score; fixing it means changing how ProposalManager funds one-milestone proposals
  • Review votes are expensive relative to the review period, and the reviewer and council can deadlock, with the daemon re-proposing continue without bound
  • Whether setKPIRegistry should key on the permanent lock rather than the active flag is undecided
  • Model-driven reviews on their own schedule were untested in the dev-chain dry run; run 3 had one real model review
  • In run 3 a retirement proposal came from the proposer outside a final review; the fix in run 4 targets this
The system

Like-button work set aside on a branch, live site left without it

The like button for this site's articles is saved on a branch, apart from the main version of the site. The saved code is the last version of the button that ran on the live site, with swipe to like and a strip tilted toward the thumb. The branch also holds the button's three server endpoints and its database setup. The main version of the site was not changed, so the live site stays without the button.

Three older design mockups were recovered and added next to that code: a small script, one mockup page and the index page of the design study. They came from earlier session logs. The folder that held the study had already been deleted and was never in version control, and a backup copy of the machine would not mount, so the rest of the mockups could not be saved.

The decision was to archive the work on its own branch rather than merge it into the site. Whether to pick the like button up again is undecided.

The recovered mockups won't open as working pages, because the shared stylesheet and script they rely on never appeared in a log. Two other mockup pages are lost, and the list of what else was lost is cut off partway through. The recovered files also date from before the design round on measuring how much a reader liked a piece.

commits
  • Keep the recovered like-study mockups alongside the last like buttonThis site
explored
  • Recovering the like-button design mockups from version control and from a machine backup; they were not in version control and the backup would not mount
  • Recovering mockup files from earlier session logs, which returned three files
decided
  • Archive the like-button work on a separate branch instead of merging it into the site
open
  • The recovered mockups won't open as working pages without the shared stylesheet and script, which never appeared in a log
  • Two mockup pages are lost, and the list of other lost items is incomplete
  • The recovered files predate the design round on measuring how much a reader liked a piece
  • Whether to pursue the like button is undecided