All 100 questions are answered. Read the processed implementation decisions, or download the original answer sheet.

Prototype interview — editable answer sheet

Prepared 2026-09-08. This is an interview, not a list of approved changes. Remote play is excluded.

How to answer

• Edit the blank Answer: line under any question. Short answers are welcome. Write Agree to accept its recommendation, or describe the behavior you want.
• Answer in any order. Keep the question IDs so another agent can process the file reliably.
• You can use a section's Section answer: line to write Accept this section except Q012 and Q015, then answer those exceptions separately. A specific question answer overrides a general section answer.
• A blank, Unsure, or Discuss means unresolved. Recommendations are not approvals. Nothing is preselected.
• The RULE sections A–D cover remaining design gates. Start there if you want to unblock mechanics work. PREFERENCE sections E–L can be answered later or in any order.
• Feel free to add notes, sketches, links, or examples below an answer. You do not need to use technical terms.
• Save this file and tell me it is ready. I will extract explicit answers, identify conflicts or follow-ups, and update the rulebook and task contracts in one batch. I will not treat completing this interview as implementing the features.

If you have little time, start with Q001–Q006, Q010–Q016, Q017–Q021, and Q024–Q032. Those cover the action budget, match results, climbing Heat, and roster/match rules. The other questions are available whenever you have time.

Confirmed decisions — no need to answer again

• All nine local prototype feature areas are approved. Remote play is excluded.
• Assembly uses a core box, empty component outlines, any-order part selection, and manufacturer browsing. Arms and held equipment are separate. Limits are hard. A two-handed weapon uses both hands, remains usable with one disabled arm under penalties, and cannot be targeted separately from its arms.
• Melee uses fresh up-front pools per Full attack, with successful dice shared between attacks and parries. Failed dice fund neither. Higher Piloting acts first; ties favor the initiator. The defender keeps its normal activation. Dual wielding and shields remain legitimate choices.
• Players roll a d6 for board-end choice and reroll ties. The winner chooses the end; the loser places first. Deployment alternates and flows directly into alternating activations. The first placer activates first. There are no new initiative rolls at round boundaries.
• Score after all surviving mechs have activated and refresh their Reactions. Activation order continues across that boundary.
• Prepare costs a Quick action and leaves eligible reaction/weapon selection open until a trigger. Overwatch arms itself with a Full action and keeps its named weapon. Melee parries are independent.
• Declining preserves the Reaction and Prepared/Overwatch until normal expiry. Multiple friendly reactions to one event resolve in the player's chosen order, with a new choice after each result.
• Overwatch covers a fixed area at a chosen map location and one elevation. Prototype size is a center hex plus six neighbors on that elevation. Both players can see it. Movement into or within it offers a shot where range and LOS permit. Choose an eligible firing point on the declared path or pass.
• Disengage resolves before leaving adjacency. Overwatch resolves at the selected watched hex. Surviving mechs continue their declared movement if able. Reaction attacks cannot trigger further reactions.

The latest reaction package is approved in the design documents but is not implemented in the current engine. The same distinction applies to the new deployment/activation order. See the implementation specification and docs/reviews/2026-09-08-session-handoff.md for baseline and handoff details.

Section index

• A. Overcharge — Q001–Q008 · RULE
• B. Scoring, endgame, and round boundaries — Q009–Q016 · RULE
• C. Climbing, Heat, and movement — Q017–Q023 · RULE
• D. Roster lock, deployment reveal, and match flow — Q024–Q033 · RULE
• E. Reaction and watch-area interface — Q034–Q041 · PREFERENCE
• F. Board layout and tactical inspection — Q042–Q051 · PREFERENCE
• G. Dice, combat pacing, and feedback — Q052–Q058 · PREFERENCE
• H. Workshop, library, and build comparisons — Q059–Q068 · PREFERENCE
• I. Saving, resuming, and replay — Q069–Q076 · PREFERENCE
• J. Sandbox and repeatable trials — Q077–Q084 · PREFERENCE
• K. Playtest reports and feedback — Q085–Q092 · PREFERENCE
• L. Learning, accessibility, and completion priorities — Q093–Q100 · PREFERENCE

A. Overcharge

Type: RULE · Work packages: TASK-037 / TASK-055

