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.
- 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
- 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
- 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
- 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