Prototype inventory and site concept
This inventory records the state before the kit-builder and melee implementation. See the implementation notes for the changes made after this review.
Reviewed 2026-09-08 at commit 6bd61a0.
This is an assessment and a discussion document. It does not change the rules or approve a new design. Work tracking stays in .liste/.
The owner identified melee as the largest departure from the initial concept. Assembly is close, but the kit builder needs a flow interview before implementation. These are the first design discussions. Earlier Locked labels record earlier decisions. They do not replace the owner's current intent.
Current direction from the owner interview
The kit builder and melee prototype brief records the current decisions, tentative values, and unresolved mechanics from the interview. It is the source for that new direction. The inventory below describes the implementation reviewed at the start of the conversation.
1. What exists
The repository contains a playable rules prototype, a simulation lab, a design packet, and a world archive. The technical foundation is substantial. The experience of building and fighting with a personal model kit is much less developed than the numerical model.
| Area | Implemented today | Boundary |
|---|---|---|
| Design | GDD, lite rules, rulebook v0.6 with numbered rules, simulator specification | Documents mix current behavior, intended behavior, old measurements, and future features |
| Catalog | 35 parts: 4 chassis, 6 heads, 11 arms, 6 legs, 8 backs; 6 pilots; 6 kits; alternate ammunition and energy Overdrive profiles | Small sample catalog. It does not yet support the full intended faction and specialty puzzle |
| Assembly | Kit presets, arbitrary part swaps by slot, load selection, weight and overload, derived stats, size-weighted hit tape, pilot and copy checks | Browser edits one to three mechs per side through dropdowns. No physical runners, clipping, or fourth-mech builder |
| Shooting | Modifier cancellation, hit, location, penetration, damage, sequential bursts, crits, overflow into Core, destroyed-part transfer, Aimed Shot | Results appear in a log and diagrams. The intended physical dice and part-detachment presentation is not built |
| Heat | Weapon heat, incoming heat, Vent, Stabilize, reactor stress, Exposed and meltdown; Overdrive | Overcharge is written in G3 but has no playable action implementation |
| Melee | Punch, kick, melee weapons, Charge, push, stagger, knockdown, Grapple, Throw, Break, shield penalty, Nimble/Mass and weight effects | A melee weapon uses Fire at adjacency. There is no exchange of strikes and parries |
| Support and reactions | Lock On, bonds, passive abilities, Prepare, Overwatch, Backup Fire, disengage, riposte, Guard, smoke, Indirect fire | Reaction choices use automatic engine behavior, including for human sides |
| Maps | 32×20 hex board; Quarry, Foundry, Causeway, plus flat test field; terrain, roofs, elevation, sight, cover, paths, zones, pushes and falls | Hand-made map data. No map editor or alternative objective system |
| Human play | Hotseat or human versus bot; human activation selection; action budget; board targets and movement affordances; heat/part inspection; handoff and event digest | Single games. Deployment is automatic; initiative winner always acts first; no clock or human sideboard flow |
| Replay | Seeded bot games, typed events, activation snapshots, board paths, shot lines, stepper and detailed dice log | No durable, versioned human-match replay library. A seed alone cannot reconstruct human choices |
| Simulation | Single games, batches, parameter sweeps, map audits, both-side comparisons, aggression grids and automated matches | Tests policy behavior under selected scenarios. It does not establish human enjoyment or global competitive balance |
| Tuner | Edit catalog, validate data, inspect derived weapon metrics, run quick checks; save JSON locally through dev API or export on static site | Power model has known biases. Tuner is marked as an idea in the tracker despite existing in code |
| Packet | Ten generated HTML pages plus the React bench; catalog-derived rulebook section C; diagrams; screenshot gallery; decisions and progress from a tracker snapshot | Four separate presentation systems, duplicate rulebook views, weak links between evidence and experiments |
| World | Realta System Registry: 8 entries and 8 chronological events; internal links, backlinks and theme inversion | Several entries are stubs. Its named organizations are not mapped to the game's five runners |
| Engineering | TypeScript engine shared by CLI and React; seeded RNG; tests; type check; Vite build; GitHub Actions; Cloudflare Pages deployment command | No production game-engine client, online service, ranked system, async service, controller implementation, or modular art pipeline found |
The six kits are Courier, Foreman, Reaver, Bastion, Lantern, and Drayman. The runners are Kessler Yards, Meridian Circuit, Hollow Saints, Nine Suns, and Tessellate.
There are 54 tracker items including two epics. The local files contain 52 work items: 38 done, 7 planned, and 7 ideas. These counts describe tracker status, not prototype completeness. At the start of this review, the packet snapshot differed on TASK-031: planned locally but still an idea in the snapshot. Running the existing snapshot exporter synchronized that item.
There are 17 dated tuning notes, a 33-row tuning register, and a power-model note. The dated notes preserve experiments. Some open register rows still describe conditions that later changes may have superseded.
Source map: GDD, rules, lite rules, register, engine, browser, site, tracker.
2. The game as currently conceived
The intended loop is: choose a roster of four assembled mechs, field three, play alternating activations across a hex map, then adapt through a secret sideboard swap between games of a best of three.
The browser currently supports a shorter loop: configure two teams of up to three mechs, play or watch one game, inspect the outcome, and edit the teams. Automated best-of-three play exists in the CLI.
Assembly and identity
Each mech has six physical parts and a pilot: chassis/Core, head, two arms, legs, and back. Arms are the weapons or shields. Parts set both capability and the distribution of incoming hits. Larger parts occupy more of a d20 location table.
Weight is the build resource. Class caps are 35, 50, and 65 before leg bonuses. Overload up to 10 costs Speed and Evasion in five-point steps. Fielded teams have a hard weight cap of 145. The rules also call for a maximum of two copies of each part across the four-mech roster and unique pilots.
Pilots have Gunnery, Piloting, Systems, and Initiative. Another fielded pilot must share a faction or specialty to activate a passive ability. Named bond pairs have proximity accuracy and can provide prepared Backup Fire. Parts can mix across runners without a penalty. Cosmetics have no combat effect.
This makes assembly a joint choice of offense, protection, mobility, heat capacity, hit distribution, and pilot synergy. The distinctive idea is that the object you assemble determines how it breaks.
An activation and a shot
A mech gets movement up to Speed, split around two Quick actions or one Full action. Fire and improvised Strike each have their own once-per-activation limit. Barrage spends a Full action to fire two different weapons. Aimed Shot spends a Full action to choose the hit location of a single-shot weapon, with a difficulty die.
Every shot uses Hit → Location → Penetration → Damage. Accuracy and difficulty dice cancel. The highest remaining d6 modifies the hit roll. Armor is a penetration threshold: a failed penetration still deals half damage. High penetration can add a crit. Damage beyond a part's durability spills into the Core without another armor roll. Future hits on a destroyed part transfer to the Core and use Core armor.
Heat does not cool passively. Vent costs a Quick action; Stabilize costs a Full action. Exceeding reactor capacity rolls stress and clears heat. Stress can remove an action, remove armor temporarily, or damage the Core. This is intended to provide a deliberate risk choice.
Melee today
A blade attack is a Fire action that needs adjacency, uses Piloting, ignores cover and Engaged, and can reroll location. A separate Quick Strike lets any mech punch or kick. Charge adds movement and momentum, with recoil and heat. Equal or greater weight permits a push; lighter attackers stagger instead. Class governs Nimble/Mass and knockdown. Weight also affects grapple contests and falls.
Grapple spends a Full action. Throw is a later Quick action, so the opponent normally gets an activation before the throw. This helps explain the historical poor conversion into throws.
The defender does not choose a parry or counter inside the ordinary melee attack. Shields add difficulty. Prepared reactions are separate triggers. TASK-031 describes a possible attack/parry exchange, but that proposal and the proposed increase to Blade Shots have not landed. The current Blade has one shot.
Space and victory
Terrain controls movement, reach, sight, cover, high ground, and objective access. Hard cover also absorbs leg-location hits. There is no facing. Three zones score one point each per controlled round. Each kill scores three. A wipe wins immediately; otherwise score decides after seven rounds, then remaining Hull percentage.
The written rotation is Quarry → Causeway → Foundry. Quarry permits long lanes. Causeway brings fighting to ledges. Foundry restricts sight and strongly rewards mobility. The recorded decision accepts Foundry as a map where the Bastion should be benched.
3. Confirmed gaps and conflicting claims
These are implementation or documentation discrepancies. They are distinct from a judgment that the design itself should change.
| Finding | Evidence | Why it matters |
|---|---|---|
| No four-mech browser roster or human match flow | web/src/model.ts accepts 1–3 builds; Bench.tsx adds only up to 3; engine/match.ts handles automated matches |
The main assembly and adaptation loop cannot yet be experienced end to end |
| Match swaps use a proxy policy | runMatch swaps only the loser's worst performer, if legal |
The rules allow both players a simultaneous secret decision informed by the next map. Reported match balance measures the proxy |
| Full-roster copy and pilot legality is not enforced by the match runner | runGame validates the fielded team; chooseSwap validates the replacement team |
A legal three-mech team does not establish that all four registered mechs obey B5. Field weight and roster copy limits need separate validation scopes |
| Human deployment and initiative choices are missing | GameState deploys at construction; rollInitiative returns the winning side as first |
H8 and E2 describe player decisions that the prototype currently makes automatically |
| Reactions are automatic | afterMove and afterAttack resolve triggers immediately; Backup Fire selects a weapon and declines overheating automatically |
E6 calls reactions optional. Human players cannot currently choose whether or how to spend that reaction |
| Overcharge is absent | G3 exists; runtime state has an overcharges counter; no action in TurnController |
The written extra-action heat gamble cannot be tested in human play |
| Exact ties become draws | GameState.finish returns draw after score and Hull tie |
I5 instead specifies a sudden-death round |
| Jump-leg heat is not applied by movement | C4/G1 specify +1 Heat in an activation with a climb; movement code does not charge it | The builder promises a heat tradeoff that is absent in play |
| Small rules summaries are stale | Grapple tooltip says class bonus while F11 uses weight difference; lite rules describe heat per shot instead of per Fire; B3 says three full Mediums fit while also noting 150 exceeds 145 | Players can learn contradictory rules from different surfaces |
| Some claimed class restrictions are not hard rules | B3 says two Heavies never fit; validators enforce weight and copies, not a heavy-count cap | Customization can invalidate prose written around the original kits |
| Tracker progress is stale | FEAT-010 Tuner remains an idea; TASK-031 differed between local tracker and packet snapshot until this review refreshed the snapshot | Home-page completion tiles are not reliable evidence of what exists |
| Technical status is stale | README and simulator spec still say 84 tests; spec lists completed falls and heat planning as out of scope | The packet understates completed work and makes handoff harder |
| World and game identity lack a mapping | Registry uses Dioscuri, Bartels & Basinger, Hauer, Yutani, MCA, ISG, and Werkzeug; catalog uses five different runner names | This may be a placeholder layer or a world-design departure. Confirm before renaming either set |
The record should retain historical evidence, but current guidance needs a clear owner and revision. A rule can be approved in intent, partly implemented, and untested with humans at the same time. One status badge cannot express all three.
4. Design concerns to discuss
Melee does not yet have its own player exchange
Most of its depth is in reaching adjacency, choosing an attack, and handling positional consequences. That may suit a fast resolution system. It will not by itself create the experience of two pilots dueling through attacks and defenses.
Historical tuning found a strong blade hit with little opportunity to use it: about 17.7% melee damage and roughly one blade Fire per game in a cited best-response sample. Those are measurements under an earlier state and bot policy, not fresh measurements of this checkout. Raising damage could increase reward for closing. It would not answer who chooses, how the defender participates, or how long an engagement should last.
Interview the desired encounter before choosing between a fast strike, an interactive exchange, or an extended brawl. The old attack/parry proposal is one option, not the assumed answer.
Assembly has the rules of a model kit, but the interaction of a form
The browser exposes most decisions at once. It has no physical part inventory, assembly order, or act of clipping. The text says "clip" while the interaction is a dropdown. Whether that matters depends on whether the pleasure is assembling an object, optimizing a loadout, or both.
The most consequential unanswered question is where parts come from. Choosing complete kits as presets is different from choosing kits whose actual runners supply a finite pool of parts for the roster. The latter changes legality, unused parts, duplicates, and kitbashing. A new screen should not silently decide this rule.
Balance evidence has a narrower scope than the pitch
The repo has already caught major measurement errors: bot aggression, deployment order, activation order, and side tie-breaks changed verdicts. The both-side aggression grid is a useful correction. It samples one policy family at a few settings; it is not proof of optimal human play.
Historical re-baselines put the reference light roster near 50.3% on Quarry and 52.8% on Causeway, while Foundry favors it strongly. The chosen match rotation was recorded at about 43.7% for that roster under the swap proxy. These results do not establish a balanced catalog, nor guarantee that melee feels good.
The analytical power score is visibly exposed in assembly, but its own register records missed range, shield hit-share, melee uptime, and speed valuation. It should be clearly labeled as a lab estimate if retained in the builder.
The small pilot set cannot express the stated synergy puzzle
All six current specialties are unique. Only Ruko and Marrow share a faction. Thus only that pair can unlock same-faction/specialty passives under the current catalog. Bonds exist across other pairs, but bonds do not activate those passives. A player might read an inert ability as a weak mechanic when the sample content has not supplied its partners.
Pace and damage need human evidence
Four shot stages can be memorable, but a burst repeats them and crits, reactions, stress, and damage dice add more rolls. Seven rounds and an intended 45-second activation clock do not demonstrate a 20-minute game. The clock is absent. A best of three also has a longer total session than one 20-minute game.
Part destruction creates a strong identity and a possible loss of agency: losing the useful arm early may leave a mech alive but uninteresting. Overflow, direct Core targeting, repair opportunities, and remaining utility should be assessed from human play. A wipe-rate target cannot answer whether a damaged mech is still fun to use.
5. One cohesive site
The concept is a shared project workbench. A visitor should understand the game, build a mech, try it, inspect the outcome, and discuss a change without feeling that they opened a different product.
Navigation and page roles
| Primary section | Contents | Existing material it absorbs |
|---|---|---|
| Overview | Short pitch, representative mech and board, current prototype capability, three useful entry actions, recent decisions | Packet home and selected GDD overview |
| Learn | Guided quick start, one canonical illustrated rules reference, glossary, worked examples | Lite rules, rules.html, rulebook.html, diagrams |
| Workshop | Kit builder, parts and pilots, saved builds, roster and sideboard | Bench assembly, catalog, GDD assembly intent; exact builder flow awaits interview |
| Play | Human versus bot, hotseat, resume game, results and replay | Play and Battle tabs; later the human match flow |
| Lab | Batch runs, parameter experiments, catalog tuning, map audits, evidence archive | Batch, Tuner, CLI capabilities, simulator page, dated notes and tuning register |
| World | Realta chronology, organizations, machines, linked entries | World registry; same site shell with its own document layout |
| Project | Design intent, open decisions, implementation inventory, progress and history | GDD, Decisions, Progress, technical specification |
The Overview should lead with "Build a mech", "Try a skirmish", and "Learn the rules". Project counters belong below the explanation of the game. New visitors should not need to understand the tracker before trying the prototype.
"Bench" currently means the application, the assembly tab, and the sideboard concept. Use Workshop for assembly, Lab for experiments, Replay for a recorded battle, and Sideboard for the fourth mech. This separates activities through clear names within one site.
A single visual language
Use the model-kit manual direction already in the GDD as the provisional basis: clear part silhouettes, runner labels, technical annotations, readable tables, and restrained cyan, pink, and amber accents. Keep the exact art treatment open until the builder interview establishes what physical assembly means.
One shared token set should own type, colors, spacing, borders, focus, controls, status labels, and part colors. One persistent navigation shell should own section links, theme choice, and responsive behavior. The registry can keep an archival reading layout within that shell. The board and lab can use denser layouts within it.
Provide consistent light and dark themes with one saved preference. The current independent Invert control, pinned dark documents, and unused bench light palette should become one behavior. Consistency means shared hierarchy and interaction as well as color.
Use the same part card in the catalog, builder, inspector, and replay. It should show the same name, silhouette, rule terms, and relevant numbers. Display any experimental catalog or rule override clearly in Lab and in results it produces.
Connected state and evidence
Preserve a build, active game, and experiment while moving between sections. Today the conditional React tabs unmount Play and Batch, which discards their local session state and terminates a batch worker on exit. This directly obstructs checking a rule and returning to the same task.
Give rules stable links by ID, such as F11. Give parts, pilots, maps, decisions, and findings stable pages or anchors. Link a disputed blade result to the blade, the relevant melee rule, the exact experiment, and the open decision. The current link rewriter sends individual tuning-note links to the top of one long simulator page.
A saved experiment needs the scenario, rosters, map, seed range, catalog revision, rule overrides, bot settings, and both-side treatment. A human replay also needs recorded decisions or a sufficient event log. A seed and roster are enough only when the decision policy is also fixed.
Make the Lab landing page a current findings summary with links to separate dated experiments. Preserve old findings as history. Label whether evidence is current, superseded, or awaiting a re-run. Do not concatenate every note into the primary reading experience.
Keep the existing foundation
The TypeScript rules engine and JSON catalog remain reusable. Shared site chrome does not require porting combat or choosing the production game engine now. The static documentation and React tools can share navigation and tokens before any larger routing change.
Keep one canonical rules source with an illustrated screen view and a print view. Catalog tables already generate from JSON; retain that work. Make descriptive catalog summaries reuse the same fields so a bonus cannot disappear between CLI, builder, and rulebook.
Separate three kinds of status: design decision, implementation coverage, and validation evidence. Record current status from maintained sources. Preserve old URLs when consolidating the two rulebook presentations and bench tabs.
The acceptance question for this site is practical: can someone build a mech, consult a rule, return to the unchanged build, play, inspect a broken part, and find the reason for its stats without losing context?
6. Interview sequence
Start with a concrete imagined use, then settle the rules it implies. Do not implement the kit-builder flow before these answers.
- Opening the kit. What is on the table at the start: a kit to assemble, a finished mech to modify, or an empty frame? What are the first few actions?
- Parts supply. Do kits provide a finite collection of runners and parts, or are they presets over a freely available catalog? What happens to unused parts when building another mech?
- Melee encounter. A blade mech reaches an opponent. What happens next? What decisions does each player make?
- Builder interaction. Is clipping a deliberate action, a short animation, or optional? What must the player see change on the mech? How should undo and swapping work?
- Builder progression. Build one mech to completion or lay out the roster first? Choose pilot before or after the machine? When should stats, legality, synergy, and sideboard appear?
- Melee consequences. How dangerous is contact? Who acts first? Can the defender parry, counter, retreat, or grapple? What distinguishes a blade, fist, shield, and heavier machine?
- Time and complexity. How long should the first build and one melee encounter take? Which decisions should repeat each game, and which should be saved?
- Identity. How do the Realta organizations relate to the catalog runners and pilots? Which names and visual references are canonical?
Each answer should produce a concrete example flow and its consequences before any rule or layout is declared settled.
7. Verification and limits
pnpm test: 28 files, 286 tests passed. pnpm typecheck: passed. pnpm site:build: passed; ten HTML pages plus the bundled bench generated. Section C already matched the catalog. The build required approval because the sandbox blocked the build tool's local IPC pipe.
This review inspected local source, docs, tracker files, catalog, and history. It did not deploy the site, run new balance sweeps, conduct a browser interaction test, inspect the external lore vault, or establish a human playtest result. Historical statistics above are attributed to the repository's tuning record. No rules, catalog values, or builder behavior were changed for this review. The existing snapshot exporter synchronized TASK-031's status and update date in site/data/liste.json.