NL
Het oorspronkelijke REODE-personage, verfijnd: een lachend crème-roze axolotlgezicht met een marineblauwe headset en cyaan lenzen
Terug naar de zaal

REODE

Code migration

Vóór het herstellen eerst de gemeenschappelijke oorzaak.

Een agent voor de migratie van Java/Spring-code.

2026.03 — 2026.04

Werkproject · migratie- en verificatiesysteem

  • CLIGeïmplementeerd · werkproject

De reparatieagent eerst de configuratie laten lezen

De agent die setter voor setter probeerde te corrigeren, is de reparatieagent in het product REODE; de ontwikkeling veranderde zijn input. Code en klantinformatie zijn niet openbaar.

Volledige legenda

Leeswijzer · één grammatica voor elke casus

  • Kolommen tonen wie handelde; van boven naar beneden loopt de tijd
  • Doorgetrokken: een vastgelegde overdracht of volgende stap
  • Dikke lapislijn ↩: een bevinding die werk terugstuurde
  • Gestreept: geen vastgelegde uitvoering (een geschreven richtlijn, advies zonder bevoegdheid, een ongecontroleerde grens)
  • Rechthoek: een actie
  • Afgerond: een waargenomen toestand of bevinding
  • Omgevouwen hoek: een artefact of bewijs
  • Gearceerde kolom: onderdelen van het product in ontwikkeling (niet de agents waarmee het wordt gebouwd)

March 21, 2026

Foutgroepen, de oorspronkelijke build en de Lombok-setup werden de reparatie-input

  1. In ontwikkelingREODE-reparatieagent

    Observatie · bevindingLosse correcties geprobeerd voor zo’n 40 setter-fouten · @Data / POM niet bekeken

  2. MensOntwikkelaar

    ActieVóór het herstellen bron- en buildconfiguratie lezen

    • overdrachtReparatie-input gewijzigd→ De oorspronkelijke baseline bouwen · fouten met hetzelfde patroon groeperen (Ontwikkelwijzigingen)

  3. WerksessieOntwikkelwijzigingen

    ActieDe oorspronkelijke baseline bouwen · fouten met hetzelfde patroon groeperen

    • overdracht→ Bewijs verzamelen: paden · 3 bronsteekproeven · annotaties · POM (Ontwikkelwijzigingen)

  4. Geschreven richtlijnBijdragersrichtlijn

    Richtlijn · ongecontroleerdTaakplan · eigen worktree

    • geen vastgelegde uitvoeringVereist door de richtlijn→ De oorspronkelijke baseline bouwen · fouten met hetzelfde patroon groeperen (Ontwikkelwijzigingen)

  5. WerksessieOntwikkelwijzigingen

    ActieBewijs verzamelen: paden · 3 bronsteekproeven · annotaties · POM

    • overdracht→ Eerst een deterministische Lombok-correctie · LLM overgeslagen als de rebuild slaagt (Ontwikkelwijzigingen)

  6. Geschreven richtlijnBijdragersrichtlijn

    Richtlijn · ongecontroleerdZero-context-review: plan ↔ diff

    • geen vastgelegde uitvoeringVereist door de richtlijn→ Bewijs verzamelen: paden · 3 bronsteekproeven · annotaties · POM (Ontwikkelwijzigingen)

  7. WerksessieOntwikkelwijzigingen

    ActieEerst een deterministische Lombok-correctie · LLM overgeslagen als de rebuild slaagt

    • overdrachtRebuild mislukt→ Mislukt de rebuild, dan modelreparatie met bewijs en herstelinstructies (REODE-reparatieagent)

  8. In ontwikkelingREODE-reparatieagent

    Observatie · bevindingMislukt de rebuild, dan modelreparatie met bewijs en herstelinstructies

    • overdrachtVerificatiesignalen→ Scorecard: build · test · verwijderde tests · surefire-uitsluitingen (Artefacten)

  9. ArtefactenArtefacten

    ArtefactScorecard: build · test · verwijderde tests · surefire-uitsluitingen

  10. WerksessieOntwikkelwijzigingen

    ActieResterende fouten gaan terug naar het verzamelen van bewijs

Achtergrond
De reparatieagent probeerde zo’n 40 fouten setMsg() not found een voor een te verhelpen zonder naar @Data of de Lombok-versie in pom.xml te kijken. Input die al kapot was, werd niet onderscheiden van fouten die de migratie had veroorzaakt.
Uitkomst
De scorecard leest build- en testresultaten samen met het aantal verwijderde tests en surefire-uitsluitingen, en slaat het coverage-onderdeel over als de baseline onbekend is. Slagen door tests te verwijderen blijft een mislukking.
Beperking
Het verzamelen van bewijs neemt steekproeven uit hoogstens drie bronnen, dus het is geen begrip van de hele codebase. Er is geen vastlegging dat de worktree, de onafhankelijke review of de develop-mergequeue uit de richtlijn werkelijk op deze casus zijn toegepast, en de codeeragent en het model voor deze casus zijn niet bevestigd. Er zijn geen definitieve test- of coverageresultaten van klanten.
Bronnen en resterende beperkingen
  • De baselinetaak en de taak ‘verkennen vóór herstellen’ gingen van bezig naar klaar, en er zijn implementatiecommits. Er zijn geen nieuwe GitHub-controleresultaten opgehaald.
  • De richtlijn van deze repository legt een mergequeue feature → develop → main vast, maar dezelfde procedure wordt niet op andere projecten toegepast.
  • De optioneel in te schakelen validatieagents zijn een mechanisme in de implementatie, geen bewijs dat ze bij elke oplevering zijn gebruikt. Cijfers zoals omvang of verhoudingen van opleveringen zijn niet opgenomen, omdat het oorspronkelijke bewijs ervan niet kon worden bevestigd.
  • Mislukt de rebuild, dan krijgt de modelreparatie nog steeds de oorspronkelijke buildfout, niet de nieuwe van de rebuild.