The approval is the checkpoint, and what a declaration is #10
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/hq#10
Reference in New Issue
Block a user
Two decisions, both approved in conversation before merging.
0042 — the approval is the checkpoint
§2 read "never merge your own", written for people. Applied to an agent it contradicted itself: it could merge nothing, because it wrote everything. So every merge here was either performed by its author or not performed at all.
Settled as the operator's own rule: every merge into the main branch is notified and approved. Notified means proposed and said out loud, not performed and mentioned. Approved means a person says yes to that merge. Who performs it is not worth constraining — the checkpoint already happened.
Rejected the literal reading, because an operator clicking merge dozens of times without reading is the shape of a checkpoint rather than one, and the record then claims a review that did not happen.
What approval is not, because this is the half that rots: a standing permission cited forever, an instruction to do the work read as approval to merge it, silence, and the author's own judgement that it is ready.
§2 amended, synced, and verified by reading the rule back out of the live page — the previous sync reported success and changed nothing.
0043 — what a declaration is
JSON, because the standard library carries it and carries no YAML, and a YAML declaration would put a third-party parser inside the one binary whose whole argument is that it needs nothing.
An ordered list, because ordering is a decision. A host deriving order from declared dependencies would be deciding the thing most likely to differ between what the control plane intended and what the machine does.
Unknown is refused, never skipped — an unknown version, type or field refuses the whole declaration. A host that skipped what it did not understand would apply most of it and report success.
Complete for what the host owns, and only that. It removes what it applied and is no longer declared, known from the store rather than inferred, and never removes what it did not create.
Where the list comes from
Added after review, because the record specified what the host accepts and said nothing about what produces it.
By hand today, in
substrate.lock— the first node has no control plane to derive anything from. Afterwards the control plane derives it from module assignments, resolved configuration, and what each module declares it needs, ordered by the dependency graph — research 011.So the record is complete on the consumer side and deliberately silent on the producer side. That is a legitimate order to settle them in: the host must refuse what it does not understand whoever wrote it.
And one consequence that only appeared when the question was asked: if the graph turns out not to determine a total order, that is 011's problem and not the host's. The host is still handed a list and still applies it as given — recorded because it is the seam where a future difficulty would otherwise try to migrate into tier 0.
Noted
Both records were marked
acceptedbefore they had been read. That is the inversion this repository keeps catching, committed by the thing that catches it. They are approved now, so the field is true — which it was not when it was written.