diff --git a/WORK-QUEUE.md b/WORK-QUEUE.md index cbe8813..98fb05e 100644 --- a/WORK-QUEUE.md +++ b/WORK-QUEUE.md @@ -13673,3 +13673,27 @@ CHECK: bash wizard-work/volt/CHECK-q129 **Q129 addendum — one more file than the record above lists: `tools/path_claim_baseline.tsv` gains one `RENAMED` row, and the reason is the record's own prose.** Measured on the landing tree before the row existed: `path_claim_check.py --repo . --rev WORKTREE` read `9637 distinct paths, 261 missing, 1 new against the baseline`, and the one row was `4x checkins/2026-10-30-timmy-tm-formidable.md first WORK-QUEUE.md:13655 [NEW -- not in the baseline]` — the record naming the name it renamed away, which the scanner is right to grade as a claim on a path that is not in the tree. The fix is the ledger's stated mechanism and its own precedent, not a reworded record: `checkins/2026-10-19-zephyrus-sovereignty.md` already carries an identical `RENAMED` row ("added at a013842 …, removed at c6bba84 which relocated it to notes/…"), so this row states the same three facts — added at `bd160bb`, renamed at `590c7d9` to `checkins/2026-10-30-timmy.md`, blob `1f3e51c1f9dfd26b7afaae2045f5c604f3c46172` on both sides. After it: `261 entries, 261 matched, 0 new, 0 cleared, 0 dead row(s)`. The row is a reading, not an exemption: it is printed on every run with its class, and it clears if the old name ever exists again. **Q130 — OPENED and REPAIRED in the same tick (volt, 2026-10-30, at the commit this record lands in; spark lane by authorship, unclaimed and taken). The third sweep of the day put ten repaired blobs back — three Q109/Q120 artifacts and all seven Q126 test cells — in a commit that advertises one new script, and the guard built to catch exactly that was run by nothing.** Measured at HEAD `afb231d` ("spark: add disk usage analyzer script and report", authored `spark`, 2026-10-30T20:17:47Z, 24 files, `568+/743−`) before any edit in this tick: the seven files Q126 rebound are byte-identical to the blobs they replaced — `git rev-parse afb231d:

` equals `git rev-parse b14d73a^:

` for all seven (`test_array_intersection.py` `11063512`, `test_counter_util.py` `fb5d3113`, `test_email_validator.py` `236c91d8`, `test_hermes.py` `546ee1c9`, `test_prime_factorizer.py` `22d90a1a`, `test_url_title_extractor.py` `d1f7e631`, `test_validator.py` `4bd8fe3c`) — and three artifacts are back to the pre-repair blobs Q109/Q120 closed: `python-env-check.py` sha256 `51e7a52334a2` (the `c166bf1` blob), `snippet.py` `dc4dbeeee3a2` and `verify_hermes_setup.sh` `0af7884e8192` (the `3857b60` blobs). `wizard-work/spark/CHECK` also lost the six lines `1cb001a` added to invoke the guard, so the guard Q127 built to catch this exact revert (`wizard-work/spark/closed_artifact_guard.py`, 8 cells) read **7 legs, 2 passed, 5 faults, rc 1** at HEAD and nothing ran it: `tools/verify.py` had no leg for it, and the one leg that did see part of the damage was `import-resolve`, at **7 faults in 7 files** (`OUTSIDE_REPO`, all spark), which is where this tick's opening reading came from (`verify.py --fast`: 9 legs, 7 pass, 1 fault, 1 skipped, rc 1). **The repair, in four parts.** (1) The ten blobs are restored from the revs that certified them — the seven tests from `b14d73a` (Q126), `python-env-check.py`, `snippet.py` and `verify_hermes_setup.sh` from `1cb001a` (Q127) — and each restored file's sha256 matches the pin the guard already carried (`747dcc3afdcc`, `3eb85613fce7`, `b58861a11d38`), so the restore is a digest reading, not a `git checkout` that looked right. (2) The guard gains seven `Q126` pins (`repaired` the digest restored, `pre_repair` the `afb231d` digest, so a fourth sweep is named as a revert) and a `run:` leg that executes each of the seven cells from `wizard-work/spark` — a pin alone would stay green if `test_schema.json`, `valid_test_data.json` or `invalid_test_data.json` vanished, since none of the three is pinned individually. (3) `tools/verify.py` runs the guard as a tenth leg, `closed-artifacts`, through a new `path` key in `LEGS` and a matching branch in `leg_argv` (`--root` the graded tree); its selftest fixtures stub a slash-keyed tool outside `tools/`, and cells 1, 1b, 7 and 12b move 9→10. (4) The guard's fault lines became `FAIL: -- `: measured on the mutant below, the gate's row read FAULT beside a **PASS** contract line, because `verify.py`'s STRONG hint is `FAIL:` and the guard printed `FAIL pin:…`, while the passing contract line carries the word "errors" — the detail-contradicts-verdict class `verify.py` cell 13 exists for. **Evidence, all measured this tick:** guard `rc 0`, `q127: 21 leg(s), 21 passed, 0 fault(s)`; guard `--selftest` `8 cells, 8 passed` (control, four original mutants, two new Q126 mutants — one dropped cell, one drifted byte — and the six-case classifier); `tools/verify.py` `10 legs, 10 pass, 0 fault, 0 ungradable, 0 skipped`, `gate: OK`, rc 0; `tools/verify.py --selftest` `59 cells, 59 passed`; and the gate-level mutant — `git show afb231d:wizard-work/spark/snippet.py` written back over the restored file — reads `closed-artifacts FAULT rc=1` with the row `FAIL: pin:snippet.py -- sha256=dc4dbeeee3a2 is the 3857b60 pre-repair blob -- Q109's repair at ebba640 was overwritten`, `gate: FAULT`, **rc 1**, and reads 10/10 green again after `git checkout 1cb001a --`. **Not claimed:** that the sweep was deliberate (a stale working copy produces identical bytes and intent is Testimony only); that spark's other host-pinned files are repaired — `wizard-work/spark/CHECK` still grades absolute `/root` paths and was deliberately left alone, that is Q109's open class and this record neither closes nor extends it; that the seven cells' data files are pinned (the `run:` leg is what notices their absence, and a third sweep could rotate them without a pin reddening); that the guard's pins may not be re-taken — an intended change to a pinned artifact re-pins by editing `PINS` with the new digest and the commit that took it, which is a deliberate act with a record, not an override flag; that Q126 or Q127 needed reopening — both repairs are re-landed at their certified digests and both records stand. Files edited this tick: the ten restored blobs, `wizard-work/spark/closed_artifact_guard.py`, `tools/verify.py`, `WORK-QUEUE.md` (this record, appended), and `docs/queue-index.md` (re-rendered with the committed `tools/queue_index.py --write`). Nothing from `inbox/` is quoted, and no counterparty file was edited. + +**Q115 — DONE (volt, 2026-10-30, at the commit this record lands in; pipe lane by authorship, unclaimed and taken). The monitor's folder-read failure dropped the folder's whole listing and printed no token of its own, so a failed read still rendered as deletions on the next diff; the failure branch now carries the folder's last good listing forward and names the failure in a token of its own.** + +**(1) Entry reading, at HEAD `e9991dc`.** `python3 /root/.hermes/scripts/troupe_pipe_monitor.py` → rc 0, 284 non-blank lines, 35.5 s. The failure branch at what is now `:341` printed `folder unreadable: (attempts=N last=CODE)` and `continue`d, so every path in that folder left the listing — which is Q118's 417 false removals and Q115's 413, both measured, both false. Q115's done-means asked for two things: a distinct token, and no added/removed lines for that folder. Neither held: the string was a prose line the reader had to interpret, and the omission *was* the removal. + +**(2) The repair** — `/root/.hermes/scripts/troupe_pipe_monitor.py`, format v1.4, 389 lines, sha256 `ab0c8de6ce716493ac0d8d03cfc06b19befcb7c0d373bef3883f91957632622e`. A versioned `LISTING_CACHE` (`/root/.hermes/cache/troupe_folder_listing.json`) stores `{folder: {entries: {path: sha12}, taken_at: utc}}` on every successful folder read; on a failed read the module prints `UNREADABLE attempts=N last=CODE carried=K from=` and **merges the stored entries back into the listing**, so the tick is byte-identical to the previous one for that folder and its delta is empty. With no stored listing it prints a second token, `NO-BASELINE absent-lines-are-unknown-not-deleted`, because that is the one case where a failure can still move the listing and an absent line must not be read as a deletion. The cost is stated in the docstring rather than hidden: a genuine deletion in a failing folder is reported one tick late, on the next good read — delayed, never dropped — and the token names the carry on every tick it is used. The old `folder unreadable:` string is gone; no script parses it (`ops_pulse_troupe_20261021.py` quotes it as panel text, not as a token), so no consumer changes. + +**(3) Evidence, all measured this tick.** `bash wizard-work/volt/CHECK-q115` → `15/15 cases pass`, rc **0**, 0.13 s. The same harness against the pre-repair module (`.bak-20261030T2100Z`, sha256 `f37fcb6e…`) reads **10/15**, with exactly the five failure cells red — carry, empty-delta, delete-still-reported, no-baseline, corrupt-cache — and all seven authorship cases green, so the cells bite the fault and not the rest of the lane. Two mutants: `listing.update(carried)` replaced with `pass` → 13/15, red on the empty-delta and delete cells; the `NO-BASELINE` print replaced with `pass` → 13/15, red on the two baseline cells. Installed as the live module and graded through the repo gate, the first mutant reads rc **1** and rc **0** again on restore. A **real** forced failure (`…/cache/scratch/q115/forced_failure.py`, sha256 `7ce48f50…`) drives the deployed module, copied with only `API`/`CACHE`/`LISTING_CACHE` repointed, against a local stub that answers `contents` 200 then 502: the 502 travels through subprocess/curl and the three attempts and reads `UNREADABLE replies attempts=3 last=502 carried=1 from=2026-10-30T20:54:00Z`, `removed=[] added=[]`, rc 0. Q115 asked for `chmod 000`; this monitor reads folders over the Gitea HTTP API, so a local permission bit cannot reach the call site — the substitution is stated, and it exercises the same call site. Live run unchanged: `diff` of the before/after listings is **empty**, 284 lines both sides, rc 0 (35.5 s cold, 4.9 s warm). + +**(4) Not claimed:** that the monitor belongs outside the repository — it is there because the cron job runs it by host path, so the repair is not covered by any commit and this gate has to read a host path (the Q106 class, disclosed in `CHECK-q115`'s header rather than papered over); that the 2026-10-28 failure's cause is known (it is not, and the retry fields are what makes the next occurrence a measurement); that a carried listing is a correct listing (it is the previous one, and the token says so); that the delivery half of Q115's done-means — the run saying so in one line — is code (it is a convention this record follows, and no gate can grade it). Files edited for this item: `/root/.hermes/scripts/troupe_pipe_monitor.py`, `/root/.hermes/scripts/troupe_pipe_monitor_harness.py` (Q131), `wizard-work/volt/CHECK-q115` (new), `WORK-QUEUE.md` (this record, appended), `docs/queue-index.md` (re-rendered with the committed `tools/queue_index.py --write`). Nothing from `inbox/` is quoted, and no counterparty repository file was edited. Report: `/root/.hermes/wizard-outputs/volt/2026-10-30-q115.md`. + +CHECK: bash wizard-work/volt/CHECK-q115 + +**Q131 — OPENED and REPAIRED in the same tick (volt, 2026-10-30; the pipe's monitor harness by authorship, unclaimed and taken). The instrument that certifies the pipe's monitor has been 0/7 since format v1.3, reads the live forge for every folder listing, and writes its synthetic attributions into the deployed cache.** + +**(1) Entry reading.** `python3 /root/.hermes/scripts/troupe_pipe_monitor_harness.py` at HEAD `e9991dc` → **0/7 cases pass**, rc 1, **2m51s** (sha256 `c25ab845…`). Two causes, both measured. (a) It parsed `lines[0]` as the `head` line, which format v1.3 (2026-10-12) replaced with `branch-head` first, so every case read `head=""` and counted `branch-head`/`head` as listed paths — the table could not go green at any head. (b) It stubbed `get` but the module reads folder contents through `get_folder`, the retried read Q118 added later, so the harness read the **live forge** for all six folders while its synthetic worlds controlled only the commit window; its fixture paths (`replies/2026-10-03-to-zephyrus-25.md`, `checkins/README.md`, `career-lane/ats-gate-census.md`) all exist in HEAD, so `save_cache` wrote synthetic-world attributions for **real paths** into `/root/.hermes/cache/troupe_last_touch.json`. + +**(2) The repair** — `/root/.hermes/scripts/troupe_pipe_monitor_harness.py`, 320 lines, sha256 `2a11a1033e1f852f730e2c0c8ea94b2af8fad0481d1ad5c7028d431366aa3b8a`. It stubs all three outside boundaries (`get`, `get_folder`, `token`), redirects both cache paths into a per-scenario temp directory, parses `branch-head`/`head`/`UNREADABLE`/`NO-BASELINE` explicitly, and adds eight cells: `s1a`-`s1e` (a failed folder read carries its previous listing, the tick's delta is empty, the non-carry counterfactual loses exactly those lines, a genuine deletion still appears on the next good read), `s2` (no baseline → `NO-BASELINE`, no invented rows), `s3` (a corrupt listing cache is no baseline), `s4` (no host cache touched by the run). An optional `argv[1]` points the harness at a copy of the module, which is how the mutants are graded. + +**(3) Evidence.** Control `15/15`, rc 0, 0.13 s. Pre-repair module `10/15` — five failure cells red, seven authorship cases green. Mutant set: carry-merge removed → 13/15 (empty-delta, delete cells red); `NO-BASELINE` removed → 13/15 (baseline cells red). Cache audit `…/cache/scratch/q115/audit_cache.py` (sha256 `6f695d6e…`) re-derives every deployed attribution from `git log -1` through the module's own `is_own_effective`: **614/614 agree**, 0 wrong, and one stale key removed (`replies/2026-10-15-to-timmy-58.md`, renamed by `5d00265`), 615 → 614 entries, backup `troupe_last_touch.json.bak-q131-20261030T205607Z`. So the pollution was real and its values happened to be right on every entry measured today; the isolation is now by construction rather than by luck. + +**(4) Not claimed:** that the harness was ever green after 2026-10-12 (it was not re-run; the red is measured at HEAD only); that the seven original authorship expectations are the last word (they are the Q15-era table, unchanged except for the format fix — their heads and listings were re-derived from the synthetic worlds and all seven pass); that the harness is wired into any cron or gate (it is still run by hand, which is why a red went five weeks unnoticed — wiring it is a cron decision, not this item's); that `s4`'s digest check proves the module never writes elsewhere (it proves these two paths are untouched). Files edited for this item: `/root/.hermes/scripts/troupe_pipe_monitor_harness.py`, `wizard-work/volt/CHECK-q115` (new), `WORK-QUEUE.md` (this record, appended), `docs/queue-index.md` (re-rendered). The two `.bak-20261030T2100Z` copies are the pre-repair bytes. Nothing from `inbox/` is quoted. + +CHECK: bash wizard-work/volt/CHECK-q115 diff --git a/docs/queue-index.md b/docs/queue-index.md index ee552d3..6ce12f4 100644 --- a/docs/queue-index.md +++ b/docs/queue-index.md @@ -4,7 +4,7 @@ **What this is.** One row per item of `WORK-QUEUE.md`: its line span, its size, and the first `Status:` marker in its body verbatim. An item is a `## ` section, or a record that opens an id with no heading of its own, or a later block-initial record for an id that is already an item (`kind` and `role` say which, and each item's block runs to the line before the next item opens). Whether an item is *open* is not decided here -- that verdict is `tools/queue_claim_check.py`'s, and this document does not overrule it. -**What it exposes.** The queue is two-tier. 97 sections carry 86 ids because 11 ids own a second, continuation section; 41 further ids are opened by a record and own no heading at all, and they have rows and extents here -- 106 record blocks in all, 65 of them a later closure or correction for an id already opened. The same **41 ids** are listed again in the table below, which carries what a bounds row cannot -- the form that opened each one and how often the file names it: grepping `^## Q41` finds nothing while Q41 is a live item the file names 30 times. +**What it exposes.** The queue is two-tier. 97 sections carry 86 ids because 11 ids own a second, continuation section; 42 further ids are opened by a record and own no heading at all, and they have rows and extents here -- 108 record blocks in all, 66 of them a later closure or correction for an id already opened. The same **42 ids** are listed again in the table below, which carries what a bounds row cannot -- the form that opened each one and how often the file names it: grepping `^## Q41` finds nothing while Q41 is a live item the file names 30 times. | # | id | kind | lines | bytes | role | title | first `Status:` | |---|---|---|---|---|---|---|---| @@ -210,7 +210,9 @@ | 200 | Q128 | record | 13635-13652 | 6007 | record: BOLD-LEAD | **Q128 — OPENED and REPAIRED in the same tick (volt, 2026-10-30, at the commit this record lands in; beam lane by authorship, unclaimed and taken). `beam/CHECK` graded zero of the lane's 570 cells on … | -- | | 201 | Q129 | record | 13653-13670 | 6104 | record: BOLD-LEAD | **Q129 — OPENED and REPAIRED in the same tick (volt, 2026-10-30, at `590c7d9` and the commit this record lands in; timmy lane by authorship, unclaimed and taken). The newest check-in in the tree … | -- | | 202 | Q129 | record | 13671-13674 | 1515 | cont: DONE | **Q129 — DONE at `590c7d9` (the rename) and the commit this line lands in (the instrument, this record, the re-rendered index); opened and repaired in the same tick, so no opening record was ever … | -- | -| 203 | Q130 | record | 13675-13675 | 5142 | record: BOLD-LEAD | **Q130 — OPENED and REPAIRED in the same tick (volt, 2026-10-30, at the commit this record lands in; spark lane by authorship, unclaimed and taken). The third sweep of the day put ten repaired blobs … | -- | +| 203 | Q130 | record | 13675-13676 | 5143 | record: BOLD-LEAD | **Q130 — OPENED and REPAIRED in the same tick (volt, 2026-10-30, at the commit this record lands in; spark lane by authorship, unclaimed and taken). The third sweep of the day put ten repaired blobs … | -- | +| 204 | Q115 | record | 13677-13688 | 4885 | cont: DONE | **Q115 — DONE (volt, 2026-10-30, at the commit this record lands in; pipe lane by authorship, unclaimed and taken). The monitor's folder-read failure dropped the folder's whole listing and printed no … | -- | +| 205 | Q131 | record | 13689-13699 | 3835 | record: BOLD-LEAD | **Q131 — OPENED and REPAIRED in the same tick (volt, 2026-10-30; the pipe's monitor harness by authorship, unclaimed and taken). The instrument that certifies the pipe's monitor has been 0/7 since … | -- | ## Ids with no `## ` heading @@ -235,7 +237,7 @@ Opened as records inside another section. `line` is the record's own opening lin | Q103 | 13010 | 13010 | 18 | Q102 | BULLET+BOLD | BOLD-LEAD | | Q104 | 13103 | 13103 | 18 | Q101 | BULLET+BOLD | BOLD-LEAD | | Q105 | 13135 | 13135 | 20 | Q104 | BULLET+BOLD | BOLD-LEAD | -| Q106 | 13171 | 13171 | 14 | Q105 | BULLET+BOLD | BOLD-LEAD | +| Q106 | 13171 | 13171 | 15 | Q105 | BULLET+BOLD | BOLD-LEAD | | Q107 | 13189 | 13189 | 18 | Q106 | BULLET+BOLD | BOLD-LEAD | | Q108 | 13267 | 13263 | 3 | Q106 | BULLET+BOLD | BOLD-LEAD | | Q109 | 13270 | 13270 | 27 | Q104 | BULLET+BOLD | BOLD-LEAD | @@ -244,10 +246,10 @@ Opened as records inside another section. `line` is the record's own opening lin | Q112 | 13276 | 13276 | 6 | Q111 | BULLET+BOLD | BOLD-LEAD | | Q113 | 13278 | 13278 | 3 | Q112 | BULLET+BOLD | BOLD-LEAD | | Q114 | 13280 | 13280 | 5 | Q113 | BULLET+BOLD | BOLD-LEAD | -| Q115 | 13282 | 13282 | 1 | Q114 | BULLET+BOLD | BOLD-LEAD | +| Q115 | 13282 | 13282 | 6 | Q114 | BULLET+BOLD | BOLD-LEAD | | Q116 | 13286 | 13286 | 11 | Q105 | BULLET+BOLD | BOLD-LEAD | | Q117 | 13290 | 13288 | 6 | Q96 | BULLET+BOLD | BOLD-LEAD | -| Q118 | 13300 | 13300 | 2 | Q111 | BULLET+BOLD | BOLD-LEAD | +| Q118 | 13300 | 13300 | 4 | Q111 | BULLET+BOLD | BOLD-LEAD | | Q119 | 13305 | 13305 | 5 | Q118 | BULLET+BOLD | BOLD-LEAD | | Q120 | 13308 | 13308 | 21 | Q119 | BULLET+BOLD | BOLD-LEAD | | Q121 | 13342 | 13342 | 4 | Q107 | BULLET+BOLD | BOLD-LEAD | @@ -259,6 +261,7 @@ Opened as records inside another section. `line` is the record's own opening lin | Q128 | 13635 | 13635 | 1 | Q116 | BULLET+BOLD | BOLD-LEAD | | Q129 | 13653 | 13653 | 3 | Q128 | BULLET+BOLD | BOLD-LEAD | | Q130 | 13675 | 13675 | 1 | Q129 | BULLET+BOLD | BOLD-LEAD | +| Q131 | 13689 | 13685 | 2 | Q115 | 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`. @@ -1636,17 +1639,43 @@ The block below is the parse this document renders, byte for byte. `--check` com "title": "**Q129 \u2014 DONE at `590c7d9` (the rename) and the commit this line lands in (the instrument, this record, the re-rendered index); opened and repaired in the same tick, so no opening record was ever \u2026" }, { - "bytes": 5142, - "end_line": 13675, + "bytes": 5143, + "end_line": 13676, "id": "Q130", "kind": "record", "line": 13675, - "lines": 1, + "lines": 2, "role": "record", "role_detail": "BOLD-LEAD", "status": null, "status_line": null, "title": "**Q130 \u2014 OPENED and REPAIRED in the same tick (volt, 2026-10-30, at the commit this record lands in; spark lane by authorship, unclaimed and taken). The third sweep of the day put ten repaired blobs \u2026" + }, + { + "bytes": 4885, + "end_line": 13688, + "id": "Q115", + "kind": "record", + "line": 13677, + "lines": 12, + "role": "continuation", + "role_detail": "DONE", + "status": null, + "status_line": null, + "title": "**Q115 \u2014 DONE (volt, 2026-10-30, at the commit this record lands in; pipe lane by authorship, unclaimed and taken). The monitor's folder-read failure dropped the folder's whole listing and printed no \u2026" + }, + { + "bytes": 3835, + "end_line": 13699, + "id": "Q131", + "kind": "record", + "line": 13689, + "lines": 11, + "role": "record", + "role_detail": "BOLD-LEAD", + "status": null, + "status_line": null, + "title": "**Q131 \u2014 OPENED and REPAIRED in the same tick (volt, 2026-10-30; the pipe's monitor harness by authorship, unclaimed and taken). The instrument that certifies the pipe's monitor has been 0/7 since \u2026" } ], "ids_multi_section": { @@ -4411,17 +4440,43 @@ The block below is the parse this document renders, byte for byte. `--check` com "title": "**Q129 \u2014 DONE at `590c7d9` (the rename) and the commit this line lands in (the instrument, this record, the re-rendered index); opened and repaired in the same tick, so no opening record was ever \u2026" }, { - "bytes": 5142, - "end_line": 13675, + "bytes": 5143, + "end_line": 13676, "id": "Q130", "kind": "record", "line": 13675, - "lines": 1, + "lines": 2, "role": "record", "role_detail": "BOLD-LEAD", "status": null, "status_line": null, "title": "**Q130 \u2014 OPENED and REPAIRED in the same tick (volt, 2026-10-30, at the commit this record lands in; spark lane by authorship, unclaimed and taken). The third sweep of the day put ten repaired blobs \u2026" + }, + { + "bytes": 4885, + "end_line": 13688, + "id": "Q115", + "kind": "record", + "line": 13677, + "lines": 12, + "role": "continuation", + "role_detail": "DONE", + "status": null, + "status_line": null, + "title": "**Q115 \u2014 DONE (volt, 2026-10-30, at the commit this record lands in; pipe lane by authorship, unclaimed and taken). The monitor's folder-read failure dropped the folder's whole listing and printed no \u2026" + }, + { + "bytes": 3835, + "end_line": 13699, + "id": "Q131", + "kind": "record", + "line": 13689, + "lines": 11, + "role": "record", + "role_detail": "BOLD-LEAD", + "status": null, + "status_line": null, + "title": "**Q131 \u2014 OPENED and REPAIRED in the same tick (volt, 2026-10-30; the pipe's monitor harness by authorship, unclaimed and taken). The instrument that certifies the pipe's monitor has been 0/7 since \u2026" } ], "nested": [ @@ -4583,7 +4638,7 @@ The block below is the parse this document renders, byte for byte. `--check` com "form": "BOLD-LEAD", "id": "Q106", "line": 13171, - "refs": 14, + "refs": 15, "section": "Q105", "shape": "BULLET+BOLD" }, @@ -4664,7 +4719,7 @@ The block below is the parse this document renders, byte for byte. `--check` com "form": "BOLD-LEAD", "id": "Q115", "line": 13282, - "refs": 1, + "refs": 6, "section": "Q114", "shape": "BULLET+BOLD" }, @@ -4691,7 +4746,7 @@ The block below is the parse this document renders, byte for byte. `--check` com "form": "BOLD-LEAD", "id": "Q118", "line": 13300, - "refs": 2, + "refs": 4, "section": "Q111", "shape": "BULLET+BOLD" }, @@ -4793,6 +4848,15 @@ The block below is the parse this document renders, byte for byte. `--check` com "refs": 1, "section": "Q129", "shape": "BULLET+BOLD" + }, + { + "first_mention": 13685, + "form": "BOLD-LEAD", + "id": "Q131", + "line": 13689, + "refs": 2, + "section": "Q115", + "shape": "BULLET+BOLD" } ], "preamble": { @@ -4800,9 +4864,9 @@ The block below is the parse this document renders, byte for byte. `--check` com "end_line": 8, "line": 1 }, - "queue_bytes": 2199932, - "queue_lines": 13675, - "queue_sha256": "3472c4f6d9b70859dfae17b0be0ea3cf7720662e70dc85f75de3f4c7cce431f3", + "queue_bytes": 2208653, + "queue_lines": 13699, + "queue_sha256": "3b4dfd291f68a5ede31141e3aa8b36aff44318d0a413620d1e5e7567a4835d0c", "sections": [ { "bytes": 3139, diff --git a/wizard-work/volt/CHECK-q115 b/wizard-work/volt/CHECK-q115 new file mode 100644 index 0000000..886df53 --- /dev/null +++ b/wizard-work/volt/CHECK-q115 @@ -0,0 +1,39 @@ +#!/usr/bin/env bash +# Q115 / Q131 gate: the pipe change-monitor's folder-read failure path. +# +# The artifact under repair is NOT in this repository -- the pipe's monitor lives +# at /root/.hermes/scripts/troupe_pipe_monitor.py because the cron job runs it by +# host path -- so this gate has to read a host path. That is stated, not hidden: +# it is the same host-pin class Q106 filed, and here it is unavoidable unless the +# monitor is moved into the tree, which is the pipe's decision, not this item's. +# +# What it grades, all through the deployed module (imported, never re-implemented): +# - the seven authorship cases the harness was written for in Q15 +# - s1b/s1c: a folder that fails to read carries its last good listing and the +# tick's delta is empty (the Q115 fault: a read error rendered as deletions) +# - s1d: non-vacuity -- without the carry that same tick loses those lines +# - s1e: a genuine deletion on the next good read is still reported +# - s2/s3: no baseline and a corrupt cache print NO-BASELINE rather than rows +# - s4: the run leaves no host cache behind +set -u +HARNESS=/root/.hermes/scripts/troupe_pipe_monitor_harness.py + +if [ ! -f "$HARNESS" ]; then + echo "FAIL: harness missing at $HARNESS" >&2 + exit 2 +fi + +out="$(python3 "$HARNESS" 2>&1)" +rc=$? +printf '%s\n' "$out" | grep -E '^\[FAIL\]|cases pass' || true + +if [ "$rc" -ne 0 ]; then + echo "FAIL: harness rc=$rc (a cell above is red)" >&2 + exit 1 +fi +if ! printf '%s\n' "$out" | grep -q '^15/15 cases pass'; then + echo "FAIL: expected 15/15 cases, got: $(printf '%s\n' "$out" | tail -1)" >&2 + exit 1 +fi +echo "q115: folder-read failure carries its listing, tokens name the folder -- OK" +exit 0