The written rule gives a third Quick action for escalating Heat. Its interaction with Full actions and the scope of escalation need a decision. These recommendations are proposals, not recorded approvals.

Section answer:

Q001. What action budget should Overcharge allow?

Recommendation: Grant one extra Quick once per activation: three Quicks, or one Full plus one Quick. It never grants a second Full. Keep the normal movement allowance.

Answer: We just should not do this, lets get rid of this overcharge concept.

Q002. Who accumulates the escalating Heat cost, and when does it reset?

Recommendation: Track it separately for each mech. Reset at the start of each game, including the next game of a match.

Answer: See 001

Q003. Should we retain the current Heat-cost sequence?

Recommendation: Use +1 on the first use, 1d3 on the second, 1d6 on the third, and 1d6+4 on the fourth and every later use that game. Treat these as tunable prototype values.

Answer: see 001

Q004. When should the Heat and any reactor stress resolve?

Recommendation: Commit Overcharge, pay or roll its Heat, then resolve stress before using the extra Quick. A destroyed mech cannot use it. The player cannot cancel after seeing the roll.

Answer: see 001

Q005. Can a player Overcharge after spending their ordinary actions?

Recommendation: Yes, until they explicitly end the activation. Keep End Activation available instead of automatically advancing as soon as the ordinary action budget is empty.

Answer: see 001

Q006. How should Overcharge interact with action penalties and restrictions?

Recommendation: Add exactly one Quick to the remaining allowance. Keep lost-action penalties, Fire once per activation, Brace/Boost restrictions, and equipment restrictions. Overcharge does not reset those flags.

Answer: see 001

Q007. What should repeated Overcharge feel like during a typical game?

Recommendation: A tempting first use, followed by increasingly risky emergency pushes. It should not become a compulsory extra action every activation. Describe a different intended feel if you have one.

Answer: see 001

Q008. How adventurous should bots be with Overcharge?

Recommendation: Start with a conservative policy that uses it for an immediate tactical benefit. Expose an aggression setting in the lab so later tuning can compare policies.

Answer: see 001

B. Scoring, endgame, and round boundaries

Type: RULE · Work packages: TASK-038 / TASK-056; TASK-053 for round transitions

Continuous activation order and Reaction refresh at scoring are confirmed. These questions cover the remaining result rules and status durations, not whether to roll initiative again.

Section answer:

Q009. Should the standard game still stop after seven normal rounds?

Recommendation: Keep seven as the first prototype cap, configurable in sandbox. Show how many scoring boundaries remain.

Answer: 7 feels right because there is a mid point, but 10 is cleaner, we can experiment with this as a balance point in the prototype.

Q010. What should decide the result before sudden death?

Recommendation: An enemy-team wipe wins immediately. Otherwise, at the cap compare score first, then remaining team Hull percentage. Keep the current 3 points per kill and 1 per controlled zone as provisional values.

Answer: Recommendation

Q011. How should remaining team Hull percentage be calculated?

Recommendation: Divide remaining body-part durability across surviving deployed mechs by the total starting body-part durability of the original deployed three. A destroyed mech contributes zero remaining durability. The reserve does not count. This is an explicit proposed definition to test against current engine behavior.

Answer: Recommendation

Q012. What should an exact score-and-Hull tie trigger?

Recommendation: Play one complete extra round, carrying activation order forward normally. Both sides receive their normal activation and Reaction opportunities. A wipe can still end the game immediately.

Answer: Sure lets do a bonus round

Q013. How should that extra round be scored and judged?

Recommendation: Score its objectives normally, then compare score and Hull again. This deliberately differs from the current text, which says to compare Hull again; choose Hull-only if that better fits your intent.

Answer: Should just recore the game like normal

Q014. What should happen if the extra round still ends exactly tied?

Recommendation: Declare a drawn game. Do not add an indefinite series of extra rounds or choose a winner by another die roll.

Answer: Recommendation

Q015. How should drawn games affect the best-of-three match?

Recommendation: Play at most the three scheduled maps, stopping early when a side reaches two wins. Draws use a scheduled game slot. After the third game, more game wins takes the match; equal wins is a drawn match. This bounds match length but may end with fewer than two wins.

Answer: Recommendation

Q016. Should existing status durations continue to use their written expiry points?

