Plan voor applicatiemodernisering

# Doel

Breng de toepassing richting een schoner, sneller en beter onderhoudbaar product zonder bestaande workflows te breken of risico te verbergen in brede refactors. Het werk moet landen als kleine, controleerbare delen met bewijs voor elk geraakt oppervlak.

# Principes

• Behoud de huidige architectuur tenzij een grens aantoonbaar churn, prestatiekosten of voor gebruikers zichtbare bugs veroorzaakt.
• Geef de voorkeur aan de kleinste correcte patch voor elk probleem en herhaal daarna.
• Scheid vereiste fixes van optionele verfijning, zodat maintainers werk met hoge waarde kunnen landen zonder te wachten op subjectieve beslissingen.
• Houd gedrag richting plugins gedocumenteerd en achterwaarts compatibel.
• Verifieer geleverd gedrag, dependency-contracten en tests voordat je claimt dat een regressie is opgelost.
• Verbeter eerst het belangrijkste gebruikerspad: onboarding, auth, chat, providerconfiguratie, pluginbeheer en diagnostiek.

# Fase 1: Baseline-audit

Inventariseer de huidige toepassing voordat je deze wijzigt.

• Identificeer de belangrijkste gebruikersworkflows en de codeoppervlakken die ze bezitten.
• Maak een lijst van dode affordances, dubbele instellingen, onduidelijke fouttoestanden en dure renderpaden.
• Leg de huidige validatiecommando's vast voor elk oppervlak.
• Markeer problemen als vereist, aanbevolen of optioneel.
• Documenteer bekende blockers waarvoor owner-review nodig is, vooral API-, security-, release- en plugin-contractwijzigingen.

Definitie van klaar:

• Eén issue-lijst met bestandsverwijzingen vanaf de repo-root.
• Elk issue heeft ernst, owner-oppervlak, verwachte gebruikersimpact en een voorgesteld validatiepad.
• Er zijn geen speculatieve opschoonitems vermengd met vereiste fixes.

# Fase 2: Product- en UX-opschoning

Geef prioriteit aan zichtbare workflows en neem verwarring weg.

• Maak onboardingtekst en lege toestanden rond model-auth, gatewaystatus en pluginconfiguratie strakker.
• Verwijder of schakel dode affordances uit wanneer geen actie mogelijk is.
• Houd belangrijke acties zichtbaar over responsieve breedtes heen in plaats van ze te verbergen achter kwetsbare layoutaannames.
• Consolideer herhaalde statusteksten zodat fouten één bron van waarheid hebben.
• Voeg progressieve openbaarmaking toe voor geavanceerde instellingen terwijl de kernconfiguratie snel blijft.

Aanbevolen validatie:

• Handmatig happy path voor eerste installatie en start door bestaande gebruikers.
• Gerichte tests voor routering, configuratiepersistentie of logica voor statusafleiding.
• Browserscreenshots voor gewijzigde responsieve oppervlakken.

# Fase 3: Frontendarchitectuur aanscherpen

Verbeter onderhoudbaarheid zonder brede herschrijving.

• Verplaats herhaalde UI-statetransformaties naar smalle getypte helpers.
• Houd verantwoordelijkheden voor data ophalen, persistentie en presentatie gescheiden.
• Geef de voorkeur aan bestaande hooks, stores en componentpatronen boven nieuwe abstracties.
• Splits te grote componenten alleen wanneer dit koppeling vermindert of tests verduidelijkt.
• Vermijd het introduceren van brede globale state voor lokale paneelinteracties.

Vereiste vangrails:

• Wijzig publiek gedrag niet als neveneffect van bestandssplitsing.
• Houd toegankelijkheidsgedrag intact voor menu's, dialogen, tabs en toetsenbordnavigatie.
• Verifieer dat laad-, lege, fout- en optimistische toestanden nog steeds renderen.

# Fase 4: Prestaties en betrouwbaarheid

Richt je op gemeten pijnpunten in plaats van brede theoretische optimalisatie.

• Meet kosten voor opstarten, routeovergangen, grote lijsten en chattranscripten.
• Vervang herhaald dure afgeleide data door gememoiseerde selectors of gecachete helpers waar profiling waarde bewijst.
• Verminder vermijdbare netwerk- of bestandssysteemscans op hot paths.
• Houd deterministische volgorde aan voor prompt-, registry-, bestands-, plugin- en netwerkinputs voordat modelpayloads worden opgebouwd.
• Voeg lichtgewicht regressietests toe voor hot helpers en contractgrenzen.

Definitie van klaar:

