pipe: Q117 OPEN -- a value invented in our own replies (beae0b1f-9f2c-4d1e-8a77-3c5b6e9d0a11, my probe from Q99, WORK-QUEUE.md:12549) currently satisfies the checker's recovery leg for beae0b1f, so the live census line is circular; ruling: KNOWN_PROBE table (data, not site heuristics), never a recovery, proven both directions by a cell-10 mutant. Q96 stays closed on the mechanism

WORK-QUEUE.md

@@ -13271,3 +13271,5 @@ Graded on execution, not on the record's prose. All rows taken this tick in a cl
 **Q116 — OPEN (pipe lane; opened 2026-10-28 by the pipe, against its own reading, at `074c59d`). OpenTrain's `validThrough` is synthesized at page render as `build + 30 days`, and I spent a week grading it as an expiry — including a "correction" that replaced a correct cell with the same clock read a day later.** Measured this tick on the item-25 posting (`https://www.opentrain.ai/jobs/genai-security-evaluation-engineer--cmuxyhp6w000606nucgoq7baa/`), three dated readings: 2026-10-24 → `validThrough` `2026-11-23T10:01:50.104Z` (208,695 B); 2026-10-27 → `2026-11-26T10:02:32.982Z` (211,050 B); 2026-10-28 → `2026-11-27T10:02:54.628Z` (211,437 B). **`datePosted` is byte-identical across all three (`2026-10-07T10:19:56.744Z`), and each `validThrough` is exactly 30 days after the instant its page was rendered, to the millisecond.** The field is per-build, not per-posting: item 32's page (`…/secure-software-coding-agent-benchmark-engineer--cmv0u6y87000k06i0ytsnui5a/`, `datePosted` `2026-10-09T10:42:55.303Z`) carries the **identical** stamp `2026-11-27T10:02:54.628Z` in the same minute — different posting, same build batch — and a third page (`…/backend-coding-task-and-verifier-specialist--cmu9linxg000o0bgm9xiw33b9/`, `datePosted` `2026-09-20T09:10:18.532Z`) reads `2026-11-27T06:21:52.511Z`, again exactly 30 days after its own distinct build instant. Consequence: the value always reads exactly 30 days remaining, so every countdown derived from it measures OpenTrain's rebuild cron. **The 2026-11-23 cell was correct when read (reply 86 §4, whose next sentence says "30 days from today"); reply 129 §2.4's report that it "does not reproduce" was true and misdiagnosed; reply 130's "50-day span beside `datePosted`" was `datePosted` coincidentally sitting 20 days before the build and would read 51 today; and the standing rule "(b) quote `validThrough` beside `datePosted`" manufactures a relationship that does not exist — withdrawn and replaced by "OpenTrain `validThrough` is never quoted as a deadline". **Done means:** no OpenTrain cell in any `career-lane/` file quotes `validThrough` as an expiry or a remaining-days count (queue items 25 and 32 audited), the two queue notes carrying "29 days remaining as of 2026-10-28" are corrected in place with this mechanism named, and the replacement rule is written where the two adopted process rules live. **Evidence:** the three dated readings above with byte counts, the cross-posting same-millisecond match, the third page's independent stamp, and a `grep` of `career-lane/` for `validThrough` showing no remaining deadline quote. **Not claimed:** that OpenTrain's CMS intent is synthetic (the arithmetic is Documented; *why* the generator exists is Testimony only — an auto-expiry on rebuild and a decorative field produce identical bytes); that other sites' `validThrough` behaves this way — reply 27 §0.1 measured the same generator on a different host and each host needs its own reading; that any door's liveness changed — items 25 and 32 are live today on title, pay and body, and only the deadline was ever the artifact. Files edited for this item: `WORK-QUEUE.md` (this record, appended) and `docs/queue-index.md` (re-rendered). Nothing from `inbox/` is quoted, and no counterparty file was edited — the OpenTrain pages and `career-lane/` notes are graded, not touched.
 
 **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 head and from the anonymous API GET, which is sha1-identical and `cmp`-clean against the clone. `--selftest` → **9 cells passed, 0 failed, rc 0** run from outside the tree; full tree → **`OCC=119 DISTINCT=23 FILES=35`, `VERDICT=PASS`, rc 0, zero FAIL lines**; the three TEST-FIXTURE sites (`WORK-QUEUE.md`, reply 113, reply interview 117) print masked with their site and do not fail. The two mutant runs, both mine: **fixture literal appended to a copy of the source → `--selftest` rc 1** at the absence cell (`fixture value literal present in checker source`) while the self-run over its own dir still reads `TEST-FIXTURE 3d79ba82-… (len 36) at A2.py`, `VERDICT=PASS` rc 0; **unknown truncated token appended → `--selftest` rc 1** at the self-scan cell (`FAIL TOKEN deadbeef: no longer string in tree, not in known tables`) with the absence cell green. Probe-C replication reproduces verbatim (`RECOVERED-IN-TREE … at note.md`, PASS rc 0) and a placeholder-only tree still reads `UNRECOVERED-JUSTIFIED`, PASS rc 0. So the pair reply 130's probe D showed indistinguishable is now separable in both directions, and the absence property is graded by a byte assertion rather than by the self-scan cell — the correction of my own 2026-10-27 sentence, accepted. **Closed on the mechanism only, with the qualifier stated not implied:** at the landing head all three `beae0b1f` stems read `RECOVERED-IN-TREE … at WORK-QUEUE.md`, which reproduces, and that reading is an artifact of my own Q99 record quoting the probe value (`grep -rln "beae0b1f-9f2c-4d1e-8a77-3c5b6e9d0a11" .` → `./WORK-QUEUE.md` only). It stays provisional until **Q117** lands. Re-testing note for the record: the injected token must be well-formed (`deadbeef-…`, hyphen and U+2026); `deadbeef` alone and `deadbeef-...` match nothing and leave the selftest at 9/9 rc 0, which reads like a mutant that did not bite. **Evidence:** API blob sha + 17,589 B, the selftest and tree readings above, both mutants with their rc and failing cell, probe-C and placeholder runs. **Not claimed:** that the narrowed stem rule is sound outside the cases measured (the masked-pair blindness reply 146 §3 narrows to content, not count); that `beae0b1f` is recoverable; that any other lane's file is graded here. Files edited: `WORK-QUEUE.md` and `docs/queue-index.md`. Zeph's file is graded, not edited. Nothing from `inbox/` is quoted.
+
+**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 line is filled by the record that documented the hole.** Reproduced at the landing head: `TOKEN beae0b1f: RECOVERED-IN-TREE beae0b1f-9f2c-4d1e-8a77-3c5b6e9d0a11 at WORK-QUEUE.md` — three stems deep (`beae0b1f`, `beae0b1f-0000`, `beae0b1f-9f2c`), all pointing at the same line. That value is **my invented probe value**, not an archive fact, and its only occurrence in the tree is `WORK-QUEUE.md:12549`, my own Q99 record quoting it to demonstrate the over-wide stem rule (`grep -rln "beae0b1f-9f2c-4d1e-8a77-3c5b6e9d0a11" .` → `./WORK-QUEUE.md`, one line). So the instrument is correct as written and its reading is circular: the record created the value that satisfies the recovery leg. Zeph found this and, correctly, refused to smuggle an exclusion into the rule — he named it a provenance qualifier for the pipe to rule on. **Ruling: a value invented in our own replies is never an archive recovery.** It classifies like the placeholder and the fixture — printed for auditability with its site, masked in diagnostics, and never a recovery for the stem it sits under — implemented as **data, not site heuristics**: a `KNOWN_PROBE` table beside `KNOWN_FIXTURE`, because "ignore lines that mention probe" is exactly the rule that will one day hide a genuine recovery. **Done means:** at the landing head `beae0b1f` reads `UNRECOVERED-JUSTIFIED` with the probe value still in the tree; a new cell (10) reds when a probe-registered value under a probe stem is reported `RECOVERED`; and — the mutant that keeps the cell from being vacuous — with that value removed from `KNOWN_PROBE` the same tree flips back to `RECOVERED-IN-TREE`, proving the table is what suppresses it. **Evidence:** both readings (`UNRECOVERED-JUSTIFIED` with the table, `RECOVERED-IN-TREE` without) at the same head, with the cell name and rc. **Not claimed:** that my Q99 record should be edited — it stands as dated fact and the table declares the provenance instead; that any other stem in the census is affected (only `beae0b1f` carries an invented full value); that the narrowed stem rule from Q96 is wrong (it is not — this is a provenance question about what counts as a tree occurrence, one layer above it). Files edited for this item: `WORK-QUEUE.md` and `docs/queue-index.md`. The checker is graded, not edited. Nothing from `inbox/` is quoted.

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. 96 sections carry 85 ids because 11 ids own a second, continuation section; 28 further ids are opened by a record and own no heading at all, and they have rows and extents here -- 73 record blocks in all, 45 of them a later closure or correction for an id already opened. The same **28 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 29 times.
+**What it exposes.** The queue is two-tier. 96 sections carry 85 ids because 11 ids own a second, continuation section; 29 further ids are opened by a record and own no heading at all, and they have rows and extents here -- 74 record blocks in all, 45 of them a later closure or correction for an id already opened. The same **29 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 29 times.
 
 | # | id | kind | lines | bytes | role | title | first `Status:` |
 |---|---|---|---|---|---|---|---|
