V2-plan

Formål

Dette dokumentet samler ønsker for neste versjon og vurderer hva som fortsatt er aktuelt. Målet er trygg prioritering før utvikling, uten å låse oss til gamle antakelser.

Status nå

  • V1 er stabil i drift.
  • Ingen kodeendringer besluttes i dette dokumentet.
  • Dette er en analyse- og beslutningsplan for V2.

Analyse av eldre ønskeliste

Vurdering: Startskjerm (pre-chat)

Anbefaling: Behold i V2, men i enkel form.

Hvorfor: - Gir tydelig inngang til chat for Gjest/Medlem. - Kan redusere misforståelser tidlig i samtalen.

Avgrensning: - Maks 2-3 valg ved oppstart. - Skal kunne hoppes over dersom bruker vil skrive direkte.

Vurdering: Hurtigvalg/chips

Anbefaling: Behold i V2 (høy nytte, lav risiko).

Hvorfor: - Gir raskere bruk på mobil og desktop. - Kan styres per klubb uten ny frontend-rammeverk.

Avgrensning: - Maks 4-6 synlige chips. - Resten vises bak "Vis flere" ved behov.

Vurdering: Action buttons fra backend

Anbefaling: Delvis V2, full utvidelse i V2.1.

Hvorfor: - Enkle CTA-knapper gir tydeligere neste steg for bruker. - Flere knapper per svar øker kompleksitet og bør fases inn kontrollert.

Avgrensning: - V2: støtt enkel knapp (action_button). - V2.1: støtt liste av knapper (action_buttons).

Vurdering: Nye admin-felt i database

Anbefaling: Innfør minimumsfelt i V2, utvid gradvis.

Hvorfor: - Mindre risiko for feil i eldre Classic ASP-flyt. - Raskere å validere i testklubb før bred utrulling.

Avgrensning V2: - UseStartScreen (bit) - UseQuickReplies (bit) - QuickRepliesList (varchar)

Utsettes til V2.1: - Separate felter som StartScreenBtn1, StartScreenBtn2 hvis behovet fortsatt er reelt.

Beslutningsmatrise

  1. Startskjerm: Ja, V2 (forenklet)
  2. Chips/quick replies: Ja, V2
  3. Action button enkel: Ja, V2
  4. Action buttons (flere): V2.1
  5. Mange nye admin-kolonner samtidig: Nei, fases inn

Trygg plan (fasevis)

Fase 0 - Beslutning og avgrensning

  • Godkjenn "MVP for V2" før utvikling.
  • Fastslå hva som ikke skal inn i første leveranse.
  • Definer testklubb og tydelig rollback-plan.

Fase 1 - Konfigurasjon (lav risiko)

  • Dokumenter datamodell for minimumsfelter.
  • Beskriv valideringsregler for admin-input (lengde, tomme verdier, separatorer).
  • Definer trygge standardverdier ved manglende konfigurasjon.

Fase 2 - GUI-flyt (kontrollert)

  • Startskjerm med 2-3 valg.
  • Chips med maksgrense.
  • Ingen tvungen endring av eksisterende V1-flyt hvis funksjoner er deaktivert.

Fase 3 - Backend-kobling (gradvis)

  • Sidekontekst sendes med forespørsel.
  • Enkel action button støttes.
  • Logging av feil og fallback-svar må være på plass før pilot.

Fase 4 - Pilot og utrulling

  • Pilot i SKI først.
  • Kontrollpunkt etter pilot: kvalitet, feilrate, brukeradopsjon.
  • Deretter gradvis utrulling klubb for klubb.

Sikkerhets- og kvalitetskrav

  • Multi-klubb kompatibilitet.
  • Ingen lokal/live lekkasje i API-ruting.
  • Bakoverkompatibilitet: V1 skal fungere når V2-felter mangler.
  • Ingen eksponering av persondata i frontend-konfigurasjon.
  • Defensive defaults ved manglende eller ugyldig admin-data.

Ikke-mål for V2

  • Ingen frontend-rammeverk.
  • Ingen full redesign av chat-widget.
  • Ingen bred DB-utvidelse utover minimumsfelter i første steg.

Dokumenterte målepunkter før Go-Live

  1. Startskjerm kan aktiveres/deaktiveres uten kodeendring.
  2. Chips rendres korrekt og sender melding uten dobbeltinnsending.
  3. V1-opplevelse er uendret når V2 er slått av.
  4. API-ruting peker korrekt i både lokal test og ekstern side.
  5. Pilot-klubb godkjenner funksjon, tekst og brukerflyt.

Avgrensning mot V1-oppsett

Kilde-/tabellvalg for JSON-cache, personvernfiltrering og regler for ferskeste informasjon tilhører V1-oppsett og drift, ikke V2-roadmap.

Se: site-docs/data-sync-cache.md

Neste beslutning

Når denne planen er godkjent, lages en kort "V2 MVP-scope" med eksakt rekkevidde for implementering.