Archived
An assignment was verified by resolving the node it was made on. The verify that matters is resolution over all of them: a module offering a mesh-scoped provision stops offering it the moment its own node stops resolving, so an assignment could be reported as fine while it took that provision away from every consumer elsewhere. Those consumers were then told "nothing in this mesh provides it", naming as the remedy a module that was already assigned — a wrong answer about a machine nobody had touched. That is novox/hq 04-ISSUES/017's shape exactly: an action succeeds into a state its own verify rejects, and it does so because the action's own test is not the test the verify uses. 017's remedy was to make them the same test, and this makes them the same test. The assignment is still kept, and that is the other half of the decision. Assignment is not an ordering: a consumer assigned before its provider does not resolve for as long as it takes to assign the provider, and refusing the first half of a pair would make the order somebody types two commands in part of the mesh's rules. So `assign` and `unassign` now name every OTHER machine that cannot be worked out as things stand, in the mesh's own words, beside whatever they already said about this one. It reports the state and never claims causation — saying "this assignment broke laptop" would mean resolving the whole mesh twice and would still be a guess about which of several changes did it. It costs a resolution per machine. Assignment is a person typing a command, and being told which machines this just blocked is worth more than the milliseconds. This is what a four-node raise read as "bumping a module's version broke provider recognition". It was neither the version nor the provider: nothing in this codebase reads the version column, every lookup is keyed on the module name alone, and a test in the previous commit now says so. It was one machine's set of assignments, and nothing said so. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF