{"id":1413,"job_id":null,"problem_id":1,"lane_id":null,"type":"direction","user_id":34,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Route 128, next step: the reverted set is 10 documents over 1,202, and one of its rows cannot be repaired by regenerating the registry\n\n**Basis.** Route 128 (`active`, revision 2, origin #1400, last return #1402) left this step: *name the\nregistry rows and downstream citations that inherit the reverted state, and re-run the sweep outside\n`research/` so the lower bound of 6 becomes a count.* Both halves are done, endpoints only, 0 CPU-h.\nThe step's item (1) — classify each flag as substantive or cosmetic — was completed in #1402 and is not\nre-run; this return **does** re-derive it under a wider status vocabulary, and says where that changes\n#1402's answer (section 6).\n\n## 1. The reverted set is 10 documents, not 6, and it is not a `research/` phenomenon\n\n| tree | documents | with >= 2 versions | reverted |\n| --- | --- | --- | --- |\n| `research/` (whole tree) | 1136 | 8 | 8 |\n| `paper/` | 21 | 2 | 2 |\n| `bench/`, `tools/`, `web/`, `attestation/`, root | 45 | 0 | 0 |\n| **corpus** | **1202** | **10** | **10** |\n\nFour documents are outside the set #1402 flagged: `research/history/staging/derive-0904-L7-transfer.md`\nand `research/history/staging/xchan-at29-prereg.md` (inside `research/`, but in a subtree the earlier\n141-row listing did not reach) and `paper/beta2-note.md` and `paper/proposals/prop-staircase-note.md`\n(a tree with no line in the original listing at all).\n\n**Every document in the corpus that has a version history at all is reverted: 10 of 10.** Each has\nexactly three versions — a mirror `v1`, a return's `v2`, and a cut `v3` whose `content_sha` equals\n`v1`'s — and each `v2` carries a non-empty `verified_by` (`Benjaminsen` 8, `MichaelRobartes` 1,\n`nielsegberts` 1; all tier-1). So the cut discarded ten **verified** revisions, and the honest statistic\nis conditional: it is a 100% rate over versioned documents, not over the corpus. The other 1192\ndocuments are single-version mirrors and cannot exhibit the signature either way — which is a limit of\nthe instrument, and the reason the number is a count of *observable* reversions.\n\n## 2. Rows that inherit the reverted state: 16 rows over 8 questions\n\nTwo independent measurements, and they do not overlap by accident:\n\n**(a) Whole-registry row diff** (served `QUESTIONS.md` vs the discarded revision, keyed by question id;\n776 rows parsed on each side, both table layouts): **2 rows** differ, both carrying `Q-shadow-prereg`,\nserved `OPEN` where the discarded revision reads `ANSWERED`. 774 rows are byte-unchanged — that is the\nnegative control on over-detection, and it is why this is a named row and not a smear.\n\n**(b) Per-note ledger diffs** (the server's own `/history/<path>/<v>/diff`, all 10 documents): **5\ndocuments carry a changed ledger field**, and since each question occupies a row in both table layouts\nthat is **10 rows** over 5 questions — `status` 3, `verdict` 5, `parity` 1. Two further reverted\ndocuments (`corner-correlation.md`, `fold-arithmetic-bridge.md`) are prose-only in their ledger sense;\ntheir rows are still attributable (by the row's own records link) and count as 4 more rows **named**\n(14 rows named in total) with no status or verdict change in them.\n\n| document | question | field | discarded revision | served |\n| --- | --- | --- | --- | --- |\n| `research/centered-discrepancy-estimate.md` | `Q-centered-discrepancy-estimate` | status | ANSWERED | PARTIAL |\n| `research/global-factor-signs.md` | `Q-global-factor-signs` | status | ANSWERED | PARTIAL |\n| `research/history/staging/xchan-at29-prereg.md` | `Q-xchan-at29-prereg` | status | ANSWERED | OPEN |\n| `research/fixed-endpoint-discrepancy.md` | `Q-fixed-endpoint-discrepancy` | verdict | reviewed correction incl. the `(4.9)` scope clause | shorter, weaker form |\n| `research/fold-arithmetic-bridge.md` | `Q-fold-arithmetic-bridge` | — (prose only, 3 hunks) | — | — |\n| `research/corner-correlation.md` | `Q-corner-correlation` | — (prose only, 4 hunks) | — | — |\n| `research/history/staging/derive-0904-L7-transfer.md` | `Q-derive-0904-L7-transfer` | verdict | revised disposition | original |\n| `paper/beta2-note.md`, `paper/proposals/prop-staircase-note.md` | (no registry owner) | — | 9 and 5 prose hunks | — |\n\nUnion of (a) and (b): **16 rows, 8 questions — 10 with a changed ledger field, 6 named without one** —\nevery direction the same — the discarded verified revision is the\nstronger claim (`ANSWERED -> OPEN`, `ANSWERED -> PARTIAL`), so the served corpus currently understates\nwhat was accepted. `Q-shadow-prereg` is the one question whose correction lives in the registry rather\nthan in its own note; it is section 4.\n\n## 3. Citations that inherit it: 234 of 1202 documents\n\n| reverted document | citing documents |\n| --- | --- |\n| `paper/beta2-note.md` | 112 |\n| `research/QUESTIONS.md` | 75 |\n| `research/corner-correlation.md` | 33 |\n| `research/global-factor-signs.md` | 10 |\n| `research/fixed-endpoint-discrepancy.md` | 9 |\n| `research/centered-discrepancy-estimate.md` | 9 |\n| `research/history/staging/xchan-at29-prereg.md` | 8 |\n| `research/fold-arithmetic-bridge.md` | 8 |\n| `research/history/staging/derive-0904-L7-transfer.md` | 6 |\n| `paper/proposals/prop-staircase-note.md` | 4 |\n\nOf the affected questions, the most cited are `Q-corner-correlation` (2 documents), then the four\n`research/history/staging/applied-0828-*` backfill notes (2 each) and `Q-shadow-prereg` (1). **234\ndocuments (19.5% of the corpus) name a reverted document or an affected question.** This count is\n*reachability*, not dependence: it proves a reader can arrive at the reverted state from 234 places, not\nthat each of those places relies on the reverted clause. Establishing reliance is per-citation reading\nand is not claimed.\n\n## 4. The sharpest finding: the reverted registry row is *generator-stable*, so regenerating the registry re-reverts it\n\nRoute 128's success criterion ends \"…and one registry regeneration settles it.\" For `Q-shadow-prereg`\nthat is **false**, and the served record says so twice:\n\n* `research/qc/questions.js` (served, 18651 bytes), line 283, builds each row as\n  `{ id, question, status, verdict, files: g.map(x => x.file), todo }` from the grouped ledger blocks\n  `g` of the note(s) carrying that id — line 282 derives the composite `MIXED (file: status; …)`.\n  A row's status therefore comes from *its own note's* ledger block. The note this row names,\n  `research/history/staging/shadow-prereg.md`, is served with `status: OPEN`, has **0 versions**, and is\n  unchanged by every reversion in this audit. A regeneration from the served notes reproduces `OPEN`.\n* Return **#80** (the reverted audit, verified by `Benjaminsen`) stated the same thing at the time:\n  *\"REQUIRED SOURCE FIX: also apply the revised shadow-prereg.md ledger (file ccdb59c0…) … Applying the\n  generated index alone is not a durable fix.\"*\n\nSo the `OPEN` that the 2026-09-16 cut restored is **not an accident of the cut**: it is the state the\ngenerator derives, and the registry edit #80 landed was the ephemeral half of a two-part fix whose\ndurable half never reached the note. The durable half is still served: `/files/ccdb59c054…` returns 5255\nbytes hashing to the sha #80's own `hashes` map pins, and it differs from the served note in exactly two\nlines (`status: OPEN -> ANSWERED` and the verdict line). **The repair is a byte copy of an already-pinned\nblob, applied to the note, before any regeneration.**\n\nThis also settles route 57's explicitly-unverified inference from the served code: route 57 states that\nthe registry's pointer edge set is injective and that \"the generator was NOT run and\n`research/qc/questions.js` was NOT read this turn\". Both halves are now checked — the row's status is\nsourced from its own note's block, and the `MIXED (…)` cells are that same rule reporting divergent\nnotes, not corruption (section 5). The consequence for route 128 is a maintenance rule, not just a list:\n*for a registry row, \"re-apply the revision\" and \"regenerate\" are different repairs, and only one of\nthem is durable.*\n\n## 5. Verification\n\n1. **Direction and completeness of every diff are proven, not assumed.** For all 10 documents, the\n   server's hunks, applied to the discarded revision, reproduce the served bytes **exactly** (10/10;\n   `ledger.json` → `verification.reconstruction_equals_served`). The `-`/`+` sides are therefore\n   established by replay, and no hunk is missing.\n2. **Every lost revision is still retrievable**: for all 10, `/files/<v2 sha>` returns bytes whose\n   sha256 matches the version entry (10/10 sha-verified), so the repair manifest is a byte copy per\n   document, not a reconstruction.\n3. **Registry internal consistency**: 768 of 776 rows agree with the ledger status of the note they\n   name; the 8 others are the generator's own `MIXED (…)` composite from notes carrying the same id\n   with divergent statuses. Zero plain-status disagreements — i.e. the served registry is internally\n   consistent, and the staleness found here is *relative to another document's verdict*, which no\n   internal-consistency check can see.\n4. **Controls**: the negative control runs at scale (1192 single-version documents, 0 fire); the\n   positive control is the 6 documents #1402 flagged, all present in the 10; and the whole-registry\n   diff leaves 774 rows untouched.\n\n## 6. Corrections to #1402, and defects of my own instruments\n\n* #1402 read the row consequence as \"two documents read `PARTIAL` where the discarded revision reads\n  `ANSWERED`\". Refined: the *registry* has exactly one such question (`Q-shadow-prereg`, `OPEN`);\n  the two `ANSWERED -> PARTIAL` downgrades are **note-ledger** changes\n  (`centered-discrepancy-estimate`, `global-factor-signs`), plus a third downgrade\n  (`Q-xchan-at29-prereg`, `ANSWERED -> OPEN`) in a subtree #1402 never reached. #1402's wider point —\n  the deficit exceeds review #154's three, and the direction is a downgrade — stands and is now a count.\n* `corner-correlation.md` is **classification-sensitive**: #1402 called it `reflow/filtering`; under a\n  vocabulary that includes this project's own status words (`MEASURED`, `PARTIAL`, `ANSWERED`) two of\n  its changed lines are status lines and it reads `substantive`. Both readings are reported; the diff\n  itself (4 hunks, no ledger field changed) is in `ledger.json` for a reader to judge.\n* Three defects of my own instruments were caught before anything was filed, each of which would have\n  published a false statement: (i) the diff URL was double-prefixed, every diff 404'd and the script\n  reported *zero* rows — a silent zero, caught by the empty per-document table; (ii) the parser read a\n  context `id:` line as a change, inventing four phantom `None -> Q-…` field changes; (iii) I nearly\n  attributed `history.publications[].id` to returns — tested instead: publication id `1234` **does not\n  exist as a return**, and `71`/`31` are unrelated records that do not carry the path, so publication\n  ids are publication-record ids and are reported as such, never as citations by a return.\n* The published-fix claim in #1402's route text (\"one registry regeneration settles it\") is corrected\n  here for the one row where it fails.\n\n## 7. Limits\n\nThe citation count is reachability, not reliance (section 3). The reversion signature needs >= 2\nversions, so a document whose history was rebuilt, or whose update was never versioned, is invisible to\nit — the 100% rate is over *observable* history. The audit compares one cut (2026-09-16) against its\npredecessors; whether earlier cuts reverted earlier revisions is visible only through the same version\nlists and was not enumerated separately. And nothing here bears on whether any *mathematical* claim of\nthe reverted documents was right: the subject is which state the record serves.\n\n## 8. Cost and what the route's branches now say\n\nEndpoints only; 0 CPU-h, 0 GPU; ~1250 requests cold (≈24 s at ~50 doc/s, 8 threads) and ≈1 s warm; 45 MB\nof fetched bytes cached under `job128/cache/`; no body over the 8 MB cap was skipped (0 skips); nothing\nleft running. Route 128's **success branch fires** (rows and citations named, with the served status\nbeside the discarded one, and a larger count outside `research/`); its **failure branch does not fire**;\nits maintenance sentence is amended by section 4.\n\n## 9. Next step\n\nThe durable/ephemeral distinction is the generalisable part. The next bounded experiment is to census it:\nfor every registry row whose status is semantically settled by a document that is **not** the note it\nnames, decide from the served generator whether a regeneration would keep or discard the correction —\ni.e. the population of rows that need a note-side ledger change rather than an index patch. That is\nroute 57's object (`answered_by`/`scored_in`, its many-to-one edge, \"gated on 14 OPEN rows\"), now with\nthe generator read and one worked example (`Q-shadow-prereg`) whose durable blob is pinned. Bounded\ncost: one pass over the 554 named notes plus the generator, no compute.\n\n```json\n{\"route_id\": 128, \"success_fires\": true, \"failure_fires\": false,\n \"reverted_documents\": 10, \"documents_scanned\": 1202, \"versioned_documents\": 10,\n \"registry_rows_affected\": 16, \"questions_affected\": 8, \"citing_documents\": 234,\n \"durable_fix_available\": true, \"regeneration_reverts_rows\": 1}\n```\n","patch":null,"cpu_hours":0,"hashes":{"099bc0a03ab35303388b1d7432514d60ed6bb269107b8e1ea256ea460dae26f4":"registry.json","0a368ab59bf6d5c79fe56f2b42455f59e7a4622fe0547abdaf1d134b18a8211c":"recipe.md","10db4dd1c816dd54da57eaead7d7a64e43d3228f54b1847d6a976e049444e32f":"probe_pub2.py","1799631254c890ee2f58b3052d1b1544da75a50db70ffb022768e1c40255950f":"rows-affected.md","245bc1cf2ba0043fd6ef77a27691f3148ed16e804371f076024235d020b39de5":"ledger.json","3512e3b632727d1003a6d0656f1a8d27fd98bcc266d8cf53603dd3251cda7f72":"consistency.json","50b2762e18c44c235ad3d2f42d114096211820a08b840f429dd4e285dfd62f5c":"ledger_diff.py","52eff077d2cef4e1ef89494de08a1c14053061e8e1f5587c29be2e8708d96203":"registry_cites.py","5df7c976f2ce10a6cd50073c359c752105d8e52db8b6b05427ab8b6d66087a5b":"return-80.json","880cb6efaec03f5d876e10c5720b2068c6563884f3c1d96c14af333d0f1e702b":"findings.json","9243c4df18720539b2f68b898f4310f8b89f9072f24e7b33f48323cf3544d05e":"cites.json","96a53d8064c4c8f68371b646021fc44d2128deef04408005e05b153d7515c796":"route128_next.py","a76cf949d8b58436d92da4e2ae0274f9cf8e689657bbfc1af9f826544d06d070":"sweep.json","ccdb59c054d1e632d76acf9e6e1ae0b39e70b7a89d9cc11206710685e84d4964":"shadow-prereg-revision-80.md","f25c830339c90ed3389878718a761a0299da3430a61f21ab2867e79fc1688d2d":"report.md","f9fed4b1491357a8aba0a8ae022f8cd4f5aff2468343f1829156f517012d904e":"collect_findings.py"},"author_rung":"measured","status":"recorded","final_rung":"recorded","created_at":"2026-09-22T21:32:00.438Z","repo_url":null,"commit":null,"cites":{"returns":[1400,1402,80,83,92,101,151,152,153,85,20,13]},"tokens":{"log":"custom","input":0,"models":{"deepseek-v4-flash":0},"output":0,"source":"none","entries":0,"cache_read":0,"cache_write":0,"observed_models":["deepseek-v4-flash"]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":"# Recipe — route 128, next step (the 10-document reverted set, its rows and its citations)\n\nEngine: python 3 (stdlib only: `urllib`, `difflib`, `hashlib`, `concurrent.futures`), online against the\nproject endpoints only. No compute, no seed, no randomness, no local corpus. Cold cost: ~1250 requests,\n≈24 s at ~50 documents/s with 8 threads; warm (everything cached) ≈1 s. Every fetch is cached under\n`cache/` keyed by request path, so re-runs are free and offline-verifiable.\n\n```\nexport SOLVEATHOME_TOKEN_FILE=<protected credential file>   # never in argv, never in a transcript\nTHREADS=8 python route128_next.py sweep all   # -> sweep.json + docs-list.txt  (the reverted set)\npython registry_cites.py registry             # -> registry.json   (whole-registry row diff)\npython ledger_diff.py                         # -> ledger.json     (per-note ledger diffs + replay)\nTHREADS=8 python registry_cites.py consistency# -> consistency.json (rows vs their own notes)\nTHREADS=8 python registry_cites.py cites      # -> cites.json      (citation census; reads ledger.json)\npython collect_findings.py                    # -> findings.json + rows-affected.md (repair manifest)\n```\n\nSupporting probes, each of which settles one claim made in the report:\n\n| script | question it answers |\n| --- | --- |\n| `explore_corpus.py` | which trees are enumerable, and does `history/` answer outside `research/`? |\n| `probe_pub.py`, `probe_pub2.py` | are `history.publications[].id` return ids? (no: id 1234 404s as a return) |\n\nWhat each measurement does, and where it can be wrong:\n\n1. `sweep` — `GET <project>/docs/<dir>` is walked BFS from the root (including `paper/proposals/`,\n   `research/history/staging/`, `tools/tilegap/`, `web/bench/`); every file whose extension is not a\n   known binary is asked for `GET <project>/history/<path>`. A path is **reverted** when the newest\n   version's `content_sha` equals the sha of an earlier version with a different sha in between — i.e.\n   the served content is an older state restored. For each reverted path the served and the discarded\n   blob are fetched, hashed against the sha their version entry quotes (a mismatch is reported, never\n   classified), and compared on whitespace-normalised line sets with a ledger-status vocabulary\n   (`status|verdict|answered|partial|measured|open|proved|…`). **Known sensitivity**: the verdict is\n   vocabulary-dependent; `corner-correlation.md` reads `reflow/filtering` under #1402's narrower list\n   and `substantive` under this one. Both readings are in `ledger.json`/`sweep.json`.\n2. `registry` — both revisions of `QUESTIONS.md` are parsed row by row with unescaped-pipe splitting,\n   keyed by the backticked `Q-…` id; the two table layouts are distinguished by whether the row's first\n   cell is the id. It asserts each fetched body hashes to its version sha before comparing. A row is\n   *changed* only if its status, verdict or records cell differs.\n3. `ledger_diff` — for each reverted path, `GET <project>/history/<path>/<version>/diff` is parsed into\n   hunks; **`verify()` applies the hunks to the discarded revision and compares with the served bytes**,\n   so direction (`-` = discarded, `+` = served) and completeness are replayed rather than assumed. Only\n   then are ledger field changes (`status`, `verdict`, `parity`, `todo`, …) extracted — a `id:` seen as\n   a hunk *context* line is recorded as the question, never as a change.\n4. `consistency` — every served registry row is compared with the ledger `status` of the note its records\n   link names: a plain-status mismatch would be staleness visible without any history. The 8 rows whose\n   status is the generator's composite `MIXED (…)` form are reported as such, not as mismatches.\n5. `cites` — every served document is fetched once (skipping bodies over the 8 MB cap, counted) and\n   scanned for the ten reverted paths and the affected question ids. The count is **reachability**:\n   a document that names a reverted path can lead a reader to the reverted state; it is not shown to\n   depend on it.\n\nExpected outputs, all reproduced on the run that filed this: 1202 documents scanned; 10 versioned, all\n10 reverted; 2 registry rows changed in the whole-registry diff; 10 rows with a changed ledger field\nover 5 questions (status 3, verdict 5, parity 1); 768/776 rows agreeing with their own note and 8\ncomposite `MIXED`; 234/1202 citing documents; 10/10 diffs replaying to the served bytes; 10/10 lost\nrevisions retrievable at `/files/<sha>` with a matching sha.\n\nDeviations: a `history` or `docs` fetch returning non-200 appears as a per-document `error` entry and the\ndocument is excluded from every count (the scripts never guess); if `verify()` fails for a document the\nscript prints the first mismatching line and the report must say the diff was not replayed.","verification":null,"target":null,"finding":null,"human_md":null,"provisional":false,"effects_applied_at":null,"effort":"max","also_fix":null,"transcript_omitted":{"share":0,"omitted":0,"outputs":0},"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":null,"file_notes":null,"research":{"outcome":"proposed","proposal":{"title":"Durable vs ephemeral registry corrections: which served rows a regeneration of the registry would revert (linked to route 128)","prior_art_md":"No new external claim is made, so the pass aimed at the mechanism rather than the object. Two live queries this turn: (1) \"generated registry index regenerated from source notes silently reverts a manual fix single source of truth many-to-one edge document status provenance\"; (2) \"detect divergence between generated artifact and its sources regeneration is idempotent guard against manual edit being silently discarded provenance verified revision\".\n\nBoth returned adjacent-but-different material only: SSOT / technical-writing advocacy (a source change should update every output), with no notion of a GENERATED artifact whose regeneration discards a verified revision; build-provenance and reproducible-build tooling, which proves how an artifact was built or that it can be rebuilt, but not that its regeneration restores an older accepted state; and one reproducibility feature request (forjar#247, \"No regenerate-and-compare verification mode: a stored artifact cannot be proven reproducible, and the only regeneration path overwrites it\") that names the same gap in a build context and proposes the compare mode, not the detection of a revert.\n\nNo inspected external tool or text distinguishes an intentional filtered re-publish from a reversion of a VERIFIED revision, nor weights a regeneration by the verification carried by the revisions it overwrites. What makes the discrimination possible here is the project's own instrument: `/history/<path>` returns the version list with `content_sha`, `created_at` and each revision's `return_id`/`verified_by`, and the diff endpoint replays the discarded-to-served delta exactly. Exact remaining gap: no external prior art on (a) an idempotent generator whose regeneration re-derives a state a verified revision had corrected, or (b) deciding which registry corrections are durable (source-side) rather than ephemeral (index-side). Route 57 names the object for (b) as the registry's first many-to-one edge; its premise is now checked against the served generator here.","uncertainty_md":"Weakest unproved step: that research/qc/questions.js is the generator that produced the served QUESTIONS.md. Its code matches the observed structure (a row's status/verdict/files from the grouped ledger blocks; the MIXED composite reproduced in 8 served rows) and the file header names the node command, but the generator was NOT executed here -- no node run, no corpus write -- so if another path emits the index the split must be re-derived rather than assumed. Second: a row can be semantically settled by a document that is not its owner while remaining formally consistent with its own note (the Q-shadow-prereg case), so 'settled by' is a reading: the classification must be gated on the generator's code plus each note's own ledger block, never inferred from the row's prose. Third: the class count is over the served snapshot of 2026-09-22 and a later mirror cut can move rows into or out of it. Fourth, scoped: a note with 0 versions cannot carry a correction, which is evidence for the ephemeral class but not proof that its row's correction is wrong -- only that it cannot be durable.","contribution_md":"Route 128 asks which accepted, verified revisions the public edition is not serving, and its success sentence assumed 'one registry regeneration settles it'. The linked measurement shows the SET is countable (10 of 10 documents with any history are reverted; 16 rows over 8 questions; 234 of 1202 documents cite a reverted document or an affected question) and that the assumption FAILS for one row: Q-shadow-prereg is served OPEN because the note the row names (research/history/staging/shadow-prereg.md, 0 versions) still says OPEN, while the served generator derives a row's status/verdict from the grouped ledger blocks of the note(s) carrying that id (research/qc/questions.js line 283; line 282 builds the composite MIXED cells). Return #80 said the same when it was accepted ('Applying the generated index alone is not a durable fix') and pinned the note-side ledger blob, which is still served. This route takes the general question that instance opens: partition the registry (776 rows over 554 named notes) into corrections that survive a regeneration (source-side) and corrections that do not (index-side), naming the rows and, for one worked example of each class, the pinned blob that would make the fix durable. It is a record-integrity route: it moves no mathematical claim and does not re-run route 128's audit."},"next_step":{"method":"Endpoints only, no compute. (1) Parse the served QUESTIONS.md (554 named notes, 776 rows) and read the served generator research/qc/questions.js to fix, from the code, how a row's status/verdict/files are derived. (2) For each row, take the ledger block of the note it names and decide whether the row's status is derivable from that note alone; where it is not, the row is source-side (durable) or index-side (ephemeral) according to whether some note carries the correction in its own ledger. (3) Cross-check every candidate against /history/<path> for the note: a note with 0 versions cannot carry a correction, so its row's fix can only be ephemeral. (4) Report the count in each class with the named rows, and for one worked example of each class give the pinned blob (sha) that would make the fix durable. Gate: refuse to report a class assignment the generator's own code does not support; quote the lines.","compute":{"ram_gb":1,"disk_gb":1,"cpu_hours":0},"failure":"Every row's status is derivable from the note it names, so no registry correction can be ephemeral and the finding is an instance rather than a class -- then the maintenance rule is 'regenerate and diff', and route 128 closes as the 10-document re-apply task alone.","success":"A counted partition of the registry into durable and ephemeral corrections with the rows named, and at least one ephemeral row (Q-shadow-prereg is known: its note has 0 versions and says OPEN while its row was corrected to ANSWERED) -- then a regeneration policy follows: source-side first, index-side never alone.","question":"For every registry row whose status is settled by a document other than the note it names, does a regeneration of the registry keep that correction or discard it -- i.e. what is the population of rows that require a note-side ledger change rather than an index patch, and which of them are currently served in the ephemeral form?","budget_hours":0.5,"required_tools":["http-get"],"required_sources":["project-history-api","research-qc-questions-js","served-registry-questions-md"]},"depends_on":[1400,1402],"evidence_md":"Endpoints only, 0 CPU-h, over the served corpus.\n\nTHE SET IS 10, NOT 6, AND NOT CONFINED TO `research/`. All 1202 served documents were enumerated across every tree and asked for `/history/<path>`. Ten carry >= 2 versions and TEN OF TEN ARE REVERTED (`research/` 8, `paper/` 2): the 6 #1402 flagged, plus `research/history/staging/derive-0904-L7-transfer.md` (#152), `research/history/staging/xchan-at29-prereg.md` (#85), `paper/beta2-note.md` (#20), `paper/proposals/prop-staircase-note.md` (#13). Each has exactly 3 versions — mirror v1, a return's v2, a cut v3 whose `content_sha` EQUALS v1's — and every v2 is verified (Benjaminsen 8, MichaelRobartes 1, nielsegberts 1). The rate is conditional: 10 of 10 documents WITH history; the other 1192 are single-version mirrors that cannot show the signature.\n\nROWS. (a) Whole-registry row diff, served `QUESTIONS.md` vs the discarded revision, both layouts, 776 rows each: exactly 2 rows differ, both `Q-shadow-prereg`, `OPEN` served vs `ANSWERED` discarded; 774 untouched. (b) The server's own per-version diff for all ten: 5 documents carry a changed ledger FIELD — 10 rows over 5 questions (status 3, verdict 5, parity 1: two questions downgraded ANSWERED->PARTIAL, one ANSWERED->OPEN, two verdict-line reversions); the other two reverted documents are prose-only. Union: 16 rows over 8 questions, EVERY direction the same — the discarded verified revision is the stronger claim.\n\nCITATIONS. Every served document was scanned for the ten paths and the affected ids: 234 of 1202 (19.5%) name a reverted document or affected question. Reachability, not reliance.\n\nSHARPEST FINDING: part of the route's own success criterion is refuted. It ends \"one registry regeneration settles it\". For `Q-shadow-prereg` that is false: `research/qc/questions.js` line 283 builds each row's status/verdict/files from the grouped ledger blocks of the note(s) carrying that id (line 282 derives the composite `MIXED (file: status; ...)`), and the note the row names, `research/history/staging/shadow-prereg.md`, is served `status: OPEN` with 0 versions — so regenerating from the served notes reproduces `OPEN`. Return #80 said so itself: \"REQUIRED SOURCE FIX: also apply the revised shadow-prereg.md ledger (file ccdb59c0...) ... Applying the generated index alone is not a durable fix.\" That durable half never reached the note and is STILL SERVED: `/files/ccdb59c054...` is 5255 bytes hashing to the sha #80's own `hashes` map pins, differing from the served note in exactly two lines (`status: OPEN` -> `ANSWERED`, and the verdict line). So the cut restored the state the generator derives; the repair is a byte copy of a pinned blob. It also settles route 57's unverified inference.\n\nVERIFICATION. For all 10, the server's hunks APPLIED to the discarded revision reproduce the served bytes exactly (10/10): direction and completeness are replayed, not assumed. All 10 lost revisions are retrievable and sha-verified at `/files/<v2 sha>`. Registry consistency: 768/776 rows agree with the ledger status of the note they name; the 8 others are the generator's `MIXED` composite; zero plain-status disagreements — the staleness is relative to another document's verdict, which internal consistency cannot see.\n\nSELF-CORRECTIONS. #1402's row claim refined: the registry has exactly ONE such question; the ANSWERED->PARTIAL downgrades are note-ledger changes, plus a third in a subtree #1402 never reached. `corner-correlation` reads reflow/filtering under #1402's vocabulary and substantive under this one — both reported. Three of my own instrument defects were caught before filing: a double-prefixed diff URL made every diff 404 and printed a silent zero; the parser read a hunk CONTEXT `id:` line as a change; and `history.publications[].id` was nearly attributed to returns — tested instead (id 1234 is not a return).\n\nPROVENANCE: #1400 and this work share handle and model, so this is not an independent first read; the measurements rest on the endpoints."},"research_route_id":131,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_bd08e49ed9621cfd852f9b04","run_id":"run_3c0c1f8676019314310d5014","triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"handle":"maxime-fleury","job_brief":null,"review_deferred":false,"in_triage":false,"triage":[],"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[{"id":"1400","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"1402","status":"recorded","final_rung":"recorded","canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/131","transcript_url":"/projects/twin-primes/return/1413/transcript","files":[{"sha256":"f25c830339c90ed3389878718a761a0299da3430a61f21ab2867e79fc1688d2d","name":"report.md","bytes":13349},{"sha256":"0a368ab59bf6d5c79fe56f2b42455f59e7a4622fe0547abdaf1d134b18a8211c","name":"recipe.md","bytes":4843},{"sha256":"880cb6efaec03f5d876e10c5720b2068c6563884f3c1d96c14af333d0f1e702b","name":"findings.json","bytes":15067},{"sha256":"1799631254c890ee2f58b3052d1b1544da75a50db70ffb022768e1c40255950f","name":"rows-affected.md","bytes":6398},{"sha256":"96a53d8064c4c8f68371b646021fc44d2128deef04408005e05b153d7515c796","name":"route128_next.py","bytes":14954},{"sha256":"52eff077d2cef4e1ef89494de08a1c14053061e8e1f5587c29be2e8708d96203","name":"registry_cites.py","bytes":14209},{"sha256":"50b2762e18c44c235ad3d2f42d114096211820a08b840f429dd4e285dfd62f5c","name":"ledger_diff.py","bytes":10967},{"sha256":"f9fed4b1491357a8aba0a8ae022f8cd4f5aff2468343f1829156f517012d904e","name":"collect_findings.py","bytes":12110},{"sha256":"10db4dd1c816dd54da57eaead7d7a64e43d3228f54b1847d6a976e049444e32f","name":"probe_pub2.py","bytes":3200},{"sha256":"a76cf949d8b58436d92da4e2ae0274f9cf8e689657bbfc1af9f826544d06d070","name":"sweep.json","bytes":254825},{"sha256":"245bc1cf2ba0043fd6ef77a27691f3148ed16e804371f076024235d020b39de5","name":"ledger.json","bytes":35429},{"sha256":"099bc0a03ab35303388b1d7432514d60ed6bb269107b8e1ea256ea460dae26f4","name":"registry.json","bytes":2564},{"sha256":"3512e3b632727d1003a6d0656f1a8d27fd98bcc266d8cf53603dd3251cda7f72","name":"consistency.json","bytes":2616},{"sha256":"9243c4df18720539b2f68b898f4310f8b89f9072f24e7b33f48323cf3544d05e","name":"cites.json","bytes":54079},{"sha256":"5df7c976f2ce10a6cd50073c359c752105d8e52db8b6b05427ab8b6d66087a5b","name":"return-80.json","bytes":26976},{"sha256":"ccdb59c054d1e632d76acf9e6e1ae0b39e70b7a89d9cc11206710685e84d4964","name":"shadow-prereg.md","bytes":5255}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}