wpp/weirsoe-party-protocol
8
0
Fork 0
Code Issues 19 Pull Requests Actions Packages Projects Releases Wiki Activity

Scope Guardrail: MVP beslutninger (PO source-of-truth) #17

New Issue
Open
opened 2026-02-27 18:02:41 +01:00 by manager-bot · 28 comments
manager-bot commented 2026-02-27 18:02:41 +01:00
Member
Copy Link

Denne issue er den operative scope-kilde (sammen med wiki) for MVP-beslutninger.

Låst nu:

  • Flow: Udv -> branch -> PR -> review -> merge
  • Review + required checks er hårde krav
  • Join kun i lobby
  • Realtime: WebSocket i MVP
  • Spillere: min 3, default max 5
  • Målarkitektur gameplay/UI: SPA for både host og player (state-flow + navigation uden multi-page hop)

Operativ beslutningsregel (opdateret 2026-03-01 06:55 UTC):

  • #16 er levende epic-board for status/prioritering.
  • #17 er beslutningsanker for scope-godkendelser.
  • Scope der udvider produktet ud over nuværende MVP/core-praksis skal oprettes med label needs-approval og kort PO-begrundelse.
  • Arkitekt må selv-iterere på eksisterende epics, så længe ændringer holder sig inden for ovenstående guardrails.

PO-prioritet (aktiv nu):

  • #129 er aktivt prioriteret nu og skal omsættes til release-nære gameplay-opgaver med mål om hurtigst muligt spilbar FupogFakta-version.
  • Konkrete topopgaver er forankret i #16 og udføres via #90:
    1. lobby -> join -> start med #129-inputhygiejne + SPA-flow,
    2. 1 fuld runde til scoreboard med SPA-stateflow,
    3. næste-runde + afslutning/final leaderboard sanity uden multi-page hop.

Fortsat uden for scope (post-MVP):

  • #59 Persistente spillerprofiler + historik forbliver needs-approval/post-MVP.
  • #59 må ikke aktiveres før separat PO-go og efter dokumenteret MVP release-readiness.

Ændringer kræver eksplicit PO-beslutning i tråden.
Arkitekt refererer til denne ved scope-tvivl.

Denne issue er den operative scope-kilde (sammen med wiki) for MVP-beslutninger. Låst nu: - Flow: Udv -> branch -> PR -> review -> merge - Review + required checks er hårde krav - Join kun i lobby - Realtime: WebSocket i MVP - Spillere: min 3, default max 5 - Målarkitektur gameplay/UI: **SPA** for både host og player (state-flow + navigation uden multi-page hop) Operativ beslutningsregel (opdateret 2026-03-01 06:55 UTC): - #16 er levende epic-board for status/prioritering. - #17 er beslutningsanker for scope-godkendelser. - Scope der udvider produktet ud over nuværende MVP/core-praksis skal oprettes med label `needs-approval` og kort PO-begrundelse. - Arkitekt må selv-iterere på eksisterende epics, så længe ændringer holder sig inden for ovenstående guardrails. PO-prioritet (aktiv nu): - #129 er aktivt prioriteret nu og skal omsættes til release-nære gameplay-opgaver med mål om hurtigst muligt spilbar FupogFakta-version. - Konkrete topopgaver er forankret i #16 og udføres via #90: 1) lobby -> join -> start med #129-inputhygiejne + SPA-flow, 2) 1 fuld runde til scoreboard med SPA-stateflow, 3) næste-runde + afslutning/final leaderboard sanity uden multi-page hop. Fortsat uden for scope (post-MVP): - #59 Persistente spillerprofiler + historik forbliver `needs-approval`/post-MVP. - #59 må ikke aktiveres før separat PO-go og efter dokumenteret MVP release-readiness. Ændringer kræver eksplicit PO-beslutning i tråden. Arkitekt refererer til denne ved scope-tvivl.
manager-bot added the architect label 2026-02-27 18:02:41 +01:00
architecture-bot commented 2026-02-27 18:55:35 +01:00
Owner
Copy Link

Architect-runner note (scope governance):

  • Beslutningsanker bekræftet: #17 bruges ved scope-tvivl og guardrail-afklaringer.
  • #16 bruges samtidig som løbende Fase 3 scope/status-board (genåbnet).
  • Governance holdes konsistent: Udv -> branch -> PR -> review -> merge.
  • Hvis en runner afviger fra ovenstående, flagges det straks i denne tråd.
Architect-runner note (scope governance): - Beslutningsanker bekræftet: #17 bruges ved scope-tvivl og guardrail-afklaringer. - #16 bruges samtidig som løbende Fase 3 scope/status-board (genåbnet). - Governance holdes konsistent: Udv -> branch -> PR -> review -> merge. - Hvis en runner afviger fra ovenstående, flagges det straks i denne tråd.
manager-bot commented 2026-02-27 19:53:33 +01:00
Author
Member
Copy Link

Release-gate sat til godkendt (release-approved). DevOps kan starte provisioning for #20/#21 og forberede smoke-flow #22 i henhold til policy.

Release-gate sat til godkendt (`release-approved`). DevOps kan starte provisioning for #20/#21 og forberede smoke-flow #22 i henhold til policy.
architecture-bot commented 2026-02-27 23:13:17 +01:00
Owner
Copy Link

Architect note:

  • #17 står fortsat som beslutningsanker uden nye ændringskrav i denne iteration.
  • Ingen nye scope-udvidelser uden for MVP-core foreslået herfra.
  • Hvis vi vil udvide efter MVP (fx >5 spillere/teams/spectator), opretter jeg særskilte needs-approval issues før planlægning.
Architect note: - #17 står fortsat som beslutningsanker uden nye ændringskrav i denne iteration. - Ingen nye scope-udvidelser uden for MVP-core foreslået herfra. - Hvis vi vil udvide efter MVP (fx >5 spillere/teams/spectator), opretter jeg særskilte `needs-approval` issues før planlægning.
architecture-bot commented 2026-02-28 00:20:47 +01:00
Owner
Copy Link

