docs(scheduler-allocator-runner): requirements, design and tasks; log bug-1892 and bug-1893

Requirements reviewed and revised (seqjob per-bucket reset, nslots/nhosts,
bug-1893 fix in the runner), design and 11-task plan generated and reviewed.
bug-1892: unsatisfy_() reads index-keyed uncommitted amounts by position.
bug-1893: allocators' shared pend-reason loop reads past the unmet list.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

.wolf/bugs/bug-1893.md

@@ -0,0 +1,80 @@
+---
+id: "bug-1893"
+status: "open"
+status_updated: "2026-09-30"
+status_note: "newly logged"
+component: "scheduler"
+severity: "wrong-result"
+timestamp: "2026-09-30T03:58:52Z"
+last_seen: "2026-09-30T03:58:52Z"
+occurrences: 1
+files: ["src/scheduler/src/plugins/seqjob_allocator.c", "src/scheduler/src/plugins/parjob_allocator.c"]
+tags: ["scheduler", "allocation", "preason", "code-review"]
+related: ["bug-1892"]
+---
+
+# bug-1893: xce_scheduler allocators add spurious resource-0 shared pend reasons (loop reads past unmet list)
+
+## Description
+**Observed:** found by code reading, so there is no failing run yet. When the shared-resource check
+fails, both allocators add the pend reasons with
+```c
+for (i = 0; i < ctx->alloc_req.shared.count; i++) {
+    rc = vget(core->resmgr, ((int*)ctx->unmeet.idxs.data)[i], (void**)&r);
+    if (rc <= 0) continue;
+    add_job_preason(reason->reasons, PREASON_NO_RESOURCE, NULL, r->name);
+}
+```
+(`seqjob_allocator.c` `my_alloc`, `parjob_allocator.c` `my_alloc`). The loop
+bound is the number of *requested* shared resources, but `ctx->unmeet` holds
+only the *unmet* ones, packed at `[0, unmeet.count)` by `unsatisfy_()`
+(`resource.c:152-165`). Its arrays were `calloc`ed with capacity
+`shared.count` (`resource.c:280`), so entries `[unmeet.count, shared.count)`
+are 0.
+
+**Expected:** iterate `i < ctx->unmeet.count` (as the host path does,
+`resource.c:566`), giving one `NO_RESOURCE` reason per unmet shared resource.
+
+**Impact:** wrong pend reason, noise level. When a job requests N shared
+resources and only M < N are unmet, the loop adds N - M extra
+`PREASON_NO_RESOURCE` reasons naming whatever resource has index 0 (if one
+exists), which that job may never have requested. Main reason and allocation
+decision are unaffected. No out-of-bounds memory access (the tail is inside the
+allocation).
+
+**Found by:** review of the `scheduler-allocator-runner` requirements
+(2026-09-29); the loop moves into the framework runner in that spec.
+
+## Environment
+- OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
+- libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
+- Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
+- Build: asan (xce.build)
+- Code: scheduler-framework @ a370d724-dirty
+- Deployment: n/a: found by code reading; any deployment where a job requests 2+ shared resources and only some are short
+
+## Reproduction
+1. `git checkout a370d724`; read the loop in
+   `src/scheduler/src/plugins/seqjob_allocator.c` / `parjob_allocator.c`
+   `my_alloc()` (after `sched_check_shared_satisfy`), and
+   `src/scheduler/src/resource.c:130-169,266-316`.
+2. Unit-test sketch: resource idx 0 = `slots`; two shared resources A (idx 7,
+   plenty) and B (idx 8, total 0); a seqjob primary requesting 1 of each.
+   Expected: exactly one host-less reason (`NO_RESOURCE`, res "B"); today a
+   second reason names `slots`.
+- Frequency: deterministic (by code reading; no test exercises it yet)
+- Evidence: not kept (code reading only)
+
+## Root cause
+TODO: required for fixed/partial
+
+## Fix
+TODO: required for fixed/partial
+
+## Verification
+- Test: TODO: name + file; RED before the fix, GREEN after
+- Suites: TODO: suite results and build profile
+- Live: TODO: soak/deploy run, or n/a and why
+
+## References
+- Related: none