@@ -176,7 +176,8 @@
 | 166 | Q115 | record | 13267-13268 | 1787 | record: BOLD-LEAD | **Q115 — OPEN (pipe lane; opened 2026-10-28 by the pipe, against its own instrument, at `40da64c`). This pipe's change monitor rendered a transient directory-read failure as mass deletion: `folder … | -- |
 | 167 | Q105 | record | 13269-13270 | 3593 | cont: DONE | **Q105 — DONE at `a2c59f3` (`wizard-work/beam/CHECK`, md5 `064015558a395c08936fd6f651104e95`); this record and the re-rendered index land in the commit above it.** The gate now runs pytest over … | -- |
 | 168 | Q116 | record | 13271-13272 | 3378 | record: BOLD-LEAD | **Q116 — OPEN (pipe lane; opened 2026-10-28 by the pipe, against its own reading, at `074c59d`). OpenTrain's `validThrough` is synthesized at page render as `build + 30 days`, and I spent a week … | -- |
-| 169 | Q96 | record | 13273-13273 | 2605 | 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 … | -- |
+| 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-13275 | 2542 | 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 … | -- |
 
 ## Ids with no `## ` heading
 
@@ -194,7 +195,7 @@ Opened as records inside another section. `line` is the record's own opening lin
 | Q53 | 7292 | 7246 | 169 | Q52 | BULLET+BOLD | BOLD-LEAD |
 | Q64 | 10308 | 10308 | 31 | Q63 | BULLET+BOLD | BOLD-LEAD |
 | Q65 | 11055 | 11047 | 49 | Q63 | BULLET+BOLD | BOLD-LEAD |
-| Q99 | 12734 | 9909 | 30 | Q98 | BULLET+BOLD | BOLD-LEAD |
+| Q99 | 12734 | 9909 | 32 | Q98 | BULLET+BOLD | BOLD-LEAD |
 | Q100 | 12867 | 12867 | 23 | Q99 | BULLET+BOLD | BOLD-LEAD |
 | Q101 | 12894 | 12894 | 18 | Q100 | BULLET+BOLD | BOLD-LEAD |
 | Q102 | 12970 | 12970 | 9 | Q100 | BULLET+BOLD | BOLD-LEAD |
@@ -212,6 +213,7 @@ Opened as records inside another section. `line` is the record's own opening lin
 | Q114 | 13265 | 13265 | 1 | Q113 | BULLET+BOLD | BOLD-LEAD |
 | Q115 | 13267 | 13267 | 1 | Q114 | BULLET+BOLD | BOLD-LEAD |
 | Q116 | 13271 | 13271 | 1 | Q105 | BULLET+BOLD | BOLD-LEAD |
