Jag inkluderade miniatyrversionen av denna prompt här eftersom serien "My Favorite Prompts" ska vara kompakta, bitstora och självständiga nuggets. Men idag förvandlade jag detta till ett verkligt galet system. Det är inte relevant om du gör ett annat CRUD-program i React eller en TODO-lista, men om du gör något ganska komplicerat i Rust eller Golang, eller något som involverar komplex data, är detta tillvägagångssätt nästan skrämmande i vad det kan göra. Det är en process med två omgångar. Här är omgång 1: --- Läs först ALLA AGENTS dot md-filer och README dot md-filer supernoggrant och förstå ALLA av båda! Använd sedan ditt kodundersökningsagentläge för att fullt ut förstå koden, den tekniska arkitekturen och syftet med projektet. När du sedan har gjort ett extremt grundligt och noggrant jobb med allt detta och djupt förstått hela det befintliga systemet och vad det gör, dess syfte, hur det implementeras och hur alla delar hänger ihop, behöver jag att du hyperintensivt undersöker, studerar och grubblar över dessa frågor som rör detta projekt: Finns det några andra grova ineffektiviteter i kärnsystemet? platser i kodbasen där 1) ändringar faktiskt skulle påverka den totala latens/responsiviteten och genomströmningen; 2) sådana att våra förändringar skulle vara bevisbart isomorfa vad gäller funktionalitet så att vi säkert skulle veta att det inte skulle ändra de resulterande utgångarna givet samma indata; 3) där du har en tydlig vision för en uppenbart bättre metod när det gäller algoritmer eller datastrukturer (notera att du för detta kan inkludera mindre kända datastrukturer och mer esoteriska/sofistikerade/matematiska algoritmer i dina överväganden samt sätt att omformulera problemet/problemena så att ett annat paradigm exponeras, som listan nedan (Observera: Innan du föreslår någon optimering, fastställ baslinjemått (p50/p95/p99 latens, genomströmning, peak memory) och fånga CPU-/allokerings-/I/O-profiler för att identifiera faktiska hotspots): - N+1 eliminering av förfrågare/hämta-mönster - nollkopiering / buffertåteranvändning / spridningsinsamling I/O - kostnader för serialiseringsformat (parse/kodningsöverhead) - begränsade köer + backtryck (förhindrar minnesexplosion och svanslatens) - sharding / randiga lås för att minska konkurrens - memoisering med strategier för cache-invalidering - dynamiska programmeringstekniker - konvex optimeringsteori - lat utvärdering / uppskjuten beräkning - iterator-/generatormönster för att undvika att materialiserar stora samlingar - strömmande/chunked processing för minnesbegränsat arbete - förberäknings- och uppslagstabeller - indexbaserad uppslagning vs linjär skanningsigenkänning - binär sökning (på data och på svarutrymme) - tvåpoängs- och skjutfönstertekniker - prefixsummor / kumulativa aggregat - topologisk sortering och DAG-medvetenhet för beroendegrafer - cykeldetektion - union-find för dynamisk koppling - graftraversering (BFS/DFS) med tidig avslutning - Dijkstras / A* för viktade kortaste vägar - prioritetsköer / heaps - försöker för prefixoperationer - Bloom-filter för probabilistiskt medlemskap - intervall-/segmentträd för intervallfrågor - rumslig indexering (k-d-träd, quadtrees, R-träd) - bestående/oföränderliga datastrukturer - copy-on-write-semantik - objekt-/anslutningspoolning - val av cache-vräkningspolicy (LRU/LFU/ARC) - batchmedveten algoritmval - asynkron I/O-batchning och koalescensering - låsfria strukturer för högkonkurrensscenarier - arbetsstöld för rekursiv parallellism - minneslayoutoptimering (SoA vs AoS, cachelokalitet) - kortslutning och tidig avslutning - stränginternering för upprepade värden - amortiserad analys med hänsyn till dessa allmänna riktlinjer där det är tillämpligt: DP-tillämplighetskontroller: - Överlappande delfrågor? → memoize med stabil statusnyckel - Optimal partitionering/batchning? → prefixsummor + intervall DP - Beroendegraf med upprepad traversering? → enkelpass-topologisk DP KONVEXA OPTIMERINGSKONTROLLER: - Att brute-forcera exakt fördelning/schemaläggning? → LP / min-kostnadsflöde med deterministisk tie-breaking - Kontinuerlig parameteranpassning med explicit förlust? → regulariserade minsta kvadrater / QP - Stort dekomponerbart konvext objektiv? → ADMM / proximala metoder Observera också att om det finns välskrivna tredjepartsbibliotek du känner till som skulle fungera bra, kan vi inkludera dem i projektet. METODIKKRAV: A) Baslinje först: Kör testsviten och en representativ arbetsbelastning; Spela in P50/P95/P99 latens, genomströmning och peak memory med exakta kommandon. B) Profil innan förslag: Fånga CPU + allokering + I/O-profiler; Identifiera de 3–5 vanligaste hotspots efter % tid innan du föreslår förändringar. C) Ekvivalensorakel: Definiera explicita gyllene utgångar + invarianter. För stora indatautrymmen, lägg till egenskapsbaserade eller metamorfa tester. D) Isomorfibevis per förändring: Varje föreslagen diff måste innehålla en kort bevisskiss som förklarar varför utdata inte kan ändras (inklusive ordning, tie-breaking, flyttalsbeteende och RNG-frön). E) Möjlighetsmatris: Rangordna kandidater efter (Påverkan × Självförtroende) / Ansträngning innan genomförande; Fokusera bara på föremål som sannolikt kommer att röra sig på p95+ eller genomströmning meningsfullt. F) Minimala skillnader: En prestandaspak per byte. Inga orelaterade refaktoreringar. Inkludera riktlinjer för rollback om det finns någon risk. G) Regressionsräcken: Lägg till referenströsklar eller övervakningskrokar för att förhindra framtida regressioner. Använd ultrathink. --- Du kan köra det en gång i Claude Code med Opus 4.5 och en gång i Codex med GPT 5.2 Codex (jag började använda bara High eftersom Extra High är för långsamt för mig om jag inte ska gå och lägga mig). När de är klara, ge dem var och en ungefär 5 snabba rundor av den här: "Toppen. Gå igenom allt igen för uppenbara förbiseende, utelämnanden eller misstag, konceptuella fel, misstag, etc. Använd ultrathink" Låt dem sedan spara utgångarna så här: "Okej, spara allt det där som PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "Okej, spara allt det där som PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Sedan gör du i Claude Code: "Jämför vad du gjorde med PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md och ta de bästa elementen från det och väv in dem i din plan för att få en hybrid av bästa av två världars överlägsna plan genom att redigera din ursprungliga planfil på plats." Sedan detta: Läs om AGENTS dot md så att det fortfarande är färskt i minnet. Läs nu HELA PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Sedan kollar du varje pärla väldigt noggrant-- är du säker på att det är vettigt? Är det optimalt? Skulle vi kunna ändra något för att få systemet att fungera bättre för användarna? Vi vill ha en omfattande och detaljerad uppsättning pärlor för allt detta med uppgifter, deluppgifter och beroendestruktur överlagrade, med detaljerade kommentarer så att hela processen blir helt självständig och självdokumenterande (inklusive relevant bakgrund, resonemang/motivering, överväganden osv. – allt vi vill att vårt "framtida jag" ska veta om målen, intentionerna och tankeprocessen och hur det tjänar projektets övergripande mål). Pärlorna ska vara så detaljerade att vi aldrig behöver gå tillbaka till det ursprungliga markdown-plandokumentet. Speglar den HELA markdown-planen korrekt på ett heltäckande sätt? Om ändringar är motiverade, revidera pärlorna eller skapa nya eller stäng ogiltiga eller ogiltiga. Det är mycket enklare och snabbare att arbeta i "planutrymme" innan vi börjar implementera dessa saker! FÖRENKLA INTE SAKER FÖR MYCKET! FÖRLORA INGA FUNKTIONER ELLER FUNKTIONER! Se också till att vi som en del av dessa beads inkluderar omfattande enhetstester och e2e-testskript med utmärkt, detaljerad loggning så att vi kan vara säkra på att allt fungerar perfekt efter implementeringen. Kom ihåg att ENDAST använda 'bd'-verktyget för att skapa och modifiera pärlorna och för att lägga till beroendena till pärlorna." Sedan några omgångar av: "Kolla varje pärla supernoga – är du säker på att det är vettigt? Är det optimalt? Skulle vi kunna ändra något för att få systemet att fungera bättre för användarna? Om så är fallet, revidera pärlorna. Det är mycket enklare och snabbare att arbeta i "planutrymme" innan vi börjar implementera dessa saker! FÖRENKLA INTE SAKER FÖR MYCKET! FÖRLORA INGA FUNKTIONER ELLER FUNKTIONER! Se också till att vi som en del av kulorna inkluderar omfattande enhetstester och e2e-testskript med utmärkt, detaljerad loggning så att vi kan vara säkra på att allt fungerar perfekt efter implementeringen. Använd ultrathink." Släpp sedan loss svärmen för att genomföra allt. Gör dig sedan redo för RUNDA 2.