Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

Moderniseringsplan voor de applicatie

​

Doel

​

Principes

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

​

Fase 1: Baseline-audit

• Identificeer de belangrijkste gebruikersworkflows en de code-oppervlakken die ze beheren.
• Maak een lijst van dode affordances, dubbele instellingen, onduidelijke foutstatussen en dure renderpaden.
• Leg de huidige validatiecommando’s vast voor elk oppervlak.
• Markeer problemen als vereist, aanbevolen of optioneel.
• Documenteer bekende blokkades die owner-review nodig hebben, vooral API-, security-, release- en Plugin-contractwijzigingen.

• Eén issuelijst met repo-root bestandsverwijzingen.
• Elk issue heeft ernst, owner-oppervlak, verwachte gebruikersimpact en een voorgesteld validatiepad.
• Geen speculatieve opruimitems zijn vermengd met vereiste fixes.

​

Fase 2: Product- en UX-opruiming

• Maak onboardingtekst en lege toestanden rond model-auth, Gateway-status en Plugin-instelling strakker.
• Verwijder of schakel dode affordances uit waar geen actie mogelijk is.
• Houd belangrijke acties zichtbaar over responsieve breedtes heen in plaats van ze te verbergen achter kwetsbare layout-aannames.
• Consolideer herhaalde statustaal zodat fouten één bron van waarheid hebben.
• Voeg progressieve onthulling toe voor geavanceerde instellingen terwijl de kerninstelling snel blijft.

• Handmatig happy path voor eerste configuratie en opstarten door bestaande gebruikers.
• Gerichte tests voor logica rond routing, config-persistentie of statusafleiding.
• Browserscreenshots voor gewijzigde responsieve oppervlakken.

​

Fase 3: Frontendarchitectuur aanscherpen

• Verplaats herhaalde UI-statustransformaties naar smalle getypeerde 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 dat koppeling vermindert of tests verduidelijkt.
• Vermijd de introductie van brede globale state voor lokale paneelinteracties.

• Wijzig publiek gedrag niet als neveneffect van het splitsen van bestanden.
• 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

• Meet kosten voor opstarten, routeovergangen, grote lijsten en chattranscripten.
• Vervang herhaalde dure afgeleide data door gememoiseerde selectors of gecachete helpers waar profiling waarde bewijst.
• Verminder vermijdbare netwerk- of bestandssysteemscans op hot paths.
• Houd deterministische ordening voor prompt-, registry-, bestands-, Plugin- en netwerk- inputs vóór constructie van modelpayloads.
• Voeg lichte regressietests toe voor hot helpers en contractgrenzen.

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

​

Fase 5: Type-, contract- en testverharding

• Vervang losse runtime-strings door discriminated unions of gesloten codelijsten.
• Valideer externe inputs met bestaande schemahelpers of zod.
• Voeg contracttests toe rond Plugin-manifesten, providercatalogi, Gateway-protocol- berichten en config-migratiegedrag.
• Houd compatibiliteitspaden in doctor- of reparatiestromen in plaats van verborgen migraties tijdens het opstarten.
• Vermijd test-only koppeling aan Plugin-internals; gebruik SDK-facades en gedocumenteerde barrels.

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

​

Fase 6: Documentatie en releasegereedheid

• Werk documentatie bij voor wijzigingen in gedrag, API, config, onboarding of Plugin.
• Voeg changelogvermeldingen alleen toe voor voor gebruikers zichtbare wijzigingen.
• Houd Plugin-terminologie gebruikersgericht; gebruik interne pakketnamen alleen waar nodig voor contributors.
• Bevestig dat release- en installatie-instructies nog steeds overeenkomen met het huidige commando- oppervlak.

• Relevante documentatie is bijgewerkt in dezelfde branch als gedragswijzigingen.
• Gegenereerde documentatie- of API-driftchecks slagen wanneer ze geraakt zijn.
• De handoff noemt alle overgeslagen validatie en waarom die is overgeslagen.

​

Aanbevolen eerste onderdeel

• Audit eerste configuratie, gereedheid van provider-auth, Gateway-status en Plugin- instellingsoppervlakken.
• Verwijder dode acties en verduidelijk fouttoestanden.
• Voeg gerichte tests toe of werk ze bij voor statusafleiding en config-persistentie.
• Voer pnpm check:changed uit.

​

Update voor frontend-Skill

# 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.