Skip to main content

Sprint 4 report

Reconstructed report for the final-submission work from 29 September to 8 October 2026, using local origin/main at a9dca04. Discussion, decisions, and actions are inferred from commit history; original minutes, ceremony dates, and attendance were not supplied. The reporting windows below organise the work in the same sequence as the earlier sprints.

This is an interim report. The roadmap’s final-submission target is 11 October; work and acceptance after this snapshot are not covered. Photos follow supplied order for presentation, with unconfirmed dates and meeting associations.

All reporting dates are in Africa/Johannesburg time and were chosen for this reconstruction. The merge register fixes the evidence snapshot; photo provenance explains the presentation-only placements.

Sprint Planning — 29 September 2026 (reconstructed)​

Reporting point: 29 September 2026 — reconstructed planning point.

Meeting photo​

Sprint 4 supplied team-call photo 1
Supplied Sprint 4 photo 1, displayed with planning.

Sprint Goal​

Prepare the existing Basic, Intermediate, and Advanced journeys for final submission: make the interface clearer, reduce avoidable startup and battle latency, improve loading and recovery, and make database operations easier to diagnose.

Discussion Summary​

  • The next increment should concentrate on finishing and stabilising existing journeys rather than expanding the game rules.
  • Start with homepage and Explore startup, then collection, decks, evolution, trading, profiles, and Author workflows.
  • Review battle hydration, action, acceptance, and match-detail reads together so latency improvements retain the existing transaction and recovery contracts.
  • Keep loading, reading preferences, keyboard focus, and mobile layout consistent across the app.
  • Treat the late Sprint 3 rate-limit integration as starting context; keep subsequent scheduler coordination and listener changes separately traceable.

Key Decisions​

  • Preserve server-owned identity, ownership, versions, gameplay results, and publication while simplifying the interface.
  • Reduce unnecessary reads and startup work before changing gameplay behavior.
  • Use focused tests and responsive browser checks for each changed journey; retain explicit deployment and manual checks.
  • Keep background recovery available and avoid blind resubmission of player or Author mutations.

Task Allocation​

  • Kevin — interface and docs: player and Author journeys, profiles, accessible typography, loading presentation, and sprint documentation.
  • Tyron — API and performance: startup and battle-path optimisations, request/pool observations, and notification-listener isolation.
  • Uzair — database and operations: durable idle-worker coordination, ranked expiry during Redis outages, and scheduler deployment guidance.
  • Team — quality and final delivery: cross-journey regression checks, deployment verification, unresolved findings, and submission evidence.

This coordination plan is reconstructed from recurring commit authorship and existing team roles; it is not a retained meeting assignment.

Action Items​

  • Begin with public startup and Explore navigation, then finish collection and battle interfaces.
  • Review each optimisation against transaction, privacy, accessibility, and recovery requirements.
  • Collect production-like measurements separately from local structural tests.
  • Keep release notes, deployment configuration, and sprint evidence aligned with merged work.

Sources​

Daily Scrum 1 — 29 September–1 October 2026 reporting window​

Reporting point: 29 September–1 October 2026 reporting window.

Meeting photo​

Sprint 4 supplied team-call photo 2
Supplied Sprint 4 photo 2, displayed with Daily Scrum 1.

