# MVP QA Gates

Version `0.1.Q` turns the current survival MVP into a repeatable test target.
Each gate must have either automation, a documented manual test, or build
evidence before it is marked complete.

## Packaged Client Launch

The packaged client launch gate proves the Windows investor/demo package can be
created, opened through a known launcher, and checked through the real-GPU
visual QA path.

Required evidence:

- `Scripts/PackageWindowsDevelopment.bat` completes successfully.
- `Builds/WindowsDevelopment/AgrarianGame.exe` exists.
- `Scripts/InstallWindowsDemoLaunchers.bat` installs:
  - `Start Agrarian Demo.cmd`
  - `Start Agrarian Demo - DX12.cmd`
  - `Start Agrarian Demo - Compatibility DX11.cmd`
- `Scripts/RunWindowsInvestorVisualQACheck.bat --check-tools` reports the
  packaged demo exists and `SunshineService` is running.
- Any full visual pass stores notes under `Saved\VisualQA\InvestorDemo`.

This gate is client-only. It does not require multiplayer server deployment.

## Server Launch

The server launch gate proves the MVP gameplay host can start the current
server-compatible package and expose the Unreal gameplay port.

Current MVP launch path:

- Prefer the true Linux dedicated-server target when a server-capable Unreal
  engine is available:
  `Scripts/BuildLinuxDedicatedServer-Windows.bat`
- Until then, use the binary-engine fallback:
  `Scripts/PackageLinuxGameServerFallback-Windows.bat`
- Deploy the produced package to `/opt/agrarian/server`.
- Launch through `/opt/agrarian/server/AgrarianGameServer.sh`.
- Manage the host with `agrarian-game-server.service`.

Required evidence:

- `systemctl is-active agrarian-game-server.service` reports `active`.
- `ss -lunp` shows `AgrarianGame` listening on `0.0.0.0:7777/udp`.
- The journal shows the Ground Zero map browse started.
- The runbook explains the true dedicated target and fallback path.

This gate is server-relevant and requires multiplayer server verification when
server launch tooling or deployed package contents change.

## Two-Client Connection

The two-client connection gate proves the MVP can be tested as a multiplayer
session with two packaged Windows clients connected to the same Ground Zero
server.

Required evidence:

- The server launch gate is passing.
- `Scripts/RunTwoClientConnectionSmoke-Windows.bat --check-tools` confirms the
  packaged client exists.
- The helper launches two clients against the same endpoint:
  `play.agrariangame.com:7777` by default, or a supplied LAN endpoint such as
  `192.168.5.15:7777`.
- Both clients reach the same Ground Zero session.
- Testers confirm both clients see the same time/weather and can remain
  connected long enough to begin the smoke test.

The manual observation steps continue in
`Docs/Ops/MultiplayerLatencyTestPlan.md` until gameplay automation can drive
two clients directly.

## Resource Gathering

The resource gathering gate proves a player can interact with placed Ground
Zero resource nodes and receive authoritative resource inventory changes.

Required evidence:

- Ground Zero includes placed wood and fiber resource nodes.
- `AAgrarianResourceNode` exposes `Gather` or `Gather by hand` prompts.
- Gathering runs only with server authority.
- Successful gathering decrements replicated `RemainingHarvests`.
- The gathered item stack is granted through the character inventory path.
- Resource depletion persistence is covered by the save/load gate.
- `Scripts/verify_playable_loop_smoke.py` includes wood and fiber gathering in
  the natural shelter loop smoke test.

This gate is gameplay/server-relevant and should be covered by the next server
package deployment.

## Craft Shelter

The craft-shelter gate proves the MVP can build a primitive shelter path from
resources through recipes and world placement.

Required evidence:

- Primitive frame, wall panel, roof panel, and shelter recipes exist.
- `BP_PrimitiveShelter` derives from the native shelter actor.
- Building placement consumes active buildable cost on the server.
- Shelter actors persist through the world-actor persistence path.
- `Scripts/verify_playable_loop_smoke.py` runs the natural shelter loop using
  wood, fiber, wildlife, shelter-piece recipes, and the primitive shelter class.