Recommendation: Yes. For example, Lock On expires at the scoring boundary; Prepared and Overwatch expire at the owning mech’s next activation. Refreshing Reactions does not clear or renew every status. Keep the different expiry types visible in the inspector.

Answer: Recommendation

C. Climbing, Heat, and movement

Type: RULE · Work packages: TASK-039 / TASK-057; TASK-050 / TASK-051 for previews

The current terrain rules permit stepped elevation, give Jump legs special climbing movement, and make large drops cause falls. The missing climbing Heat behavior needs an explicit contract.

Section answer:

Q017. What should trigger Jump-leg climbing Heat?

Recommendation: The first upward step in an activation adds 1 Heat. Charge and Boost climbs share that same once-per-activation trigger. Flat movement and descents do not trigger it.

Answer: Recommendation

Q018. When should climbing Heat resolve relative to the upward step?

Recommendation: Pay it just before the first upward step and resolve stress there. Only make the step if the mech remains able. This gives an unambiguous interruption position.

Answer: Pay it as it occurs on their line of travel

Q019. What happens if climbing Heat damages the legs or destroys the mech?

Recommendation: Recheck movement legality from its current hex. Stop any step or follow-up now made illegal. Do not refund Heat or move the mech onto an unreachable rooftop.

Answer: Recommendation

Q020. Should a second climb in the same activation be free of additional climbing Heat?

Recommendation: Yes, including a later movement segment, Boost, or Charge. Clear the climbing-Heat flag at the next activation. This is a Heat rule, not a waiver of terrain movement costs.

Answer: No, each climb should give heat

Q021. Should we retain the current fall rule for a drop of two or more levels?

Recommendation: Yes: Legs take 1d6 plus 1 per full 15 Weight, ignoring Armor, and movement ends. Show the risk before committing. Keep the numbers provisional.

Answer: Recommendation

Q022. How much control should the player have over a declared movement path?

Recommendation: Suggest a legal path, then allow waypoints or individual hex choices before confirmation. Make movement cost and watched-area exposure visible so the shortest route is not forced.

Answer: when placed, we can draw an optimal legal path to that point for them, more than 1 waypoint can be placed as long as they have remaining movement available that turn

Q023. How should the UI handle a deliberately dangerous route?

Recommendation: Show a clear fall, Heat, and possible-reaction summary before confirmation. Require an extra confirmation for a deliberate fall, with a preference to suppress that extra prompt for experienced play.

Answer: Recommendation

D. Roster lock, deployment reveal, and match flow

Type: RULE · Work packages: TASK-041 / TASK-044 / TASK-058 / TASK-059

Four mechs, three deployed, one reserve, hard limits, alternating deployment, a d6 roll-off, and continuous activation order are settled. These questions concern what gets locked and revealed.

Section answer:

Q024. What information should opponents see before selecting their initial three?

Recommendation: Show both complete four-mech rosters, including equipment and pilots. Keep only the selection of the deployed three private until both players confirm.

Answer: Recommendation

Q025. When should the initial deployed teams become public?

Recommendation: Reveal both sets of three together before the board-end roll and alternating placement. Neither player gets to revise their selection after seeing the other’s choice.

Answer: Recommendation

Q026. What should be locked when a match begins?

Recommendation: Lock all four builds, equipment, ammunition selections, and pilot assignments for the match. Pilot reassignment remains available while arranging the roster before locking.

Answer: Recommendation

Q027. Should each pilot be unique across all four roster mechs?

Recommendation: Keep the written B5 rule: one copy of a pilot in the whole four-mech roster, including the reserve. Saved library builds can reuse pilots; a match roster must resolve conflicts.

Answer: Recommendation

Q028. How should the written two-copy part limit count equipment and repeated slots?

Recommendation: Count each installed copy across all four mechs. Two identical arms or two identical one-handed weapons use two copies; one two-handed weapon uses one. Count structural parts and held equipment by catalog identity; do not count the same shared core profile as different because its box name differs. This interpretation needs approval.

Answer: Lets get rid of that rule, no part limit.

Q029. How should the builder handle a legal four-mech roster whose selected three exceed Team Cap?

Recommendation: Keep the roster in the library, show which selections of three are legal, and prevent confirming an illegal deployed team. Do not require every possible trio to fit.

Answer: Recommendation + we should warn at build time that there are illegal combinations in this roster

Q030. What exactly may change between games?