Summary of Progress​

  • Homepage work reserved the shell layout and right-sized artwork (PR #333). Commit 5b76e39 reports local production-build Lighthouse results; these are recorded local measurements, not deployed acceptance.
  • First-install service-worker navigation was corrected, and CPU-match code was deferred from public startup (PR #334, PR #335).
  • Explore gained clearer navigation, trail-stop numbering, territory detail, map layers, and campus-time presentation (PR #336).
  • Collection artwork was resized, CPU battle presentation delays were reduced, and deck hydration reads were reduced (PR #337–PR #339).

Blockers and Open Questions​

  • Public startup, signed-in restoration, and a first CPU battle have different loading boundaries and need separate checks.
  • Smaller artwork and deferred modules still need sharp previews, safe chunk-load recovery, and responsive layouts.
  • Local Lighthouse measurements do not establish performance on the deployed mobile journey.

Actions Taken​

  • Separated public startup work from the optional CPU battle module.
  • Kept location guidance, map/list recovery, and trail/territory navigation visible during Explore refinements.
  • Reduced presentation and hydration overhead while retaining existing battle state and deck rules.

Next Actions​

  • Complete collection, deck, evolution, and trade interfaces.
  • Reduce battle-action reads without weakening version, identity, or turn checks.
  • Verify first visits, reloads, and mobile card previews against the changed loading paths.

Sources​

Daily Scrum 2 — 2–3 October 2026 reporting window​

Reporting point: 2–3 October 2026 reporting window.

Meeting photo​

Sprint 4 supplied team-call photo 3
Supplied Sprint 4 photo 3, displayed with Daily Scrum 2.

Summary of Progress​

  • PvP action-path reads were reduced (PR #340). Collection, decks, evolution, and trade presentation were refined (PR #341).
  • Player profiles gained owner editing, cropped pictures, statuses, favourite owned cards, activity, and achievement presentation (PR #342). Commit 6514154 includes migration 0064 and ownership/deletion boundaries.
  • Author workspaces and analytics were streamlined, including review, catalogue, placement, sidebar, and shared loading work (PR #343).
  • Player battle lobbies, shared history, and completed battle reports were refined (PR #344).

Blockers and Open Questions​

  • Profile favourites must retain exact owned-card IDs, and editing must remain owner-only.
  • Trade, evolution, placement, and battle UI changes must preserve confirmation, version-conflict, and recovery behavior.
  • Merge history contains migration-expectation, focus, responsive-metadata, and fixture repairs; these need to stay aligned with the product contracts.

Actions Taken​

  • Grouped related player actions and reduced repeated labels across collection, trade, and battle interfaces.
  • Kept profile publication opt-in and progression server-authoritative.
  • Added reusable Author and battle presentation while keeping saved results and historical context visible.

Next Actions​

  • Finish account settings and accessible reading preferences.
  • Optimise invitation acceptance and match-detail reads.
  • Check mobile layout, native picker interactions, keyboard focus, and migration compatibility together.

Sources​

Daily Scrum 3 — 4–6 October 2026 reporting window​

Reporting point: 4–6 October 2026 reporting window.

Meeting photo​

Sprint 4 supplied team-call photo 4
Supplied Sprint 4 photo 4, displayed with Daily Scrum 3.

Summary of Progress​

  • PvP acceptance hydration and receipt/clock work were combined, and match-ready phases gained observations (PR #345–PR #347).
  • Account settings were simplified, and shared typography and accessible reading preferences were integrated (PR #348, PR #349).
  • Match-detail reads and initial acceptance writes were consolidated (PR #350, PR #351). Terminal-result focus checks were made asynchronous (PR #352).
  • PostgreSQL pool pressure observations were added, and ranked settlement reused already-loaded policy (PR #353, PR #354).

Blockers and Open Questions​

  • Fewer queries do not by themselves prove lower end-to-end latency; database wait, identity, network, and client preparation remain separate costs.
  • Focus assertions must wait for effects without hiding missing focus or broken recovery.
  • Pool observations must identify operational pressure without logging SQL parameters, credentials, or player identifiers.

Actions Taken​

  • Reduced repeated hydration and writes within existing acceptance and settlement boundaries.
  • Kept account recovery, deletion, accessibility preferences, and developer-key behavior available while simplifying settings.
  • Added request-phase and pool-holder evidence for diagnosing slow paths before further architectural changes.

Next Actions​

  • Correlate pool waits with controlled battle and session-restoration requests.
  • Finish Explore route/startup optimisation and app-wide loading recovery.
  • Investigate idle-worker wake behavior and persistent listener occupancy using the new observations.

Sources​

Daily Scrum 4 — 7–8 October 2026 reporting window​

Reporting point: 7–8 October 2026 reporting window.

Meeting photo​

Sprint 4 supplied team-call photo 5
Supplied Sprint 4 photo 5, displayed with Daily Scrum 4.

Summary of Progress​

  • Homepage-to-Explore navigation retained the SPA path, and mobile map startup work was reduced (PR #355, PR #359).
  • App-wide loading and retained-refresh behavior were integrated, including safe slow-load recovery and background saved-attempt sync (PR #360). The merge includes the work referenced by issues #356 and #357.
  • Idle gameplay coordination and operational guidance were integrated (PR #361). Commit d137554 keeps existing ranked expiry and due territory settlement available during Redis outages.
  • PostgreSQL LISTEN subscriptions moved to a dedicated direct pool (PR #362), while gateway reads retain the shared authoritative database path.

Blockers and Open Questions​

  • Coordinated idle scheduling remains a staged rollout; the polling default and deployment prerequisites must stay explicit.
  • Listener isolation needs the private direct LISTENER_DATABASE_URL setting and aggregate Neon session headroom checks.
  • Neither structural tests nor merged scheduling code prove deployed Neon suspension or a measured production latency improvement.
  • Loading recovery must not expose protected content or silently repeat submitted actions.

Actions Taken​

  • Kept confirmed content through revisits and refreshes and scoped loading feedback to the affected operation.
  • Separated new-work coordination from PostgreSQL-fenced existing-work cleanup during Redis outages.
  • Separated notification subscriptions from request-pool capacity and documented startup, reconnect, and shutdown checks.

Next Actions​

  • Complete the remaining submission-period work after this 8 October snapshot.
  • Provision and verify listener configuration before the corresponding release.
  • Run the documented hosted coordination, outage, recovery, and signed-in journeys against a named revision.
  • Record measured outcomes, unresolved findings, and actual stakeholder review results in the release evidence.

Sources​

Backlog Refinement — 29 September–8 October 2026 evidence window​

Reporting point: 29 September–8 October 2026 evidence window.

Discussion​

Refine final-submission work around the most visible player friction and the operational risks exposed by latency and pool observations. These topics are reconstructed from the sequence of UI, performance, test-repair, and deployment commits.

Completed or Mostly Completed Items​

  • Homepage/Explore startup, artwork sizing, CPU battle presentation, and battle database-path refinements were merged.
  • Collection, decks, evolution, trading, profiles, Author workspaces, account settings, and typography changes were merged.
  • Loading/recovery, retained refresh, pool observations, idle coordination, and listener isolation were integrated in the repository.

Items Needing Refinement​

  • Define deployment prerequisites and checks for the direct listener endpoint and staged scheduler backend.
  • Separate local timing/structural evidence from hosted latency, multi-instance behavior, and idle suspension.
  • Keep signed-in account lifecycle, multiplayer recovery, accessibility, and mobile journeys in final regression scope.
  • Confirm which submission-period findings remain open using their actual tracker and retest evidence.

Backlog Decisions​

  • Group presentation work by complete journey and keep state-changing behavior tied to existing API contracts.
  • Reduce repeated database work before increasing connection capacity or changing gameplay semantics.
  • Keep Redis-fenced work creation and PostgreSQL-only existing-work cleanup distinct.
  • Treat operational rollout and measured acceptance as follow-up work even when the implementation PR has merged.

Action Items​

  • Finish a traceable submission checklist with revision, environment, result, and remaining limitations.
  • Collect a small controlled request sample alongside pool and scheduler observations.
  • Record actual review outcomes and retests when the corresponding sessions occur.

Sources​

Sprint Review — 8 October 2026 (interim)​

Reporting point: 8 October 2026 — interim review snapshot.

Implementation Available for Review​

  • Public startup, Explore navigation/maps/trails, card artwork, and CPU battle entry (PR #333–PR #339, PR #355, PR #359).
  • Collection, deck, evolution, trade, profile, Author, completed-battle, account, and typography presentation (PR #341–PR #344, PR #348, PR #349).
  • Battle action, invitation acceptance, match detail, ranked settlement, and pool observations (PR #340, PR #345–PR #347, PR #350–PR #354).
  • Loading/recovery, retained refresh, idle coordination, and dedicated notification listening (PR #360–PR #362).

Accepted Items​

The merge register establishes repository integration through a9dca04. No original Sprint 4 stakeholder acceptance or release sign-off was supplied; this interim reconstruction does not close the sprint or the final-submission gate.

Review Notes​

  • The increment concentrates on refining and stabilising journeys already delivered in earlier sprints.
  • The homepage commit reports a three-run local mobile Lighthouse median increase from 60 to 87 and CLS from 1.935 to 0; retain its local production-build qualification.
  • Profile work retains owner-only editing, opt-in sharing, exact owned-card favourites, and account-deletion cleanup.
  • Loading work retains protected identity gates and operation-specific mutation recovery.
  • Idle scheduling and listener changes include operational prerequisites; polling-to-coordination rollout, hosted outage/recovery checks, and production measurements remain separate evidence.
  • The roadmap targets final submission on 11 October. Work after this 8 October snapshot remains outside the report.

Follow-up Items​

  • Demonstrate the agreed player and Author journeys on the named submission build.
  • Verify listener configuration, Neon connection headroom, and staged scheduler requirements.
  • Record mobile, accessibility, account lifecycle, saved-attempt, and multiplayer recovery outcomes.
  • Link each remaining finding to its owner, change, and focused retest; record actual reviewer feedback.

Sources​

Sprint Retrospective — 8 October 2026 (interim)​

Reporting point: 8 October 2026 — interim retrospective reconstruction.

What Went Well​

  • Journey-based interface passes improved consistency across Explore, collection, battles, profiles, Author, and settings.
  • Performance changes targeted concrete costs: artwork transfer, module startup, presentation delays, repeated hydration, writes, and policy reads.
  • Focus, fixture, migration, and responsive repairs were retained alongside the feature work.
  • Pool observations informed later operational changes, and scheduler/listener documentation retained rollout and recovery requirements.

What Did Not Go Well​

  • Follow-up commits repaired asynchronous focus assertions, fixture state, migration expectations, and validation alignment after larger interface changes.
  • Repository delivery and local checks still need separate hosted, stakeholder, and manual release evidence.
  • Connection occupancy and idle-worker wake behavior required additional work late in the submission period.
  • Contemporaneous meeting minutes and photo-to-meeting mappings were not retained in the supplied material.

Lessons Learned​

  • Review loading, recovery, focus, and responsive states as part of the journey rather than after the visual pass.
  • Use request-phase and pool evidence to identify a bottleneck before changing architecture.
  • Design outage handling around existing work as well as new-work creation.
  • Keep implementation completion, deployment configuration, measured benefit, and release acceptance separately traceable.

Action Items for Final Submission​

  • Interface streams: finish named desktop/mobile and accessibility journeys with actual results and unresolved limitations.
  • API/data streams: verify direct listener configuration, connection headroom, scheduler rollout, and outage/reconnect behavior.
  • Team: retain the final revision, deployment details, review outcomes, findings, and retests with the submission record.
  • Sprint coordination: record future meeting dates, attendees, concise decisions, and photo mappings at the time.

These are reconstructed recommendations; no team vote or acceptance of an action is inferred.

Sources​

Sources and Record Status​

Delivery evidence​

The Sprint 4 evidence retains the dated merge register, immutable commit references, and outstanding acceptance limits.

Image provenance​

For presentation, photo 1 appears beside planning, followed by photos 2–5 beside Daily Scrums 1–4. This follows the earlier sprint layout; it does not establish which meeting each image depicts.

The site's meeting-01.png through meeting-05.png are byte-for-byte copies of the supplied 1.png through 5.png. Filenames establish supplied order; they do not establish attendance, dates, discussion, or decisions.

No Review or Retrospective photo is assigned.

AI declaration​

The original ceremony narratives used repository history, project documentation, and the supplied vitaqsprint.pdf layout reference with assistance from Codex[GPT-6].

Report consolidation and simplification assisted by Codex[GPT-6]. Repeated agendas, workflow instructions, and source notices were removed; historical dates, photo provenance, and evidence limits are unchanged. No meeting, attendance, quotation, acceptance, or test result is inferred from this edit.