chore(wolf): checkpoint buglog.json (960 bugs)

.wolf/buglog.json

@@ -17216,6 +17216,35 @@
       ],
       "occurrences": 4,
       "last_seen": "2026-08-18T08:00:00Z"
+    },
+    {
+      "id": "bug-1579",
+      "timestamp": "2026-08-18T09:00:00Z",
+      "error_message": "run-resource-verify.sh's new controller-side check (task 6.2, query_controller_resvals()) reported a live MISMATCH for the default resource set's 'cpuf' resource: 'controller check: cpuf -> MISMATCH: injected=9.5 observed=0.000000', even though inject_resources()'s own resupdate call reported 'cpuf=9.5 -> accepted' moments earlier in the same run.",
+      "file": ".claude/skills/xce-test-resources/run-resource-verify.sh (not a bug in this file's new logic -- see root_cause); src/controller/worker.c (add_hostattrs_resvals(), apply_worker_dead_mutation()) is the production code responsible for the behavior being (correctly) observed",
+      "root_cause": "NOT A BUG -- documented, intentional controller production behavior colliding with this test script's own multi-process session structure. inject_resources() (task 6.1) runs join+resupdate+quit in ONE xce_test process; the 'quit' disconnects the synthetic worker's TCP connection to the controller at the end of that same script. query_controller_resvals() (task 6.2) then runs its resval query in a SEPARATE, LATER xce_test process/session -- by which point the synthetic worker is already gone from the controller's perspective. 'cpuf' is one of worker.c's N_HOST_ATTRS resources (add_hostattrs_resvals(), worker.c:260-287: type/model/cpuf/maxcpus/maxmem/maxswap/maxtmp/ndisks), which mark_worker_unavail() -> apply_worker_dead_mutation() (worker.c:704-716) deliberately RESETS (reset_hostattrs_unknown() then re-applies add_hostattrs_resvals()) whenever a worker is marked dead/disconnected -- correct, intentional production behavior for a REAL worker daemon that has genuinely gone away (you don't want a dead worker still advertising stale cpu capacity for scheduling). Every OTHER default resource (r15m, pg, ls, it, swp, io, tmp, mem -- none of which are in worker.c's N_HOST_ATTRS list) is a generic, non-host-attrs resval that persists correctly across worker disconnect and reported MATCH. Confirmed via live isolation: re-running with the exact same 8 non-cpuf resources reported 8/8 MATCH; re-running the mixed accept/reject scenario (mem=5, not-a-real-resource=1) correctly reported mem MATCH and skipped the rejected resource entirely (no query attempted). design.md's own sequence diagram does not show a worker disconnect between the resupdate leg and the resval-query leg, implying the intended flow keeps the synthetic worker connected throughout verification -- task 6.1's single-shot 'join;resupdate;quit' session structure deviates from that, but only resources that collide with worker.c's host-attrs reset list are affected.",
+      "fix": "NOT FIXED (deliberately, per requirements.md's Boundary Context: 'fixing unrelated bugs surfaced incidentally during verification... should be reported, not silently fixed'; also, DEFAULT_RESOURCE_ARGS is task 6.1's committed array, explicitly reserved for finalization at task 7.1 per tasks.md's Implementation Notes -- 'before task 7.1 finalizes the actual default resource set'). query_controller_resvals()'s own comparison/parsing logic is correct and was validated independently (8/8 MATCH on a cpuf-free resource set, plus direct synthetic-input tests of the controller_values_match() comparison helper). Two options for whoever finalizes the default set / builds task 7.1's verdict aggregation: (a) drop 'cpuf' from DEFAULT_RESOURCE_ARGS (also applies transitively to type/model/maxcpus/maxmem/maxswap/maxtmp/ndisks if ever added) in favor of a host-attrs-safe numeric name, or (b) restructure inject_resources() so the synthetic worker's xce_test session stays connected (no 'quit') across all per-layer checks, disconnecting only at final cleanup -- matching design.md's sequence diagram. Only affects the CONTROLLER-layer check (a live resval query, sensitive to current connection state); the scheduler/apiserver checks (tasks 6.3/6.4) are trace-log-tail based and read what was logged at apply-time, so they are immune to this ordering regardless of subsequent worker disconnect.",
+      "tags": [
+        "false-positive",
+        "test-tooling",
+        "resource-value-verification",
+        "run-resource-verify.sh",
+        "task-6.2",
+        "controller-check",
+        "cpuf",
+        "worker-disconnect",
+        "host-attrs",
+        "add_hostattrs_resvals",
+        "mark_worker_unavail",
+        "not-a-bug",
+        "default-resource-set",
+        "task-7.1-followup"
+      ],
+      "related_bugs": [
+        "bug-1578"
+      ],
+      "occurrences": 1,
+      "last_seen": "2026-08-18T09:00:00Z"
     }
   ]
 }