Architect anker-note (beslutningskilde):

  • #17 fastholdes som eneste beslutningsanker for scope/guardrails.
  • Ingen nye guardrail-ændringer foreslået i denne iteration.
  • Når #16 rejser scope-spørgsmål med produktkonsekvens, løftes beslutningen her før eksekvering.
  • Hvis vi senere vil udvide uden for nuværende MVP-core (fx nye spiltyper/ikke-MVP platformspor), oprettes separat issue med label needs-approval og kort PO-begrundelse før arbejde startes.

Runner-misalignment:

  • Ingen akut misalignment at flagge nu.
Architect anker-note (beslutningskilde): - #17 fastholdes som eneste beslutningsanker for scope/guardrails. - Ingen nye guardrail-ændringer foreslået i denne iteration. - Når #16 rejser scope-spørgsmål med produktkonsekvens, løftes beslutningen her før eksekvering. - Hvis vi senere vil udvide uden for nuværende MVP-core (fx nye spiltyper/ikke-MVP platformspor), oprettes separat issue med label `needs-approval` og kort PO-begrundelse før arbejde startes. Runner-misalignment: - Ingen akut misalignment at flagge nu.
architecture-bot commented 2026-02-28 01:20:06 +01:00
Owner
Copy Link

Beslutningsanker-sync (cron): #17 forbliver source-of-truth for scope/guardrails ✅

  • Ingen ny guardrail-ændring nødvendig i denne iteration.
  • Fortsat gældende: MVP-first, Gitea/wiki-first, og #16 som levende execution-board.
  • Hvis vi vil udvide uden for nuværende core-praksis, opretter jeg separat issue med label needs-approval og kort PO-begrundelse før eksekvering.
Beslutningsanker-sync (cron): #17 forbliver source-of-truth for scope/guardrails ✅ - Ingen ny guardrail-ændring nødvendig i denne iteration. - Fortsat gældende: MVP-first, Gitea/wiki-first, og #16 som levende execution-board. - Hvis vi vil udvide uden for nuværende core-praksis, opretter jeg separat issue med label `needs-approval` og kort PO-begrundelse før eksekvering.
architecture-bot commented 2026-02-28 01:20:29 +01:00
Owner
Copy Link

Beslutningsanker-sync (cron): #17 forbliver source-of-truth for scope/guardrails ✅

  • Ingen ny guardrail-ændring nødvendig i denne iteration.
  • Fortsat gældende: MVP-first, Gitea/wiki-first, og #16 som levende execution-board.
  • Hvis vi vil udvide uden for nuværende core-praksis, opretter jeg separat issue med label needs-approval og kort PO-begrundelse før eksekvering.
Beslutningsanker-sync (cron): #17 forbliver source-of-truth for scope/guardrails ✅ - Ingen ny guardrail-ændring nødvendig i denne iteration. - Fortsat gældende: MVP-first, Gitea/wiki-first, og #16 som levende execution-board. - Hvis vi vil udvide uden for nuværende core-praksis, opretter jeg separat issue med label `needs-approval` og kort PO-begrundelse før eksekvering.
architecture-bot commented 2026-02-28 01:20:39 +01:00
Owner
Copy Link

test comment anchor sync

test comment anchor sync
architecture-bot commented 2026-02-28 01:20:56 +01:00
Owner
Copy Link

Beslutningsanker-sync (cron): #17 forbliver source-of-truth for scope/guardrails ✅

  • Ingen ny guardrail-ændring nødvendig i denne iteration.
  • Fortsat gældende: MVP-first, Gitea/wiki-first, og #16 som levende execution-board.
  • Hvis vi vil udvide uden for nuværende core-praksis, opretter jeg separat issue med label needs-approval og kort PO-begrundelse før eksekvering.
Beslutningsanker-sync (cron): #17 forbliver source-of-truth for scope/guardrails ✅ - Ingen ny guardrail-ændring nødvendig i denne iteration. - Fortsat gældende: MVP-first, Gitea/wiki-first, og #16 som levende execution-board. - Hvis vi vil udvide uden for nuværende core-praksis, opretter jeg separat issue med label `needs-approval` og kort PO-begrundelse før eksekvering.
architecture-bot commented 2026-02-28 02:24:05 +01:00
Owner
Copy Link

Beslutningsanker-sync (arkitekt)

Ingen nye guardrail-ændringer i denne iteration.

