aetherbound-guild/docs/reference/USER_PLAY_VIDEO_STUDY_2026-08-11.md

# User-Play Video Study, 2026-08-11

## Decision Boundary

This study records generalized behavior from one authorized private user-play
recording. It does not transfer names, prose, formulas, prices, layouts, art,
audio, code or other expressive material. No third-party frame is stored in
this repository. The complete private evidence package remains outside Git.

The decision enabled by this study is whether Aetherbound Guild should retain
its compact current deployed line or adopt an independently authored larger
Company-growth envelope before any runtime implementation begins.

## Source And Evidence

- Source SHA-256:
  `188373d2bc3686afb74815f9f6aa9ff3abc59708dda2618ca2ea843d4f46358b`
- Duration: `00:51:12.939`; 1280x720 video with stereo audio.
- Private evidence root:
  `/Users/wusumac/Documents/game-reference-archive/dwarves-glory-death-and-loot/2026-08-11-user-video/`
- Three fixed time segments retain 25 native source frames each, 75 total.
- Every segment has a 25-row SHA-256 screenshot manifest verified against the
  final files. Product Git remains free of those commercial frames.
- Phase 2 adds nine source-bound interaction clips and 841 sequentially decoded
  one-second states. Only `phase2/sequences-r3/` and
  `phase2/contact-sheets-r3/` are valid timeline samples; two earlier sampling
  attempts are retained privately as `INVALID_TIME_BINDING`.

## Directly Proven Behavior

### Run Arc And Scale

- The recording enters a new run, shows preparation, advances through repeated
  automatic battles and results, then ends when the eight-member side reaches
  zero while one boss-side unit remains. The resulting game-over report shows
  59 accumulated victories before returning to the title screen.
- The final report has eight Company result rows and awards 35 units of a
  persistent resource. The displayed time field is not interpreted because
  its unit and relationship to the edited recording are unknown.
- The visible roster grows from two occupied members to seven, then later
  reaches eight. A roster occupancy display shows `8/10`; eight members are
  also simultaneously represented in live battle.

### Preparation And Economy

- Repeated recruit offers expose unequal prices, role/profession presentation
  and multiple attributes before commitment.
- One continuously observed recruit transaction reduces the displayed balance
  by the candidate's displayed price and changes the occupied roster from two
  to three. Separate observed item transactions reduce balance and increase
  backpack occupancy.
- Member inspection exposes level, attributes, weapon category, attack
  interval and an active-ability field.
- Equipment has multiple member slots and tooltips with eligibility, stats,
  conditional behavior and sell value. The visible backpack capacity is 22,
  and a separate paged storage surface is present.
- Visible shop levels include 4, 6, 8 and 9. The recording includes ordinary
  three-offer states, a broader shop with at least eight visible offers,
  shop-upgrade information and recurring zero-price three-choice states.
- A continuously observed shop-level transition changes the displayed balance,
  level, visible offers and next-upgrade information. A forge sequence places
  matching inputs, plays a transformation response and leaves a higher-tier
  output in inventory; its recipe and formula remain unknown.
- Results separate per-member condition rows from no-loot, one-item and
  multi-item reward variants.

### Battle

- Battle resolves without a visible normal target or skill command. Opposing
  groups advance from the sides, meet near the center and exchange actions.
- The HUD exposes aggregate side state, living-unit counters, per-member
  status, elapsed time, speed and local numerical/effect feedback.
- Sampled ordinary victories follow the opposing living-unit count reaching
  zero and transition into a separate result presentation. The recording does
  not support line crossing as the ordinary victory rule.
- Two separately resolved battles begin by expanding the visible member-state
  panels from two to seven and from three to seven during the opening second.
  A victory, report, preparation state and fresh encounter selection separate
  those battles. The sequence supports staggered battle entry, not a seven-to-
  three collapse or a same-battle revival claim.
- The terminal boss sequence visibly reduces the Company counter from eight to
  zero while the opposing counter remains one, emits member-death messages and
  opens the game-over report. This directly establishes a party-wipe run
  terminal for the observed mode.
- Forest, cave, red-rock/open and snow-field presentations are directly seen.

## Explicit Unknowns

- The recording does not prove same-battle respawn, reserve auto-entry,
  permanent-loss confirmation, retreat settlement or the exact rule behind
  staged entry-panel expansion.
- Ten is a displayed roster capacity in this state, not a proven universal
  mode limit or a total number of recruit identities.
- The final report explicitly says the 35-unit award can be spent in a
  persistent upgrade surface to improve later members, but the recording does
  not open that surface or prove its prices, tree or carry-over formula.
- The recording does not enumerate complete professions, skills, equipment,
  artifacts, enemies, bosses, regions, chapters, modes or achievements.
- Narration and the mixed recording prevent reliable event-to-audio mapping.

## Reconciliation With Earlier Research

The earlier private observation proved a separate 12-victory completed run.
This new 59-victory result does not contradict it: both values are exact only
for their recorded run and mode state. The new recording strengthens runtime
lower bounds for Company size, shop progression, storage and environment
coverage, but does not convert any package file count into a gameplay count.

The Phase 2 evidence corrects three unsafe interpretations:

1. The apparent three-panel state is a new battle's first second and expands to
   seven on the next sampled second; it is not evidence of seven units
   shrinking to three or of same-battle revival.
2. Moving battlefield composition does not prove boundary crossing as a base
   victory condition; sampled victories instead follow enemy elimination.
