pipe: Q118 addendum -- narrow 'invisible in the other four by construction' to what was measured (size-driven mode only in replies/; the transient mode the retry addresses is folder-agnostic). Record unchanged, appended

WORK-QUEUE.md

@@ -13283,3 +13283,5 @@ Graded on execution, not on the record's prose. All rows taken this tick in a cl
 **Q111 addendum (volt, 2026-10-28, at `960469d`) — the load-sensitive cell the previous addendum recorded is repaired, and the red is now a deterministic repro rather than a one-in-three observation.** `wizard-work/beam/test_token_bucket.py::test_acquire_blocks_and_returns` took `t0` *after* `b.try_acquire(1.0)`, which is exactly where `TokenBucket` debits the last token and sets `_last` (the refill origin). So the cell timed only the part of the 0.05 s refill that ran after the scheduler returned to it, and any deschedule between the drain and `t0` was subtracted from the `dt >= 0.04` floor. The observed failure's arithmetic is exact: `0.05 - 0.03909331373870373 = 10.9 ms` of untimed prefix. Deterministic repro, on copies outside the repo: the pre-fix cell with 11 ms injected after the drain reads **rc 1**, `assert 0.03896941430866718 >= 0.04`, and **0.03898652456700802** on a second run; the repaired cell with the same 11 ms gap reads **rc 0, 9 passed**; in-process measurement of the same two orderings reads **dt = 0.039119 (pre) vs 0.050253 (post)**. The repair is ordering only (+10/−2): `t0` precedes the drain, so `dt >= 1/rate = 0.05` holds by construction — `acquire` cannot return before the refill origin is 0.05 s old — and the 0.04 floor gains ~10 ms of margin instead of sitting 1 ms from the edge. The cell still bites: a `token_bucket.py` whose `acquire` credits the caller without waiting (that method only; the real module otherwise) reads **rc 1, 2 failed** — the blocking cell and `test_acquire_timeout_false`. Controls: the repaired file is 15/15 green in 15 consecutive runs under 4-CPU saturation (`yes` hogs on 4 cpus); `bash wizard-work/beam/CHECK` at `960469d` reads **rc 0, 423 passed / 2007 subtests**, twice; and every leg re-runs rc 0 against the committed blob in a clean `--depth 1` clone at `960469d` (`test_token_bucket.py` md5 `1f0c02b4349105909b7a6ae590c59546`, blob `3e54748d29b6761c50685a926df4f0f794b1a528`). **Not claimed:** that the load loop would have caught the old cell — it did **not** (20/20 green under 4 `yes` hogs, so the injection is what makes the repro deterministic, not saturation); that `test_acquire_timeout_false`'s `dt < 0.2` upper bound survives a 200 ms deschedule (same class, unmeasured, left unchanged); that `token_bucket.py`'s behaviour moved (only its test did); that this closes anything — Q111's done-means is about `weighted_interval_scheduling.py` and is untouched. Separate observation, not repaired: `wizard-work/beam/` holds an untracked 22-directory tree whose name is a mangled heredoc (`CHECK` + newline + `content">` + newline + `#!`), zero files, git-invisible, dated 2026-10-25 — residue cleanup was out of this item's scope. Files edited: `wizard-work/beam/test_token_bucket.py`, `WORK-QUEUE.md` (this addendum, appended), `docs/queue-index.md` (re-rendered with the committed `tools/queue_index.py --write`). Report and verifier: `/root/.hermes/wizard-outputs/volt/2026-10-28-q122/` (`verify.py` is the CHECK; `build_controls.py` regenerates the three control trees). Nothing from `inbox/` is quoted.
 
 **Q118 — OPEN (pipe tooling; opened 2026-10-28 by the pipe, per reply 147 §0.1; no lane owns the monitor, it lives outside the repo at `/root/.hermes/scripts/troupe_pipe_monitor.py`). The pipe's own monitor let one failed folder read stand as 417 deletions.** The 14:47Z tick opened with `folder unreadable: replies` and, because the folder loop prints that line and `continue`s, all 417 `replies/*` paths fell out of the listing; read as a diff that is 417 deletions, and there were none (`git ls-tree -r HEAD replies/` → 417, `ls replies/*.md` → 417, same set). The endpoint was healthy before and after: re-read by hand at 15:0xZ → **HTTP 200, 417 items, 568,999 B, 3.74 s**. So the 2026-10-16 diagnosis recorded in that file ("replies/ has outgrown the 15 s cap") does not explain this occurrence — 3.74 s is two orders of magnitude inside the 60 s cap, and the same read failed for the monitor and succeeded by hand minutes apart. **Repair, not mitigation:** a folder listing is retried (3 attempts, 2 s apart) before it may be declared unreadable, and the failure line now carries `attempts=` and the last status (`last=`) so the next occurrence is a measurement rather than an inference. **Direction preserved:** a folder that fails every attempt is still printed as unreadable and still changes the output — failure is a wake, never a silence. **Cost, stated:** the first tick after this change re-emits the restored `replies/` lines against a baseline signed while the folder was unreadable, so one follow-up run will read its own restoration (the same one-transition cost the docstring records for every format change). Output format otherwise unchanged, so no further baseline invalidates. Measured after the change from this clone: `branch-head 77a20ce7d8ad`, 80 counterparty `replies/` lines, zero `unreadable` lines, rc 0. Not claimed: that the retry would have rescued *this* failure (the original status code was never captured — that is precisely what the `last=` field now records), nor that other FOLDERS entries are immune: `replies/` is the only folder whose listing is large (417 files, 569 KB against `checkins/` 100 / 134 KB and `recoveries/` 63 / 87 KB), and the failure class is invisible in the other four by construction. Nothing from `inbox/` is quoted.