Recommendation: Each player may stand pat or swap one deployed mech with their current reserve. No part, loadout, or pilot edits. A mech swapped out becomes the new reserve and can return in a later game.

Answer: Recommendation + I think ammo should be able to be changed

Q031. When should between-game swaps be revealed?

Recommendation: Collect both decisions behind a pass-device curtain, then reveal both at the start of deployment. Validate each team before its player commits. Keep the next map visible during the decision.

Answer: Recommendation

Q032. Should normal matches use the fixed Quarry, Causeway, Foundry order?

Recommendation: Keep that order for the first full local prototype. Let sandbox and single-game practice choose a map directly. Map order can be tuned later.

Answer: The 3 maps and their order should be random for a full game

Q033. How prominent should single-game practice be beside the full match?

Recommendation: Offer clear Single Game, Best of Three, and Scenario entry points. Practice may use one to three mechs per side; a normal match requires a complete four-mech roster.

Answer: We should have a BO1 and BO3 option always available, its not necessarily practice

E. Reaction and watch-area interface

Type: PREFERENCE · Work packages: TASK-047 / TASK-048 / TASK-049 / TASK-050 / TASK-054

The reaction rules are confirmed. These questions shape their presentation. They do not reopen the fixed seven-hex area, one-elevation rule, Prepare cost, decline retention, or player-chosen response order.

Section answer:

Q034. How should a player place an Overwatch area?

Recommendation: Choose the weapon, click a center tile, preview the center-plus-neighbors at that tile’s elevation, then confirm. Show the selected elevation explicitly.

Answer: Recommendation + this should probably be a cone of cover that is selected

Q035. How should the board distinguish watched tiles from tiles the weapon cannot currently shoot?

Recommendation: Keep the fixed area outline visible. Use a separate muted or hatched treatment for tiles currently blocked by LOS or outside range, with a short explanation when inspected.

Answer: Recommendation

Q036. How should overlapping friendly and enemy watch areas look?

Recommendation: Use team-colored outlines and patterns, with stronger emphasis for the selected mech. Let the player temporarily isolate one area without concealing that other areas exist.

Answer: Recommendation

Q037. How should the player choose an Overwatch firing point along a declared path?

Recommendation: Present the path once with eligible firing points highlighted. Select a point to inspect the shot, then confirm or pass this move. Avoid opening a separate dialog for every hex.

Answer: lets try the Recommendation, im not sure

Q038. How should multiple eligible reacting mechs be presented?

Recommendation: Show their mech cards beside the board. Choose one, resolve its reaction, then update the remaining choices. Include a clear Pass Remaining Reactions control for that event.

Answer: Recommendation

Q039. What should happen when reaction control switches to the other local player?

Recommendation: Show a clear actor banner and a Continue prompt before accepting input. Use a privacy curtain for hidden setup choices; ordinary combat information can remain visible.

Answer: Recommendation

Q040. What explanation should appear after a planned reaction becomes illegal?

Recommendation: Say exactly why, such as target destroyed, named weapon disabled, or LOS blocked. Preserve unspent Reaction budgets and return to the remaining legal choices.

Answer: Recommendation

Q041. How should movement resume visually after a reaction?

Recommendation: Keep the untraveled path visible during the interruption. After resolution, briefly show any changed movement limit or canceled follow-up, then continue along the legal remainder.

Answer: Recommendation

F. Board layout and tactical inspection

Type: PREFERENCE · Work packages: TASK-047 / TASK-048 / TASK-051

The board-centered layout, camera controls, and persistent inspector are approved. These questions help choose the strongest implementation for this prototype.

Section answer:

Q042. What visual treatment should the prototype board use?

Recommendation: Use a crisp 2D hex board with shallow elevation shading and modular mech silhouettes. This improves readability without making a new 3D engine a prerequisite. Describe a different visual target if needed.

Answer: Recommendation

Q043. What should get the most space on a desktop screen?

Recommendation: Give the board most of the window, with a narrow pinned inspector and compact controls near the bottom. Put the full event log in a drawer.

Answer: Recommendation

Q044. What information must always remain visible during an activation?

Recommendation: Active mech and player, remaining movement/actions, Heat, Reaction state, score, and the current required choice. Keep detailed formulas expandable.

Answer: Recommendation

