docs(job-array-one-based-index): requirements, design and tasks; log bug-1898, bug-1899

Spec for numbering job-array elements from 1 (bug-1896): approved
requirements, a design reviewed over 20 rounds until clean (log in
research.md), and a 30-task plan. The design review found two live
apiserver defects, logged here: bracketed job_id/job_name filters are
never evaluated (bug-1898) and ControlJobByID re-dispatches earlier
selections (bug-1899).

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

.wolf/buglog.json

@@ -16693,6 +16693,60 @@
         "0fe27d4b"
       ],
       "record": ".wolf/bugs/bug-1897.md"
+    },
+    {
+      "id": "bug-1898",
+      "status": "open",
+      "status_updated": "2026-10-01",
+      "status_note": "newly logged",
+      "component": "apiserver",
+      "severity": "wrong-result",
+      "timestamp": "2026-10-01T04:26:54Z",
+      "last_seen": "2026-10-01T04:26:54Z",
+      "occurrences": 1,
+      "error_message": "apiserver ignores [..] job_id/job_name filters: CompConditions never evaluated\n\n**Observed:** found by code review, no failing run captured yet. Every REST selection value containing `[` and `]` is turned into a `CompFilterCondition`, removed from the plain filters and passed to `utils.BuildQueryOptions` as `CompConditions`, but `store.ExecuteQuery` evaluates only `opts.Conditions`:\n```go\n// src/frontend/apiserver/store/query.go:19-22\nif len(opts.Conditions) > 0 {\n    rows = FilterRows(rows, opts.Conditions)\n}\n// opts.CompConditions (utils/types.go:96, set at :454) is never read anywhere\n```\nSo the bracketed selection is silently dropped: `GetJobsInfo` (`job_id`/`job_name` with `[...]`, `controllers/jobs.go:186,494-510`), `GetJobByIDs` (`:780,961`) and `FetchJobList` (`:3311,3420-3436,3463`, used by filter-based `ControlJob`) return every row that matches the remaining filters.\n\n**Expected:** a selection such as `job_id:eq:X[2]` or `job_name:eq:foo[1-3]` returns only the matching array elements; a control command `xcecli jobs kill -J 'foo[1]'` acts only on element 1 of arrays named `foo`.\n**Impact:** wrong result, and for control a wrong target: `xcecli jobs list X[2]` lists unrelated jobs; filter-based control with `-J 'name[k]'` and no other filter matches all jobs, and its \"most recent job\" rule (`jobs.go:2752-2757`) then kills/stops/resumes the newest job in the cluster instead of the named element. `ControlJobByID` is not affected (it post-filters with `foundJob`).\n**Found by:** review (design review of spec `job-array-one-based-index`, 2026-10-01)",
+      "file": "src/frontend/apiserver/store/query.go, src/frontend/apiserver/utils/types.go, src/frontend/apiserver/controllers/jobs.go",
+      "root_cause": "TODO: required for fixed/partial",
+      "fix": "TODO: required for fixed/partial\n\nVerification:\n- Test: TODO: name + file; RED before the fix, GREEN after\n- Suites: TODO: suite results and build profile\n- Live: TODO: soak/deploy run, or n/a and why",
+      "tags": [
+        "apiserver",
+        "job-array",
+        "query",
+        "control",
+        "code-review"
+      ],
+      "related_bugs": [
+        "bug-1896"
+      ],
+      "fix_commits": [],
+      "record": ".wolf/bugs/bug-1898.md"
+    },
+    {
+      "id": "bug-1899",
+      "status": "open",
+      "status_updated": "2026-10-01",
+      "status_note": "newly logged",
+      "component": "apiserver",
+      "severity": "wrong-result",
+      "timestamp": "2026-10-01T05:10:35Z",
+      "last_seen": "2026-10-01T05:10:35Z",
+      "occurrences": 1,
+      "error_message": "ControlJobByID re-dispatches earlier selections on every later selection of one request\n\n**Observed:** found by code review, no failing run captured yet. In `ControlJobByID` the slice `successJobs` is declared once before the loop over the request's selections (`src/frontend/apiserver/controllers/jobs.go:2464`), is appended to inside that loop (`:2575-2583`), and the dispatch loop over the whole accumulated slice also sits inside it (`:2594-2617`):\n```go\nsuccessJobs := []map[string]interface{}{}            // :2464, outside\nfor _, ujobFilterCdArray := range allFiltCdArrays {   // one per selection\n    ...\n    successJobs = append(successJobs, ...)           // :2575\n    if len(successJobs) > 0 {\n        for _, successJob := range successJobs {      // re-sends all earlier ones\n            err = backend.ControlJob(...)              // :2611\n```\n**Expected:** each selected job receives the control action once per request; the response lists it once.\n**Impact:** wrong result: `xcecli jobs kill X[1],Y[2]` (or `kill A,B`) signals the first selection's jobs once per later selection (N selections -> the first job is sent N times); a repeated kill of an already-killed job can make the backend call fail and the request report an error; `BuildBatchOperationResponse` receives the accumulated slice, so the response lists earlier jobs repeatedly. Distinct from the out-of-scope duplicate-signal case of one element selected twice (job-array-one-based-index requirements).\n**Found by:** review (design review round 11 of spec `job-array-one-based-index`, 2026-10-01)",
+      "file": "src/frontend/apiserver/controllers/jobs.go",
+      "root_cause": "TODO: required for fixed/partial",
+      "fix": "TODO: required for fixed/partial\n\nVerification:\n- Test: TODO: name + file; RED before the fix, GREEN after\n- Suites: TODO: suite results and build profile\n- Live: TODO: soak/deploy run, or n/a and why",
+      "tags": [
+        "apiserver",
+        "control",
+        "job-array",
+        "code-review"
+      ],
+      "related_bugs": [
+        "bug-1898",
+        "bug-1896"
+      ],
+      "fix_commits": [],
+      "record": ".wolf/bugs/bug-1899.md"
     }
   ]
 }