-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathproof.html
More file actions
952 lines (885 loc) · 84.8 KB
/
Copy pathproof.html
File metadata and controls
952 lines (885 loc) · 84.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>CORETEXA — Proof · verification benchmark</title>
<meta name="description" content="A living log of Coretexa run against real open-source bugs. Every fix is checked by two independent verifiers before it ships — one that reproduces the bug, one whose only job is to refute the fix. 12 fix runs, 11 verifier catches, 5 agent-authored pull requests refuted, 0 self-closes — and one refutation the maintainer merged past is now fixed upstream.">
<link rel="canonical" href="https://coretexa.dev/proof.html">
<meta property="og:site_name" content="Coretexa">
<meta property="og:type" content="website">
<meta property="og:url" content="https://coretexa.dev/proof.html">
<meta property="og:title" content="Coretexa proof log — 12 fix runs, 11 verifier catches">
<meta property="og:description" content="A living log of Coretexa run against real open-source bugs. Every fix is checked by two independent verifiers before it ships — one that reproduces the bug, one whose only job is to refute the fix. 12 fix runs, 11 verifier catches, 5 agent-authored pull requests refuted, 0 self-closes — and one refutation the maintainer merged past is now fixed upstream.">
<meta property="og:image" content="https://coretexa.dev/og.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Coretexa — the agent that does the work can’t close it.">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@fezystockmarke1">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@400;500;600;700&family=IBM+Plex+Mono:wght@400;500;600&display=swap" rel="stylesheet">
<style>
:root{
--ground:#071a30;
--ground-2:#0b2545;
--paper:#0a2138;
--line:#18456e;
--line-2:#1f5688;
--hair:rgba(120,180,230,.16);
--cyan:#22d3ee;
--cyan-dim:#0e7f96;
--amber:#f5b642;
--white:#eaf4fb;
--ink:#a8c6de;
--ink-dim:#6c93b4;
--ok:#3ddc97;
--bad:#ff5d73;
--mono:'IBM Plex Mono',ui-monospace,monospace;
--sans:'Space Grotesk',system-ui,sans-serif;
--maxw:1180px;
}
*{box-sizing:border-box;margin:0;padding:0}
html{scroll-behavior:smooth}
body{
font-family:var(--sans);
background:var(--ground);
color:var(--ink);
line-height:1.55;
-webkit-font-smoothing:antialiased;
overflow-x:hidden;
position:relative;
}
/* graph-paper background */
body::before{
content:"";
position:fixed;inset:0;z-index:-2;
background:
linear-gradient(var(--hair) 1px,transparent 1px) 0 0/26px 26px,
linear-gradient(90deg,var(--hair) 1px,transparent 1px) 0 0/26px 26px,
linear-gradient(rgba(120,180,230,.05) 1px,transparent 1px) 0 0/130px 130px,
linear-gradient(90deg,rgba(120,180,230,.05) 1px,transparent 1px) 0 0/130px 130px,
radial-gradient(ellipse at 50% -10%,#0d2c4d 0%,var(--ground) 60%);
pointer-events:none;
}
body::after{
content:"";
position:fixed;inset:0;z-index:-1;
background:radial-gradient(ellipse at 50% 40%,transparent 55%,rgba(3,10,20,.55) 100%);
pointer-events:none;
}
a{color:inherit;text-decoration:none}
::selection{background:var(--cyan);color:var(--ground)}
.wrap{max-width:var(--maxw);margin:0 auto;padding:0 28px}
.mono{font-family:var(--mono)}
.label{font-family:var(--mono);font-size:11px;letter-spacing:.18em;text-transform:uppercase;color:var(--cyan-dim)}
/* ---- dimension-line section headers ---- */
.sec-tag{
display:inline-flex;align-items:center;gap:10px;
font-family:var(--mono);font-size:11px;letter-spacing:.22em;text-transform:uppercase;
color:var(--cyan);margin-bottom:20px;
}
.sec-tag::before{content:"";width:34px;height:1px;background:var(--cyan);opacity:.6}
.sec-tag .num{color:var(--amber)}
h1,h2,h3{font-weight:600;color:var(--white);line-height:1.08;letter-spacing:-.01em}
section{padding:96px 0;position:relative}
.divider{max-width:var(--maxw);margin:0 auto;height:1px;background:linear-gradient(90deg,transparent,var(--line),transparent)}
/* =========== NAV =========== */
nav{
position:sticky;top:0;z-index:50;
backdrop-filter:blur(10px);
background:rgba(7,26,48,.72);
border-bottom:1px solid var(--hair);
}
.nav-in{max-width:var(--maxw);margin:0 auto;padding:14px 28px;display:flex;align-items:center;gap:24px}
.brand{display:flex;align-items:center;gap:12px;font-weight:700;letter-spacing:.14em;color:var(--white);font-size:15px}
.brand .glyph{width:22px;height:22px;flex:none}
.nav-links{display:flex;gap:26px;margin-left:auto;font-family:var(--mono);font-size:13px}
.nav-links a{color:var(--ink);transition:color .18s;position:relative}
.nav-links a:hover{color:var(--cyan)}
.nav-links a::after{content:"";position:absolute;left:0;bottom:-5px;width:0;height:1px;background:var(--cyan);transition:width .2s}
.nav-links a:hover::after{width:100%}
.tag-mit{font-family:var(--mono);font-size:11px;color:var(--ink-dim);border:1px solid var(--hair);padding:3px 8px;border-radius:3px;letter-spacing:.08em}
.btn{
font-family:var(--mono);font-size:13px;font-weight:500;
display:inline-flex;align-items:center;gap:8px;
padding:9px 16px;border-radius:5px;cursor:pointer;transition:.18s;white-space:nowrap;
}
.btn-primary{background:var(--cyan);color:#04121f;border:1px solid var(--cyan);font-weight:600}
.btn-primary:hover{background:#5fe4f6;box-shadow:0 0 20px rgba(34,211,238,.35)}
.btn-ghost{background:transparent;color:var(--white);border:1px solid var(--line-2)}
.btn-ghost:hover{border-color:var(--cyan);color:var(--cyan)}
.nav-toggle{display:none;margin-left:auto;background:none;border:1px solid var(--line-2);color:var(--white);border-radius:5px;padding:7px 10px;cursor:pointer}
/* =========== HERO =========== */
.hero{padding:88px 0 72px;position:relative}
.hero-grid{display:grid;grid-template-columns:1.05fr .95fr;gap:56px;align-items:center}
.hero .kicker{margin-bottom:22px}
.hero h1{font-size:clamp(36px,5vw,60px);letter-spacing:-.02em;margin-bottom:22px}
.hero h1 .hl{color:var(--cyan)}
.hero p.sub{font-size:18px;max-width:560px;margin-bottom:18px;color:var(--ink)}
.hero .worksline{font-family:var(--mono);font-size:12.5px;color:var(--ink-dim);margin-bottom:30px}
.hero .worksline .ok{color:var(--ok)}
.hero-cta{display:flex;gap:14px;flex-wrap:wrap}
.btn-lg{padding:13px 22px;font-size:14px}
/* mini schematic in hero */
.hero-card{
border:1px solid var(--line);border-radius:10px;
background:linear-gradient(160deg,rgba(11,37,69,.75),rgba(7,26,48,.55));
padding:22px;position:relative;overflow:hidden;
}
.hero-card::before{content:"SPEC-01 / NO-SELF-CLOSE";position:absolute;top:12px;right:14px;font-family:var(--mono);font-size:9.5px;letter-spacing:.16em;color:var(--cyan-dim)}
.corner{position:absolute;width:12px;height:12px;border:1px solid var(--cyan);opacity:.5}
.corner.tl{top:8px;left:8px;border-right:0;border-bottom:0}
.corner.tr{top:8px;right:8px;border-left:0;border-bottom:0}
.corner.bl{bottom:8px;left:8px;border-right:0;border-top:0}
.corner.br{bottom:8px;right:8px;border-left:0;border-top:0}
/* =========== PROBLEM =========== */
.problem-grid{display:grid;grid-template-columns:repeat(3,1fr);gap:22px;margin-top:14px}
.pcard{
border:1px solid var(--hair);border-radius:9px;padding:26px 24px;
background:rgba(10,33,56,.4);position:relative;transition:.2s;
}
.pcard:hover{border-color:var(--line-2);transform:translateY(-3px)}
.pcard .idx{font-family:var(--mono);font-size:12px;color:var(--amber);margin-bottom:16px;display:block}
.pcard h3{font-size:18px;margin-bottom:10px}
.pcard p{font-size:14.5px;color:var(--ink-dim)}
.problem-lead{font-size:22px;color:var(--white);max-width:760px;margin-bottom:10px;font-weight:500;line-height:1.35}
.problem-lead .q{color:var(--cyan)}
/* =========== HOW IT WORKS / PIPELINE =========== */
.diagram-shell{
border:1px solid var(--line);border-radius:12px;
background:linear-gradient(180deg,rgba(9,30,52,.6),rgba(7,22,40,.35));
padding:26px 22px 20px;margin-top:8px;position:relative;
}
.diagram-head{display:flex;justify-content:space-between;align-items:baseline;margin-bottom:8px;flex-wrap:wrap;gap:8px}
.diagram-head .t{font-family:var(--mono);font-size:11px;letter-spacing:.16em;color:var(--cyan-dim)}
.svg-scroll{width:100%;overflow:hidden}
svg.pipeline{display:block;width:100%;height:auto}
.pipe-mobile{display:none}
.pipe-mobile svg{max-width:360px;margin:6px auto 0;display:block}
.legend{display:flex;gap:22px;flex-wrap:wrap;margin-top:16px;font-family:var(--mono);font-size:11.5px;color:var(--ink-dim)}
.legend span{display:inline-flex;align-items:center;gap:7px}
.legend i{width:10px;height:10px;border-radius:2px;display:inline-block}
/* =========== FIVE GATES =========== */
.gates{display:grid;grid-template-columns:repeat(5,1fr);gap:16px;margin-top:14px;counter-reset:g}
.gate{
border:1px solid var(--hair);border-top:2px solid var(--cyan);
border-radius:8px;padding:22px 18px;background:rgba(10,33,56,.35);
position:relative;transition:.2s;
}
.gate:hover{background:rgba(14,42,70,.6);transform:translateY(-3px)}
.gate .gn{font-family:var(--mono);font-size:12px;color:var(--cyan);margin-bottom:14px;display:block}
.gate h4{font-size:15px;color:var(--white);font-weight:600;line-height:1.3;margin-bottom:6px}
.gate p{font-size:13px;color:var(--ink-dim)}
.gate.g5{border-top-color:var(--amber)}
.gate.g5 .gn{color:var(--amber)}
/* =========== NO SELF CLOSE =========== */
.nsc-grid{display:grid;grid-template-columns:1fr 1.15fr;gap:44px;align-items:center}
.nsc h2{font-size:clamp(28px,3.4vw,40px);margin-bottom:20px}
.nsc h2 .no{color:var(--bad)}
.nsc p{font-size:16px;color:var(--ink);margin-bottom:16px;max-width:460px}
.nsc .enforced{font-family:var(--mono);font-size:13px;color:var(--white);border-left:2px solid var(--amber);padding-left:14px}
.term{
border:1px solid var(--line);border-radius:10px;overflow:hidden;
background:#04121f;font-family:var(--mono);font-size:13px;box-shadow:0 24px 60px -30px rgba(0,0,0,.8);
}
.term-bar{display:flex;align-items:center;gap:7px;padding:11px 15px;background:#081f36;border-bottom:1px solid var(--line)}
.term-bar i{width:11px;height:11px;border-radius:50%;display:inline-block}
.term-bar .t{margin-left:10px;font-size:11px;color:var(--ink-dim);letter-spacing:.05em}
.term-body{padding:18px 18px 20px;line-height:1.85;overflow-x:auto}
.term-body .l{white-space:pre;display:block}
.c-prompt{color:var(--cyan)}
.c-cmd{color:var(--white)}
.c-flag{color:var(--amber)}
.c-str{color:var(--ok)}
.c-com{color:var(--ink-dim)}
.c-key{color:#8ab4ff}
.c-bad{color:var(--bad);font-weight:600}
.c-ok{color:var(--ok);font-weight:600}
.c-dim{color:var(--ink-dim)}
/* =========== BEYOND TICKETS =========== */
.beyond-grid{display:grid;grid-template-columns:1fr 1fr;gap:26px;margin-top:14px}
.bcard{border:1px solid var(--hair);border-radius:11px;padding:30px 28px;background:rgba(10,33,56,.4);position:relative;overflow:hidden}
.bcard h3{font-size:20px;margin-bottom:12px;display:flex;align-items:center;gap:10px}
.bcard h3 .badge{font-family:var(--mono);font-size:10px;letter-spacing:.1em;color:var(--amber);border:1px solid var(--amber);border-radius:3px;padding:2px 7px}
.bcard p{font-size:14.5px;color:var(--ink-dim);margin-bottom:20px}
.tree-wrap{width:100%;overflow-x:auto}
svg.tree{display:block;width:100%;height:auto;min-width:300px}
.tree-note{font-family:var(--mono);font-size:11px;color:var(--ink-dim);margin-top:12px;line-height:1.6}
.tree-note b{color:var(--amber)}
/* =========== PROOF =========== */
.proof{text-align:center}
.stats{display:grid;grid-template-columns:repeat(3,1fr);gap:0;margin:34px auto 0;max-width:820px;border:1px solid var(--line);border-radius:12px;overflow:hidden}
.stat{padding:38px 20px;position:relative;background:rgba(9,30,52,.4)}
.stat + .stat{border-left:1px solid var(--line)}
.stat .num{font-family:var(--mono);font-size:clamp(40px,6vw,58px);font-weight:600;color:var(--cyan);line-height:1;letter-spacing:-.02em}
.stat.amber .num{color:var(--amber)}
.stat .cap{font-family:var(--mono);font-size:12px;color:var(--ink-dim);margin-top:12px;letter-spacing:.04em}
.stat .dim-line{position:absolute;top:20px;left:16px;right:16px;height:1px;border-top:1px dashed var(--hair)}
.proof-quote{font-size:19px;color:var(--white);max-width:680px;margin:0 auto 6px;font-weight:500;line-height:1.4}
.proof-sub{font-family:var(--mono);font-size:13px;color:var(--ink-dim);max-width:620px;margin:14px auto 0}
/* =========== QUICK START =========== */
.qs-grid{display:grid;grid-template-columns:.85fr 1.15fr;gap:40px;align-items:start}
.steps{list-style:none;counter-reset:s}
.steps li{position:relative;padding:0 0 26px 46px;border-left:1px dashed var(--line);margin-left:16px}
.steps li:last-child{border-left-color:transparent;padding-bottom:0}
.steps li::before{
counter-increment:s;content:counter(s,decimal-leading-zero);
position:absolute;left:-16px;top:-4px;width:32px;height:32px;border-radius:50%;
background:var(--ground);border:1px solid var(--cyan);color:var(--cyan);
font-family:var(--mono);font-size:12px;display:flex;align-items:center;justify-content:center;
}
.steps li h4{font-size:16px;color:var(--white);margin-bottom:5px;font-weight:600}
.steps li p{font-size:14px;color:var(--ink-dim)}
.steps li code{font-family:var(--mono);font-size:12.5px;color:var(--amber);background:rgba(245,182,66,.08);padding:1px 5px;border-radius:3px}
/* =========== FINAL CTA =========== */
.final{text-align:center;padding:100px 0}
.final h2{font-size:clamp(30px,4vw,46px);margin-bottom:20px}
.final p{font-size:17px;color:var(--ink);max-width:560px;margin:0 auto 30px}
.final-cta{display:flex;gap:14px;justify-content:center;flex-wrap:wrap}
.honest{font-family:var(--mono);font-size:12.5px;color:var(--ink-dim);margin-top:26px}
/* =========== FOOTER =========== */
footer{border-top:1px solid var(--hair);padding:34px 0;font-family:var(--mono);font-size:12.5px;color:var(--ink-dim)}
.foot-in{max-width:var(--maxw);margin:0 auto;padding:0 28px;display:flex;flex-wrap:wrap;gap:16px;align-items:center;justify-content:space-between}
.foot-in .dot{color:var(--line-2)}
footer a:hover{color:var(--cyan)}
/* reveal */
.reveal{opacity:0;transform:translateY(22px);transition:opacity .7s cubic-bezier(.2,.7,.2,1),transform .7s cubic-bezier(.2,.7,.2,1)}
.reveal.in{opacity:1;transform:none}
/* SVG animation classes */
.flow-path{stroke-dasharray:6 5;animation:march 1.1s linear infinite}
@keyframes march{to{stroke-dashoffset:-22}}
.node-pulse{animation:nodeGlow 2.6s ease-in-out infinite}
@keyframes nodeGlow{0%,100%{opacity:.55}50%{opacity:1}}
.reject-x{animation:rejBlink 2.2s steps(1) infinite}
@keyframes rejBlink{0%,60%{opacity:1}80%,100%{opacity:.25}}
@media (prefers-reduced-motion:reduce){
html{scroll-behavior:auto}
.flow-path{animation:none;stroke-dashoffset:0}
.node-pulse{animation:none;opacity:1}
.reject-x{animation:none;opacity:1}
#token{display:none}
.reveal{opacity:1;transform:none;transition:none}
}
/* ============ RESPONSIVE ============ */
@media(max-width:960px){
.hero-grid{grid-template-columns:1fr;gap:36px}
.nsc-grid{grid-template-columns:1fr;gap:30px}
.qs-grid{grid-template-columns:1fr;gap:30px}
.beyond-grid{grid-template-columns:1fr}
.problem-grid{grid-template-columns:1fr}
.gates{grid-template-columns:repeat(2,1fr)}
}
@media(max-width:640px){
section{padding:64px 0}
.wrap{padding:0 18px}
.nav-links,.tag-mit,.btn-primary.desk{display:none}
.nav-toggle{display:inline-flex}
nav.open .nav-links{display:flex;position:absolute;top:57px;left:0;right:0;flex-direction:column;gap:0;background:var(--ground-2);border-bottom:1px solid var(--line);padding:8px 0}
nav.open .nav-links a{padding:13px 28px;border-top:1px solid var(--hair)}
nav.open .nav-links a::after{display:none}
.hero{padding:54px 0 40px}
.stats{grid-template-columns:1fr}
.stat + .stat{border-left:0;border-top:1px solid var(--line)}
.gates{grid-template-columns:1fr}
.hero-cta .btn,.final-cta .btn{flex:1;justify-content:center}
.foot-in{flex-direction:column;text-align:center;gap:10px}
.pipe-desktop{display:none}
.pipe-mobile{display:block}
}
</style>
<style>
/* ---- case-study / proof page ---- */
.proof-hero{padding:64px 0 40px}
.proof-hero h1{font-size:clamp(32px,4.4vw,52px);letter-spacing:-.02em;margin-bottom:20px}
.proof-hero h1 .hl{color:var(--cyan)}
.proof-hero .sub{font-size:18px;max-width:640px;color:var(--ink);margin-bottom:14px}
.updated{font-family:var(--mono);font-size:12px;color:var(--ink-dim)}
.updated .live{color:var(--ok)}
.score{display:grid;grid-template-columns:repeat(6,1fr);gap:14px;margin:34px 0 8px}
.score .cell{border:1px solid var(--line);border-radius:9px;background:linear-gradient(160deg,rgba(11,37,69,.6),rgba(7,26,48,.4));padding:16px 16px 14px;position:relative}
.score .cell .k{font-family:var(--mono);font-size:10px;letter-spacing:.16em;text-transform:uppercase;color:var(--cyan-dim);margin-bottom:9px}
.score .cell .v{font-size:30px;font-weight:600;color:var(--white);line-height:1;font-family:var(--mono)}
.score .cell .v small{font-size:14px;color:var(--ink-dim)}
.score .cell.hero-cell{border-color:var(--cyan);box-shadow:0 0 24px rgba(34,211,238,.14)}
.score .cell.hero-cell .v{color:var(--cyan)}
@media(max-width:900px){.score{grid-template-columns:repeat(2,1fr)}}
.callout{border:1px solid var(--amber);border-radius:11px;background:linear-gradient(160deg,rgba(63,45,10,.35),rgba(7,26,48,.5));padding:26px 28px;position:relative;margin-top:20px}
.callout::before{content:"FLAGSHIP CATCH";position:absolute;top:13px;right:16px;font-family:var(--mono);font-size:9.5px;letter-spacing:.16em;color:var(--amber)}
.callout h3{color:var(--amber);font-size:20px;margin-bottom:12px;padding-right:120px}
.callout p{color:var(--ink);font-size:15.5px;max-width:760px}
.callout p + p{margin-top:12px}
.callout code{font-family:var(--mono);font-size:13px;color:var(--white);background:rgba(120,180,230,.1);padding:2px 6px;border-radius:4px}
.log{display:flex;flex-direction:column;gap:22px;margin-top:8px}
.entry{border:1px solid var(--line);border-radius:11px;background:linear-gradient(160deg,rgba(11,37,69,.55),rgba(7,26,48,.4));padding:24px 26px;position:relative}
.entry .corner{position:absolute;width:11px;height:11px;border:1px solid var(--cyan);opacity:.4}
.entry .corner.tl{top:8px;left:8px;border-right:0;border-bottom:0}
.entry .corner.br{bottom:8px;right:8px;border-left:0;border-top:0}
.entry .top{display:flex;align-items:center;gap:12px;flex-wrap:wrap;margin-bottom:14px}
.entry .date{font-family:var(--mono);font-size:12px;color:var(--ink-dim)}
.entry .repo{font-family:var(--mono);font-size:14px;color:var(--white);font-weight:500}
.badge{font-family:var(--mono);font-size:10px;letter-spacing:.1em;text-transform:uppercase;padding:3px 8px;border-radius:4px;border:1px solid var(--hair)}
.badge.lang{color:var(--cyan);border-color:var(--cyan-dim)}
.badge.open{color:var(--amber);border-color:rgba(245,182,66,.4)}
.badge.caught{color:var(--ground);background:var(--ok);border-color:var(--ok);font-weight:600}
.entry h3{font-size:18px;color:var(--white);margin-bottom:12px;letter-spacing:-.01em}
.entry .catch{border-left:2px solid var(--ok);padding:2px 0 2px 16px;margin:14px 0;color:var(--ink)}
.entry .catch b{color:var(--ok)}
.entry .catch .em{color:var(--white)}
.entry p{color:var(--ink);font-size:15px}
.entry code{font-family:var(--mono);font-size:12.5px;color:var(--white);background:rgba(120,180,230,.1);padding:2px 6px;border-radius:4px}
.entry .links{display:flex;gap:16px;flex-wrap:wrap;margin-top:16px;font-family:var(--mono);font-size:12.5px}
.entry .links a{color:var(--cyan);border-bottom:1px solid transparent;transition:.15s}
.entry .links a:hover{border-bottom-color:var(--cyan)}
.method-grid{display:grid;grid-template-columns:1fr 1fr;gap:22px;margin-top:10px}
@media(max-width:820px){.method-grid{grid-template-columns:1fr}}
.mcard{border:1px solid var(--line);border-radius:10px;background:rgba(11,37,69,.4);padding:22px 24px}
.mcard h3{font-size:16px;color:var(--white);margin-bottom:12px}
.mcard ul{list-style:none;display:flex;flex-direction:column;gap:9px}
.mcard li{font-size:14.5px;color:var(--ink);padding-left:18px;position:relative}
.mcard li::before{content:"→";position:absolute;left:0;color:var(--cyan-dim);font-family:var(--mono)}
.mcard li b{color:var(--white)}
.next li::before{content:"◇";color:var(--amber)}
.honest{border:1px dashed var(--line-2);border-radius:9px;padding:16px 20px;margin-top:22px;color:var(--ink-dim);font-size:14px;font-family:var(--mono)}
.honest b{color:var(--ink)}
/* ---- nav fits between phone and desktop (added 2026-07-27) ---- */
@media(max-width:900px){ .tag-mit{display:none} }
@media(max-width:830px){
.btn-primary.desk{display:none}
.nav-links{gap:16px;font-size:12px}
}
@media(max-width:620px){
.nav-in{flex-wrap:wrap;row-gap:10px}
.nav-links{margin-left:0;width:100%;gap:14px;flex-wrap:wrap}
}
</style>
</head>
<body>
<nav id="nav">
<div class="nav-in">
<a href="/" class="brand">
<svg class="glyph" viewBox="0 0 24 24" fill="none" stroke="var(--cyan)" stroke-width="1.6">
<rect x="3" y="3" width="18" height="18" rx="2"/>
<path d="M7 12.5l3 3 7-7" stroke="var(--amber)" stroke-width="1.8"/>
</svg>
CORETEXA
</a>
<span class="tag-mit">MIT · open source</span>
<div class="nav-links">
<a href="/#how">How it works</a>
<a href="/#verdicts">Verdicts</a>
<a href="/#start">Quick start</a>
<a href="/proof.html" style="color:var(--cyan)">Proof</a>
<a href="/blog.html">Writing</a>
<a href="https://github.com/earfman/coretexa-verify" target="_blank" rel="noopener">GitHub</a>
</div>
<a href="https://github.com/marketplace/actions/coretexa-verify" target="_blank" rel="noopener" class="btn btn-primary desk">Get it</a>
<button class="nav-toggle" id="navToggle" aria-label="Menu">≡</button>
</div>
</nav>
<span id="top"></span>
<header class="proof-hero wrap">
<div class="sec-tag kicker"><span class="num">PROOF</span> verification benchmark · a living log</div>
<h1>We let a second agent <span class="hl">try to break</span> our own fixes.</h1>
<p class="sub">Coretexa is the rule that the agent which does the work can't close it. This is the receipt: every time we run the loop against a real open-source bug, an independent verifier tries to refute the fix before it ships. Here is what it caught.</p>
<p class="updated">last updated <b>2026-07-27</b> · <span class="live">● live</span> — appended as runs happen</p>
<div class="score">
<div class="cell"><div class="k">Fix runs</div><div class="v">19<small> + 3 reported</small></div></div>
<div class="cell"><div class="k">Bot PRs refuted</div><div class="v">5<small> / 1 fixed</small></div></div>
<div class="cell hero-cell"><div class="k">Verifier catches</div><div class="v">11<small> of 12 written up</small></div></div>
<div class="cell"><div class="k">First-pass-correct</div><div class="v">1</div></div>
<div class="cell"><div class="k">Withdrawn by us</div><div class="v">1<small> duplicate</small></div></div>
<div class="cell hero-cell"><div class="k">Merged</div><div class="v">5<small> / 11 in review</small></div></div>
</div>
<p class="proof-sub" style="text-align:left;margin:14px 0 0"><b style="color:var(--ok)">Five merges landed:</b> a Bazel maintainer merged the <code>buildtools</code> fix into <code>bazelbuild:main</code> (Google/Bazel core tooling); the FastMCP auth fix merged the same evening it posted; and — the marquee — a Google maintainer merged the <code>gson</code> fix into <code>google/gson</code> after running it through Google’s full internal test suite first (a library with 1B+ downloads). Ecosystems: TypeScript · Python · Rust · Go · Java — including GitHub’s own <code>gh</code> CLI and the MCP reference SDK. Run 6 is the first <b style="color:var(--white)">first-pass-correct</b> run: the doer nailed it and the verifier said so. We report that honestly rather than claim a perfect catch rate — a catch rate you can’t distinguish from a clean pass isn’t worth anything. The fourth merge landed 07-25: a Sollumz maintainer merged the <code>szio</code> fix <b style="color:var(--white)">six hours after a user filed the bug</b> — and it was the <em>second</em> version of that fix, because the verifier killed the first one for silently corrupting data while all 291 tests passed. Also in flight: <code>superfile</code> (a 1.36GB memory blowup traced to a mis-parsed video header) and <code>QuantEcon.py</code>. The fifth merge landed 07-27: <code>git-machete</code>, after four rounds of review across nine commits — the maintainer invited us as a collaborator partway through. On <code>croniter</code>, a Pallets-eco maintainer diffed <b style="color:var(--white)">8,012 schedule expansions</b> to characterise the blast radius himself before approving in principle — the most rigorous review any of this work has received, and worth more to us than the merge. Two entries below are not wins: a <code>pydantic</code> PR closed by policy because we read the PR template and not the contributing guide, and a <code>cachetools</code> fix we withdrew as a duplicate of an open PR our own check missed. Runs 1–12 carry the full catch write-ups; 13–19 are logged in brief. Meanwhile the same hostile-verification discipline opened a second front: <b style="color:var(--white)">refuting other agents’ green-CI pull requests</b> (see REFUTE, below).</p>
<div class="callout">
<h3>A passing test suite lied — and the verifier caught it.</h3>
<p>Fixing a panic in <code>rust-url</code> (the URL crate nearly every Rust program depends on), the first fix made the project's <b style="color:var(--white)">entire Web Platform Test suite pass green</b>. It was still wrong: it silently dropped Windows drive letters, turning <code>file:///a:/..</code> into <code>file:///</code>. The bundled test data had no case for it, so the green was a false green.</p>
<p>The independent verifier didn't trust the green. It ran a differential sweep against the WHATWG reference, caught the regression, and rejected the fix. The doer narrowed it; the second pass verified clean. <b style="color:var(--amber)">That is the entire point of Coretexa</b> — the actor that did the work was not allowed to close it.</p>
<p style="font-size:13px"><b>Honest postscript (07-24):</b> Servo declined the PR — “the Servo project does not currently allow AI contributions.” A policy call, theirs to make; we logged it as <code>rejected-policy</code>, added <code>servo/*</code> to our do-not-post list, and the catch above stands on its own merits. And the pattern repeated: on 07-25 the very same false-green failure mode was caught again, in <code>szio</code> — a fix that passed all 291 tests and was still silently corrupting data (first entry in the log below).</p>
</div>
</header>
<div class="divider"></div>
<section class="wrap">
<div class="sec-tag"><span class="num">LOG</span> the run history</div>
<div class="log">
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-27</span>
<span class="repo">pydantic/pydantic #13507</span>
<span class="badge lang">Python</span>
<span class="badge" style="color:var(--ink-dim);border-color:var(--line)">closed · policy</span>
</div>
<h3>Every constraint chained after <code>ge</code>/<code>lt</code>/<code>le</code> vanished from the published JSON schema</h3>
<p>In pydantic’s experimental <code>pipeline</code> API, <code>validate_as(int).ge(0).multiple_of(2)</code> emitted a JSON schema carrying only the <code>ge</code>. The dropped constraint still <em>ran</em> at validation time — so the model rejected odd numbers while the schema it published said they were fine. Every consumer downstream of that schema — a generated client, an OpenAPI document, a form builder — would have disagreed with the server, and nothing would have logged an error anywhere.</p>
<p style="font-size:13px;margin-top:8px"><b style="color:var(--amber)">Closed by policy, and the mistake was ours.</b> A bot closed the pull request within minutes: pydantic requires a contributor to be assigned to the referenced issue before opening one. That rule is stated plainly in <code>docs/contributing.md</code> — a file that was sitting in our own checkout, unread. We read the PR template and not the contributing guide. The issue stands open on its merits; the PR is logged here as a process failure, not a technical one.</p>
<div class="links">
<a href="https://github.com/pydantic/pydantic/issues/13507" target="_blank" rel="noopener">Issue #13507 →</a>
<a href="https://github.com/pydantic/pydantic/pull/13508" target="_blank" rel="noopener">Pull request #13508 (closed) →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-26</span>
<span class="repo">knadh/koanf #434</span>
<span class="badge lang">Go</span>
<span class="badge open">PR open</span>
</div>
<h3><code>Int64</code> returned <span style="color:var(--white)">the most negative number</span> for the largest positive one</h3>
<p><code>koanf.Int64</code> falls through to a float round-trip for any non-integer input and finishes with <code>int64(f)</code>. Go leaves that conversion implementation-defined when the value is out of range; on amd64 and arm64 the hardware hands back the “integer indefinite” value, which is <code>math.MinInt64</code>. JSON is what makes it reachable from an ordinary config file, because <code>encoding/json</code> decodes every number to a <code>float64</code> and <code>float64(math.MaxInt64)</code> rounds <em>up</em> past the int64 range. So <code>{"n": 9223372036854775807}</code> — the largest legal int64 — read back as <code>-9223372036854775808</code>.</p>
<div class="catch"><b>The guard that does not work:</b> the obvious bound, <code>f > math.MaxInt64</code>, is false for exactly the values that overflow. <code>math.MaxInt64</code> is an untyped constant, and it converts to the <span class="em">same float64</span> that the overflowing value rounds to, so the comparison never fires — a guard that looks right, compiles, and silently lets every bad value through. The fix bounds on <code>float64(1 << 63)</code> instead. <code>float64(math.MinInt64)</code> <em>is</em> exactly representable, so it is correct on the low side; NaN compares false against everything and needs its own test.</div>
<div class="links">
<a href="https://github.com/knadh/koanf/issues/434" target="_blank" rel="noopener">Issue #434 →</a>
<a href="https://github.com/knadh/koanf/pull/435" target="_blank" rel="noopener">Pull request #435 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-25</span>
<span class="repo">gtk-rs/gtk4-rs #2345</span>
<span class="badge lang">Rust</span>
<span class="badge open">PR open</span>
</div>
<h3>A refactor moved eight methods onto a trait <span style="color:var(--white)">no widget subclass can reach</span></h3>
<p>Since 0.11.4, a gtk4-rs widget subclass with a custom class struct could no longer call <code>add_binding_action</code> from <code>class_init()</code> — nor <code>add_shortcut</code>, <code>install_property_action</code>, <code>query_action</code>, <code>activate_signal</code>, <code>layout_manager_type</code>, <code>css_name</code> or <code>accessible_role</code>. A commit titled “allow calling Class methods on any widget” moved all eight off <code>WidgetClassExt</code> (bounded on <code>ClassStruct</code>) and onto a new <code>WidgetClassManualExt</code> implemented for <code>glib::Class<T></code>. Those two bounds are disjoint, so the methods became unreachable from precisely the place the documentation tells you to call them.</p>
<p style="font-size:13px;margin-top:8px"><b>The issue reported one method. All eight were gone.</b> The affected version window is not recoverable from the tags — <code>git tag --contains</code> on the offending commit returns nothing — so it was established by checking out released tags one at a time and compiling against each.</p>
<div class="links">
<a href="https://github.com/gtk-rs/gtk4-rs/issues/2345" target="_blank" rel="noopener">Issue #2345 →</a>
<a href="https://github.com/gtk-rs/gtk4-rs/pull/2346" target="_blank" rel="noopener">Pull request #2346 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-25</span>
<span class="repo">Sollumz/szio #1217</span>
<span class="badge lang">Python</span>
<span class="badge" style="color:var(--ground);background:var(--ok);border-color:var(--ok);font-weight:600">✓ MERGED</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3>All 291 tests passed — and the fix was still silently corrupting a matrix shape the suite never checks</h3>
<p>Sollumz (the standard GTA V Blender toolchain) crashed importing any model whose <code>CompositeTransform</code> used tabs: the matrix parser in <code>szio</code> split rows on literal 3-space runs and values on single spaces, so tab-delimited files died with <code>ValueError: could not convert string to float: '0\t\t\t\t\t0'</code>. Scouted 5 hours after a user filed it, reproduced byte-identical, root-caused, fixed with tests — PR posted 26 hours after the issue opened, race-clean the whole way.</p>
<div class="catch"><b>Catch — the false green, again:</b> the doer’s first fix (flat whitespace tokenization) passed the <b style="color:var(--white)">entire 291-test suite green</b>. The adversarial verifier corpus-diffed old-vs-new over the repo’s own fixtures and killed it: CodeWalker writes fragment bound matrices as <span class="em">4 rows × 3 columns</span>, and the flat fill silently smeared orientation and translation — demonstrated end-to-end through the public <code>Fragment</code> API, on files the project itself ships. No test asserted those values, so CI stayed green over live data corruption. v2 preserves per-row structure; both verifiers re-ran clean in pristine trees. The run also surfaced two latent bugs nobody had filed (a wrong return class, and a crash under the standalone numpy backend).</div>
<p style="font-size:13px;margin-top:8px"><b style="color:var(--ok)">Merged 07-25, six hours after the bug was filed:</b> a Sollumz maintainer merged it into <code>szio:main</code> (commit <code>5aa3d16</code>), auto-closing the Sollumz issue — the benchmark’s fourth merge. Worth stating plainly: the version that merged is the <em>second</em> one. The first passed every test and would have shipped silent data corruption.</p>
<div class="links">
<a href="https://github.com/Sollumz/szio/pull/2" target="_blank" rel="noopener">Pull request #2 →</a>
<a href="https://github.com/Sollumz/Sollumz/issues/1217" target="_blank" rel="noopener">Issue #1217 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-25</span>
<span class="repo">QuantEcon/QuantEcon.py #870</span>
<span class="badge lang">Python</span>
<span class="badge open">PR open</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3>A download utility saved HTTP <span style="color:var(--white)">error pages</span> under the requested filename — and reported success</h3>
<p><code>fetch_nb_dependencies</code>, exported at the top level of QuantEcon.py (the standard computational-economics library), wrote whatever the server returned straight to disk and appended <code>True</code>. Ask for a file that isn’t there and you get a 314 KB HTML error page saved as <code>your-data.csv</code>, reported as fetched — the failure resurfaces later as a parse error somewhere unrelated. Four defects in ~30 lines: no <code>raise_for_status()</code>, no timeout, a file handle shadowing the loop variable, and <code>type(files) == list</code> sending tuples into the wrong branch.</p>
<div class="catch"><b>Catch — the test gap was ours:</b> the adversarial verifier mutation-tested our own new tests and found one that couldn’t fail: reverting the default timeout to <code>None</code> (reintroducing the unbounded-hang bug) left the suite green, because we only asserted the <em>explicit</em> timeout path. Fixed by pinning the default. It also surfaced a consequence the issue never mentioned — with <code>overwrite=True</code> the old code <span class="em">destroyed a good local file</span>, replacing real data with the error page and still returning success. That is silent data loss, now disclosed in the PR.</div>
<p style="font-size:13px;margin-top:8px">A quieter echo of the same theme: the two pre-existing tests for this function <b style="color:var(--white)">passed by saving an error page</b> in any environment without network access — the bug passing its own test, in a third repo this week.</p>
<div class="links">
<a href="https://github.com/QuantEcon/QuantEcon.py/pull/905" target="_blank" rel="noopener">Pull request #905 →</a>
<a href="https://github.com/QuantEcon/QuantEcon.py/issues/870" target="_blank" rel="noopener">Issue #870 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-25</span>
<span class="repo">yorukot/superfile #1550</span>
<span class="badge lang">Go</span>
<span class="badge open">PR open</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3>19 GB of RAM eaten by a file manager — because Go’s PE parser accepted a video as a COFF object</h3>
<p>A user reported superfile filling RAM and swap until the kernel killed it, just from scrolling past large videos, and blamed the exif reader. It wasn’t exif. <code>GetBinaryArchitecture</code> runs on every file, and Go’s <code>debug/pe</code> accepts files <span class="em">without</span> an <code>MZ</code> header as raw COFF objects — so an MP4’s leading bytes get read as section and symbol counts, and the parser allocates against garbage offsets inside a 2 GB file. One goroutine fires per cursor move, so a sweep multiplies it. The fix gates all three <code>debug/*</code> parsers behind a 4-byte magic check. Measured over 200 concurrent fetches: <b style="color:var(--white)">+1,357 MB → +0.6 MB</b>, 18s → 0.01s.</p>
<div class="catch"><b>Catch:</b> the verifier ran ~40 fixtures — real ELF and <code>.so</code>, cross-compiled PE, thin/byte-swapped/fat Mach-O, a clang-produced COFF object, permission-denied files, fifos — and found one honest parity gap: MZ-less RISC-V COFF objects would have <span class="em">lost their architecture label</span>. Three constants fixed it. It also measured the residual we chose to keep (a 2-byte magic collision still reaches the parser, ~5 in 65536 on random data), which is disclosed in the PR rather than quietly shipped.</div>
<p style="font-size:13px;margin-top:8px">Posted ~3 hours after the report. The repo’s own AI reviewer looked at the change and returned “no actionable comments” — on a fix for a bug that AI review had never caught in the first place.</p>
<div class="links">
<a href="https://github.com/yorukot/superfile/pull/1552" target="_blank" rel="noopener">Pull request #1552 →</a>
<a href="https://github.com/yorukot/superfile/issues/1550" target="_blank" rel="noopener">Issue #1550 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-21</span>
<span class="repo">VirtusLab/git-machete #1754</span>
<span class="badge lang">Python</span>
<span class="badge" style="color:var(--ground);background:var(--ok);border-color:var(--ok);font-weight:600">✓ MERGED</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3><code>discover</code>/<code>status</code> showed a <span style="color:var(--white)">different branch tree</span> in every worktree</h3>
<p>git-machete inferred branch structure from the HEAD reflog — which is <span class="em">per-worktree</span> in git — so the same repo produced different discovered trees depending on which worktree you ran it from. The fix reads reflogs across all worktree HEADs. Found the same way as the szio bug: a fresh user-reported issue, hours old, race-checked immediately.</p>
<div class="catch"><b>Catch:</b> the fix replaced a <code>git</code> subprocess call with direct file reads — and the hostile verifier caught that this silently dropped the subprocess’s implicit strict-UTF-8 decode. On a non-UTF-8-locale environment (minimal containers, <code>LC_ALL=C</code> CI), one accented committer name in a reflog would have crashed the command — a regression the doer’s green tests never touched. Fixed with an explicit <code>utf-8</code>/<code>surrogateescape</code> read that is strictly more robust than the old path.</div>
<p style="font-size:13px;margin-top:8px"><b style="color:var(--ok)">Merged 07-27:</b> nine commits across four rounds of review — the longest engagement on the board, and the one that produced the most correction. The maintainer issued a collaborator invite partway through. Merge five.</p>
<div class="links">
<a href="https://github.com/VirtusLab/git-machete/pull/1755" target="_blank" rel="noopener">Pull request #1755 →</a>
<a href="https://github.com/VirtusLab/git-machete/issues/1754" target="_blank" rel="noopener">Issue #1754 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-20</span>
<span class="repo">pallets-eco/croniter #246</span>
<span class="badge lang">Python</span>
<span class="badge open">PR open</span>
<span class="badge" style="color:var(--cyan);border-color:var(--cyan-dim)">● maintainer approved in principle</span>
</div>
<h3><code>59/15 * * * *</code> fired four times an hour — and never at :59</h3>
<p>When a step expression’s start equals the field maximum, croniter expanded <code>{start}/{step}</code> to the <em>entire field</em>. A job scheduled <code>59/15 * * * *</code> ran at :00, :15, :30 and :45 — four times an hour, at none of which the user asked for. The same held in every field at its maximum: <code>23/6</code> in hours, <code>DEC/3</code> in months, <code>SAT/2</code> in day-of-week, <code>31/5</code> in day-of-month. The cause is a normalisation artefact read as user intent: <code>{start}/{step}</code> is rewritten to <code>{start}-{max}/{step}</code>, which at the maximum becomes <code>{max}-{max}/{step}</code> and falls into the branch meant for a user-written equal range like <code>Jan-Jan</code>, which croniter deliberately expands to the whole cycle.</p>
<div class="catch"><b>Reviewed by a Pallets-eco maintainer.</b> Jarek Potiuk (<code>potiuk</code>) did not take the claim on trust — he characterised the blast radius himself, diffing <code>.expanded</code> across <b style="color:var(--white)">8,012 cases</b> (4,006 generated expressions × two modes). 1,996 differ, every one of them containing a field-max <code>X/step</code> token, and none change error status. His verdict: “approving in principle.” He also caught two formatting violations the project’s own CI structurally cannot — <code>tox -e fmt</code> runs <code>ruff format</code>, not <code>--check</code>. Exactly the failure mode this whole benchmark is about, found in the review of our own patch.</div>
<div class="links">
<a href="https://github.com/pallets-eco/croniter/pull/246" target="_blank" rel="noopener">Pull request #246 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-20</span>
<span class="repo">python-poetry/tomlkit #557</span>
<span class="badge lang">Python</span>
<span class="badge open">PR open</span>
</div>
<h3>A sub-table under a dotted key <span style="color:var(--white)">escaped its parent</span> and reappeared at the document root</h3>
<p>Given a document containing <code>[t]</code> with <code>a.b = 1</code>, assigning <code>doc["t"]["a"]["c"] = {}</code> rendered the header as <code>[a.c]</code> instead of <code>[t.a.c]</code>. The key left <code>t.a</code> and reappeared at the root, so <code>parse(dumps(doc)) != doc</code> — a round-trip data-loss bug in the library Poetry uses to rewrite your <code>pyproject.toml</code>. Array-of-tables had the same fault. In <code>Container._render_table</code> a single <code>prefix</code> argument was doing two incompatible jobs: the relative dotted-key prefix a leaf item needs, and the absolute header path a nested sub-table needs. The dotted-key branch dropped it entirely — right for the leaf, wrong for anything nested under it.</p>
<div class="catch"><b>This is the run where the mechanical half is visible in the PR itself.</b> The new tests were checked by reverting <code>container.py</code> to its base content while keeping them — and they fail, so they genuinely gate the change rather than passing alongside it. That check is the experiment now packaged as <a href="https://github.com/marketplace/actions/coretexa-verify" style="color:var(--cyan)">coretexa-verify</a>, and this is it run by hand on our own work before we asked anyone else to trust it.</div>
<div class="links">
<a href="https://github.com/python-poetry/tomlkit/pull/568" target="_blank" rel="noopener">Pull request #568 →</a>
<a href="https://github.com/python-poetry/tomlkit/issues/557" target="_blank" rel="noopener">Issue #557 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-19</span>
<span class="repo">jd/tenacity #658</span>
<span class="badge lang">Python</span>
<span class="badge open">PR open</span>
</div>
<h3><code>raise e from e</code> pinned a core at 100% forever — and <code>stop_after_attempt</code> could not stop it</h3>
<p><code>retry_if_exception_cause_type</code> walks the <code>__cause__</code> chain until it reaches <code>None</code>. A cyclic chain never does, and the simplest cycle is the one-liner <code>raise e from e</code>. What makes this worse than an ordinary hang is <em>where</em> it spins: inside the retry predicate. Tenacity only consults stop conditions <span class="em">after</span> the predicate returns, so <code>stop_after_attempt</code>, <code>stop_after_delay</code> and every other bound the user configured are unreachable. The stdlib <code>traceback</code> module guards against exactly these cause cycles when walking exception chains; tenacity did not.</p>
<p style="font-size:13px;margin-top:8px">The regression test hangs indefinitely on <code>main</code> and passes in milliseconds with the fix — bounded only by an external timeout, which is the honest way to write a test for a hang. Both cycle shapes are covered: the self-cause one-liner and a two-node <code>a → b → a</code>.</p>
<div class="links">
<a href="https://github.com/jd/tenacity/issues/658" target="_blank" rel="noopener">Issue #658 →</a>
<a href="https://github.com/jd/tenacity/pull/659" target="_blank" rel="noopener">Pull request #659 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-19</span>
<span class="repo">tkem/cachetools #406</span>
<span class="badge lang">Python</span>
<span class="badge" style="color:var(--ink-dim);border-color:var(--line)">withdrawn · duplicate</span>
</div>
<h3>An overwrite that looked like it worked left the <span style="color:var(--white)">old value readable</span> — and we filed a duplicate</h3>
<p><code>TLRUCache.__setitem__</code> skips storing an item whose <code>ttu</code> is already in the past. When the key already held a live value, the skip path returned without invalidating it: <code>key in cache</code> stayed <code>True</code> and <code>cache[key]</code> returned the <em>overwritten</em> value, after an assignment that raised nothing and looked like it succeeded. <code>TTLCache</code> does the opposite — store, then expire — so a <code>ttl=0</code> overwrite there invalidates correctly. The two classes diverge in exactly the value-derived-<code>ttu</code> pattern the documentation recommends.</p>
<div class="catch"><b>Withdrawn by us — the only one so far.</b> PR #400 already fixed this bug and predated ours. Our duplicate check searched open <em>issues</em> and keyword-missed the open <em>pull request</em>. We closed ours the moment we saw it, credited the earlier author, and left the additional analysis on the issue where it might still be useful. The maintainer’s reply — “thanks for sharing, and providing additional analysis” — was a kinder outcome than the process earned. It is in the log because a benchmark that quietly deletes its own misses is not a benchmark.</div>
<div class="links">
<a href="https://github.com/tkem/cachetools/issues/406" target="_blank" rel="noopener">Issue #406 →</a>
<a href="https://github.com/tkem/cachetools/pull/407" target="_blank" rel="noopener">Pull request #407 (withdrawn) →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-20 → 07-27</span>
<span class="repo">aiocache #1081 · cast #356 · cobra #2463</span>
<span class="badge lang">Python · Go</span>
<span class="badge open">reported, no PR</span>
</div>
<h3>Three reported and deliberately <span style="color:var(--white)">not patched</span></h3>
<p>Not every finding should arrive as a pull request. Each of these changes behaviour somebody may be relying on, so they went in as issues — reproduction, root cause, and the fix decision left where it belongs.</p>
<div class="catch"><b>aio-libs/aiocache #1081</b> — <code>clear(namespace="user")</code> on <code>SimpleMemoryCache</code> prefix-matches with no boundary, so it silently clears <code>user_sessions</code> too. The Valkey backend does not behave this way, so the two backends of the same API disagree about what a namespace is.<br><br><b>spf13/cast #356</b> — <code>ToInt64E(math.MaxUint64)</code> returns <code>-1</code> and no error. Out-of-range numeric conversions wrap silently across the API, in a library whose entire job is converting between types safely.<br><br><b>spf13/cobra #2463</b> — help output depends on the order you called <code>AddCommand</code>, because <code>CommandPathPadding</code> is snapshotted once and never recomputed. Reorder two registrations and your CLI’s help text changes alignment.</div>
<div class="links">
<a href="https://github.com/aio-libs/aiocache/issues/1081" target="_blank" rel="noopener">aiocache #1081 →</a>
<a href="https://github.com/spf13/cast/issues/356" target="_blank" rel="noopener">cast #356 →</a>
<a href="https://github.com/spf13/cobra/issues/2463" target="_blank" rel="noopener">cobra #2463 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-17</span>
<span class="repo">PrefectHQ/fastmcp #4515</span>
<span class="badge lang">Python</span>
<span class="badge" style="color:var(--ground);background:var(--ok);border-color:var(--ok);font-weight:600">✓ MERGED</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3>One unsupported key in a JWKS rejected <span style="color:var(--white)">every</span> token — on the MCP auth path</h3>
<p>FastMCP’s <code>JWTVerifier</code> converted every key in a remote JWKS up front with no per-key guard, so a single Ed25519 key (which Rauthy and Ory Hydra publish next to their RSA keys) made the whole set fail — every token rejected, including ones validly RSA-signed. The fix skips unusable keys per RFC 7517 instead of letting one poison the set. First bug run through our new automated <b style="color:var(--white)">find→fix→verify→stage</b> pipeline, then held for a human to approve posting.</p>
<div class="catch"><b>Catch (and a first):</b> the verifier’s 20 adversarial probes couldn’t break the code — but it caught the write-up calling the change “behavior identical” (it wasn’t; full inventory now in the PR), a missed hardening case, and — the notable one — a <b style="color:var(--white)">sanction ruling</b>: the issue reporter had offered a PR, so posting silently would have appropriated their diagnosis. We led the PR with credit to them and offered co-authorship on the issue. Our own no-self-ship rule, applied to us: the doer staged, a human shipped.</div>
<p style="font-size:13px;margin-top:8px"><b style="color:var(--ok)">Full arc, same day:</b> 90 minutes after posting, the repo’s Require Issue Link bot auto-closed the PR (issue not yet assigned to the author — a process gate our scouting missed; we logged the miss here the hour it happened). One assignment-request comment later: a maintainer assigned the issue, the PR auto-reopened, and it was <b style="color:var(--ok)">merged the same evening</b> — the benchmark’s second merge. The reporter’s reply: “Your version is better than what I’d have sent.” Crediting their diagnosis cost one sentence and earned an endorsement.</p>
<div class="links">
<a href="https://github.com/PrefectHQ/fastmcp/pull/4517" target="_blank" rel="noopener">Pull request #4517 →</a>
<a href="https://github.com/PrefectHQ/fastmcp/issues/4515" target="_blank" rel="noopener">Issue #4515 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-17</span>
<span class="repo">google/gson #992</span>
<span class="badge lang">Java</span>
<span class="badge" style="color:var(--ground);background:var(--ok);border-color:var(--ok);font-weight:600">✓ MERGED</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3>Equal <code>JsonPrimitive</code>s hashed differently — breaking <code>HashMap</code> after every JSON round-trip</h3>
<p>gson’s <code>equals</code> treats <code>42</code>, a parsed <code>"42"</code>, and <code>42.0</code> as equal — but <code>hashCode</code> used a different algorithm per backing type, violating Java’s <code>Object.hashCode</code> contract. Store a value under <code>new JsonPrimitive(42)</code>, round-trip the number through JSON, and the lookup misses. The fix derives the hash solely from the <code>double</code> value every branch of <code>equals</code> compares. Java is the log’s <b style="color:var(--white)">sixth ecosystem</b>, in a library with over a billion downloads.</p>
<div class="catch"><b>Catch:</b> the verifier fuzzed ~4.7M number pairs (zero violations survive the fix) — then attacked the <span class="em">report</span>. It caught the doer’s writeup misstating which hash values change (integral-valued doubles like <code>42.0</code> change too, not just huge longs) and required disclosure of a pre-existing <code>equals</code> non-transitivity the fix deliberately does not touch. Both corrections landed in the PR before it opened.</div>
<p style="font-size:13px;margin-top:8px"><b style="color:var(--ok)">Merged 07-23:</b> filed with eyes open — gson is largely in maintenance mode, so this was banked as a quality proof point, not an expected merge. It merged anyway: a Google maintainer ran the change through <b style="color:var(--white)">all of Google’s internal tests</b> first (“the test run passed, so I think this is good to go”), then merged it into <code>google/gson</code> — the benchmark’s third merge, and its highest-reputation one.</p>
<div class="links">
<a href="https://github.com/google/gson/pull/3059" target="_blank" rel="noopener">Pull request #3059 →</a>
<a href="https://github.com/google/gson/issues/992" target="_blank" rel="noopener">Issue #992 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-14</span>
<span class="repo">cli/cli #9252</span>
<span class="badge lang">Go</span>
<span class="badge open">PR open</span>
<span class="badge" style="color:var(--cyan);border-color:var(--cyan-dim)">● first-pass verified</span>
</div>
<h3><code>gh search code --repo A,B --web</code> built an <span style="color:var(--white)">unsatisfiable</span> query — on GitHub’s own CLI</h3>
<p>Searching code across multiple repos with <code>--web</code> opened the browser with <code>keyword repo:A repo:B</code>. GitHub’s code search ANDs repeated qualifiers, so that asks for a file in <em>both</em> repos at once — impossible — and the page returns “condition is unsatisfiable.” The fix OR-groups them: <code>( keyword ) (repo:A OR repo:B)</code>, scoped to github.com so enterprise’s legacy search isn’t disturbed. A verification protocol that runs on GitHub, fixing GitHub’s own tool.</p>
<div class="catch" style="border-left-color:var(--cyan)"><b style="color:var(--cyan)">First-pass-correct.</b> <span class="em">The first run where the verifier didn’t catch a defect</span> — the doer got the fix, tests, and scoping right first try. The verifier confirmed the non-obvious part: the parentheses are load-bearing. A naive <code>keyword repo:A OR repo:B</code> would parse as <code>(keyword AND repo:A) OR repo:B</code> — silently returning <em>every</em> file in the second repo. It also flagged one pre-existing scope gap (<code>--match file,path</code>), which we disclosed in the PR rather than silently ship or speculatively over-fix. We log this as <b style="color:var(--white)">not a catch</b>, on purpose.</div>
<div class="links">
<a href="https://github.com/cli/cli/pull/13874" target="_blank" rel="noopener">Pull request #13874 →</a>
<a href="https://github.com/cli/cli/issues/9252" target="_blank" rel="noopener">Issue #9252 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-13</span>
<span class="repo">modelcontextprotocol/typescript-sdk #2284</span>
<span class="badge lang">TypeScript</span>
<span class="badge open">PR open</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3>Invalid params to a spec method answered <code>-32603</code> Internal error instead of <code>-32602</code> Invalid params</h3>
<p>When a spec-defined method (e.g. <code>logging/setLevel</code>) got params that failed its wire schema, the dispatch closure re-threw a bare error and the funnel mapped it to <code>-32603</code> — telling the caller the <em>server</em> broke when in fact the <em>request</em> was malformed. Per JSON-RPC 2.0 that’s <code>-32602</code>. Custom handlers with a params schema already answered <code>-32602</code>; the fix brings spec methods in line. Filed by a core MCP maintainer; an MCP-native verifier fixing the MCP reference SDK.</p>
<div class="catch"><b>Catch:</b> the verifier caught an <span class="em">overstated blast radius</span> — the doer’s first writeup implied ordinary <code>Server</code> consumers hit the bug, but the <code>Server</code> wrapper validates params first and already returned <code>-32602</code>; the real leak was confined to unwrapped spec-method dispatch / raw <code>Protocol</code> consumers. It also caught that <code>logging/setLevel</code> is deleted from the 2026 era registry, so the “covers both eras” claim had to be re-scoped. Corrected before the PR opened.</div>
<div class="links">
<a href="https://github.com/modelcontextprotocol/typescript-sdk/pull/2492" target="_blank" rel="noopener">Pull request #2492 →</a>
<a href="https://github.com/modelcontextprotocol/typescript-sdk/issues/2284" target="_blank" rel="noopener">Issue #2284 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-13</span>
<span class="repo">bazelbuild/buildtools #1470</span>
<span class="badge lang">Go</span>
<span class="badge" style="color:var(--ground);background:var(--ok);border-color:var(--ok);font-weight:600">✓ MERGED</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3>buildifier needed two passes to reach a stable format — and failed its own <code>--mode=check</code></h3>
<p style="color:var(--ok);font-size:13px;margin-bottom:6px"><b>Merged into <code>bazelbuild:main</code></b> by a Bazel maintainer (“Thanks!”) — the benchmark’s first merge, on Google/Bazel core tooling.</p>
<p>A compact block statement followed by a comment (<code>def f(): pass</code> + <code># comment</code>) parsed to a different AST than its expanded form: the comment attached to the block instead of becoming a standalone comment statement, so pass 1 omitted the separating blank line and freshly formatted files failed check-mode CI. The fix makes both forms parse identically; one pass now converges. 222-file differential sweep: zero changes to any stable format.</p>
<div class="catch"><b>Catch:</b> this time the verifier caught the <span class="em">evidence, not the code</span> — one of the doer's four test shapes never reproduced the bug, half the "tests pass" claim was vacuous (the cited test never exercises plain golden files), a code comment referenced behavior that doesn't exist, and a toolchain version mismatch would have shipped a noisy generated-table diff. All four corrected before submission.</p></div>
<div class="links">
<a href="https://github.com/bazelbuild/buildtools/pull/1481" target="_blank" rel="noopener">Pull request #1481 →</a>
<a href="https://github.com/bazelbuild/buildtools/issues/1470" target="_blank" rel="noopener">Issue #1470 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-13</span>
<span class="repo">servo/rust-url #1114</span>
<span class="badge lang">Rust</span>
<span class="badge" style="color:var(--ink-dim);border-color:var(--line)">closed · policy</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3>Panic joining a relative reference onto a <code>file:</code> URL with a drive-letter-shaped segment</h3>
<p><code>pop_path</code> protected any path segment shaped like a Windows drive letter — even one not in drive position (the <code>a:</code> in <code>/w:/a:</code>) — so <code>..</code> was appended without a separating slash and a debug-assert panicked. The fix restricts the guard to the drive-position segment, per the WHATWG spec.</p>
<div class="catch"><b>Catch:</b> the first fix <span class="em">passed the full WPT suite green</span> but regressed <code>file:///a:/..</code> to <code>file:///</code>. The verifier's differential sweep vs. the WHATWG oracle caught the false green; the fix was narrowed to a single hunk and re-verified byte-for-byte against the clean baseline.</p></div>
<p style="font-size:13px;margin-top:8px"><b style="color:var(--ink-dim)">Closed on policy 07-24:</b> a maintainer closed the PR because “the Servo project does not currently allow AI contributions” — a blanket policy, not a defect in the fix. Logged honestly: the verifier catch (a false green, caught before ship) still stands as the proof point; the distribution outcome was foreclosed by policy, not by the merits.</p>
<div class="links">
<a href="https://github.com/servo/rust-url/pull/1143" target="_blank" rel="noopener">Pull request #1143 →</a>
<a href="https://github.com/servo/rust-url/issues/1114" target="_blank" rel="noopener">Issue #1114 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-13</span>
<span class="repo">awslabs/aws-cfn-template-flip #120</span>
<span class="badge lang">Python</span>
<span class="badge open">PR open</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3><code>Fn::GetAtt</code> with a nested intrinsic crashed on dump</h3>
<p>A CloudFormation <code>GetAtt</code> containing a nested <code>FindInMap</code> (allowed by <code>AWS::LanguageExtensions</code>) crashed the dumper. The library pulls ~2.6M downloads/month, so the broken path is well-travelled.</p>
<div class="catch"><b>Catch:</b> the obvious fix stopped the crash but emitted <span class="em">YAML the library's own loader could not read back</span> — it fixed the dump and broke the round-trip, the whole purpose of a format converter. The verifier caught it; the fix switched to the long-form mapping that round-trips cleanly.</div>
<div class="links">
<a href="https://github.com/awslabs/aws-cfn-template-flip/pull/122" target="_blank" rel="noopener">Pull request #122 →</a>
<a href="https://github.com/awslabs/aws-cfn-template-flip/issues/120" target="_blank" rel="noopener">Issue #120 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-12</span>
<span class="repo">oguimbal/pg-mem #338</span>
<span class="badge lang">TypeScript</span>
<span class="badge open">PR open</span>
<span class="badge caught">✓ verifier caught</span>
</div>
<h3><code>= ANY(array)</code> on an indexed column returned no rows</h3>
<p>An index optimization compared an indexed column against the whole array value instead of element-wise, silently returning nothing. A two-year-old open issue. The fix skips the scalar-index path for <code>ANY</code>/<code>ALL</code>.</p>
<div class="catch"><b>Catch:</b> before a single line was filed, verification discipline <span class="em">killed three wrong leads</span> — a "recursive-CTE bug" that was an unimplemented feature, a "uuid-specific" bug that was actually general, and a wrong initial reproduction. The discipline's value showed up as bugs <em>not</em> filed.</div>
<div class="links">
<a href="https://github.com/oguimbal/pg-mem/pull/477" target="_blank" rel="noopener">Pull request #477 →</a>
<a href="https://github.com/oguimbal/pg-mem/issues/338" target="_blank" rel="noopener">Issue #338 →</a>
</div>
</article>
</div>
</section>
<div class="divider"></div>
<section class="wrap">
<div class="sec-tag"><span class="num">REFUTE</span> verifying other agents’ pull requests</div>
<p class="proof-sub" style="text-align:left;margin:0 0 18px">A second front, opened 07-24. AI-authored PRs now merge on green CI — written by one bot, reviewed by another, rubber-stamped by a human. We point the same hostile verifier at <b style="color:var(--white)">other agents’ open PRs</b>: reproduce the claim in a pristine tree, then try to break it. A finding posts only when the failure reproduces deterministically — and every one below survived that gate <span class="em">after</span> the PR’s own CI passed and its AI reviewers signed off. The mechanical half of this discipline — can the PR’s own tests fail? — is packaged as <a href="https://github.com/marketplace/actions/coretexa-verify" style="color:var(--cyan)">a free check for your repo →</a></p>
<div class="log">
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-24</span>
<span class="repo">sqlfluff/sqlfluff PR #8187</span>
<span class="badge lang">Python</span>
<span class="badge caught">✓ refuted — novel</span>
</div>
<h3>A parser “fix” that silently un-lints the rest of the file</h3>
<p>An <code>Anything()</code> fallback in the sparksql <code>SET</code> grammar swallows the <span class="em">next statement</span> when a SET line lacks a terminator — <code>DROP TABLE prod.customers;</code> gets absorbed as raw tokens no lint rule ever visits. On merge-base the file correctly reports unparsable; on the PR head: zero violations. CI was green — 576/576 dialect tests — because no fixture omits its terminator. The repo’s AI reviewer looked at the exact line twice: “No issues found across 5 files, confidence 5/5.” The human reviewer caught a design overreach but not this. Reproduced twice independently, four swallowed-statement shapes, posted as a review comment.</p>
<div class="links"><a href="https://github.com/sqlfluff/sqlfluff/pull/8187" target="_blank" rel="noopener">PR #8187 review comment →</a></div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-24</span>
<span class="repo">sqlfluff/sqlfluff PR #8201</span>
<span class="badge lang">Python</span>
<span class="badge caught">✓ refuted — novel</span>
<span class="badge" style="color:var(--ink-dim);border-color:var(--line)">closed · possible bot</span>
</div>
<h3>The PR’s own scenario still failed in one dialect — and rewrote a query to return different rows</h3>
<p>An ST05 fix used two different identifier normalizers on the two sides of a reservation check. They agree in 27 dialects and disagree in exactly one: bigquery, where the PR’s own example still produced the unfixed output — an alias silently rebinding from a physical table to a generated CTE. Executed against a real engine: <code>[(10,),(20,),(30,)]</code> before, <code>[(0,)]</code> after. No error, different rows. CI: 2,471 tests green; new fixtures covered three dialects — not the one where the normalizers disagree. Five Codex review passes and one “confidence 5/5” cubic pass had cleared it.</p>
<div class="catch"><b style="color:var(--amber)">Outcome, 07-27 — and it is not a clean win.</b> The author acted on the finding: a commit titled <code>fix(ST05): avoid BigQuery CTE name capture</code> landed the same day. Then Codex found a self-reference problem and the author patched it; Codex found a keywordless-recursive-CTE problem and the author patched that; Codex found a <code>RecursionError</code> in alias allocation and the author patched that too. Eleven commits and twenty review comments in, a sqlfluff contributor labelled the pull request <b style="color:var(--white)"><code>possible bot</code></b> and closed it with one line: “Apparently the bots are having a lot of fun with this.” The author’s reply was “is this a fault on my end?”</div>
<p style="font-size:13px;margin-top:8px">We were right, and we were also part of what got closed. Our comment sits in that thread beside the machine review suggestions, and to a maintainer scrolling past, it reads like more of the same. That is the lesson from this run and it cuts against us: a correct refutation posted into an agent-versus-agent thread adds volume to exactly the signal maintainers are learning to pattern-match and dismiss. <b style="color:var(--white)">Being right is not sufficient.</b> The open question this leaves us with — and we do not have a settled answer — is whether a refutation is worth posting at all once a thread already carries two or more machine reviewers.</p>
<div class="links"><a href="https://github.com/sqlfluff/sqlfluff/pull/8201" target="_blank" rel="noopener">PR #8201 review comment →</a></div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-24 → 07-25</span>
<span class="repo">SollanSystems/loop-engineer PR #80 → issue #81 → PR #89</span>
<span class="badge lang">Python</span>
<span class="badge caught">✓ escalated — fixed upstream</span>
</div>
<h3>Refuted, ignored, merged — then the issue we filed was fixed upstream</h3>
<p>A Copilot-authored PR promised filesystem-non-mutating reads, but only delivered on cleanly-closed stores: with a crash-left <code>events.db-wal</code>, a read still creates an <code>events.db-shm</code> sidecar — and the PR’s own regression test only builds clean stores, so CI can’t see it. We posted the refute with a deterministic repro. The maintainer merged two days later: zero commits after the comment, no reply. Same day, we re-verified the leak against merged <code>main</code> and filed a standalone issue with a script that seeds the crash state — so the next fix has to beat a real test, not a green one. <b style="color:var(--ok)">On 07-25 the maintainer shipped that fix.</b> PR #89 reads crash-left WAL stores through a temp copy, and its description rejects both shortcuts the issue named — <code>immutable=1</code> silently drops WAL frames, checkpoint-on-open is a write. Six regression tests, with a negative control proving them red on unfixed <code>main</code>. Issue #81 closed as completed. The refutation was correct the first time; it only needed to be somewhere a merge couldn’t scroll past it. <span style="color:var(--ink-dim)">The fix is the maintainer’s, not ours — it is not counted as a merge above.</span></p>
<div class="links">
<a href="https://github.com/SollanSystems/loop-engineer/pull/80" target="_blank" rel="noopener">The refute on PR #80 →</a>
<a href="https://github.com/SollanSystems/loop-engineer/issues/81" target="_blank" rel="noopener">Follow-up issue #81 →</a>
<a href="https://github.com/SollanSystems/loop-engineer/pull/89" target="_blank" rel="noopener">The upstream fix, PR #89 →</a>
</div>
</article>
<article class="entry">
<span class="corner tl"></span><span class="corner br"></span>
<div class="top">
<span class="date">2026-07-24</span>
<span class="repo">FalkorDB #109 · elastic/apm-server #21556</span>
<span class="badge lang">Python · Go</span>
<span class="badge caught">✓ refuted ×2</span>
</div>
<h3>Two more, same shape: tests weakened until the regression passes</h3>
<p>A FalkorDB “stabilize tests” PR relaxed an assertion so that a possible Python 3.11 label-add regression passes green — reproduced both ways: correct code passes old and new tests, regressed code fails the original and <span class="em">passes the weakened one</span>. And on elastic/apm-server, a Copilot flaky-test fix left <code>RawFields</code> nil, deterministically breaking four downstream callers — posted as a help-first steer toward the bot’s own proposed upstream fix.</p>
<div class="links">
<a href="https://github.com/FalkorDB/FalkorDB/pull/109" target="_blank" rel="noopener">FalkorDB PR #109 →</a>
<a href="https://github.com/elastic/apm-server/pull/21556" target="_blank" rel="noopener">apm-server PR #21556 →</a>
</div>
</article>
</div>
<div class="honest"><b>One we verified and did not post:</b> a camunda bpmnlint finding was confirmed at the code level — then we found another agent had already surfaced the same defect in-thread an hour earlier. Posting would have been noise wearing a verification badge. Dropped, logged, counted nowhere above.</div>
</section>
<div class="divider"></div>
<section class="wrap">
<div class="sec-tag"><span class="num">METHOD</span> how a run works</div>
<div class="method-grid">
<div class="mcard">
<h3>The loop</h3>
<ul>
<li><b>Scout</b> — find an unclaimed, locally-reproducible bug (no existing fix PR).</li>
<li><b>Reproduce</b> — confirm it against the real code, no external accounts.</li>
<li><b>Fix</b> — one actor (the doer) writes the change and a regression test.</li>
<li><b>Verify</b> — a <b>different</b> actor reproduces from scratch and tries to refute the fix against ground truth.</li>
<li><b>Close</b> — only after verification. The doer can never close its own work.</li>
</ul>
</div>
<div class="mcard">
<h3>What we count — and why catches lead</h3>
<ul>
<li><b>Verifier catches</b> — work that would have shipped wrong. The number that proves the discipline.</li>
<li><b>Self-closes: 0</b> — an invariant, enforced by actor identity, not an outcome.</li>
<li><b>Merges</b> — a contributor metric, tracked but not the point.</li>
<li><b>Refutes</b> — the same hostile pass pointed at other agents’ green PRs; posted only when the break reproduces deterministically, dropped silently when someone else surfaced it first.</li>
<li>Scope is honest: bugs needing a live cloud account are out of scope, not failures.</li>
<li>We do <b>not</b> spam PRs — we verify privately and open only clean ones.</li>
</ul>
</div>
</div>
<div class="honest"><b>Known limitation we're fixing next:</b> today the doer and verifier are independent sessions of the same model. The next step is cross-model verification — one model does, a different model verifies — to turn "independent session" into "independent intelligence."</div>
</section>
<div class="divider"></div>
<section class="wrap">
<div class="sec-tag"><span class="num">NEXT</span> queued targets</div>
<div class="method-grid">
<div class="mcard">
<h3>On deck</h3>
<ul class="next">
<li><b>The fresh-bug vein:</b> git-machete, szio and superfile were all found the same way — a user-reported bug <span class="em">hours old</span> in a moderately-popular repo, race-checked immediately. szio went from a stranger’s report to merged upstream in six hours. That beats mining <code>help wanted</code> backlogs, which attract contributor crowds; we’ve retired the help-wanted-first advice that used to sit here.</li>
<li><b>Maintainer-filed audit items</b> are a second vein worth working: QuantEcon’s <code>#870</code> arrived with acceptance criteria attached — an invitation rather than a race, and a clear signal the fix is wanted.</li>
<li><b>Proven-friendly repos first:</b> maintainers who’ve merged our work (fastmcp, gson, buildtools, tenacity, croniter, tomlkit — and now the Sollumz org) get scouted before strangers. Landing odds are part of the scouting gate.</li>
<li><b>A do-not-post list, honored:</b> some projects (pallets/*, servo/*) have said no to AI contributions. We don’t post there — reproducibility doesn’t override a maintainer’s policy.</li>
<li><b>Refute runs, retired 07-27.</b> This line used to say “more refute runs.” Five were posted and none produced a clean win. On <code>sqlfluff</code> #8201 the author acted on our finding and pushed a commit named after it — then a contributor labelled the whole thread <code>possible bot</code> and closed it. A correct refutation dropped into an agent-versus-agent thread adds volume to the exact signal maintainers are learning to dismiss. The analysis is still worth doing; posting it into a cold thread is not. Left here rather than deleted, because a page that quietly edits out its retired bets is not evidence of anything.</li>
<li><b>A liveness check before the cycle, added 07-27.</b> Judge a repo by its last <em>merged</em> pull request from a human, not by stars. We spent a full run on a 4,800-star library that had not merged anything in eight months. The finding was real; the audience was not there.</li>
</ul>
</div>
<div class="mcard">
<h3>The claim, stated plainly</h3>
<ul>
<li><b style="color:var(--ok)">Five merged</b> — Google/Bazel core tooling (<code>buildtools</code>), the FastMCP auth layer (same-day merge, issue reporter endorsing the fix), <code>google/gson</code> (a Google maintainer merged it after running Google’s full internal test suite), <code>szio</code> (merged six hours after the bug was filed), and <code>git-machete</code> (merged 07-27 after four rounds of review across nine commits, with a collaborator invite partway through). Eleven more in review, including <code>croniter</code>, where a Pallets-eco maintainer diffed 8,012 schedule expansions himself before approving in principle. Real maintainers reviewed and accepted Coretexa-verified fixes. Distribution, not just verification.</li>
<li>Twenty fix runs. The first twelve carry the full write-ups: <b>eleven verifier catches</b> — three false-green test suites (rust-url, szio, QuantEcon), a mis-parsed binary header eating 1.36GB, an un-reloadable "fix", a locale-dependent encoding crash, overstated evidence, an overstated blast radius, a misstated regression scope — <b>and one honest first-pass-correct</b> run, reported as such.</li>
<li><b style="color:var(--amber)">One run shipped without the verifier, and it is on the record.</b> Run 20 (<code>go-humanize</code>) was found, fixed and posted in a session that never opened the queue. The mechanical revert-check passed, which proves only that the tests gate the change — not that the change is right. The database refused to file it as posted, because the schema will not accept posted-and-unverified. It sits unverified until two hostile verifiers have run. We would rather show you a constraint catching us than a counter that never moves.</li>
<li><b>Twice the verifier caught our own tests, not our code</b> — a green suite that cannot fail is worth nothing, so a fix ships only once its test has proven it can fail.</li>
<li><b>Five bot PRs refuted</b> — each one green in CI and cleared by its AI reviewers before our verifier broke it with a deterministic repro. One refute was ignored and merged anyway; it became a public issue with a seeded-crash regression recipe the same day.</li>
<li>Across TypeScript, Python, Rust, Go, and Java — including GitHub’s own <code>gh</code> CLI, the MCP reference SDK, Google’s gson, and the FastMCP auth layer. The check isn’t tied to one stack.</li>
<li>The value isn't "AI wrote a patch." It's <b>a second actor stopped a bad one from closing</b> — and, when there was nothing to stop, said so.</li>
</ul>
</div>
</div>
</section>
<div class="divider"></div>
<footer>
<div class="foot-in">
<span><b style="color:var(--white);letter-spacing:.12em">CORETEXA</b> <span class="dot">·</span> coretexa.dev</span>
<span>MIT <span class="dot">·</span> 2026 <span class="dot">·</span> the agent that does the work can't close it</span>
<a href="https://github.com/earfman/coretexa-verify" target="_blank" rel="noopener">GitHub →</a>
</div>
</footer>
<script>
(function(){var nav=document.getElementById('nav'),tog=document.getElementById('navToggle');if(tog){tog.addEventListener('click',function(){nav.classList.toggle('open');});}})();
</script>
</body>
</html>