Satsuma's repairs now choose between upgrade and migration by where the defect is

Satsuma's products are sets of smart contracts that the system builds and then operates, and some of them hold funds. When one has a defect, there are two ways to repair it: an upgrade, which swaps the code behind a proxy while the address and holdings stay put, or a migration, which moves to a new contract. Three fixes to how the system chooses and carries out these repairs were committed in one session.

The first fix is about how the system checks that a deployed contract offers the function a repair needs. The old check, deployedExposes, looked at the wrong place: "deployedExposes read the code at the claim's address — the proxy — which only carries upgradeToAndCall's selector." Its replacement, exposesAt, follows the ERC-1967 slot to the contract the proxy points to and checks that as well as the proxy. It was tested on hardhat against a real proxy.

The second fix changes how the assessor, the step that decides how a defect gets fixed, picks the path. A rule that a declared migration always wins is gone; when both paths are real, the assessor now decides per issue. The decision, as written in the session: "The real question is where the defect lies: in the proxied contract's code (upgrade — address, holdings and bindings stay) or in a contract the upgrade can't touch, like the RemoteAccount holding the position or an immutable router address (migration)."

The third fix makes the background process that runs deployments keep the same repository name across deploy attempts.

In the same session, a test run of an experiment that has not been announced yet was checked on its live chains before being stopped and archived, so the archive carries real counts: 26 proposals and 26 executed on chain, every key result met, and the books matching. The three code repositories created for the run were deleted. The record does not say whether the new code has run in a later test.