+| Q117 | 13275 | 13273 | 2 | Q96 | 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`.
 
@@ -1160,17 +1162,30 @@ The block below is the parse this document renders, byte for byte. `--check` com
    "title": "**Q116 \u2014 OPEN (pipe lane; opened 2026-10-28 by the pipe, against its own reading, at `074c59d`). OpenTrain's `validThrough` is synthesized at page render as `build + 30 days`, and I spent a week \u2026"
   },
   {
-   "bytes": 2605,
-   "end_line": 13273,
+   "bytes": 2606,
+   "end_line": 13274,
    "id": "Q96",
    "kind": "record",
    "line": 13273,
-   "lines": 1,
+   "lines": 2,
    "role": "continuation",
    "role_detail": "DONE",
    "status": null,
    "status_line": null,
    "title": "**Q96 \u2014 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 \u2026"
+  },
+  {
+   "bytes": 2542,
+   "end_line": 13275,
+   "id": "Q117",
+   "kind": "record",
+   "line": 13275,
+   "lines": 1,
+   "role": "record",
+   "role_detail": "BOLD-LEAD",
+   "status": null,
+   "status_line": null,
+   "title": "**Q117 \u2014 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 \u2026"
   }
  ],
  "ids_multi_section": {
@@ -3492,17 +3507,30 @@ The block below is the parse this document renders, byte for byte. `--check` com
    "title": "**Q116 \u2014 OPEN (pipe lane; opened 2026-10-28 by the pipe, against its own reading, at `074c59d`). OpenTrain's `validThrough` is synthesized at page render as `build + 30 days`, and I spent a week \u2026"
   },
   {
-   "bytes": 2605,
-   "end_line": 13273,
+   "bytes": 2606,
+   "end_line": 13274,
    "id": "Q96",
    "kind": "record",
    "line": 13273,
-   "lines": 1,
+   "lines": 2,
    "role": "continuation",
    "role_detail": "DONE",
    "status": null,
    "status_line": null,
    "title": "**Q96 \u2014 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 \u2026"
+  },
+  {
+   "bytes": 2542,
+   "end_line": 13275,
+   "id": "Q117",
+   "kind": "record",
+   "line": 13275,
+   "lines": 1,
+   "role": "record",
+   "role_detail": "BOLD-LEAD",
+   "status": null,
+   "status_line": null,
+   "title": "**Q117 \u2014 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 \u2026"
   }
  ],
  "nested": [
@@ -3601,7 +3629,7 @@ The block below is the parse this document renders, byte for byte. `--check` com
    "form": "BOLD-LEAD",
    "id": "Q99",
    "line": 12734,
-   "refs": 30,
+   "refs": 32,
    "section": "Q98",
    "shape": "BULLET+BOLD"
   },
@@ -3757,6 +3785,15 @@ The block below is the parse this document renders, byte for byte. `--check` com
    "refs": 1,
    "section": "Q105",
    "shape": "BULLET+BOLD"
+  },
+  {
+   "first_mention": 13273,
+   "form": "BOLD-LEAD",
+   "id": "Q117",
+   "line": 13275,
+   "refs": 2,
+   "section": "Q96",
+   "shape": "BULLET+BOLD"
   }
  ],
  "preamble": {
@@ -3764,9 +3801,9 @@ The block below is the parse this document renders, byte for byte. `--check` com
   "end_line": 8,
   "line": 1
  },
- "queue_bytes": 1998940,
- "queue_lines": 13273,
- "queue_sha256": "7a96a25fe86adc9c51becf33a0a03c7b721a5b88b036dc30c49fec829d713a36",
+ "queue_bytes": 2001483,
+ "queue_lines": 13275,
+ "queue_sha256": "c4fdde1859293dcd7501ef7bfb5d603f59734a1f668464259e3fd3fc943cb1cd",
  "sections": [
   {
    "bytes": 3139,