Add a brainstorm on developing changes that touch real machines #24

Merged

vnprc merged 1 commit from agent/dev-process-brainstorm into master

2026-07-30 22:36:21 +01:00

allod-agent commented

2026-07-30 20:15:20 +01:00

Member

The document's central finding is that merging to master was never the dangerous act. A machine is built from the deploy flake's committed lock, so nothing reaches a running VM until that lock advances and the machine is rebuilt. The proposal therefore keeps the current merge cadence and adds one question before each merge — does this change any machine actually run? — plus a deliberate activation step and one throwaway machine that takes risky changes first.

Filed in brainstorm/ rather than dev-plans/ because it is not scoped work yet: adopting it means memory edits, possibly one tool, and a habit change, and none of that is decided.

Refs allod/strategy#20

Risk

R0. A brainstorm document. No runtime behaviour, no generated behaviour, no state.

Validation

The command the proposal rests on was executed against the real composition root while the document was written: the transitive override syntax works, a warm evaluation is about six seconds per machine, and the operator's development machine came out byte-identical under an unmerged branch — which is the inertness proof the proposal asks every landing step to produce.

A brainstorm document on how we develop changes that touch real machines, prompted by a near-miss this week: an inventory field was set on the operator's own development machine, which would have converted it to a new VM runtime the moment a later milestone started reading that field. Nothing in the process caught it; a human noticed. The document's central finding is that merging to master was never the dangerous act. A machine is built from the deploy flake's committed lock, so nothing reaches a running VM until that lock advances and the machine is rebuilt. The proposal therefore keeps the current merge cadence and adds one question before each merge — does this change any machine actually run? — plus a deliberate activation step and one throwaway machine that takes risky changes first. Filed in `brainstorm/` rather than `dev-plans/` because it is not scoped work yet: adopting it means memory edits, possibly one tool, and a habit change, and none of that is decided. Refs allod/strategy#20 ## Risk R0. A brainstorm document. No runtime behaviour, no generated behaviour, no state. ## Validation The command the proposal rests on was executed against the real composition root while the document was written: the transitive override syntax works, a warm evaluation is about six seconds per machine, and the operator's development machine came out byte-identical under an unmerged branch — which is the inertness proof the proposal asks every landing step to produce.

allod-agent added 1 commit

2026-07-30 20:15:21 +01:00