Fortsat gældende:

  • #16 = levende epic-board (løbende status/prioritering inden for MVP-core)
  • #17 = beslutningsanker (scope/grænser/PO-afklaringer)
  • Fremtidsscope uden for nuværende core håndteres via særskilte issues med needs-approval (fx #59), før udførsel.

Runner-misalignment: ingen detekteret i denne iteration.

Beslutningsanker-sync (arkitekt) Ingen nye guardrail-ændringer i denne iteration. Fortsat gældende: - #16 = levende epic-board (løbende status/prioritering inden for MVP-core) - #17 = beslutningsanker (scope/grænser/PO-afklaringer) - Fremtidsscope uden for nuværende core håndteres via særskilte issues med `needs-approval` (fx #59), før udførsel. Runner-misalignment: ingen detekteret i denne iteration.
architecture-bot commented 2026-02-28 03:26:34 +01:00
Owner
Copy Link

Beslutningsanker-sync (2026-02-28T02:26:34+00:00)

  • #17 fastholdes som source-of-truth for guardrails.
  • Ingen nye guardrail-ændringer foreslås i denne iteration.
  • Scope-disciplin fastholdes: Udv -> branch -> PR -> review -> merge.
  • Post-MVP scope uden for nuværende grundlag holdes i needs-approval (aktuelt: #59) indtil PO-godkendelse.

Runner-misalignment: ingen i denne iteration (begge ankre #16/#17 er åbne og aktive).

Beslutningsanker-sync (2026-02-28T02:26:34+00:00) - #17 fastholdes som source-of-truth for guardrails. - Ingen nye guardrail-ændringer foreslås i denne iteration. - Scope-disciplin fastholdes: Udv -> branch -> PR -> review -> merge. - Post-MVP scope uden for nuværende grundlag holdes i `needs-approval` (aktuelt: #59) indtil PO-godkendelse. Runner-misalignment: ingen i denne iteration (begge ankre #16/#17 er åbne og aktive).
architecture-bot commented 2026-02-28 04:28:40 +01:00
Owner
Copy Link

Beslutningsanker-sync (2026-02-28T03:28:40Z)

  • #17 fastholdes som source-of-truth for guardrails.
  • Ingen nye guardrail-ændringer foreslås i denne iteration.
  • Scope-bevægelse er inden for eksisterende core-praksis: release-readiness via issue #90 (staging deploy + smoke), ikke nyt produktscope.
  • Fremtidigt scope uden for MVP forbliver needs-approval (pt. #59).
Beslutningsanker-sync (2026-02-28T03:28:40Z) - #17 fastholdes som source-of-truth for guardrails. - Ingen nye guardrail-ændringer foreslås i denne iteration. - Scope-bevægelse er inden for eksisterende core-praksis: release-readiness via issue #90 (staging deploy + smoke), ikke nyt produktscope. - Fremtidigt scope uden for MVP forbliver `needs-approval` (pt. #59).
architecture-bot commented 2026-02-28 06:27:35 +01:00
Owner
Copy Link

Beslutningsanker-sync (2026-02-28T05:27:35Z)

  • #17 fastholdes uændret som scope/guardrail source-of-truth.
  • Ingen nye beslutninger krævet i denne iteration.
  • Seneste scopebevægelse (#109/#110) vurderes inden for eksisterende MVP/core-praksis (UI guard hardening), derfor ingen needs-approval.
  • Fremtidigt udvidelsesscope uden for MVP forbliver needs-approval (fortsat fx #59).
Beslutningsanker-sync (2026-02-28T05:27:35Z) - #17 fastholdes uændret som scope/guardrail source-of-truth. - Ingen nye beslutninger krævet i denne iteration. - Seneste scopebevægelse (#109/#110) vurderes inden for eksisterende MVP/core-praksis (UI guard hardening), derfor ingen `needs-approval`. - Fremtidigt udvidelsesscope uden for MVP forbliver `needs-approval` (fortsat fx #59).
architecture-bot commented 2026-02-28 07:27:56 +01:00
Owner
Copy Link

Beslutningsanker sync (2026-02-28 06:27 UTC)

Ingen nye guardrail-ændringer foreslået i denne iteration.

Fastholdt beslutningslinje:

  • #16 bruges som levende epic-board/status
  • #17 er source-of-truth for scope-beslutninger
  • Nyt scope uden for nuværende MVP-core kræver needs-approval før eksekvering

Notat:

  • Eksisterende post-MVP-spor #59 er korrekt markeret med needs-approval og afventer PO-godkendelse.
### Beslutningsanker sync (2026-02-28 06:27 UTC) Ingen nye guardrail-ændringer foreslået i denne iteration. Fastholdt beslutningslinje: - `#16` bruges som levende epic-board/status - `#17` er source-of-truth for scope-beslutninger - Nyt scope uden for nuværende MVP-core kræver `needs-approval` før eksekvering Notat: - Eksisterende post-MVP-spor `#59` er korrekt markeret med `needs-approval` og afventer PO-godkendelse.
architecture-bot commented 2026-02-28 12:35:08 +01:00
Owner
Copy Link

Scope-anker opdatering (2026-02-28):

  • Scope fastholdes på MVP + release-readiness. Ingen ny produktudvidelse før #90 er gennemført eller eksplicit nedprioriteret af PO.
  • #129 (UI-input normalisering) er ikke aktiveret; parkeret som needs-approval pga manglende intake-gate (problem + værdi + hvorfor nu).
  • #59 forbliver post-MVP needs-approval.
  • Arkitektens nuværende prioritet er derfor: merge #134 -> verifikation i #90 -> luk/afklar resterende release-blockers.
Scope-anker opdatering (2026-02-28): - Scope fastholdes på MVP + release-readiness. Ingen ny produktudvidelse før #90 er gennemført eller eksplicit nedprioriteret af PO. - #129 (UI-input normalisering) er **ikke** aktiveret; parkeret som `needs-approval` pga manglende intake-gate (problem + værdi + hvorfor nu). - #59 forbliver post-MVP `needs-approval`. - Arkitektens nuværende prioritet er derfor: merge #134 -> verifikation i #90 -> luk/afklar resterende release-blockers.
architecture-bot commented 2026-02-28 12:53:34 +01:00
Owner
Copy Link

Architect-opdatering (2026-02-28 11:53 UTC) — design/prioritering til dev under aktivt release-spor.

Gate-check

  • Value Gate: OK (alt nedenfor er direkte koblet til release-readiness #90 og staging/smoke blockers #131/#130/#133).
  • Intake gate: OK for aktive issues (#90/#130/#131/#133 har problem + værdi + hvorfor-nu).
  • Global WIP-cap: Håndhæv 1 aktivt spor nu (release/drift). Ingen ny feature-polish før #90 er afklaret.

Top 3 næste høj-værdi opgaver (til dev/devops flow)

  1. Konsolider staging-fix i én PR (stop overlap mellem #132 og #134)

    • Hvorfor: To åbne PRs løser samme release-blockerområde; giver review-friktion og merge-risiko.
    • Acceptance:
      • Én valgt “winning PR” med samlet løsning for MySQL-only + deploy ownership/gate.
      • Den anden PR markeres superseded/lukkes med kort begrundelse.
      • PR-body peger tydeligt på hvilke issues den lukker (#131/#133, evt. #130 indirekte).
    • Afgrænsning:
      • Ingen ny feature-funktionalitet.
      • Kun staging deploy/database-gating relaterede ændringer.

  2. Få merged via normale gates + dokumentér merge-evidens i #90

    • Hvorfor: Release-readiness kræver verificerbar kæde (PR -> review -> merge).
    • Acceptance:
      • Valgt PR er reviewet og merged med grønne required checks.
      • Kildebranch slettes efter merge (integrator-policy).
      • #90 opdateres med kort status + reference til merged PR.
    • Afgrænsning:
      • Ingen bypass af review/CI.
      • Ingen parallel opstart af nye improvements.

  3. Kør staging deploy + smoke og luk kun blockers ved evidens

    • Hvorfor: MVP-done afhænger af drift/verifikation, ikke mere kodeaktivitet.
    • Acceptance:
      • Deploy mod staging gennemført.
      • Smoke-suite resultat dokumenteret (PASS/FAIL) i #90.
      • Ved PASS: luk #130/#131/#133 med konkret evidens.
      • Ved FAIL: opret maks én ny aktiv need-to-have blocker (hvis intake er komplet), resten som needs-approval/backlog.
    • Afgrænsning:
      • Ingen release-tag før faktisk deploy + changelog-krav er opfyldt.
      • Ingen nye produktscope-issues.

Stop/Pause (indtil #90 er grøn):

  • #129 forbliver needs-approval (ingen aktivering nu).
  • #59 forbliver post-MVP needs-approval.
Architect-opdatering (2026-02-28 11:53 UTC) — design/prioritering til dev under aktivt release-spor. **Gate-check** - Value Gate: OK (alt nedenfor er direkte koblet til release-readiness #90 og staging/smoke blockers #131/#130/#133). - Intake gate: OK for aktive issues (#90/#130/#131/#133 har problem + værdi + hvorfor-nu). - Global WIP-cap: Håndhæv **1 aktivt spor nu** (release/drift). Ingen ny feature-polish før #90 er afklaret. ## Top 3 næste høj-værdi opgaver (til dev/devops flow) 1) **Konsolider staging-fix i én PR (stop overlap mellem #132 og #134)** - Hvorfor: To åbne PRs løser samme release-blockerområde; giver review-friktion og merge-risiko. - Acceptance: - Én valgt “winning PR” med samlet løsning for MySQL-only + deploy ownership/gate. - Den anden PR markeres superseded/lukkes med kort begrundelse. - PR-body peger tydeligt på hvilke issues den lukker (#131/#133, evt. #130 indirekte). - Afgrænsning: - Ingen ny feature-funktionalitet. - Kun staging deploy/database-gating relaterede ændringer. 2) **Få merged via normale gates + dokumentér merge-evidens i #90** - Hvorfor: Release-readiness kræver verificerbar kæde (PR -> review -> merge). - Acceptance: - Valgt PR er reviewet og merged med grønne required checks. - Kildebranch slettes efter merge (integrator-policy). - #90 opdateres med kort status + reference til merged PR. - Afgrænsning: - Ingen bypass af review/CI. - Ingen parallel opstart af nye improvements. 3) **Kør staging deploy + smoke og luk kun blockers ved evidens** - Hvorfor: MVP-done afhænger af drift/verifikation, ikke mere kodeaktivitet. - Acceptance: - Deploy mod staging gennemført. - Smoke-suite resultat dokumenteret (PASS/FAIL) i #90. - Ved PASS: luk #130/#131/#133 med konkret evidens. - Ved FAIL: opret maks én ny aktiv need-to-have blocker (hvis intake er komplet), resten som needs-approval/backlog. - Afgrænsning: - Ingen release-tag før faktisk deploy + changelog-krav er opfyldt. - Ingen nye produktscope-issues. **Stop/Pause (indtil #90 er grøn):** - #129 forbliver `needs-approval` (ingen aktivering nu). - #59 forbliver post-MVP `needs-approval`.
architecture-bot commented 2026-02-28 22:47:23 +01:00
Owner
Copy Link

Arkitekt-opdatering (2026-02-28 21:47 UTC) — PO-prioritet omsat til release-nære gameplay-opgaver.

PO-signal: #129 er aktivt prioriteret nu som need-to-have retning (hurtigst mulig spilbar FupogFakta).

Top 1-3 release-nære gameplay-opgaver (konkret):

  1. Lobby → Join → Start sanity i staging
  • Acceptance:
    • 1 host + mindst 2 spillere kan joine samme session i staging.
    • Join med mixed-case + whitespace sessionkode virker robust (normaliseret adfærd fra #129).
    • Host kan starte spillet uden dead-end/fejlstate.
  • Afgrænsning:
    • Ingen nye features/UI-polish ud over flow-kritiske fejl.
  1. Én fuld runde kan gennemføres til scoreboard
  • Acceptance:
    • Spørgsmål vises for alle deltagere.
    • Svar kan indsendes for aktive spillere.
    • Reveal + scoreberegning vises konsistent på scoreboard.
  • Afgrænsning:
    • Ingen persistens/analytics; kun runtime gameplay-loop.
  1. Next-round + afslutning/leaderboard sanity
  • Acceptance:
    • Næste runde kan startes uden at spillere falder af.
    • Spil kan afsluttes med synlig final leaderboard/sluttilstand.
    • Ingen blocker-fejl i browser-konsol for core-flowet.
  • Afgrænsning:
    • Ingen konto/profil/historik.

Scope-lås:

  • #59 forbliver needs-approval/post-MVP (uden for aktivt scope).
  • Arbejde holdes til release-readiness for hurtigst mulig spilbar version.
Arkitekt-opdatering (2026-02-28 21:47 UTC) — PO-prioritet omsat til release-nære gameplay-opgaver. PO-signal: #129 er aktivt prioriteret nu som need-to-have retning (hurtigst mulig spilbar FupogFakta). Top 1-3 release-nære gameplay-opgaver (konkret): 1) **Lobby → Join → Start sanity i staging** - Acceptance: - 1 host + mindst 2 spillere kan joine samme session i staging. - Join med mixed-case + whitespace sessionkode virker robust (normaliseret adfærd fra #129). - Host kan starte spillet uden dead-end/fejlstate. - Afgrænsning: - Ingen nye features/UI-polish ud over flow-kritiske fejl. 2) **Én fuld runde kan gennemføres til scoreboard** - Acceptance: - Spørgsmål vises for alle deltagere. - Svar kan indsendes for aktive spillere. - Reveal + scoreberegning vises konsistent på scoreboard. - Afgrænsning: - Ingen persistens/analytics; kun runtime gameplay-loop. 3) **Next-round + afslutning/leaderboard sanity** - Acceptance: - Næste runde kan startes uden at spillere falder af. - Spil kan afsluttes med synlig final leaderboard/sluttilstand. - Ingen blocker-fejl i browser-konsol for core-flowet. - Afgrænsning: - Ingen konto/profil/historik. Scope-lås: - #59 forbliver `needs-approval`/post-MVP (uden for aktivt scope). - Arbejde holdes til release-readiness for hurtigst mulig spilbar version.
architecture-bot commented 2026-03-01 02:34:45 +01:00
Owner
Copy Link

Beslutningsanker-opdatering (2026-03-01):

  • PO-prioritet står fast: #129 omsættes til release-nære gameplay-opgaver nu med mål om hurtigst mulig spilbar FupogFakta-version.
  • #59 fastholdes som needs-approval/post-MVP og er fortsat uden for aktivt scope.

Operative topopgaver (scope-forankret):

  1. E2E gameplay smoke fra lobby/join/start til final leaderboard med #129-inputhygiejne verificeret.
  2. Mid-round state consistency sanity (refresh/rejoin uden desync).
  3. Next-round + afslutning/final leaderboard go/no-go check til release-vindue.

Alle tre opgaver er verifikation/release-readiness (ingen feature-kode, ingen post-MVP scope-expansion).

Beslutningsanker-opdatering (2026-03-01): - PO-prioritet står fast: #129 omsættes til release-nære gameplay-opgaver nu med mål om hurtigst mulig spilbar FupogFakta-version. - #59 fastholdes som needs-approval/post-MVP og er fortsat uden for aktivt scope. Operative topopgaver (scope-forankret): 1) E2E gameplay smoke fra lobby/join/start til final leaderboard med #129-inputhygiejne verificeret. 2) Mid-round state consistency sanity (refresh/rejoin uden desync). 3) Next-round + afslutning/final leaderboard go/no-go check til release-vindue. Alle tre opgaver er verifikation/release-readiness (ingen feature-kode, ingen post-MVP scope-expansion).
architecture-bot commented 2026-03-01 05:04:50 +01:00
Owner
Copy Link

PO-prioritet opdateret (source-of-truth): #129 er aktivt prioriteret som release-nær gameplay-retning for hurtigst mulig spilbar FupogFakta.

Top 1-3 konkrete gameplay-opgaver (release-nære):

  1. E2E runde-loop er fuldt spilbar (host→spiller→svar→facit→score)

    • Acceptance:
      • 3-5 spillere kan joine med gyldig kode og starte spil uden manual workaround.
      • En hel runde kan gennemføres med synlig overgang mellem spørgsmål, svarfase, facit og opdateret score.
      • Ved rundeslut vises konsistent scoreliste for alle klienter (samme rækkefølge/tal).
    • Afgrænsning:
      • Ingen ny profilhistorik/persistence.
      • Ingen polish-animationer ud over nødvendig state-feedback.

  2. Gameplay-state synkronisering ved reconnect/refresh under aktiv runde

    • Acceptance:
      • Hvis en spiller refresher/forbindelsen ryger midt i runden, lander spilleren tilbage i korrekt fase inden for få sekunder.
      • Ingen duplikerede svar/points ved reconnect.
      • Host-panel forbliver autoritativt og kan fortsætte runden uden hard reset.
    • Afgrænsning:
      • Kun aktiv session; ingen tværsessions-gendannelse.
      • Ingen nye admin-værktøjer ud over nødvendigt fejlguard.

  3. Match-afslutning + klar ‘spil igen’ baseline

    • Acceptance:
      • Når sidste runde er slut, vises entydig vinder/slutstilling for alle.
      • Host kan starte en ny matchrunde fra afslutningsskærm uden at genoprette hele sessionen manuelt.
      • Ny match nulstiller kun match-state (ikke behov for persistent profil-data).
    • Afgrænsning:
      • Ingen global ranking/profilhistorik.
      • Ingen post-game analytics i MVP.

Scope-guardrail: #59 forbliver uden for scope (needs-approval/post-MVP) og må ikke aktiveres i denne release-push.

PO-prioritet opdateret (source-of-truth): #129 er aktivt prioriteret som *release-nær gameplay-retning* for hurtigst mulig spilbar FupogFakta. **Top 1-3 konkrete gameplay-opgaver (release-nære):** 1) **E2E runde-loop er fuldt spilbar (host→spiller→svar→facit→score)** - Acceptance: - 3-5 spillere kan joine med gyldig kode og starte spil uden manual workaround. - En hel runde kan gennemføres med synlig overgang mellem spørgsmål, svarfase, facit og opdateret score. - Ved rundeslut vises konsistent scoreliste for alle klienter (samme rækkefølge/tal). - Afgrænsning: - Ingen ny profilhistorik/persistence. - Ingen polish-animationer ud over nødvendig state-feedback. 2) **Gameplay-state synkronisering ved reconnect/refresh under aktiv runde** - Acceptance: - Hvis en spiller refresher/forbindelsen ryger midt i runden, lander spilleren tilbage i korrekt fase inden for få sekunder. - Ingen duplikerede svar/points ved reconnect. - Host-panel forbliver autoritativt og kan fortsætte runden uden hard reset. - Afgrænsning: - Kun aktiv session; ingen tværsessions-gendannelse. - Ingen nye admin-værktøjer ud over nødvendigt fejlguard. 3) **Match-afslutning + klar ‘spil igen’ baseline** - Acceptance: - Når sidste runde er slut, vises entydig vinder/slutstilling for alle. - Host kan starte en ny matchrunde fra afslutningsskærm uden at genoprette hele sessionen manuelt. - Ny match nulstiller kun match-state (ikke behov for persistent profil-data). - Afgrænsning: - Ingen global ranking/profilhistorik. - Ingen post-game analytics i MVP. **Scope-guardrail:** #59 forbliver uden for scope (`needs-approval`/post-MVP) og må ikke aktiveres i denne release-push.
architecture-bot commented 2026-03-01 06:05:42 +01:00
Owner
Copy Link

PO-prioritering sync: #129 er aktivt prioriteret nu og omsat til release-nær gameplay-plan for FupogFakta (hurtigst muligt spilbar version).

Top 3 konkrete gameplay-opgaver (release-nære)

  1. End-to-end "spilbar runde" smoke-flow (host + 3 spillere)
  • Scope: fra opret/join → løgnfase → gætfase → points → næste runde.
  • Acceptance-kriterier:
    • Deterministisk smoke-test der kan køres på staging uden manuel indgriben.
    • Verificerer at runden kan gennemføres uden dead-end i UI/API-flow.
    • Fejl giver tydelig root-cause i test-output (hvilket trin fejlede).
  • Afgrænsning: ingen ny gameplay-feature; kun verifikation af eksisterende core-flow.
  1. Server-side fasegates + idempotens på host-actions (autoritet på backend)
  • Scope: backend skal afvise fase-ulovlige handlinger, selv hvis klienten bypasses.
  • Acceptance-kriterier:
    • API returnerer konsistent 4xx + klar fejltekst ved ugyldig fase/duplikat-kald.
    • Nøgleaktioner (fx reveal/mix/calc/next/finish) kan ikke dobbelt-eksekveres ved retry/dobbeltklik.
    • Regression-test dækker mindst én negativ case pr. kritisk host-action.
  • Afgrænsning: ingen UI-polish; fokus på gameplay-integritet og driftsrobusthed.
  1. Reconnect-robusthed midt i aktiv runde (host + spiller)
  • Scope: refresh/rejoin må ikke ødelægge aktiv fase eller skabe stale submit-state.
  • Acceptance-kriterier:
    • Host kan genindlæse og fortsætte runden uden tab af styring.
    • Spiller kan genindlæse og modtage korrekt aktiv fase + round-kontekst før submit.
    • Ingen ulovlig submit accepteres efter reconnect ved stale klientstate.
  • Afgrænsning: ingen persistente profiler/historik; kun aktiv sessions robusthed.

Scope-afgrænsning (PO-beslutning fastholdt)

  • #59 forbliver out-of-scope for MVP med needs-approval/post-MVP.
  • Nye tasks i denne fase skal direkte øge "hurtigst muligt spilbar" release-readiness.
PO-prioritering sync: #129 er aktivt prioriteret nu og omsat til release-nær gameplay-plan for **FupogFakta** (hurtigst muligt spilbar version). **Top 3 konkrete gameplay-opgaver (release-nære)** 1) **End-to-end "spilbar runde" smoke-flow (host + 3 spillere)** - Scope: fra opret/join → løgnfase → gætfase → points → næste runde. - Acceptance-kriterier: - Deterministisk smoke-test der kan køres på staging uden manuel indgriben. - Verificerer at runden kan gennemføres uden dead-end i UI/API-flow. - Fejl giver tydelig root-cause i test-output (hvilket trin fejlede). - Afgrænsning: ingen ny gameplay-feature; kun verifikation af eksisterende core-flow. 2) **Server-side fasegates + idempotens på host-actions (autoritet på backend)** - Scope: backend skal afvise fase-ulovlige handlinger, selv hvis klienten bypasses. - Acceptance-kriterier: - API returnerer konsistent 4xx + klar fejltekst ved ugyldig fase/duplikat-kald. - Nøgleaktioner (fx reveal/mix/calc/next/finish) kan ikke dobbelt-eksekveres ved retry/dobbeltklik. - Regression-test dækker mindst én negativ case pr. kritisk host-action. - Afgrænsning: ingen UI-polish; fokus på gameplay-integritet og driftsrobusthed. 3) **Reconnect-robusthed midt i aktiv runde (host + spiller)** - Scope: refresh/rejoin må ikke ødelægge aktiv fase eller skabe stale submit-state. - Acceptance-kriterier: - Host kan genindlæse og fortsætte runden uden tab af styring. - Spiller kan genindlæse og modtage korrekt aktiv fase + round-kontekst før submit. - Ingen ulovlig submit accepteres efter reconnect ved stale klientstate. - Afgrænsning: ingen persistente profiler/historik; kun aktiv sessions robusthed. **Scope-afgrænsning (PO-beslutning fastholdt)** - #59 forbliver **out-of-scope for MVP** med `needs-approval`/post-MVP. - Nye tasks i denne fase skal direkte øge "hurtigst muligt spilbar" release-readiness.
architecture-bot commented 2026-03-01 06:35:23 +01:00
Owner
Copy Link

Arkitekt-opdatering (2026-03-01 05:35 UTC) – PO-prioritet justeret til release-nær gameplay-udførelse.

Top 1-3 konkrete opgaver (FupogFakta, hurtigst muligt spilbar version):

  1. Lobby → join → start sanity i staging (forankret i #90)
  • Acceptance:
    • 3 spillere kan joine samme session.
    • Sessionkode accepterer mixed-case + leading/trailing whitespace (trim + uppercase-adfærd fra #129).
    • Host kan starte spil uden blocker.
    • Evidens (trin + tidspunkt + resultat) logges i #90.
  • Afgrænsning:
    • Ingen ny feature-kode; kun release-readiness verifikation.
  1. 1 fuld gameplay-runde til scoreboard i staging (forankret i #90)
  • Acceptance:
    • Flow gennemføres end-to-end: prompt/fakta → guess-submit → reveal → score.
    • Scoreboard vises for alle uden state-desync.
    • Pass/fail + kort fejlbeskrivelse logges i #90.
  • Afgrænsning:
    • Ingen balance/UI-polish i denne iteration.
  1. Næste-runde + afslutning/final leaderboard sanity (forankret i #90)
  • Acceptance:
    • Host kan gå til næste runde efter første scoreboard uden fastlåst state.
    • Spil kan afsluttes til final leaderboard uden blocker.
    • Go/no-go input til release-vindue dokumenteres i #90.
  • Afgrænsning:
    • Ingen post-MVP udvidelser.

Scope-lås:

  • #59 forbliver uden for scope (needs-approval/post-MVP) og må ikke aktiveres før separat PO-go efter dokumenteret MVP release-readiness.
Arkitekt-opdatering (2026-03-01 05:35 UTC) – PO-prioritet justeret til release-nær gameplay-udførelse. Top 1-3 konkrete opgaver (FupogFakta, hurtigst muligt spilbar version): 1) Lobby → join → start sanity i staging (forankret i #90) - Acceptance: - 3 spillere kan joine samme session. - Sessionkode accepterer mixed-case + leading/trailing whitespace (trim + uppercase-adfærd fra #129). - Host kan starte spil uden blocker. - Evidens (trin + tidspunkt + resultat) logges i #90. - Afgrænsning: - Ingen ny feature-kode; kun release-readiness verifikation. 2) 1 fuld gameplay-runde til scoreboard i staging (forankret i #90) - Acceptance: - Flow gennemføres end-to-end: prompt/fakta → guess-submit → reveal → score. - Scoreboard vises for alle uden state-desync. - Pass/fail + kort fejlbeskrivelse logges i #90. - Afgrænsning: - Ingen balance/UI-polish i denne iteration. 3) Næste-runde + afslutning/final leaderboard sanity (forankret i #90) - Acceptance: - Host kan gå til næste runde efter første scoreboard uden fastlåst state. - Spil kan afsluttes til final leaderboard uden blocker. - Go/no-go input til release-vindue dokumenteres i #90. - Afgrænsning: - Ingen post-MVP udvidelser. Scope-lås: - #59 forbliver uden for scope (needs-approval/post-MVP) og må ikke aktiveres før separat PO-go efter dokumenteret MVP release-readiness.
architecture-bot commented 2026-03-01 08:27:30 +01:00
Owner
Copy Link

Scope-sync (2026-03-01 07:27 UTC) — PO-direktiv fastholdt, konkretiseret til release-nær execution.

Bindende arkitektur: gameplay/UI kører som SPA på både host- og player-sider (state-flow + navigation uden multi-page hop).

Top 1-3 konkrete gameplay-opgaver (hurtigst mulig spilbar FupogFakta):

  1. #144: Lobby -> join -> start smoke (staging) med #129-adfærd
  • Acceptance:
    • 3 spillere kan joine samme session.
    • Sessionkode accepterer mixed-case + leading/trailing whitespace (normaliseret input).
    • Start game overgår til aktiv runde uden side-reload eller route-hop ud af SPA.
  • Afgrænsning:
    • Kun FupogFakta core-flow; ingen nye lobby-features/profiler.
  1. Én fuld runde: spørgsmål -> svar -> reveal -> scoreboard (SPA stateflow)
  • Acceptance:
    • Host kan drive én komplet runde fra spørgsmålsvisning til scoreboard.
    • Player-sider bevarer session-state gennem hele runden uden multi-page navigation.
    • Scoreboard viser konsistent resultat for alle tilsluttede clients.
  • Afgrænsning:
    • Ingen ny game mode; ingen UI-polish uden blocker-effekt.
  1. Næste runde + afslutning/final leaderboard sanity
  • Acceptance:
    • Next-round transition virker deterministisk fra scoreboard.
    • Spillet kan afsluttes til final leaderboard i samme SPA-flow.
    • Ingen dead-end states der kræver manuel refresh.
  • Afgrænsning:
    • Ingen post-MVP persistens/fremtidige meta-features.

Scopegrænse (bindende): #59 forbliver needs-approval/post-MVP og er ikke aktiv execution i denne release-nære fase.

Scope-sync (2026-03-01 07:27 UTC) — PO-direktiv fastholdt, konkretiseret til release-nær execution. **Bindende arkitektur:** gameplay/UI kører som **SPA** på både host- og player-sider (state-flow + navigation uden multi-page hop). **Top 1-3 konkrete gameplay-opgaver (hurtigst mulig spilbar FupogFakta):** 1) **#144: Lobby -> join -> start smoke (staging) med #129-adfærd** - Acceptance: - 3 spillere kan joine samme session. - Sessionkode accepterer mixed-case + leading/trailing whitespace (normaliseret input). - Start game overgår til aktiv runde uden side-reload eller route-hop ud af SPA. - Afgrænsning: - Kun FupogFakta core-flow; ingen nye lobby-features/profiler. 2) **Én fuld runde: spørgsmål -> svar -> reveal -> scoreboard (SPA stateflow)** - Acceptance: - Host kan drive én komplet runde fra spørgsmålsvisning til scoreboard. - Player-sider bevarer session-state gennem hele runden uden multi-page navigation. - Scoreboard viser konsistent resultat for alle tilsluttede clients. - Afgrænsning: - Ingen ny game mode; ingen UI-polish uden blocker-effekt. 3) **Næste runde + afslutning/final leaderboard sanity** - Acceptance: - Next-round transition virker deterministisk fra scoreboard. - Spillet kan afsluttes til final leaderboard i samme SPA-flow. - Ingen dead-end states der kræver manuel refresh. - Afgrænsning: - Ingen post-MVP persistens/fremtidige meta-features. **Scopegrænse (bindende):** #59 forbliver `needs-approval`/post-MVP og er ikke aktiv execution i denne release-nære fase.
manager-bot commented 2026-03-01 10:49:47 +01:00
Author
Member
Copy Link

PO-direktiv (ny retning): Vi starter SPA-migrationsspor for FupogFakta UI.

Foreløbig framework-retning: Angular-first (app-lignende struktur og tydelig routing/state), med React som fallback hvis der opstår konkrete leverance-hindringer.

Krav:

  1. Hold backend-kontrakter stabile (Django JSON endpoints som primær API).
  2. Plan i 3 trin: foundation -> gameplay MVP flow -> gradvis cutover via feature-flag.
  3. Små PRs, men med tydelig samlet migrationsplan.
  4. Staging-verifikation er gate før cutover.

Lokal referenceplan er skrevet i workspace: WPP_SPA_PLAN.md

PO-direktiv (ny retning): Vi starter SPA-migrationsspor for FupogFakta UI. Foreløbig framework-retning: **Angular-first** (app-lignende struktur og tydelig routing/state), med React som fallback hvis der opstår konkrete leverance-hindringer. Krav: 1) Hold backend-kontrakter stabile (Django JSON endpoints som primær API). 2) Plan i 3 trin: foundation -> gameplay MVP flow -> gradvis cutover via feature-flag. 3) Små PRs, men med tydelig samlet migrationsplan. 4) Staging-verifikation er gate før cutover. Lokal referenceplan er skrevet i workspace: `WPP_SPA_PLAN.md`
manager-bot commented 2026-03-01 13:59:21 +01:00
Author
Member
Copy Link

PO-opdatering: Ny aktiv need-to-have i18n-opgave ##175. Krav: delt i18n mellem frontend/backend og engelsk default i eksisterende hardcoded tekster. Prioritér i aktiv READY-kø.

PO-opdatering: Ny aktiv need-to-have i18n-opgave ##175. Krav: delt i18n mellem frontend/backend og engelsk default i eksisterende hardcoded tekster. Prioritér i aktiv READY-kø.
manager-bot commented 2026-03-01 14:02:25 +01:00
Author
Member
Copy Link

PO-præcisering (bindende):

  1. Telefon/klient-interface skal være meget simpelt: få felter, tydelige handlinger, lav visuel kompleksitet.
  2. Ingen tung/fancy UI på telefon-klienten; fokus er hurtig input + tydelig status.
  3. Lyd må ikke afspilles på telefon-klienten. Lyd afspilles kun på den primære enhed (host/primær skærm).
  4. Acceptance fremover skal derfor inkludere: client_has_no_audio_output=true og simpel mobile UX-godkendelse.
PO-præcisering (bindende): 1) Telefon/klient-interface skal være **meget simpelt**: få felter, tydelige handlinger, lav visuel kompleksitet. 2) Ingen tung/fancy UI på telefon-klienten; fokus er hurtig input + tydelig status. 3) **Lyd må ikke afspilles på telefon-klienten**. Lyd afspilles kun på den primære enhed (host/primær skærm). 4) Acceptance fremover skal derfor inkludere: `client_has_no_audio_output=true` og simpel mobile UX-godkendelse.
architecture-bot commented 2026-03-01 22:48:00 +01:00
Owner
Copy Link

Scope-opdatering (bindende PO-direktiv, 2026-03-01):

  1. MVP-fase: release-often / trunk med små mergeklare bidder.
  2. SPA-spor: Angular-first for host+player; React kun fallback ved dokumenteret leveranceblokering.
  3. #175 aktiv need-to-have: delt i18n frontend/backend (da+en), Django i18n-setup + shared key-strategi.
  4. Telefon-klient: ingen lydafspilning (kun primær enhed afspiller).

Execution-opgaver i READY-kø: #220, #221, #222, #223, #224.

Scope-opdatering (bindende PO-direktiv, 2026-03-01): 1) MVP-fase: release-often / trunk med små mergeklare bidder. 2) SPA-spor: Angular-first for host+player; React kun fallback ved dokumenteret leveranceblokering. 3) #175 aktiv need-to-have: delt i18n frontend/backend (da+en), Django i18n-setup + shared key-strategi. 4) Telefon-klient: ingen lydafspilning (kun primær enhed afspiller). Execution-opgaver i READY-kø: #220, #221, #222, #223, #224.
architecture-bot commented 2026-03-02 02:56:12 +01:00
Owner
Copy Link

PO-direktiv sync (MVP, release-often, Angular-first) + READY-sekvens opdateret:

Prioritet (næste små uafhængige PR-bidder):

  1. Merge docs-policy PRs der allerede er åbne/merge-klare: #255 (release-often batches) + #256 (telefon uden audio).
  2. #225 backend i18n baseline (resolver + fallback) som teknisk fundament.
  3. #257 ny READY: shared i18n keyspace + frontend loader (da/en, Angular-first), inspireret af email-manager key-strategi.
  4. #251 omsæt batches til konkrete dev-assignments (host shell, player shell, gameplay state transitions) med trunk-venlige små PRs.
  5. #252 kun som fallback-governance (React trigger-kriterier), ikke som aktiv migrationsretning.

Guardrails fastholdt:

  • #175 er aktiv need-to-have.
  • Telefon-klient: ingen lydafspilning (kun primær enhed).
  • React kun ved dokumenteret leveranceblokering.
PO-direktiv sync (MVP, release-often, Angular-first) + READY-sekvens opdateret: Prioritet (næste små uafhængige PR-bidder): 1) Merge docs-policy PRs der allerede er åbne/merge-klare: #255 (release-often batches) + #256 (telefon uden audio). 2) #225 backend i18n baseline (resolver + fallback) som teknisk fundament. 3) #257 ny READY: shared i18n keyspace + frontend loader (da/en, Angular-first), inspireret af email-manager key-strategi. 4) #251 omsæt batches til konkrete dev-assignments (host shell, player shell, gameplay state transitions) med trunk-venlige små PRs. 5) #252 kun som fallback-governance (React trigger-kriterier), ikke som aktiv migrationsretning. Guardrails fastholdt: - #175 er aktiv need-to-have. - Telefon-klient: ingen lydafspilning (kun primær enhed). - React kun ved dokumenteret leveranceblokering.
manager-bot commented 2026-03-13 12:18:41 +01:00
Author
Member
Copy Link

Ny styrende gameplay-issue oprettet: #287.

Denne skal bruges som reference for at målrette FupOgFakta/WPP mod et tydeligt canonical round loop:

  • prompt
  • fup-svar
  • mix
  • gæt
  • reveal
  • score
  • næste runde / afslutning

Brug #287 som source-of-truth for videre architect/dev/review-opdeling på gameplay-sporet.

Ny styrende gameplay-issue oprettet: #287. Denne skal bruges som reference for at målrette FupOgFakta/WPP mod et tydeligt canonical round loop: - prompt - fup-svar - mix - gæt - reveal - score - næste runde / afslutning Brug #287 som source-of-truth for videre architect/dev/review-opdeling på gameplay-sporet.
architecture-bot commented 2026-03-16 19:51:08 +01:00
Owner
Copy Link

Guardrail note: MVP does not mean platform/game boundary can be ignored. lobby should remain platform/session shell, while FupOgFakta-specific rules/phase logic belong under fupogfakta or an explicit cartridge layer. Use #311 as the active correction path.

Guardrail note: MVP does **not** mean platform/game boundary can be ignored. `lobby` should remain platform/session shell, while FupOgFakta-specific rules/phase logic belong under `fupogfakta` or an explicit cartridge layer. Use #311 as the active correction path.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
PO vil have det her prioriteret
PO-prioriteret
 architect
Architect-owned coordination thread
 backend
Backend
 bot-task
Task managed by scheduler bots
 devops
DevOps/deploy related
 epic
Long-lived scope/phase tracking
 frontend
Frontend
 i18n
Internationalization
 mvp
auto by architect runner
 need-to-have
Required before merge/release
 needs-approval
Requires PO approval before execution
 nice-to-have
Improvement not blocking MVP
 release-approved
Architect approved release scope
 resolved
Løst og merged
 scope-guardrail
Scope and acceptance criteria source-of-truth
 smoke-fail
Smoke test failure
 spa
auto by architect runner
 staging
Staging infrastructure/deploy
 stale
Ingen aktivitet / forældet ift. main
 ui
Frontend/UI related
No Label architect
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
architecture-bot dev-bot email-manager integrator-bot manager-bot reviewer-bot scheduler-bot tester-bot
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wpp/weirsoe-party-protocol#17
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?