This gate is gameplay/server-relevant and should be covered by the next server
package deployment.

## Craft Fire

The craft-fire gate proves the MVP can produce or use a campfire through the
crafting/building loop, then interact with that fire in the world.

Required evidence:

- `DA_Recipe_Campfire` exists with the `campfire` recipe ID.
- The campfire item/buildable path is available to the player blueprint setup.
- `BP_Campfire` derives from `AAgrarianCampfire`.
- `AAgrarianCampfire` supports `Light fire` and `Maintain fire` interaction
  prompts.
- Campfire lit/fuel state is replicated.
- Campfire persistence and fire-risk QA verifiers pass.

This gate is gameplay/server-relevant and should be covered by the next server
package deployment.

## Full Day/Night Survival

The full day/night survival gate proves one player can remain alive through one
complete compressed Agrarian day while the server advances time, weather, and
survival pressure.

MVP timing:

- The gameplay calendar target is `4 real hours = 1 in-game day`.
- `AAgrarianGameState` advances and replicates `WorldHours`, day/year state,
  solar bounds, `IsNight`, weather, and ambient temperature.
- The pass starts at a known hour, preferably dawn or morning, and ends after
  `WorldHours` reaches the same solar phase on the next in-game day.

Required evidence:

- Hunger, thirst, stamina, body temperature, and health update over time on
  server authority.
- A player can gather resources, craft or use a fire, craft or use shelter,
  and recover enough food/water/warmth to avoid death for the full cycle.
- Day/night state changes at least once and returns to the original phase.
- The critical survival HUD can show alive/dead state and core stat pressure.
- World time and player survival state are covered by save/load persistence.
- The result is recorded as either a completed manual run or a captured test
  log before external MVP demos treat the gate as fully play-proven.

This gate is gameplay/server-relevant and should be covered by the next server
package deployment.

## Survival Pressure Death

The survival-pressure death gate proves the MVP does not merely display hunger,
thirst, exposure, illness, or injury as cosmetic stats. Sustained pressure must
be able to reduce health, mark the character dead, replicate the death state,
and expose a clear respawn path.

Required evidence:

- Starvation, dehydration, cold exposure, sickness, and bleeding can reduce
  `Survival.Health` on server authority.
- `ClampSurvival` calls `UpdateDeathState`, clamps health to zero, clears
  stamina, sets `bIsDead`, and records `LastDeathReason`.
- The replicated survival snapshot includes the death state and last death
  reason.
- The critical survival HUD and death/respawn panel display the dead state and
  cause.
- The player controller exposes the MVP respawn path and revives the survival
  component on the server.
- Death/respawn behavior remains persistence-safe through the player stat
  save/load path.

This gate is gameplay/server-relevant and should be covered by the next server
package deployment.

## Reconnect State Retention

The reconnect state retention gate proves a player can disconnect, reconnect,
and recover the MVP state that matters for a continuing survival session instead
of starting over from a blank pawn.

Required evidence:

- `AAgrarianGameGameMode::Logout` captures a player snapshot before the pawn is
  released.
- `AAgrarianGameGameMode::RestartPlayer` restores a matching snapshot after the
  normal MVP spawn path.
- `UAgrarianPersistenceSubsystem::SavePlayerSnapshot` and
  `RestorePlayerSnapshot` preserve transform, safe player identity, survival,
  care history, and inventory.
- Inventory restore uses `RestoreSavedItems` so derived carry weight and
  inventory listeners refresh after reconnect.
- If no matching snapshot exists, the player falls back to the normal MVP spawn
  point instead of failing the join.
- The manual two-client test records reconnect evidence alongside world
  time/weather consistency.

This gate is server-relevant and must be rechecked after multiplayer package
deployment.