Q045. What should clicking an enemy mech do when no attack is being selected?

Recommendation: Pin its inspector without changing the active mech. During an attack, make target selection a clearly labeled mode.

Answer: Recommendation

Q046. Should the camera automatically follow activations and reactions?

Recommendation: Use gentle focus on the new actor or reaction event, with an easy way to disable it. Preserve user zoom and provide a reset-to-board control.

Answer: Recommendation

Q047. How should players understand elevation at a glance?

Recommendation: Use visible level labels, stepped terrain edges, and a selectable elevation overlay. Make roofs and street-level tiles clearly distinct.

Answer: Recommendation, the board itself should have real terrain with the hex grid on top of it, but thats for full engine implementation

Q048. How should damaged body parts be shown?

Recommendation: Use a small body diagram with numeric durability, cracks or disabled markers, and a linked equipment summary. Selecting an arm should reveal which held weapon it affects.

Answer: When the unit is selected we should show little line indicators pointing to each part and show their health bar for that part. When individual parts are damage these should always be shown. We should also have an inspector card that uses the small body diagram

Q049. How much enemy information should the inspector reveal during combat?

Recommendation: Show the same public combat stats, equipment, pilot effects, and damage information available for friendly mechs. Keep only agreed private setup choices hidden.

Answer: Recommendation

Q050. How should action selection flow?

Recommendation: Select an action, then its weapon if needed, then a target or watched area, inspect the consequences, and confirm. Preserve selection when an option becomes invalid and explain the problem.

Answer: Recommendation

Q051. How should the phone layout behave?

Recommendation: Keep the board visible, use a bottom sheet for the inspector and decisions, and make dice selection reachable without precision taps. Avoid requiring hover or dragging to perform an essential action.

Answer: i have no phone plans at this time, plan for ipad at a minimum right now

G. Dice, combat pacing, and feedback

Type: PREFERENCE · Work packages: TASK-049 / TASK-051 / TASK-060

Both melee pools roll up front; successes fund both attacks and parries; failed dice fund neither. Those decisions are settled. This section concerns how players see and understand them.

Section answer:

Q052. How quickly should normal combat results play out?

Recommendation: Use brief grouped reveals, with Instant and Step Through options. Never require waiting for decorative dice animations to finish.

Answer: decorative dice animation should be very quick

Q053. How much detail should each melee die show?

Recommendation: Always show weapon source, face/result, and whether it is available, selected, spent, failed, or invalidated. Expand to show modifiers and the success threshold.

Answer: We dont care about the result number, these should only show as opportunity pips as the result of dice rolls and be consumed as they are used

Q054. Should failed and spent dice remain visible during the exchange?

Recommendation: Yes, visibly separated or dimmed. This explains how the original pool became the remaining choices instead of making dice appear to vanish.

Answer: no, they should be discarded in the dice roll animation

Q055. What should the defender see before choosing a parry?

Recommendation: The attacking weapon, chosen body part, parry cost, legal defensive dice, and a concise explanation of what accepting the hit will resolve. Do not reveal unrolled damage.

Answer: Recommendation

Q056. How should ranged attack stages be displayed?

Recommendation: Group modifier and hit rolls first, then location, penetration, damage, critical effects, and Heat. Let the player expand individual shots or replay the sequence.

Answer: the sequence should happen and we should have like a tight line that shows each stage, but ultimately floating damage numbers would be the thing they are looking for. We should show the chance to hit when selecting to fire before confirmation though

Q057. Should previews show odds or only the visible dice and thresholds?

Recommendation: Show dice and thresholds by default, with optional derived odds in an expanded panel. Never show future RNG results or imply a roll is guaranteed.

Answer: show odds as a digest when selecting, think XCOM "X% to HIT"

Q058. What should draw attention when a major event happens?

Recommendation: Use a short body-part damage highlight and plain text for arm disabled, Core destroyed, Heat stress, and objective scoring. Keep sound optional and preserve the same information with reduced motion.

Answer: ultimately we should have animations for these, but we can flash a highlight text banner or something in the prototype

H. Workshop, library, and build comparisons

Type: PREFERENCE · Work packages: TASK-044 / TASK-045 / TASK-046

The core box, empty outlines, any-order assembly, manufacturer browsing, separate arms and held weapons, and hard limits stay. These questions extend that approved flow.