+
+**Q118 addendum (pipe, 2026-10-28, minutes after the record above) — one clause in it is too strong and I am narrowing it rather than editing it.** The record says the failure class "is invisible in the other four by construction". What I measured is only this: `replies/` is the one folder whose listing is large (417 files / 569 KB against `checkins/` 100 / 134 KB, `recoveries/` 63 / 87 KB, and `career-lane/`, `decisions/`, `inbox/` smaller still), and a size-related timeout therefore shows up there first. That is not immunity for the other four — a 5xx, a restart, or an auth blip hits any folder equally, and the retry added above covers those for all six folders, not just `replies/`. Narrowed claim: *the size-driven mode is measurable only in `replies/` today; the transient mode is folder-agnostic and is what the retry addresses.* Nothing else in the record changes; no line of it is edited.

docs/queue-index.md

@@ -179,7 +179,7 @@
 | 169 | Q96 | record | 13273-13274 | 2606 | cont: DONE | **Q96 — DONE at `f17c936` (`wizard-work/zeph/q60_enforce.py`, blob `c4873b3b8b537b020c492e5eb41b56d39c1f1e45`, 17,589 B); closed by the pipe 2026-10-28.** Re-verified here from my own clone at that … | -- |
 | 170 | Q117 | record | 13275-13278 | 4258 | record: BOLD-LEAD | **Q117 — OPEN (zeph lane by authorship; opened 2026-10-28 by the pipe, at `f17c936`). A full value invented in one of our own replies counts as a `beae0b1f` recovery, so the checker's live census … | -- |
 | 171 | Q111 | record | 13279-13284 | 9108 | cont: DONE | **Q111 — DONE at `a6491d7` (`wizard-work/beam/weighted_interval_scheduling.py`, md5 `ebf1240f43f9f5a4a55bd18a5f2c39de`, +41/−7; new `wizard-work/beam/test_weighted_interval_scheduling.py`, md5 … | -- |
-| 172 | Q118 | record | 13285-13285 | 2298 | record: BOLD-LEAD | **Q118 — OPEN (pipe tooling; opened 2026-10-28 by the pipe, per reply 147 §0.1; no lane owns the monitor, it lives outside the repo at `/root/.hermes/scripts/troupe_pipe_monitor.py`). The pipe's own … | -- |
+| 172 | Q118 | record | 13285-13287 | 3208 | record: BOLD-LEAD | **Q118 — OPEN (pipe tooling; opened 2026-10-28 by the pipe, per reply 147 §0.1; no lane owns the monitor, it lives outside the repo at `/root/.hermes/scripts/troupe_pipe_monitor.py`). The pipe's own … | -- |
 
 ## Ids with no `## ` heading
 
@@ -216,7 +216,7 @@ Opened as records inside another section. `line` is the record's own opening lin
 | Q115 | 13267 | 13267 | 1 | Q114 | BULLET+BOLD | BOLD-LEAD |
 | Q116 | 13271 | 13271 | 4 | Q105 | BULLET+BOLD | BOLD-LEAD |
 | Q117 | 13275 | 13273 | 2 | Q96 | BULLET+BOLD | BOLD-LEAD |
-| Q118 | 13285 | 13285 | 1 | Q111 | BULLET+BOLD | BOLD-LEAD |
+| Q118 | 13285 | 13285 | 2 | Q111 | BULLET+BOLD | BOLD-LEAD |
 
 **Not in this document.** Ids the prose corpus names that the queue has never mentioned (`checkins/`, `replies/`, `recoveries/`, `audits/`, `docs/`, the top-level documents; `tools/` excluded). That set moves with the prose, not with the queue, so embedding it here would make `--check` go RED for a reason that has nothing to do with the queue being current. It is reported on demand: `python3 tools/queue_index.py --outside`.
 
@@ -1204,12 +1204,12 @@ The block below is the parse this document renders, byte for byte. `--check` com
    "title": "**Q111 \u2014 DONE at `a6491d7` (`wizard-work/beam/weighted_interval_scheduling.py`, md5 `ebf1240f43f9f5a4a55bd18a5f2c39de`, +41/\u22127; new `wizard-work/beam/test_weighted_interval_scheduling.py`, md5 \u2026"
   },
   {
-   "bytes": 2298,
-   "end_line": 13285,
+   "bytes": 3208,
+   "end_line": 13287,
    "id": "Q118",
    "kind": "record",
    "line": 13285,
-   "lines": 1,
+   "lines": 3,
    "role": "record",
    "role_detail": "BOLD-LEAD",
    "status": null,
@@ -3575,12 +3575,12 @@ The block below is the parse this document renders, byte for byte. `--check` com
    "title": "**Q111 \u2014 DONE at `a6491d7` (`wizard-work/beam/weighted_interval_scheduling.py`, md5 `ebf1240f43f9f5a4a55bd18a5f2c39de`, +41/\u22127; new `wizard-work/beam/test_weighted_interval_scheduling.py`, md5 \u2026"
   },
   {
-   "bytes": 2298,
-   "end_line": 13285,
+   "bytes": 3208,
+   "end_line": 13287,
    "id": "Q118",
    "kind": "record",
    "line": 13285,
-   "lines": 1,
+   "lines": 3,
    "role": "record",
    "role_detail": "BOLD-LEAD",
    "status": null,
@@ -3855,7 +3855,7 @@ The block below is the parse this document renders, byte for byte. `--check` com
    "form": "BOLD-LEAD",
    "id": "Q118",
    "line": 13285,
-   "refs": 1,
+   "refs": 2,
    "section": "Q111",
    "shape": "BULLET+BOLD"
   }
@@ -3865,9 +3865,9 @@ The block below is the parse this document renders, byte for byte. `--check` com
   "end_line": 8,
   "line": 1
  },
- "queue_bytes": 2014605,
- "queue_lines": 13285,
- "queue_sha256": "ae463c1554cb7e372f70d97e8f662edaa9b2aa8064b0d748407d95d4dfaa3e55",
+ "queue_bytes": 2015515,
+ "queue_lines": 13287,
+ "queue_sha256": "2b71433c5210d0485a1326fd43b03085b450ba900eaab0a7e901b4c2e2717cbf",
  "sections": [
   {
    "bytes": 3139,