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.