Section answer:

Q059. What should the Workshop show when it opens?

Recommendation: Offer Continue Draft, My Builds, My Rosters, and Open a Core Box. Keep the visual boxed-kit route prominent.

Answer: instead of open a core box just have that be a New Build or something

Q060. How should completed builds be named and organized?

Recommendation: Allow a custom name, optional role tags, manufacturer/box filters, and a compact visual card. Keep catalog IDs out of the normal player-facing name.

Answer: They should get a call sign from their pilot that serves as their "class" designation. Custom name is a nickname we can apply and display for the player only for now

Q061. How should incomplete builds be saved?

Recommendation: Autosave drafts separately from completed library builds. Let players keep several drafts, clearly labeled incomplete and unable to enter a normal match.

Answer: Recommendation

Q062. How should saving changes to a library build affect roster copies?

Recommendation: Save the library build independently. Offer an explicit update to unlocked roster copies with a change preview; never alter a locked match.

Answer: Recommendation

Q063. What should Duplicate do?

Recommendation: Create a new independent build or roster with a new instance identity and an editable name. Changes to the copy must not affect the original.

Answer: Recommendation

Q064. Which comparison information matters most while choosing a part?

Recommendation: Start with changes to Weight, arm Capacity/Handling, movement, defense, Heat, and weapon capability. Show old and new values with an explanation of any legality failure.

Answer: Recommendation

Q065. How should the builder explain a melee-oriented loadout?

Recommendation: Show its fresh pool sources and counts, arm contributions, two-handed restrictions, shield defense dice, and a selectable example opponent for target-dependent success information.

Answer: Recommendation

Q066. How should pilot reassignment be presented?

Recommendation: Before confirming, show any teammate pilot swap and the resulting faction/bond changes. Keep reassignment easy while arranging an unlocked roster.

Answer: Recommendation

Q067. What should the four-mech roster screen emphasize?

Recommendation: Show three deployed cards plus a distinct reserve card, Team Cap for the selected three, roster-wide legality, and active pilot synergies. Let selection change without rebuilding the mechs.

Answer: Recommendation

Q068. How should build and roster import errors be handled?

Recommendation: Preview imported records, explain missing/changed parts and conflicts, and require explicit replacement of existing entries. Preserve the last good library and support exporting the rejected input for diagnosis.

Answer: Recommendation

I. Saving, resuming, and replay

Type: PREFERENCE · Work packages: TASK-042 / TASK-043 / TASK-060

Complete saves, immutable session content, deterministic reconstruction, and human replay are approved requirements. These questions decide the user-facing workflow.

Section answer:

Q069. What should opening Play do when an unfinished game exists?

Recommendation: Offer Resume prominently, with a clear New Game alternative. Show the last phase, teams, and save time before continuing.

Answer: Recommendation, like many ranked matchmaking systems in the wild

Q070. Should players be able to keep more than one unfinished local session?

Recommendation: Yes. Keep a small named session library, with one most recent session highlighted. Starting a new game must not silently replace another.

Answer: local sessions, sure, these should be treated like game saves

Q071. How should autosave and manual saves relate?

Recommendation: Autosave accepted actions and pending choices. Also allow named checkpoints and file export. Explain storage failures without interrupting access to the current game.

Answer: Recommendation

Q072. How long should completed games remain in browser storage?

Recommendation: Keep a manageable recent-history list and let players pin favorites or export them. Ask before deleting pinned records; use a documented retention limit for ordinary history.

Answer: Recommendation

Q073. What should a normal export contain?

Recommendation: Include the complete reproducible session plus a readable summary: setup, rules/content version, seeds, choices, events, and notes. Use JSON for restoration and Markdown for a human digest.

Answer: Recommendation

Q074. How should an imported unfinished hotseat match resume?

Recommendation: Start at a neutral handoff screen before showing the owning player’s private setup choices. Explain that a local save file contains the full session and is not a secrecy boundary.

Answer: Recommendation

Q075. How should the player navigate a replay?

Recommendation: Offer previous/next event, activation, and round; a timeline; playback speed; and bookmarks. Keep a selected mech inspector usable while paused.

Answer: Recommendation

Q076. What should happen when a saved session uses an unsupported rules version?

