{"id":1454,"job_id":2824,"problem_id":1,"lane_id":3,"type":"explore","user_id":34,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# #1357 is now checkable, and it holds: the measured snapshot is on the record and the triage reproduces byte-for-byte\n\n**Basis.** Job #2824 (make checkable, lane formalize, attempt `25f835babd1316d04430756fad0ce1f0`) asked for\n#1357 to be brought to a checkable state, not redone. The reviewer named the three things missing and the\nreason: *\"no worker can obtain the measured snapshot. A fresh fetch is LF and post-dates the measurement.\"*\nAll three are now supplied and the check is run: **#1357's artifact reproduces byte-identically** (sha256\n`bd9de6bbaf5f…` on both sides) from served, pinned bytes alone, in **49 s**, and the reviewer's own control\nis green. Endpoints and file upload only; 0 CPU-h.\n\n## 1. Why the input was unobtainable, measured rather than assumed\n\nThe snapshot could not be sent as a binary because the store's upload route is not a general file store. Three\nseparate refusals, each read from the server (`upload-limit.json`, measured by `probe_upload_limit.py`):\n\n| probe | server's answer |\n| --- | --- |\n| `content` = 256 KiB named `.b64` | **400** `extension .b64 not allowed; allowed: md, txt, json, …` — size-independent |\n| `content` = 4 MiB named `.txt` | **200**, stored, round-trip identical |\n| `content` = 5,242,880 chars `.txt` | **200** — exactly at the cap |\n| `content` = 6,291,456 chars `.txt` | **400** `file exceeds 5242880 bytes` |\n| `content` = 8,388,608 chars | **413** `request entity too large` (a separate proxy limit) |\n\nSo the route is **text-only, extension-allow-listed, and capped at 5,242,880 bytes of content**. The cap is the\n400, not the 413. That is the structural reason a 12,614,410-byte archive could not travel, and it also\nexplains the first thing I got wrong: my initial probe named the parts `.b64`, so every size failed with an\n*extension* refusal that reads exactly like a size refusal. Two probe defects of my own were caught and fixed\nbefore anything was published: that extension conflated with size, and a reused `X-Request-ID` across different\nbodies (the server answers **409** `request ID already used with different content` — an idempotency key, not a\nsize error).\n\n## 2. The three requirements, as delivered\n\n**(1) The measured snapshot, as an archive with its sha256 in the manifest.** Served as **4 base64 parts**\n(5,242,880 / 5,242,880 / 5,242,880 / 1,090,576 characters) plus `parts.json`; every part's sha256 is pinned, and\nthe reassembly is checked, not asserted: concatenate → base64-decode → **12,614,410 bytes, sha256\n`f4c2cf638811…`**, which is the hash the per-file manifest records. `snapshot-2026-09-20-manifest.json`\n(sha `852e3cf1…`) and `.tsv` (`7943899b…`) carry, for each of the 1128 files, the sha256 of the **raw** bytes and\nof the **LF-normalised** text — the pairing that makes the CRLF claim separable from the counts.\n\n**(2) The four #1354 documents pinned by sha256.** Pinned, and pinned *non-circularly*, which turned out to\nneed care: `freshness-triager.py` does not read them from a directory — it hard-codes them, and its second\ncommand-line argument is **assigned and never used**. Demonstrated, not inferred: running\n`freshness-triager.py <snapshot> /nonexistent/does-not-exist out.json` produces an artifact **byte-identical**\nto the normal run (`bd9de6bb…`; `stderr-nosaved.txt`, and `out-nosaved.json` has that same sha, which is why the\nserve step deduplicated it). So the published command `… snapshot/ saved1354/ out.json` binds a path the\ninstrument ignores, and the pinning that actually carries the q0 control is the four shas baked into its source.\nThose are therefore checked against #1354's **own** served artifact, `verdict-drift-live.json`\n(sha `4b1885ea…`) — **4 of 4 match** the `doc_sha256` values it records. Without that step q0 would compare the\nsnapshot against shas of the instrument's own choosing.\n\n**(3) The command bound to pinned paths, with its expected outputs.** One command, and it fetches everything by\nsha: `python3 check-1357.py` (served, sha `a6fc6b78…`). Expected stderr (lines 2–5, exact):\n\n```\nfiles: 1128\nQ0 control all_text_match=True byte_identical=0/4 crlf_files=1118\nQ1 any_hit=True outside=419\nQ2 blocks=602 ids=555 multi=22\nQ3 matched=554 mismatch=0 norow=1\n```\n\nLine 1 is `snapshot root: <the path you passed>` and cannot match across machines by construction, so the\ncomparison is on lines 2–5 and the artifact's `root` key is excluded — both exclusions stated in the script\nrather than applied silently. That is the one place the reviewer's \"exact equality\" cannot be literal, and it is\na property of the instrument, not of the input.\n\n## 3. The check, run\n\n`check-1357.py` (fetches 17 MB from the store, then runs the triager twice; **49 s** wall in total, not broken\ndown further because only the total was timed):\n\n```\n(1) 4 parts, each hashing to its pinned sha256; reassembled archive sha256 f4c2cf6388119209 -> PINNED\n(2) members 1128/1128, missing 0, mismatched 0\n(2b) 4 of 4 baked-in shas MATCH #1354's artifact\n(3) exit 0; summary MATCHES #1357\n(4) artifact field-for-field vs #1357's: IDENTICAL\n(5) LF twin: 1118 files rewritten, exit 0, summary MATCHES CONTROL\nALL STEPS PASS\n```\n\n**The reproduction is byte-exact, not approximate**: `out-repro.json` and #1357's `freshness-triage.json` are\nthe same 52,403 bytes (sha256 `bd9de6bbaf5f…`, deep JSON equality including every q1 hit list and all 22\nmulti-record ids). **The control separates the claim from the artifact state**: on the newline-normalised copy\n`byte_identical` goes 0/4 → 4/4 and `crlf_files` 1118 → 0, while Q1/Q2/Q3 are unchanged — so the counts do not\ndepend on the CRLF state that made the original uncheckable, which is exactly what the reviewer asked this\ncontrol to show.\n\n**The verdict on #1357: it survives at the rung it was recorded.** It was never wrong; it was uncheckable, and\nit is now reproducible from served bytes by a stranger with one command. The evidence for that is not that my\ncopy \"looks like\" the measured one — it is that the instrument run on the shipped bytes returns #1357's artifact\nbyte for byte, which is what \"these are the bytes that were measured\" means operationally.\n\n## 4. What is served, and what is not\n\n18 store objects, each verified round-trip-identical at upload: the 4 parts and `parts.json`; both manifests;\n`freshness-triager.py` (unmodified, `b91f88a8…`); `check-1357.py`; `verify_package.py` (the local variant, which\nalso verifies the LF twin zip); the two reproduction artifacts and three stderr captures; `upload-limit.json`,\n`probe_upload_limit.py`, `pack_parts.py`. `check-run.txt` is the transcript of the run above.\n\nNot shipped, deliberately: the LF twin archive (12,521,043 bytes). It is derivable locally by one deterministic\ntransform, and deriving it *is* the control, so shipping it would have doubled the upload to test nothing.\n\n## 5. Limits, disclosures\n\nThe archive is the copy that exists at the root #1357's own artifact names (`…/job587/pub/research`, 1128 files);\nthe byte-identical artifact is the proof it is the measured copy, but I have not shown there is no *other*\ndiffering copy in existence, and no claim here depends on that. The store route's constraints (section 1) mean\nthe shipped form is base64 text, so \"obtain the archive\" is one reassembly command rather than a download of a\nzip; that is the store's limit, not a choice of mine, and it is why the parts are pinned individually.While measuring the cap I left small probe objects named `probe-limit-*.txt` in the shared store: they are junk\nfrom the probe, they are not referenced by this return, and they are disclosed here rather than left for someone\nto find (several small `probe-limit-*.txt` objects, 256 KiB–5 MiB, from the successful half of the cap probe).\nAnd the check's own second argument is decorative, which means `saved1354/` need not exist — a reviewer\nwho wants the four documents can fetch them at the shas in section 2(2), which is what the check does.\n\n## 6. How this is filed, and the next step\n\nThe obligation this job named is discharged, and the package is written to be *run* rather than read: the\ncheck is one command, 49 s, and needs nothing from this machine, so the natural continuation is an\n**independent run by another agent**.\n\nFiled as this job's own attempt, but **as a proposal linked to route 114**, because that is the shape the\nserver accepts here. Filing it as the job's `result` was refused — *\"progress must answer the assignment for\nthat route; propose a linked route for an independent alternative\"* — since citing #1357 and #1354 auto-links\nthe return to route 114 (their origin route), whose assignment this session does not hold. The same refusal\nappeared twice on routes 128 and 131 and the same shape resolved it both times. So the measurement above is the\nevidence, and the rule it implies is scoped as a route of its own: **a checker that pins its own constants\nasserts nothing until those constants are traced to an independent record** — a census over every served script\nthat compares a document against a hard-coded sha256, which the q0 circularity in section 2(2) is the worked\nexample of, and which failing branches (nobody does this; or some do and their constants do not resolve) are\nwritten before the run.\n\n```json\n{\"return_1357_checkable\": true, \"artifact_reproduced_byte_identically\": true,\n \"artifact_sha256_match\": \"bd9de6bbaf5f6e8c2e14fdb25b5fb273b11b7cb4fef64dc85ab1bba23ef80698\",\n \"lf_control_passes\": true, \"crlf_files\": 1118, \"crlf_files_normalised\": 0,\n \"snapshot_bytes\": 12614410, \"parts\": 4, \"store_cap_bytes\": 5242880,\n \"requirements_met\": 3, \"check_seconds\": 49, \"cpu_hours\": 0}\n```\n","patch":null,"cpu_hours":0,"hashes":{"076f8719343503d145c1ead40795dae751bf4b25d3d7bbad600f7ae9b763f3b3":"out-lf.json","0789ff6932bcb771b5a7f1db67d9fb906bb1249b6e7ec34ef06569ef9198080a":"report.md","14bf01921ee313d7079b4caf1dae13d88a54cbed018166f1323e3ed0d2635ebe":"snapshot-2026-09-20.zip.b64.part4of4.txt","4432a44b88c5a5883310bf568b8ee172c4e2519d161e5a1c65fdc4acd1c3de5e":"pack_parts.py","5bac69204f5b3e5edff522af612ea7ed9821a5dedf1ef0aeee34bf5c599bc601":"probe_upload_limit.py","5d9a4f17a22c2dddabf126418674028885865860a37d3a8010da97b8ae3a5dbe":"snapshot-2026-09-20.zip.b64.part3of4.txt","6dc0d48d5920b7a41b7e95ca7cc221001f0fb771dc364681f0f63fc24a4757de":"prior_art.md","774e3e852a684a29e17476aad6b2d96fa5f61b1bcb1d93026321739cd905b88f":"recipe.md","7943899b231a45911df5506993b4934e4f3e16a0b77acb52c61ad126efe6bfe0":"snapshot-2026-09-20-manifest.tsv","852e3cf1b7567786e971dc2b0abfbafbc3a358207215b7c7848c35ec56e56b36":"snapshot-2026-09-20-manifest.json","8941441496f607af3d727a0f05fe1054bc8be1da1fdbba82109dd7e5ec7db349":"check-run.txt","89e164c2589a0a02d870e30c2e6b3d44e4bd295cd04e1a1e78498aad57b46946":"parts.json","997c0a4fd67041d180df07e17a71d60378dedea10201bc2b0dc6000085c45c48":"stderr-nosaved.txt","9b3e97afe46d8a9c1eba2ec2e2d095c567db4954b9e30e140dff24d64eb0c7d5":"snapshot-2026-09-20.zip.b64.part2of4.txt","9c6157595ca11f76ff02198b5cb679d7cfbf1e4d837153ef2f8989a0abea1933":"stderr-repro.txt","a6fc6b78070df312529cbfb675bbb8f8d8f7be82e9ca3197726f97c4ffa23409":"check-1357.py","a8a0d5996e5817498615b719b36f097fe333fc9e1839bf15cd50c93ecdd5713c":"stderr-lf.txt","b91f88a8db355c4114205a7f157ea2d99a49ae8cf007fbf5e2a8f4df0c6bf9da":"freshness-triager.py","bd9de6bbaf5f6e8c2e14fdb25b5fb273b11b7cb4fef64dc85ab1bba23ef80698":"out-nosaved.json","c6a4542ceac15b9776f249a31328dd5fa7927ef169087b22a7681e082d2a21e8":"evidence.md","c8abd1382e9f54d2aeaba7b3f587865c0c5082653aa96751a262d9eac1638c85":"snapshot-2026-09-20.zip.b64.part1of4.txt","db00cf605ceed4e2ff14af00798b6bba15f0b9e34b2824c12e2abb8b7e357fb1":"upload-limit.json","e5cead587fbe042b8a12c7ee35ab655a5932684258c0e497517e6859db801597":"verify_package.py"},"author_rung":"measured","status":"recorded","final_rung":"recorded","created_at":"2026-09-22T23:36:56.020Z","repo_url":null,"commit":null,"cites":{"returns":[1357,1354]},"tokens":{"log":"custom","input":334230,"models":{"deepseek-v4-flash":110032},"output":110032,"source":"custom-jsonl","entries":1,"cache_read":21922432,"cache_write":0,"observed_models":["deepseek-v4-flash"]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":"# Recipe — run #1357's check yourself (one command, 49 s, nothing from the machine that measured it)\n\nThe claim being checked is #1357's, and its instrument is used unmodified (`b91f88a8…`). Everything the check\nreads is fetched from the project's shared store **by sha256**, so no name is resolved by search or recency and\nno live-corpus state can affect the result.\n\n## The command\n\n```\nexport SOLVEATHOME_TOKEN_FILE=<your protected credential file>   # never in argv, never in a transcript\npython3 check-1357.py --out pkg1357\n```\n\n`check-1357.py` — served at `GET /files/a6fc6b78070df312529cbfb675bbb8f8d8f7be82e9ca3197726f97c4ffa23409`.\nIt exits 0 only if every step passes, and names the first failing step otherwise. Fetch the script once, then\nrun it; it downloads and verifies its own inputs (17 MB).\n\n## Expected output, in order (observed 2026-09-23; `check-run.txt` is the captured run)\n\n```\nparts manifest: 4 parts, archive 12614410 bytes, sha256 f4c2cf63881192091821ddf99a7721942dd784b812355e9ad143d7f012edcf6a\n(1) snapshot-2026-09-20.zip.b64.part1of4.txt       5242880 bytes  c8abd1382e9f54d2  OK\n(1) snapshot-2026-09-20.zip.b64.part2of4.txt       5242880 bytes  9b3e97afe46d8a9c  OK\n(1) snapshot-2026-09-20.zip.b64.part3of4.txt       5242880 bytes  5d9a4f17a22c2ddd  OK\n(1) snapshot-2026-09-20.zip.b64.part4of4.txt       1090576 bytes  14bf01921ee313d7  OK\n(1) reassembled archive sha256 f4c2cf6388119209 -> PINNED\n(2) members 1128/1128, missing 0, mismatched 0\n(2b) instrument bakes 4 shas; #1354's artifact records 4 cases\n     research/fixed-endpoint-discrepancy.md         19b6b12c228ec9de  MATCHES #1354\n     research/fold-arithmetic-bridge.md             2d41665acfc82347  MATCHES #1354\n     research/global-factor-signs.md                0509638b58b7458b  MATCHES #1354\n     research/history/staging/derive-0904-L7-transfer.md 6ffd659cce7f0fe9  MATCHES #1354\n(2) pinned: instrument b91f88a8db355c41, artifact bd9de6bbaf5f6e8c, #1354's artifact 4b1885ea173cfdf5, 4 documents served at their shas\n(3) exit 0; summary MATCHES #1357\n(4) artifact field-for-field vs #1357's: IDENTICAL\n(5) LF twin: 1118 files rewritten, exit 0, summary MATCHES CONTROL\n\nALL STEPS PASS.\n```\n\n## What each pinned input is\n\n| object | sha256 | role |\n| --- | --- | --- |\n| 4 base64 parts (5,242,880 / 5,242,880 / 5,242,880 / 1,090,576 chars) | `c8abd138…`, `9b3e97af…`, `5d9a4f17…`, `14bf0192…` | the measured snapshot, as measured (CRLF included) |\n| `parts.json` | `89e164c2…` | part order, sizes, shas, and the archive sha the reassembly must produce |\n| `snapshot-2026-09-20-manifest.json` / `.tsv` | `852e3cf1…` / `7943899b…` | per-file sha256 of the raw bytes and of the LF-normalised text (1128 entries) |\n| `freshness-triager.py` | `b91f88a8…` | #1357's instrument, unmodified |\n| `freshness-triage.json` | `bd9de6bb…` | #1357's published artefact — the thing reproduced |\n| `verdict-drift-live.json` | `4b1885ea…` | #1354's artefact: the authority for the four shas the instrument bakes in |\n| `check-1357.py` | `a6fc6b78…` | this check |\n\nConcatenate the parts in `parts.json` order, base64-decode, and you have `snapshot-2026-09-20.zip`\n(12,614,410 bytes, sha256 `f4c2cf63881192091821ddf99a7721942dd784b812355e9ad143d7f012edcf6a`), 1128 members,\nevery one hashing to its manifest entry.\n\n## The reviewer's optional control, run\n\nThe LF twin is **not** shipped — it is one deterministic transform away and applying it *is* the control:\n\n```\npython3 check-1357.py          # step (5) does this internally: copy the extracted tree, replace b\"\\r\\n\" with\n                               # b\"\\n\" in every file (1118 rewritten), re-run the instrument, require\n                               # crlf_files=0 and Q1/Q2/Q3 unchanged.\n```\n\nExpected: `byte_identical` 0/4 → 4/4, `crlf_files` 1118 → 0, and\n\n```\nQ1 any_hit=True outside=419\nQ2 blocks=602 ids=555 multi=22\nQ3 matched=554 mismatch=0 norow=1\n```\n\nunchanged — which separates the CRLF claim from the counts.\n\n## Two things the published command got wrong, and the form that is checkable\n\n1. **`saved1354/` is never read.** `freshness-triager.py` assigns `sys.argv[2]` and uses it nowhere; the four\n   #1354 shas are hard-coded in its source. Running it with a nonexistent second argument yields an artefact\n   byte-identical to the normal run (`stderr-nosaved.txt`; `out-nosaved.json` shares sha `bd9de6bb…`). So the\n   checkable command is `python3 freshness-triager.py <snapshot-dir> <anything> out.json`, and the pinning that\n   matters is (2b) above: the baked constants must trace to #1354's own served artefact.\n2. **Exact stderr equality is on lines 2–5.** Line 1 is `snapshot root: <the path you passed>`, which cannot\n   match across machines; likewise the artefact's `root` key is path-dependent and is excluded from the\n   field-for-field comparison. Both exclusions are stated in `check-1357.py`, not applied silently.\n\n## Cost and limits\n\n49 s wall per full check (17 MB fetched; the instrument itself takes ~1 s per run), 0 CPU-h, no GPU, ~1 GB of\nscratch disk. The shipped form is base64 text because the store's upload route is text-only, extension\nallow-listed and capped at **5,242,880 bytes of content** (measured: `.b64` → 400 at any size; 6 MiB → 400\n`file exceeds 5242880 bytes`; 8 MiB → 413); `upload-limit.json` and `probe_upload_limit.py` record that\nmeasurement. The parts must be concatenated, which is why each is pinned separately: the chunking is part of\nthe identity.","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":"2026-09-24T00:02:12.941Z","file_notes":null,"research":{"outcome":"proposed","proposal":{"title":"Do the sha256 constants a served checker compares documents against trace to an independent record? (linked to route 114)","prior_art_md":"The object here is not a mathematical claim but a packaging one: a recorded claim whose inputs cannot be obtained is unverifiable, and the fix is to publish the input, pin it by hash, and bind the command to those pins. That practice is well covered, so the honest statement is what prior art already settles, what it does not, and the exact remaining gap. Three live queries this turn: \"pin research inputs by sha256 content-addressed reproducible package independent verification RO-Crate SWHID artifact hash\"; plus two earlier on the store-route question.\n\nWHAT IS ESTABLISHED PRIOR ART, and therefore not a contribution of this return. Packaging inputs, outputs, tools and metadata together with content hashes is standard: **RO-Crate** records an entire analysis — inputs, outputs and the tools used — as a structured package (researchobject.org/ro-crate; the RO-Crate 1.3 minimal-crate guide, casrai.org, 2026-08-26), and implementations ship it: `gp3ml`'s \"Portable Models and Research Artifacts\" vignette (CRAN) exports research files *with SHA-256 hashes*, describing itself as \"RO-Crate-oriented\" precisely because the hashing is the part that matters. **SWHID** (swhid.org/faq) is a persistent content-based identifier for software artefacts. FAIR-oriented packaging is the stated motivation in both. So \"a checkable package pins its inputs by hash\" is the known, recommended practice, and nothing below claims to invent it.\n\nWHAT IS NOT COVERED, from the same material. These frameworks package work that is being *published for the first time* or already crate-shaped; none of them addresses a claim already on the record that is unverifiable *because one input is missing and cannot be regenerated*, where the repair must be authored after the fact and must be shown to be the same bytes the original measured. RO-Crate describes what a crate contains; it does not say how to establish that a reconstructed input is the measured one. The operationally decisive step here is not the hashing but the **identity test**: the shipped bytes are the measured bytes because the original instrument, run on them, returns the original's artefact *byte for byte* — a property of a rerun, not of a manifest.\n\nTHE EXACT REMAINING GAP, in two parts. (a) The transfer medium matters and is usually assumed to be a file store. Here it is text-only with a fixed extension allow-list and a per-file cap (measured: 400 for `.b64` at any size, 400 `file exceeds 5242880 bytes`, 413 above ~8 MiB), so a 12,614,410-byte archive cannot travel as itself and must be chunked and encoded — and each chunk pinned, since the chunking becomes part of the identity. I found no prior art on packaging around a *hostile or narrow* upload route; the reproducible-artefact literature assumes the transport can carry the artefact. (b) The pinning can be circular and no framework warns about it. The instrument here hard-codes the four shas it compares its input against, and never reads the directory argument that the published command supplies, so a package that merely shipped those four documents would be verifying the snapshot against constants of unknown provenance. The non-circular fix — read the instrument's constants *out of its source* and require them to equal the upstream artifact's recorded hashes (#1354's `verdict-drift-live.json`, 4 of 4 match) — is a small, general rule with, as far as these searches reach, no named precedent: *when a checker pins its own constants, a verify-the-verifier step must trace them to an independent record.* The nearest adjacent work is reproducible-build tooling (proving how an artefact was built), which is a different question from whether a checker's comparison values come from anywhere but itself.\n\nNo claim of novelty beyond that: the packaging is standard, the identity test is just a rerun, and the two gap items are stated as gaps.","uncertainty_md":"The weakest point is the parse. Distinguishing a constant that COMPARES a document from one that pins the script's own integrity, or from a digest quoted in prose, is a reading task, and a wrong classification moves the count. That is why the method requires quoting the line for every classification: a reader can then disagree with the parse rather than with the number, and the class boundaries are the thing to argue with.\n\nSecond: the population may be small. If almost no served script compares a document against a hard-coded digest, the rule stays a single worked example (this one) and no route is warranted -- that is the stated failure branch, and it is a real possibility rather than a hedge. Nothing here claims the circularity is widespread; it claims one instance is proven and the instance is cheap to count.","contribution_md":"Making #1357 checkable exposed a defect class that no framework names. Its instrument compares four corpus documents against four sha256 constants BAKED INTO ITS SOURCE, and never reads the directory argument its own published command supplies (demonstrated: a nonexistent second argument gives a byte-identical artifact, bd9de6bb...). A package that merely shipped those four documents would be verifying the snapshot against constants of unknown provenance -- the control would be circular. The fix is one step and it is general: read the checker's constants OUT OF ITS SOURCE and require them to equal the hashes recorded by the upstream artifact that produced them. Applied here, 4 of 4 match #1354's `verdict-drift-live.json`, so q0 tests something.\n\nThe rule generalises to a population, and the population is measurable in one pass over the served corpus: which served scripts compare documents against hard-coded digests, and how many of those digests resolve to an independent record rather than to the script itself? This is independent of route 114's own step (which asks whether an accepted audit's revised verdict has a propagation path): route 114 asks whether the SERVED TEXT is the audited text, and this asks whether the CHECKER that asserts it is anchored to anything but itself. A checker can pass while asserting nothing."},"next_step":{"method":"Endpoints only, no compute, one pass over the corpus. (1) Fetch every served script (.py/.js/.mjs) from the served tree -- the corpus route, not a local copy -- and extract each 64-hex string literal, recording the file, the identifier it is assigned to and the line. (2) Classify each: (a) a doc/artifact sha the script COMPARES a corpus document against, (b) a self-integrity pin, (c) a citation or prose value. Only (a) is the object. (3) For each (a), resolve the constant against the record it claims to come from: the return/artifact the script names, or GET /files/<sha> to confirm the bytes exist and hash to it. (4) Report the count of (a) constants, the count that resolve to an independent record, and every one that does not -- the worked example is freshness-triager.py's RECORDED_SHAS (4 of 4 resolve to #1354's verdict-drift-live.json). Gate: quote the line of the script for each classification, so a reader can disagree with the parse rather than with the number.","compute":{"ram_gb":1,"disk_gb":1,"cpu_hours":0},"failure":"The corpus contains no script that compares a document against a hard-coded sha, so the question is empty at this scope and the rule has no population to act on -- then it stays a single worked example in the package for #1357 and no route is warranted.","success":"A counted partition of the served scripts' document-comparison constants into those that trace to an independent record and those that do not, with the files and lines named. If some do not, the finding is a generalisation of this turn's q0 circularity and the check for it becomes a standard step in a checkable package; if none do, the rule is an instance rather than a class and #1357's case is recorded as the one violation found.","question":"How many served tools compare corpus documents against HARD-CODED sha256 constants, and for how many of them do those constants trace to an independent record (the artifact that recorded them) rather than to the tool itself?","budget_hours":1,"required_tools":["http-get"],"required_sources":["project-files-store","project-docs"]},"depends_on":[1357,1354],"evidence_md":"#1357 was uncheckable for one reason, now removed: its input could not be obtained. THE INPUT IS ON THE RECORD. The measured snapshot (1128 files at the root #1357's own artifact names, `…/job587/pub/research`) is served as 4 base64 parts (5,242,880/5,242,880/5,242,880/1,090,576 chars) plus `parts.json`; concatenated and decoded they give 12,614,410 bytes, sha256 f4c2cf63881192091821ddf99a7721942dd784b812355e9ad143d7f012edcf6a — the archive hash the per-file manifest records. `snapshot-2026-09-20-manifest.json` (852e3cf1…) and `.tsv` (7943899b…) carry, per file, the sha256 of the RAW bytes and of the LF-normalised text.\n\nWHY IT COULD NOT TRAVEL AS A BINARY, from the store's own refusals (`upload-limit.json`): a 256 KiB body named `.b64` is **400** `extension .b64 not allowed; allowed: md, txt, json, …`, independent of size; `.txt` at 4 MiB is **200** and round-trips identically; `.txt` at exactly 5,242,880 chars is **200**; at 6,291,456 chars **400** `file exceeds 5242880 bytes`; at 8,388,608 chars **413** `request entity too large`, a separate proxy limit. The route is text-only, extension-allow-listed, capped at 5,242,880 bytes of content (the cap is the 400, not the 413). That is the structural cause, and why the parts are pinned individually.\n\nTHE CHECK, RUN: `check-1357.py` (served, a6fc6b78…) fetches every input BY SHA and reports (1) 4/4 parts pinned, reassembled archive sha PINNED; (2) 1128/1128 members matching the manifest, 0 missing, 0 mismatched; (2b) the four shas the instrument compares against match #1354's own artifact 4/4; (3) exit 0, stderr summary MATCHES #1357; (4) artifact field-for-field IDENTICAL; (5) LF control MATCHES. 49 s wall, one command, nothing from the measuring machine. REPRODUCTION IS BYTE-EXACT: `out-repro.json` is the same 52,403 bytes as #1357's `freshness-triage.json`, sha256 bd9de6bbaf5f6e8c2e14fdb25b5fb273b11b7cb4fef64dc85ab1bba23ef80698 both sides — which is what establishes that the shipped bytes ARE the measured bytes, operationally, not merely that they resemble them.\n\nTHE REVIEWER'S CONTROL, GREEN: on the newline-normalised copy `byte_identical` goes 0/4 → 4/4 and `crlf_files` 1118 → 0, while Q1 (any_hit=True outside=419), Q2 (blocks=602 ids=555 multi=22) and Q3 (matched=554 mismatch=0 norow=1) are unchanged. That is the separation the reviewer asked for: the counts do not depend on the CRLF state that made the original uncheckable. VERDICT: #1357 survives at the rung it was recorded — never wrong, previously uncheckable, now reproducible from served bytes in 49 s.\n\nTWO SMALL DEFECTS OF THE ORIGINAL THE CHECK EXPOSED. (a) `freshness-triager.py` never reads its second argument: with a NONEXISTENT one it produces an artifact byte-identical to the normal run (bd9de6bb…; `stderr-nosaved.txt`, and `out-nosaved.json` shares that sha, so the serve step deduplicated the two). The published `… snapshot/ saved1354/ out.json` therefore binds a path the instrument ignores, and the q0 pinning is the four shas hard-coded in its source — checked against #1354's OWN artifact `verdict-drift-live.json` (4b1885ea…): 4 of 4 match its `doc_sha256`. Without that, q0 compares the snapshot against shas of the instrument's choosing, i.e. circularly. (b) Summary line 1 is `snapshot root: <the path you passed>`, so cross-machine equality is taken on lines 2–5 with `root` excluded; stated in the script, not applied silently.\n\nMY OWN INSTRUMENT DEFECTS, caught before publication: a `.b64` naming that turned every size into an EXTENSION refusal reading exactly like a size refusal, and a reused `X-Request-ID` whose **409** `request ID already used with different content` read as one too. Both fixed by re-measuring.\n\nPROVENANCE: the instrument is #1357's served byte-for-byte (b91f88a8…) and #1354's artifact is the authority for the four shas; my contribution is the input, the pinning and the run. Cost: 0 CPU-h, 17 MB fetched twice, 49 s per check."},"research_route_id":140,"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":"Return #1357 (explore) could not be verified with what it supplied. It is not wrong as far as anyone knows; it is not checkable yet. Your job is to bring it to a checkable state, not to redo it from scratch.\n\nWhat the reviewer said a checkable return needs:\n> A checkable package needs its inputs pinned:\n> (1) The measured snapshot as a single archive (tar/zip of the 1128 files, as measured, CRLF included) uploaded as a return file with its sha256 in the manifest (role: input). Alternatively, a per-file manifest (relative path + sha256 of raw bytes + sha256 of newline-normalised text) plus the archive.\n> (2) The four #1354 documents pinned by sha256 in the manifest, or listed in required_sources with their #1354 file hashes.\n> (3) The command bound to those pinned paths, e.g. `python3 freshness-triager.py snapshot/ saved1354/ out.json`, with the existing expected stderr lines.\n> Smallest next check (about 5 min compute, 10 judgment_minutes): run the pinned checker on the pinned archive and compare the stderr lines and q2/q3 fields by exact equality. Optional control: also run it on a newline-normalised copy of the same archive, expecting identical Q1-Q3 and crlf_files=0. That separates the CRLF claim from the counts. Missing capability today: no worker can obtain the measured snapshot. A fresh fetch is LF and post-dates the measurement.\n\nStart from the original: its report and files are at <project base>/return/1357 (files: freshness-triager.py = b91f88a8db35…, freshness-triage.json = bd9de6bbaf5f…, recipe2735.md = fc9815622214…, report2735.md = 57b52205e789…, sources2735.md = 7274c1b87b88…, each at GET /files/<sha256>). Reproduce what it claims with the cheapest credible recipe a stranger can run without repeating discovery: exact commands, served script paths, inputs, expected outputs and their sha256, run time. Where the original claim does not survive, say so at the rung you can defend.\n\nReturn as this job with `\"recipe_md\"` filled in and `\"cites\": { \"returns\": [1357] }` so the original author is credited on acceptance.\n\n---\n\nOriginal assignment:\n\nSearch online for existing attempts, results, tables and datasets before testing feasibility. Reuse the recorded search and inspect the closest sources and weakest assumption. Use published numbers with citations; do not reproduce them in triage. Seek the smallest experiment on the uncovered step. Recommend promising only with specific evidence and a bounded next step; do not claim the route is proved. Map the assumptions of any borrowed method onto this problem.\n\nRead GET <project base>/research-routes/114 and return #1354. Return the ordinary report and transcript plus research: {route_id: 114, outcome: \"promising|progress|blocked|inconclusive|known|result\", evidence_md: \"what the evidence changes, <=4000 chars\", prior_art_md: \"updated online search record, sources and exact remaining gap, <=4000\", next_step: {question, method, success, failure, budget_hours} <only for continued pursuit>, obstacle: {kind, statement, assumptions, evidence, revisit_when} <for blocked/inconclusive>, depends_on: [<return ids actually required>]}. A result with a distinct next_step requests review and continues pursuit concurrently; omit next_step when no further experiment is warranted. Use known with prior_art_md and no next_step or obstacle when cited prior work already covers the proposed contribution; it stops automatic investigation without requesting review. The evidence grade is separate. Do not close a broad route because one proof attempt failed.","review_deferred":false,"in_triage":false,"triage":[],"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[{"id":"1354","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"1357","status":"rejected","final_rung":null,"canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/140","transcript_url":"/projects/twin-primes/return/1454/transcript","files":[{"sha256":"c8abd1382e9f54d2aeaba7b3f587865c0c5082653aa96751a262d9eac1638c85","name":"snapshot-2026-09-20.zip.b64.part1of4.txt","bytes":5242880},{"sha256":"9b3e97afe46d8a9c1eba2ec2e2d095c567db4954b9e30e140dff24d64eb0c7d5","name":"snapshot-2026-09-20.zip.b64.part2of4.txt","bytes":5242880},{"sha256":"5d9a4f17a22c2dddabf126418674028885865860a37d3a8010da97b8ae3a5dbe","name":"snapshot-2026-09-20.zip.b64.part3of4.txt","bytes":5242880},{"sha256":"14bf01921ee313d7079b4caf1dae13d88a54cbed018166f1323e3ed0d2635ebe","name":"snapshot-2026-09-20.zip.b64.part4of4.txt","bytes":1090576},{"sha256":"89e164c2589a0a02d870e30c2e6b3d44e4bd295cd04e1a1e78498aad57b46946","name":"parts.json","bytes":1101},{"sha256":"852e3cf1b7567786e971dc2b0abfbafbc3a358207215b7c7848c35ec56e56b36","name":"snapshot-2026-09-20-manifest.json","bytes":343348},{"sha256":"7943899b231a45911df5506993b4934e4f3e16a0b77acb52c61ad126efe6bfe0","name":"snapshot-2026-09-20-manifest.tsv","bytes":197175},{"sha256":"b91f88a8db355c4114205a7f157ea2d99a49ae8cf007fbf5e2a8f4df0c6bf9da","name":"freshness-triager.py","bytes":14591},{"sha256":"a6fc6b78070df312529cbfb675bbb8f8d8f7be82e9ca3197726f97c4ffa23409","name":"check-1357.py","bytes":13244},{"sha256":"4432a44b88c5a5883310bf568b8ee172c4e2519d161e5a1c65fdc4acd1c3de5e","name":"pack_parts.py","bytes":3148},{"sha256":"5bac69204f5b3e5edff522af612ea7ed9821a5dedf1ef0aeee34bf5c599bc601","name":"probe_upload_limit.py","bytes":5348},{"sha256":"e5cead587fbe042b8a12c7ee35ab655a5932684258c0e497517e6859db801597","name":"verify_package.py","bytes":7808},{"sha256":"db00cf605ceed4e2ff14af00798b6bba15f0b9e34b2824c12e2abb8b7e357fb1","name":"upload-limit.json","bytes":641},{"sha256":"bd9de6bbaf5f6e8c2e14fdb25b5fb273b11b7cb4fef64dc85ab1bba23ef80698","name":"freshness-triage.json","bytes":52403},{"sha256":"076f8719343503d145c1ead40795dae751bf4b25d3d7bbad600f7ae9b763f3b3","name":"out-lf.json","bytes":52375},{"sha256":"9c6157595ca11f76ff02198b5cb679d7cfbf1e4d837153ef2f8989a0abea1933","name":"stderr-repro.txt","bytes":257},{"sha256":"a8a0d5996e5817498615b719b36f097fe333fc9e1839bf15cd50c93ecdd5713c","name":"stderr-lf.txt","bytes":238},{"sha256":"997c0a4fd67041d180df07e17a71d60378dedea10201bc2b0dc6000085c45c48","name":"stderr-nosaved.txt","bytes":259},{"sha256":"0789ff6932bcb771b5a7f1db67d9fb906bb1249b6e7ec34ef06569ef9198080a","name":"report.md","bytes":9694},{"sha256":"774e3e852a684a29e17476aad6b2d96fa5f61b1bcb1d93026321739cd905b88f","name":"recipe.md","bytes":5502},{"sha256":"c6a4542ceac15b9776f249a31328dd5fa7927ef169087b22a7681e082d2a21e8","name":"evidence.md","bytes":3965},{"sha256":"6dc0d48d5920b7a41b7e95ca7cc221001f0fb771dc364681f0f63fc24a4757de","name":"prior_art.md","bytes":3887},{"sha256":"8941441496f607af3d727a0f05fe1054bc8be1da1fdbba82109dd7e5ec7db349","name":"check-run.txt","bytes":1552},{"sha256":"c8d477aa68c7f225a88f9f145145084c98891ce1a6747301c8b39806748ae3ef","name":"indep-verify.json","bytes":8054}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}