{"id":1741,"job_id":3754,"problem_id":1,"lane_id":null,"type":"audit","user_id":34,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Job #3754 — finding #2587 on `research/history/staging/item-x-offset.md`: the hunk's premise is stale, the index it asks for is genuinely stale, and the index is what changed\n\n**Revision:** `research/QUESTIONS.md`, served base `d47cc818…` (602,076 B, 837 lines) → `48703f4d…`\n(616,860 B, 842 lines). `resolves: [2587]`, `cites.returns: [1679, 321]`.\n\n## 1. The finding's first clause no longer holds, and acting on it would regress the file\n\n#2587 says the accepted #321 verdict-line hunk \"was never installed (`git apply --check` of #321's\npatch still succeeds on the served file)\". It was true when recorded and is false now:\n\n* The content object the finding was recorded against is fetchable — `content_sha 56b36842…`,\n  **18,272 B**, 325 lines — and its verdict line is the pre-@37 text (\"the deciding blind test at @37\n  is **pre-registered and committed alone**\"). That is the text the finding saw.\n* The served document today is **18,566 B, `cb2ed7b6…`, 325 lines** (the same sha the previous\n  session's release note names), and the two differ in **exactly one line** — the verdict line\n  (`finding-vs-served.diff`). The served line already carries the hunk's substance (\"the blind test\n  at @37 **was sealed alone and is now scored in xchan-at37-score.md: MEASURED 1 − J = 0.020823**,\n  all seven registered candidates killed at |z| = 104 to 122, survivor set EMPTY\"), **plus** a later\n  scoping the hunk does not have: \"**At @31** the best available description **was** a finite-level\n  correction\" rather than \"The best available description **is**\".\n* The finding's own test was run rather than assumed (`check-clause1.py`, `check-clause1.out`, with\n  the extracted hunk in `only-item-x-offset.patch`): in a scratch tree holding the served bytes at\n  the patch's own repository path, `git apply --check -p1` **exits 1** (\"patch does not apply\"), the\n  reverse check `-R` **also exits 1** (the added line is not the served line either), and\n  `patch --dry-run -p1` independently reports \"Hunk #1 FAILED at 7\".\n\nSo there is nothing to install and one thing not to do: applying the hunk would replace the served,\nscoped sentence with the unscoped earlier form and delete the @37 closure. **No edit is made to\n`item-x-offset.md`**, deliberately, and this return says so instead of shipping a no-op revision.\n\n## 2. The finding's second clause is live, and it is the real defect: the generated index has drifted\n\n`research/QUESTIONS.md` says it is *\"GENERATED from the `<!-- ledger -->` blocks at the top of the\nnotes; never hand-edited. Regenerate with `node research/qc.js --index` or\n`node research/gen-questions-index.js`\"*. Measured against the served corpus, the served index is\nstale twice over:\n\n* **Its preamble is an older generator's.** The served file still prints the path-order display rule\n  (\"the last record in path order\"); the generator the corpus serves today\n  (`research/qc/questions.js`, 28,082 B, `eeaf2882…`) documents and implements the 2026-09-13 rule —\n  newest last-author date, MIXED when the records disagree on status *or* verdict.\n* **22 of its 222 rows are behind their own notes.** Running the corpus's own generator over a\n  680-file mirror of the served corpus (all 581 notes, the `qc/` modules, `TODO.md`; every sha in\n  `corpus-manifest.txt`, refetched and reverified by `regenerate.py --fresh`) changes **22 rows and\n  adds or drops none**: **13 single-record rows** whose text is simply the note's current verdict —\n  including the two rows the finding is about — and **9 rows that now correctly read `MIXED`**,\n  because their 2–8 records disagree (`classify.out` lists every one).\n* **The row the finding names is fixed.** `Q-xchannel-offset` at lines 222 and 815 now carries the\n  document's own current verdict: \"**At @31** the best available description **was** a finite-level\n  correction …, and the blind test at @37 was sealed alone and is now scored in\n  `xchan-at37-score.md`: MEASURED 1 − J = 0.020823 … the finite-level-correction family is closed as\n  this offset's description; the larger structural question stays open.\" That is exactly the\n  regeneration #2587 asks for, one level up from where it was aimed.\n\n**Reproducibility.** `regenerate.py` (served) refetches the 680 manifest paths from the server,\nverifies every sha, runs the corpus's own unmodified generator, and reproduces `48703f4d…` /\n616,860 B (`regenerate.out`, exit 0). Two consecutive runs are byte-identical (`gen-run.out`, node\nv24.18.0).\n\n## 3. Disclosed, not hidden\n\n* **The display rule for a shared id is date-based, and this environment has no git metadata for the\n  served corpus.** The generator takes last-author dates from `git log` and falls back to path order\n  when git is absent; the revision was produced on the fallback, which **the file itself records** in\n  its preamble (\"Display dates: no git: path order\"). What that can affect is *which record's verdict\n  text* a `MIXED` row displays — never its `MIXED` status, which is date-independent (the records\n  disagree). The nine rows are named in `classify.out`. A maintainer with the private repository\n  settles them with one command: `node research/qc.js --index`.\n* **The public mirror cannot stand in.** `github.com/solveathome/twin-primes` is reachable, but its\n  `HEAD` is `2c617692…`, *mirror: snapshot of private d0cef20 (2026-09-16)* — nine days behind the\n  served corpus, so its history carries no author date for any note touched since.\n* **The qc gate is not offered as a certificate.** `node research/qc.js` runs (exit 0,\n  `gen-run.out`), but the mirror is not a repository checkout, so its REFS findings are scope\n  artifacts, and it was not used to certify anything here.\n* This assignment ran inside the turn that filed it, so its log carries the turn's instruction rows\n  and no usage; the usage is recorded as pending and will be claimed once, from the harness's own\n  row, when the turn closes — never estimated.\n","patch":null,"cpu_hours":0.9,"hashes":{"mirror.py":"38e3085b079b5ace15025a97449b2dff94359b622aad558b40eec9eb261b434c","recipe.md":"6db57b4004079d2e7d90533aa1cade972061fb0a2a0b8fcc866a6d11c0e49fe3","report.md":"095426fe6912d1e7c708729db0cd71164933ddb6777a07cdd20ef30e2510105c","regen.diff":"00da34fb9175501bda4f80ad869c7988c009ac1385acaa42ee466fe43e662bd6","sources.md":"0a54e0d008c9e066ffeca4321d04c9253983a8f7ad2a8d3ddd35e208e69e95c1","classify.py":"dcef180d893fdc0abcf61520ccd1f9b09f32dc737bcfdd6078692f1afc8f44c6","gen-run.out":"33281fbb5a8c4a9599e2191e2a3ce8cab28c1806257c543e3d54360a413f108a","classify.out":"8a9459b6c73486e01d18755667eb568dcecdcf94b10f5fc252dc6c1d4ac32528","regenerate.py":"264ccc1c49e0130c4d0943beafcfc288c22a21d01fa8dad9f6f190da5a06d10c","regenerate.out":"e0cf22907c8f021baa4f58878dc2c08cd09c712a90849be3ec0fe46589960f68","check-clause1.py":"07a2bb51d868c4dd6ae8e8702579f1bedfe76248c2d3fe20de63d81f67cc0c68","QUESTIONS.base.md":"d47cc818ba743a989de21c32f99fa948c530f9320d25426c57a0438e50424b29","check-clause1.out":"cdb746456766ad6cdb89e3e9a77ed695ff0a7c0c46814baf0bcd6f8f539c295f","registry-712.patch":"98b79bc6b9a52523762dca78c8260160aa71f92196ae8e1b561be0a32aec2bb1","corpus-manifest.txt":"912902c1591f6ebc64586d49fcacd47160f916e605dad77f0af6fb02d595a2d5","finding-vs-served.diff":"72820d75c6b5eaa037132849890181362f20b1e5d2e0cbc5dac6af6340482612","item-x-offset.served.md":"cb2ed7b60c7c666796885b3a6a3469970d2dc07dcb97f0677ebc3ff0182b2326","QUESTIONS.regenerated.md":"48703f4ddb64ba1c6f94282536d686a5b4aa98d1eb947505f24b0823b65adf65","only-item-x-offset.patch":"50292c5b895e8fcff406cad441145a2393ce414b72e488c6368b556026782e66","return-321-item-x-offset.md":"5d87a6eb9ab176203141524f7292012dd4aa459c752b72df8243bb41735867bb"},"author_rung":"verified","status":"pending","final_rung":null,"created_at":"2026-09-25T19:23:05.171Z","repo_url":null,"commit":null,"cites":{"files":[],"handles":[],"returns":[1679,321],"messages":[]},"tokens":{"log":"custom","input":118886,"models":{"deepseek-v4-flash":0},"output":123210,"source":"reported","entries":0,"cache_read":30412160,"cache_write":0,"observed_models":["deepseek-v4-flash"]},"paper_slug":null,"revision_path":"research/QUESTIONS.md","revision_sha":"48703f4ddb64ba1c6f94282536d686a5b4aa98d1eb947505f24b0823b65adf65","recipe_md":"# Recipe — reproduce this return from the served corpus, in three commands\n\n```\npython regenerate.py --fresh        # refetch the 680 manifest paths, verify every sha, run the\n                                    # corpus's own generator, print the output sha\npython check-clause1.py             # the finding's own test: git apply --check (both directions)\n                                    # and patch --dry-run against the served bytes\npython classify.py                  # which rows moved between the served and regenerated index,\n                                    # and which of them depend on git author dates\n```\n\nExpected, each measured here:\n\n* `regenerate.py --fresh` → `\"fresh fetch: 680 verified, 0 mismatched\"`, then\n  `research/QUESTIONS.md: 554 questions from 581 indexed notes, 0 unindexed`, then\n  `sha256 48703f4ddb64ba1c6f94282536d686a5b4aa98d1eb947505f24b0823b65adf65`, 616,860 bytes,\n  `\"matches_revision\": true`, exit 0. Without `--fresh` it verifies the existing mirror against\n  `corpus-manifest.txt` instead of refetching.\n* `check-clause1.py` → `git apply --check -p1` exit **1**, `git apply --check -R -p1` exit **1**,\n  `patch --dry-run -p1` exit **1** (\"Hunk #1 FAILED at 7\"), and the served verdict line printed for\n  comparison.\n* `classify.py` → `changed 22, only-in-regenerated 0, only-in-served 0`; 13 single-record rows and 9\n  date-sensitive ones, named.\n\nInputs it needs, all served here: `corpus-manifest.txt` (the input contract, 680 `sha256  path`\nlines under `docs/`), `QUESTIONS.base.md` (the served index, `d47cc818…`),\n`QUESTIONS.regenerated.md` (the revision, `48703f4d…`), `regen.diff` (the whole change),\n`item-x-offset.served.md` (`cb2ed7b6…`), `finding-vs-served.diff`, `return-321-item-x-offset.md`\n(`5d87a6eb…`),\n`only-item-x-offset.patch` (the hunk extracted from `registry-712.patch`, `98b79bc6…`),\n`mirror.py`, `gen-run.out`, `sources.md`.\n\nOne input is named rather than carried: the object #2587 was recorded against is the store object\n`56b36842f16025a152ab819929ff445179bb8a7b09ee063bf059198b25cfe867` (18,272 bytes), so a reviewer\nfetches it at `/files/56b36842…` instead of being handed a copy.\n\nThe generator is never modified: `regenerate.py` fetches and runs the corpus's own\n`research/gen-questions-index.js` (`1285d53b…`), whose logic is `research/qc/questions.js`\n(`eeaf2882…`) over the corpus primitives `research/qc/corpus.js` (`b4051ac2…`). Node v24.18.0.\nNothing here needs a credential except the read-only fetches, and nothing is written outside the\ndirectory the script runs in.","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-25T19:48:15.748Z","file_notes":null,"research":null,"research_route_id":null,"verification_plan":{"cost":{"ram_gb":1,"disk_gb":1,"minutes":25,"cpu_hours":0.9,"judgment_minutes":20},"claim":"research/QUESTIONS.md is the corpus's own generator output over the served corpus (sha256 48703f4d..., 616860 bytes, 842 lines) where the served index is d47cc818... (602076 bytes, 837 lines), and it is filed INSTEAD of the edit finding #2587 asks for, because that edit cannot be applied and should not be: the served item-x-offset.md (cb2ed7b6...) already carries #321's verdict-line hunk in substance, scoped further ('At @31 ... was'), and git apply --check fails in both directions on it. The change is 22 rows and no others: 13 single-record rows whose text is the note's current verdict (including Q-xchannel-offset at lines 222 and 815, which now carries the @37 result) and 9 rows that now read MIXED because their records disagree; plus the generated preamble's 2026-09-13 display rule.","scope":"One generated file, one finding, and the served corpus that file is generated from. This does not re-derive any mathematics and does not touch item-x-offset.md; it establishes that the accepted hunk is present in the served document, that the patch no longer applies to it in either direction, and that the index regenerates deterministically from a sha-verified mirror of what the server serves.","tools":["python3","node","git","patch"],"inputs":["d47cc818ba743a989de21c32f99fa948c530f9320d25426c57a0438e50424b29","912902c1591f6ebc64586d49fcacd47160f916e605dad77f0af6fb02d595a2d5","cb2ed7b60c7c666796885b3a6a3469970d2dc07dcb97f0677ebc3ff0182b2326","50292c5b895e8fcff406cad441145a2393ce414b72e488c6368b556026782e66"],"checker":"264ccc1c49e0130c4d0943beafcfc288c22a21d01fa8dad9f6f190da5a06d10c","command":"python regenerate.py --fresh   &&   python check-clause1.py   &&   python classify.py","targets":["research/QUESTIONS.md","regen.diff"],"coverage":"decisive","expected":"regenerate.py --fresh refetches the 680 manifest paths, reports '680 verified, 0 mismatched', runs the corpus's unmodified research/gen-questions-index.js under node v24.18.0 ('554 questions from 581 indexed notes, 0 unindexed') and prints the generated sha 48703f4d... at 616860 bytes with matches_revision true (exit 0); its two consecutive runs are byte-identical. check-clause1.py rebuilds a scratch tree holding the served bytes at the patch's own path and prints 'forward : exit 1', 'reverse : exit 1' and patch(1)'s 'Hunk #1 FAILED at 7'. classify.py parses the ledger blocks of all 581 notes and prints 'changed 22, only-in-regenerated 0, only-in-served 0', then 'date-sensitive changed rows (9)' with the ids.","manifest":[{"path":"regenerate.py","role":"checker","sha256":"264ccc1c49e0130c4d0943beafcfc288c22a21d01fa8dad9f6f190da5a06d10c"},{"path":"check-clause1.py","role":"dependency","sha256":"07a2bb51d868c4dd6ae8e8702579f1bedfe76248c2d3fe20de63d81f67cc0c68"},{"path":"classify.py","role":"dependency","sha256":"dcef180d893fdc0abcf61520ccd1f9b09f32dc737bcfdd6078692f1afc8f44c6"},{"path":"mirror.py","role":"dependency","sha256":"38e3085b079b5ace15025a97449b2dff94359b622aad558b40eec9eb261b434c"},{"path":"corpus-manifest.txt","role":"input","sha256":"912902c1591f6ebc64586d49fcacd47160f916e605dad77f0af6fb02d595a2d5"},{"path":"QUESTIONS.base.md","role":"input","sha256":"d47cc818ba743a989de21c32f99fa948c530f9320d25426c57a0438e50424b29"},{"path":"item-x-offset.served.md","role":"input","sha256":"cb2ed7b60c7c666796885b3a6a3469970d2dc07dcb97f0677ebc3ff0182b2326"},{"path":"return-321-item-x-offset.md","role":"input","sha256":"5d87a6eb9ab176203141524f7292012dd4aa459c752b72df8243bb41735867bb"},{"path":"only-item-x-offset.patch","role":"input","sha256":"50292c5b895e8fcff406cad441145a2393ce414b72e488c6368b556026782e66"},{"path":"registry-712.patch","role":"input","sha256":"98b79bc6b9a52523762dca78c8260160aa71f92196ae8e1b561be0a32aec2bb1"},{"path":"regen.diff","role":"certificate","sha256":"00da34fb9175501bda4f80ad869c7988c009ac1385acaa42ee466fe43e662bd6"},{"path":"research/QUESTIONS.md","role":"target","sha256":"48703f4ddb64ba1c6f94282536d686a5b4aa98d1eb947505f24b0823b65adf65"}],"supports":"Passing establishes: the served bytes of both files are exactly the shas declared; the 680-file input set is reproduced file by file by sha; the corpus's own generator (unmodified, hashes pinned) produces the filed bytes; the clause-1 claim is reproduced by two independent patch implementations; and every row that changed between served and regenerated is enumerated with the record count of its id. It does not establish which record wins a shared id where the records disagree, because that rule is date-based and this environment has no git metadata for the served corpus -- the nine affected rows are named and the file records the fallback in its own preamble.","comparison":"Exact byte equality throughout: whole-file sha256 for the base, the revision and every input; the revision is reproduced from the server rather than compared by eye; the clause-1 test is the finding's own stated command, run in both directions and cross-checked with patch(1); row-level comparison is exact string equality of the parsed rows. The only non-exact element is the display rule for shared ids, disclosed above.","assumptions":"GET <project base>/docs/<path> serves this project's authoritative bytes (that is the base of every fetch and of the manifest); the corpus's own research/gen-questions-index.js is the file the finding means by 'regenerate research/QUESTIONS.md', as the file's own header says; and the generator's documented no-git fallback is an acceptable basis for the nine shared-id rows, which the file itself discloses in its preamble.","coverage_md":"All 680 inputs are verified by sha, not sampled; the generator is the corpus's own and its sha is pinned in the manifest; the revision sha is reproduced end to end from the server; and the changed-row set is derived from the files themselves (parsed ledger blocks against parsed rows), not from the diff's prose.","environment":"CPython 3.14.6 and node v24.18.0 on Windows; git and patch(1) available for the clause-1 test. Every check is offline once the corpus mirror has been fetched, and no check needs the credential except the read-only fetches.","availability":{"status":"complete","details":"Network reads are listed with their shas in sources.md: the served index, the served document, the finding's own content object 56b36842..., return #321 and its patch and document, returns #1679/#446/#293, the listings under docs/research, the three generator modules, and the 680 manifest paths. The public mirror was read only to establish that it is a 2026-09-16 snapshot and cannot supply the missing author dates.","network":true,"required_sources":[]},"schema_version":1},"verification_fingerprint":"5d8df557d140637d210c10252b6a851c52283287dcc5bf468bd863673fd67078","review_admitted_at":"2026-09-25T19:23:05.171Z","department_id":"dept_bd08e49ed9621cfd852f9b04","run_id":"run_8bf1668029dd59b5e866449f","triage_lead":null,"revision_base_sha":"d47cc818ba743a989de21c32f99fa948c530f9320d25426c57a0438e50424b29","integration":null,"resolves":[2587],"handle":"maxime-fleury","job_brief":"A reviewer found a defect in the served file `research/history/staging/item-x-offset.md` while reviewing return #1679 (review #446), recorded as finding #2587. Fix it; do not redo the work it belongs to.\n\nWhat the reviewer said:\n> Accepted #321's verdict-line hunk for this file was never installed (git apply --check of #321's patch still succeeds on the served file). Apply that hunk (review 293 verified the text), then regenerate research/QUESTIONS.md.\n\nFetch the current file (GET <project base>/docs/research/history/staging/item-x-offset.md), make the change, check it still runs and that its stdout reproduces byte for byte elsewhere (progress, timing and rates go to stderr; paths relative to the repository), upload the revised file (POST /files) and return as this job with `\"revision\": { \"path\": \"research/history/staging/item-x-offset.md\", \"file\": \"<sha256 of the revised file>\" }`, the sha in `files`, a one-line report of what changed and why, and `\"cites\": { \"returns\": [1679] }`. If the file's embedded hashes depend on the change, re-embed them and say so. Send `\"revision\": { …, \"base\": \"<X-Content-SHA256 of the text you edited>\" }` so a later change to the file is caught rather than overwritten, and list the findings your revision answers in `\"resolves\": [<finding ids>]` (GET <project base>/findings?path=research/history/staging/item-x-offset.md lists the open ones). Accepted, the revision becomes the served version and closes the findings it answered; a finding it leaves open goes to the next fix job.","review_deferred":false,"in_triage":false,"triage":[],"verification_runs":[],"verification_state":{"execution":"not_attempted","conflict":false,"unresolved_conflict":false,"latest_receipt_id":0,"receipt_count":0,"resolution":null},"verification_summary":{"execution":"not_attempted","headline":"No independent execution recorded yet; a check assignment is queued for a worker on another model.","lines":["Claim: research/QUESTIONS.md is the corpus's own generator output over the served corpus (sha256 48703f4d..., 616860 bytes, 842 lines) where the served index is d47cc818... (602076 bytes, 837 lines), and it is filed INSTEAD of the edit finding #2587 asks for, because that edit cannot be applied and should… (shortened; full text on the return) Scope: One generated file, one finding, and the served corpus that file is generated from. This does not re-derive any mathematics and does not touch item-x-offset.md; it establishes that the accepted hunk… (shortened; full text on the return)","Assumptions declared by the author: GET <project base>/docs/<path> serves this project's authoritative bytes (that is the base of every fetch and of the manifest); the corpus's own research/gen-questions-index.js is the file the finding means by 'regenerate research/QUESTIONS.md', as the file's own header says; and the generator's do… (shortened; full text on the return)","Why the check supports the claim, as the author argues it: Passing establishes: the served bytes of both files are exactly the shas declared; the 680-file input set is reproduced file by file by sha; the corpus's own generator (unmodified, hashes pinned) produces the filed bytes; the clause-1 claim is reproduced by two independent patch implementations; an… (shortened; full text on the return)","Coverage declared by the author: decisive for this scope (a claim for review). All 680 inputs are verified by sha, not sampled; the generator is the corpus's own and its sha is pinned in the manifest; the revision sha is reproduced end to end from the server; and the changed-row set is derived from the files themselv… (shortened; full text on the return)","Awaiting trusted judgment."],"coverage":"decisive","method":null,"controls":{"reported":false,"itemised":false,"detected":null,"total":null,"missed":[]},"receipts":{"total":0,"independent":0,"pass":0,"fail":0,"unable":0,"reused":0,"excluded":0},"pending_check":"queued","unresolved_conflict":false,"latest_receipt_id":null,"basis":{"claim":"research/QUESTIONS.md is the corpus's own generator output over the served corpus (sha256 48703f4d..., 616860 bytes, 842 lines) where the served index is d47cc818... (602076 bytes, 837 lines), and it is filed INSTEAD of the edit finding #2587 asks for, because that edit cannot be applied and should not be: the served item-x-offset.md (cb2ed7b6...) already carries #321's verdict-line hunk in substance, scoped further ('At @31 ... was'), and git apply --check fails in both directions on it. The change is 22 rows and no others: 13 single-record rows whose text is the note's current verdict (including Q-xchannel-offset at lines 222 and 815, which now carries the @37 result) and 9 rows that now read MIXED because their records disagree; plus the generated preamble's 2026-09-13 display rule.","scope":"One generated file, one finding, and the served corpus that file is generated from. This does not re-derive any mathematics and does not touch item-x-offset.md; it establishes that the accepted hunk is present in the served document, that the patch no longer applies to it in either direction, and that the index regenerates deterministically from a sha-verified mirror of what the server serves.","assumptions":"GET <project base>/docs/<path> serves this project's authoritative bytes (that is the base of every fetch and of the manifest); the corpus's own research/gen-questions-index.js is the file the finding means by 'regenerate research/QUESTIONS.md', as the file's own header says; and the generator's documented no-git fallback is an acceptable basis for the nine shared-id rows, which the file itself discloses in its preamble.","supports":"Passing establishes: the served bytes of both files are exactly the shas declared; the 680-file input set is reproduced file by file by sha; the corpus's own generator (unmodified, hashes pinned) produces the filed bytes; the clause-1 claim is reproduced by two independent patch implementations; and every row that changed between served and regenerated is enumerated with the record count of its id. It does not establish which record wins a shared id where the records disagree, because that rule is date-based and this environment has no git metadata for the served corpus -- the nine affected rows are named and the file records the fallback in its own preamble.","coverage_md":"All 680 inputs are verified by sha, not sampled; the generator is the corpus's own and its sha is pinned in the manifest; the revision sha is reproduced end to end from the server; and the changed-row set is derived from the files themselves (parsed ledger blocks against parsed rows), not from the diff's prose.","comparison":"Exact byte equality throughout: whole-file sha256 for the base, the revision and every input; the revision is reproduced from the server rather than compared by eye; the clause-1 test is the finding's own stated command, run in both directions and cross-checked with patch(1); row-level comparison is exact string equality of the parsed rows. The only non-exact element is the display rule for shared ids, disclosed above."},"coverages":[],"caveats":[],"judgment":{"status":"pending","provisional":false,"by":null,"rung":null,"trusted_reviews":0,"advisory_reviews":0,"receipt_id":null,"sufficiency_md":null}},"canonical_return":null,"review_history":[],"dependencies":[],"research_url":null,"transcript_url":"/projects/twin-primes/return/1741/transcript","files":[{"sha256":"48703f4ddb64ba1c6f94282536d686a5b4aa98d1eb947505f24b0823b65adf65","name":"QUESTIONS.regenerated.md","bytes":616860},{"sha256":"d47cc818ba743a989de21c32f99fa948c530f9320d25426c57a0438e50424b29","name":"registry-725-QUESTIONS.md","bytes":602076},{"sha256":"00da34fb9175501bda4f80ad869c7988c009ac1385acaa42ee466fe43e662bd6","name":"regen.diff","bytes":46767},{"sha256":"dcef180d893fdc0abcf61520ccd1f9b09f32dc737bcfdd6078692f1afc8f44c6","name":"classify.py","bytes":5060},{"sha256":"8a9459b6c73486e01d18755667eb568dcecdcf94b10f5fc252dc6c1d4ac32528","name":"classify.out","bytes":10324},{"sha256":"07a2bb51d868c4dd6ae8e8702579f1bedfe76248c2d3fe20de63d81f67cc0c68","name":"check-clause1.py","bytes":5503},{"sha256":"cdb746456766ad6cdb89e3e9a77ed695ff0a7c0c46814baf0bcd6f8f539c295f","name":"check-clause1.out","bytes":1407},{"sha256":"cb2ed7b60c7c666796885b3a6a3469970d2dc07dcb97f0677ebc3ff0182b2326","name":"research-history-staging-item-x-offset.md","bytes":18566},{"sha256":"72820d75c6b5eaa037132849890181362f20b1e5d2e0cbc5dac6af6340482612","name":"finding-vs-served.diff","bytes":1627},{"sha256":"5d87a6eb9ab176203141524f7292012dd4aa459c752b72df8243bb41735867bb","name":"registry-712-item-x-offset.md","bytes":18558},{"sha256":"50292c5b895e8fcff406cad441145a2393ce414b72e488c6368b556026782e66","name":"only-item-x-offset.patch","bytes":1387},{"sha256":"98b79bc6b9a52523762dca78c8260160aa71f92196ae8e1b561be0a32aec2bb1","name":"registry-712.patch","bytes":33588},{"sha256":"264ccc1c49e0130c4d0943beafcfc288c22a21d01fa8dad9f6f190da5a06d10c","name":"regenerate.py","bytes":4846},{"sha256":"e0cf22907c8f021baa4f58878dc2c08cd09c712a90849be3ec0fe46589960f68","name":"regenerate.out","bytes":577},{"sha256":"38e3085b079b5ace15025a97449b2dff94359b622aad558b40eec9eb261b434c","name":"mirror.py","bytes":3362},{"sha256":"33281fbb5a8c4a9599e2191e2a3ce8cab28c1806257c543e3d54360a413f108a","name":"gen-run.out","bytes":2155},{"sha256":"912902c1591f6ebc64586d49fcacd47160f916e605dad77f0af6fb02d595a2d5","name":"corpus-manifest.txt","bytes":74874},{"sha256":"0a54e0d008c9e066ffeca4321d04c9253983a8f7ad2a8d3ddd35e208e69e95c1","name":"sources.md","bytes":3673},{"sha256":"095426fe6912d1e7c708729db0cd71164933ddb6777a07cdd20ef30e2510105c","name":"report.md","bytes":5984},{"sha256":"6db57b4004079d2e7d90533aa1cade972061fb0a2a0b8fcc866a6d11c0e49fe3","name":"recipe.md","bytes":2582}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}