Recommendation: Keep the file intact and explain the incompatibility. Offer its readable summary if available. Do not silently replay it under different rules or overwrite it with a failed migration.

Answer: Recommendation

J. Sandbox and repeatable trials

Type: PREFERENCE · Work packages: TASK-061 / TASK-062

Sandbox-only state editing, controlled dice, rewind, reset, and side swapping are approved. Normal matches retain hard build limits and cannot use these controls.

Section answer:

Q077. What should the sandbox start screen prioritize?

Recommendation: Offer the existing melee trials, a few focused tactical presets, and a Create Scenario path using the existing maps.

Answer: Recommendation

Q078. Which starting-state controls should be visible immediately?

Recommendation: Mech placement, team, pilot/loadout selection, per-part damage, disabled arms, Heat, and seed. Put uncommon statuses and exact dice scripts in an advanced section.

Answer: Recommendation

Q079. How should a player place and edit mechs?

Recommendation: Select a legal saved build, click a valid map hex, then edit starting damage/status in its inspector. Keep illegal placement explanations next to the board.

Answer: Recommendation

Q080. How should controlled dice be specified?

Recommendation: Allow an explicit sequence of die faces by resolution stage, clearly labeled scripted. Default unscripted trials to normal seeded rolls. Stop with an explanation if a required script is missing or incompatible; never silently fake a result.

Answer: Recommendation

Q081. How should sandbox rewind work?

Recommendation: Let the player return to an earlier accepted decision and create a new branch. Preserve the original branch and label both as sandbox history.

Answer: Recommendation

Q082. What should Reset Trial restore?

Recommendation: Restore the exact initial map, positions, builds, damage, Heat, statuses, seed, and scripted dice. Repeating the same decisions should produce the same result.

Answer: Recommendation

Q083. What should swapping sides do?

Recommendation: Offer a clearly described mirrored scenario: exchange teams and deployment orientation while preserving the intended terrain relationship. Record the transform and seed policy so results are comparable.

Answer: Recommendation

Q084. Which additional trial presets are most valuable first?

Recommendation: Prioritize watched-area crossings on different elevations, prepared disengagement, climbing Heat, sudden death, and objective contests, alongside the three melee trials. Add your own specific problem situations.

Answer: Recommendation + anything we want to test the balance of

K. Playtest reports and feedback

Type: PREFERENCE · Work packages: TASK-063 / TASK-066

Reports should make confusing moments reproducible and useful. They remain local or explicitly exported; no telemetry service or remote play is part of this work.

Section answer:

Q085. What should the one-click Report This Moment action capture?

Recommendation: Capture the session and exact decision/event index, then ask for a short note. Let the player continue immediately and write more afterward.

Answer: Recommendation

Q086. What feedback categories would help you review a session?

Recommendation: Offer rules confusion, unclear UI, unexpected result, suspected bug, pacing, and balance concern, plus free text. Do not force a category to submit a note.

Answer: Recommendation

Q087. Which match-summary metrics should appear first?

Recommendation: Result, rounds, objective score, kills, parts disabled, Heat/stress events, melee attacks/parries, and action usage. Keep detailed weapon statistics expandable.

Answer: Recommendation

Q088. What melee evidence would be most useful for assessing the intended feel?

Recommendation: Show starting and spent pools by source, parries versus accepted hits, targeted parts, arm-loss effects, and exchange decision count. Pair the numbers with the player’s note about whether choices felt meaningful.

Answer: Recommendation

Q089. Should we record time spent making decisions?

Recommendation: Record optional local observed decision time, separating pauses and replay time where possible. Use it to assess pacing; do not enforce a countdown in this epic.

Answer: Recommendation

Q090. How should a completed playtest report be shared with another agent?

Recommendation: Export a Markdown digest plus the machine-readable session and bookmarks. Include exact rules/catalog identity and any sandbox/scripted-dice flags.

Answer: Recommendation

Q091. How should the UI distinguish observed results from balance conclusions?

Recommendation: Label small playtests as observations. Show setup and sample size. Keep formal balance claims in the existing both-sides, reproducible tuning workflow.

Answer: Recommendation

Q092. What questions should a player see immediately after a game?

Recommendation: Ask what was confusing, which decision mattered most, whether melee felt interactive, and whether the game felt too long. Make every answer optional and preserve the report if they skip.

Answer: Recommendation

