chore(scheduler-sim-diagnostics): mark container-only task groups complete

Tasks 2 and 3 are container-only major headers (per tasks-generation.md's
hierarchy rule); all their executable sub-tasks (2.1-2.3, 3.1-3.2) are
already complete. Bookkeeping only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC
This commit is contained in:
Rongsong Shen 2026-09-17 15:37:43 +00:00
parent 57b93f2942
commit 77924f787e
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2

View file

@ -8,7 +8,7 @@
- _Requirements: 1.1, 1.2, 1.4, 2.1, 3.1_
- _Boundary: Limit Plugin Accessor_
- [ ] 2. Core: Limit lookup and configured-setting display
- [x] 2. Core: Limit lookup and configured-setting display
- [x] 2.1 Implement name/all resolution with correct absence messaging
- New white-box test file `test_repl_limit_table.c` created (sibling of `test_repl_resource_table.c`, own `#include` set covering `plugins/limit.c` and `resource.c` for real — not stubbed — per `design.md`'s build-wiring risk note citing bug-1762's precedent)
- `repl_info_limit(sim, arg)`: `arg == "all"` iterates `limit_get_configured_limits()`; `NULL`/empty prints "no limits configured" (Requirement 1.7); `arg != "all"` does a `key_find()` by name (not a scan) on the same handle, printing "no such limit '<name>'" (Requirement 1.3) for a `NULL` handle or a miss — a `NULL` handle on this path is never treated as "no limits configured," matching that message's own `all`-only scoping
@ -28,7 +28,7 @@
- Observable: two REPL fixtures — one percent-based limit on a per-host resource without explicit per-host scoping (note appears), one absolute-value or explicitly-global-scoped limit (note does not appear)
- _Requirements: 1.6_
- [ ] 3. Core: Live accounted-usage display
- [x] 3. Core: Live accounted-usage display
- [x] 3.1 Display usage for cluster-wide (non-host-scoped) limit instances
- Iterate `limit_get_usage_instances()`, filter by `vres->limit == matched_limit`; for a GLOBAL/SHARED `vres`, read capacity from `core.sharedInst[idx]` and accounted usage from `core.sharedInUse[idx]`
- Existence-of-instance and zero-usage are distinct: zero matching `xce_vres_t` (no capacity entry at all) prints "no active usage instance yet" (Requirement 2.2); a matched `xce_vres_t` whose `sharedInUse[idx]` is `NULL`/absent instead displays a genuine `accounted=0` (it has been evaluated and has a real capacity, just nothing charged against it yet) — existence is gated on the capacity read, never on the in-use read