fix(scheduler): percent-limit capacity reads maxmem/maxswap, not mem/swap (bug-1834)

update_limit_res_value() computed a percent-based limit's capacity from
the resource's own live, fluctuating value (e.g. "mem"), letting the
enforced cap drift with unrelated memory pressure instead of staying
pinned to a stable fraction of total capacity. instantiate_limit() now
resolves a static capacity-source resource once at instantiation time
(mem->maxmem, swap->maxswap, table-driven), stored on a new
xce_vres_t.percent_res field; a missing counterpart falls back to
today's behavior rather than failing instantiation.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC

.wolf/buglog.json

@@ -24711,6 +24711,37 @@
       ],
       "occurrences": 1,
       "last_seen": "2026-09-20T11:00:00Z"
+    },
+    {
+      "id": "bug-1834",
+      "timestamp": "2026-09-20T09:35:00Z",
+      "error_message": "User-identified design gap (not yet reproduced as a live symptom, code-traced and confirmed): for a percent-based limit whose `resname` is a dynamic/consumable resource (e.g. `mem`, `swap`), the limit's CAPACITY is computed as percent * the resource's current LIVE value, not percent * the resource's static total. This means the same limit's enforced cap drifts up and down as unrelated memory pressure on the host changes, rather than staying pinned to a stable fraction of total capacity (e.g. 'this queue may use up to 20% of the host's total memory' should not shrink because some other job is currently using more memory).",
+      "file": "src/scheduler/src/plugins/limit.c",
+      "root_cause": "update_limit_res_value() (limit.c:142-165) computes `val = get_resvals(array, 1, &(vres->res->idx), &val); val = val * vres->limit->val.val;` for any percent!=0 limit -- `vres->res` is resolved in instantiate_limit() (xcelimit.c:574) via a single key_find(resmgr, limit->val.resname, ...), i.e. exactly the resource named by the limit's OWN `resname` field. `resname` today serves two roles that this code conflates: (1) selecting the accounting/consumable resource the limit's virtual resource (`vres->vres`) is keyed against for usage tracking (correctly `mem`, since jobs consume `mem`), and (2) supplying the live base value multiplied by percent to derive capacity (currently ALSO `mem`, the dynamic worker-reported load index per .kiro/steering/resource-accounting.md -- 'mem is not maxmem... mem is a dynamic load index... refreshed on the worker's regular load-report cadence'). Role (2) should read a static/non-consumable resource instead (`maxmem` for `mem`, `maxswap` for `swap`) -- both already exist as registered per-host resources (src/configs/resources.yaml:108 `maxmem`, :112 `maxswap`, 'self-reported once by the worker at join time and never refreshed' per resource-accounting.md) so no new resource type is needed, only a change to which resource the percent multiplication reads. xce_limit_val_t/xce_limit_config_t (types.h:800-818) have no field today to name this second resource explicitly -- resname is single-purpose in the struct.",
+      "fix": "FIXED (2026-09-20). Added xce_vres_t.percent_res (src/include/xce/types.h) -- a resolved xce_resource_t* pointer for the percent-branch capacity read, kept separate from `res` (which stays the limit's own accounting resource, unchanged) so the two roles are no longer conflated. instantiate_limit() (src/lib/xcelimit.c) resolves it ONCE at instantiation time via a small table-driven static lookup (percent_capacity_resource_map[]: mem->maxmem, swap->maxswap) -- table-driven per user request, so a future dynamic/static pair (e.g. tmp/maxtmp) is a one-line addition. A missing/unregistered counterpart is NOT a hard failure: percent_res stays NULL and update_limit_res_value() (src/scheduler/src/plugins/limit.c) falls back to `res`, preserving today's behavior for any resource with no known static pair -- this is what keeps every pre-existing percent-limit test passing unchanged (they never register 'maxmem' in their resmgr fixtures, and none of them exercise update_limit_res_value()'s real computation anyway -- its existing white-box harness, test_repl_limit_table.c, stubs get_resvals()/put_resvals() as no-ops). New coverage: 4 unit tests in src/lib/testsuite/test_limit.c proving percent_res resolves to maxmem/maxswap for mem/swap, stays NULL for percent=0, and stays NULL (graceful fallback, not -ENOENT) for a percent-based limit on a resource with no known static counterpart (e.g. ncpus). Extended the shared src/lib/testsuite/test_resmgr_fixture.c/.h with maxmem/swap/maxswap test resources for this. Full lib (314 tests) and scheduler (85 test binaries) suites pass with zero regressions -- confirmed via raw testlog grep for ':FAIL:', not just the meson aggregate summary.",
+      "tags": [
+        "scheduler",
+        "limit-plugin",
+        "resource-accounting",
+        "mem-vs-maxmem",
+        "swap-vs-maxswap",
+        "percent-limit-capacity",
+        "update_limit_res_value",
+        "instantiate_limit",
+        "design-gap",
+        "user-identified",
+        "needs-owner",
+        "related-to-bug-1831",
+        "related-to-bug-1832",
+        "night_mem_pct",
+        "fixed"
+      ],
+      "related_bugs": [
+        "bug-1831",
+        "bug-1832"
+      ],
+      "occurrences": 1,
+      "last_seen": "2026-09-20T10:15:00Z"
     }
   ]
 }

