Voorstellen en validatie
Overzicht
Wanneer ElevenAgents Architect een wijziging heeft voltooid, levert het die aan je als een voorstel: een branch die de wijziging bevat, tests die aantonen dat deze werkt, en een merge proposal met het verzoek om die branch samen te voegen met main. Op deze pagina lees je hoe elk onderdeel werkt, waar je het vindt en hoe een voorstel van een gesprek naar live verkeer gaat.
Wat een voorstel is
Een voorstel is gebaseerd op het bestaande versioning-model:
De merge proposal is een standaardmerge proposal van ElevenAgents, hetzelfde type dat een teamgenoot handmatig opent. Het is geen afzonderlijk objecttype.
Een merge proposal omvat precies één bronbranch en één doelbranch, dus één voorstel bevat één kandidaatoplossing. Om alternatieven te vergelijken, vraag je Architect om elk alternatief op een eigen branch te zetten. Elke branch krijgt dan een eigen voorstel en je kunt het verkeer ertussen verdelen als een experiment.
Architect handelt namens jou, dus een merge proposal die het opent, wordt onder jouw naam als auteur geregistreerd. Er is geen veld dat vastlegt dat Architect deze heeft gemaakt. Vermeld het in de voorstelbeschrijving als je team dat wil weten.
Hoe een voorstel wordt gemaakt
Architect maakt een voorstel wanneer je het vraagt iets te repareren of te verbeteren, of wanneer je het een mislukte test, een Spotlight-bevinding of een issue geeft. De volledige volgorde, inclusief de tools die Architect bij elke stap aanroept, staat in het uitgewerkte voorbeeld. Kort samengevat:
- Architect onderzoekt, maakt een branch en zet de wijziging klaar in je concept op die branch.
- Architect schrijft tests en simulaties voor de wijziging en voert ze uit in het gesprek voordat het je het resultaat toont.
- Architect opent het publicatievenster. Je controleert de diff en selecteert Publiceren, waarmee de wijziging als een nieuwe versie op de branch wordt vastgelegd.
- Architect opent een merge proposal naar
mainen schrijft de beschrijving op basis van de daadwerkelijke commits en testuitvoeringen van de branch. - Architect biedt aan om tijdens de beoordeling van het voorstel een klein deel van het live verkeer naar de branch te sturen. Hiervoor is je goedkeuring nodig.
Je kunt bij elke stap stoppen. Een branch met een gepubliceerde versie maar zonder merge proposal is nog steeds nuttig: je kunt deze zelf testen of later een voorstel openen.
Validatie binnen het gesprek
Architect schrijft en voert tests uit als onderdeel van het maken van de wijziging, niet als een afzonderlijke stap die je achteraf start. Voor een oplossing is een nuttig patroon om te tonen dat de nieuwe tests zonder de wijziging mislukken en ermee slagen. Architect kan dezelfde tests uitvoeren op de oorspronkelijke branch en op het concept dat de wijziging bevat.
Architect voert deze voor-en-nacontrole niet automatisch uit bij elke wijziging. Vraag erom wanneer het belangrijk is, bijvoorbeeld: “Toon me de nieuwe simulatie die mislukt op main en slaagt op de branch, en open daarna een voorstel.”
Een test slaagt wanneer aan elke succesvoorwaarde is voldaan. Bij een LLM-test voldoet het antwoord van de agent aan de succescriteria. Bij een tool-calltest wordt de verwachte tool aangeroepen met de verwachte parameters. Bij een simulatie voldoet het gesimuleerde gesprek aan de succesvoorwaarden. Vraag Architect om tests meerdere keren uit te voeren om te controleren op wisselvallige resultaten. Het kan elke test maximaal 50 keer herhalen en het slagingspercentage rapporteren.
Zie Testing voor de definitie van elk testtype.
Waar je voorstellen vindt
Open de agent en ga vervolgens naar Version Control > Proposals. Je kunt de lijst filteren op status, auteur (Created by) en reviewer (Awaiting review from, Reviewed by). Een voorstel dat Architect in je gesprek heeft geopend, wordt vermeld met jou als auteur.
Architect geeft ook een link naar het voorstel terug in het gesprek zodra het dit maakt.
Opbouw van een voorstel
De pagina van een voorstel toont de bron- en doelbranches, de status, of het kan worden samengevoegd en hoeveel de bronbranch achterloopt op of voorloopt op de doelbranch. Deze bevat de volgende tabbladen:
Overzicht
Wijzigingen
Testuitvoeringen
Gesprekken
De beschrijving, een activiteitentijdlijn met commits op de bronbranch, reviews en opmerkingen, en een opmerkingenveld. De zijbalk toont reviewers, aanbevolen reviewers en eventuele gekoppelde issues.
Een beschrijving die Architect schrijft, heeft altijd drie secties: Samenvatting (elke betekenisvolle wijziging en waarom), Testen (welke tests zijn uitgevoerd en de resultaten, of de vermelding dat er geen zijn uitgevoerd) en Hoe te beoordelen (waar je op moet letten en een test om uit te voeren of gesprek om te proberen).
Beoordelen en samenvoegen
Statussen
Een merge proposal heeft een van deze statussen:
Zolang een voorstel open is, is de meest recente review van elke reviewer Goedgekeurd of Wijzigingen gevraagd. Er zijn geen afzonderlijke statussen voor “getest” of “klaar voor beoordeling”. Testresultaten worden in plaats daarvan getoond op het tabblad Testuitvoeringen.
Reviews en opmerkingen verschijnen in de activiteitentijdlijn op het tabblad Overzicht, naast elke nieuwe versie die op de bronbranch is vastgelegd.
Wie kan goedkeuren en samenvoegen
- Iedereen met editortoegang tot de agent kan een voorstel beoordelen, behalve de auteur. Omdat Architect namens jou handelt, kun je een voorstel dat Architect in je gesprek heeft geopend niet goedkeuren. Dat moet een teamgenoot doen.
- Een voorstel kan worden samengevoegd zodra het minstens één goedkeuring heeft van iemand anders dan de auteur en de meest recente review van geen enkele reviewer Wijzigingen gevraagd is. Workspacebeheerders kunnen zonder goedkeuring samenvoegen.
- Samenvoegen met een beschermde branch vereist beheerdersrechten of een goedkeuring van een beheerder.
Architect kan een merge proposal niet goedkeuren, van opmerkingen voorzien, samenvoegen of sluiten. Deze stappen worden altijd door mensen uitgevoerd. Zie Merge proposals voor de volledige reviewregels.
Architect kan een branch rechtstreeks samenvoegen, zonder voorstel, wanneer je het daarom vraagt en je rol
de merge toestaat. In de modus Goedkeuring vereist vraagt het eerst toestemming. In de modus Automatisch goedkeuren doet het dat niet. Gebruik
branchbescherming op main als elke wijziging via een beoordeeld voorstel moet gaan.
Wat er gebeurt bij samenvoegen
Na een merge is geen afzonderlijke publicatiestap nodig. Samenvoegen schrijft een nieuwe versie op de doelbranch en die versie bedient direct live verkeer voor het aandeel verkeer dat het doel ontvangt. Wanneer het doel main is en er geen verkeersverdeling is ingesteld, betekent dat alle bellers.
Samenvoegen doet ook het volgende:
- Verplaatst elk aandeel live verkeer dat de bronbranch had naar het doel.
- Archiveert de bronbranch standaard.
- Sluit elk ander open voorstel van dezelfde branch.
- Lost het gekoppelde issue op, als dat er is.
Geleidelijke uitrol
Voordat een voorstel wordt samengevoegd, kun je een deel van het live verkeer naar de bijbehorende branch sturen, zodat echte bellers de wijziging gebruiken.
Start de verdeling
Vraag Architect bijvoorbeeld: “Stuur 5% van het verkeer naar deze branch.” Architect vertelt je de volledige
resulterende verdeling, inclusief het aandeel van main, en vraagt om goedkeuring voordat het deze toepast. Je kunt
dit ook zelf instellen: selecteer in Version Control > Branches de optie Deploy op de branch.
De verkeersverdeling moet altijd samen 100% zijn en routing is deterministisch per gesprek. Het aandeel wijzigen van een beschermde branch, inclusief verkeer weghalen bij een beschermde main, vereist een beheerder. Zie Traffic deployment.
Proactieve voorstellen
Architect maakt voorstellen wanneer je het daarom vraagt of wanneer je het een mislukte test, een Spotlight- bevinding, een waarschuwing of een issue geeft. Het scant je agents nog niet volgens een schema en opent ook niet zelf voorstellen.
De proactieve route bestaat momenteel uit Spotlight, gevolgd door een overdracht. Spotlight monitort de gesprekken van je agent continu. Het maakt een wekelijkse samenvatting met voorgestelde onderzoeken, geeft realtime waarschuwingen en beveelt configuratiewijzigingen aan. Zo zet je een Spotlight-bevinding om in een voorstel:
Kies een bevinding
Open de wekelijkse samenvatting en bekijk Voorgestelde volgende stappen, of open een realtime waarschuwing.
Draag het over aan ElevenAgents Architect
Selecteer Openen in Architect bij een suggestie, Analyseren met Architect bij de samenvatting, of Onderzoeken met Architect bij een waarschuwing. Architect ontvangt de bevinding en krijgt de instructie om deze te verifiëren aan de hand van echte gesprekken en vast te stellen welke branch wordt beïnvloed voordat het een wijziging voorstelt.
Issues werken op dezelfde manier. Je live agent kan tijdens gesprekken issues markeren voor beoordeling en Bespreken met Architect bij een issue start een onderzoek daarnaar.
Geplande automatiseringen, met rapporten die naar een inbox van Architect worden gestuurd, zijn in ontwikkeling. Het tabblad Inbox op de pagina van Architect is een tijdelijke aanduiding hiervoor.