L. Learning, accessibility, and completion priorities

Type: PREFERENCE · Work packages: TASK-034 / TASK-064 / TASK-065 / TASK-066

All nine local feature areas remain approved. These answers help sequence the work and define a good first-play experience; they do not remove any area from scope.

Section answer:

Q093. Who is the first complete prototype mainly for?

Recommendation: Prioritize you and a new local playtester sharing a screen, with a human-versus-bot option for solo checks. Describe the least experienced player we should accommodate.

Answer: Recommendation + This initial prototype is for a small group of friends that will help develop the game further if we decide the prototype is in good shape

Q094. What should the first guided experience teach?

Recommendation: A short legal kit build, selecting a deployed team, moving and firing, a responsive melee parry, and watching an area. Teach deeper Heat, pilot synergy, and sideboarding in separate short scenarios.

Answer: Recommendation

Q095. How intrusive should guidance be during ordinary Play?

Recommendation: Use optional contextual hints and a Help panel. Make tutorials skippable and restartable, and avoid blocking experienced players with repeated explanations.

Answer: Recommendation

Q096. Which keyboard controls are essential to you?

Recommendation: Cover hex navigation, selection/confirmation, cancel, inspector focus, dice selection, and ending an activation. Include visible shortcut help and avoid shortcuts while typing in text fields.

Answer: Recommendation

Q097. What readability or accessibility needs should we explicitly test?

Recommendation: Support enlarged text, non-color status cues, visible keyboard focus, reduced motion, and essential flows without hover. Add any personal requirements, assistive technology, or difficult interactions.

Answer: Recommendation

Q098. Which devices and screen sizes matter most for actual playtests?

Recommendation: Prioritize a laptop/desktop browser, then usable phone portrait and tablet layouts. Name the devices you expect to use so browser acceptance checks can match them.

Answer: deprioritize phone portrait, Laptop/Desktop + Tablet Landscape (for full engine developed game) + Steam Deck (for full engine developed game)

Q099. Which three approved improvements would you most like to try first?

Recommendation: My suggested order is reliable resume, the board/inspector and watched-area interface, then a complete local match. List a different order if another pain point matters more.

Answer: recommendation

Q100. What would make you call the prototype ready for a serious playtest?

Recommendation: A new player can assemble and field a legal team, complete a local match without rules intervention, recover from a reload, understand melee and Overwatch, and export a confusing moment. Add your own must-pass examples and anything this interview missed.

Answer: recommendation

Additional notes

Use this space for concerns, reference images, examples of games or interfaces, and questions that the interview did not cover. If a confirmed decision now feels wrong, identify it here explicitly so we can revisit it without silently changing the rest.

Notes: There is still much of this that doesnt fit my exact look and feel that I have in my head. Lets consider that this is a prototype and do not linger much on the display aspects outside of making it a prototype that I feel like is strong and comprehensible enough for my fellow developers and playtesters to understand.

Processing instructions for the next agent

1. Read the full answer sheet and current specification before editing rules. Treat question and recommendation text as prompts, not owner answers.
2. Resolve explicit section acceptance and question-specific exceptions. Preserve unanswered/Unsure/Discuss items. Never infer approval from elapsed time, a blank field, or the existence of a recommendation.
3. Map A to TASK-037, B to TASK-038 and any status follow-up, C to TASK-039, and D to TASK-041. E–L map to the listed feature tasks. TASK-040 remains a completed reaction interview unless the owner explicitly revisits it.
4. Summarize accepted decisions and any conflicting answers. Ask only the necessary follow-ups in a batch. Do not block independent approved work on unrelated unanswered preferences.
5. Update accepted rule text, implementation contracts, and the handoff together. Mark a decision task done only when its dependent behavior is settled. Gameplay tasks remain open until implemented and verified.
6. Keep the original owner answers. Do not replace them with your interpretation. Record the processed question IDs, assumptions, and unresolved exceptions in the handoff.
7. Save tracker changes locally and export the portable snapshot. Respect the owner's exclusion of .liste/ from Git pushes and the warning about exporting an older tracker over a newer snapshot.
8. Batch documentation updates and the packet rebuild. Do not rebuild after each individual answer. Do not deploy this answer sheet or any other changes without the applicable deployment authorization.

Processing record (agent use; leave blank until answers are reviewed):