{"id":1121,"job_id":2074,"problem_id":1,"lane_id":4,"type":"explore","user_id":34,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Job #2074 — exact residual-hole repair on the recorded n = 25 state (route 90)\n\nLane: measure. Type: explore (discovery). Attempt `af3907a2e0baf12d075a16492f807508`.\nInput: the served n = 25 residue tuple, **unmodified** —\n`evidence/1098/check-2043.out.json`, sha256 `0d77773d01631d9eb70b76b1…` (the sha route 90\ndeclares as its input; re-fetched and re-hashed this turn).\n\nThe question this turn was pre-registered in #1105: *can an EXACT solve close the SINGLE\nrecorded hole of the recorded state at R = 2028 by residue reassignment rather than by more\ndescent?* The answer is **no, and not within four reassignments** — established by exhaustion,\nnot by a cap. Along the way the target geometry turned out to be different from the one the\nroute declared, and that changes where the bar is.\n\nSemantics used everywhere are the project's own (the definition `verify-2043.py` implements):\na window is *covered* when every one of its integers is ≡ 1 or −1 mod at least one of the first\nn primes. Nothing here re-defines the object.\n\n---\n\n## 1. The instrument, and why its negatives are worth something\n\nCoverage of a candidate window is a bitmask (bit *i* = offset *i* is covered). Two\n**independent implementations** were written and cross-checked:\n\n| file | core | role |\n|---|---|---|\n| `work/repair90.py` | incremental coverage counts, Python loops | first implementation |\n| `work/repair90b.py` | big-int bitmasks, pairwise-disjoint masks per prime so XOR removes a prime's contribution | second implementation, ~7× faster |\n\nBoth search the same object: choose a set of primes, reassign their residues, leave every other\nprime at its recorded residue, and ask whether the window is covered. The branching is\n*chained* — a later move may cover a hole created by an earlier one, which the producer's\ndepth-2 repair could not do — and it is **complete**: at each node it picks an uncovered offset\nand branches over every (prime, residue) pair that covers it with an as-yet unmoved prime. A\nsolution must contain such a pair, so no solution is missed; an equivalent statement of the\nsame fact is that a value whose covered offsets are all covered by the other moves can be\ndeleted from any solution (minimal-solution argument).\n\nK = number of reassigned primes. A run that ends **without** touching its node or time cap is\nreported `exhausted: true`, and that is a *complete* statement: **no** reassignment of ≤ K\nprimes covers the window. A run that hits a cap is reported `aborted: true` and says nothing.\nThe distinction is kept in every artifact.\n\nNegative controls run this turn:\n\n* **Unrestricted enumeration** (`repair90b.py enum`) for K ≤ 2: every subset of ≤ 2 primes and\n  **every** residue value of each (no \"must cover a hole\" restriction, 300 subsets × Π p\n  values). Result: **no witness** at R = 2028. This is the check that the branching restriction\n  above is not hiding a solution.\n* **Two implementations, different traversals**: identical verdicts at every K, with different\n  node counts (an implementation artefact of tie-breaking, both complete).\n* **Five window starts** (197, 200, 226, 227, 250, 268 — see §2): identical verdicts and\n  *identical* node counts at K = 1, 2, 3, so the negative does not depend on where the window\n  boundary falls.\n* A bookkeeping bug was caught by an assertion *before* any result was read (holes were compared\n  in local vs absolute offsets); it is recorded here because the first printed number of this\n  session was wrong and would have been a false \"1 hole\" claim.\n\n## 2. The declared target is not the best one: the hole geometry\n\nThe recorded state has holes at absolute offsets\n`16, 196, 226, 2254, 2296, 2302, 2326, 2374, 2386, 2452, 2506, …` (131 holes in [0, 8000);\n131 is a density count, not a claim of maximality anywhere).\n\nLet `R_max(k)` = the longest window containing at most k holes. Two independent computations\n(sliding window; and the gap formula `holes[i+k+1] − holes[i] − 1`, restricted to the exactly-k\ncase) agree on every load-bearing row:\n\n| k holes | R_max(k) | window | bar 27000/11 = 2454.55 |\n|---|---|---|---|\n| 0 | 2027 | [227, 2254) | — (this is the recorded `best_run_in_best_state`) |\n| 1 | **2069** | [227, 2296) | — |\n| 2 | 2237 | [17, 2254) | — |\n| 3 | 2279 | [17, 2296) | — |\n| 4 | 2296 | [0, 2296) | — |\n| 5 | 2309 | [17, 2326) | — |\n| 6 | 2357 | [17, 2374) | — |\n| 7 | 2374 (2369 exactly-7) | [0, 2374) | — |\n| 8 | 2435 | [17, 2452) | **below** |\n| 9 | **2489** | [17, 2506) | **above** |\n\nThree consequences.\n\n1. The pre-registered target R = 2028 is *not* the biggest single-hole target: the one hole 2254\n   supports a window of **2069** at start 227. Closing one hole is worth +42 over the record, not\n   +1. The route's own \"R = 2028 (start 197)\" is the smallest deficit, not the widest.\n2. The bar 2454.55 is crossed **exactly at k = 9** (2489 ≥ 2455) and not at k = 8 (2435 < 2455).\n   That confirms #1105's \"nine holes, not three\" with the precise window: the 9 holes to close\n   are those inside [17, 2506) — `196, 226, 2254, 2296, 2302, 2326, 2374, 2386, 2452` — and\n   closing them yields 2489, i.e. 34 above the bar, which is more than the route's own\n   requirement for moving the base-10 floor to ln(G2/900) with G2 ≥ 2455. (No value of G2 is\n   asserted here beyond the route's stated threshold.)\n3. The cost of the bar is now priced in holes *and* in the window that carries them. Everything\n   below is run at the smallest deficit and, for calibration, on the published ladder.\n\n## 3. The pre-registered question: exhaustion at K ≤ 4\n\nWindow [227, 2255) (R = 2028), the single hole at absolute offset **2254**:\n\n| K | nodes (impl. A) | nodes (impl. B) | verdict |\n|---|---|---|---|\n| 1 | 50 | 50 | exhausted — all 49 covering moves fail |\n| 2 | 2 354 | 1 989 | exhausted |\n| 3 | 106 130 | 75 200 | exhausted |\n| 4 | — | **2 705 010** (99.7 s) | **exhausted** |\n\n**No reassignment of at most four primes covers this window.** At K = 5 the tree is ~10⁸ nodes\nat the measured 27 000 nodes/s — about one hour with this instrument — and was not run; that is\nthe priced gap, not a claim.\n\nThe same run at R = 2069 / start 227 (the *wider* single-hole window) and at the 2-hole window\nR = 2237 / start 17 was not completed, so nothing is claimed there.\n\n**Why the residual is stiff, measured.** Out of 1 035 single-prime moves away from the recorded\nstate, 49 cover the hole 2254 and the least damaging of them leaves **42** new holes in the\nwindow (median 98). The 986 moves that do *not* cover the hole leave at least 22 holes. So the\nfirst covering move triples the hole count: a repair must be a chain, and the chain must be at\nleast five primes long.\n\n**Randomised repair.** A bitmask min-conflicts/tabu search (reassignment chains allowed,\n2.05 M steps, 300 s) starting from the recorded state **never went below 1 hole** on the 1-hole\nwindows — consistent with the exhaustive negatives above — and reduced the 9-hole bar window\n[17, 2506) from 9 to **6** holes without closing it. A beam search on the same complete tree\n(width 4 000, depth 14) was *worse* than the DFS at depth 1 (best 42 holes) because the total\nhole count is the wrong objective for a chain that must temporarily grow: it is reported as a\nmeasured negative for that objective, not as an upper bound.\n\n## 4. Calibration of the instrument on the published ladder (n = 13…22)\n\nThe comparability the brief asks for. For each published level the instrument starts from the\n**producer's own recorded best state** and targets `ceiling_R` = published term + 1 at the\nminimum-hole window — the same deficit shape as the n = 25 experiment.\n\n| n | published a(n) | target | holes at target | K = 4 nodes (exhausted) | closed? |\n|---|---|---|---|---|---|\n| 13 | 545 | 546 | 1 | 106 107 | no |\n| 14 | 617 | 618 | 1 | 152 425 | no |\n| 15 | 707 | 708 | 1 | 205 800 | no |\n| 16 | 869 | 870 | 1 | 284 775 | no |\n| 17 | 965 | 966 | 1 | 427 978 | no |\n| 18 | 1079 | 1080 | 2 | 521 280 | no |\n| 19 | 1283 | 1284 | 5 | 726 727 | no |\n| 20 | 1397 | 1398 | 5 | 945 568 | no |\n| 21 | 1529 | 1530 | 3 | 1 237 157 | no |\n| 22 | 1709 | 1710 | 5 | 1 517 760 | no |\n\n**10/10 levels, nothing closes within four reassignments**, every K = 4 tree exhausted (total\n3 min 5 s). This is the measurement that gives the n = 25 negative a scale: the \"+1 step\" is a\ndeep chain *uniformly along the ladder*, at n where the producer's local maximiser already\nrecovers 72–99 % of the published optimum. It also means the instrument cannot be blamed for\nfailing only at n = 25.\n\n## 5. Verdict against the pre-registered criteria\n\n* **Success** (a verified covered run ≥ 2028 at n = 25): **NOT achieved.** No new witness was\n  produced, so there is no new claim to hand to `verify-2043.py`, and nothing is reported as\n  verified. The recorded bound a(25) ≥ 2027 from #1098 stands unchanged, and the previously\n  reported values a(24) ≥ 1728, a(23) ≥ 1439, a(26) ≥ 1931, a(27) ≥ 2017, a(28) ≥ 2300 stand.\n* **Failure criterion** (\"no move set closes the single hole at R = 2028 → the mechanism is\n  closed with evidence at the smallest possible deficit\"): **met, in strengthened form.** The\n  route wrote *within the node cap*; what was obtained is **exhaustion**, i.e. a complete\n  negative at depth ≤ 4, reproduced by two implementations and by an unrestricted enumeration\n  for depth ≤ 2 — plus the same negative on all ten published levels.\n* **What is NOT closed:** depth 5 and beyond (price: ~10⁸ nodes ≈ 1 h for the 1-hole window, more\n  for the bar), the 2-hole window R = 2237, and the bar window [17, 2506). The route is not\n  refuted and no maximality is claimed anywhere: a(25) ≤ 2453 stays open as before.\n* **What stands:** the published terms, the identity G2(p_n#) = A144311(n) + 1, both bars, and\n  the derived lower bounds. A method that cannot close one hole cannot close nine, so the\n  mechanism (exact shallow repair on a plateau state) is closed *as a route to the bar*; the\n  route's ingredient list is what fails, not the ladder.\n\n## 6. What would change the answer (the distinct next experiment)\n\nThe measured gap is narrow and named: **K = 5 exhaustion on window [227, 2296)** (R = 2069, one\nhole, the widest single-hole target ⇒ +42 on the record). It needs either ~1 h at 27 000\nnodes/s, or a factor-~20 speed-up of the node rate — the obvious candidates being an\norder-heuristic change (the tree is hook-order dependent through the *hole-choice* rule, which\nis the one thing the DFS fixes) and a per-node cache of candidate lists. If K = 5 also exhausts,\nthe shallow-repair mechanism is closed at the widest single-hole target and the next decisive\nobject is the 2-hole window 2237, not the bar.\n\nTwo honesty notes. (1) The producer defect reported in #1105 — per-trial residue tuples are not\nstored — was **not** fixed here and still blocks any per-trial re-analysis of #1098. (2) The\ninstrument is exact only about *reassignments of the recorded state*; it says nothing about\nstates reachable by more descent, and a covered run > 2027 may well exist elsewhere on the wheel\nof the primes ≤ 97. Everything above is a statement about this state.\n","patch":null,"cpu_hours":0.35,"hashes":{"calib90.py":"b43b4d73ee1f18914414574893b59c07957cab6f9152ce35a87c334b4d637c05","repair90.py":"1f40ab6bbc63fca0a7cb81a5188e3b6c49364b275ed87cdfe7670b71cff0a635","repair90b.py":"0db78f6baf415645681ec51b256bebd29b986c165884fa0936763ea5f37fcd73","report-repair90.md":"255c7e07ccbb4aec50e5b4d481ad9bea8cf2c63e9a69d83881849b473d12f059","check-2043.out.json":"0d77773d01631d9eb70b76b18588c13b1d76b2bca5a0e4ff22b52c5887630600","repair90b-beam-R2028.json":"1975dc57ff0d775de8d204eb04962e932d529ac4008efd4a6fa74127bf6b47b7","repair90-starts-r2028.json":"b27bc6953252302db22133a481f8405c0992a483ea42802ccc2e5c8d3dbcd2f1","repair90b-mc-R2489-s3.json":"25ab0e23036e408023f4eb70e14514736e7bb57f15918da07030a674d9451071","calib90-published-ladder.json":"a2510a4e83864ca98f8c6087afbe50d01790edfea8c3fc54f37da4c46434fd36","repair90-depth-r2028-s227.json":"a7a6eb321c0859f2d6a06ef2432e03a09c2fc5ec2e085ca14b5a0a973031084c","repair90b-solve-R2028-s227-K4.json":"d2903f37363a11e8f3628df5af9d22630d64bfba4e6980213df0eb06c6da78aa","transcript-repair90.scrubbed.jsonl":"4cef9168cfb4bfa7c356d3aab30bca16d0f3fd12ca91641a61e684449f3c3647","0d77773d01631d9eb70b76b18588c13b1d76b2bca5a0e4ff22b52c5887630600":"check-2043.out.json","0db78f6baf415645681ec51b256bebd29b986c165884fa0936763ea5f37fcd73":"repair90b.py","1975dc57ff0d775de8d204eb04962e932d529ac4008efd4a6fa74127bf6b47b7":"repair90b-beam-R2028.json","1f40ab6bbc63fca0a7cb81a5188e3b6c49364b275ed87cdfe7670b71cff0a635":"repair90.py","255c7e07ccbb4aec50e5b4d481ad9bea8cf2c63e9a69d83881849b473d12f059":"report-repair90.md","25ab0e23036e408023f4eb70e14514736e7bb57f15918da07030a674d9451071":"repair90b-mc-R2489-s3.json","4cef9168cfb4bfa7c356d3aab30bca16d0f3fd12ca91641a61e684449f3c3647":"transcript-repair90.scrubbed.jsonl","a2510a4e83864ca98f8c6087afbe50d01790edfea8c3fc54f37da4c46434fd36":"calib90-published-ladder.json","a7a6eb321c0859f2d6a06ef2432e03a09c2fc5ec2e085ca14b5a0a973031084c":"repair90-depth-r2028-s227.json","b27bc6953252302db22133a481f8405c0992a483ea42802ccc2e5c8d3dbcd2f1":"repair90-starts-r2028.json","b43b4d73ee1f18914414574893b59c07957cab6f9152ce35a87c334b4d637c05":"calib90.py","d2903f37363a11e8f3628df5af9d22630d64bfba4e6980213df0eb06c6da78aa":"repair90b-solve-R2028-s227-K4.json"},"author_rung":"measured","status":"recorded","final_rung":"recorded","created_at":"2026-09-19T00:34:06.908Z","repo_url":null,"commit":null,"cites":{"files":["research-routes/90","research/QUESTIONS.md"],"handles":[],"returns":[1098,1105],"messages":[]},"tokens":{"log":"custom","input":241706,"models":{"deepseek-v4-flash":93069},"output":93069,"source":"custom-jsonl","entries":1,"cache_read":11352920,"cache_write":0,"observed_models":["deepseek-v4-flash"]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":null,"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-19T00:41:57.130Z","file_notes":null,"research":{"outcome":"progress","route_id":90,"next_step":{"method":"Input: the served n = 25 residue tuple (sha 0d77773d...), unmodified. Run the depth-limited exact DFS of work/repair90b.py at R = 2069, start 227 (one hole, 2254) with K = 5 and a node cap of 2e8: a run that ends without touching the cap is a COMPLETE negative at depth 5, a run that finds a state is a witness to hand to verify-2043.py unmodified. Either way record the node count and the wall time, so the per-depth cost curve keeps accumulating. Spend the remaining budget on the node rate first (hook-order rule and a candidate-list cache; the measured rate is 27000 nodes/s and the tree is bigger than 2e8 nodes if K = 5 does not exhaust). Only if K = 5 exhausts, move to the 2-hole window R = 2237, start 17, since the bar's 9-hole window [17, 2506) is out of reach of this instrument as measured.","compute":{"ram_gb":2,"disk_gb":1,"cpu_hours":0},"failure":"K = 5 exhausts with no cover on [227, 2296) AND on [227, 2255): the residual of a local maximiser on the wheel of the primes <= 97 is then closed to shallow reassignment at both single-hole targets, and any constructive improvement must come from more descent or from a different instrument, not from repairing this state.","success":"A verified covered run >= 2069 at n = 25 (a(25) >= 2069, +42 on the recorded 2027), or a COMPLETE negative at depth 5 on the widest single-hole window, which closes the shallow-repair mechanism at the best target rather than the smallest one.","question":"At n = 25, can an exact solve close the SINGLE hole 2254 of the recorded state on the WIDEST single-hole window [227, 2296) (R = 2069, +42 on the record), when the same hole is provably not closable by any reassignment of <= 4 primes on the narrower window [227, 2255)?","budget_hours":2,"required_tools":[],"required_sources":[]},"depends_on":[1098,1105],"evidence_md":"EXACT RESIDUAL-HOLE REPAIR ON THE RECORDED n = 25 STATE (job #2074, route 90). Input: the served tuple check-2043.out.json, sha256 0d77773d01631d9eb70b76b1..., UNMODIFIED. Semantics are verify-2043.py's definition. Two INDEPENDENT implementations (incremental coverage counts; big-int bitmasks) search the same complete tree: reassign the residues of K primes, leave the rest, cover the window; chained moves allowed. A run that does not touch its cap is reported EXHAUSTED, which is a complete negative; a capped run is reported ABORTED and claims nothing.\n\n(1) THE PRE-REGISTERED FAILURE IS MET IN STRENGTHENED FORM. Window [227,2255) (R = 2028) has the single hole 2254. K=1 exhausted (50 nodes); K=2 exhausted (2354 / 1989 nodes by the two implementations); K=3 exhausted (106130 / 75200); K=4 EXHAUSTED at 2705010 nodes, 99.7 s. So NO reassignment of at most four primes covers that window -- exhaustion, not a node cap. Independent checks: an unrestricted enumeration over all subsets of <= 2 primes and ALL their residue values finds no witness (guarding the hole-covering branching restriction); the verdict and node counts are identical for five window starts (197, 200, 226, 227, 250, 268), so the negative does not depend on the boundary.\n\n(2) WHY THE RESIDUAL IS STIFF, MEASURED. Of 1035 single-prime moves off the recorded state, the 49 that cover the hole leave at least 42 new holes in the window (median 98); the 986 that do not leave at least 22. The first covering move more than triples the hole count, so any repair is a chain of length >= 5.\n\n(3) THE DECLARED TARGET WAS NOT THE BEST ONE. The recorded holes begin 16, 196, 226, 2254, 2296, 2302, 2326, 2374, 2386, 2452, 2506, 2512, ... (131 in [0,8000)). The longest window with <= k holes, computed twice (sliding window and the gap formula): k=0 2027 [227,2254); k=1 2069 [227,2296); k=2 2237 [17,2254); k=3 2279; k=4 2296; k=5 2309; k=6 2357; k=7 2374; k=8 2435; k=9 2489 [17,2506). Consequences: the one hole 2254 is worth +42 (2069), not +1; and the bar 27000/11 = 2454.55 is crossed exactly at k = 9 and NOT at k = 8 (2435), the nine holes being 196, 226, 2254, 2296, 2302, 2326, 2374, 2386, 2452. #1105's 'nine holes, not three' is confirmed and given its precise window.\n\n(4) CALIBRATION ON THE PUBLISHED LADDER, the comparability the brief asks for. Starting from the producer's own recorded best state at each published level n = 13..22, target = published + 1 at the minimum-hole window, the same instrument closes NOTHING at depth <= 4: 10/10 levels, every K=4 tree exhausted (106107 nodes at n=13 rising to 1517760 at n=22), 3 min 5 s total. So the '+1 step' is a deep chain uniformly along the ladder, at levels where the producer's maximiser already recovers 72-99% of the optimum, and the n = 25 negative cannot be blamed on the level.\n\n(5) RANDOMISED REPAIR, also negative. A bitmask min-conflicts/tabu search (chains allowed, 2.05M steps, 300 s) never left the single hole on the 1-hole windows, and reduced the 9-hole bar window [17,2506) from 9 to 6 holes without closing it. A beam search on the same tree (width 4000, depth 14) is worse than the DFS at depth 1 (best 42 holes): the total hole count is the wrong objective for a chain that must temporarily grow.\n\n(6) SCOPE AND WHAT CHANGES. No cover beyond 2027 is claimed, a(25) <= 2453 stays open, and the published terms, the identity G2(p_n#) = A144311(n) + 1, both bars and the derived lower bounds all stand. The measured gap is named: K = 5 on the WIDEST single-hole window [227,2296) (2069, +42 on the record), priced at ~1e8 nodes ~ 1 h at the measured 27000 nodes/s, or ~20x faster with a hook-order/candidate-cache change; and, separately, the 2-hole window 2237 which was not run. The #1105 producer defect (no per-trial residue tuples) is unfixed.\n\nRUNG: (1)-(6) MEASURED by this run's scripts, all attached; (1) is a COMPLETE negative at depth <= 4 for that window, not a measurement of a search. Evidence grade: measured.","prior_art_md":"UPDATED ONLINE SEARCH RECORD (2026-09-19, this job).\n\n(1) ONE QUERY RUN THIS TURN, on the object this experiment could produce a witness for: a published CONSTRUCTIVE covered run for the two-class A144311 ladder at n >= 23. Query: A144311 / Jacobsthal run of consecutive integers = +-1 mod the first n primes / n = 25 / constructive witness / 2026. Nothing new surfaced: the hits are the 2016 Math StackExchange thread on computing A144311, the 2019 MathOverflow thread on strings of consecutive integers divisible by 1..N, Hagedorn's one-class computations (h(n) for n < 50; the Jul 2026 ResearchGate record of that line is the one-class A048670 object, not the two-class one), and unrelated Jacobsthal-number pages. No source publishing a two-class covered-run witness at any n >= 23 was located this turn.\n\n(2) CARRIED FORWARD, NOT RE-READ: #1105's search of the same day is the current state of the record on the one source that could plausibly bear on it -- Nguyen, 'Finite-Window Noncovering on Primorial Wheels', preprints.org 202608.1299 (DOI 10.20944/preprints202608.1299.v1, posted 2026-08-19), whose abstract is reachable through Crossref/OpenAlex while the publisher answers 403 to this client on every endpoint. Its object is a PAIR of symmetric offsets {C-d, C+d} around a primorial centre, with instances |U(86)| >= 3 and |U(128)| >= 2 -- not a run of consecutive integers each +-1 mod p, and not a ladder index. Neither ladder has a published term at n >= 23: OEIS A144311 (22 terms, a(22) = 1709, %I #23 Dec 05 2024) and OEIS A288815 (21 terms, largest 2622, %I #19 Apr 12 2026). UNCHANGED.\n\nEXACT REMAINING GAP, and this job does not close it: no located source states a constructive cover at n >= 23, and this job produced NO new witness either -- so the gap 'no constructive witness at n >= 23 is stated anywhere, in the literature or on this project's record' stands on both sides. What this job adds is not novelty but cost: the shallow-repair mechanism on the recorded state is exhaustively closed at depth <= 4, and the bar is priced (9 holes at window [17,2506) -> 2489; the widest single-hole window is 2069, not 2028).\n\nNO NOVELTY CLAIM is made beyond the query run and the sources listed as inspected."},"research_route_id":90,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_bd08e49ed9621cfd852f9b04","run_id":"run_dbafcb3afddae906ed1c3d4e","triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"handle":"maxime-fleury","job_brief":"First update the online prior-work search for this experiment. If existing work covers it, record that and stop; otherwise run this bounded sprint on the uncovered uncertainty. Use cited published numbers during pursuit; their reproduction belongs in later validation. Build on the supplied findings; do not reconstruct earlier research. Return concrete progress and its cheapest credible check, a useful result for review, or a precisely scoped obstacle. Continued investment requires a distinct experiment.\n\nRead GET <project base>/research-routes/90 and return #1105. Return the ordinary report and transcript plus research: {route_id: 90, 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":"1098","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"1105","status":"recorded","final_rung":"recorded","canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/90","transcript_url":"/projects/twin-primes/return/1121/transcript","files":[{"sha256":"255c7e07ccbb4aec50e5b4d481ad9bea8cf2c63e9a69d83881849b473d12f059","name":"report-repair90.md","bytes":11235},{"sha256":"4cef9168cfb4bfa7c356d3aab30bca16d0f3fd12ca91641a61e684449f3c3647","name":"transcript-repair90.scrubbed.jsonl","bytes":6336},{"sha256":"d2903f37363a11e8f3628df5af9d22630d64bfba4e6980213df0eb06c6da78aa","name":"repair90b-solve-R2028-s227-K4.json","bytes":707},{"sha256":"a7a6eb321c0859f2d6a06ef2432e03a09c2fc5ec2e085ca14b5a0a973031084c","name":"repair90-depth-r2028-s227.json","bytes":649},{"sha256":"b27bc6953252302db22133a481f8405c0992a483ea42802ccc2e5c8d3dbcd2f1","name":"repair90-starts-r2028.json","bytes":3218},{"sha256":"a2510a4e83864ca98f8c6087afbe50d01790edfea8c3fc54f37da4c46434fd36","name":"calib90-published-ladder.json","bytes":2060},{"sha256":"25ab0e23036e408023f4eb70e14514736e7bb57f15918da07030a674d9451071","name":"repair90b-mc-R2489-s3.json","bytes":834},{"sha256":"1975dc57ff0d775de8d204eb04962e932d529ac4008efd4a6fa74127bf6b47b7","name":"repair90b-beam-R2028.json","bytes":1856},{"sha256":"1f40ab6bbc63fca0a7cb81a5188e3b6c49364b275ed87cdfe7670b71cff0a635","name":"repair90.py","bytes":20793},{"sha256":"0db78f6baf415645681ec51b256bebd29b986c165884fa0936763ea5f37fcd73","name":"repair90b.py","bytes":15389},{"sha256":"b43b4d73ee1f18914414574893b59c07957cab6f9152ce35a87c334b4d637c05","name":"calib90.py","bytes":3391},{"sha256":"0d77773d01631d9eb70b76b18588c13b1d76b2bca5a0e4ff22b52c5887630600","name":"check-2043.out.json","bytes":34230}],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}