Opened #42 / sent #44 (the MNEMON_DATA_DIR prompt-path fix) last weekend. Been in the feat/core-control-plane branch since, read CONTRIBUTING, so asking before writing real code.
Read conflict_harness_test.go. Arm A (write-write -> CAS) and Arm B (read-stale, proposer declares G in its read-set, Deferred once G moves) are clear, and Arm E answers what I came in with: per-resource read-set is the default, whole-projection digest is the serializable candidate held open in §10. So the mechanism I'd have proposed already exists.
No arm covers the referential case: an edge pointing at a node that changes under it. Arm B catches a stale scalar dependency; I wanted the stale structural one. Wrote it as another arm in the same harness, two nodes plus an edge, all memory resources (edges aren't a kind yet, and with OpDelete out of P0 I model "endpoint removed" as an update that bumps the node). Two proposers on one log: P1 supersedes endpoint B, P2 creates the edge to B.
If P2 doesn't put B in its read-set, both commit and the edge stands on a node that moved under it, no conflict. If P2 declares B@1, it Defers ReadStale, same as Arm B. So the read-set closes it, but only if the proposer declares the endpoint.
Question: when edges come under the kernel (OpDelete being reserved made me read that as the direction), should the schema require an edge write to carry its endpoint versions, so integrity isn't proposer goodwill?
I checked whether this is reachable today and don't think it is: edges aren't a kernel resource, supersession isn't wired through the kernel, and the resources it does manage are flat with no cross-references. So this is a when-edges-land question, not a live bug. Say if I've read that wrong.
Arm's written and passing against the branch, suite green, vet clean. Can attach it or open a test-only PR. Mostly want to know if it's already on the radar for edges-under-kernel or if I'm poking at something settled.
Opened #42 / sent #44 (the MNEMON_DATA_DIR prompt-path fix) last weekend. Been in the
feat/core-control-planebranch since, read CONTRIBUTING, so asking before writing real code.Read
conflict_harness_test.go. Arm A (write-write -> CAS) and Arm B (read-stale, proposer declares G in its read-set, Deferred once G moves) are clear, and Arm E answers what I came in with: per-resource read-set is the default, whole-projection digest is theserializablecandidate held open in §10. So the mechanism I'd have proposed already exists.No arm covers the referential case: an edge pointing at a node that changes under it. Arm B catches a stale scalar dependency; I wanted the stale structural one. Wrote it as another arm in the same harness, two nodes plus an edge, all
memoryresources (edges aren't a kind yet, and with OpDelete out of P0 I model "endpoint removed" as an update that bumps the node). Two proposers on one log: P1 supersedes endpoint B, P2 creates the edge to B.If P2 doesn't put B in its read-set, both commit and the edge stands on a node that moved under it, no conflict. If P2 declares
B@1, it Defers ReadStale, same as Arm B. So the read-set closes it, but only if the proposer declares the endpoint.Question: when edges come under the kernel (OpDelete being reserved made me read that as the direction), should the schema require an edge write to carry its endpoint versions, so integrity isn't proposer goodwill?
I checked whether this is reachable today and don't think it is: edges aren't a kernel resource, supersession isn't wired through the kernel, and the resources it does manage are flat with no cross-references. So this is a when-edges-land question, not a live bug. Say if I've read that wrong.
Arm's written and passing against the branch, suite green, vet clean. Can attach it or open a test-only PR. Mostly want to know if it's already on the radar for edges-under-kernel or if I'm poking at something settled.