.wolf/cerebrum.md

@@ -241,3 +241,4 @@
 - **(2026-09-15, controller-status Req 12 discovery/requirements) Any new `ctrlstatus`-response field that describes a property of the current PRIMARY (not just the responding node itself) forces an explicit standby-fidelity design fork, and it is worth asking the user about it up front rather than assuming.** Options are: (a) propagate the value to standbys (learned via heartbeat, matching the precedent Req 10 already set for committedLsn/committedConfigVersion) so any reachable node answers accurately, or (b) report "unknown" on a standby even when it already knows the primary's name/term. Asked explicitly for the new "primary elected in term X at time Y" fields; user chose (a), full learned fidelity — consistent with how `primaryName` (Req 2.3) and committed position (Req 10) already work off-primary. Default to proposing (a) as the recommended option when this fork recurs, since it's the established pattern for this spec, but still confirm rather than assume, since it materially changes design/task scope (heartbeat payload changes) vs. a pure read of local state.
 - **(2026-09-15) `controller-status`'s spec.json tracks its delta/reopen history in a single top-level `delta` object, not an array** — when starting a new delta cycle on top of one that already reached `validate_impl.decision: "GO"`, preserve the just-closed cycle by nesting it under `delta.prior_delta` (reopened_at/reason/new_requirements/impl_status) rather than overwriting it outright, so the requirement-number provenance ("which delta added Req N") stays recoverable from spec.json alone without needing git blame.
 - **(2026-09-20, bug-1833) `xceadmin`'s bundled JSON schemas exist in TWO copies on disk, and editing the wrong one is silently discarded on the next build.** `src/configs/schema/*.schema.json` is the REAL canonical source; `src/xceadmin/src/xcecommon/schema_files/json/*.schema.json` is a checked-in mirror that `meson-build.sh:104` unconditionally overwrites from the canonical copy on every `xceadmin` build (`cp "$SRC_DIR/configs/schema/"*.schema.json "$SCHEMA_DST/json/"`). Editing only the xceadmin-tree copy produces a schema change that appears correct in `git diff` but has ZERO effect on any real build or test run — confirmed by editing only that copy, rebuilding, and watching a new schema constraint simply not fire (no error, just silent no-op), then finding the sync line and editing both copies to fix it. **Before editing any file under `src/xceadmin/src/xcecommon/schema_files/`, grep `meson-build.sh` for a sync/cp step first** — the same "editing xceadmin source doesn't retroactively update an already-built snapshot" caution documented elsewhere in this file extends to specific FILES within the tree being silently resynced from elsewhere, not just whole-package staleness.
+- **(2026-09-20, bug-1834) `var` (rtti's `typeinfo.h`) is `#define var void*` — a raw macro, not a typedef — so `var a, b, c;` does NOT declare three `void*`s.** It expands to `void* a, b, c;`, which in C only pointer-types the FIRST declarator; `b` and `c` silently fall back to an implicit `int` (a legacy K&R extension GCC still tolerates by default), producing `-Wincompatible-pointer-types`/`-Wint-conversion` errors at every later use, often far from the declaration and easy to misread as unrelated call-site bugs. Hit writing 4 new tests in `test_limit.c` that copied `var umgr, qmgr, hmgr, pmgr;` from a working single-variable pattern elsewhere in the file. **Always declare each `var` on its own line** (`var umgr;` / `var qmgr;` / ...) — this codebase's own existing tests (`test_build_limit_ok1` et al.) already do this consistently; the comma-list form is the anomaly, not the norm, despite looking harmless for an ordinary typedef'd type.