Sisällytin tähän pienen version tästä kehotteesta, koska "My Favorite Prompts" -sarjan pitäisi olla kompakteja, puremakokoisia, itsenäisiä nuggetteja. Mutta tänään muutin tämän todella hulluksi järjestelmäksi. Se ei ole relevanttia, jos teet toista CRUD-ohjelmaa Reactissa tai TODO-listaa, mutta jos teet jotain melko monimutkaista Rustissa tai Golangissa tai jotain monimutkaista dataa sisältävää, tämä lähestymistapa on melkein pelottava siinä, mitä se voi tehdä. Se on kahden kierroksen prosessi. Tässä on ensimmäinen kierros: --- Lue ensin KAIKKI AGENTS dot md -tiedostot ja README dot md -tiedostot todella tarkasti ja ymmärrä KAIKKI molemmat! Käytä sitten kooditutkimusagenttitilaa ymmärtääksesi täysin koodin, teknisen arkkitehtuurin ja projektin tarkoituksen. Kun olet tehnyt erittäin perusteellisen ja huolellisen työn kaiken tämän parissa ja ymmärtänyt syvällisesti koko olemassa olevan järjestelmän ja sen tarkoituksen, toteutuksen ja miten kaikki osat liittyvät toisiinsa, tarvitsen sinun hyperintensiivisesti tutkivan, tutkivan ja pohtimaan näitä kysymyksiä tämän projektin yhteydessä: Onko ydinjärjestelmässä muita törkeitä tehottomuuksia? Koodipohjan kohdat, joissa 1) muutokset oikeasti siirtäisivät kokonaisviiveen, reagoivuuden ja läpimenon kannalta; 2) siten, että muutoksemme olisivat toiminnallisuudeltaan todistettavasti isomorfisia, jotta tietäisimme varmasti, ettei se muuttaisi tuloksia samoilla syötteillä annettuna; 3) missä sinulla on selkeä visio selvästi paremmasta lähestymistavasta algoritmien tai tietorakenteiden osalta (huomaa, että tähän voit sisällyttää pohdintoihisi vähemmän tunnettuja tietorakenteita ja erikoisempia/kehittyneempiä/matemaattisia algoritmeja sekä tapoja muotoilla ongelma uudelleen niin, että toinen paradigma paljastuu, kuten alla esitetty lista (Huomautus: Ennen optimoinnin ehdottamista määritä lähtömittarit (p50/p95/p99 viive, läpäisy, huippumuisti) ja tallenna CPU/allokointi/I/O-profiilit todellisten hotspottien tunnistamiseksi): - N+1 kysely-/hakukuvion poisto - nollakopioi / puskurin uudelleenkäyttö / scatter-gather I/O - sarjoittamismuotojen kustannukset (jäsennys/koodauskuorma) - rajoitetut jonot + vastapaine (estää muistin räjähtämisen ja hännän viiveen) - sirpaleiset / raidalliset lukot kilpailun vähentämiseksi - muistinkäyttö välimuistin mitätöintistrategioilla - dynaamiset ohjelmointitekniikat - konveksi optimointiteoria - laiska arviointi / viivästetty laskenta - iteraattori-/generaattorimallit, jotta suurten kokoelmien ei muodostuisi - suoratoisto/chunked-prosessointi muistirajoitetussa työssä - esilaskenta- ja hakutaulukot - Indeksipohjainen haku vs lineaarinen skannaustunnistus - binäärihaku (datassa ja vastaustilassa) - kaksipiste- ja liukuikkunatekniikat - etuliitesummat / kumulatiiviset aggregaatit - topologinen lajittelu ja DAG-tietoisuus riippuvuusgraafeille - syklin tunnistus - union-find dynaamiselle yhteydelle - graafin läpikäynti (BFS/DFS) varhaisella päättymisellä - Dijkstran / A* painotetuille lyhyimmille poluille - prioriteettijonot / kenot - yritykset etuliiteoperaatioille - Bloom-suodattimet todennäköisyyspohjaiseen jäsenyyteen - väli-/segmenttipuut etäisyyskyselyille - spatiaalinen indeksointi (k-d-puut, kvadripuut, R-puut) - pysyvät/muuttumattomat tietorakenteet - kopioi-kirjoitussemantiikka - objekti/yhteyspoolaus - välimuistin häätöpolitiikan valinta (LRU/LFU/ARC) - erätietoinen algoritmin valinta - asynkroninen I/O-eräys ja yhdistyminen - lukitsemattomat rakenteet korkean kilpailun skenaarioihin - työn varastaminen rekursiivisessa rinnakkaisuudessa - muistin asettelun optimointi (SoA vs AoS, välimuistin lokaliteetti) - oikosulku ja varhainen päättäminen - merkkijonojen harjoittelu toistuville arvoille - amortisoitu analyysipäättely Ottaen huomioon nämä yleiset oppaat, jos sovellettavissa: DP:N SOVELTUVUUSTARKISTUKSET: - Päällekkäisiä alaongelmia? → memoisoi vakaalla tilaavaimella - Optimaalinen osiointi/eräys? → etuliitteen summat + intervalli DP - Riippuvuuskäyrä, jossa on toistuva kulku? → yksivaiheinen topologinen DP KONVEKSIN OPTIMOINTITARKISTUKSET: - Pakottamalla tarkkaa allokointia/aikataulutusta? → LP / minimikustannusvirta deterministisellä tie-breakingillä - Jatkuva parametrisovitus eksplisiittisellä häviöllä? → säännölliset pienimmät neliösummat / QP - Suuri hajottava konveksi objektiivi? → ADMM / proksimaaliset menetelmät Huomaa myös, että jos tiedät hyvin kirjoitettuja kolmannen osapuolen kirjastoja, jotka toimisivat hyvin, voimme sisällyttää ne projektiin. METODOLOGIAN VAATIMUKSET: A) Lähtötaso ensin: Suorita testipaketti ja edustava työkuorma; Tallenna P50/P95/P99 viive, läpimenokyky ja huippumuisti täsmällisillä komennoilla. B) Profiili ennen ehdotusta: Capture CPU + allokaatio + I/O-profiilit; Tunnista 3–5 tärkeintä hotspottia % ajan mukaan ennen muutosten ehdottamista. C) Ekvivalenssiorakkeli: Määritellään eksplisiittiset kultaiset ulostulot + invariantit. Suurille syötetiloille lisää ominaisuuspohjaiset tai metamorfiset testit. D) Isomorfismitodistus per muutos: Jokaisessa ehdotetussa differentiaalissa on oltava lyhyt todistusluonnos, joka selittää, miksi tulosteet eivät voi muuttua (mukaan lukien järjestys, tasapeliratkaisu, liukulukukäyttäytyminen ja satunnaisuuden siemenet). E) Mahdollisuuksien matriisi: Arvioi ehdokkaat (Vaikutus × Itseluottamus) / Ponnistelun mukaan ennen käyttöönottoa; Keskity vain kohteisiin, jotka todennäköisesti siirtävät P95+:ta tai läpimenoa merkittävästi. F) Minimidifferentiteet: Yksi suorituskykyvipu per muutos. Ei mitään irrallista refaktorointia. Sisällytä palautusohjeistus, jos riskiä on olemassa. G) Regressiokaiteet: Lisää vertailukynnysarvoja tai seurantakoukkuja tulevien regressioiden estämiseksi. Käytä ultrathinkia. --- Voit ajaa sen kerran Claude Codessa Opus 4.5:llä ja kerran Codexissa GPT 5.2 Codexilla (aloin käyttää vain Highia, koska Extra High on minulle liian hidas, ellei ole menossa nukkumaan). Kun he ovat valmiita, lyö kutakin noin viidellä nopealla kierroksella tästä: "Hienoa. Käy kaikki uudelleen läpi mahdollisten ilmeisten laiminlyöntien tai virheiden, käsitteellisten virheiden, virheiden ym. varalta. Käytä ultrathinkia" Sitten pyydä heitä tallentamaan ulostulot näin: "OK, säästä kaikki tuo PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md:ksi" "OK, säästä kaikki tuo PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md:ksi" Sitten Claude-koodissa tehdään: "Vertaa mitä teit PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md:hen ja ota siitä parhaat elementit ja punoo ne suunnitelmaasi saadaksesi hybridin paras molempien maailmojen paremman suunnitelman muokkaamalla alkuperäistä suunnitelmatiedostoasi." Sitten tämä: Lue AGENTS dot MD uudelleen, jotta se pysyy tuoreena mielessäsi. Lue nyt KOKO PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Sitten tarkista jokainen helmi todella huolellisesti – oletko varma, että se on järkevää? Onko se optimaalista? Voisimmeko muuttaa jotain, jotta järjestelmä toimisi paremmin käyttäjille? Haluamme kattavan ja yksityiskohtaisen kokoelman helmiä kaikkeen tähän, jossa on tehtäviä, alatehtäviä ja riippuvuusrakennetta, yksityiskohtaisia kommentteja, jotta kokonaisuus on täysin itsenäinen ja itsedokumentoitu (mukaan lukien asiaankuuluva tausta, päättely/perustelut, harkinnat jne. – kaikki, mitä haluaisimme "tulevan minämme" tietävän tavoitteista, aikomuksista ja ajatteluprosessista sekä siitä, miten ne palvelevat projektin päämääriä). Helmien tulisi olla niin yksityiskohtaisia, ettei meidän koskaan tarvitse palata alkuperäiseen alennussuunnitelmaan. Kuvaako se tarkasti KOKO markdown-suunnitelmatiedoston kattavalla tavalla? Jos muutoksia tarvitaan, päivitä helmet tai luo uudet tai sulje virheettömät tai kelvottomat vaihtoehdot. On paljon helpompaa ja nopeampaa toimia "suunnittelutilassa" ennen kuin alamme toteuttaa näitä asioita! ÄLÄ YKSINKERTAISTA ASIOITA LIIKAA! ÄLÄ MENETÄ MITÄÄN OMINAISUUKSIA TAI TOIMINNALLISUUTTA! Varmista myös, että näihin helmiin sisällytämme kattavat yksikkötestit ja e2e-testiskriptit sekä yksityiskohtaiset lokituskirjaukset, jotta voimme olla varmoja, että kaikki toimii täydellisesti käyttöönoton jälkeen. Muista käyttää VAIN 'bd'-työkalua helmien luomiseen ja muokkaamiseen sekä helmien riippuvuuksien lisäämiseen." Sitten muutama kierros: "Tarkista jokainen helmi todella huolellisesti – oletko varma, että se on järkevää? Onko se optimaalista? Voisimmeko muuttaa jotain, jotta järjestelmä toimisi paremmin käyttäjille? Jos on, tarkista helmet. On paljon helpompaa ja nopeampaa toimia "suunnittelutilassa" ennen kuin alamme toteuttaa näitä asioita! ÄLÄ YKSINKERTAISTA ASIOITA LIIKAA! ÄLÄ MENETÄ MITÄÄN OMINAISUUKSIA TAI TOIMINNALLISUUTTA! Varmista myös, että helmiin sisältyy kattavat yksikkötestit ja e2e-testiskriptit sekä laadukkaat, yksityiskohtaiset lokitukset, jotta voimme olla varmoja, että kaikki toimii täydellisesti käyttöönoton jälkeen. Käytä ultrathinkia." Sitten anna parven päästä irti toteuttaaksesi kaiken. Sitten valmistaudu KIERROKSEEN 2.