Vlak pull requestů je typovaný objekt, který lze vidět

138. Train pull requestů je typovaný objekt, který lze vidět

Kontext

Pull requesty v tomto repozitáři jsou často naskládané: změna se rozdělí na články, každý stojí na tom pod ním, a vlak přistává odspodu nahoru. Executor hrany už zná. Klasifikátor čte každý řádek Stacked on #N a Depends on #N a každou základní větev, která je headem jiného otevřeného pull requestu, do potvrzených závislostí a uvádí důvody jako stacked_on:#807 a depends_on:#883. Executor také připravuje další head každého článku před jeho řadou a drží jej v lokálním refu refs/prep/<n>, a pushne jej, až když článek přijde na řadu.

Nic z toho netvořilo objekt, který by si kdokoli mohl přečíst. Které pull requesty tvoří vlak, který článek přistane příště, které připravené heady jsou stále nepushnuté a o kolik je každý článek za masterem, bylo známo jen ze zpráv relací a z lokálních refů, které žádná jiná relace neviděla. Za jeden večer se dvě relace navzájem ptaly na pořadí týchž jedenácti článků. prs status ukazuje jeden pull request naráz, seřazený frontou, a pořadí fronty není pořadí vlaku: horní článek se řadí před dolní článek, na který čeká, kdykoli je méně rizikový.

Vlastník dne 2026-10-11 požádal o interaktivní, podrobnou vizualizaci trainu ve stylu Neo4j Browseru.

Rozhodnutí

1. Vlak se odvozuje, nikdy nedeklaruje. crate::integration::train počítá vlaky ze tří věcí, které checkout už má: fronty (queue_of, ze zaznamenaného pozorování), těl a kontrol v tomto pozorování a refů refs/prep/. Vlak je souvislá komponenta otevřených pull requestů podle jejich potvrzených vzájemných závislostí, spolu s každým otevřeným pull requestem, který vůbec deklaruje závislost. Článek, jehož nižší články už přistály, je stále zbytkem svého vlaku, přičemž tyto pull requesty jsou pod ním. Odvozené závislosti (head, který jen obsahuje jiný) jsou důkaz a nic nespojují, jako v klasifikátoru.

2. Pořadí je pořadím vlaku, ne fronty. Články se řadí topologickým řazením, nižší články první, shody se rozhodují pořadím ve frontě. Články zachycené v cyklu jdou nakonec a jsou označeny, cyklus se hlásí. Každý článek nese své position, své depth od masteru, zda je at_turn (každá jím deklarovaná závislost přistála), na čem stojí on a co carries. Každý vlak nese svůj roots, tops a next článek.

3. Hrana říká, jak je deklarována. Stack podle základní větve nebo řádek Stacked on je STACKED_ON; Depends on, Requires a Land after jsou DEPENDS_ON. Hrana je satisfied, když pull request pod ní byl mergnut.

4. Připravený head se porovnává, nikdy nepřesouvá. refs/prep/<n> se čte pomocí git for-each-ref. Připravený head článku je pushed, když je to head, který forge servíruje, a pending jinak. Připravený head, jehož pull request není článkem, se uvede jako nepřipojený. Nic v tomto modelu nefetchuje, nepushuje ani nezapisuje ref a push na řadě článku zůstává aktem executoru.

5. Jedna schopnost, každý povrch. integration.trains je deklarováno jednou s capability! a promítnuto do majordomus prs trains (text a --format json), GET /api/v1/pull-requests/trains a MCP majordomus_pull_request_trains. Jako zbytek modulu je jen pro čtení a offline.

6. Cockpit ho kreslí a vypisuje. /cockpit/trains vykresluje jednu tabulku na train, která nepotřebuje JavaScript, se stejnými fakty. share/cockpit/trains.js přidává kresbu v Cytoscape v duchu Neo4j Browseru: master jako kotvící uzel, kulaté uzly s popiskem uvnitř, barvené podle určení z deklarovaných rolí stavu a tónu (nikdy barevným literálem), popsané orientované vztahy, silové nebo vrstvené rozvržení, tažení, zoom, posun, rozsvícení sousedů uzlu pod ukazatelem, panel vlastností, filtry podle trainu a určení, hledání a navigace klávesnicí. Pohyb se řídí prefers-reduced-motion. Stejnou trasu HTTP dotazuje jednou za minutu, dokud je karta viditelná, a ukazuje, kdy se naposledy ptala. Žádný stream se pro něj nevymýšlí.

Důsledky

• Co je vlak, co přistane příště a které připravené heady čekají na svou řadu, může číst kterákoli relace, člověk nebo nástroj ze stejné odpovědi, aniž by to musela nést zpráva mezi relacemi.
• Kresba a tabulka se nemohou rozcházet, protože obě vykreslují odpověď jedné schopnosti a ta schopnost je tatáž hodnota, kterou vypisuje příkazová řádka (případ 1072).
• Každá odpověď znovu rozhoduje vztah každého odkazu k masteru, což na vytíženém stroji trvá vteřiny. Stránka proto dotazuje jednou za minutu a nikdy, dokud je dotaz ještě venku. Cachovaná odpověď by byla samostatné rozhodnutí.
• Slovo vztahu carries_master (ADR 0129) se čte ze serializovaného druhu vztahu, takže model funguje na spustitelném souboru s tímto vztahem i bez něj a hlásí false, kde není znám.
• Odkaz na forge je odkaz GitHubu, protože executor pozoruje forge přes CLI GitHubu a nic jiného.

Zamítnuté alternativy

• Deklarování trains v souboru. Byl by to druhý záznam toho, co už deklarují těla a základní větve, a zastaral by ve chvíli, kdy by se odkaz přesměroval.
• Řazení trainu podle pořadí ve frontě. Pořadí odpovídá na „co je nejbezpečnější udělat dál“, ne na „co na čem stojí“. Ukázané jako pořadí trainu by dalo horní článek před článek, na který čeká.
• Proud pro stránku. Relace 1b vlastní majordomus monitor (I2400 až I2407). Dotazování existující trasy nic nevymýšlí a degraduje na tabulku renderovanou serverem.
• Rozšíření rozvržení pro Cytoscape. Cockpit vendoruje cytoscape.min.js a nic jiného a jeho content-security policy nejmenuje žádný vzdálený původ. Vestavěné cose je silové rozvržení a breadthfirst z masteru dává vrstvený pohled.