3. The 59-victory report is a defeat terminal after a party wipe, not proof of
   campaign completion or a fixed 59-stage mode.

## Phase 3 Public-Video Reconciliation

Phase 3 adds three source-bound public-video lanes while keeping all commercial
clips and frames outside this repository. The private combined report and its
evidence manifest are under:

`/Users/wusumac/Documents/game-reference-archive/dwarves-glory-death-and-loot/2026-08-11-public-video-phase3/`

The public evidence changes the death model materially:

- `PROVEN`: ordinary combat and ultimate activation are automatic. The visible
  battle controls are camera mode, speed, pause and retreat, rather than normal
  per-member movement, targeting or skill timing.
- `PROVEN`: the three displayed difficulty descriptions use different loss
  rules. The forgiving mode revives the whole roster after a wipe and deducts
  victories; the normal mode revives individual casualties after a victory but
  ends the run on a full-party wipe; permanent death is explicitly limited to
  the hard mode.
- `PROVEN`: these are between-battle or mode-level recovery rules. No retained
  continuous sequence shows a defeated member returning during the same active
  battle. One late item tooltip discloses fatal-hit prevention, but its trigger
  was not observed.
- `PROVEN`: a late run reaches a visible `10/10` roster, fields ten members,
  reaches shop tier 10, uses a 22-slot carried inventory and exposes a separate
  `7/10` storage surface. These are exact observed states, not universal caps.
- `PROVEN`: preparation depth includes a recipe browser with three input cells,
  a consumptive individual passive/veteran operation, profession-labeled
  equipment, a formation-card catalog with four populated active slots, a
  connected Rune Circle and named loadout-management UI.
- `PROVEN`: one continuous guide segment shows a prepared ten-member roster,
  automatic boss combat, enemy count reaching zero, victory treatment and a
  return to the hall. Whether that victory completes the run remains unknown.
- `PROVEN`: separate runs terminate at 30, 59 and 126 accumulated victories and
  show different persistent awards. A 100-victory milestone also grants a
  persistent award and unlocks an optional future-run mode. None of these
  values establishes a universal reward formula or authored stage total.

Version boundaries remain explicit. One title page visibly reports `v1.24.0`.
The long-run source is only `LIKELY` version 2.0 because that claim comes from
narration, not a retained in-game version label. The endgame guide's exact
build is unknown. Values and mechanics that differ across these sources must
not be averaged or silently treated as one current build.

Public-video edits and speed changes also prevent any valid inference about
normal run duration, decision density or real-time pacing. Exact content totals,
formulas, audio-event mappings, retreat settlement, hard-mode cleanup and
cross-session save behavior remain unknown.

## Phase 4 Replication-Readiness Closure

Targeted Phase 4 evidence closes the remaining structural blockers without
copying reference content or formulas. The private report is:

`/Users/wusumac/Documents/game-reference-archive/dwarves-glory-death-and-loot/2026-08-11-public-video-phase4/PHASE4_REPLICATION_READINESS_ZH.md`

- `PROVEN`: a continuous Rune Circle operation spends rune points and visibly
  illuminates connected path segments. An advanced-profession node visibly
  requires two adjacent completed paths plus a separate currency cost. Refund
  and reset behavior remain unknown.
- `PROVEN`: a complete public mobile walkthrough uses a landscape layout. Its
  in-game tutorial explicitly instructs Tap operations for reroll, member
  pickup/position exchange and item sale, and shows item placement into
  inventory. The recording does not expose physical touch coordinates or drag
  thresholds.
- `PROVEN`: one boss-ladder source visibly identifies a seventh boss at round
  300, then shows three elemental dragon fights before a separate final Raid
  encounter. It is evidence of staged boss escalation, not a complete content
  count or timing model.
- `PROVEN`: an independent continuous final-Raid recording shows a ten-member
  side defeat the final boss, then displays the authoritative choice to keep
  guiding the current clan or send its members into retirement. Final-boss
  victory therefore does not force the current run to stop.
- `PROVEN_UI_ONLY`: a Tavern explanation exposes an experience-recovery loop
  between battles, a distributable progression resource and retiring members.
  No retirement transaction was performed, so confirmation, equipment cleanup,
  roster mutation and persistence remain unknown.
- `PROVEN`: a retained title screen directly reports `v2.0.0`; it is separate
  from the independently visible `v1.24.0` source.

The reference record is now sufficient for independent product-contract and
mobile-prototype design of the high-level experience. It remains insufficient
for a one-to-one claim about every profession, item, enemy, formula, layout,
audio event or content total. Those gaps should be independently authored and
validated rather than reconstructed from commercial expression.

## Product Implications, Not Reference Facts

The reference evidence demonstrates that visible Company growth can carry a
long run: recruitment changes the battle silhouette, preparation density and
result report. Aetherbound's current compact line is an original product
choice, but it now requires explicit Owner review because it may underdeliver
the requested large-recruit fantasy.

The recommended independent envelope is:

`two-member opening -> ten-member run roster -> deployed capacity grows through
four, six and eight -> no same-battle respawn -> no automatic Reserve entry ->
ordinary victory requires eliminating the enemy group`

This is not yet product authority. It would require one coherent revision of
the game contract, battle system, economy, save/failure rules, screen map,
interactive prototype, simulation fixtures and validators. Formal runtime
development remains frozen.

## Shortest Next Action

Owner reviews the Phase 4 replication-readiness decision and then authorizes or
rejects an original product-contract and landscape mobile-prototype revision;
runtime implementation remains frozen.