Third autonomous run starts with stricter rules for the products it runs

Satsuma's autonomous system takes an objective, proposes the products it needs, votes on them, builds them and then operates them. A third run of this loop was started and watched through the opening of two products, their reviews, a halt, and several restarts of the process that drives the loop. In this run, the core contracts were part of the system's setup from the start.

Most of the session went into ownership: what the loop may do to a product it already runs when something goes wrong. Four commits landed on this behaviour. A product that holds state, such as an exchange whose trading pairs hold liquidity, now gets no redeploy fix until upgrade and migration payloads exist; a declared upgrade path is recorded, not executed. The first product of the run, an exchange, declares itself stateful with no upgrade path, so the loop will refuse to redeploy it and leave any issue open with the reason.

A halted product's operations never run, even if an on-chain vote to resume them executes, and a fresh halt is no longer mistaken for an old one. When the loop took the exchange on as a product it operates (adoption), one of the rules it must keep (an invariant) pointed to a measurement (a KPI) the loop could not encode, because the call was written with its arguments inline. That invariant is now dropped with a warning instead of the whole adoption failing, and the adoption proceeded with the rest. Drafts of product manifests also back off to one per half hour.

The process driving the loop was restarted after each of three of the fixes to pick them up. The exchange review was requested but had not run by the end of the session; after it, the run is to be stopped and archived. A normaliser for measurement calls written with inline arguments was described but is not yet committed.