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

.wolf/buglog.json

@@ -17286,6 +17286,30 @@
       "related_bugs": [],
       "occurrences": 1,
       "last_seen": "2026-08-18T12:10:00Z"
+    },
+    {
+      "id": "bug-1582",
+      "timestamp": "2026-08-18T13:00:00Z",
+      "error_message": "run-resource-verify.sh task 7.1 round-1 review REJECTED: independent reviewer killed the live scheduler process mid-run (after deployment confirmed up, before its trace-log poll completed) and got VERDICT line `unreachable=0 mismatches=1` plus FAILURE line `status=MISMATCH ... observed=` -- should have been `unreachable=1 mismatches=0` and `status=UNREACHABLE ... observed=<none>`.",
+      "file": ".claude/skills/xce-test-resources/run-resource-verify.sh",
+      "root_cause": "main()'s record-building loop derived sched_ok/api_ok (feeding aggregate_verdict()) by testing whether the SCHEDULER_OBSERVED[$vname]/APISERVER_OBSERVED[$vname] associative-array KEY EXISTED (`[ -n \"${arr[k]+x}\" ]`). But query_scheduler_resvals()/query_apiserver_resvals() (tasks 6.3/6.4, already-approved) unconditionally SET these array entries for every accepted+checked resource -- including on a genuine UNREACHABLE/timeout, where the value is just set to the empty string \"\". Since the key always existed, sched_ok/api_ok were always 1 regardless of reachability, so aggregate_verdict() never saw the real UNREACHABLE status -- it fell through to comparing the injected value against an empty string, which reads as MISMATCH instead of UNREACHABLE. Contradicted Requirement 6.3, design.md's Error Handling (\"Layer unreachable ... labeled UNREACHABLE distinctly from MISMATCH ... not a silent skip\"), and this task's own SKILL.md documentation of the same behavior. Note: the analogous ctrl_ok derivation (from CONTROLLER_OBSERVED array-key existence) is NOT affected -- query_controller_resvals()/internal_controller_check() has no separate UNREACHABLE concept at all (a query failure there aborts the whole run via fail()), so array-key existence is an accurate proxy for that layer specifically.",
+      "fix": "Round-2 remediation: derive sched_ok/api_ok from SCHEDULER_CHECK_RESULTS[$vname]/APISERVER_CHECK_RESULTS[$vname] instead (already correctly populated by tasks 6.3/6.4 with exactly \"MATCH\", \"MISMATCH: injected=... observed=...\", or \"UNREACHABLE: ...\") -- a leading \"UNREACHABLE:\" means ok=0, anything else (including a defensive __UNCHECKED__ fallback for a missing key, which should never happen given both query_*_resvals() functions iterate the same accepted-name list this loop reads) means ok=1 with the real observed value. Also extracted main()'s inline record-building loop into a standalone build_verdict_records_from_tsv() function (populates global VERDICT_RECORDS) so a synthetic test can exercise main()'s ACTUAL data-marshaling code (not just aggregate_verdict() called directly with hand-built records, which is what round-1's task 8.2-style synthetic tests did and which structurally could never have caught this bug). Live-reproduced the reviewer's exact scenario (kill scheduler right after deployment confirms up, before inject_resources()/query_scheduler_resvals() ever runs) and confirmed the VERDICT line now correctly shows `unreachable=9 mismatches=0` (all 9 default-set resources) with `status=UNREACHABLE ... observed=<none>` FAILURE lines, apiserver/controller layers unaffected (still MATCH). New synthetic regression test (scenario E, using build_verdict_records_from_tsv() directly) added and confirmed to fail against a reverted copy of the old buggy logic (unreachable=0 mismatches=2) and pass against the fix (unreachable=1 mismatches=1 across a mixed good/schedbad/apibad/rejected batch) -- proving the test is meaningful, not tautological.",
+      "tags": [
+        "bash",
+        "resource-value-verification",
+        "task-7.1",
+        "aggregate_verdict",
+        "unreachable-vs-mismatch",
+        "round-1-rejected",
+        "round-2-fixed",
+        "sched_ok",
+        "api_ok"
+      ],
+      "related_bugs": [
+        "bug-1581"
+      ],
+      "occurrences": 1,
+      "last_seen": "2026-08-18T13:00:00Z"
     }
   ]
 }