• Elke prestatiewijziging legt baseline, verwachte impact, werkelijke impact en resterende kloof vast.
• Geen prestatiepatch landt uitsluitend op intuïtie wanneer goedkope meting beschikbaar is.

# Fase 5: Types, contracten en tests verharden

Verhoog correctheid op de grenspunten waarvan gebruikers en plugin-auteurs afhankelijk zijn.

• Vervang losse runtime-strings door discriminated unions of gesloten codelijsten.
• Valideer externe inputs met bestaande schemahelpers of zod.
• Voeg contracttests toe rond pluginmanifesten, providercatalogi, gatewayprotocolberichten en configuratiemigratiegedrag.
• Houd compatibiliteitspaden in doctor- of repairflows in plaats van verborgen migraties tijdens het opstarten.
• Vermijd test-only koppeling aan plugin-internals; gebruik SDK-facades en gedocumenteerde barrels.

Aanbevolen validatie:

• pnpm check:changed
• Gerichte tests voor elke gewijzigde grens.
• pnpm build wanneer lazy boundaries, packaging of gepubliceerde oppervlakken wijzigen.

# Fase 6: Documentatie en releasegereedheid

Houd gebruikersgerichte documentatie afgestemd op gedrag.

• Werk documentatie bij met gedrags-, API-, configuratie-, onboarding- of pluginwijzigingen.
• Voeg changelogitems alleen toe voor gebruikerszichtbare wijzigingen.
• Houd pluginterminologie gebruikersgericht; gebruik interne pakketnamen alleen waar nodig voor contributors.
• Bevestig dat release- en installatie-instructies nog steeds overeenkomen met het huidige commando-oppervlak.

Definitie van klaar:

• Relevante documentatie is bijgewerkt in dezelfde branch als gedragswijzigingen.
• Checks voor gegenereerde documentatie of API-drift slagen wanneer ze geraakt zijn.
• De overdracht noemt eventuele overgeslagen validatie en waarom die is overgeslagen.

# Aanbevolen eerste deel

Begin met een afgebakende Control UI- en onboarding-pass:

• Audit eerste installatie, gereedheid van provider-auth, gatewaystatus en pluginconfiguratieoppervlakken.
• Verwijder dode acties en verduidelijk fouttoestanden.
• Voeg gerichte tests toe of werk ze bij voor statusafleiding en configuratiepersistentie.
• Voer pnpm check:changed uit.

Dit levert hoge gebruikerswaarde op met beperkt architectuurrisico.

# Frontend-skillupdate

Gebruik deze sectie om de frontendgerichte SKILL.md bij te werken die met de moderniseringstaak is meegeleverd. Als je deze richtlijnen adopteert als repo-lokale OpenClaw-skill, maak dan eerst .agents/skills/openclaw-frontend/SKILL.md, behoud de frontmatter die bij die doelskill hoort en voeg daarna de body-richtlijnen toe of vervang ze door de volgende inhoud.

# Frontend Delivery Standards

Use this skill when implementing or reviewing user-facing React, Next.js,
desktop webview, or app UI work.

## Operating rules

- Start from the existing product workflow and code conventions.
- Prefer the smallest correct patch that improves the current user path.
- Separate required fixes from optional polish in the handoff.
- Do not build marketing pages when the request is for an application surface.
- Keep actions visible and usable across supported viewport sizes.
- Remove dead affordances instead of leaving controls that cannot act.
- Preserve loading, empty, error, success, and permission states.
- Use existing design-system components, hooks, stores, and icons before adding
  new primitives.

## Implementation checklist

1. Identify the primary user task and the component or route that owns it.
2. Read the local component patterns before editing.
3. Patch the narrowest surface that solves the issue.
4. Add responsive constraints for fixed-format controls, toolbars, grids, and
   counters so text and hover states cannot resize the layout unexpectedly.
5. Keep data loading, state derivation, and rendering responsibilities clear.
6. Add tests when logic, persistence, routing, permissions, or shared helpers
   change.
7. Verify the main happy path and the most relevant edge case.

## Visual quality gates

- Text must fit inside its container on mobile and desktop.
- Toolbars may wrap, but controls must remain reachable.
- Buttons should use familiar icons when the icon is clearer than text.
- Cards should be used for repeated items, modals, and framed tools, not for
  every page section.
- Avoid one-note color palettes and decorative backgrounds that compete with
  operational content.
- Dense product surfaces should optimize for scanning, comparison, and repeated
  use.

## Handoff format

Report:

- What changed.
- What user behavior changed.
- Required validation that passed.
- Any validation skipped and the concrete reason.
- Optional follow-up work, clearly separated from required fixes.