make recipe selection and buffers of smelter and reprocessing plant behave like other buildings, except that a recipe may be chosen automatically

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K

.claude/CLAUDE.md

@@ -0,0 +1,184 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Interaction
+
+* ONLY modify code or other files if explicitly asked to do so
+* keep the tone professional, brief and to the point — brevity applies to prose and
+  preamble, not to the substance of an objection or a design rationale
+* be critical: where there is a concrete technical reason to disagree, name it once;
+  if the user reaffirms, proceed with their call without re-litigating
+
+## Project Overview
+
+Dota Factory is a single-player game that blends a Factorio-style factory builder with
+DOTA-style wave defence. The player builds a factory on an asteroid — mining ores,
+transporting materials over belts and splitters, and crafting through a config-defined
+production tree — to supply shipyards that produce autonomous combat ships. Those ships
+fight off endless enemy waves advancing from the right. See `docs/concept.md` for the full design.
+
+
+## Project Structure
+
+* the project root and the git repository root are the same directory
+* project requirements can be found at `docs/requirements.md`
+* architecture decisions can be found at `docs/architecture.md`
+* game content design (ship/module roster, layout grids, footprint gating) can be found at `docs/content_design.md`
+* replay/determinism design can be found at `docs/replay_design.md`
+* balancing rules, targets, tuned numbers, process, and history live under `docs/balancing/`
+
+Requirements carry stable `REQ-<AREA>-<NAME>` ids. They are cited throughout the code in
+comments — when changing behavior, find the governing REQ id first and
+keep the citation accurate.
+
+## Coding Guidelines
+
+* avoid duplicate code
+* when planning a change, weigh the long-term maintainability of the codebase instead of
+  defaulting to the lowest-effort patch — but no speculative generality: never build or
+  prepare for functionality we may never need. If the maintainable solution is much larger
+  than the request, say so and let the user decide the scope.
+* class layout: static members first, then non-static; within each, public, then protected,
+  then private (Qt `slots:`/`signals:` are ordinary non-static access groups). Inside an
+  access group the order is: nested types, static constants, aliases, methods, fields,
+  friends. Out-of-line method definitions follow the declaration order. Applies to new
+  classes and to files being edited anyway — don't reorder existing headers just to comply.
+* do not use the "auto" keyword, with two exceptions:
+  * **named local lambdas** — a lambda's type is unnameable, and `std::function`
+    is not an acceptable substitute in per-tick code because it adds a heap
+    allocation and an indirect call
+  * **iterator types** — `auto it = m_buildings.find(id)` is allowed where
+    spelling the iterator out adds length without adding information
+  * everywhere else the type is written out; in particular `auto` is not used
+    for plain values, return values, or range-for element types
+* use Qt utility data types (like QPoint, QVector3D, QString, etc.)
+* wrap strings that appear in the UI with Qt's "tr()"
+* use the EventManager/EventHandler instead of defining own signals and slots
+* use std::optional if a variable can be "not set"
+* start the name of a getter method with "get"
+* don't use abbreviations, except very common ones ("s" for seconds, "min", "max", etc.)
+* if a variable holds a value that has a unit or if a function returns a value that has a unit, append that unit to the name (e.g. "m_shipVelocity_mps", "getAcceleration_mpss()")
+* always enclose scopes in braces
+* keep source files ASCII-only. A non-ASCII character needed at runtime (a glyph in a
+  UI string, a symbol drawn on a widget) is written as its code point with a comment
+  naming it (`const QChar shiftGlyph(0x21E7);  // U+21E7 UPWARDS WHITE ARROW`), never
+  as a literal character: MSVC 2017 does not read the sources as UTF-8 by default and
+  silently mangles them. Never round-trip a source file through
+  `Get-Content`/`Set-Content` either: Windows PowerShell reads it as ANSI and writes
+  it back double-encoded with a BOM. Use the Edit/Write tools.
+
+## Build
+
+Requires CMake 3.14.4+, a C++17 compiler, and Qt 5 (developed against Qt 5.12.3,
+MSVC 2017 x64; `Qt5_DIR` is cached in `build/CMakeCache.txt`). Needs Qt components
+Widgets, Network, Multimedia, Charts, Svg, plus OpenGL.
+
+External dependencies vendored under `src/external/`:
+* **toml++** — reading TOML config files
+* **tinyexpr** — evaluating formula strings from config files
+* **EnTT** — entity registry backing the ship/station/debris simulation
+* **Catch2** — test framework
+
+Configure and build (a configured `build/` tree already exists):
+
+```sh
+cmake -S . -B build                             # configure (multi-config VS generator)
+cmake --build build --config Debug              # all targets
+cmake --build build --config Debug --target DotaFactory_test
+```
+
+Targets: `DotaFactory` (app), `DotaFactory_lib`, `DotaFactory_ui`, `DotaFactory_test`,
+`DotaFactory_balancing`. Executables land in `build/DotaFactory/<Config>/{app,balancing}/`.
+
+**Adding a source file requires editing CMake.** Every directory under `src/` has its own
+`CMakeLists.txt` listing files explicitly in `HDRS`/`SRCS` (or `TEST_FILES` for tests) —
+there is no globbing. A new file that is not registered simply will not compile.
+
+Config data is not copied: `CONFIG_DIR` is a compile definition pointing at
+`bin/app/data/config` for the app and balancing tool, and `bin/test/data/config` for
+tests (a separate fixture set). On Windows the build also junctions `bin/*/data` into the
+output directories and copies the Qt DLLs.
+
+Run the app: `build/DotaFactory/Debug/app/DotaFactory.exe`, optionally
+`--replay <file>` for view-only playback of a recorded run.
+
+**Visual verification is the user's job.** Screen-capturing the app window does not
+work here: `CopyFromScreen` and `PrintWindow` both return a blank white client area
+even while the app is running and rendering normally, because the capture cannot read
+the composited surface of the `QOpenGLWidget`-backed window. A blank capture therefore
+says nothing about whether the UI works, so do not read one as a regression and do not
+try to work around it. To check a UI change: build, run the tests, launch the app, and
+ask the user to look at it. Redirecting the process's stdout/stderr to a file does
+work and is worth checking for Qt warnings.
+
+## Tests
+
+Catch2, single executable, links `lib` only — no QApplication, no display.
+
+```sh
+build/DotaFactory/Debug/app/DotaFactory_test.exe                    # all
+build/DotaFactory/Debug/app/DotaFactory_test.exe "[belt],[building]" # by tag
+build/DotaFactory/Debug/app/DotaFactory_test.exe "BeltSystem: *"     # by name pattern
+build/DotaFactory/Debug/app/DotaFactory_test.exe --reporter compact
+```
+
+Common tags: `[building] [belt] [behavior] [blueprint] [modules] [config] [wave] [combat]
+[replay] [determinism] [ship] [debris] [threat] [unlock]`.
+
+`src/test/SimulationTestAccess.h` is a friend-struct backdoor to `Simulation`'s private
+mutators; tests use it instead of duplicating the command path. It lives under `src/test`
+and is deliberately off the lib/ui/app include path.
+
+## Verification Tools
+
+Python scripts in `tools/` read the real configs and are the first check
+after config edits (see `docs/balancing/process.md`):
+
+* `verify_recipes.py` — recipe-tree closure, visuals coverage, orphan items
+* `verify_layouts.py` — module footprint gating per hull layout
+* `threat_report.py` — item/module/ship threat values, ratios, belt feasibility
+
+The `DotaFactory_balancing` target runs parallel arena simulations from
+`bin/balancing/data/balancing.toml` for combat-stat tuning.
+
+## Architecture
+
+See `docs/architecture.md` for the full write-up. Highlights and the
+invariants that are easy to break:
+
+* Strict simulation/presentation split, enforced at the CMake target level: `lib`
+  (sim + config, Qt Core/Gui only — no QtWidgets), `ui` (QtWidgets + QOpenGLWidget),
+  `app` (thin main), `test` (Catch2 against `lib`).
+* Fixed 30 Hz tick simulation, 60 FPS render, accumulator-driven; game speed is a
+  tick-rate multiplier. All sim quantities are in ticks, never wall-clock seconds.
+* The tick order in `Simulation::tick()` is load-bearing for determinism — see the
+  Tick Order section of `architecture.md` before reordering systems.
+* **Command chokepoint:** every sim mutation during play flows through
+  `Simulation::apply(const Command&)` (see `sim/Command.h`, `CommandManager`), so runs can
+  be recorded and replayed. Commands reference stable ids (`BuildingId`, tile coords,
+  choice indices) — never raw `entt::entity` handles. UI code must not call sim mutators
+  directly. Determinism is checksummed (`StateChecksum`) and covered by
+  `DeterminismTest` / `ReplayPlaybackTest`.
+* Config is loaded once at startup, formulas compiled once via tinyexpr, immutable
+  afterwards; malformed config aborts startup rather than failing mid-game. Restart
+  reloads config from disk (REQ-CFG-RELOAD).
+* **The sim uses EnTT for ships, stations, debris, and module child entities**, wrapped by
+  `core/EntityAdmin` (registry, factory methods, `forEach<Ts...>` views). Components live
+  in `lib/ecs/component/`, systems in `lib/ecs/system/`. Note: `architecture.md`'s
+  "Ships" and "Why Not ECS" sections still describe the earlier
+  `std::optional<Component>` design and are stale on this point; the code is authoritative.
+  Buildings and the belt subsystem stay outside the entity model.
+* Ship AI is score-based, not fixed-priority: `AiSystem` runs evaluate → select → execute
+  phases over per-behavior evaluator/executor pairs in `lib/ecs/system/ai/`. Evaluators and
+  executors never mutate the world; world mutation lives in `CombatSystem`,
+  `SalvagerSystem`, `RepairSystem`, `MovementIntentSystem`.
+* Belt subsystem is behind a narrow port-level interface (`tryPutItem` / `tryTakeItem` /
+  `clearTiles` / `tick` / `forEachVisualItem`); per-tile implementation now, swappable
+  later. No other system asks "what is on tile X".
+* All inter-widget and sim→UI communication goes through the `EventManager`/`EventHandler`
+  singleton in `lib/eventsystem/` (events in `lib/eventsystem/event/`). The sim itself
+  stays free of EventManager for determinism — it buffers `BeamFiredEvent`s in a vector
+  that the UI drains each frame and re-emits.
+* State-change events are *refresh signals*, not carriers of truth: a widget re-reads the
+  value from `Simulation` rather than caching the event payload.

.claude/skills/bug/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: bug
+description: Investigate a reported bug, find and explain its root cause, and propose a fix — without implementing anything
+argument-hint: <description of the buggy behavior>
+disable-model-invocation: true
+---
+
+A bug has been reported:
+
+$ARGUMENTS
+
+Investigate it and propose a solution. **Do not implement anything** — no edits, no new files, no fixes applied. The goal of this pass is understanding and a proposal the user can approve first.
+
+Work through it like this:
+
+1. **Pin down expected vs. actual.** Restate what the behavior should be and what it actually is. If the report is ambiguous about the conditions that trigger it, note your assumptions explicitly.
+
+2. **Find the relevant code.** Search for the subsystem(s) involved (Grep/Glob, then Read the actual files). Don't reason from memory or from names alone — read the implementation that runs in this case.
+
+3. **Trace the real execution path.** Follow the data/control flow step by step for the specific failing scenario. For the tick-based simulation, that means tracing the relevant systems in tick order, including the per-tick progress/cap arithmetic where it matters. Use the project's actual constants (tick rate, belt speed, etc.) rather than hand-waving.
+
+4. **State the root cause precisely.** Name the exact mechanism, citing `file:line`. Explain *why* it produces the observed symptom — connect the cause to the visible effect concretely (e.g. "single-slot output serializes to one item per full-tile traversal, so items land ~1 tile apart"). Confirm it explains the specific trigger conditions in the report.
+
+5. **Propose a solution.** Describe the change and where it would go (`file:line`), reusing existing patterns in the codebase. If the symptom has more than one contributing path, say so. If the fix involves a design or balance trade-off (correctness vs. throughput, lossless vs. capped, a visual side effect, etc.), surface it as a decision for the user — give a recommendation, but ask before assuming which behavior they want.
+
+6. **Stop and hand back.** End with the proposal and any open questions. Offer to implement (and to add tests) only once the user has chosen a direction.
+
+Keep the write-up grounded in what the code actually does — quote the lines that matter. Adhere to the repository's coding guidelines and architecture notes (see `.claude/CLAUDE.md`) when describing any proposed change.

.claude/skills/cpp-pro/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: C++ Pro
+description: Expert C++ developer specializing in modern C++20/23, systems programming, and high-performance computing. Masters template metaprogramming, zero-overhead abstractions, and low-level optimization with emphasis on safety and efficiency.
+triggers:
+  - C++
+  - C++17
+  - C++20
+  - C++23
+  - modern C++
+  - template metaprogramming
+  - systems programming
+  - performance optimization
+  - SIMD
+  - memory management
+  - CMake
+role: specialist
+scope: implementation
+output-format: code
+---
+
+# C++ Pro
+
+Senior C++ developer with deep expertise in modern C++20/23, systems programming, high-performance computing, and zero-overhead abstractions.
+
+## Role Definition
+
+You are a senior C++ engineer with 15+ years of systems programming experience. You specialize in modern C++20/23, template metaprogramming, performance optimization, and building production-grade systems with emphasis on safety, efficiency, and maintainability. You follow C++ Core Guidelines and leverage cutting-edge language features.
+
+## When to Use This Skill
+
+- Building high-performance C++ applications
+- Implementing template metaprogramming solutions
+- Optimizing memory-critical systems
+- Developing concurrent and parallel algorithms
+- Creating custom allocators and memory pools
+- Systems programming and embedded development
+
+## Core Workflow
+
+1. **Analyze architecture** - Review build system, compiler flags, performance requirements
+2. **Design with concepts** - Create type-safe interfaces using C++20 concepts
+3. **Implement zero-cost** - Apply RAII, constexpr, and zero-overhead abstractions
+4. **Verify quality** - Run sanitizers, static analysis, and performance benchmarks
+5. **Optimize** - Profile, measure, and apply targeted optimizations
+
+## Reference Guide
+
+Load detailed guidance based on context:
+
+| Topic | Reference | Load When |
+|-------|-----------|-----------|
+| Modern C++ Features | `references/modern-cpp.md` | C++20/23 features, concepts, ranges, coroutines |
+| Template Metaprogramming | `references/templates.md` | Variadic templates, SFINAE, type traits, CRTP |
+| Memory & Performance | `references/memory-performance.md` | Allocators, SIMD, cache optimization, move semantics |
+| Concurrency | `references/concurrency.md` | Atomics, lock-free structures, thread pools, coroutines |
+| Build & Tooling | `references/build-tooling.md` | CMake, sanitizers, static analysis, testing |
+
+## Constraints
+
+### MUST DO
+- Follow C++ Core Guidelines
+- Use concepts for template constraints
+- Apply RAII universally
+- Do not use `auto`
+- Prefer `std::unique_ptr` and `std::shared_ptr`
+- Write const-correct code
+- Use forward declarations in header files if possible
+- Use descriptive functions names and variable names instead of writing comments
+
+### MUST NOT DO
+- Use raw `new`/`delete` (prefer smart pointers)
+- Ignore compiler warnings
+- Use C-style casts (use static_cast, etc.)
+- Mix exception and error code patterns inconsistently
+- Write non-const-correct code
+- Use `using namespace std` in headers
+- Ignore undefined behavior
+- Skip move semantics for expensive types
+- Write lots of comments
+
+## Output Templates
+
+When implementing C++ features, provide:
+1. Header file with interfaces and templates
+2. Implementation file (when needed)
+3. CMakeLists.txt updates (if applicable)
+4. Test file demonstrating usage
+
+## Knowledge Reference
+
+C++20/23, concepts, ranges, coroutines, modules, template metaprogramming, SFINAE, type traits, CRTP, smart pointers, custom allocators, move semantics, RAII, SIMD, atomics, lock-free programming, CMake, Conan, sanitizers, clang-tidy, cppcheck, Catch2, GoogleTest

.claude/skills/cpp-pro/references/build-tooling.md

@@ -0,0 +1,443 @@
+# Build Systems and Tooling
+
+> Reference for: C++ Pro
+> Load when: CMake, sanitizers, static analysis, testing frameworks, CI/CD
+
+## Modern CMake
+
+```cmake
+cmake_minimum_required(VERSION 3.20)
+project(MyProject VERSION 1.0.0 LANGUAGES CXX)
+
+# Set C++ standard
+set(CMAKE_CXX_STANDARD 20)
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
+set(CMAKE_CXX_EXTENSIONS OFF)
+
+# Export compile commands for tools
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
+# Compiler warnings
+if(MSVC)
+    add_compile_options(/W4 /WX)
+else()
+    add_compile_options(-Wall -Wextra -Wpedantic -Werror)
+endif()
+
+# Create library target
+add_library(mylib
+    src/mylib.cpp
+    include/mylib.h
+)
+
+target_include_directories(mylib
+    PUBLIC
+        $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
+        $<INSTALL_INTERFACE:include>
+    PRIVATE
+        ${CMAKE_CURRENT_SOURCE_DIR}/src
+)
+
+target_compile_features(mylib PUBLIC cxx_std_20)
+
+# Create executable
+add_executable(myapp src/main.cpp)
+target_link_libraries(myapp PRIVATE mylib)
+
+# Dependencies with FetchContent
+include(FetchContent)
+
+FetchContent_Declare(
+    fmt
+    GIT_REPOSITORY https://github.com/fmtlib/fmt.git
+    GIT_TAG 10.1.1
+)
+FetchContent_MakeAvailable(fmt)
+
+target_link_libraries(mylib PUBLIC fmt::fmt)
+
+# Testing
+enable_testing()
+add_subdirectory(tests)
+
+# Install rules
+include(GNUInstallDirs)
+install(TARGETS mylib myapp
+    EXPORT MyProjectTargets
+    LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+    ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
+)
+
+install(DIRECTORY include/
+    DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
+)
+```
+
+## Sanitizers
+
+```cmake
+# AddressSanitizer (ASan) - memory errors
+set(CMAKE_CXX_FLAGS_ASAN
+    "-g -O1 -fsanitize=address -fno-omit-frame-pointer"
+    CACHE STRING "Flags for ASan build"
+)
+
+# UndefinedBehaviorSanitizer (UBSan)
+set(CMAKE_CXX_FLAGS_UBSAN
+    "-g -O1 -fsanitize=undefined -fno-omit-frame-pointer"
+    CACHE STRING "Flags for UBSan build"
+)
+
+# ThreadSanitizer (TSan) - data races
+set(CMAKE_CXX_FLAGS_TSAN
+    "-g -O1 -fsanitize=thread -fno-omit-frame-pointer"
+    CACHE STRING "Flags for TSan build"
+)
+
+# MemorySanitizer (MSan) - uninitialized reads
+set(CMAKE_CXX_FLAGS_MSAN
+    "-g -O1 -fsanitize=memory -fno-omit-frame-pointer"
+    CACHE STRING "Flags for MSan build"
+)
+
+# Usage: cmake -DCMAKE_BUILD_TYPE=ASAN ..
+```
+
+## Static Analysis
+
+```yaml
+# .clang-tidy configuration
+---
+Checks: >
+  *,
+  -fuchsia-*,
+  -google-*,
+  -llvm-*,
+  -modernize-use-trailing-return-type,
+  -readability-identifier-length
+
+WarningsAsErrors: '*'
+
+CheckOptions:
+  - key: readability-identifier-naming.ClassCase
+    value: CamelCase
+  - key: readability-identifier-naming.FunctionCase
+    value: lower_case
+  - key: readability-identifier-naming.VariableCase
+    value: lower_case
+  - key: readability-identifier-naming.ConstantCase
+    value: UPPER_CASE
+  - key: readability-identifier-naming.MemberCase
+    value: lower_case
+  - key: readability-identifier-naming.MemberSuffix
+    value: '_'
+  - key: modernize-use-nullptr.NullMacros
+    value: 'NULL'
+```
+
+```bash
+# Run clang-tidy
+clang-tidy src/*.cpp -p build/
+
+# Run cppcheck
+cppcheck --enable=all --std=c++20 --suppress=missingInclude src/
+
+# Run include-what-you-use
+include-what-you-use -std=c++20 src/main.cpp
+```
+
+## Testing with Catch2
+
+```cpp
+#include <catch2/catch_test_macros.hpp>
+#include <catch2/benchmark/catch_benchmark.hpp>
+#include "mylib.h"
+
+TEST_CASE("Vector operations", "[vector]") {
+    std::vector<int> vec{1, 2, 3};
+
+    SECTION("push_back") {
+        vec.push_back(4);
+        REQUIRE(vec.size() == 4);
+        REQUIRE(vec.back() == 4);
+    }
+
+    SECTION("pop_back") {
+        vec.pop_back();
+        REQUIRE(vec.size() == 2);
+        REQUIRE(vec.back() == 2);
+    }
+}
+
+TEST_CASE("Exception handling", "[exceptions]") {
+    REQUIRE_THROWS_AS(risky_function(), std::runtime_error);
+    REQUIRE_THROWS_WITH(risky_function(), "error message");
+}
+
+TEST_CASE("Floating point", "[math]") {
+    REQUIRE_THAT(compute_value(),
+                 Catch::Matchers::WithinAbs(3.14, 0.01));
+}
+
+BENCHMARK("Vector creation") {
+    return std::vector<int>(1000);
+};
+
+BENCHMARK("Vector fill") {
+    std::vector<int> vec(1000);
+    for (int i = 0; i < 1000; ++i) {
+        vec[i] = i;
+    }
+    return vec;
+};
+```
+
+## Testing with GoogleTest
+
+```cpp
+#include <gtest/gtest.h>
+#include <gmock/gmock.h>
+#include "calculator.h"
+
+class CalculatorTest : public ::testing::Test {
+protected:
+    void SetUp() override {
+        calc = std::make_unique<Calculator>();
+    }
+
+    void TearDown() override {
+        calc.reset();
+    }
+
+    std::unique_ptr<Calculator> calc;
+};
+
+TEST_F(CalculatorTest, Addition) {
+    EXPECT_EQ(calc->add(2, 3), 5);
+    EXPECT_EQ(calc->add(-1, 1), 0);
+}
+
+TEST_F(CalculatorTest, Division) {
+    EXPECT_DOUBLE_EQ(calc->divide(10, 2), 5.0);
+    EXPECT_THROW(calc->divide(10, 0), std::invalid_argument);
+}
+
+// Parameterized tests
+class AdditionTest : public ::testing::TestWithParam<std::tuple<int, int, int>> {};
+
+TEST_P(AdditionTest, ValidAddition) {
+    auto [a, b, expected] = GetParam();
+    Calculator calc;
+    EXPECT_EQ(calc.add(a, b), expected);
+}
+
+INSTANTIATE_TEST_SUITE_P(
+    AdditionSuite,
+    AdditionTest,
+    ::testing::Values(
+        std::make_tuple(1, 2, 3),
+        std::make_tuple(-1, -2, -3),
+        std::make_tuple(0, 0, 0)
+    )
+);
+
+// Mock objects
+class MockDatabase : public Database {
+public:
+    MOCK_METHOD(void, connect, (const std::string&), (override));
+    MOCK_METHOD(std::string, query, (const std::string&), (override));
+    MOCK_METHOD(void, disconnect, (), (override));
+};
+
+TEST(ServiceTest, UsesDatabase) {
+    MockDatabase mock_db;
+    EXPECT_CALL(mock_db, connect("localhost"))
+        .Times(1);
+    EXPECT_CALL(mock_db, query("SELECT *"))
+        .WillOnce(::testing::Return("result"));
+
+    Service service(mock_db);
+    service.process();
+}
+```
+
+## Performance Profiling
+
+```cpp
+// Benchmark with Google Benchmark
+#include <benchmark/benchmark.h>
+
+static void BM_VectorPush(benchmark::State& state) {
+    for (auto _ : state) {
+        std::vector<int> vec;
+        for (int i = 0; i < state.range(0); ++i) {
+            vec.push_back(i);
+        }
+        benchmark::DoNotOptimize(vec);
+    }
+}
+BENCHMARK(BM_VectorPush)->Range(8, 8<<10);
+
+static void BM_VectorReserve(benchmark::State& state) {
+    for (auto _ : state) {
+        std::vector<int> vec;
+        vec.reserve(state.range(0));
+        for (int i = 0; i < state.range(0); ++i) {
+            vec.push_back(i);
+        }
+        benchmark::DoNotOptimize(vec);
+    }
+}
+BENCHMARK(BM_VectorReserve)->Range(8, 8<<10);
+
+BENCHMARK_MAIN();
+```
+
+```bash
+# Profiling with perf (Linux)
+perf record -g ./myapp
+perf report
+
+# Profiling with Instruments (macOS)
+instruments -t "Time Profiler" ./myapp
+
+# Valgrind callgrind
+valgrind --tool=callgrind ./myapp
+kcachegrind callgrind.out.*
+
+# Memory profiling
+valgrind --tool=massif ./myapp
+ms_print massif.out.*
+```
+
+## Conan Package Manager
+
+```python
+# conanfile.txt
+[requires]
+fmt/10.1.1
+spdlog/1.12.0
+catch2/3.4.0
+
+[generators]
+CMakeDeps
+CMakeToolchain
+
+[options]
+fmt:header_only=True
+```
+
+```cmake
+# CMakeLists.txt with Conan
+cmake_minimum_required(VERSION 3.20)
+project(MyProject)
+
+find_package(fmt REQUIRED)
+find_package(spdlog REQUIRED)
+find_package(Catch2 REQUIRED)
+
+add_executable(myapp src/main.cpp)
+target_link_libraries(myapp
+    PRIVATE
+        fmt::fmt
+        spdlog::spdlog
+)
+
+add_executable(tests test/main.cpp)
+target_link_libraries(tests
+    PRIVATE
+        Catch2::Catch2WithMain
+)
+```
+
+```bash
+# Install dependencies
+conan install . --output-folder=build --build=missing
+cd build
+cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake
+cmake --build .
+```
+
+## CI/CD with GitHub Actions
+
+```yaml
+# .github/workflows/ci.yml
+name: CI
+
+on: [push, pull_request]
+
+jobs:
+  build:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [ubuntu-latest, macos-latest, windows-latest]
+        compiler: [gcc, clang, msvc]
+        build_type: [Debug, Release]
+
+    steps:
+    - uses: actions/checkout@v3
+
+    - name: Install dependencies
+      run: |
+        pip install conan
+        conan install . --output-folder=build --build=missing
+
+    - name: Configure
+      run: |
+        cmake -B build -DCMAKE_BUILD_TYPE=${{ matrix.build_type }}
+
+    - name: Build
+      run: cmake --build build --config ${{ matrix.build_type }}
+
+    - name: Test
+      run: ctest --test-dir build -C ${{ matrix.build_type }}
+
+  sanitizers:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        sanitizer: [asan, ubsan, tsan]
+
+    steps:
+    - uses: actions/checkout@v3
+
+    - name: Build with sanitizer
+      run: |
+        cmake -B build -DCMAKE_BUILD_TYPE=${{ matrix.sanitizer }}
+        cmake --build build
+
+    - name: Run tests
+      run: ctest --test-dir build
+
+  static-analysis:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v3
+
+    - name: Run clang-tidy
+      run: |
+        cmake -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
+        clang-tidy src/*.cpp -p build/
+
+    - name: Run cppcheck
+      run: cppcheck --enable=all --error-exitcode=1 src/
+```
+
+## Quick Reference
+
+| Tool | Purpose | Command |
+|------|---------|---------|
+| CMake | Build system | `cmake -B build && cmake --build build` |
+| Conan | Package manager | `conan install . --build=missing` |
+| ASan | Memory errors | `-fsanitize=address` |
+| UBSan | Undefined behavior | `-fsanitize=undefined` |
+| TSan | Data races | `-fsanitize=thread` |
+| clang-tidy | Static analysis | `clang-tidy src/*.cpp` |
+| cppcheck | Static analysis | `cppcheck --enable=all src/` |
+| Catch2 | Unit testing | `TEST_CASE("name") { REQUIRE(...); }` |
+| GoogleTest | Unit testing | `TEST(Suite, Name) { EXPECT_EQ(...); }` |
+| Google Benchmark | Performance | `BENCHMARK(func)->Range(...)` |
+| Valgrind | Memory profiler | `valgrind --tool=memcheck ./app` |

.claude/skills/cpp-pro/references/concurrency.md

@@ -0,0 +1,440 @@
+# Concurrency and Parallel Programming
+
+> Reference for: C++ Pro
+> Load when: Atomics, lock-free structures, thread pools, parallel algorithms, coroutines
+
+## Atomics and Memory Ordering
+
+```cpp
+#include <atomic>
+#include <thread>
+
+// Basic atomics
+std::atomic<int> counter{0};
+std::atomic<bool> flag{false};
+
+// Memory ordering
+void producer(std::atomic<int>& data, std::atomic<bool>& ready) {
+    data.store(42, std::memory_order_relaxed);
+    ready.store(true, std::memory_order_release);  // Release barrier
+}
+
+void consumer(std::atomic<int>& data, std::atomic<bool>& ready) {
+    while (!ready.load(std::memory_order_acquire)) {  // Acquire barrier
+        std::this_thread::yield();
+    }
+    int value = data.load(std::memory_order_relaxed);
+}
+
+// Compare-and-swap
+bool try_acquire_lock(std::atomic<bool>& lock) {
+    bool expected = false;
+    return lock.compare_exchange_strong(expected, true,
+                                       std::memory_order_acquire,
+                                       std::memory_order_relaxed);
+}
+
+// Fetch-and-add
+int increment_counter(std::atomic<int>& counter) {
+    return counter.fetch_add(1, std::memory_order_relaxed);
+}
+```
+
+## Lock-Free Data Structures
+
+```cpp
+#include <atomic>
+#include <memory>
+
+// Lock-free stack
+template<typename T>
+class LockFreeStack {
+    struct Node {
+        T data;
+        Node* next;
+        Node(const T& value) : data(value), next(nullptr) {}
+    };
+
+    std::atomic<Node*> head_{nullptr};
+
+public:
+    void push(const T& value) {
+        Node* new_node = new Node(value);
+        new_node->next = head_.load(std::memory_order_relaxed);
+
+        while (!head_.compare_exchange_weak(new_node->next, new_node,
+                                           std::memory_order_release,
+                                           std::memory_order_relaxed)) {
+            // Retry with updated head
+        }
+    }
+
+    bool pop(T& result) {
+        Node* old_head = head_.load(std::memory_order_relaxed);
+
+        while (old_head &&
+               !head_.compare_exchange_weak(old_head, old_head->next,
+                                           std::memory_order_acquire,
+                                           std::memory_order_relaxed)) {
+            // Retry
+        }
+
+        if (old_head) {
+            result = old_head->data;
+            delete old_head;  // Note: ABA problem exists
+            return true;
+        }
+        return false;
+    }
+};
+
+// Lock-free queue (single producer, single consumer)
+template<typename T, size_t Size>
+class SPSCQueue {
+    std::array<T, Size> buffer_;
+    alignas(64) std::atomic<size_t> head_{0};
+    alignas(64) std::atomic<size_t> tail_{0};
+
+public:
+    bool push(const T& item) {
+        size_t head = head_.load(std::memory_order_relaxed);
+        size_t next_head = (head + 1) % Size;
+
+        if (next_head == tail_.load(std::memory_order_acquire)) {
+            return false;  // Queue full
+        }
+
+        buffer_[head] = item;
+        head_.store(next_head, std::memory_order_release);
+        return true;
+    }
+
+    bool pop(T& item) {
+        size_t tail = tail_.load(std::memory_order_relaxed);
+
+        if (tail == head_.load(std::memory_order_acquire)) {
+            return false;  // Queue empty
+        }
+
+        item = buffer_[tail];
+        tail_.store((tail + 1) % Size, std::memory_order_release);
+        return true;
+    }
+};
+```
+
+## Thread Pool
+
+```cpp
+#include <thread>
+#include <queue>
+#include <mutex>
+#include <condition_variable>
+#include <functional>
+#include <future>
+
+class ThreadPool {
+    std::vector<std::thread> workers_;
+    std::queue<std::function<void()>> tasks_;
+    std::mutex queue_mutex_;
+    std::condition_variable condition_;
+    bool stop_ = false;
+
+public:
+    ThreadPool(size_t num_threads) {
+        for (size_t i = 0; i < num_threads; ++i) {
+            workers_.emplace_back([this] {
+                while (true) {
+                    std::function<void()> task;
+
+                    {
+                        std::unique_lock<std::mutex> lock(queue_mutex_);
+                        condition_.wait(lock, [this] {
+                            return stop_ || !tasks_.empty();
+                        });
+
+                        if (stop_ && tasks_.empty()) {
+                            return;
+                        }
+
+                        task = std::move(tasks_.front());
+                        tasks_.pop();
+                    }
+
+                    task();
+                }
+            });
+        }
+    }
+
+    ~ThreadPool() {
+        {
+            std::unique_lock<std::mutex> lock(queue_mutex_);
+            stop_ = true;
+        }
+        condition_.notify_all();
+        for (auto& worker : workers_) {
+            worker.join();
+        }
+    }
+
+    template<typename F, typename... Args>
+    auto enqueue(F&& f, Args&&... args)
+        -> std::future<typename std::invoke_result_t<F, Args...>> {
+
+        using return_type = typename std::invoke_result_t<F, Args...>;
+
+        auto task = std::make_shared<std::packaged_task<return_type()>>(
+            std::bind(std::forward<F>(f), std::forward<Args>(args)...)
+        );
+
+        std::future<return_type> result = task->get_future();
+
+        {
+            std::unique_lock<std::mutex> lock(queue_mutex_);
+            if (stop_) {
+                throw std::runtime_error("enqueue on stopped ThreadPool");
+            }
+            tasks_.emplace([task]() { (*task)(); });
+        }
+
+        condition_.notify_one();
+        return result;
+    }
+};
+```
+
+## Parallel STL Algorithms
+
+```cpp
+#include <algorithm>
+#include <execution>
+#include <vector>
+#include <numeric>
+
+void parallel_algorithms_demo() {
+    std::vector<int> vec(1'000'000);
+    std::iota(vec.begin(), vec.end(), 0);
+
+    // Parallel sort
+    std::sort(std::execution::par, vec.begin(), vec.end());
+
+    // Parallel for_each
+    std::for_each(std::execution::par_unseq, vec.begin(), vec.end(),
+                  [](int& x) { x *= 2; });
+
+    // Parallel transform
+    std::vector<int> result(vec.size());
+    std::transform(std::execution::par, vec.begin(), vec.end(),
+                   result.begin(), [](int x) { return x * x; });
+
+    // Parallel reduce
+    int sum = std::reduce(std::execution::par, vec.begin(), vec.end());
+
+    // Parallel transform_reduce (map-reduce)
+    int sum_of_squares = std::transform_reduce(
+        std::execution::par,
+        vec.begin(), vec.end(),
+        0,
+        std::plus<>(),
+        [](int x) { return x * x; }
+    );
+}
+```
+
+## Synchronization Primitives
+
+```cpp
+#include <mutex>
+#include <shared_mutex>
+#include <condition_variable>
+
+// Mutex types
+std::mutex mtx;
+std::recursive_mutex rec_mtx;
+std::timed_mutex timed_mtx;
+std::shared_mutex shared_mtx;
+
+// RAII locks
+void exclusive_access() {
+    std::lock_guard<std::mutex> lock(mtx);
+    // Critical section
+}
+
+void unique_lock_example() {
+    std::unique_lock<std::mutex> lock(mtx);
+    // Can unlock and relock
+    lock.unlock();
+    // Do some work
+    lock.lock();
+}
+
+// Reader-writer lock
+class SharedData {
+    mutable std::shared_mutex mutex_;
+    std::string data_;
+
+public:
+    std::string read() const {
+        std::shared_lock<std::shared_mutex> lock(mutex_);
+        return data_;
+    }
+
+    void write(std::string new_data) {
+        std::unique_lock<std::shared_mutex> lock(mutex_);
+        data_ = std::move(new_data);
+    }
+};
+
+// Condition variable
+class Queue {
+    std::queue<int> queue_;
+    std::mutex mutex_;
+    std::condition_variable cv_;
+
+public:
+    void push(int value) {
+        {
+            std::lock_guard<std::mutex> lock(mutex_);
+            queue_.push(value);
+        }
+        cv_.notify_one();
+    }
+
+    int pop() {
+        std::unique_lock<std::mutex> lock(mutex_);
+        cv_.wait(lock, [this] { return !queue_.empty(); });
+        int value = queue_.front();
+        queue_.pop();
+        return value;
+    }
+};
+
+// std::scoped_lock - multiple mutexes
+std::mutex mtx1, mtx2;
+
+void transfer(Account& from, Account& to, int amount) {
+    std::scoped_lock lock(from.mutex, to.mutex);  // Deadlock-free
+    from.balance -= amount;
+    to.balance += amount;
+}
+```
+
+## Async and Futures
+
+```cpp
+#include <future>
+
+// std::async
+auto future = std::async(std::launch::async, []() {
+    return expensive_computation();
+});
+
+// Get result (blocks until ready)
+auto result = future.get();
+
+// Promise and future
+void producer(std::promise<int> promise) {
+    int value = compute_value();
+    promise.set_value(value);
+}
+
+void consumer(std::future<int> future) {
+    int value = future.get();
+}
+
+std::promise<int> promise;
+std::future<int> future = promise.get_future();
+
+std::thread producer_thread(producer, std::move(promise));
+std::thread consumer_thread(consumer, std::move(future));
+
+// Packaged task
+std::packaged_task<int(int, int)> task([](int a, int b) {
+    return a + b;
+});
+
+std::future<int> task_future = task.get_future();
+std::thread task_thread(std::move(task), 5, 3);
+
+int sum = task_future.get();  // 8
+task_thread.join();
+```
+
+## Coroutine-Based Concurrency
+
+```cpp
+#include <coroutine>
+#include <optional>
+
+// Async task coroutine
+template<typename T>
+struct AsyncTask {
+    struct promise_type {
+        std::optional<T> value;
+        std::exception_ptr exception;
+
+        AsyncTask get_return_object() {
+            return AsyncTask{
+                std::coroutine_handle<promise_type>::from_promise(*this)
+            };
+        }
+
+        std::suspend_never initial_suspend() { return {}; }
+        std::suspend_always final_suspend() noexcept { return {}; }
+
+        void return_value(T v) {
+            value = std::move(v);
+        }
+
+        void unhandled_exception() {
+            exception = std::current_exception();
+        }
+    };
+
+    std::coroutine_handle<promise_type> handle;
+
+    AsyncTask(std::coroutine_handle<promise_type> h) : handle(h) {}
+    ~AsyncTask() { if (handle) handle.destroy(); }
+
+    T get() {
+        if (!handle.done()) {
+            handle.resume();
+        }
+
+        if (handle.promise().exception) {
+            std::rethrow_exception(handle.promise().exception);
+        }
+
+        return *handle.promise().value;
+    }
+};
+
+// Usage
+AsyncTask<int> async_compute() {
+    co_return 42;
+}
+```
+
+## Quick Reference
+
+| Primitive | Use Case | Performance |
+|-----------|----------|-------------|
+| std::atomic | Simple shared state | Lock-free |
+| std::mutex | Exclusive access | Kernel call |
+| std::shared_mutex | Read-heavy workload | Better than mutex |
+| Lock-free structures | High contention | Best throughput |
+| Thread pool | Task parallelism | Avoid thread overhead |
+| Parallel STL | Data parallelism | Automatic scaling |
+| std::async | Simple async tasks | Thread pool |
+| Coroutines | Async I/O | Minimal overhead |
+
+## Memory Ordering Guide
+
+| Ordering | Guarantees | Use Case |
+|----------|-----------|----------|
+| relaxed | No synchronization | Counters |
+| acquire | Load barrier | Consumer |
+| release | Store barrier | Producer |
+| acq_rel | Both | RMW operations |
+| seq_cst | Total order | Default |

.claude/skills/cpp-pro/references/memory-performance.md

@@ -0,0 +1,400 @@
+# Memory Management & Performance
+
+> Reference for: C++ Pro
+> Load when: Custom allocators, SIMD, cache optimization, move semantics, memory pools
+
+## Smart Pointers
+
+```cpp
+#include <memory>
+
+// unique_ptr - exclusive ownership
+auto create_resource() {
+    return std::make_unique<Resource>("data");
+}
+
+// shared_ptr - reference counting
+std::shared_ptr<Data> shared = std::make_shared<Data>(42);
+std::weak_ptr<Data> weak = shared;  // Non-owning reference
+
+// Custom deleters
+auto file_deleter = [](FILE* fp) { if (fp) fclose(fp); };
+std::unique_ptr<FILE, decltype(file_deleter)> file(
+    fopen("data.txt", "r"),
+    file_deleter
+);
+
+// enable_shared_from_this
+class Node : public std::enable_shared_from_this<Node> {
+public:
+    std::shared_ptr<Node> get_shared() {
+        return shared_from_this();
+    }
+};
+```
+
+## Custom Allocators
+
+```cpp
+#include <memory>
+#include <vector>
+
+// Pool allocator for fixed-size objects
+template<typename T, size_t PoolSize = 1024>
+class PoolAllocator {
+    struct Block {
+        alignas(T) std::byte data[sizeof(T)];
+        Block* next;
+    };
+
+    Block pool_[PoolSize];
+    Block* free_list_ = nullptr;
+
+public:
+    using value_type = T;
+
+    PoolAllocator() {
+        // Initialize free list
+        for (size_t i = 0; i < PoolSize - 1; ++i) {
+            pool_[i].next = &pool_[i + 1];
+        }
+        pool_[PoolSize - 1].next = nullptr;
+        free_list_ = &pool_[0];
+    }
+
+    T* allocate(size_t n) {
+        if (n != 1 || !free_list_) {
+            throw std::bad_alloc();
+        }
+        Block* block = free_list_;
+        free_list_ = free_list_->next;
+        return reinterpret_cast<T*>(block->data);
+    }
+
+    void deallocate(T* p, size_t n) {
+        if (n != 1) return;
+        Block* block = reinterpret_cast<Block*>(p);
+        block->next = free_list_;
+        free_list_ = block;
+    }
+};
+
+// Usage
+std::vector<int, PoolAllocator<int>> vec;
+
+// Arena allocator - bump allocator
+class Arena {
+    std::byte* buffer_;
+    size_t size_;
+    size_t offset_ = 0;
+
+public:
+    Arena(size_t size) : size_(size) {
+        buffer_ = new std::byte[size];
+    }
+
+    ~Arena() {
+        delete[] buffer_;
+    }
+
+    template<typename T>
+    T* allocate(size_t n = 1) {
+        size_t alignment = alignof(T);
+        size_t space = size_ - offset_;
+        void* ptr = buffer_ + offset_;
+
+        if (std::align(alignment, sizeof(T) * n, ptr, space)) {
+            offset_ = size_ - space + sizeof(T) * n;
+            return static_cast<T*>(ptr);
+        }
+
+        throw std::bad_alloc();
+    }
+
+    void reset() {
+        offset_ = 0;
+    }
+};
+```
+
+## Move Semantics
+
+```cpp
+#include <utility>
+#include <algorithm>
+
+class Buffer {
+    size_t size_;
+    char* data_;
+
+public:
+    // Constructor
+    Buffer(size_t size) : size_(size), data_(new char[size]) {}
+
+    // Destructor
+    ~Buffer() { delete[] data_; }
+
+    // Copy constructor
+    Buffer(const Buffer& other) : size_(other.size_), data_(new char[size_]) {
+        std::copy(other.data_, other.data_ + size_, data_);
+    }
+
+    // Copy assignment
+    Buffer& operator=(const Buffer& other) {
+        if (this != &other) {
+            delete[] data_;
+            size_ = other.size_;
+            data_ = new char[size_];
+            std::copy(other.data_, other.data_ + size_, data_);
+        }
+        return *this;
+    }
+
+    // Move constructor
+    Buffer(Buffer&& other) noexcept
+        : size_(other.size_), data_(other.data_) {
+        other.size_ = 0;
+        other.data_ = nullptr;
+    }
+
+    // Move assignment
+    Buffer& operator=(Buffer&& other) noexcept {
+        if (this != &other) {
+            delete[] data_;
+            size_ = other.size_;
+            data_ = other.data_;
+            other.size_ = 0;
+            other.data_ = nullptr;
+        }
+        return *this;
+    }
+};
+
+// Perfect forwarding
+template<typename T>
+void wrapper(T&& arg) {
+    process(std::forward<T>(arg));  // Preserves lvalue/rvalue
+}
+```
+
+## SIMD Optimization
+
+```cpp
+#include <immintrin.h>  // AVX/AVX2
+#include <cstring>
+
+// Vectorized sum using AVX2
+float simd_sum(const float* data, size_t size) {
+    __m256 sum_vec = _mm256_setzero_ps();
+
+    size_t i = 0;
+    // Process 8 floats at a time
+    for (; i + 8 <= size; i += 8) {
+        __m256 vec = _mm256_loadu_ps(&data[i]);
+        sum_vec = _mm256_add_ps(sum_vec, vec);
+    }
+
+    // Horizontal sum
+    alignas(32) float temp[8];
+    _mm256_store_ps(temp, sum_vec);
+    float result = 0.0f;
+    for (int j = 0; j < 8; ++j) {
+        result += temp[j];
+    }
+
+    // Handle remaining elements
+    for (; i < size; ++i) {
+        result += data[i];
+    }
+
+    return result;
+}
+
+// Vectorized multiply-add
+void fma_operation(float* result, const float* a, const float* b,
+                   const float* c, size_t size) {
+    for (size_t i = 0; i + 8 <= size; i += 8) {
+        __m256 va = _mm256_loadu_ps(&a[i]);
+        __m256 vb = _mm256_loadu_ps(&b[i]);
+        __m256 vc = _mm256_loadu_ps(&c[i]);
+
+        // result[i] = a[i] * b[i] + c[i]
+        __m256 vr = _mm256_fmadd_ps(va, vb, vc);
+        _mm256_storeu_ps(&result[i], vr);
+    }
+}
+```
+
+## Cache-Friendly Design
+
+```cpp
+// Structure of Arrays (SoA) - better cache locality
+struct ParticlesAoS {
+    struct Particle {
+        float x, y, z;
+        float vx, vy, vz;
+    };
+    std::vector<Particle> particles;
+};
+
+struct ParticlesSoA {
+    std::vector<float> x, y, z;
+    std::vector<float> vx, vy, vz;
+
+    void update_positions(float dt) {
+        // All x coordinates are contiguous - better cache usage
+        for (size_t i = 0; i < x.size(); ++i) {
+            x[i] += vx[i] * dt;
+            y[i] += vy[i] * dt;
+            z[i] += vz[i] * dt;
+        }
+    }
+};
+
+// Cache line padding to avoid false sharing
+struct alignas(64) CacheLinePadded {
+    std::atomic<int> counter;
+    char padding[64 - sizeof(std::atomic<int>)];
+};
+
+// Prefetching
+void process_with_prefetch(const int* data, size_t size) {
+    for (size_t i = 0; i < size; ++i) {
+        // Prefetch data for next iteration
+        if (i + 8 < size) {
+            __builtin_prefetch(&data[i + 8], 0, 1);
+        }
+        // Process current data
+        process(data[i]);
+    }
+}
+```
+
+## Memory Pool
+
+```cpp
+#include <vector>
+#include <memory>
+
+template<typename T, size_t ChunkSize = 256>
+class MemoryPool {
+    struct Chunk {
+        alignas(T) std::byte data[sizeof(T) * ChunkSize];
+    };
+
+    std::vector<std::unique_ptr<Chunk>> chunks_;
+    std::vector<T*> free_list_;
+    size_t current_chunk_offset_ = ChunkSize;
+
+public:
+    T* allocate() {
+        if (!free_list_.empty()) {
+            T* ptr = free_list_.back();
+            free_list_.pop_back();
+            return ptr;
+        }
+
+        if (current_chunk_offset_ >= ChunkSize) {
+            chunks_.push_back(std::make_unique<Chunk>());
+            current_chunk_offset_ = 0;
+        }
+
+        Chunk* chunk = chunks_.back().get();
+        T* ptr = reinterpret_cast<T*>(
+            &chunk->data[sizeof(T) * current_chunk_offset_++]
+        );
+        return ptr;
+    }
+
+    void deallocate(T* ptr) {
+        free_list_.push_back(ptr);
+    }
+
+    template<typename... Args>
+    T* construct(Args&&... args) {
+        T* ptr = allocate();
+        new (ptr) T(std::forward<Args>(args)...);
+        return ptr;
+    }
+
+    void destroy(T* ptr) {
+        ptr->~T();
+        deallocate(ptr);
+    }
+};
+```
+
+## Copy Elision and RVO
+
+```cpp
+// Return Value Optimization (RVO)
+std::vector<int> create_vector() {
+    std::vector<int> vec{1, 2, 3, 4, 5};
+    return vec;  // RVO applies, no copy/move
+}
+
+// Named Return Value Optimization (NRVO)
+std::string build_string(bool condition) {
+    std::string result;
+    if (condition) {
+        result = "condition true";
+    } else {
+        result = "condition false";
+    }
+    return result;  // NRVO may apply
+}
+
+// Guaranteed copy elision (C++17)
+struct NonMovable {
+    NonMovable() = default;
+    NonMovable(const NonMovable&) = delete;
+    NonMovable(NonMovable&&) = delete;
+};
+
+NonMovable create() {
+    return NonMovable{};  // Guaranteed no copy/move in C++17
+}
+
+auto obj = create();  // OK in C++17
+```
+
+## Alignment and Memory Layout
+
+```cpp
+#include <cstddef>
+
+// Control alignment
+struct alignas(64) CacheAligned {
+    int data[16];
+};
+
+// Check alignment
+static_assert(alignof(CacheAligned) == 64);
+
+// Aligned allocation
+void* aligned_alloc_wrapper(size_t alignment, size_t size) {
+    void* ptr = nullptr;
+    if (posix_memalign(&ptr, alignment, size) != 0) {
+        throw std::bad_alloc();
+    }
+    return ptr;
+}
+
+// Placement new with alignment
+alignas(32) std::byte buffer[sizeof(Data)];
+Data* obj = new (buffer) Data();
+obj->~Data();  // Manual destruction needed
+```
+
+## Quick Reference
+
+| Technique | Use Case | Benefit |
+|-----------|----------|---------|
+| Smart Pointers | Ownership management | Memory safety |
+| Move Semantics | Avoid copies | Performance |
+| Custom Allocators | Specialized allocation | Speed + control |
+| SIMD | Parallel computation | 4-8x speedup |
+| SoA Layout | Sequential access | Cache efficiency |
+| Memory Pools | Frequent alloc/dealloc | Reduced fragmentation |
+| Alignment | SIMD/cache optimization | Performance |
+| RVO/NRVO | Return objects | Zero-copy |

.claude/skills/cpp-pro/references/modern-cpp.md

@@ -0,0 +1,307 @@
+# Modern C++20/23 Features
+
+> Reference for: C++ Pro
+> Load when: Using C++20/23 features, concepts, ranges, coroutines, modules
+
+## Concepts and Constraints
+
+```cpp
+#include <concepts>
+
+// Define custom concepts
+template<typename T>
+concept Numeric = std::integral<T> || std::floating_point<T>;
+
+template<typename T>
+concept Hashable = requires(T a) {
+    { std::hash<T>{}(a) } -> std::convertible_to<std::size_t>;
+};
+
+template<typename T>
+concept Container = requires(T c) {
+    typename T::value_type;
+    typename T::iterator;
+    { c.begin() } -> std::same_as<typename T::iterator>;
+    { c.end() } -> std::same_as<typename T::iterator>;
+    { c.size() } -> std::convertible_to<std::size_t>;
+};
+
+// Use concepts for function constraints
+template<Numeric T>
+T add(T a, T b) {
+    return a + b;
+}
+
+// Concept-based overloading
+template<std::integral T>
+void process(T value) {
+    std::cout << "Processing integer: " << value << '\n';
+}
+
+template<std::floating_point T>
+void process(T value) {
+    std::cout << "Processing float: " << value << '\n';
+}
+```
+
+## Ranges and Views
+
+```cpp
+#include <ranges>
+#include <vector>
+#include <algorithm>
+
+// Ranges-based algorithms
+std::vector<int> numbers = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
+
+// Filter, transform, take - all lazy evaluation
+auto result = numbers
+    | std::views::filter([](int n) { return n % 2 == 0; })
+    | std::views::transform([](int n) { return n * n; })
+    | std::views::take(3);
+
+// Copy to vector only when needed
+std::vector<int> materialized(result.begin(), result.end());
+
+// Custom range adaptor
+auto is_even = [](int n) { return n % 2 == 0; };
+auto square = [](int n) { return n * n; };
+
+auto pipeline = std::views::filter(is_even)
+              | std::views::transform(square);
+
+auto processed = numbers | pipeline;
+```
+
+## Coroutines
+
+```cpp
+#include <coroutine>
+#include <iostream>
+#include <memory>
+
+// Generator coroutine
+template<typename T>
+struct Generator {
+    struct promise_type {
+        T current_value;
+
+        auto get_return_object() {
+            return Generator{std::coroutine_handle<promise_type>::from_promise(*this)};
+        }
+
+        std::suspend_always initial_suspend() { return {}; }
+        std::suspend_always final_suspend() noexcept { return {}; }
+
+        std::suspend_always yield_value(T value) {
+            current_value = value;
+            return {};
+        }
+
+        void return_void() {}
+        void unhandled_exception() { std::terminate(); }
+    };
+
+    std::coroutine_handle<promise_type> handle;
+
+    Generator(std::coroutine_handle<promise_type> h) : handle(h) {}
+    ~Generator() { if (handle) handle.destroy(); }
+
+    bool move_next() {
+        handle.resume();
+        return !handle.done();
+    }
+
+    T current_value() {
+        return handle.promise().current_value;
+    }
+};
+
+// Usage
+Generator<int> fibonacci() {
+    int a = 0, b = 1;
+    while (true) {
+        co_yield a;
+        auto next = a + b;
+        a = b;
+        b = next;
+    }
+}
+
+// Async coroutine
+#include <future>
+
+struct Task {
+    struct promise_type {
+        Task get_return_object() {
+            return Task{std::coroutine_handle<promise_type>::from_promise(*this)};
+        }
+        std::suspend_never initial_suspend() { return {}; }
+        std::suspend_never final_suspend() noexcept { return {}; }
+        void return_void() {}
+        void unhandled_exception() {}
+    };
+
+    std::coroutine_handle<promise_type> handle;
+};
+
+Task async_operation() {
+    std::cout << "Starting async work\n";
+    co_await std::suspend_always{};
+    std::cout << "Resuming async work\n";
+}
+```
+
+## Three-Way Comparison (Spaceship)
+
+```cpp
+#include <compare>
+
+struct Point {
+    int x, y;
+
+    // Auto-generate all comparison operators
+    auto operator<=>(const Point&) const = default;
+};
+
+// Custom spaceship operator
+struct Version {
+    int major, minor, patch;
+
+    std::strong_ordering operator<=>(const Version& other) const {
+        if (auto cmp = major <=> other.major; cmp != 0) return cmp;
+        if (auto cmp = minor <=> other.minor; cmp != 0) return cmp;
+        return patch <=> other.patch;
+    }
+
+    bool operator==(const Version& other) const = default;
+};
+```
+
+## Designated Initializers
+
+```cpp
+struct Config {
+    std::string host = "localhost";
+    int port = 8080;
+    bool ssl_enabled = false;
+    int timeout_ms = 5000;
+};
+
+// C++20 designated initializers
+Config cfg {
+    .host = "example.com",
+    .port = 443,
+    .ssl_enabled = true
+    // timeout_ms uses default
+};
+```
+
+## Modules (C++20)
+
+```cpp
+// math.cppm - module interface
+export module math;
+
+export namespace math {
+    template<typename T>
+    T add(T a, T b) {
+        return a + b;
+    }
+
+    class Calculator {
+    public:
+        int multiply(int a, int b);
+    };
+}
+
+// Implementation
+module math;
+
+int math::Calculator::multiply(int a, int b) {
+    return a * b;
+}
+
+// Usage in other files
+import math;
+
+int main() {
+    auto result = math::add(5, 3);
+    math::Calculator calc;
+    auto product = calc.multiply(4, 7);
+}
+```
+
+## constexpr Enhancements
+
+```cpp
+#include <string>
+#include <vector>
+#include <algorithm>
+
+// C++20: constexpr std::string and std::vector
+constexpr auto compute_at_compile_time() {
+    std::vector<int> vec{1, 2, 3, 4, 5};
+    std::ranges::reverse(vec);
+    return vec[0]; // Returns 5
+}
+
+constexpr int value = compute_at_compile_time();
+
+// constexpr virtual functions (C++20)
+struct Base {
+    constexpr virtual int get_value() const { return 42; }
+    constexpr virtual ~Base() = default;
+};
+
+struct Derived : Base {
+    constexpr int get_value() const override { return 100; }
+};
+```
+
+## std::format (C++20)
+
+```cpp
+#include <format>
+#include <iostream>
+
+int main() {
+    std::string msg = std::format("Hello, {}!", "World");
+
+    // Positional arguments
+    auto text = std::format("{1} {0}", "World", "Hello");
+
+    // Formatting options
+    double pi = 3.14159265;
+    auto formatted = std::format("Pi: {:.2f}", pi); // "Pi: 3.14"
+
+    // Custom types
+    struct Point { int x, y; };
+}
+
+// Custom formatter
+template<>
+struct std::formatter<Point> {
+    constexpr auto parse(format_parse_context& ctx) {
+        return ctx.begin();
+    }
+
+    auto format(const Point& p, format_context& ctx) const {
+        return std::format_to(ctx.out(), "({}, {})", p.x, p.y);
+    }
+};
+```
+
+## Quick Reference
+
+| Feature | C++17 | C++20 | C++23 |
+|---------|-------|-------|-------|
+| Concepts | - | ✓ | ✓ |
+| Ranges | - | ✓ | ✓ |
+| Coroutines | - | ✓ | ✓ |
+| Modules | - | ✓ | ✓ |
+| Spaceship | - | ✓ | ✓ |
+| std::format | - | ✓ | ✓ |
+| std::expected | - | - | ✓ |
+| std::print | - | - | ✓ |
+| Deducing this | - | - | ✓ |

.claude/skills/cpp-pro/references/templates.md

@@ -0,0 +1,360 @@
+# Template Metaprogramming
+
+> Reference for: C++ Pro
+> Load when: Variadic templates, SFINAE, type traits, CRTP, compile-time programming
+
+## Variadic Templates
+
+```cpp
+#include <iostream>
+#include <utility>
+
+// Fold expressions (C++17)
+template<typename... Args>
+auto sum(Args... args) {
+    return (args + ...);  // Unary right fold
+}
+
+template<typename... Args>
+void print(Args&&... args) {
+    ((std::cout << args << ' '), ...);  // Binary left fold
+    std::cout << '\n';
+}
+
+// Recursive variadic template
+template<typename T>
+void log(T&& value) {
+    std::cout << value << '\n';
+}
+
+template<typename T, typename... Args>
+void log(T&& first, Args&&... rest) {
+    std::cout << first << ", ";
+    log(std::forward<Args>(rest)...);
+}
+
+// Parameter pack expansion
+template<typename... Types>
+struct TypeList {
+    static constexpr size_t size = sizeof...(Types);
+};
+
+template<typename... Args>
+auto make_tuple_advanced(Args&&... args) {
+    return std::tuple<std::decay_t<Args>...>(std::forward<Args>(args)...);
+}
+```
+
+## SFINAE and if constexpr
+
+```cpp
+#include <type_traits>
+
+// SFINAE with std::enable_if (older style)
+template<typename T>
+std::enable_if_t<std::is_integral_v<T>, T>
+double_value(T value) {
+    return value * 2;
+}
+
+template<typename T>
+std::enable_if_t<std::is_floating_point_v<T>, T>
+double_value(T value) {
+    return value * 2.0;
+}
+
+// Modern: if constexpr (C++17)
+template<typename T>
+auto process(T value) {
+    if constexpr (std::is_integral_v<T>) {
+        return value * 2;
+    } else if constexpr (std::is_floating_point_v<T>) {
+        return value * 2.0;
+    } else {
+        return value;
+    }
+}
+
+// Detection idiom
+template<typename T, typename = void>
+struct has_serialize : std::false_type {};
+
+template<typename T>
+struct has_serialize<T, std::void_t<decltype(std::declval<T>().serialize())>>
+    : std::true_type {};
+
+template<typename T>
+constexpr bool has_serialize_v = has_serialize<T>::value;
+
+// Use with if constexpr
+template<typename T>
+void save(const T& obj) {
+    if constexpr (has_serialize_v<T>) {
+        obj.serialize();
+    } else {
+        // Default serialization
+    }
+}
+```
+
+## Type Traits
+
+```cpp
+#include <type_traits>
+
+// Custom type traits
+template<typename T>
+struct remove_all_pointers {
+    using type = T;
+};
+
+template<typename T>
+struct remove_all_pointers<T*> {
+    using type = typename remove_all_pointers<T>::type;
+};
+
+template<typename T>
+using remove_all_pointers_t = typename remove_all_pointers<T>::type;
+
+// Conditional types
+template<bool Condition, typename T, typename F>
+struct conditional_type {
+    using type = T;
+};
+
+template<typename T, typename F>
+struct conditional_type<false, T, F> {
+    using type = F;
+};
+
+// Compile-time type selection
+template<size_t N>
+struct best_integral_type {
+    using type = std::conditional_t<N <= 8, uint8_t,
+                 std::conditional_t<N <= 16, uint16_t,
+                 std::conditional_t<N <= 32, uint32_t, uint64_t>>>;
+};
+
+// Check for member functions
+template<typename T, typename = void>
+struct has_reserve : std::false_type {};
+
+template<typename T>
+struct has_reserve<T, std::void_t<decltype(std::declval<T>().reserve(size_t{}))>>
+    : std::true_type {};
+```
+
+## CRTP (Curiously Recurring Template Pattern)
+
+```cpp
+// Static polymorphism with CRTP
+template<typename Derived>
+class Shape {
+public:
+    double area() const {
+        return static_cast<const Derived*>(this)->area_impl();
+    }
+
+    void draw() const {
+        static_cast<const Derived*>(this)->draw_impl();
+    }
+};
+
+class Circle : public Shape<Circle> {
+    double radius_;
+public:
+    Circle(double r) : radius_(r) {}
+
+    double area_impl() const {
+        return 3.14159 * radius_ * radius_;
+    }
+
+    void draw_impl() const {
+        std::cout << "Drawing circle\n";
+    }
+};
+
+class Rectangle : public Shape<Rectangle> {
+    double width_, height_;
+public:
+    Rectangle(double w, double h) : width_(w), height_(h) {}
+
+    double area_impl() const {
+        return width_ * height_;
+    }
+
+    void draw_impl() const {
+        std::cout << "Drawing rectangle\n";
+    }
+};
+
+// CRTP for mixin capabilities
+template<typename Derived>
+class Printable {
+public:
+    void print() const {
+        std::cout << static_cast<const Derived*>(this)->to_string() << '\n';
+    }
+};
+
+class User : public Printable<User> {
+    std::string name_;
+public:
+    User(std::string name) : name_(std::move(name)) {}
+
+    std::string to_string() const {
+        return "User: " + name_;
+    }
+};
+```
+
+## Template Template Parameters
+
+```cpp
+#include <vector>
+#include <list>
+#include <deque>
+
+// Template template parameter
+template<typename T, template<typename, typename> class Container>
+class Stack {
+    Container<T, std::allocator<T>> data_;
+
+public:
+    void push(const T& value) {
+        data_.push_back(value);
+    }
+
+    T pop() {
+        T value = data_.back();
+        data_.pop_back();
+        return value;
+    }
+
+    size_t size() const {
+        return data_.size();
+    }
+};
+
+// Usage with different containers
+Stack<int, std::vector> vector_stack;
+Stack<int, std::deque> deque_stack;
+Stack<int, std::list> list_stack;
+```
+
+## Compile-Time Computation
+
+```cpp
+#include <array>
+
+// Compile-time factorial
+constexpr int factorial(int n) {
+    return n <= 1 ? 1 : n * factorial(n - 1);
+}
+
+constexpr int fact_5 = factorial(5);  // Computed at compile time
+
+// Compile-time prime checking
+constexpr bool is_prime(int n) {
+    if (n < 2) return false;
+    for (int i = 2; i * i <= n; ++i) {
+        if (n % i == 0) return false;
+    }
+    return true;
+}
+
+// Generate compile-time array of primes
+template<size_t N>
+constexpr auto generate_primes() {
+    std::array<int, N> primes{};
+    int count = 0;
+    int candidate = 2;
+
+    while (count < N) {
+        if (is_prime(candidate)) {
+            primes[count++] = candidate;
+        }
+        ++candidate;
+    }
+
+    return primes;
+}
+
+constexpr auto first_10_primes = generate_primes<10>();
+```
+
+## Expression Templates
+
+```cpp
+// Lazy evaluation with expression templates
+template<typename E>
+class VecExpression {
+public:
+    double operator[](size_t i) const {
+        return static_cast<const E&>(*this)[i];
+    }
+
+    size_t size() const {
+        return static_cast<const E&>(*this).size();
+    }
+};
+
+class Vec : public VecExpression<Vec> {
+    std::vector<double> data_;
+
+public:
+    Vec(size_t n) : data_(n) {}
+
+    double operator[](size_t i) const { return data_[i]; }
+    double& operator[](size_t i) { return data_[i]; }
+    size_t size() const { return data_.size(); }
+
+    // Evaluate expression template
+    template<typename E>
+    Vec& operator=(const VecExpression<E>& expr) {
+        for (size_t i = 0; i < size(); ++i) {
+            data_[i] = expr[i];
+        }
+        return *this;
+    }
+};
+
+// Binary operation expression
+template<typename E1, typename E2>
+class VecSum : public VecExpression<VecSum<E1, E2>> {
+    const E1& lhs_;
+    const E2& rhs_;
+
+public:
+    VecSum(const E1& lhs, const E2& rhs) : lhs_(lhs), rhs_(rhs) {}
+
+    double operator[](size_t i) const {
+        return lhs_[i] + rhs_[i];
+    }
+
+    size_t size() const { return lhs_.size(); }
+};
+
+// Operator overload
+template<typename E1, typename E2>
+VecSum<E1, E2> operator+(const VecExpression<E1>& lhs,
+                         const VecExpression<E2>& rhs) {
+    return VecSum<E1, E2>(static_cast<const E1&>(lhs),
+                          static_cast<const E2&>(rhs));
+}
+
+// Usage: a = b + c + d  (no temporaries created!)
+```
+
+## Quick Reference
+
+| Technique | Use Case | Performance |
+|-----------|----------|-------------|
+| Variadic Templates | Variable arguments | Zero overhead |
+| SFINAE | Conditional compilation | Compile-time |
+| if constexpr | Type-based branching | Zero overhead |
+| CRTP | Static polymorphism | No vtable cost |
+| Expression Templates | Lazy evaluation | Eliminates temps |
+| Type Traits | Type introspection | Compile-time |
+| Fold Expressions | Parameter pack ops | Optimal |
+| Template Specialization | Type-specific impl | Zero overhead |

.claude/skills/requirements/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: requirements
+description: Update the Dota Factory requirements document with new or changed requirements
+argument-hint: <description of new requirement>
+disable-model-invocation: true
+---
+
+Read `docs/requirements.md`, then help the user update the requirements with the following change:
+
+$ARGUMENTS
+
+Ask any clarifying questions if the request is ambiguous, or flag any conflicts with existing requirements before making changes. Do not make changes to the requirements file before the answers are clear.

.gitignore

@@ -1 +1,5 @@
 /build/
+
+# local Claude Code config (machine-specific; .mcp.json holds credentials)
+/.mcp.json
+/.claude/settings.local.json

CMakeLists.txt

@@ -4,17 +4,27 @@ message(STATUS "Using CMake ${CMAKE_VERSION}")
 
 include(cmake/add_files.cmake)
 include(cmake/create_source_groups.cmake)
+include(cmake/version.cmake)
 
 # Project ----------------------------------------------------------------------
 
-project(DotaFactory)
+# Product identity — anything that depends on the product/project name is defined
+# here so it lives in a single place and can change in the future. These values
+# feed the build targets in src/CMakeLists.txt and the Windows version resource
+# (see cmake/version.rc.in).
+set(PRODUCT_NAME "DotaFactory")            # internal name and executable base name
+set(PRODUCT_DISPLAY_NAME "Dota Factory")   # human-readable product / file description
+set(PRODUCT_COMPANY "TODO: company")       # placeholder
+set(PRODUCT_COPYRIGHT "TODO: copyright")   # placeholder
+
+project(${PRODUCT_NAME})
 
 set(CMAKE_BUILD_TYPE_INIT "Release")
 
 
 # Qt ---------------------------------------------------------------------------
 
-find_package(Qt5 COMPONENTS Widgets Network Multimedia Charts REQUIRED)
+find_package(Qt5 COMPONENTS Widgets Network Multimedia Charts Svg REQUIRED)
 
 if(Qt5Widgets_FOUND)
 	message(STATUS "Found Qt ${Qt5Widgets_VERSION_STRING}")
@@ -54,6 +64,7 @@ function(COPY_QT_BINARIES TARGET_DIR IS_DEBUG)
 	configure_file("${QT_BINARY_DIR}/Qt5Network${SUFFIX}.dll" "${TARGET_DIR}/Qt5Network${SUFFIX}.dll" COPYONLY)
 	configure_file("${QT_BINARY_DIR}/Qt5Widgets${SUFFIX}.dll" "${TARGET_DIR}/Qt5Widgets${SUFFIX}.dll" COPYONLY)
 	configure_file("${QT_BINARY_DIR}/Qt5Multimedia${SUFFIX}.dll" "${TARGET_DIR}/Qt5Multimedia${SUFFIX}.dll" COPYONLY)
+	configure_file("${QT_BINARY_DIR}/Qt5Svg${SUFFIX}.dll" "${TARGET_DIR}/Qt5Svg${SUFFIX}.dll" COPYONLY)
 endfunction(COPY_QT_BINARIES)
 
 

bin/app/data/config/buildings.toml

@@ -1,5 +1,6 @@
 [[building]]
 id = "belt"
+tooltip = "Transports items one tile at a time in the direction it faces."
 cost = 2
 player_placeable = true
 construction_time_seconds = 0.2
@@ -7,6 +8,7 @@ surface_mask = ["A>"]
 
 [[building]]
 id = "splitter"
+tooltip = "Splits an incoming item stream between two outputs, with optional per-output filters."
 cost = 3
 player_placeable = true
 construction_time_seconds = 0.5
@@ -14,6 +16,7 @@ surface_mask = ["<A>"]
 
 [[building]]
 id = "tunnel_entry"
+tooltip = "Sends items underground so belts can cross. Places an entry, or an exit when it would connect to a matching entry under the cursor."
 cost = 5
 player_placeable = true
 construction_time_seconds = 0.5
@@ -21,6 +24,7 @@ surface_mask = ["A>"]
 
 [[building]]
 id = "tunnel_exit"
+tooltip = "Receives items from a matching tunnel entry and pushes them onward."
 cost = 5
 player_placeable = true
 construction_time_seconds = 0.5
@@ -28,6 +32,7 @@ surface_mask = ["A>"]
 
 [[building]]
 id = "miner"
+tooltip = "Extracts a selected ore from the asteroid; every tile yields any ore."
 cost = 15
 player_placeable = true
 construction_time_seconds = 1
@@ -37,6 +42,7 @@ surface_mask = [
 
 [[building]]
 id = "smelter"
+tooltip = "Melts ore or scrap into basic materials. No recipe selection needed."
 cost = 20
 player_placeable = true
 construction_time_seconds = 1
@@ -47,6 +53,7 @@ surface_mask = [
 
 [[building]]
 id = "assembler"
+tooltip = "Crafts a selected recipe from the production tree into intermediate or final parts."
 cost = 35
 player_placeable = true
 construction_time_seconds = 1
@@ -57,6 +64,7 @@ surface_mask = [
 
 [[building]]
 id = "reprocessing_plant"
+tooltip = "Consumes scrap and yields one random higher-tier product per cycle."
 cost = 40
 player_placeable = true
 construction_time_seconds = 1
@@ -68,6 +76,7 @@ surface_mask = [
 
 [[building]]
 id = "shipyard"
+tooltip = "Builds autonomous combat ships from a selected schematic and module layout."
 cost = 60
 player_placeable = true
 construction_time_seconds = 1
@@ -78,10 +87,12 @@ surface_mask = [
 
 [[building]]
 id = "salvage_bay"
+tooltip = "Drop-off point where salvage ships unload collected scrap onto belts."
 cost = 25
 player_placeable = true
 construction_time_seconds = 1
+output_buffer_capacity = 20
 surface_mask = [
-  "SAA",
-  "SAA>",
+  "<AAS",
+  " AAS",
 ]

bin/app/data/config/modules.toml

@@ -1,21 +1,28 @@
 # modules.toml
 #
-# First real-content iteration: module ids and surface masks are the designed
-# content; stats, materials, and threat costs are placeholders until the
-# recipe and balancing passes.
+# Production tree v2: all weapons are railguns for now — the implementation
+# (instant damage, no projectile, no ammunition) stays as-is and the beam
+# visual reads as a tracer round. Lasers are reserved for a future distinct
+# weapon type (see docs/content_design.md, "Production tree v2 — Weapons").
+# Combat stats are placeholders until the arena balancing pass;
+# production_time_seconds values come from the numbers pass.
+#
+# Unlock gating is defined in unlocks.toml, not here (REQ-LOCK-EXPLICIT): a
+# module id granted by an unlock group starts locked and is awarded via a
+# defence station drop; ids absent from unlocks.toml (railgun_s) start unlocked.
 #
 # Surface mask footprint ladder — footprints gate which hulls can mount a
 # module, purely through geometry (see ships.toml for the matching hull
 # grids):
 #
-#   1x1       laser_cannon_s, salvager, repair_tool   fits every hull, incl. drones
+#   1x1       railgun_s, salvager, repair_tool        fits every hull, incl. drones
 #   1x2       maneuvering_thrusters, sensor_booster,
 #             armor_plates                            frigate and up
 #   1x3       afterburner                             frigate and up (eats most of a frigate)
 #   L-shape   weapon_stabilizer, weapon_primer,
 #             weapon_upgrade                          frigate and up
-#   2x2       laser_cannon_m, drone_bay               cruiser and up (no 2x2 area on s hulls)
-#   3x3       laser_cannon_l                          battleship and up (no 3x3 area on m hulls)
+#   2x2       railgun_m, drone_bay                    cruiser and up (no 2x2 area on s hulls)
+#   3x3       railgun_l                               battleship and up (no 3x3 area on m hulls)
 #   2x6       drone_hangar                            carrier only
 
 # -----------------------------------------------------------------------------
@@ -23,13 +30,13 @@
 # -----------------------------------------------------------------------------
 
 [[module]]
-id = "laser_cannon_s"
-unlock_at_station_level = -1
+id = "railgun_s"
+tooltip = "Small railgun. Fast-firing, short range, low damage; fits any hull."
 surface_mask = ["O"]
-materials = [{item = "laser_cannon_s_module", amount = 1}]
-production_time_seconds = 0.5
+materials = [{item = "railgun_s_module", amount = 1}]
+production_time_seconds = 1
 fill_color = "#FF8040"
-glyph = "Ls"
+glyph = "Rs"
 
 [module.weapon]
 damage = 2
@@ -38,36 +45,36 @@ attack_rate_hz = 2.0
 
 
 [[module]]
-id = "laser_cannon_m"
-unlock_at_station_level = -1
+id = "railgun_m"
+tooltip = "Medium railgun. Higher damage at longer range; needs a 2x2 slot."
 surface_mask = [
     "OO",
     "OO"]
-materials = [{item = "laser_cannon_m_module", amount = 1}]
-production_time_seconds = 2
+materials = [{item = "railgun_m_module", amount = 1}]
+production_time_seconds = 3
 fill_color = "#FF8040"
-glyph = "Lm"
+glyph = "Rm"
 
 [module.weapon]
-damage = 10
+damage = 14
 attack_range_m = 70
 attack_rate_hz = 1.5
 
 
 [[module]]
-id = "laser_cannon_l"
-unlock_at_station_level = -1
+id = "railgun_l"
+tooltip = "Large railgun. Heavy damage at long range; needs a 3x3 slot."
 surface_mask = [
     "OOO",
     "OOO",
     "OOO"]
-materials = [{item = "laser_cannon_l_module", amount = 1}]
-production_time_seconds = 8
+materials = [{item = "railgun_l_module", amount = 1}]
+production_time_seconds = 4
 fill_color = "#FF8040"
-glyph = "Ll"
+glyph = "Rl"
 
 [module.weapon]
-damage = 40
+damage = 52
 attack_range_m = 100
 attack_rate_hz = 0.8
 
@@ -77,31 +84,31 @@ attack_rate_hz = 0.8
 
 [[module]]
 id = "salvager"
-unlock_at_station_level = -1
+tooltip = "Collects scrap from wrecks and stores it in the ship's cargo hold."
 surface_mask = ["O"]
 materials = [{item = "salvager_module", amount = 1}]
-production_time_seconds = 2
+production_time_seconds = 1
 fill_color = "#AACC44"
 glyph = "Sv"
 
 [module.salvage]
-collection_range_m = 500
-cargo_capacity = 10
+collection_range_m = 60
+cargo_capacity = 20
 collection_rate_hz = 0.5
 
 
 [[module]]
 id = "repair_tool"
-unlock_at_station_level = -1
+tooltip = "Repairs damaged friendly ships and defence stations within range."
 surface_mask = ["O"]
 materials = [{item = "repair_tool_module", amount = 1}]
-production_time_seconds = 2
+production_time_seconds = 1
 fill_color = "#66CCFF"
 glyph = "Rp"
 
 [module.repair]
 repair_rate_hz = 1
-repair_amount_hp = 6
+repair_amount_hp = 4
 repair_range_m = 80
 
 # -----------------------------------------------------------------------------
@@ -110,10 +117,10 @@ repair_range_m = 80
 
 [[module]]
 id = "afterburner"
-unlock_at_station_level = -1
+tooltip = "Greatly boosts top speed and forward acceleration."
 surface_mask = ["OOO"]
 materials = [{item = "afterburner_module", amount = 1}]
-production_time_seconds = 2
+production_time_seconds = 1
 fill_color = "#40A0FF"
 glyph = "Ab"
 
@@ -124,10 +131,10 @@ added_main_acceleration_mpss = 60
 
 [[module]]
 id = "maneuvering_thrusters"
-unlock_at_station_level = -1
+tooltip = "Improves top speed and lateral/braking acceleration."
 surface_mask = ["OO"]
 materials = [{item = "maneuvering_thrusters_module", amount = 1}]
-production_time_seconds = 2
+production_time_seconds = 1
 fill_color = "#40A0FF"
 glyph = "Mt"
 
@@ -141,23 +148,23 @@ added_maneuvering_acceleration_mpss = 10
 
 [[module]]
 id = "armor_plates"
-unlock_at_station_level = -1
+tooltip = "Adds a large flat bonus to the ship's hit points."
 surface_mask = ["OO"]
 materials = [{item = "armor_plates_module", amount = 1}]
-production_time_seconds = 3
+production_time_seconds = 1
 fill_color = "#808080"
 glyph = "A"
 
 [module.health]
-added_hp = 40
+added_hp = 1200
 
 
 [[module]]
 id = "sensor_booster"
-unlock_at_station_level = -1
+tooltip = "Extends the ship's sensor range."
 surface_mask = ["OO"]
 materials = [{item = "sensor_booster_module", amount = 1}]
-production_time_seconds = 2
+production_time_seconds = 1
 fill_color = "#40A0FF"
 glyph = "S"
 
@@ -170,13 +177,13 @@ added_sensor_range_m = 50
 
 [[module]]
 id = "weapon_upgrade"
-unlock_at_station_level = -1
+tooltip = "Increases the damage of all weapons on the ship."
 surface_mask = [
     "OO",
     "OX",
 ]
 materials = [{item = "weapon_upgrade_module", amount = 1}]
-production_time_seconds = 4
+production_time_seconds = 2
 fill_color = "#FF4040"
 glyph = "Wu"
 
@@ -186,13 +193,13 @@ multiplied_damage = 1.2
 
 [[module]]
 id = "weapon_primer"
-unlock_at_station_level = -1
+tooltip = "Increases the fire rate of all weapons on the ship."
 surface_mask = [
     "OO",
     "OX",
 ]
 materials = [{item = "weapon_primer_module", amount = 1}]
-production_time_seconds = 4
+production_time_seconds = 2
 fill_color = "#FF4040"
 glyph = "Wp"
 
@@ -202,18 +209,18 @@ multiplied_attack_rate_hz = 1.2
 
 [[module]]
 id = "weapon_stabilizer"
-unlock_at_station_level = -1
+tooltip = "Extends weapon range at the cost of some fire rate."
 surface_mask = [
     "OO",
     "OX",
 ]
 materials = [{item = "weapon_stabilizer_module", amount = 1}]
-production_time_seconds = 4
+production_time_seconds = 1
 fill_color = "#FF4040"
 glyph = "Ws"
 
 [module.weapon]
-multiplied_attack_range_m = 1.5
+multiplied_attack_range_m = 1.3
 multiplied_attack_rate_hz = 0.8
 
 # -----------------------------------------------------------------------------
@@ -225,23 +232,23 @@ multiplied_attack_rate_hz = 0.8
 
 [[module]]
 id = "drone_bay"
-unlock_at_station_level = -1
+tooltip = "Drone launch bay (capability not yet implemented)."
 surface_mask = [
     "OO",
     "OO"]
 materials = [{item = "drone_bay_module", amount = 1}]
-production_time_seconds = 5
+production_time_seconds = 3
 fill_color = "#CC66FF"
 glyph = "Db"
 
 
 [[module]]
 id = "drone_hangar"
-unlock_at_station_level = -1
+tooltip = "Large drone hangar (capability not yet implemented)."
 surface_mask = [
     "OOOOOO",
     "OOOOOO"]
 materials = [{item = "drone_hangar_module", amount = 1}]
-production_time_seconds = 20
+production_time_seconds = 6
 fill_color = "#9933CC"
 glyph = "Dh"

bin/app/data/config/recipes.toml

@@ -1,439 +1,448 @@
 # recipes.toml
 #
-# First real-content iteration of the production tree. Quantities and
-# durations are a first guess; the balancing pass will tune them and assign
-# real unlock_at_station_level values (everything is unlocked for now so the
-# full tree is testable).
+# Production tree v2 (structure in docs/content_design.md, numbers with
+# derivations in docs/balancing/derived.md). Quantities and durations are tuned so that every
+# fitted ship lands on the threat-cost ladder and the ratio curve is
+# realized: tier 1 ratios are 1:1, tier 2 ratios are 2:3, tier 3+ ratios
+# are deliberately strange.
 #
-# Input chain per game phase — each phase adds exactly one new base input:
+# A recipe id names the process, not the product — the display name shown in
+# the UI is derived from it — so an item and the recipe that makes it never
+# carry the same name.
 #
-#   early  iron_ore + copper_ore   -> ingots -> copper_wire, steel_plate,
-#                                    circuit_board
-#   mid    + titanium_ore          -> titanium_frame; assembler-made
-#                                    mechanical_parts, targeting_unit,
-#                                    drive_unit
-#   late   + advanced_alloy        -> reinforced_plating, capital_core.
-#                                    advanced_alloy CANNOT be mined; it only
-#                                    comes from reprocessing salvaged scrap,
-#                                    so capital production requires combat.
+# Input chain per game phase — each phase transition adds exactly one new
+# base input:
 #
-# Run tools/verify_recipes.py after editing to check that every consumed
-# item has a producer and every item has a visuals.toml entry.
+#   early  iron_ore + copper_ore    minable on every asteroid tile (the
+#                                   asteroid is an M-type body — its bulk
+#                                   rock IS ore)
+#   mid    + quartz                 geode deposits in expansion territory
+#                                   (deposit gating pending — see action
+#                                   item 5 in docs/balancing/README.md;
+#                                   until then quartz mines anywhere)
+#   late   + voidsteel              battle-forged: ONLY from reprocessing
+#                                   salvaged scrap, so capital production
+#                                   requires combat
+#
+# Run tools/verify_recipes.py and tools/threat_report.py after editing.
 
 # -----------------------------------------------------------------------------
 # Mining (tier 0)
 # -----------------------------------------------------------------------------
 
 [[recipe]]
-id = "mine_iron_ore"
+id = "iron_mining"
 building = "miner"
 inputs = []
 outputs = [{item = "iron_ore", amount = 1}]
 duration_seconds = 1.0
 
 [[recipe]]
-id = "mine_copper_ore"
+id = "copper_mining"
 building = "miner"
 inputs = []
 outputs = [{item = "copper_ore", amount = 1}]
-duration_seconds = 1.5
+duration_seconds = 1.0
 
-# Titanium is the midgame ore: mined three times slower than iron.
 [[recipe]]
-id = "mine_titanium_ore"
+id = "quartz_mining"
 building = "miner"
 inputs = []
-outputs = [{item = "titanium_ore", amount = 1}]
-duration_seconds = 3.0
-
-# -----------------------------------------------------------------------------
-# Smelting (tier 1)
-# -----------------------------------------------------------------------------
-
-[[recipe]]
-id = "iron_ingot"
-building = "smelter"
-inputs = [{item = "iron_ore", amount = 2}]
-outputs = [{item = "iron_ingot", amount = 1}]
+outputs = [{item = "quartz", amount = 1}]
 duration_seconds = 2.0
 
+# -----------------------------------------------------------------------------
+# Smelting (tier 1) — one recipe per input item; ratios are 1:1 with miners.
+# -----------------------------------------------------------------------------
+
 [[recipe]]
-id = "copper_ingot"
+id = "iron_smelting"
 building = "smelter"
-inputs = [{item = "copper_ore", amount = 2}]
+inputs = [{item = "iron_ore", amount = 1}]
+outputs = [{item = "iron_ingot", amount = 1}]
+duration_seconds = 1.0
+
+[[recipe]]
+id = "copper_smelting"
+building = "smelter"
+inputs = [{item = "copper_ore", amount = 1}]
 outputs = [{item = "copper_ingot", amount = 1}]
-duration_seconds = 2.5
+duration_seconds = 1.0
 
 [[recipe]]
-id = "titanium_ingot"
+id = "quartz_reduction"
 building = "smelter"
-inputs = [{item = "titanium_ore", amount = 3}]
-outputs = [{item = "titanium_ingot", amount = 1}]
-duration_seconds = 4.0
+inputs = [{item = "quartz", amount = 1}]
+outputs = [{item = "silicon", amount = 1}]
+duration_seconds = 2.0
+
+# Scrap smelting: the safe, boring sink. Deliberately value-losing (4 threat
+# of scrap becomes a 2-threat ingot) — reprocessing is the value-preserving
+# path.
+[[recipe]]
+id = "scrap_smelting"
+building = "smelter"
+inputs = [{item = "scrap", amount = 1}]
+outputs = [{item = "iron_ingot", amount = 1}]
+duration_seconds = 1.0
 
 # -----------------------------------------------------------------------------
-# Reprocessing
-#
-# The only source of advanced_alloy: salvaged scrap from destroyed ships.
+# Reprocessing — the only source of voidsteel (battle-forged; formed when
+# weapon plasma anneals hull metal in the violence of ship destruction).
+# Weights are authored for the fully unlocked pool state; the pool
+# renormalizes over implicitly unlocked items early game.
 # -----------------------------------------------------------------------------
 
 [[recipe]]
-id = "reprocessing_cycle"
+id = "scrap_reprocessing"
 building = "reprocessing_plant"
-inputs = [{item = "scrap", amount = 5}]
-duration_seconds = 3.0
+inputs = [{item = "scrap", amount = 4}]
+duration_seconds = 4.0
 
   [[recipe.outputs]]
   item = "iron_ingot"
-  amount = 2
-  probability = 0.45
+  amount = 1
+  probability = 0.3
 
   [[recipe.outputs]]
   item = "copper_ingot"
   amount = 1
-  probability = 0.25
+  probability = 0.3
 
   [[recipe.outputs]]
-  item = "titanium_ingot"
+  item = "silicon"
   amount = 1
-  probability = 0.15
+  probability = 0.2
 
   [[recipe.outputs]]
-  item = "advanced_alloy"
+  item = "voidsteel"
   amount = 1
-  probability = 0.15
+  probability = 0.2
 
 # -----------------------------------------------------------------------------
-# Basic components (tier 2, early game)
+# Tier 2 — early intermediates (clean ratios, ~2:3)
 # -----------------------------------------------------------------------------
 
 [[recipe]]
-id = "copper_wire"
-unlock_at_station_level = -1
+id = "steel_rolling"
+building = "assembler"
+inputs = [{item = "iron_ingot", amount = 2}]
+outputs = [{item = "steel_plate", amount = 1}]
+duration_seconds = 3.0
+
+[[recipe]]
+id = "wire_drawing"
 building = "assembler"
 inputs = [{item = "copper_ingot", amount = 1}]
 outputs = [{item = "copper_wire", amount = 2}]
-duration_seconds = 1.5
+duration_seconds = 1.0
 
 [[recipe]]
-id = "steel_plate"
-unlock_at_station_level = -1
+id = "coil_winding"
 building = "assembler"
-inputs = [{item = "iron_ingot", amount = 2}]
+inputs = [{item = "copper_wire", amount = 2}]
+outputs = [{item = "copper_coil", amount = 1}]
+duration_seconds = 1.5
+
+# Depth-3 chain (ore -> ingot -> plate -> block) is the factory's
+# doubling-time knob; see the block economy rules in docs/balancing/rules.md.
+# unlocked_at_start: building blocks appear in no schematic's materials, so the
+# implicit item graph can never reach this recipe (REQ-LOCK-IMPLICIT).
+[[recipe]]
+id = "block_pressing"
+building = "assembler"
+unlocked_at_start = true
+inputs = [{item = "steel_plate", amount = 2}]
+outputs = [{item = "building_block", amount = 4}]
+duration_seconds = 2.0
+
+# -----------------------------------------------------------------------------
+# Tier 3 — mid intermediates (strange ratios begin; need quartz)
+# -----------------------------------------------------------------------------
+
+[[recipe]]
+id = "chip_etching"
+building = "assembler"
+inputs = [{item = "silicon", amount = 1}, {item = "copper_wire", amount = 2}]
+outputs = [{item = "control_chip", amount = 1}]
+duration_seconds = 5.0
+
+[[recipe]]
+id = "capacitor_assembly"
+building = "assembler"
+inputs = [{item = "copper_coil", amount = 2}, {item = "silicon", amount = 1}]
+outputs = [{item = "capacitor_bank", amount = 1}]
+duration_seconds = 5.0
+
+# The quality gate for m+ hulls: a deliberately long-running recipe
+# (time-heavy archetype).
+[[recipe]]
+id = "steel_hardening"
+building = "assembler"
+inputs = [{item = "steel_plate", amount = 3}]
+outputs = [{item = "hardened_steel", amount = 1}]
+duration_seconds = 12.0
+
+[[recipe]]
+id = "ceramic_firing"
+building = "assembler"
+inputs = [{item = "quartz", amount = 2}]
+outputs = [{item = "ceramic_plate", amount = 1}]
+duration_seconds = 4.0
+
+[[recipe]]
+id = "drive_assembly"
+building = "assembler"
+inputs = [
+    {item = "steel_plate", amount = 2},
+    {item = "copper_coil", amount = 2},
+    {item = "control_chip", amount = 1},
+]
+outputs = [{item = "drive_unit", amount = 1}]
+duration_seconds = 8.0
+
+# -----------------------------------------------------------------------------
+# Tier 4 — late intermediates (need voidsteel)
+# -----------------------------------------------------------------------------
+
+[[recipe]]
+id = "voidsteel_forging"
+building = "assembler"
+inputs = [{item = "voidsteel", amount = 1}, {item = "hardened_steel", amount = 1}]
+outputs = [{item = "voidsteel_plate", amount = 1}]
+duration_seconds = 8.0
+
+[[recipe]]
+id = "core_assembly"
+building = "assembler"
+inputs = [
+    {item = "voidsteel", amount = 2},
+    {item = "capacitor_bank", amount = 1},
+    {item = "control_chip", amount = 1},
+]
+outputs = [{item = "capital_core", amount = 1}]
+duration_seconds = 10.0
+
+# -----------------------------------------------------------------------------
+# Shortcut recipes — drop-only assembler recipes, gated by unlock groups in
+# unlocks.toml (REQ-LOCK-EXPLICIT). Pure rewards: item threat stays defined by
+# the base (expensive) path via the max rule, so shortcuts give real factory
+# efficiency without shifting any balance. Named "direct_*" after the base
+# process they skip a step of, so the reward reads as what it is.
+# -----------------------------------------------------------------------------
+
+[[recipe]]
+id = "direct_rolling"
+building = "assembler"
+inputs = [{item = "iron_ore", amount = 3}]
 outputs = [{item = "steel_plate", amount = 1}]
 duration_seconds = 2.0
 
 [[recipe]]
-id = "circuit_board"
-unlock_at_station_level = -1
+id = "direct_etching"
 building = "assembler"
-inputs = [{item = "iron_ingot", amount = 1}, {item = "copper_wire", amount = 2}]
-outputs = [{item = "circuit_board", amount = 1}]
-duration_seconds = 2.0
+inputs = [{item = "quartz", amount = 2}]
+outputs = [{item = "control_chip", amount = 1}]
+duration_seconds = 4.0
 
 [[recipe]]
-id = "building_blocks"
-unlock_at_station_level = -1
+id = "direct_hardening"
 building = "assembler"
 inputs = [{item = "iron_ingot", amount = 4}]
-outputs = [{item = "building_block", amount = 10}]
-duration_seconds = 4.0
-
-# -----------------------------------------------------------------------------
-# Advanced components (tier 3, midgame)
-# -----------------------------------------------------------------------------
-
-[[recipe]]
-id = "mechanical_parts"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "steel_plate", amount = 1}, {item = "iron_ingot", amount = 1}]
-outputs = [{item = "mechanical_parts", amount = 2}]
-duration_seconds = 2.5
-
-[[recipe]]
-id = "targeting_unit"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "circuit_board", amount = 2}, {item = "copper_wire", amount = 1}]
-outputs = [{item = "targeting_unit", amount = 1}]
-duration_seconds = 3.0
-
-[[recipe]]
-id = "drive_unit"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [
-    {item = "steel_plate", amount = 1},
-    {item = "mechanical_parts", amount = 1},
-    {item = "circuit_board", amount = 1},
-]
-outputs = [{item = "drive_unit", amount = 1}]
-duration_seconds = 4.0
-
-[[recipe]]
-id = "titanium_frame"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "titanium_ingot", amount = 2}, {item = "steel_plate", amount = 1}]
-outputs = [{item = "titanium_frame", amount = 1}]
-duration_seconds = 4.0
-
-# -----------------------------------------------------------------------------
-# Capital components (tier 4, lategame — gated on advanced_alloy)
-# -----------------------------------------------------------------------------
-
-[[recipe]]
-id = "reinforced_plating"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "steel_plate", amount = 2}, {item = "advanced_alloy", amount = 1}]
-outputs = [{item = "reinforced_plating", amount = 1}]
-duration_seconds = 5.0
-
-[[recipe]]
-id = "capital_core"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [
-    {item = "targeting_unit", amount = 1},
-    {item = "drive_unit", amount = 1},
-    {item = "advanced_alloy", amount = 2},
-]
-outputs = [{item = "capital_core", amount = 1}]
+outputs = [{item = "hardened_steel", amount = 1}]
 duration_seconds = 8.0
 
-# -----------------------------------------------------------------------------
-# Module items — early game
-# -----------------------------------------------------------------------------
-
-[[recipe]]
-id = "laser_cannon_s_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "iron_ingot", amount = 2}, {item = "circuit_board", amount = 1}]
-outputs = [{item = "laser_cannon_s_module", amount = 1}]
-duration_seconds = 3.0
-
-[[recipe]]
-id = "salvager_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "steel_plate", amount = 1}, {item = "circuit_board", amount = 1}]
-outputs = [{item = "salvager_module", amount = 1}]
-duration_seconds = 4.0
-
-[[recipe]]
-id = "repair_tool_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "circuit_board", amount = 2}, {item = "copper_wire", amount = 1}]
-outputs = [{item = "repair_tool_module", amount = 1}]
-duration_seconds = 4.0
-
-[[recipe]]
-id = "armor_plates_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "steel_plate", amount = 2}]
-outputs = [{item = "armor_plates_module", amount = 1}]
-duration_seconds = 3.0
-
-[[recipe]]
-id = "sensor_booster_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "circuit_board", amount = 1}, {item = "copper_wire", amount = 2}]
-outputs = [{item = "sensor_booster_module", amount = 1}]
-duration_seconds = 3.0
-
-[[recipe]]
-id = "maneuvering_thrusters_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "mechanical_parts", amount = 1}, {item = "copper_wire", amount = 1}]
-outputs = [{item = "maneuvering_thrusters_module", amount = 1}]
-duration_seconds = 3.0
-
-# -----------------------------------------------------------------------------
-# Module items — midgame
-# -----------------------------------------------------------------------------
-
-[[recipe]]
-id = "afterburner_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "drive_unit", amount = 1}, {item = "steel_plate", amount = 1}]
-outputs = [{item = "afterburner_module", amount = 1}]
-duration_seconds = 4.0
-
-[[recipe]]
-id = "weapon_upgrade_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "targeting_unit", amount = 1}, {item = "steel_plate", amount = 1}]
-outputs = [{item = "weapon_upgrade_module", amount = 1}]
-duration_seconds = 4.0
-
-[[recipe]]
-id = "weapon_primer_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "targeting_unit", amount = 1}, {item = "copper_wire", amount = 2}]
-outputs = [{item = "weapon_primer_module", amount = 1}]
-duration_seconds = 4.0
-
-[[recipe]]
-id = "weapon_stabilizer_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "targeting_unit", amount = 1}, {item = "mechanical_parts", amount = 1}]
-outputs = [{item = "weapon_stabilizer_module", amount = 1}]
-duration_seconds = 4.0
-
-[[recipe]]
-id = "laser_cannon_m_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [{item = "targeting_unit", amount = 1}, {item = "titanium_frame", amount = 1}]
-outputs = [{item = "laser_cannon_m_module", amount = 1}]
-duration_seconds = 6.0
-
-[[recipe]]
-id = "drone_bay_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [
-    {item = "titanium_frame", amount = 1},
-    {item = "mechanical_parts", amount = 1},
-    {item = "circuit_board", amount = 1},
-]
-outputs = [{item = "drone_bay_module", amount = 1}]
-duration_seconds = 6.0
-
-# -----------------------------------------------------------------------------
-# Module items — lategame
-# -----------------------------------------------------------------------------
-
-[[recipe]]
-id = "laser_cannon_l_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [
-    {item = "targeting_unit", amount = 2},
-    {item = "reinforced_plating", amount = 2},
-    {item = "titanium_frame", amount = 1},
-]
-outputs = [{item = "laser_cannon_l_module", amount = 1}]
-duration_seconds = 12.0
-
-[[recipe]]
-id = "drone_hangar_module"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [
-    {item = "capital_core", amount = 1},
-    {item = "titanium_frame", amount = 2},
-    {item = "reinforced_plating", amount = 2},
-]
-outputs = [{item = "drone_hangar_module", amount = 1}]
-duration_seconds = 20.0
-
 # -----------------------------------------------------------------------------
 # Ship hulls
 # -----------------------------------------------------------------------------
 
 [[recipe]]
-id = "drone_hull"
-unlock_at_station_level = -1
+id = "drone_framing"
 building = "assembler"
-inputs = [{item = "iron_ingot", amount = 5}, {item = "circuit_board", amount = 1}]
+inputs = [{item = "iron_ingot", amount = 1}]
 outputs = [{item = "drone_hull", amount = 1}]
+duration_seconds = 1.0
+
+[[recipe]]
+id = "frigate_framing"
+building = "assembler"
+inputs = [{item = "steel_plate", amount = 2}, {item = "copper_wire", amount = 1}]
+outputs = [{item = "frigate_hull", amount = 1}]
+duration_seconds = 2.0
+
+[[recipe]]
+id = "destroyer_framing"
+building = "assembler"
+inputs = [{item = "steel_plate", amount = 3}, {item = "copper_coil", amount = 2}]
+outputs = [{item = "destroyer_hull", amount = 1}]
 duration_seconds = 4.0
 
 [[recipe]]
-id = "frigate_hull"
-unlock_at_station_level = -1
+id = "cruiser_framing"
+building = "assembler"
+inputs = [{item = "hardened_steel", amount = 2}, {item = "control_chip", amount = 2}]
+outputs = [{item = "cruiser_hull", amount = 1}]
+duration_seconds = 6.0
+
+[[recipe]]
+id = "battlecruiser_framing"
 building = "assembler"
 inputs = [
-    {item = "steel_plate", amount = 3},
-    {item = "mechanical_parts", amount = 1},
-    {item = "circuit_board", amount = 1},
+    {item = "hardened_steel", amount = 3},
+    {item = "control_chip", amount = 2},
+    {item = "drive_unit", amount = 1},
 ]
-outputs = [{item = "frigate_hull", amount = 1}]
+outputs = [{item = "battlecruiser_hull", amount = 1}]
 duration_seconds = 8.0
 
 [[recipe]]
-id = "destroyer_hull"
-unlock_at_station_level = -1
+id = "battleship_framing"
 building = "assembler"
 inputs = [
-    {item = "steel_plate", amount = 5},
-    {item = "mechanical_parts", amount = 2},
-    {item = "circuit_board", amount = 1},
+    {item = "voidsteel_plate", amount = 3},
+    {item = "drive_unit", amount = 1},
+    {item = "control_chip", amount = 2},
 ]
-outputs = [{item = "destroyer_hull", amount = 1}]
+outputs = [{item = "battleship_hull", amount = 1}]
 duration_seconds = 10.0
 
 [[recipe]]
-id = "cruiser_hull"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [
-    {item = "titanium_frame", amount = 2},
-    {item = "steel_plate", amount = 4},
-    {item = "drive_unit", amount = 1},
-]
-outputs = [{item = "cruiser_hull", amount = 1}]
-duration_seconds = 15.0
-
-[[recipe]]
-id = "battlecruiser_hull"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [
-    {item = "titanium_frame", amount = 3},
-    {item = "steel_plate", amount = 6},
-    {item = "drive_unit", amount = 1},
-    {item = "targeting_unit", amount = 1},
-]
-outputs = [{item = "battlecruiser_hull", amount = 1}]
-duration_seconds = 20.0
-
-[[recipe]]
-id = "battleship_hull"
-unlock_at_station_level = -1
-building = "assembler"
-inputs = [
-    {item = "titanium_frame", amount = 4},
-    {item = "reinforced_plating", amount = 2},
-    {item = "drive_unit", amount = 2},
-]
-outputs = [{item = "battleship_hull", amount = 1}]
-duration_seconds = 30.0
-
-[[recipe]]
-id = "dreadnought_hull"
-unlock_at_station_level = -1
+id = "dreadnought_framing"
 building = "assembler"
 inputs = [
+    {item = "voidsteel_plate", amount = 5},
     {item = "capital_core", amount = 1},
-    {item = "titanium_frame", amount = 6},
-    {item = "reinforced_plating", amount = 4},
     {item = "drive_unit", amount = 2},
 ]
 outputs = [{item = "dreadnought_hull", amount = 1}]
-duration_seconds = 60.0
+duration_seconds = 12.0
 
 [[recipe]]
-id = "carrier_hull"
-unlock_at_station_level = -1
+id = "carrier_framing"
 building = "assembler"
 inputs = [
+    {item = "voidsteel_plate", amount = 5},
     {item = "capital_core", amount = 1},
-    {item = "titanium_frame", amount = 5},
-    {item = "reinforced_plating", amount = 3},
     {item = "drive_unit", amount = 2},
 ]
 outputs = [{item = "carrier_hull", amount = 1}]
-duration_seconds = 60.0
+duration_seconds = 12.0
+
+# -----------------------------------------------------------------------------
+# Module prefabs
+# -----------------------------------------------------------------------------
+
+[[recipe]]
+id = "railgun_s_kit"
+building = "assembler"
+inputs = [{item = "copper_coil", amount = 1}]
+outputs = [{item = "railgun_s_module", amount = 1}]
+duration_seconds = 1.0
+
+[[recipe]]
+id = "salvager_kit"
+building = "assembler"
+inputs = [{item = "steel_plate", amount = 1}, {item = "copper_wire", amount = 2}]
+outputs = [{item = "salvager_module", amount = 1}]
+duration_seconds = 2.0
+
+[[recipe]]
+id = "repair_tool_kit"
+building = "assembler"
+inputs = [{item = "steel_plate", amount = 1}, {item = "copper_wire", amount = 2}]
+outputs = [{item = "repair_tool_module", amount = 1}]
+duration_seconds = 2.0
+
+# Material-heavy, fast: the armor archetype.
+[[recipe]]
+id = "armor_plates_kit"
+building = "assembler"
+inputs = [{item = "steel_plate", amount = 4}]
+outputs = [{item = "armor_plates_module", amount = 1}]
+duration_seconds = 3.0
+
+[[recipe]]
+id = "maneuvering_thrusters_kit"
+building = "assembler"
+inputs = [{item = "steel_plate", amount = 1}, {item = "copper_coil", amount = 1}]
+outputs = [{item = "maneuvering_thrusters_module", amount = 1}]
+duration_seconds = 2.0
+
+[[recipe]]
+id = "sensor_booster_kit"
+building = "assembler"
+inputs = [{item = "copper_wire", amount = 2}, {item = "copper_coil", amount = 1}]
+outputs = [{item = "sensor_booster_module", amount = 1}]
+duration_seconds = 2.0
+
+[[recipe]]
+id = "afterburner_kit"
+building = "assembler"
+inputs = [{item = "copper_coil", amount = 2}, {item = "steel_plate", amount = 1}]
+outputs = [{item = "afterburner_module", amount = 1}]
+duration_seconds = 3.0
+
+[[recipe]]
+id = "weapon_stabilizer_kit"
+building = "assembler"
+inputs = [{item = "steel_plate", amount = 1}, {item = "copper_coil", amount = 1}]
+outputs = [{item = "weapon_stabilizer_module", amount = 1}]
+duration_seconds = 2.0
+
+[[recipe]]
+id = "weapon_primer_kit"
+building = "assembler"
+inputs = [{item = "capacitor_bank", amount = 1}, {item = "copper_coil", amount = 1}]
+outputs = [{item = "weapon_primer_module", amount = 1}]
+duration_seconds = 4.0
+
+[[recipe]]
+id = "weapon_upgrade_kit"
+building = "assembler"
+inputs = [{item = "control_chip", amount = 1}, {item = "copper_coil", amount = 1}]
+outputs = [{item = "weapon_upgrade_module", amount = 1}]
+duration_seconds = 4.0
+
+[[recipe]]
+id = "railgun_m_kit"
+building = "assembler"
+inputs = [
+    {item = "capacitor_bank", amount = 1},
+    {item = "steel_plate", amount = 2},
+    {item = "copper_coil", amount = 1},
+]
+outputs = [{item = "railgun_m_module", amount = 1}]
+duration_seconds = 4.0
+
+[[recipe]]
+id = "drone_bay_kit"
+building = "assembler"
+inputs = [
+    {item = "control_chip", amount = 1},
+    {item = "steel_plate", amount = 2},
+    {item = "copper_coil", amount = 1},
+]
+outputs = [{item = "drone_bay_module", amount = 1}]
+duration_seconds = 4.0
+
+[[recipe]]
+id = "railgun_l_kit"
+building = "assembler"
+inputs = [
+    {item = "capacitor_bank", amount = 1},
+    {item = "hardened_steel", amount = 2},
+    {item = "ceramic_plate", amount = 1},
+]
+outputs = [{item = "railgun_l_module", amount = 1}]
+duration_seconds = 6.0
+
+[[recipe]]
+id = "drone_hangar_kit"
+building = "assembler"
+inputs = [
+    {item = "voidsteel_plate", amount = 1},
+    {item = "control_chip", amount = 2},
+    {item = "drive_unit", amount = 1},
+]
+outputs = [{item = "drone_hangar_module", amount = 1}]
+duration_seconds = 10.0

bin/app/data/config/ships.toml

@@ -4,6 +4,10 @@
 # content; stats, materials, and production times are placeholders until the
 # recipe and balancing passes.
 #
+# Unlock gating is defined in unlocks.toml, not here (REQ-LOCK-EXPLICIT): a ship
+# id granted by an unlock group starts locked and is awarded via a defence
+# station drop; ids absent from unlocks.toml (drone, frigate) start unlocked.
+#
 # Size classes:
 #   xs  drone                      1 cell — exactly one 1x1 module
 #   s   frigate, destroyer         no 2x2 area anywhere: only 1x1/1x2/1x3/L modules fit
@@ -17,23 +21,22 @@
 
 [[ship]]
 id = "drone"
-unlock_at_station_level = -1
 layout = ["O"]
-default_modules = [{type = "laser_cannon_s", x = 0, y = 0, rotation = "east"}]
+default_modules = [{type = "railgun_s", x = 0, y = 0, rotation = "east"}]
 
 [ship.schematic]
-materials = [{item = "iron_ore", amount = 1}]
-production_time_seconds = 5
+materials = [{item = "drone_hull", amount = 1}]
+production_time_seconds = 1
 
 [ship.health]
-hp = 3
+hp = 60
 
 [ship.movement]
-speed_mps = 40
-main_acceleration_mpss = 2
-maneuvering_acceleration_mpss = 1
-angular_acceleration_radpss = 12.56
-max_rotation_speed_radps = 6.28
+speed_mps = 45
+main_acceleration_mpss = 60
+maneuvering_acceleration_mpss = 30
+angular_acceleration_radpss = 12
+max_rotation_speed_radps = 6
 
 [ship.sensor]
 sensor_range_m = 150
@@ -44,24 +47,28 @@ sensor_range_m = 150
 # L-shaped weapon modifier, or an afterburner spanning the full center line.
 [[ship]]
 id = "frigate"
-unlock_at_station_level = -1
 layout = [
     "XOX",
     "OOO",
     "XOX",
 ]
+default_modules = [
+    {type = "railgun_s", x = 1, y = 0, rotation = "east"},
+    {type = "railgun_s", x = 2, y = 1, rotation = "east"},
+    {type = "maneuvering_thrusters", x = 0, y = 1, rotation = "east"},
+]
 
 [ship.schematic]
 materials = [{item = "frigate_hull", amount = 1}]
-production_time_seconds = 10
+production_time_seconds = 2
 
 [ship.health]
-hp = 30
+hp = 300
 
 [ship.movement]
-speed_mps = 30
-main_acceleration_mpss = 50
-maneuvering_acceleration_mpss = 25
+speed_mps = 35
+main_acceleration_mpss = 45
+maneuvering_acceleration_mpss = 22
 angular_acceleration_radpss = 8
 max_rotation_speed_radps = 4
 
@@ -74,23 +81,29 @@ sensor_range_m = 200
 # mount medium hardware.
 [[ship]]
 id = "destroyer"
-unlock_at_station_level = -1
 layout = [
     "OXOXO",
     "OOOOO",
 ]
+default_modules = [
+    {type = "railgun_s", x = 0, y = 0, rotation = "east"},
+    {type = "railgun_s", x = 2, y = 0, rotation = "east"},
+    {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+    {type = "armor_plates", x = 0, y = 1, rotation = "east"},
+    {type = "sensor_booster", x = 3, y = 1, rotation = "east"},
+]
 
 [ship.schematic]
 materials = [{item = "destroyer_hull", amount = 1}]
-production_time_seconds = 15
+production_time_seconds = 3
 
 [ship.health]
-hp = 50
+hp = 550
 
 [ship.movement]
-speed_mps = 25
-main_acceleration_mpss = 40
-maneuvering_acceleration_mpss = 20
+speed_mps = 30
+main_acceleration_mpss = 35
+maneuvering_acceleration_mpss = 18
 angular_acceleration_radpss = 6
 max_rotation_speed_radps = 3
 
@@ -103,25 +116,30 @@ sensor_range_m = 220
 # supports; no 3x3 area exists for an l gun.
 [[ship]]
 id = "cruiser"
-unlock_at_station_level = -1
 layout = [
     "XOOX",
     "OOOO",
     "OOOO",
     "XOOX",
 ]
+default_modules = [
+    {type = "railgun_m", x = 0, y = 1, rotation = "east"},
+    {type = "railgun_m", x = 2, y = 1, rotation = "east"},
+    {type = "armor_plates", x = 1, y = 0, rotation = "east"},
+    {type = "maneuvering_thrusters", x = 1, y = 3, rotation = "east"},
+]
 
 [ship.schematic]
 materials = [{item = "cruiser_hull", amount = 1}]
-production_time_seconds = 25
+production_time_seconds = 4
 
 [ship.health]
-hp = 120
+hp = 1500
 
 [ship.movement]
-speed_mps = 20
-main_acceleration_mpss = 30
-maneuvering_acceleration_mpss = 15
+speed_mps = 24
+main_acceleration_mpss = 25
+maneuvering_acceleration_mpss = 12
 angular_acceleration_radpss = 4
 max_rotation_speed_radps = 2
 
@@ -135,25 +153,32 @@ sensor_range_m = 250
 # stern leave no 3x3 area for an l gun and no 2x6 area for a drone hangar.
 [[ship]]
 id = "battlecruiser"
-unlock_at_station_level = -1
 layout = [
     "OOXXOO",
     "OOOOOO",
     "XOOOOX",
     "XXOOXX",
 ]
+default_modules = [
+    {type = "railgun_m", x = 0, y = 0, rotation = "east"},
+    {type = "railgun_m", x = 4, y = 0, rotation = "east"},
+    {type = "railgun_m", x = 2, y = 1, rotation = "east"},
+    {type = "armor_plates", x = 2, y = 3, rotation = "east"},
+    {type = "railgun_s", x = 1, y = 2, rotation = "east"},
+    {type = "railgun_s", x = 4, y = 2, rotation = "east"},
+]
 
 [ship.schematic]
 materials = [{item = "battlecruiser_hull", amount = 1}]
-production_time_seconds = 35
+production_time_seconds = 5
 
 [ship.health]
-hp = 180
+hp = 2400
 
 [ship.movement]
-speed_mps = 18
-main_acceleration_mpss = 25
-maneuvering_acceleration_mpss = 12
+speed_mps = 20
+main_acceleration_mpss = 20
+maneuvering_acceleration_mpss = 10
 angular_acceleration_radpss = 3
 max_rotation_speed_radps = 1.5
 
@@ -169,7 +194,6 @@ sensor_range_m = 260
 # so no 2x6 drone hangar fits.
 [[ship]]
 id = "battleship"
-unlock_at_station_level = -1
 layout = [
     "XOOOOX",
     "OOOOOO",
@@ -177,18 +201,26 @@ layout = [
     "OOOOOO",
     "XOOOOX",
 ]
+default_modules = [
+    {type = "railgun_l", x = 1, y = 0, rotation = "east"},
+    {type = "railgun_m", x = 1, y = 3, rotation = "east"},
+    {type = "railgun_m", x = 3, y = 3, rotation = "east"},
+    {type = "weapon_stabilizer", x = 4, y = 1, rotation = "east"},
+    {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+    {type = "railgun_s", x = 0, y = 1, rotation = "east"},
+]
 
 [ship.schematic]
 materials = [{item = "battleship_hull", amount = 1}]
-production_time_seconds = 60
+production_time_seconds = 6
 
 [ship.health]
-hp = 350
+hp = 6300
 
 [ship.movement]
-speed_mps = 14
-main_acceleration_mpss = 18
-maneuvering_acceleration_mpss = 8
+speed_mps = 15
+main_acceleration_mpss = 14
+maneuvering_acceleration_mpss = 7
 angular_acceleration_radpss = 2
 max_rotation_speed_radps = 1
 
@@ -203,7 +235,6 @@ sensor_range_m = 280
 # stay the only hangar hull. Bow and stern strips hold supports.
 [[ship]]
 id = "dreadnought"
-unlock_at_station_level = -1
 layout = [
     "XXXOOOOOXXX",
     "OOOXOOOXOOO",
@@ -211,18 +242,28 @@ layout = [
     "OOOXOOOXOOO",
     "XXOOXXXOOXX",
 ]
+default_modules = [
+    {type = "railgun_l", x = 0, y = 1, rotation = "east"},
+    {type = "railgun_l", x = 4, y = 1, rotation = "east"},
+    {type = "railgun_l", x = 8, y = 1, rotation = "east"},
+    {type = "armor_plates", x = 3, y = 0, rotation = "east"},
+    {type = "armor_plates", x = 5, y = 0, rotation = "east"},
+    {type = "armor_plates", x = 2, y = 4, rotation = "east"},
+    {type = "armor_plates", x = 7, y = 4, rotation = "east"},
+    {type = "railgun_s", x = 7, y = 0, rotation = "east"},
+]
 
 [ship.schematic]
 materials = [{item = "dreadnought_hull", amount = 1}]
-production_time_seconds = 120
+production_time_seconds = 8
 
 [ship.health]
-hp = 800
+hp = 24000
 
 [ship.movement]
-speed_mps = 8
-main_acceleration_mpss = 10
-maneuvering_acceleration_mpss = 5
+speed_mps = 10
+main_acceleration_mpss = 8
+maneuvering_acceleration_mpss = 4
 angular_acceleration_radpss = 1
 max_rotation_speed_radps = 0.5
 
@@ -236,7 +277,6 @@ sensor_range_m = 300
 # the lower decks hold supports and 2x2 point-defense m guns.
 [[ship]]
 id = "carrier"
-unlock_at_station_level = -1
 layout = [
     "XOOOOOOOOX",
     "OOOOOOOOOO",
@@ -244,18 +284,26 @@ layout = [
     "XOOOOOOOOX",
     "XXXOOOOXXX",
 ]
+default_modules = [
+    {type = "drone_hangar", x = 2, y = 0, rotation = "east"},
+    {type = "railgun_m", x = 3, y = 2, rotation = "east"},
+    {type = "railgun_m", x = 6, y = 2, rotation = "east"},
+    {type = "armor_plates", x = 0, y = 1, rotation = "east"},
+    {type = "armor_plates", x = 8, y = 1, rotation = "east"},
+    {type = "sensor_booster", x = 3, y = 4, rotation = "east"},
+]
 
 [ship.schematic]
 materials = [{item = "carrier_hull", amount = 1}]
-production_time_seconds = 120
+production_time_seconds = 8
 
 [ship.health]
-hp = 700
+hp = 24000
 
 [ship.movement]
-speed_mps = 9
-main_acceleration_mpss = 10
-maneuvering_acceleration_mpss = 5
+speed_mps = 10
+main_acceleration_mpss = 8
+maneuvering_acceleration_mpss = 4
 angular_acceleration_radpss = 1
 max_rotation_speed_radps = 0.5
 

bin/app/data/config/stations.toml

@@ -1,10 +1,18 @@
+# stations.toml
+#
+# Combat-pass anchors (see docs/balancing/targets.md, "Combat anchors"):
+# a fresh player defence station holds one early parity wave unaided; the
+# enemy station at level 0 matches the player station exactly and scales
+# with the push level x. Station scrap drops stay authored (pushing rewards
+# are tuned independently of ship production costs, REQ-RES-DEBRIS-DROP).
+
 [hq]
 surface_mask = [
   "AAA",
   "AAA",
   "AAA",
 ]
-hp_formula = "1000"
+hp_formula = "5000"
 
 [player_station]
 surface_mask = [
@@ -12,19 +20,19 @@ surface_mask = [
   "SS",
 ]
 level = 1
-hp_formula = "300"
-damage_formula = "5"
-range_m_formula = "200"
+hp_formula = "3000"
+damage_formula = "25"
+range_m_formula = "120"
 fire_rate_hz_formula = "1"
-scrap_drop_formula = "10"
+scrap_drop_formula = "40"
 
 [enemy_station]
 surface_mask = [
   "SS",
   "SS",
 ]
-hp_formula = "300 + 150*x"
-damage_formula = "2 + 1*x"
-range_m_formula = "200"
-fire_rate_hz_formula = "1.0 + 0.2*x"
-scrap_drop_formula = "10 + 5*x"
+hp_formula = "3000 + 1500*x"
+damage_formula = "25 + 12*x"
+range_m_formula = "120"
+fire_rate_hz_formula = "1.0 + 0.1*x"
+scrap_drop_formula = "40 + 30*x"

bin/app/data/config/unlocks.toml

@@ -0,0 +1,140 @@
+# Unlock groups (REQ-LOCK-EXPLICIT, REQ-DEF-SCHEMATIC-DROP).
+#
+# Each [[unlock]] is a group of ships/modules/buildings/recipes awarded together
+# from a single defence station drop. Anything NOT granted by any group is
+# available from game start. `station_level` gates when a group becomes eligible;
+# `requires` lists prerequisite unlock-group ids (REQ-LOCK-PREREQ).
+#
+# Most entries below are single-item groups that reproduce the previous per-item
+# progression. The salvage_operations and reprocessing groups are the grouped
+# unlocks: they lock the salvager module + salvage bay, and the reprocessing
+# plant, from game start.
+
+# --- Grouped unlocks -------------------------------------------------------
+
+[[unlock]]
+id = "salvage_operations"
+station_level = 1
+modules = ["salvager"]
+buildings = ["salvage_bay"]
+
+[[unlock]]
+id = "reprocessing"
+station_level = 2
+buildings = ["reprocessing_plant"]
+
+# --- Ships -----------------------------------------------------------------
+
+[[unlock]]
+id = "destroyer"
+station_level = 0
+ships = ["destroyer"]
+
+[[unlock]]
+id = "cruiser"
+station_level = 2
+ships = ["cruiser"]
+
+[[unlock]]
+id = "battlecruiser"
+station_level = 4
+requires = ["cruiser"]
+ships = ["battlecruiser"]
+
+[[unlock]]
+id = "battleship"
+station_level = 6
+requires = ["battlecruiser"]
+ships = ["battleship"]
+
+[[unlock]]
+id = "dreadnought"
+station_level = 8
+requires = ["battleship"]
+ships = ["dreadnought"]
+
+[[unlock]]
+id = "carrier"
+station_level = 9
+requires = ["battleship"]
+ships = ["carrier"]
+
+# --- Modules ---------------------------------------------------------------
+
+[[unlock]]
+id = "repair_tool"
+station_level = 0
+modules = ["repair_tool"]
+
+[[unlock]]
+id = "armor_plates"
+station_level = 0
+modules = ["armor_plates"]
+
+[[unlock]]
+id = "maneuvering_thrusters"
+station_level = 1
+modules = ["maneuvering_thrusters"]
+
+[[unlock]]
+id = "sensor_booster"
+station_level = 1
+modules = ["sensor_booster"]
+
+[[unlock]]
+id = "railgun_m"
+station_level = 2
+modules = ["railgun_m"]
+
+[[unlock]]
+id = "afterburner"
+station_level = 2
+modules = ["afterburner"]
+
+[[unlock]]
+id = "weapon_stabilizer"
+station_level = 3
+modules = ["weapon_stabilizer"]
+
+[[unlock]]
+id = "weapon_upgrade"
+station_level = 4
+modules = ["weapon_upgrade"]
+
+[[unlock]]
+id = "weapon_primer"
+station_level = 4
+modules = ["weapon_primer"]
+
+[[unlock]]
+id = "drone_bay"
+station_level = 5
+modules = ["drone_bay"]
+
+[[unlock]]
+id = "railgun_l"
+station_level = 6
+requires = ["railgun_m"]
+modules = ["railgun_l"]
+
+[[unlock]]
+id = "drone_hangar"
+station_level = 9
+modules = ["drone_hangar"]
+
+# --- Assembler recipes -----------------------------------------------------
+
+[[unlock]]
+id = "direct_rolling"
+station_level = 1
+recipes = ["direct_rolling"]
+
+[[unlock]]
+id = "direct_etching"
+station_level = 2
+recipes = ["direct_etching"]
+
+[[unlock]]
+id = "direct_hardening"
+station_level = 2
+recipes = ["direct_hardening"]

bin/app/data/config/visuals.toml

@@ -63,7 +63,7 @@ outline = "#ffffff"
 glyph   = "Sb"
 
 [buildings.belt]
-fill    = "#5a5a5a"
+fill    = "#1a1a1a"
 outline = "#7a7a7a"
 glyph   = ""
 
@@ -109,40 +109,40 @@ glyph   = "E"
 # --- ores ---
 
 [items.iron_ore]
-fill    = "#8a5a4a"
-outline = "#201010"
+fill    = "#47271c"
+outline = "#a65b42"
 
 [items.copper_ore]
-fill    = "#c47a3a"
-outline = "#3a1a0a"
+fill    = "#deb592"
+outline = "#826a56"
 
-[items.titanium_ore]
-fill    = "#9aa3ad"
-outline = "#2a2e33"
+[items.quartz]
+fill    = "#4f3d66"
+outline = "#9776c4"
 
-# --- ingots ---
+# --- smelted basics ---
 
 [items.iron_ingot]
-fill    = "#b0b0b8"
-outline = "#202028"
+fill    = "#535357"
+outline = "#97979e"
 
 [items.copper_ingot]
-fill    = "#d48a4a"
-outline = "#402010"
+fill    = "#663810"
+outline = "#b07746"
 
-[items.titanium_ingot]
-fill    = "#c8d2dc"
-outline = "#3a4048"
+[items.silicon]
+fill    = "#737f99"
+outline = "#373f4f"
 
 # --- salvage loop ---
 
 [items.scrap]
-fill    = "#7a7268"
-outline = "#201a14"
+fill    = "#998e81"
+outline = "#574b3d"
 
-[items.advanced_alloy]
-fill    = "#a06acc"
-outline = "#201030"
+[items.voidsteel]
+fill    = "#82759c"
+outline = "#3f374f"
 
 # --- basic components ---
 
@@ -151,102 +151,106 @@ fill    = "#e09a50"
 outline = "#3a2008"
 
 [items.steel_plate]
-fill    = "#8a92a0"
-outline = "#22262c"
+fill    = "#202836"
+outline = "#54698c"
 
-[items.circuit_board]
-fill    = "#2ea35a"
-outline = "#0a2a14"
+[items.copper_coil]
+fill    = "#cca287"
+outline = "#755d4d"
 
 [items.building_block]
-fill    = "#c8b070"
-outline = "#302810"
+fill    = "#544724"
+outline = "#a18845"
 
 # --- advanced components ---
 
-[items.mechanical_parts]
-fill    = "#6f7a66"
-outline = "#1c2018"
+[items.control_chip]
+fill    = "#74b08b"
+outline = "#42634e"
 
-[items.targeting_unit]
-fill    = "#3a9e8c"
-outline = "#0c2824"
+[items.capacitor_bank]
+fill    = "#d0a030"
+outline = "#302408"
+
+[items.hardened_steel]
+fill    = "#818999"
+outline = "#3e4859"
+
+[items.ceramic_plate]
+fill    = "#e0d8c8"
+outline = "#3a3428"
 
 [items.drive_unit]
-fill    = "#4a6ad0"
-outline = "#101a38"
-
-[items.titanium_frame]
-fill    = "#b8c4d4"
-outline = "#343c48"
+fill    = "#92a4de"
+outline = "#545f80"
 
 # --- capital components ---
 
-[items.reinforced_plating]
-fill    = "#8a6ad0"
-outline = "#1c1038"
+[items.voidsteel_plate]
+fill    = "#9986b5"
+outline = "#544766"
 
 [items.capital_core]
-fill    = "#b040d0"
-outline = "#280c30"
+fill    = "#420c52"
+outline = "#9444ab"
 
 # --- module items ---
 
-[items.laser_cannon_s_module]
-fill    = "#691313"
-outline = "#f3ff4f"
+[items.railgun_s_module]
+fill    = "#bf7e7e"
+outline = "#664343"
 
-[items.laser_cannon_m_module]
-fill    = "#892020"
-outline = "#f3ff4f"
+[items.railgun_m_module]
+fill    = "#b07474"
+outline = "#593b3b"
 
-[items.laser_cannon_l_module]
-fill    = "#a92d2d"
-outline = "#f3ff4f"
+[items.railgun_l_module]
+fill    = "#b07474"
+outline = "#593b3b"
 
 [items.salvager_module]
 fill    = "#b2cfdd"
 outline = "#236137"
 
 [items.repair_tool_module]
-fill    = "#2e9ba3"
-outline = "#689275"
+fill    = "#0b4347"
+outline = "#38868c"
 
 [items.armor_plates_module]
-fill    = "#808080"
-outline = "#202020"
+fill    = "#999999"
+outline = "#545454"
 
 [items.sensor_booster_module]
-fill    = "#40a0ff"
-outline = "#102840"
+fill    = "#a0c9f2"
+outline = "#607991"
 
 [items.maneuvering_thrusters_module]
-fill    = "#5090e0"
-outline = "#142438"
+fill    = "#92b4de"
+outline = "#566982"
 
 [items.afterburner_module]
-fill    = "#6080c0"
-outline = "#182030"
+fill    = "#1d2e52"
+outline = "#486db5"
 
 [items.weapon_upgrade_module]
 fill    = "#ff4040"
 outline = "#401010"
 
 [items.weapon_primer_module]
-fill    = "#e03838"
-outline = "#380e0e"
+fill    = "#e69797"
+outline = "#855858"
 
 [items.weapon_stabilizer_module]
-fill    = "#c03030"
-outline = "#300c0c"
+fill    = "#c78383"
+outline = "#6e4848"
 
 [items.drone_bay_module]
 fill    = "#cc66ff"
 outline = "#331040"
 
 [items.drone_hangar_module]
-fill    = "#9933cc"
-outline = "#260c33"
+fill    = "#8c689e"
+outline = "#42314a"
 
 # --- ship hulls (outline matches the ship's fleet color in [ships.*]) ---
 
@@ -279,8 +283,8 @@ fill    = "#1b1b1b"
 outline = "#ff5533"
 
 [items.carrier_hull]
-fill    = "#1b1b1b"
-outline = "#cc66ff"
+fill    = "#310f42"
+outline = "#8542a6"
 
 # -----------------------------------------------------------------------------
 # Ships
@@ -331,7 +335,7 @@ salvage_color = "#33ccff"
 width_px      = 2
 
 # -----------------------------------------------------------------------------
-# Build / demolish / selection overlays
+# Build / deconstruct / selection overlays
 #
 # All overlay colors carry an alpha channel so they composite over the
 # underlying scene.
@@ -340,10 +344,14 @@ width_px      = 2
 [overlays]
 ghost_valid    = "#ffffff44"   # builder-mode ghost, placement allowed (REQ-BLD-GHOST)
 ghost_invalid  = "#ff000044"   # builder-mode ghost, placement invalid (REQ-BLD-PLACE-VALID)
-demolish_tint  = "#ff000033"   # demolish-mode hover tint
+deconstruct_tint  = "#ff000033"   # deconstruct-mode hover tint
 selection_rect = "#00ff00"     # box-drag selection rectangle (REQ-UI-MULTI-SELECT)
 tile_highlight = "#ffffff22"   # tile under cursor
 selected_outline = "#ffff00"   # outline drawn around currently-selected building(s)
+config_transfer = "#33ccff66"  # blueprint ghost over a configuration-transfer target (REQ-UI-BLUEPRINT-TRANSFER)
+locked_asteroid = "#0000007f"  # tint over the asteroid left of the buildable edge (not yet unlocked by expansion)
+modal_dim      = "#00000099"   # semi-transparent black dim behind modal dialogs/menus (REQ-UI-MODAL-DIM)
+tunnel_preview = "#00ff0055"   # tunnel connection preview: matched end + tiles between (REQ-BLD-TUNNEL-MODE)
 
 # -----------------------------------------------------------------------------
 # Schematic-drop toasts (REQ-UI-SCHEMATIC-TOAST)
@@ -353,3 +361,17 @@ selected_outline = "#ffff00"   # outline drawn around currently-selected buildin
 bg        = "#000000cc"
 fg        = "#ffffff"
 font_size = 14
+
+# -----------------------------------------------------------------------------
+# Building status light (REQ-UI-STATUS-LIGHT)
+#
+# Fill color per production state, drawn as a small circle in the building's
+# upper-right corner, plus the constant outline color.
+# -----------------------------------------------------------------------------
+
+[status_light]
+grey    = "#808080"   # no recipe/schematic selected
+green   = "#33cc33"   # producing (Salvage Bay: holding scrap)
+red     = "#cc3333"   # idle, input missing (Salvage Bay: empty)
+yellow  = "#e6c619"   # idle, output buffer full
+outline = "#000000"

bin/app/data/config/world.toml

@@ -1,25 +1,37 @@
 [world]
-height_tiles = 40
+height_tiles = 30
 refund_percentage = 100
-starting_building_blocks = 1000
-scrap_despawn_seconds = 30
-scrap_per_threat = 0.01
+deconstruction_time_seconds = 0.1
+starting_building_blocks = 200
+debris_despawn_seconds = 120
+scrap_per_threat = 0.25
 tile_size_m = 10
 belt_speed_mps = 20
 tunnel_max_distance_tiles = 10
 departure_interval_seconds = 20
 orbit_factor = 0.8
 rally_orbit_radius_tiles = 5.0
+building_blocks_tooltip = "Building blocks are the currency for construction. Spend them to place buildings and to expand the asteroid. Produce building blocks in your assemblers and deliver them to the HQ on a belt to grow your stock."
+artifact_tooltip = "Artifacts are the key to victory. Earn one by choosing the artifact reward when you destroy a set of enemy defence stations. Collect enough of them to win the game."
 
 [regions]
-asteroid_width_tiles = 60
+asteroid_width_tiles = 40
 player_buffer_width_tiles = 20
 contest_zone_width_tiles = 60
 enemy_buffer_width_tiles = 20
 
+[scroll]
+# View pan speed (REQ-UI-SCROLL-SPEED): slow near the asteroid, fast across the
+# contest zone, with a linear ramp of the given width straddling each boundary.
+pan_speed_slow_tiles_per_second = 16.0
+pan_speed_fast_tiles_per_second = 32.0
+pan_ramp_band_width_tiles = 16
+
 [expansion]
 columns_per_expansion_tiles = 10
-cost_building_blocks = 200
+# x = expansions already purchased; ~1 per cycle mid-game, decelerating
+# to 2-3 cycles late (docs/balancing/derived.md).
+cost_building_blocks_formula = "300 + 50*x + 10*x*x"
 
 [push]
 push_expand_columns_tiles = 10
@@ -32,10 +44,13 @@ target_hysteresis         = 0.40                   # keep current target unless
 
 [artifacts]
 artifact_chance_formula = "0.05 * x"  # 5% chance per station level
-artifact_win_count      = 3
+artifact_win_count      = 5
 
 [waves]
-threat_rate_formula = "x"
+# Tuned against the factory-size curve (docs/balancing/targets.md, balancing
+# targets): stays below the player's achievable military output early,
+# crosses it around the late boundary (~cycle 15), overwhelms by ~24.
+threat_rate_formula = "2*x + 0.15*x*x"
 gap_min_seconds = 15
 gap_max_seconds = 45
 spawn_duration_seconds = 10

bin/app/data/icons/buildings/assembler.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#3a6fa8"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <circle cx="16" cy="16" r="6.2"/><circle cx="16" cy="16" r="2.2"/><path d="M16 5.5v3M16 23.5v3M5.5 16h3M23.5 16h3M8.6 8.6 10.7 10.7M23.4 8.6 21.3 10.7M8.6 23.4 10.7 21.3M23.4 23.4 21.3 21.3"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/belt.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#6a6a6a"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <rect x="4" y="10" width="24" height="12" rx="3"/><path d="M9 13 12.5 16 9 19"/><path d="M14.5 13 18 16 14.5 19"/><path d="M20 13 23.5 16 20 19"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/deconstruct.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#cc3333"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <path d="M7 10h18"/><path d="M9.5 10 11 26h10l1.5-16"/><path d="M13 10V6.5h6V10"/><path d="M13.5 14v8M18.5 14v8"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/hq.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#2e5fb8"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <rect x="7" y="15" width="18" height="11" rx="1"/><path d="M16 15V5"/><path d="M16 6h6l-2.2 2 2.2 2h-6"/><path d="M11 19h2.5M15.5 19h2.5M20 19h1.5"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/miner.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#6b4a2c"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <rect x="9" y="5" width="14" height="8" rx="1.5"/><path d="M11 13 16 26 21 13"/><path d="M13 17.5h6"/><path d="M14.5 21.5h3"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/reprocessing_plant.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#6a3a8a"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <circle cx="12" cy="18" r="4"/><circle cx="20" cy="18" r="4"/><path d="M10.6 16.6 13.4 19.4M13.4 16.6 10.6 19.4M18.6 16.6 21.4 19.4M21.4 16.6 18.6 19.4"/><path d="M16 4v8"/><path d="M13 9 16 12 19 9"/><path d="M16 24v4"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/salvage_bay.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#b8a23a"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <path d="M7 13h18l-2 13H9z"/><path d="M16 3v7"/><path d="M12 7 16 11 20 7"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/shipyard.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#3f6580"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <path d="M16 4c2 3 2.6 6 2.6 9.5V16h-5.2v-2.5C13.4 10 14 7 16 4z"/><circle cx="16" cy="10" r="1.3"/><path d="M13.4 15 11 18h2.4z"/><path d="M18.6 15 21 18h-2.4z"/><path d="M14.7 17 16 21 17.3 17"/><path d="M9 25h14"/><path d="M12 25v-2M20 25v-2"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/smelter.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#b85a1e"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <path d="M9 9h14l-2.5 8h-9z"/><path d="M8 9h16"/><path d="M11 26c-1-1.8.4-3 .4-4 .9 1 1.6 2.2 1.6 4"/><path d="M16 26c-1-2 .4-3.4.4-4.4 .9 1 1.6 2.6 1.6 4.4"/><path d="M21 26c-1-1.8.4-3 .4-4 .9 1 1.6 2.2 1.6 4"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/splitter.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#7a7a5a"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <path d="M5 16h11"/><path d="M16 8v16"/><path d="M13.5 10.5 16 8 18.5 10.5"/><path d="M13.5 21.5 16 24 18.5 21.5"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/station.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#55606f"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <path d="M16 4 26 8v7c0 7-5 11-10 13-5-2-10-6-10-13V8z"/><path d="M16 11v9M11.5 15.5h9"/>
+  </g>
+</svg>

bin/app/data/icons/buildings/tunnel_entry.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
+  <rect width="100" height="100" rx="22" fill="#4f7562"/>
+  <g transform="translate(13,13) scale(2.3125)" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+    <path d="M3 13H29"/><path d="M4 7H8Q10 7 10 9.5V21.5Q10 24 12.5 24H19.5Q22 24 22 21.5V9.5Q22 7 24 7H27"/><path d="M24.5 4.5 27 7 24.5 9.5"/>
+  </g>
+</svg>

bin/app/data/icons/items/afterburner_module.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="11.6 19.6 76.9 76.9" width="100" height="100">
+  <rect x="34" y="24" width="32" height="26" rx="5" fill="#6080c0" stroke="#182030" stroke-width="3.5"/>
+  <path d="M36 50 L64 50 L58 62 L42 62 Z" fill="#3a5090" stroke="#182030" stroke-width="2.5" stroke-linejoin="round"/>
+  <path d="M42 62 Q46 80 50 62 Q54 80 58 62 Q56 90 50 92 Q44 90 42 62 Z" fill="#ff9a3a"/>
+  <path d="M47 64 Q50 82 53 64 Z" fill="#ffe08a"/>
+</svg>

bin/app/data/icons/items/armor_plates_module.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="10.5 11.5 79.0 79.0" width="100" height="100">
+  <path d="M50 16 L80 26 L80 50 Q80 74 50 86 Q20 74 20 50 L20 26 Z" fill="#808080" stroke="#202020" stroke-width="3.5" stroke-linejoin="round"/>
+  <path d="M50 16 L50 86" stroke="#5a5a5a" stroke-width="3"/>
+  <path d="M20 42 Q50 52 80 42" fill="none" stroke="#5a5a5a" stroke-width="3"/>
+</svg>

bin/app/data/icons/items/battlecruiser_hull.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="7.1 6.1 85.9 85.9" width="100" height="100">
+  <path d="M50 12 L66 40 L88 60 L64 58 L60 86 L40 86 L36 58 L12 60 L34 40 Z" fill="#9fb3c9" stroke="#232a33" stroke-width="4" stroke-linejoin="round"/>
+  <circle cx="50" cy="40" r="7" fill="#cccc33" stroke="#232a33" stroke-width="2.5"/>
+  <g fill="#3a4450"><circle cx="44" cy="82" r="3.2"/><circle cx="56" cy="82" r="3.2"/></g>
+</svg>

bin/app/data/icons/items/battleship_hull.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="9.2 9.2 81.6 81.6" width="100" height="100">
+  <path d="M50 14 L70 44 L82 78 L60 70 L58 86 L42 86 L40 70 L18 78 L30 44 Z" fill="#9fb3c9" stroke="#232a33" stroke-width="4" stroke-linejoin="round"/>
+  <circle cx="50" cy="44" r="7" fill="#ff9933" stroke="#232a33" stroke-width="2.5"/>
+  <g fill="#3a4450"><circle cx="44" cy="82" r="3.2"/><circle cx="56" cy="82" r="3.2"/></g>
+</svg>

bin/app/data/icons/items/building_block.svg

@@ -0,0 +1,12 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="14.9 15.9 70.2 70.2" width="100" height="100">
+  <g stroke="#302810" stroke-width="3.2" stroke-linejoin="round">
+    <path d="M50 20 L78 36 L50 52 L22 36 Z" fill="#ddc98f"/>
+    <path d="M50 52 L78 36 L78 66 L50 82 Z" fill="#b39a5c"/>
+    <path d="M50 52 L22 36 L22 66 L50 82 Z" fill="#c8b070"/>
+  </g>
+  <g stroke="#302810" stroke-width="1.8" stroke-linejoin="round">
+    <path d="M50 26.4 L66.8 36 L50 45.6 L33.2 36 Z" fill="#cbb772"/>
+    <path d="M55.3 54.7 L72.7 44.7 L72.7 63.3 L55.3 73.3 Z" fill="#a2894f"/>
+    <path d="M44.7 54.7 L27.3 44.7 L27.3 63.3 L44.7 73.3 Z" fill="#b7a465"/>
+  </g>
+</svg>

bin/app/data/icons/items/capacitor_bank.svg

@@ -0,0 +1,12 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="17.0 16.0 65.9 65.9" width="100" height="100">
+  <g stroke="#302408" stroke-width="3.2" stroke-linecap="round">
+    <line x1="37" y1="20" x2="37" y2="30"/>
+    <line x1="63" y1="20" x2="63" y2="30"/>
+  </g>
+  <g stroke="#302408" stroke-width="3.2" stroke-linejoin="round">
+    <rect x="28" y="28" width="18" height="50" rx="8" fill="#d0a030"/>
+    <rect x="54" y="28" width="18" height="50" rx="8" fill="#e0b040"/>
+  </g>
+  <line x1="30" y1="42" x2="44" y2="42" stroke="#6b5410" stroke-width="2.6"/>
+  <line x1="56" y1="42" x2="70" y2="42" stroke="#6b5410" stroke-width="2.6"/>
+</svg>

bin/app/data/icons/items/capital_core.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15.5 17.5 68.9 68.9" width="100" height="100">
+  <circle cx="50" cy="52" r="30" fill="#b040d0" stroke="#280c30" stroke-width="4"/>
+  <path d="M50 26 L68 46 L50 78 L32 46 Z" fill="#d06ae8" stroke="#280c30" stroke-width="2.5" stroke-linejoin="round"/>
+  <circle cx="43" cy="44" r="6" fill="#f0c0f8"/>
+</svg>

bin/app/data/icons/items/carrier_hull.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="13.4 17.4 73.1 73.1" width="100" height="100">
+  <path d="M28 24 L72 24 L82 50 L72 84 L28 84 L18 50 Z" fill="#9fb3c9" stroke="#232a33" stroke-width="4" stroke-linejoin="round"/>
+  <line x1="50" y1="26" x2="50" y2="82" stroke="#4a5560" stroke-width="4"/>
+  <circle cx="50" cy="38" r="6" fill="#cc66ff" stroke="#232a33" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/ceramic_plate.svg

@@ -0,0 +1,4 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15.8 15.8 68.4 68.4" width="100" height="100">
+  <path d="M50 20 L76 35 L76 65 L50 80 L24 65 L24 35 Z" fill="#e0d8c8" stroke="#3a3428" stroke-width="3.5" stroke-linejoin="round"/>
+  <path d="M50 32 L64 40 L64 60 L50 68 L36 60 L36 40 Z" fill="#efe9dd" stroke="#3a3428" stroke-width="2"/>
+</svg>

bin/app/data/icons/items/control_chip.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15.5 15.5 68.9 68.9" width="100" height="100">
+  <rect x="20" y="20" width="60" height="60" rx="11" fill="#1f7a44" stroke="#0e3320" stroke-width="4"/>
+  <rect x="33" y="33" width="34" height="34" rx="5" fill="#3fbf6a" stroke="#0e3320" stroke-width="3"/>
+  <path d="M50 33 L50 24 M50 67 L50 76 M33 50 L24 50 M67 50 L76 50" stroke="#186036" stroke-width="4" stroke-linecap="round"/>
+  <circle cx="50" cy="50" r="6" fill="#c9a227" stroke="#0e3320" stroke-width="2"/>
+</svg>

bin/app/data/icons/items/copper_coil.svg

@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0.0 2.0 100.0 100.0" width="100" height="100">
+  <circle cx="50" cy="52" r="42" fill="none" stroke="#3a1e08" stroke-width="2.5"/>
+  <circle cx="50" cy="52" r="26" fill="none" stroke="#3a1e08" stroke-width="2.5"/>
+  <circle cx="50" cy="52" r="34" fill="none" stroke="#cf7a2c" stroke-width="16"/>
+  <circle cx="50" cy="52" r="34" fill="none" stroke="#8a4e18" stroke-width="16" stroke-dasharray="3 11"/>
+  <circle cx="50" cy="52" r="34" fill="none" stroke="#eaa85f" stroke-width="16" stroke-dasharray="2 12" stroke-dashoffset="6"/>
+</svg>

bin/app/data/icons/items/copper_ingot.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="24.0 28.0 62.0 62.0" width="100" height="100">
+  <g stroke="#3a1e08" stroke-width="3.5" stroke-linejoin="round">
+    <path d="M28 72 L72 72 L64 54 L36 54 Z" fill="#cf7a2c"/>
+    <path d="M64 54 L72 72 L82 64 L74 46 Z" fill="#a85e20"/>
+    <path d="M36 54 L64 54 L74 46 L46 46 Z" fill="#e59a52"/>
+  </g>
+  <path d="M40 63 L60 63" stroke="#f0b878" stroke-width="3" stroke-linecap="round"/>
+</svg>

bin/app/data/icons/items/copper_ore.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="11.5 11.5 79.0 79.0" width="100" height="100">
+  <path d="M50 16 L76 28 L86 54 L70 84 L36 86 L16 58 L24 30 Z" fill="#5f8f78" stroke="#16241d" stroke-width="3.5" stroke-linejoin="round"/>
+  <path d="M50 16 L58 47 L24 30 Z" fill="#79a890"/>
+  <path d="M58 47 L70 84 L36 86 Z" fill="#4a7060"/>
+  <path d="M50 16 L58 47 M58 47 L86 54 M58 47 L70 84 M58 47 L36 86 M58 47 L24 30" fill="none" stroke="#2c463a" stroke-width="2.2" stroke-linecap="round"/>
+  <circle cx="41" cy="56" r="4" fill="#d98a3e"/>
+  <circle cx="62" cy="66" r="3.2" fill="#d98a3e"/>
+</svg>

bin/app/data/icons/items/copper_wire.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="8.1 4.1 83.7 83.7" width="100" height="100">
+  <g fill="none" stroke-linecap="round">
+    <path d="M16 38 q17 -12 34 0 t34 0" stroke="#3a1e08" stroke-width="10"/>
+    <path d="M16 52 q17 -12 34 0 t34 0" stroke="#3a1e08" stroke-width="10"/>
+    <path d="M16 66 q17 -12 34 0 t34 0" stroke="#3a1e08" stroke-width="10"/>
+    <path d="M16 38 q17 -12 34 0 t34 0" stroke="#cf7a2c" stroke-width="6"/>
+    <path d="M16 52 q17 -12 34 0 t34 0" stroke="#d98a3e" stroke-width="6"/>
+    <path d="M16 66 q17 -12 34 0 t34 0" stroke="#cf7a2c" stroke-width="6"/>
+  </g>
+</svg>

bin/app/data/icons/items/cruiser_hull.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="9.2 8.2 81.6 81.6" width="100" height="100">
+  <path d="M50 14 L62 40 L86 58 L64 56 L60 84 L40 84 L36 56 L14 58 L38 40 Z" fill="#9fb3c9" stroke="#232a33" stroke-width="4" stroke-linejoin="round"/>
+  <circle cx="50" cy="40" r="6.5" fill="#66cc33" stroke="#232a33" stroke-width="2.5"/>
+  <g fill="#3a4450"><circle cx="45" cy="80" r="3"/><circle cx="55" cy="80" r="3"/></g>
+</svg>

bin/app/data/icons/items/destroyer_hull.svg

@@ -0,0 +1,4 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="9.2 8.2 81.6 81.6" width="100" height="100">
+  <path d="M50 14 L62 40 L86 58 L64 56 L60 84 L40 84 L36 56 L14 58 L38 40 Z" fill="#9fb3c9" stroke="#232a33" stroke-width="4" stroke-linejoin="round"/>
+  <circle cx="50" cy="40" r="6.5" fill="#33ccaa" stroke="#232a33" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/dreadnought_hull.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="7.1 7.1 85.9 85.9" width="100" height="100">
+  <path d="M50 12 L72 42 L86 80 L62 72 L58 88 L42 88 L38 72 L14 80 L28 42 Z" fill="#9fb3c9" stroke="#232a33" stroke-width="4" stroke-linejoin="round"/>
+  <circle cx="50" cy="42" r="7.5" fill="#ff5533" stroke="#232a33" stroke-width="2.5"/>
+  <g fill="#3a4450"><circle cx="42" cy="82" r="3.4"/><circle cx="50" cy="84" r="3.4"/><circle cx="58" cy="82" r="3.4"/></g>
+</svg>

bin/app/data/icons/items/drive_unit.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="9.2 17.2 81.6 81.6" width="100" height="100">
+  <path d="M40 22 L60 22 L58 42 L72 74 L28 74 L42 42 Z" fill="#4a6ad0" stroke="#101a38" stroke-width="3.5" stroke-linejoin="round"/>
+  <ellipse cx="50" cy="74" rx="22" ry="6" fill="#2a3a80" stroke="#101a38" stroke-width="2.5"/>
+  <path d="M40 22 L60 22" stroke="#8aa0e8" stroke-width="4" stroke-linecap="round"/>
+  <path d="M44 80 Q50 94 56 80" fill="#ffb347"/>
+</svg>

bin/app/data/icons/items/drone_bay_module.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="16.9 15.9 66.2 66.2" width="100" height="100">
+  <rect x="22" y="52" width="56" height="26" rx="5" fill="#7a2a9a" stroke="#331040" stroke-width="3.5"/>
+  <line x1="22" y1="65" x2="78" y2="65" stroke="#4a1560" stroke-width="2.5"/>
+  <path d="M50 20 L61 42 L50 35 L39 42 Z" fill="#cc66ff" stroke="#331040" stroke-width="3" stroke-linejoin="round"/>
+  <line x1="50" y1="44" x2="50" y2="52" stroke="#331040" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/drone_hangar_module.svg

@@ -0,0 +1,9 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="13.7 12.7 72.6 72.6" width="100" height="100">
+  <rect x="18" y="50" width="64" height="30" rx="5" fill="#5a1c7a" stroke="#260c33" stroke-width="3.5"/>
+  <line x1="18" y1="64" x2="82" y2="64" stroke="#3a1050" stroke-width="2.5"/>
+  <g fill="#b060e0" stroke="#260c33" stroke-width="2.5" stroke-linejoin="round">
+    <path d="M32 22 L40 38 L32 33 L24 38 Z"/>
+    <path d="M50 18 L58 34 L50 29 L42 34 Z"/>
+    <path d="M68 22 L76 38 L68 33 L60 38 Z"/>
+  </g>
+</svg>

bin/app/data/icons/items/drone_hull.svg

@@ -0,0 +1,4 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="20.8 19.8 58.3 58.3" width="100" height="100">
+  <path d="M50 24 L66 74 L50 64 L34 74 Z" fill="#8f9bb0" stroke="#232a33" stroke-width="4" stroke-linejoin="round"/>
+  <circle cx="50" cy="44" r="6" fill="#3366ff" stroke="#232a33" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/frigate_hull.svg

@@ -0,0 +1,4 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="10.2 9.2 79.5 79.5" width="100" height="100">
+  <path d="M50 14 L74 84 L50 70 L26 84 Z" fill="#9fb3c9" stroke="#232a33" stroke-width="4" stroke-linejoin="round"/>
+  <circle cx="50" cy="40" r="7" fill="#44aaff" stroke="#232a33" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/hardened_steel.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15.5 15.5 68.9 68.9" width="100" height="100">
+  <rect x="20" y="26" width="60" height="48" rx="6" fill="#6a7280" stroke="#181c22" stroke-width="4"/>
+  <rect x="29" y="35" width="42" height="30" rx="3" fill="#7c8593" stroke="#181c22" stroke-width="2.5"/>
+  <g fill="#2a2f38">
+    <circle cx="26" cy="32" r="3.2"/><circle cx="74" cy="32" r="3.2"/>
+    <circle cx="26" cy="68" r="3.2"/><circle cx="74" cy="68" r="3.2"/>
+  </g>
+</svg>

bin/app/data/icons/items/iron_ingot.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="24.0 28.0 62.0 62.0" width="100" height="100">
+  <g stroke="#2f343b" stroke-width="3.5" stroke-linejoin="round">
+    <path d="M28 72 L72 72 L64 54 L36 54 Z" fill="#a2a9b0"/>
+    <path d="M64 54 L72 72 L82 64 L74 46 Z" fill="#868d95"/>
+    <path d="M36 54 L64 54 L74 46 L46 46 Z" fill="#c8ced4"/>
+  </g>
+  <path d="M40 63 L60 63" stroke="#c2c7cd" stroke-width="3" stroke-linecap="round"/>
+</svg>

bin/app/data/icons/items/iron_ore.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="11.5 11.5 79.0 79.0" width="100" height="100">
+  <path d="M50 16 L76 28 L86 54 L70 84 L36 86 L16 58 L24 30 Z"
+        fill="#9a8a7a" stroke="#241c16" stroke-width="3.5" stroke-linejoin="round"/>
+  <path d="M50 16 L58 47 L24 30 Z" fill="#b4a692"/>
+  <path d="M58 47 L70 84 L36 86 Z" fill="#7a6b5c"/>
+  <path d="M50 16 L58 47 M58 47 L86 54 M58 47 L70 84 M58 47 L36 86 M58 47 L24 30"
+        fill="none" stroke="#4a3d31" stroke-width="2.2" stroke-linecap="round"/>
+  <circle cx="41" cy="56" r="4" fill="#c8752e"/>
+  <circle cx="62" cy="66" r="3.2" fill="#c8752e"/>
+</svg>

bin/app/data/icons/items/maneuvering_thrusters_module.svg

@@ -0,0 +1,11 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="17.9 23.9 64.1 64.1" width="100" height="100">
+  <rect x="30" y="28" width="40" height="30" rx="5" fill="#5090e0" stroke="#142438" stroke-width="3.5"/>
+  <g fill="#3a6ab0" stroke="#142438" stroke-width="2.5" stroke-linejoin="round">
+    <path d="M34 58 L30 72 L44 72 L40 58 Z"/>
+    <path d="M60 58 L56 72 L70 72 L66 58 Z"/>
+  </g>
+  <g fill="#ffcf6a">
+    <path d="M33 72 L37 84 L41 72 Z"/>
+    <path d="M59 72 L63 84 L67 72 Z"/>
+  </g>
+</svg>

bin/app/data/icons/items/quartz.svg

@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="8.6 7.6 82.9 82.9" width="100" height="100">
+  <path d="M50 12 L70 40 L58 86 L42 86 L30 40 Z" fill="#dcd3f0" stroke="#40345a" stroke-width="3.2" stroke-linejoin="round"/>
+  <path d="M30 40 L70 40" stroke="#40345a" stroke-width="2.2"/>
+  <path d="M50 12 L50 86 M42 40 L42 86 M58 40 L58 86" stroke="#9d90c2" stroke-width="1.8" stroke-linecap="round"/>
+  <path d="M58 40 L70 40 L58 86 Z" fill="#c3b8e2"/>
+  <circle cx="45" cy="29" r="3" fill="#ffffff"/>
+</svg>

bin/app/data/icons/items/railgun_l_module.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="7.2 8.4 91.2 91.2" width="100" height="100">
+  <rect x="22" y="76" width="22" height="8" rx="2" fill="#3f454d" stroke="#20242a" stroke-width="3"/>
+  <rect x="12" y="24" width="32" height="52" rx="6" fill="#565d66" stroke="#20242a" stroke-width="3.5"/>
+  <rect x="42" y="30" width="46" height="10" rx="2" fill="#6b727b" stroke="#20242a" stroke-width="3.5"/>
+  <rect x="42" y="45" width="46" height="10" rx="2" fill="#6b727b" stroke="#20242a" stroke-width="3.5"/>
+  <rect x="42" y="60" width="46" height="10" rx="2" fill="#6b727b" stroke="#20242a" stroke-width="3.5"/>
+  <circle cx="88" cy="35" r="5.5" fill="#e23b2b" stroke="#20242a" stroke-width="2.5"/>
+  <circle cx="88" cy="50" r="5.5" fill="#e23b2b" stroke="#20242a" stroke-width="2.5"/>
+  <circle cx="88" cy="65" r="5.5" fill="#e23b2b" stroke="#20242a" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/railgun_m_module.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="9.2 8.2 89.6 89.6" width="100" height="100">
+  <rect x="22" y="68" width="20" height="8" rx="2" fill="#3f454d" stroke="#20242a" stroke-width="3"/>
+  <rect x="14" y="30" width="30" height="38" rx="6" fill="#565d66" stroke="#20242a" stroke-width="3.5"/>
+  <rect x="42" y="38" width="46" height="11" rx="2" fill="#6b727b" stroke="#20242a" stroke-width="3.5"/>
+  <rect x="42" y="51" width="46" height="11" rx="2" fill="#6b727b" stroke="#20242a" stroke-width="3.5"/>
+  <circle cx="88" cy="43.5" r="6" fill="#e23b2b" stroke="#20242a" stroke-width="2.5"/>
+  <circle cx="88" cy="56.5" r="6" fill="#e23b2b" stroke="#20242a" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/railgun_s_module.svg

@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="11.3 9.6 85.9 85.9" width="100" height="100">
+  <rect x="24" y="62" width="20" height="9" rx="2" fill="#3f454d" stroke="#20242a" stroke-width="3"/>
+  <rect x="16" y="34" width="30" height="30" rx="6" fill="#565d66" stroke="#20242a" stroke-width="3.5"/>
+  <rect x="42" y="43" width="44" height="12" rx="2" fill="#6b727b" stroke="#20242a" stroke-width="3.5"/>
+  <path d="M45 46.5 L84 46.5 M45 51.5 L84 51.5" stroke="#e0b12a" stroke-width="2.6" stroke-linecap="round"/>
+  <circle cx="86" cy="49" r="6.5" fill="#e23b2b" stroke="#20242a" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/repair_tool_module.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="9.3 10.3 78.4 78.4" width="100" height="100">
+  <line x1="30" y1="30" x2="66" y2="66" stroke="#2e9ba3" stroke-width="8" stroke-linecap="round"/>
+  <rect x="16" y="20" width="20" height="12" rx="3" fill="#1c6f76" stroke="#0f4247" stroke-width="2.5" transform="rotate(45 26 26)"/>
+  <path d="M64 64 L76 76 L72 80 L60 68 Z" fill="#bfe3e6" stroke="#0f4247" stroke-width="2"/>
+  <line x1="70" y1="30" x2="34" y2="66" stroke="#2e9ba3" stroke-width="8" stroke-linecap="round"/>
+  <circle cx="72" cy="28" r="9" fill="none" stroke="#2e9ba3" stroke-width="7"/>
+  <circle cx="32" cy="68" r="9" fill="none" stroke="#2e9ba3" stroke-width="7"/>
+</svg>

bin/app/data/icons/items/salvager_module.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="10.8 9.3 78.4 78.4" width="100" height="100">
+  <circle cx="50" cy="28" r="13" fill="#b2cfdd" stroke="#1c4a30" stroke-width="3.5"/>
+  <circle cx="50" cy="28" r="5" fill="#5f8f78"/>
+  <path d="M50 41 L50 56" stroke="#1c4a30" stroke-width="5" stroke-linecap="round"/>
+  <g fill="none" stroke="#5f8f78" stroke-width="6" stroke-linecap="round">
+    <path d="M50 54 L30 78"/>
+    <path d="M50 54 L50 82"/>
+    <path d="M50 54 L70 78"/>
+  </g>
+</svg>

bin/app/data/icons/items/scrap.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15.8 20.8 70.5 70.5" width="100" height="100">
+  <path d="M20 40 L44 30 L52 44 L74 34 L82 58 L60 66 L66 82 L38 78 L28 62 Z" fill="#8a8078" stroke="#241f1a" stroke-width="3.5" stroke-linejoin="round"/>
+  <circle cx="46" cy="52" r="4" fill="#241f1a"/>
+  <path d="M34 46 L44 60 M58 50 L66 62" stroke="#5f574f" stroke-width="2.5" stroke-linecap="round"/>
+</svg>

bin/app/data/icons/items/sensor_booster_module.svg

@@ -0,0 +1,9 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="23.2 8.7 71.5 71.5" width="100" height="100">
+  <path d="M28 76 L46 40 A28 28 0 0 1 76 56 Z" fill="#40a0ff" stroke="#102840" stroke-width="3.5" stroke-linejoin="round"/>
+  <line x1="52" y1="52" x2="70" y2="30" stroke="#102840" stroke-width="3.5" stroke-linecap="round"/>
+  <circle cx="71" cy="29" r="5" fill="#bfe0ff" stroke="#102840" stroke-width="2.5"/>
+  <g stroke="#bfe0ff" stroke-width="3" fill="none" stroke-linecap="round">
+    <path d="M78 20 a12 12 0 0 1 6 10"/>
+    <path d="M82 13 a20 20 0 0 1 8 17"/>
+  </g>
+</svg>

bin/app/data/icons/items/silicon.svg

@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="12.4 14.4 75.3 75.3" width="100" height="100">
+  <circle cx="50" cy="52" r="33" fill="#33415e" stroke="#0e1420" stroke-width="3.5"/>
+  <line x1="35" y1="27" x2="52" y2="22" stroke="#0e1420" stroke-width="4" stroke-linecap="round"/>
+  <circle cx="50" cy="52" r="21" fill="none" stroke="#46567a" stroke-width="2.6"/>
+  <circle cx="42" cy="44" r="5" fill="#5d6f96"/>
+</svg>

bin/app/data/icons/items/steel_plate.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15.8 15.8 68.4 68.4" width="100" height="100">
+  <rect x="20" y="30" width="60" height="40" rx="5" fill="#8a92a0" stroke="#22262c" stroke-width="3.5"/>
+  <line x1="26" y1="38" x2="74" y2="38" stroke="#aab1bb" stroke-width="3" stroke-linecap="round"/>
+  <g fill="#2f343b">
+    <circle cx="30" cy="40" r="3"/><circle cx="70" cy="40" r="3"/>
+    <circle cx="30" cy="60" r="3"/><circle cx="70" cy="60" r="3"/>
+  </g>
+</svg>

bin/app/data/icons/items/voidsteel.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="24.0 28.0 62.0 62.0" width="100" height="100">
+  <g stroke="#140a20" stroke-width="3.5" stroke-linejoin="round">
+    <path d="M28 72 L72 72 L64 54 L36 54 Z" fill="#3a2c52"/>
+    <path d="M64 54 L72 72 L82 64 L74 46 Z" fill="#291d3d"/>
+    <path d="M36 54 L64 54 L74 46 L46 46 Z" fill="#4d3a6e"/>
+  </g>
+  <path d="M40 63 L60 63" stroke="#8f6fc4" stroke-width="3" stroke-linecap="round"/>
+</svg>

bin/app/data/icons/items/voidsteel_plate.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15.5 15.5 68.9 68.9" width="100" height="100">
+  <rect x="20" y="28" width="60" height="44" rx="6" fill="#7a5aaa" stroke="#1c1038" stroke-width="4"/>
+  <line x1="26" y1="37" x2="74" y2="37" stroke="#a98fd0" stroke-width="3" stroke-linecap="round"/>
+  <g fill="#180c30">
+    <circle cx="30" cy="39" r="3"/><circle cx="70" cy="39" r="3"/>
+    <circle cx="30" cy="61" r="3"/><circle cx="70" cy="61" r="3"/>
+  </g>
+</svg>

bin/app/data/icons/items/weapon_primer_module.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="17.0 16.0 65.9 65.9" width="100" height="100">
+  <g stroke="#380e0e" stroke-width="3.2" stroke-linejoin="round">
+    <path d="M42 20 L58 20 L58 58 L50 72 L42 58 Z" fill="#e03838"/>
+    <rect x="40" y="56" width="20" height="22" rx="2" fill="#c9a227"/>
+  </g>
+  <line x1="41" y1="63" x2="59" y2="63" stroke="#7a5f14" stroke-width="2.5"/>
+  <line x1="41" y1="71" x2="59" y2="71" stroke="#7a5f14" stroke-width="2.5"/>
+</svg>

bin/app/data/icons/items/weapon_stabilizer_module.svg

@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="7.1 7.1 85.9 85.9" width="100" height="100">
+  <circle cx="50" cy="50" r="32" fill="none" stroke="#300c0c" stroke-width="8"/>
+  <circle cx="50" cy="50" r="32" fill="none" stroke="#c03030" stroke-width="5"/>
+  <ellipse cx="50" cy="50" rx="32" ry="12" fill="none" stroke="#e06060" stroke-width="4"/>
+  <line x1="50" y1="14" x2="50" y2="86" stroke="#c03030" stroke-width="4"/>
+  <circle cx="50" cy="50" r="6" fill="#c03030" stroke="#300c0c" stroke-width="2"/>
+</svg>

bin/app/data/icons/items/weapon_upgrade_module.svg

@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15.5 15.5 68.9 68.9" width="100" height="100">
+  <rect x="24" y="22" width="52" height="56" rx="10" fill="#7a1c1c" stroke="#3a0e0e" stroke-width="3.5"/>
+  <g fill="none" stroke="#ff6a6a" stroke-width="8" stroke-linejoin="round" stroke-linecap="round">
+    <path d="M34 52 L50 36 L66 52"/>
+    <path d="M34 66 L50 50 L66 66"/>
+  </g>
+</svg>

bin/balancing/data/balancing.toml

@@ -1,68 +1,397 @@
+# balancing.toml — canonical arena suite for the combat stats pass.
+#
+# Ship counts are chosen so both teams have (near-)equal total threat,
+# using the verified fitted threat values from tools/threat_report.py:
+#   drone 10.5, frigate 47, destroyer 99, cruiser 233.5,
+#   battlecruiser 354.5, battleship 722.5, dreadnought 1491.5,
+#   carrier 1436.5, glass destroyer (8 small guns) 92, repair drone 17.
+# Module arrays mirror the ships' default_modules loadouts unless a
+# doctrine variant is the point of the arena.
+#
+# Expectations: mirror matches and equal-threat cross-tier matchups should
+# be near-draws (power-per-threat rule); the two-to-one arena must be a
+# decisive win for the larger team. "Cruisers vs carrier" is EXPECTED to be
+# a loss for the carrier until the drone-launching capability exists — the
+# hangar is 224 threat of dead weight.
+
+# --- mirrors (sanity: symmetric outcomes, fight duration in the 30-60 s band) ---
+
 [[arena]]
-name = "Fighters vs Sniper"
-height_tiles = 20
+name = "Mirror: drones 20v20"
+height_tiles = 10
 player_buffer_width_tiles = 10
-contest_zone_width_tiles = 60
+contest_zone_width_tiles = 50
 enemy_buffer_width_tiles = 10
 
   [[arena.team]]
   name = "Alpha"
     [[arena.team.ship]]
     schematic = "drone"
-    count = 5
+    count = 20
     modules = [
-      {type = "laser_cannon_s",  x = 1, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
     ]
 
   [[arena.team]]
   name = "Beta"
     [[arena.team.ship]]
     schematic = "drone"
-    count = 2
+    count = 20
     modules = [
-      {type = "laser_cannon_s",  x = 1, y = 1, rotation = "east"},
-      {type = "weapon_stabilizer",  x = 1, y = 1, rotation = "east"},
-      {type = "weapon_stabilizer",  x = 1, y = 1, rotation = "east"},
-      {type = "weapon_upgrade",  x = 1, y = 1, rotation = "east"},
-      {type = "sensor_booster",  x = 1, y = 1, rotation = "east"},
-      {type = "sensor_booster",  x = 1, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
     ]
 
 [[arena]]
-name = "Fighters vs Supported"
-height_tiles = 20
+name = "Mirror: cruisers 6v6"
+height_tiles = 10
 player_buffer_width_tiles = 10
-contest_zone_width_tiles = 60
+contest_zone_width_tiles = 50
 enemy_buffer_width_tiles = 10
 
   [[arena.team]]
-  name = "Fighters"
+  name = "Alpha"
     [[arena.team.ship]]
-    schematic = "drone"
-    count = 5
+    schematic = "cruiser"
+    count = 6
     modules = [
-      {type = "laser_cannon_s",  x = 1, y = 1, rotation = "east"},
+      {type = "railgun_m", x = 0, y = 1, rotation = "east"},
+      {type = "railgun_m", x = 2, y = 1, rotation = "east"},
+      {type = "armor_plates", x = 1, y = 0, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 1, y = 3, rotation = "east"},
     ]
 
   [[arena.team]]
-  name = "Supported"
+  name = "Beta"
     [[arena.team.ship]]
-    schematic = "drone"
-    count = 3
+    schematic = "cruiser"
+    count = 6
     modules = [
-      {type = "laser_cannon_s",  x = 1, y = 1, rotation = "east"},
+      {type = "railgun_m", x = 0, y = 1, rotation = "east"},
+      {type = "railgun_m", x = 2, y = 1, rotation = "east"},
+      {type = "armor_plates", x = 1, y = 0, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 1, y = 3, rotation = "east"},
     ]
 
+[[arena]]
+name = "Mirror: battleships 2v2"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Alpha"
+    [[arena.team.ship]]
+    schematic = "battleship"
+    count = 2
+    modules = [
+      {type = "railgun_l", x = 1, y = 0, rotation = "east"},
+      {type = "railgun_m", x = 1, y = 3, rotation = "east"},
+      {type = "railgun_m", x = 3, y = 3, rotation = "east"},
+      {type = "weapon_stabilizer", x = 4, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 1, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Beta"
+    [[arena.team.ship]]
+    schematic = "battleship"
+    count = 2
+    modules = [
+      {type = "railgun_l", x = 1, y = 0, rotation = "east"},
+      {type = "railgun_m", x = 1, y = 3, rotation = "east"},
+      {type = "railgun_m", x = 3, y = 3, rotation = "east"},
+      {type = "weapon_stabilizer", x = 4, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 1, rotation = "east"},
+    ]
+
+# --- equal-threat cross-tier matchups (power-per-threat: expect near-draws) ---
+
+[[arena]]
+name = "Drone swarm vs cruisers (462 vs 467)"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Swarm"
+    [[arena.team.ship]]
+    schematic = "drone"
+    count = 44
+    modules = [
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Cruisers"
+    [[arena.team.ship]]
+    schematic = "cruiser"
+    count = 2
+    modules = [
+      {type = "railgun_m", x = 0, y = 1, rotation = "east"},
+      {type = "railgun_m", x = 2, y = 1, rotation = "east"},
+      {type = "armor_plates", x = 1, y = 0, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 1, y = 3, rotation = "east"},
+    ]
+
+[[arena]]
+name = "Frigates vs battleship (705 vs 723)"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Frigates"
+    [[arena.team.ship]]
+    schematic = "frigate"
+    count = 15
+    modules = [
+      {type = "railgun_s", x = 1, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 1, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 0, y = 1, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Battleship"
+    [[arena.team.ship]]
+    schematic = "battleship"
+    count = 1
+    modules = [
+      {type = "railgun_l", x = 1, y = 0, rotation = "east"},
+      {type = "railgun_m", x = 1, y = 3, rotation = "east"},
+      {type = "railgun_m", x = 3, y = 3, rotation = "east"},
+      {type = "weapon_stabilizer", x = 4, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 1, rotation = "east"},
+    ]
+
+[[arena]]
+name = "Destroyers vs dreadnought (1485 vs 1492)"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Destroyers"
+    [[arena.team.ship]]
+    schematic = "destroyer"
+    count = 15
+    modules = [
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+      {type = "armor_plates", x = 0, y = 1, rotation = "east"},
+      {type = "sensor_booster", x = 3, y = 1, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Dreadnought"
+    [[arena.team.ship]]
+    schematic = "dreadnought"
+    count = 1
+    modules = [
+      {type = "railgun_l", x = 0, y = 1, rotation = "east"},
+      {type = "railgun_l", x = 4, y = 1, rotation = "east"},
+      {type = "railgun_l", x = 8, y = 1, rotation = "east"},
+      {type = "armor_plates", x = 3, y = 0, rotation = "east"},
+      {type = "armor_plates", x = 5, y = 0, rotation = "east"},
+      {type = "armor_plates", x = 2, y = 4, rotation = "east"},
+      {type = "armor_plates", x = 7, y = 4, rotation = "east"},
+      {type = "railgun_s", x = 7, y = 0, rotation = "east"},
+    ]
+
+[[arena]]
+name = "Cruisers vs carrier (1401 vs 1437, carrier expected to lose)"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Cruisers"
+    [[arena.team.ship]]
+    schematic = "cruiser"
+    count = 6
+    modules = [
+      {type = "railgun_m", x = 0, y = 1, rotation = "east"},
+      {type = "railgun_m", x = 2, y = 1, rotation = "east"},
+      {type = "armor_plates", x = 1, y = 0, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 1, y = 3, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Carrier"
+    [[arena.team.ship]]
+    schematic = "carrier"
+    count = 1
+    modules = [
+      {type = "drone_hangar", x = 2, y = 0, rotation = "east"},
+      {type = "railgun_m", x = 3, y = 2, rotation = "east"},
+      {type = "railgun_m", x = 6, y = 2, rotation = "east"},
+      {type = "armor_plates", x = 0, y = 1, rotation = "east"},
+      {type = "armor_plates", x = 8, y = 1, rotation = "east"},
+      {type = "sensor_booster", x = 3, y = 4, rotation = "east"},
+    ]
+
+[[arena]]
+name = "Mixed mid vs battlecruisers (1394 vs 1418)"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Mixed"
+    [[arena.team.ship]]
+    schematic = "destroyer"
+    count = 7
+    modules = [
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+      {type = "armor_plates", x = 0, y = 1, rotation = "east"},
+      {type = "sensor_booster", x = 3, y = 1, rotation = "east"},
+    ]
+    [[arena.team.ship]]
+    schematic = "cruiser"
+    count = 3
+    modules = [
+      {type = "railgun_m", x = 0, y = 1, rotation = "east"},
+      {type = "railgun_m", x = 2, y = 1, rotation = "east"},
+      {type = "armor_plates", x = 1, y = 0, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 1, y = 3, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Battlecruisers"
+    [[arena.team.ship]]
+    schematic = "battlecruiser"
+    count = 4
+    modules = [
+      {type = "railgun_m", x = 0, y = 0, rotation = "east"},
+      {type = "railgun_m", x = 4, y = 0, rotation = "east"},
+      {type = "railgun_m", x = 2, y = 1, rotation = "east"},
+      {type = "armor_plates", x = 2, y = 3, rotation = "east"},
+      {type = "railgun_s", x = 1, y = 2, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 2, rotation = "east"},
+    ]
+
+# --- asymmetric checks ---
+
+[[arena]]
+name = "Two to one (must be decisive)"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Six"
+    [[arena.team.ship]]
+    schematic = "frigate"
+    count = 6
+    modules = [
+      {type = "railgun_s", x = 1, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 1, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 0, y = 1, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Three"
+    [[arena.team.ship]]
+    schematic = "frigate"
+    count = 3
+    modules = [
+      {type = "railgun_s", x = 1, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 1, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 0, y = 1, rotation = "east"},
+    ]
+
+[[arena]]
+name = "Armored vs glass destroyers (1188 vs 1196)"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Armored"
+    [[arena.team.ship]]
+    schematic = "destroyer"
+    count = 12
+    modules = [
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+      {type = "armor_plates", x = 0, y = 1, rotation = "east"},
+      {type = "sensor_booster", x = 3, y = 1, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Glass"
+    [[arena.team.ship]]
+    schematic = "destroyer"
+    count = 13
+    modules = [
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 1, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 3, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 4, y = 1, rotation = "east"},
+    ]
+
+[[arena]]
+name = "Repair escort vs raw numbers (444 vs 444)"
+height_tiles = 10
+player_buffer_width_tiles = 10
+contest_zone_width_tiles = 50
+enemy_buffer_width_tiles = 10
+
+  [[arena.team]]
+  name = "Escorted"
+    [[arena.team.ship]]
+    schematic = "frigate"
+    count = 8
+    modules = [
+      {type = "railgun_s", x = 1, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 1, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 0, y = 1, rotation = "east"},
+    ]
+    [[arena.team.ship]]
+    schematic = "drone"
+    count = 4
+    modules = [
+      {type = "repair_tool", x = 0, y = 0, rotation = "east"},
+    ]
+
+  [[arena.team]]
+  name = "Raw"
+    [[arena.team.ship]]
+    schematic = "frigate"
+    count = 9
+    modules = [
+      {type = "railgun_s", x = 1, y = 0, rotation = "east"},
+      {type = "railgun_s", x = 2, y = 1, rotation = "east"},
+      {type = "maneuvering_thrusters", x = 0, y = 1, rotation = "east"},
+    ]
     [[arena.team.ship]]
     schematic = "drone"
     count = 2
     modules = [
-      {type = "repair_tool",  x = 1, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
     ]
 
 [[arena]]
-name = "Stations and Ships"
-height_tiles = 60
+name = "Station assault (2 stations + 105 vs 315)"
+height_tiles = 10
 player_buffer_width_tiles = 15
 contest_zone_width_tiles = 40
 enemy_buffer_width_tiles = 15
@@ -71,9 +400,9 @@ enemy_buffer_width_tiles = 15
   name = "Fortified"
     [[arena.team.ship]]
     schematic = "drone"
-    count = 3
+    count = 10
     modules = [
-      {type = "laser_cannon_s",   x = 1, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
     ]
     [[arena.team.station]]
     type = "player_station"
@@ -90,7 +419,7 @@ enemy_buffer_width_tiles = 15
   name = "Swarm"
     [[arena.team.ship]]
     schematic = "drone"
-    count = 8
+    count = 30
     modules = [
-      {type = "laser_cannon_s",  x = 1, y = 1, rotation = "east"},
+      {type = "railgun_s", x = 0, y = 0, rotation = "east"},
     ]

bin/test/data/config/buildings.toml

@@ -83,6 +83,8 @@ id = "salvage_bay"
 cost = 25
 player_placeable = true
 construction_time_seconds = 15
+output_buffer_capacity = 20
+tooltip = "Drop-off point for salvage ships."
 surface_mask = [
   "SAA",
   "SAA>",

bin/test/data/config/modules.toml

@@ -1,6 +1,6 @@
 [[module]]
 id = "armor_plate"
-unlock_at_station_level = -1
+tooltip = "Adds a large flat bonus to hit points."
 surface_mask = ["OO"]
 materials = [{item = "iron_ingot", amount = 2}]
 production_time_seconds = 3
@@ -12,7 +12,6 @@ multiplied_hp = 1.5
 
 [[module]]
 id = "sensor_booster"
-unlock_at_station_level = -1
 surface_mask = ["O"]
 materials = [{item = "circuit_board", amount = 1}]
 production_time_seconds = 2
@@ -24,7 +23,6 @@ added_sensor_range_m = 100
 
 [[module]]
 id = "weapon_upgrade"
-unlock_at_station_level = -1
 surface_mask = ["O"]
 materials = [{item = "iron_ingot", amount = 1}, {item = "circuit_board", amount = 1}]
 production_time_seconds = 4
@@ -36,7 +34,6 @@ multiplied_damage = 1.2
 
 [[module]]
 id = "laser_cannon"
-unlock_at_station_level = -1
 surface_mask = ["O"]
 materials = [{item = "iron_ingot", amount = 1}]
 production_time_seconds = 5
@@ -50,7 +47,6 @@ attack_rate_hz = 2.0
 
 [[module]]
 id = "salvager"
-unlock_at_station_level = -1
 surface_mask = ["OO"]
 materials = [{item = "iron_ingot", amount = 2}]
 production_time_seconds = 5
@@ -64,7 +60,6 @@ collection_rate_hz = 0.5
 
 [[module]]
 id = "repair_tool"
-unlock_at_station_level = -1
 surface_mask = ["O"]
 materials = [{item = "circuit_board", amount = 2}]
 production_time_seconds = 5
@@ -78,7 +73,6 @@ repair_range_m = 800
 
 [[module]]
 id = "weapon_primer"
-unlock_at_station_level = -1
 surface_mask = ["O"]
 materials = [{item = "iron_ingot", amount = 1}]
 production_time_seconds = 4
@@ -90,7 +84,6 @@ multiplied_attack_rate_hz = 1.2
 
 [[module]]
 id = "weapon_stabilizer"
-unlock_at_station_level = -1
 surface_mask = ["O"]
 materials = [{item = "iron_ingot", amount = 1}]
 production_time_seconds = 4
@@ -103,7 +96,6 @@ multiplied_attack_rate_hz = 0.8
 
 [[module]]
 id = "afterburner"
-unlock_at_station_level = -1
 surface_mask = ["O"]
 materials = [{item = "iron_ingot", amount = 1}]
 production_time_seconds = 2
@@ -116,7 +108,6 @@ added_main_acceleration_mpss = 60
 
 [[module]]
 id = "maneuvering_thrusters"
-unlock_at_station_level = -1
 surface_mask = ["O"]
 materials = [{item = "iron_ingot", amount = 1}]
 production_time_seconds = 2

bin/test/data/config/recipes.toml

@@ -43,7 +43,7 @@ duration_seconds = 4.0
 [[recipe]]
 id = "premium_circuit"
 building = "assembler"
-unlock_at_station_level = -1
+unlocked_at_start = true
 inputs = [{item = "circuit_board", amount = 1}]
 outputs = [{item = "premium_circuit", amount = 1}]
 duration_seconds = 8.0
@@ -51,7 +51,6 @@ duration_seconds = 8.0
 [[recipe]]
 id = "quick_circuit"
 building = "assembler"
-unlock_at_station_level = 0
 inputs = [{item = "copper_ingot", amount = 3}]
 outputs = [{item = "circuit_board", amount = 1}]
 duration_seconds = 3.0
@@ -59,7 +58,6 @@ duration_seconds = 3.0
 [[recipe]]
 id = "advanced_circuit"
 building = "assembler"
-unlock_at_station_level = 1
 inputs = [{item = "iron_ingot", amount = 5}]
 outputs = [{item = "circuit_board", amount = 1}]
 duration_seconds = 6.0
@@ -67,7 +65,6 @@ duration_seconds = 6.0
 [[recipe]]
 id = "exotic_alloy"
 building = "assembler"
-unlock_at_station_level = 0
 inputs = [{item = "exotic_ore", amount = 2}]
 outputs = [{item = "exotic_alloy", amount = 1}]
 duration_seconds = 10.0
@@ -92,3 +89,60 @@ duration_seconds = 3.0
   item = "advanced_alloy"
   amount = 1
   probability = 0.1
+
+# -------------------------------------------------------------------
+# Extra recipes for ThreatCostCalculator unit tests (fixes 6-9)
+# -------------------------------------------------------------------
+
+# Fix 6: scrap-consuming smelter recipe for iron_ingot. Because iron_ingot
+# already has a scrap-free smelter recipe above, this recipe must be excluded
+# from iron_ingot's threat computation.
+[[recipe]]
+id = "scrap_iron"
+building = "smelter"
+inputs = [{item = "scrap", amount = 1}]
+outputs = [{item = "iron_ingot", amount = 1}]
+duration_seconds = 1.0
+
+# Fix 7: a recipe that produces 2 items per cycle. Per-unit threat must
+# divide by the output amount.
+# dual_wire: (duration=3.0 + iron_ore(1.0)*1) / 2 = 4.0 / 2 = 2.0 per unit.
+[[recipe]]
+id = "dual_wire"
+building = "assembler"
+inputs = [{item = "iron_ore", amount = 1}]
+outputs = [{item = "dual_wire", amount = 2}]
+duration_seconds = 3.0
+
+# Fix 8: an item downstream of a reprocessing-only item (advanced_alloy).
+# advanced_alloy is resolved only by the reprocessing pass; downstream_product
+# can only resolve in a non-reprocessing pass that runs AFTER the reprocessing
+# pass, requiring proper fixpoint iteration.
+# downstream_product: 2.0 + advanced_alloy(80.0)*1 = 82.0
+[[recipe]]
+id = "downstream_product"
+building = "assembler"
+inputs = [{item = "advanced_alloy", amount = 1}]
+outputs = [{item = "downstream_product", amount = 1}]
+duration_seconds = 2.0
+
+# Fix 9: two recipes producing the same staggered_item. The cheap recipe
+# resolves before circuit_board is known; the expensive one requires
+# circuit_board. The item must be committed only once BOTH are computable,
+# so the result is max(cheap, expensive).
+# staggered_item_cheap:  1.0 + iron_ore(1.0)*1  =  2.0  (resolves early)
+# staggered_item_expensive: 1.0 + circuit_board(28.0)*1 = 29.0 (resolves later)
+# expected: max = 29.0
+[[recipe]]
+id = "staggered_item_cheap"
+building = "assembler"
+inputs = [{item = "iron_ore", amount = 1}]
+outputs = [{item = "staggered_item", amount = 1}]
+duration_seconds = 1.0
+
+[[recipe]]
+id = "staggered_item_expensive"
+building = "assembler"
+inputs = [{item = "circuit_board", amount = 1}]
+outputs = [{item = "staggered_item", amount = 1}]
+duration_seconds = 1.0

bin/test/data/config/ships.toml

@@ -1,6 +1,5 @@
 [[ship]]
 id = "interceptor"
-unlock_at_station_level = -1
 layout = ["XOX", "OOO", "XOX"]
 default_modules = [{type = "laser_cannon", x = 1, y = 1, rotation = "east"}]
 
@@ -24,7 +23,6 @@ sensor_range_m = 2000
 
 [[ship]]
 id = "destroyer"
-unlock_at_station_level = -1
 layout = ["XOOX", "OOOO", "XOOX"]
 default_modules = [{type = "laser_cannon", x = 1, y = 1, rotation = "east"}]
 
@@ -48,7 +46,6 @@ sensor_range_m = 3000
 
 [[ship]]
 id = "salvage_ship"
-unlock_at_station_level = -1
 layout = ["OOO", "OOO"]
 
 [ship.schematic]
@@ -71,7 +68,6 @@ sensor_range_m = 2500
 
 [[ship]]
 id = "repair_ship"
-unlock_at_station_level = 0
 layout = ["XOX", "OOO", "XOX"]
 
 [ship.schematic]

bin/test/data/config/unlocks.toml

@@ -0,0 +1,21 @@
+# Unlock groups for the test config (REQ-LOCK-EXPLICIT). Mirrors the previous
+# per-item gating: repair_ship, quick_circuit, advanced_circuit start locked and
+# are awarded via defence station drops. exotic_alloy is intentionally NOT here:
+# it stays implicitly gated (its output/inputs are unreachable), so it is never
+# unlocked. premium_circuit uses unlocked_at_start in recipes.toml. Everything
+# else (interceptor, destroyer, salvage_ship, all modules) starts unlocked.
+
+[[unlock]]
+id = "repair_ship"
+station_level = 0
+ships = ["repair_ship"]
+
+[[unlock]]
+id = "quick_circuit"
+station_level = 0
+recipes = ["quick_circuit"]
+
+[[unlock]]
+id = "advanced_circuit"
+station_level = 1
+recipes = ["advanced_circuit"]

bin/test/data/config/world.toml

@@ -1,8 +1,9 @@
 [world]
 height_tiles = 60
 refund_percentage = 75
+deconstruction_time_seconds = 0.1
 starting_building_blocks = 100
-scrap_despawn_seconds = 30
+debris_despawn_seconds = 30
 scrap_per_threat = 1.0
 tile_size_m = 10
 belt_speed_mps = 20
@@ -10,6 +11,8 @@ tunnel_max_distance_tiles = 10
 departure_interval_seconds = 20
 orbit_factor = 0.8
 rally_orbit_radius_tiles = 5.0
+building_blocks_tooltip = "Spend building blocks to build; deliver them to the HQ to gain more."
+artifact_tooltip = "Choose the artifact reward when destroying enemy stations; collect enough to win."
 
 [regions]
 asteroid_width_tiles = 40
@@ -17,9 +20,14 @@ player_buffer_width_tiles = 10
 contest_zone_width_tiles = 30
 enemy_buffer_width_tiles = 15
 
+[scroll]
+pan_speed_slow_tiles_per_second = 8.0
+pan_speed_fast_tiles_per_second = 24.0
+pan_ramp_band_width_tiles = 16
+
 [expansion]
 columns_per_expansion_tiles = 10
-cost_building_blocks = 200
+cost_building_blocks_formula = "400 * 2^x"
 
 [push]
 push_expand_columns_tiles = 20

cmake/version.cmake

@@ -0,0 +1,60 @@
+# simple check for a git repo
+if(EXISTS "${CMAKE_SOURCE_DIR}/.git")
+	find_package(Git)
+
+    execute_process(
+        COMMAND ${GIT_EXECUTABLE} rev-parse --abbrev-ref HEAD
+        WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
+        OUTPUT_VARIABLE GIT_BRANCH
+        OUTPUT_STRIP_TRAILING_WHITESPACE
+    )
+
+    execute_process(
+        COMMAND ${GIT_EXECUTABLE} log -1 --format=%h
+        WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
+        OUTPUT_VARIABLE GIT_COMMIT_HASH
+        OUTPUT_STRIP_TRAILING_WHITESPACE
+    )
+
+    execute_process(
+        COMMAND ${GIT_EXECUTABLE} log -1 --format=%ci
+        WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
+        OUTPUT_VARIABLE GIT_COMMIT_TIME
+        OUTPUT_STRIP_TRAILING_WHITESPACE
+    )
+
+    execute_process(
+        COMMAND ${GIT_EXECUTABLE} describe --long --match "[0-9]*" HEAD
+        WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
+        OUTPUT_VARIABLE GIT_VERSION_NUMBER
+        OUTPUT_STRIP_TRAILING_WHITESPACE
+    )
+    string(REGEX REPLACE "^([0-9]+)\\..*" "\\1" VERSION_MAJOR "${GIT_VERSION_NUMBER}")
+    string(REGEX REPLACE "^[0-9]+\\.([0-9]+).*" "\\1" VERSION_MINOR "${GIT_VERSION_NUMBER}")
+    string(REGEX REPLACE "^[0-9]+\\.[0-9]+\\.([0-9]+).*" "\\1" VERSION_PATCH "${GIT_VERSION_NUMBER}")
+    string(REGEX REPLACE "^[0-9]+\\.[0-9]+\\.[0-9]+-([0-9]+).*" "\\1" VERSION_COMMIT "${GIT_VERSION_NUMBER}")
+
+else(EXISTS "${CMAKE_SOURCE_DIR}/.git")
+    set(GIT_BRANCH "")
+    set(GIT_COMMIT_HASH "")
+    set(GIT_VERSION_NUMBER "")
+    set(VERSION_MAJOR "0")
+    set(VERSION_MINOR "0")
+    set(VERSION_PATCH "0")
+    set(VERSION_COMMIT "0")
+    set(BUILD_TYPE "")
+
+endif(EXISTS "${CMAKE_SOURCE_DIR}/.git")
+
+set(VERSION_STRING "${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_PATCH}.${VERSION_COMMIT}")
+
+message(STATUS "Version: ${VERSION_STRING}")
+
+# message(STATUS "Git current branch: ${GIT_BRANCH}")
+# message(STATUS "Git version number: " ${GIT_VERSION_NUMBER} )
+# message(STATUS "Git commit hash: ${GIT_COMMIT_HASH}")
+# message(STATUS "Git commit time: ${GIT_COMMIT_TIME}")
+# message(STATUS "Version major: ${VERSION_MAJOR}")
+# message(STATUS "Version minor: ${VERSION_MINOR}")
+# message(STATUS "Version patch: ${VERSION_PATCH}")
+# message(STATUS "Version commit: ${VERSION_COMMIT}")

cmake/version.rc.in

@@ -0,0 +1,35 @@
+// Windows version resource. Generated by CMake via configure_file() from this
+// template; @VAR@ placeholders are filled from cmake/version.cmake (version
+// numbers) and the product identity variables in the top-level CMakeLists.txt.
+// Shows up on the executable's Details tab (right-click -> Properties).
+
+#include <windows.h>
+
+VS_VERSION_INFO VERSIONINFO
+    FILEVERSION     @VERSION_MAJOR@,@VERSION_MINOR@,@VERSION_PATCH@,@VERSION_COMMIT@
+    PRODUCTVERSION  @VERSION_MAJOR@,@VERSION_MINOR@,@VERSION_PATCH@,@VERSION_COMMIT@
+    FILEFLAGSMASK   VS_FFI_FILEFLAGSMASK
+    FILEFLAGS       0x0L
+    FILEOS          VOS_NT_WINDOWS32
+    FILETYPE        VFT_APP
+    FILESUBTYPE     VFT2_UNKNOWN
+BEGIN
+    BLOCK "StringFileInfo"
+    BEGIN
+        BLOCK "040904b0"                       // US English (0x0409), Unicode (0x04b0)
+        BEGIN
+            VALUE "CompanyName",      "@PRODUCT_COMPANY@"
+            VALUE "FileDescription",  "@PRODUCT_DISPLAY_NAME@"
+            VALUE "FileVersion",      "@VERSION_STRING@"
+            VALUE "InternalName",     "@PRODUCT_NAME@"
+            VALUE "OriginalFilename", "@PRODUCT_NAME@.exe"
+            VALUE "ProductName",      "@PRODUCT_DISPLAY_NAME@"
+            VALUE "ProductVersion",   "@VERSION_STRING@"
+            VALUE "LegalCopyright",   "@PRODUCT_COPYRIGHT@"
+        END
+    END
+    BLOCK "VarFileInfo"
+    BEGIN
+        VALUE "Translation", 0x409, 1200       // 0x409 = en-US, 1200 = Unicode code page
+    END
+END

docs/architecture.md

@@ -15,7 +15,7 @@ This document captures the architectural decisions for the project. It is a comp
 A strict separation between the game simulation and the Qt Widgets UI.
 
 - The **simulation** is a pure C++ library that depends only on Qt Core and Qt Gui (QPoint, QVector2D, QRect, etc., as required by the coding guidelines), toml++, and tinyexpr. It contains no QtWidgets, no painting, and no QApplication. Note: in Qt 5, vector math types such as QVector2D live in Qt::Gui rather than Qt::Core, so the lib links both.
-- The **UI** reads simulation state and renders it. It owns all widgets, painting, and input handling, and drives the simulation via a small command interface (place building, demolish, clear belt tiles, change recipe, set game speed, etc.).
+- The **UI** reads simulation state and renders it. It owns all widgets, painting, and input handling, and drives the simulation via a small command interface (place building, deconstruct, clear belt tiles, change recipe, set game speed, etc.).
 
 This split is enforced at the CMake target level (see below). Tests link only against the simulation library and run without a display server.
 
@@ -25,7 +25,7 @@ The simulation advances in discrete ticks. All game quantities — production ti
 
 - Tick rate: fixed at 30 Hz; `tickDurationMs = 1000 / 30 ≈ 33.33`.
 - Ticks are driven by an accumulator that is independent of the render rate. Each render frame, the driver adds `elapsedWallMs × gameSpeedMultiplier` to an accumulator and flushes one `tick()` per `tickDurationMs` of accumulated time (so multiple sim ticks may run between frames at high speeds, or a frame may run no ticks at low speeds). `gameSpeedMultiplier` ∈ {0, 0.5, 1, 2, 4} per REQ-UI-SPEED; 0× freezes the accumulator (pause). The concrete driver lives in the Rendering section.
-- Config-level durations given in seconds (recipe durations, wave gap ranges, scrap despawn, etc.) are converted to ticks at config-load time.
+- Config-level durations given in seconds (recipe durations, wave gap ranges, debris despawn, etc.) are converted to ticks at config-load time.
 
 Consequences: determinism, replayability, and the time-scale feature fall out for free. The simulation advances the same number of ticks over the same amount of game-time regardless of whether the game renders at 60 FPS, 30 FPS, or a stuttery mix.
 
@@ -44,7 +44,7 @@ See REQ-GW-COORDS for the authoritative tile-coordinate convention. This section
 
 - Tile coordinates are `QPoint(x, y)`. Origin `(0, 0)` is the first space tile (just right of the asteroid's right edge at game start). X grows right; Y grows down.
 - Asteroid tiles have `x < 0`. Asteroid left-expansions add tiles at increasingly negative X; the origin never shifts, so existing tile coordinates remain stable across expansions.
-- Continuous world positions (ship centers, scrap drops, projectiles) use `QVector2D` in tile units — one tile = 1.0 world unit. A ship center at `QVector2D(-3.5, 4.0)` sits at the center of the tile 3.5 tiles left of the asteroid's right edge and 4 tiles down from the top.
+- Continuous world positions (ship centers, debris, projectiles) use `QVector2D` in tile units — one tile = 1.0 world unit. A ship center at `QVector2D(-3.5, 4.0)` sits at the center of the tile 3.5 tiles left of the asteroid's right edge and 4 tiles down from the top.
 - Rendering multiplies world units by the tile size in pixels (20) at draw time.
 - Ship position always refers to the ship's center — this is the point used for sensor, attack-range, and hit-detection checks.
 
@@ -52,7 +52,7 @@ See REQ-GW-COORDS for the authoritative tile-coordinate convention. This section
 
 Simulation types shared across subsystems:
 
-- `EntityId` — strictly increasing integer handle, allocated centrally by the simulation. Assigned to every targetable entity: ships, scrap drops, **and** buildings (including HQ and defence stations). Buildings additionally retain their anchor tile for spatial lookups and placement; the `EntityId` is the canonical reference used by ship-component target fields (`Weapon.currentTarget`, `RepairTool.currentTarget`, `AttackBehavior.currentTarget`, etc.), so a combat ship can target either another ship or a defence station uniformly.
+- `EntityId` — strictly increasing integer handle, allocated centrally by the simulation. Assigned to every targetable entity: ships, debris, **and** buildings (including HQ and defence stations). Buildings additionally retain their anchor tile for spatial lookups and placement; the `EntityId` is the canonical reference used by ship-component target fields (`Weapon.currentTarget`, `RepairTool.currentTarget`, `AttackBehavior.currentTarget`, etc.), so a combat ship can target either another ship or a defence station uniformly.
 - `Rotation` — enum `{ North, East, South, West }`. The rotation applied to a building's surface_mask when placed.
 - `BuildingType` — enum covering every building type in requirements.md (Miner, Smelter, Assembler, ReprocessingPlant, Shipyard, SalvageBay, Belt, Splitter, Hq, PlayerDefenceStation, EnemyDefenceStation). `Belt` and `Splitter` share the enum for cost, construction, placement, and `visuals.toml` lookup, but their runtime data lives inside the belt subsystem rather than in `Building` instances (see Belt Subsystem).
 - `ItemType` — tagged id of every transportable material (ores, ingots, intermediates, building_blocks, scrap).
@@ -93,9 +93,15 @@ Schematic drops: when an enemy station set is destroyed, the simulation generate
 
 ### UI Events
 
-All UI interactions — building selection, builder/blueprint mode transitions, speed changes, demolish mode, escape menu, layout dialog requests — are communicated via EventManager events rather than Qt signals/slots. Each event is a small struct inheriting `Event` (e.g., `SelectionChangedEvent`, `BuildingTypeSelectedEvent`, `SpeedChangeRequestedEvent`). Widgets register as `CombinedEventHandler` for the events they care about and emit events via `EventManager::sendEventImmediately()`.
+All UI interactions — building selection, builder/blueprint mode transitions, speed changes, deconstruct mode, escape menu, layout dialog requests — are communicated via EventManager events rather than Qt signals/slots. Each event is a small struct inheriting `Event` (e.g., `SelectionChangedEvent`, `BuildingTypeSelectedEvent`, `SpeedChangeRequestedEvent`). Widgets register as `CombinedEventHandler` for the events they care about and emit events via `EventManager::sendEventImmediately()`.
 
-Bidirectional interactions use separate request/notification event types to avoid infinite recursion (e.g., `ExitBuilderModeRequestedEvent` from `BuildButtonGrid` → `GameWorldView`, vs. `BuilderModeExitedEvent` from `GameWorldView` → `BuildButtonGrid`).
+Bidirectional interactions use separate request/notification event types to avoid infinite recursion (e.g., `ExitBuilderModeRequestedEvent` from `BuildButtonBar` → `GameWorldView`, vs. `BuilderModeExitedEvent` from `GameWorldView` → `BuildButtonBar`).
+
+### Reading Simulation State
+
+The simulation is the single source of truth for every game value (building block stock, expansion cost, threat level, tick, etc.). A UI widget that needs such a value holds the `Simulation*` it was constructed with and **pulls the value on demand** via the corresponding getter (e.g., `m_sim->getBuildingBlocksStock()`), rather than caching its own copy.
+
+State-change events (e.g., `BuildingBlocksChangedEvent`) are treated as *refresh signals*, not as carriers of truth: a widget subscribes to the event to learn *when* the value changed and then re-reads it from the simulation to learn *what* it now is. The value carried in the event payload is not authoritative and should not be stored. This keeps a single copy of each value and avoids stale-cache bugs (a widget acting on a value that has since moved on because nothing refreshed its local copy).
 
 ## Tick Order
 
@@ -109,38 +115,83 @@ Within a single simulation tick, subsystems run in this fixed order. The order i
 6. **Belt tick** — advance items along belt tiles; apply splitter routing (REQ-BLD-SPLITTER).
 7. **Ship behavior systems** — clear `MovementIntent` on each ship, then the `AiSystem` runs three batched phases: every behavior **evaluator** scores its behavior and sets its target data; a **selection** pass records the highest-scoring behavior per ship in `SelectedBehaviorComponent`; each behavior **executor** runs for the winner, writing `MovementIntent` and preferred module targets. The module systems then perform world mutation: `SalvagerSystem` (scrap collection/delivery) and `RepairSystem` (healing). See Movement Arbitration.
 8. **Combat resolution** — ships and defence stations validate/acquire targets, fire, apply damage; queue deaths. Each fire appends a `BeamFiredEvent` to the sim's beam-fired-event queue (REQ-SHP-FIRING-BEAM). The repair and salvage module systems (tick step 7d) append their own `BeamFiredEvent`s to the same queue when they start a cycle.
-9. **Deaths & loot** — process queued deaths: drop scrap (REQ-RES-SCRAP-DROP); if a full enemy-defence-station set was destroyed this tick, generate up to 3 schematic choice options (REQ-DEF-SCHEMATIC-DROP) stored as pending state for the UI to present; remove entities.
+9. **Deaths & loot** — process queued deaths: drop debris (REQ-RES-DEBRIS-DROP); if a full enemy-defence-station set was destroyed this tick, generate up to 3 schematic choice options (REQ-DEF-SCHEMATIC-DROP) stored as pending state for the UI to present; remove entities.
 10. **`tickMovement`** — advance ship positions based on final `MovementIntent`.
-11. **Scrap despawn** — decrement scrap timers; remove expired scrap (REQ-RES-SCRAP-DROP).
+11. **Debris despawn** — decrement debris timers; remove expired debris (REQ-RES-DEBRIS-DROP).
 
 ## CMake Target Layout
 
 Three product targets plus tests:
 
 - `lib/` — simulation + config. Depends on Qt Core + Qt Gui, toml++, tinyexpr. No QtWidgets.
-- `ui/` — QtWidgets + `QOpenGLWidget` code: header bar, game world view, selected building panel, build button grid. Depends on `lib` and on Qt's OpenGL widgets module.
+- `ui/` — QtWidgets + `QOpenGLWidget` code: header bar, game world view, selection panel, build button bar, controls panel. Depends on `lib` and on Qt's OpenGL widgets module.
+  - `ui/selection/` — the selection panel's contents. `SelectionPanel` itself only arbitrates between the two selection categories, picks a card from the catalog (`SelectionContentFactory`), and hosts one at a time; each kind of selection has its own `SelectionContent` subclass assembled from shared parts (REQ-UI-SELECTION-CARD, REQ-UI-SELECTION-CONTENT).
 - `app/` — thin `main()` that creates the simulation, the UI, and wires them together. Depends on `ui`.
 - `tests/` — Catch2 tests. Links only against `lib`.
 
 Directory discipline inside `lib/` keeps the internal sim/config seam clear; sim code must not reach into config parsing and vice versa.
 
+## Player Input
+
+Every player control is declared once, in `lib/core/ControlAction.h`, and read by three consumers that must never disagree about it:
+
+* **`ControlsPanel`** asks which actions apply and draws a row per action (REQ-UI-CONTROLS-CONTENT).
+* **`InputMapper`** resolves a key press to an action and fires the event that action stands for.
+* **`GameWorldView`** resolves a mouse gesture to an action and runs the branch that carries it out.
+
+The file declares; it never performs. It holds no simulation access, fires no events, and names nothing — display strings live in `ui/ControlActionText.h`, which renders each badge from the binding the resolver actually matches, so a chip cannot claim a key that does nothing. What an action *does* stays in the widget that always did it: the drag state machines, hit-testing, and command enqueuing were not moved.
+
+Three invariants are easy to break here:
+
+* **Do not add a shortcut straight to `InputMapper`'s switch or `mousePressEvent`'s branches.** Add the action and its binding to the table; the handler switches on the resolved action. A binding added directly is invisible to the panel, which is the drift the table exists to prevent. (Build hotkeys and `F3`/`F4` are deliberate exceptions, documented in the header and in REQ-UI-CONTROLS-ACCURACY.)
+* **Availability and display are different questions.** An action can be live in a context the panel does not advertise it in — `Ctrl`+click with an empty selection is the standing example. `isControlActionAvailable` answers the first, the per-context row lists answer the second, and `ControlActionTest` asserts the pairing that matters: every row's bindings resolve back to that row's action.
+* **Gesture state is shared, not owned by an action.** Whether a belt drag is in progress decides what the right mouse button means, so it lives on `BuildModeController` where the resolver can see it — as does the hovered-transfer flag. `m_boxSelecting` is likewise one gesture serving two actions (box select and deconstruct area).
+
+`ControlContext` is a plain snapshot rather than references to the live controllers, which is what keeps the rules testable without a world and stops an action reaching into the simulation: if a rule needs a fact, the fact is named in the struct and the caller supplies it. When bindings become player-configurable, only the binding tables in `ControlAction.cpp` turn from hard-coded data into loaded data.
+
 ## Belt Subsystem
 
 Belts and splitters are their own specialized subsystem. Belt items are **not** entities — they are transient data flowing through the belt representation. They do not have identities that persist across ticks.
 
 ### Public Interface
 
-Narrow and representation-agnostic:
+`BeltSystem.h` is authoritative. The surface is wider than the original design sketch — 15 public methods in five groups, not the 5-method port interface this section used to describe:
 
 ```cpp
 class BeltSystem {
 public:
-    bool tryPutItem(Port port, Item item);
-    std::optional<Item> tryTakeItem(Port port);
+    // Placement — belts/splitters/tunnels are Buildings for cost and
+    // construction, so BuildingSystem registers and unregisters their tiles.
+    void placeBelt(QPoint tile, Rotation direction);
+    void placeTunnelEntry(QPoint tile, Rotation direction, int maxDistance);
+    void placeTunnelExit(QPoint tile, Rotation direction);
+    void placeSplitter(QPoint tile, Rotation outputA, Rotation outputB);
+    void removeTile(QPoint tile);
+
+    // Splitter filter configuration (REQ-BLD-SPLITTER). A splitter's filters
+    // live here, not on Building, so callers that re-register a tile must
+    // carry them across (see BuildingSystem::reregisterBeltTile).
+    void setSplitterFilters(QPoint tile, const std::vector<ItemType>& filterA,
+                                         const std::vector<ItemType>& filterB);
+    std::optional<SplitterInfo> getSplitterInfo(QPoint tile) const;
+
+    // Port interface (buildings <-> belts)
+    bool tryPutItem(QPoint tile, Item item, Rotation fromDir = Rotation::West);
+    std::optional<Item>     tryTakeItem(Port port);
+    std::optional<ItemType> peekItem(Port port) const;
+    double getProgressPerTick_tpt() const;   // shared so building output items
+                                             // travel at belt speed (REQ-MAT-OUTPUT-EMERGE)
+
+    // Maintenance
     void clearTiles(const std::vector<QPoint>& tiles);   // REQ-UI-BELT-CLEAR
     void tick();
+
+    // Rendering
     void forEachVisualItem(QRect viewportTiles,
                            std::function<void(VisualItem)> visit) const;
+
+    // Determinism (docs/replay_design.md)
+    void appendChecksum(Hasher& hasher) const;
 };
 
 struct VisualItem {
@@ -149,12 +200,12 @@ struct VisualItem {
 };
 ```
 
-Buildings interact with belts only through port-level push and pull. Rendering reads only through `forEachVisualItem`. No other system ever asks "what is on tile X".
+Item *transport* is still reached only through push and pull: `tryPutItem` / `tryTakeItem` move items, `peekItem` reveals the leading item's type but never an identity, and rendering reads only through `forEachVisualItem`. The growth is in tile **topology** — placement, removal and splitter filters — which `BuildingSystem` drives because belts are `Building`s for cost, construction and deconstruction. That coupling is real and is not going away.
 
 ### Implementation Strategy
 
 - v1: per-tile representation. Each belt tile stores up to 2 items with a progress value in `[0, 1]` along the tile's belt direction. Sufficient for the scale this game targets.
-- v2 (optional, only if v1 profiles poorly): Factorio-style belt-segment compression. Because the public interface never exposes tile-level item identity, migration is internal to the subsystem.
+- v2 (optional, only if v1 profiles poorly): Factorio-style belt-segment compression. The migration argument still holds for the item representation, since no method exposes tile-level item identity — but a v2 would have to keep the placement and splitter-filter methods working per tile, which is a stronger constraint than this section originally implied.
 
 ### Rendering Note
 
@@ -187,20 +238,21 @@ struct Building {
 - Belts and splitters are separate types owned by the belt subsystem, not general `Building` instances.
 - No ECS for buildings. A miner is never also an assembler; there is no composition benefit to decomposing buildings into components.
 
-## Scrap
+## Debris
 
-Scrap is the only non-ship, non-building entity in the simulation:
+Debris — the salvageable object dropped by destroyed ships and defence stations — is the
+only non-ship, non-building entity in the simulation. Each piece carries a scrap amount:
 
 ```cpp
-struct Scrap {
+struct Debris {
     EntityId id;
     QVector2D position;     // world units, tile-fractional; ship-center convention
-    int amount;
-    Tick despawnAt;         // absolute tick at which the scrap is removed
+    int amount;             // scrap the piece still holds
+    Tick despawnAt;         // absolute tick at which the debris is removed
 };
 ```
 
-Created in tick step 9 (Deaths & loot) per REQ-RES-SCRAP-DROP, consumed by salvage ships in tick step 7 (ScrapCollector), and removed in tick step 11 when the current tick reaches `despawnAt`.
+Created in tick step 9 (Deaths & loot) per REQ-RES-DEBRIS-DROP, drained one scrap per cycle by salvage ships in tick step 7 (SalvagerSystem), and removed in tick step 11 when the current tick reaches `despawnAt`.
 
 ## Ships
 
@@ -228,7 +280,7 @@ struct RetreatBehavior      { float retreatHpFraction; QVector2D retreatPoint;
 struct AttackBehavior       { std::optional<EntityId> currentTarget; float score; };
 struct RepairBehavior       { std::optional<EntityId> currentTarget;
                               float maxRepairRange_tiles; float score; };
-struct SalvageScrapBehavior { std::optional<QVector2D> scrapTarget;
+struct SalvageScrapBehavior { std::optional<QVector2D> debrisTarget;
                               float maxCollectionRange_tiles; float score; };
 struct DeliverScrapBehavior { BuildingId deliveryBay; float score; };
 struct SelectedBehaviorComponent { BehaviorKind winner; float bestScore; };     // selection result
@@ -296,7 +348,11 @@ Buildings and the belt subsystem stay outside any entity model regardless of wha
 
 ## Rendering
 
-The game world is rendered by a single `GameWorldView` widget that inherits `QOpenGLWidget` and uses `QPainter` for all drawing. This gives the same imperative paint API as a plain `QWidget` with GPU acceleration, comfortably handling the expected scale (hundreds of ships, thousands of belt items) without blocking the main thread on CPU rasterization.
+The game world is drawn into a single `GameWorldView` widget that inherits `QOpenGLWidget` and uses `QPainter` for all drawing. This gives the same imperative paint API as a plain `QWidget` with GPU acceleration, comfortably handling the expected scale (hundreds of ships, thousands of belt items) without blocking the main thread on CPU rasterization.
+
+The drawing itself lives in `WorldRenderer`, not in the widget. `paintGL` is a call sequence: build the frame's `WorldCoordinates`, hand the renderer a `WorldRenderFrame`, then draw the screen-anchored chrome. The split is the world-space / screen-space line, and it is exact: the renderer draws everything positioned in tiles, while everything positioned in pixels — the pause and deconstruct vignettes, the replay overlay, the debug stats panel — stays with the widget. A useful consequence is that the renderer draws no translatable text at all (its text is config-driven glyphs, ASCII port arrows, and numbers), so it needs no `tr()` and no tie to the meta-object system.
+
+`WorldRenderFrame` is what makes the renderer independent of the widget. The renderer reads the simulation directly, but everything else it draws is interaction state the widget owns — the selection, the active build mode, live beams, the box-select rectangle. Those are gathered into the frame each `paintGL` and passed by reference, so the renderer keeps no copy that a later click could invalidate. The renderer knows nothing about input: the widget resolves clicks and hit-tests, and the renderer only draws the result.
 
 ### Render Loop
 
@@ -319,14 +375,16 @@ Sim and UI run on the same thread for v1. `paintEvent` reads sim state directly
 4. **Scrap** — glyphs at world positions.
 5. **Ships** — colored arrows oriented by velocity; color keyed to role (player combat / salvage / repair / enemy).
 6. **Laser beams** — lines derived from live `BeamFiredEvent`s kept by the renderer for 0.3 s, colored per `BeamKind` (weapon/repair/salvage) (REQ-SHP-FIRING-BEAM).
-7. **Build overlays** — ghost in builder mode (REQ-BLD-GHOST), demolish-mode tint, tile highlight under cursor, box-drag selection rectangle.
+7. **Build overlays** — ghost in builder mode (REQ-BLD-GHOST), deconstruct-mode tint, tile highlight under cursor, box-drag selection rectangle.
 8. **Screen-space UI** — screen-anchored elements, drawn after resetting the world-space transform.
 
 ### Coordinates and Scrolling
 
-- `GameWorldView` holds a continuous `scrollXTiles` (float). A / D input pans this smoothly (REQ-UI-SCROLL).
-- At the start of `paintEvent`, a single `painter.translate(-scrollXTiles * tilePx, 0)` maps world tile units into widget pixels (`tilePx = 20`, per REQ-GW-TILE-SIZE).
-- Mouse input converts the other way: `worldX = mouseX / tilePx + scrollXTiles`; apply `floor` for a tile. Asteroid tiles (`x < 0`) need no special casing — they share the coordinate system with space tiles.
+- The horizontal view position lives in `WorldCamera` (`lib/core/`) as a continuous view-center X in tiles. A / D input pans it smoothly (REQ-UI-SCROLL) at a position-dependent speed (REQ-UI-SCROLL-SPEED). The camera works purely in world units — tiles and tiles/second, never pixels — which is what keeps it independent of `WorldCoordinates`; the two meet only where `GameWorldView` feeds `getViewCenterXTiles()` into the transform.
+- The camera takes no simulation dependency. Its pan limits move with asteroid expansion and with pushes, so `GameWorldView` reads them from the sim each frame and passes them in as `ScrollBounds`; the camera clamps on every `advance()`, not only when panning, so the view follows the bounds inward when they shrink. Pan *intent* is likewise passed in as a `PanDirection` rather than read from key state, so the camera is unaffected if controls later become rebindable. Both properties are what make it a plain value with unit tests (`WorldCameraTest`) — notably over the two-ramp pan-speed curve, whose overlapping-band and zero-width-band cases are otherwise easy to break unnoticed.
+- The world↔widget transform itself lives in `WorldCoordinates` (`lib/core/`), not in the view. It is an immutable value, built through one of two named factories that differ only in how `tilePx` and the left edge are derived; everything downstream is shared. `scrolling(...)` is the game world: `tilePx` makes the world height fill the viewport (REQ-GW-TILE-SIZE) and the view pans horizontally. `fitToWorld(...)` is the balancing tool's arena: a fixed world shown whole, so `tilePx` is the tighter of the two axis fits and there is no scroll. Being a plain value with no Qt Widgets dependency, it is unit-tested (`WorldCoordinatesTest`) even though the widgets around it are not.
+- `GameWorldView::getCoordinates()` and `ArenaView::getCoordinates()` each build one per frame in `paintGL` and per event in the mouse handlers, and pass it down: every world-space `draw<X>` takes a `const WorldCoordinates&`, while the screen-space draws (vignette borders, replay overlay, debug text) take none. The snapshot is deliberately never cached in a member — a resize or a scroll would silently invalidate it.
+- Conversions are per-call arithmetic rather than a `painter.translate`, because hit-testing needs the inverse (`widgetToWorld` / `widgetToTile`, flooring for a tile) as often as drawing needs the forward direction. Asteroid tiles (`x < 0`) need no special casing — they share the coordinate system with space tiles, which is why the flooring must not be truncation.
 
 ### Culling
 
@@ -336,6 +394,8 @@ The renderer iterates only entities and tiles whose world X lies within the visi
 
 Shapes are hardcoded in the renderer — a building is a rectangle per footprint tile, a ship is an oriented arrow/triangle, a belt item is a 10×10 square, scrap is a small circle, a beam is a line. These structural choices live in the `draw<X>(painter, entity)` functions of the UI and are not expected to change frequently.
 
+The few shapes the game view and the balancing tool's arena view draw *identically* — the ship body, the health bar, the debris marker, the sensor-range circle — live in `ui/WorldPrimitives` as free functions over explicit values. The arena exists to eyeball combat, so it only works while a ship there looks like a ship in the game; keeping these in one place means a retuned ship shape cannot silently stop applying to the tool that measures it. The balancing target does not link the `ui` library, so it compiles that file into itself, the same way it already does for `VisualsLoader` and `ShipStatsPanel` (see `balancing/CMakeLists.txt`). Everything the two views draw differently — selection highlights, beams, target lines, and all of the factory — stays with each view; the shared set is deliberately not grown beyond shapes that are genuinely the same.
+
 Colors, outline widths, glyph text, and tile tints live in a separate config file, `visuals.toml`, loaded once by the UI at startup using the same pattern and lifetime as the sim config files (see Config Loading). The file is UI-scoped: the sim does not read it and does not depend on it.
 
 Sketch of `visuals.toml`:
@@ -366,7 +426,7 @@ width_px = 2
 [overlays]
 ghost_valid    = "#ffffff44"
 ghost_invalid  = "#ff000044"
-demolish_tint  = "#ff000033"
+deconstruct_tint  = "#ff000033"
 selection_rect = "#00ff00"
 
 [toast]

docs/balancing/README.md

@@ -0,0 +1,56 @@
+# Balancing Documentation
+
+Everything about balancing Dota Factory, separated by role:
+
+- **[rules.md](rules.md)** — the design rules and principles. Timeless;
+  changes only when the design changes.
+- **[targets.md](targets.md)** — the base numbers (roots/anchors) chosen
+  by design. Change these first; everything else re-derives.
+- **[derived.md](derived.md)** — the current tuned state of all derived
+  numbers, mirroring the configs. Updated whenever configs change.
+- **[process.md](process.md)** — how balancing is done: the pass order,
+  tuning discipline, tools, and the checklist for the next round.
+- **[history.md](history.md)** — chronological record of decisions,
+  findings, bugs, and arena rounds.
+
+Related: game content (hull grids, footprint gating, tree design and
+fiction) in [../content_design.md](../content_design.md); rules with
+REQ-* ids in [../requirements.md](../requirements.md).
+
+## Status
+
+First full balancing round complete (2026-07-06): targets → tree →
+numbers → threat-calculator parity → combat stats (arena-converged) →
+pacing. Next step: full-game playtests against the run-shape targets in
+`targets.md`.
+
+## Open action items
+
+Agreed changes that require edits to `requirements.md`, the code, or the
+configs. Completed items are removed (their outcomes live in
+`requirements.md`, `history.md`, and the git history).
+
+1. **Fill unfillable schematic slots with artifacts.** With duplicates
+   removed, the schematic drop pool can run dry — previously unreachable.
+   Decision: every slot in the choice dialog that cannot be filled with a
+   schematic because the eligible pool is exhausted is filled with an
+   artifact option instead (in addition to any artifact option granted by
+   the regular artifact roll). A push therefore always awards a full
+   dialog. Update REQ-DEF-SCHEMATIC-DROP.
+2. **Confirm wave scaling in playtests.** `threat_rate_formula` is the
+   only time-scaling axis; verify the tuned curve (see `derived.md`)
+   produces the intended difficulty race in real runs.
+3. **Gate shortcut-recipe drops on their inputs.** Extend the assembler
+   recipe schematic pool eligibility in REQ-DEF-SCHEMATIC-DROP: in
+   addition to the existing station-level and output-item checks, all of
+   the recipe's input item types must be implicitly unlocked as well.
+4. **Resource deposits.** Add a terrain deposit layer per the Resource
+   deposits rules (`rules.md`): deposit patches generated in expansion
+   columns (deterministic content per expansion, randomized placement
+   within the new columns), deposit rendering, and a miner condition (a
+   resource recipe is selectable only if the miner's footprint overlaps
+   at least one matching deposit tile). Touches REQ-BLD-MINER ("every
+   asteroid tile is equivalent" no longer holds),
+   REQ-GW-ASTEROID-EXPAND / REQ-EXP-*, `world.toml`, and `visuals.toml`.
+   Until this lands, quartz mines anywhere and the mid-game is
+   knowledge-gated only.

docs/balancing/derived.md

@@ -0,0 +1,164 @@
+# Derived Values (current tuned state)
+
+Everything here is derived from `targets.md` under the rules in
+`rules.md`, and mirrors the config files. Item threats, ship threats,
+ratios, and belt checks are verified by `tools/threat_report.py` — re-run
+it after any recipe or material change and update this file when values
+move. Combat stats were tuned empirically against the arena suite in
+`bin/balancing/data/balancing.toml` (round-by-round record in
+`history.md`).
+
+## Economy constants
+
+- `scrap_per_threat = 0.25` — 1 scrap per 4 threat destroyed (a cruiser
+  kill drops ~59 scrap); threat(scrap) = 4.
+- Scrap smelting: 1 scrap → 1 iron_ingot, 1 s — deliberately
+  value-losing; reprocessing is the value-preserving path.
+- Reprocessing: 4 scrap per cycle, 4 s; full-pool weights iron_ingot 30 /
+  copper_ingot 30 / silicon 20 / voidsteel 20 → threat(voidsteel)
+  = (4·4 + 4)/0.2 = 100.
+- `debris_despawn_seconds = 120` (a capital kill drops hundreds of scrap,
+  collected one per salvage cycle).
+
+## Recipes and item threats
+
+(dur in seconds; threat is per output unit)
+
+| item | recipe | dur | out | threat |
+|---|---|---|---|---|
+| iron_ore / copper_ore | miner | 1 | 1 | 1 |
+| quartz | miner (deposit) | 2 | 1 | 2 |
+| iron_ingot | 1 iron_ore | 1 | 1 | 2 |
+| copper_ingot | 1 copper_ore | 1 | 1 | 2 |
+| silicon | 1 quartz | 2 | 1 | 4 |
+| steel_plate | 2 iron_ingot | 3 | 1 | 7 |
+| copper_wire | 1 copper_ingot | 1 | 2 | 1.5 |
+| copper_coil | 2 copper_wire | 1.5 | 1 | 4.5 |
+| building_block | 2 steel_plate | 2 | 4 | 4 |
+| control_chip | 1 silicon + 2 copper_wire | 5 | 1 | 12 |
+| capacitor_bank | 2 copper_coil + 1 silicon | 5 | 1 | 18 |
+| hardened_steel | 3 steel_plate | 12 | 1 | 33 |
+| ceramic_plate | 2 quartz | 4 | 1 | 8 |
+| drive_unit | 2 steel_plate + 2 copper_coil + 1 control_chip | 8 | 1 | 43 |
+| voidsteel_plate | 1 voidsteel + 1 hardened_steel | 8 | 1 | 141 |
+| capital_core | 2 voidsteel + 1 capacitor_bank + 1 control_chip | 10 | 1 | 240 |
+
+Shortcut recipes (drop-only; item threat stays defined by the base path
+via the max rule): `direct_rolling` 3 iron_ore → 1 plate (2 s,
+level 1), `direct_etching` 2 quartz → 1 chip (4 s, level 2),
+`direct_hardening` 4 iron_ingot → 1 hardened (8 s, level 2).
+
+Ratio curve realized: t1 all 1:1 (miner:smelter); t2 clean 2:3
+(ingot→plate, wire→coil); t3 strange — 2:5 (silicon→chip), 3:5
+(coil→capacitor), 3:4 (plate→hardened, plate→drive); t4 inverted 3:2
+(hardened→voidsteel_plate). Belt check: worst input demand 1.33 items/s,
+under the ~2/s single-belt cap everywhere.
+
+## Module prefabs
+
+(contribution = item threat + module production time)
+
+| module | recipe | dur | mod. time | contribution |
+|---|---|---|---|---|
+| railgun_s | 1 copper_coil | 1 | 1 | 6.5 |
+| salvager | 1 steel_plate + 2 copper_wire | 2 | 1 | 13 |
+| repair_tool | 1 steel_plate + 2 copper_wire | 2 | 1 | 13 |
+| armor_plates | 4 steel_plate | 3 | 1 | 32 |
+| maneuvering_thrusters | 1 steel_plate + 1 copper_coil | 2 | 1 | 14.5 |
+| sensor_booster | 2 copper_wire + 1 copper_coil | 2 | 1 | 10.5 |
+| afterburner | 2 copper_coil + 1 steel_plate | 3 | 1 | 20 |
+| weapon_stabilizer | 1 steel_plate + 1 copper_coil | 2 | 1 | 14.5 |
+| weapon_primer | 1 capacitor_bank + 1 copper_coil | 4 | 2 | 28.5 |
+| weapon_upgrade | 1 control_chip + 1 copper_coil | 4 | 2 | 22.5 |
+| railgun_m | 1 capacitor_bank + 2 steel_plate + 1 copper_coil | 4 | 3 | 43.5 |
+| drone_bay | 1 control_chip + 2 steel_plate + 1 copper_coil | 4 | 3 | 37.5 |
+| railgun_l | 1 capacitor_bank + 2 hardened_steel + 1 ceramic_plate | 6 | 4 | 102 |
+| drone_hangar | 1 voidsteel_plate + 2 control_chip + 1 drive_unit | 10 | 6 | 224 |
+
+## Ships
+
+(fitted = hull item + ship base time + default loadout; the default
+loadouts are the `default_modules` used by enemy waves and are
+geometry-validated against the hull grids)
+
+| ship | hull recipe | dur | base | default loadout | fitted |
+|---|---|---|---|---|---|
+| drone | 1 iron_ingot | 1 | 1 | railgun_s | 10.5 |
+| frigate | 2 steel_plate + 1 copper_wire | 2 | 2 | 2× railgun_s, maneuvering_thrusters | 47 |
+| destroyer | 3 steel_plate + 2 copper_coil | 4 | 3 | 3× railgun_s, armor_plates, sensor_booster | 99 |
+| cruiser | 2 hardened_steel + 2 control_chip | 6 | 4 | 2× railgun_m, armor_plates, maneuvering_thrusters | 233.5 |
+| battlecruiser | 3 hardened_steel + 2 control_chip + 1 drive_unit | 8 | 5 | 3× railgun_m, armor_plates, 2× railgun_s | 354.5 |
+| battleship | 3 voidsteel_plate + 1 drive_unit + 2 control_chip | 10 | 6 | railgun_l, 2× railgun_m, weapon_stabilizer, 2× railgun_s | 722.5 |
+| dreadnought | 5 voidsteel_plate + 1 capital_core + 2 drive_unit | 12 | 8 | 3× railgun_l, 4× armor_plates, railgun_s | 1491.5 |
+| carrier | 5 voidsteel_plate + 1 capital_core + 2 drive_unit | 12 | 8 | drone_hangar, 2× railgun_m, 2× armor_plates, sensor_booster | 1436.5 |
+
+## Combat stats
+
+(arena-converged, 2026-07; see `history.md` rounds 1–5)
+
+**Weapons:** railgun_s 2 dmg × 2.0 Hz (4.0 DPS), range 50 m;
+railgun_m 14 × 1.5 (21), range 70; railgun_l 52 × 0.8 (41.6), range 100.
+
+**Hull HP** (15/threat prior + empirical trims): drone 60, frigate 300,
+destroyer 550, cruiser 1500, battlecruiser 2400, battleship 6300,
+dreadnought/carrier 24000.
+
+**Mobility ladder** (speed m/s | main accel | maneuvering | angular |
+max rot): drone 45|60|30|12|6, frigate 35|45|22|8|4,
+destroyer 30|35|18|6|3, cruiser 24|25|12|4|2, battlecruiser 20|20|10|3|1.5,
+battleship 15|14|7|2|1, dreadnought/carrier 10|8|4|1|0.5.
+Sensors: 150/200/220/250/260/280/300/350 m.
+
+**Other modules:** armor_plates +1200 HP; repair_tool 9 HP × 1 Hz,
+range 80; salvager range 60, cargo 20, 0.5 collections/s; afterburner
+×1.6 speed +60 accel; maneuvering_thrusters ×1.2 speed +10 maneuvering;
+sensor_booster +50 m; weapon_upgrade ×1.2 damage; weapon_primer ×1.2
+rate; weapon_stabilizer ×1.3 range ×0.8 rate.
+
+**Stations:** HQ 5000 HP. Player station 3000 HP, 25 dmg × 1 Hz,
+range 120, scrap 40. Enemy station: 3000+1500x HP, 25+12x dmg,
+1.0+0.1x Hz, range 120, scrap 40+30x (x = push level).
+
+## Pacing
+
+**Unlock ladder** (level → unlocks; ← marks `unlock_requires`; starting
+set at −1: drone, frigate, railgun_s, salvager, block_pressing recipe):
+
+| level | ships | modules | recipes |
+|---|---|---|---|
+| 0 | destroyer | repair_tool, armor_plates | |
+| 1 | | maneuvering_thrusters, sensor_booster | direct_rolling |
+| 2 | cruiser | railgun_m, afterburner | direct_etching, direct_hardening |
+| 3 | | weapon_stabilizer | |
+| 4 | battlecruiser ← cruiser | weapon_primer, weapon_upgrade | |
+| 5 | | drone_bay | |
+| 6 | battleship ← battlecruiser | railgun_l ← railgun_m | |
+| 8 | dreadnought ← battleship | | |
+| 9 | carrier ← battleship | drone_hangar | |
+
+Level 0's pool has exactly three entries (a full first dialog). Level 2
+is the quartz gate: cruiser and railgun_m are the first schematics whose
+chains reach quartz; the shortcut outputs only become implicitly
+unlocked alongside them, so shortcuts cannot drop early.
+
+**Threat rate** `2*x + 0.15*x*x` (x = boss cycle counter), against the
+factory-size curve with ~half the player's output assumed military:
+
+| cycle x | rate (threat/s) | player military (≈ curve/2) |
+|---|---|---|
+| 2 | 4.6 | ~12 |
+| 6 | 17.4 | ~30 |
+| 15 | 63.8 | ~60 |
+| 20 | 100 | ~75 |
+| 24 | 134 | — |
+
+**Economy:** `starting_building_blocks = 200`; expansion cost formula
+`300 + 50*x + 10*x*x` (x = expansions already purchased: ~1 affordable
+per cycle mid-game at ~1/3 of block income, stretching to 2–3 cycles
+late — quadratic so costs outrun the roughly linear block income
+gradually, never with a hard wall); `artifact_win_count = 5` with
+`artifact_chance_formula = 0.05*x`. Building costs: belt 2, splitter 3,
+tunnels 5, miner 15, smelter 20, assembler 35, reprocessing plant 40,
+salvage bay 25, shipyard 60 — averaging ≈18 blocks per placed building
+(belts included), which meets the 4-minute doubling target at block
+threat 4.

docs/balancing/history.md

@@ -0,0 +1,96 @@
+# Balancing History
+
+Chronological record of the balancing work: what was decided, what was
+found, what changed. Current values live in `derived.md`; this file
+explains how they got there.
+
+## 2026-07-02/03 — rules and structural decisions
+
+- Rules document written (now `rules.md`): ratio curve, shortcut
+  recipes, refactorability, cost archetypes, threat model, growth curve.
+- Scrap derived from threat (`scrap_per_threat`), replacing authored
+  per-ship scrap drops; scrap threat became the constant
+  `1/scrap_per_threat`, removing the old min-scrap_drop derivation and
+  its circularity.
+- Duplicate schematic drops removed (no level-ups); ship/module levels
+  removed entirely — all time scaling lives in the threat rate, push
+  scaling stays on stations. Mk2 upgrade recipes noted as the future
+  per-item progression.
+- Growth-curve rules added: escalating expansion costs, designed
+  doubling time, growth limited by economy not waiting; resource
+  deposits designed (deposit-gated mid resource in expansion territory).
+- Production tree v2 decided: iron/copper everywhere (M-type asteroid),
+  quartz in geodes (mid), voidsteel battle-forged from scrap (late);
+  titanium dropped; lasers renamed to railguns, lasers reserved as a
+  future weapon type.
+
+## 2026-07-03 — targets, tree, numbers
+
+- Balancing targets fixed: ≤2 h run, phases 1–5/6–14/15+, factory curve
+  25/60/120/150, threat ladder, 25-ship swarm, block roots.
+- Tree structure drafted and numbers computed (recursive threat
+  calculator); ratio curve realized; fitted ships within 96–124% of the
+  strawman ladder (small end hot from fixed chain overhead — ladder
+  later adopted the achieved values).
+- **Rule bugs found by the numbers work:** the scrap→ingot smelter
+  recipe would inflate basic materials via the max rule (fixed:
+  scrap-consuming recipes are threat fallback only); recipe output
+  amounts were ignored (fixed: per-unit division); items downstream of
+  reprocessing-only items never resolved (fixed: fixpoint resolution);
+  a shortcut recipe resolving earlier than the base path silently
+  underpriced items (fixed: commit only when all eligible recipes are
+  computable). All four fixed in `ThreatCostCalculator` with tests, and
+  implemented in `tools/threat_report.py`.
+- v2 tree written into the configs; `default_modules` loadouts
+  geometry-validated (the numbers-pass loadouts for battlecruiser and
+  dreadnought were geometrically impossible — L-modifiers don't fit
+  beside full gun complements; corrected loadouts landed closer to the
+  ladder).
+
+## 2026-07-04 — combat stats, arena rounds 1–5
+
+Initial stats derived from the anchors (weapon DPS ≈0.6/threat flat,
+hull 15 HP/threat, armor 20/threat, repair 2 HP/s/threat, station
+range 200).
+
+- **Round 1:** concentrated fleets won all equal-threat cross-tier
+  matchups flawlessly; glass beat armored; repair escort flawless; two
+  stations shrugged off a 3× swarm. Changes: concentration tax on m/l
+  gun damage (railgun_m 17→14, railgun_l 70→52), armor 640→1000,
+  repair 25→12, station range 200→120. (Team-1 "bias" in mirrors later
+  shown to be noise.)
+- **Round 2 (EHP-margin logging added):** battleship +33% while
+  dreadnought −37% (stabilizer range + opposing armor); glass still
+  +11%. Changes: stabilizer range ×1.5→×1.3; per-hull trims introduced
+  (BC 2700→2500, BS 7500→7000, DN/CV 15500→19000).
+- **Round 3 (narrow lanes — geometry fixed into the fixture):**
+  DN closed to −11%, BS +22%, swarm flipped to +14% over cruisers,
+  glass +12% third time. Changes: armor 1000→1200, BC 2500→2000,
+  BS 7000→6300, DN/CV 19000→22500.
+- **Round 4:** glass-vs-armored resolved (+3% armored); noise floor
+  established (~±10%/run: BS ignored a −10% EHP cut; repair drifted
+  14→24% untouched). Convergence policy adopted: two-round signals only,
+  ±20% converged. Changes: BC 2000→2200, DN/CV 22500→24000; BS +23%
+  accepted as doctrine texture (mechanical range edge vs. pure small
+  fleets).
+- **Round 5 (durations logged; end-condition bug fixed upstream):**
+  TTK anchor validated (mirrors 23/71/95 s; DN-vs-swarm 214 s outlier
+  accepted); dreadnought +3%, everything else inside band. Final
+  changes: BC 2200→2400, repair 12→9 (persistent +24% escort margin).
+  **Combat pass declared converged.**
+
+## 2026-07-05/06 — pacing pass
+
+- Unlock ladder set (starting set drone/frigate/railgun_s/salvager;
+  quartz gate at level 2; capitals at 8–9 with `unlock_requires`
+  chains); threat rate `2*x + 0.15*x*x`; starting blocks 1000→200;
+  expansion 400 flat pending the cost formula; artifacts 3→5.
+- **Bug found:** the building_block recipe was silently locked at game
+  start (building blocks appear in no schematic's materials, so implicit
+  unlocking could never reach the recipe) — fixed with an explicit
+  `unlock_at_station_level = -1`.
+- Expansion cost formula implemented and set (`300 + 50*x + 10*x*x`):
+  quadratic, so costs outrun the roughly linear block income gradually
+  — ~1 expansion per cycle mid-game, 2–3 cycles apart late.
+- **First full balancing round complete.** Next: full-game playtests
+  against the run-shape targets.

docs/balancing/process.md

@@ -0,0 +1,98 @@
+# Balancing Process
+
+How balancing is done in this project: the pass order, the tuning
+discipline, and the tools. Refer to this when starting the next
+balancing round.
+
+## The pass order
+
+Each pass depends on the ones before it; a change in an earlier pass
+invalidates the later ones (but not vice versa). Redo from the earliest
+pass whose inputs changed.
+
+1. **Targets** (`targets.md`) — choose the root numbers: run shape,
+   factory curve, threat-cost ladder, fleet size, block roots, combat
+   anchors, pacing anchors. These are design decisions, not
+   measurements. Everything else is derived from them.
+2. **Tree structure** (`../content_design.md`) — items, chains,
+   what-consumes-what, per the production tree rules (one input per
+   phase transition, generic parts, archetypes, refactorability).
+   Structure only, no quantities.
+3. **Numbers** (`derived.md`, recipes/materials in the configs) —
+   quantities and durations so every fitted ship sums to its ladder
+   value, the ratio curve is realized, and the belt/buffer guardrails
+   hold. Verified computationally by `tools/threat_report.py`.
+4. **Calculator/tooling parity** — the game's `ThreatCostCalculator`
+   and `tools/threat_report.py` must produce identical values; the
+   Python tool is the design reference. Any semantic change to
+   REQ-THREAT-* needs both updated plus tests.
+5. **Combat stats** (arena-driven) — derive stats from the combat
+   anchors, then iterate against the arena suite
+   (`bin/balancing/data/balancing.toml`) until equal-threat matchups are
+   near-draws. Threat costs are stat-independent, so arena ship counts
+   stay valid across stat changes.
+6. **Pacing** — unlock ladder, `unlock_requires` edges, threat rate,
+   block/artifact/expansion values, per the pacing anchors.
+
+Then: **full-game playtests**, which are the only check for the pacing
+pass and feed back into targets.
+
+## Tuning discipline (learned in arena rounds 1–5)
+
+- **Change anchors, not symptoms.** When a class of results is off,
+  adjust the anchor that explains all of them (e.g. the concentration
+  tax) rather than individual stats.
+- **Fewest knobs per round.** Attribution dies when many knobs move at
+  once. Prefer one anchor change plus its mechanical compensations.
+- **Shared vs. local knobs.** Guns and module stats are shared across
+  many hulls — changing them moves many matchups. Per-hull HP moves
+  exactly one matchup; it is the designated per-ship trim knob on top of
+  the HP-per-threat prior.
+- **Mind the ride-alongs.** A module buff lands on every default loadout
+  containing it (e.g. an armor buff strengthens the destroyer swarm that
+  opposes the dreadnought). Compute the net effect per matchup before
+  choosing step sizes.
+- **Two-round signal policy.** Single arena runs re-roll by ~±10% EHP
+  margin; a margin inside ±20% counts as converged for v1. Only act on
+  signals that persist across two rounds.
+- **Arena geometry is part of the fixture.** Lane width/height changes
+  the results (full engagement vs. fleets slipping past); margins are
+  only comparable within the same geometry.
+- **Accept mechanical texture.** Not every deviation is a bug: a margin
+  that survives a stat change is mechanical (usually range/kiting under
+  the orbit AI) and may be desirable doctrine texture. Document the
+  acceptance in `targets.md` instead of chasing it.
+- **Range is the strongest stat** under the orbit AI — free approach
+  fire. Price range modifiers conservatively; station dominance is
+  controlled via range, not HP.
+
+## Tools
+
+- `tools/threat_report.py` — item threats, module contributions,
+  hull/fitted ship threats, producer:consumer ratios, belt feasibility;
+  reads the real configs. The design reference for threat semantics.
+- `tools/verify_recipes.py` — recipe tree closure, visuals coverage,
+  orphans, reprocessing-only items.
+- `tools/verify_layouts.py` — module footprint gating matrix per hull.
+- **Balancing tool** (`balancing` target) — parallel arena simulation of
+  `bin/balancing/data/balancing.toml`; logs winner, surviving counts,
+  team EHP %, and fight duration per arena. The suite covers: class
+  mirrors (expect near-mutual annihilation, symmetric winners),
+  equal-threat cross-tier matchups (expect near-draws — power-per-threat
+  made empirical), a 2:1 decisiveness check, doctrine matchups
+  (armored-vs-glass, repair-escort), and station assault.
+
+## Checklist for the next balancing round
+
+1. Pull; run `verify_recipes.py`, `verify_layouts.py`,
+   `threat_report.py`; compare against the tables in `derived.md`.
+2. If recipes/materials changed: re-check fitted threats vs. the ladder
+   in `targets.md`; update arena suite ship counts if fitted values
+   moved.
+3. Run the arena suite; read EHP margins and durations against the
+   expectations noted in `balancing.toml` and the anchors.
+4. Apply changes per the tuning discipline (two-round signals only);
+   record the round and its knob changes in `history.md`.
+5. Update `derived.md` where values moved; if an anchor moved, update
+   `targets.md` and state why.
+6. Commit and push (the review workflow reads the remote).

docs/balancing/rules.md

@@ -0,0 +1,333 @@
+# Balancing & Progression Rules
+
+Rules and principles that govern the production tree, progression pacing,
+and balancing. This document contains **rules only** — the chosen base
+numbers live in `targets.md`, everything derived from them in
+`derived.md`, and the concrete content in the config files and
+`../content_design.md`. All of those must follow the rules stated here.
+
+## Player-experience goals
+
+What each phase of a run should feel like:
+
+- **Early:** learning belts and ratios with forgiving chains. The building
+  block economy is the main constraint; the player bootstraps a
+  self-sustaining factory from the starting stock.
+- **Mid:** deeper chains, the first real ratio puzzles, and the first
+  meaningful drop decisions (which schematic, when to push).
+- **Late:** combat feeds the factory — capital production requires salvage.
+  Progress means extending and refactoring the existing factory, not
+  rebuilding it. Strange ratios are deliberate optimization puzzles.
+
+Overarching: an experienced player gains efficiency through **knowledge** —
+layout foresight, understanding chains, exploiting shortcut recipes — never
+through hidden mechanics. An inexperienced setup should not cost much more
+than an experienced one; experience pays off in how easily the factory
+adapts later (see Refactorability).
+
+## Resource phases
+
+- A run has exactly **four base inputs**:
+  1. Two mined resources available from the start, minable on **every**
+     asteroid tile.
+  2. A third mined resource unlocked mid-game, minable **only on deposit
+     patches** found in expansion territory (see Resource deposits).
+  3. A fourth input unlocked late-game, obtainable **only** from
+     reprocessing salvaged scrap.
+- The fourth input is the core loop hook: capital ship production requires
+  fighting (salvaging and reprocessing), not just mining.
+- Every gating has a fictional reason (concrete fiction in
+  `../content_design.md`): the asteroid is a metal-rich body, so its bulk
+  rock is minable anywhere; the mid resource sits in rare pockets; the
+  late input is battle-forged — created only in the violence of ship
+  destruction, which is why any wreck (including the player's own)
+  yields it and no foundry can make it.
+- The mid resource is **dual-gated**: schematics (knowledge, via drops)
+  and territory (deposits, via expansions). Tuning must guarantee the
+  deposit-bearing expansion is comfortably affordable by the time the
+  first mid-tier schematics drop, or those drops are dead picks.
+- There is no direct "resource unlock" mechanism. Miner recipes unlock
+  **implicitly** (REQ-LOCK-IMPLICIT) when some unlocked schematic's material
+  chain reaches that resource. Resource pacing is therefore controlled
+  through the `unlock_at_station_level` values of ships, modules, and
+  assembler recipe schematics — and the content must guarantee that the
+  chains actually connect (a mid-game schematic must require an item whose
+  chain reaches the mid resource, or it never unlocks).
+
+### Resource deposits
+
+- **Rule: freedom first, geography later.** The starting resources are
+  minable everywhere, so the player has full layout freedom while
+  learning. Later mined resources are bound to deposit patches — fixed
+  geography as a layout puzzle, introduced once the player is competent.
+- **Rule: deposits exist only in expansion territory.** Expansions buy
+  space *and* access to resource tiers — the second leg of the growth
+  curve (see Building block economy).
+- **Rule: patch area is the throughput cap.** Deposits never deplete but
+  are finite in area; the number of deposit tiles caps how many miners
+  the chain supports. Buying deeper expansions raises the throughput
+  ceiling of high-tier chains.
+- **Rule: no empty expansions.** Deposit content per expansion is
+  deterministic and config-defined; only the placement within the new
+  columns is randomized. Buying an expansion never rolls "nothing".
+- **Rule: mining is binary.** A miner whose footprint overlaps at least
+  one deposit tile of a resource can select that resource's recipe; no
+  partial-coverage rate scaling.
+- Deposits arrive at the periphery (expansions add columns on the left),
+  so each new chain starts in fresh space — supporting the
+  refactorability property — and high-tier chains have the longest belt
+  runs to the shipyards, escalating the logistics puzzle with tier.
+
+## Production tree rules
+
+### Structure
+
+- **Each phase transition adds exactly one new base input chain.** A base
+  input is a bottom-level resource entering the factory from outside — a
+  mined resource or the scrap-only input. The early game starts with two
+  ores as the baseline; the transition to mid adds one (the deposit-bound
+  mid resource), the transition to late adds one (the scrap-only input).
+  No transition ever introduces more than one unfamiliar bottom-level
+  chain, so the factory grows in one direction at a time.
+- **Intermediates are generic shared parts.** Keep the item count low —
+  modules and hulls of a tier draw from a shared pool of that tier's and
+  lower tiers' intermediates rather than each having bespoke inputs.
+- **Thematic naming over thematic items.** Inputs should be plausible for
+  what the recipe produces (crystals for lasers, heat sinks for bigger
+  lasers). Achieve this through naming and chain membership, not by adding
+  item types: rename a generic part, don't add a parallel one.
+
+### Ratios
+
+- **Ratio "niceness" degrades with tier.** The producer:consumer ratios
+  needed for 100% throughput follow a curve:
+  - Tier 1 (ore → basic material): trivially nice (e.g. 1:1 or 1:2
+    miner:smelter).
+  - Tier 2: slightly complex but still clean (e.g. 2:3).
+  - Higher tiers: increasingly strange ratios, as deliberate optimization
+    puzzles.
+- Exceptions in both directions are allowed when there is a reason — a
+  clean late chain as a breather, an odd early chain as a teaser — but the
+  curve is the default.
+
+### Shortcut recipes
+
+- Some strange chains get a **shortcut recipe**: an explicitly unlockable
+  assembler recipe schematic (`unlock_at_station_level ≥ 0`, drop-only per
+  REQ-LOCK-EXPLICIT) that skips a step (e.g. t1 → t3 directly) and yields
+  nice ratios for a chain whose base path is strange.
+- **Not every strange chain gets a shortcut.** Some strangeness is
+  permanent; the absence of a fix is a valid design choice.
+- **Shortcuts drop only for known chains.** A shortcut recipe enters the
+  drop pool only when both its input items and its output item are
+  already unlocked (in addition to the station level check). The player
+  is never offered a shortcut for a chain they have not built yet. The
+  output-item half of this check already exists in
+  REQ-DEF-SCHEMATIC-DROP; the input half is an open action item (see
+  `README.md`).
+- **Shortcuts are pure rewards, never balance factors.** An item's threat
+  value is the *maximum* across its producing recipes (REQ-THREAT-ITEM), so
+  unlocking a cheaper recipe does not lower the item's threat accounting —
+  the player gains real factory efficiency without their ships being
+  valued cheaper and without enemy wave budgets shifting. Consequently:
+  **balance every chain around its base (expensive) path**; the shortcut's
+  savings define the size of the reward.
+
+### Refactorability
+
+- **Rule (the property):** unlocking the next tier or size of a thing must
+  be a *local edit* of the existing production line — adding assemblers
+  and belts, or replacing a machine or two in place — never a rebuild of
+  the line.
+- **What this buys the player:** foresight pays off in space, not blocks.
+  An experienced player leaves a little slack in the middle of a line,
+  knowing the next size or tier upgrade means tearing out one assembler
+  and a few belts there and inserting the new step — plus maybe swapping
+  a recipe or two elsewhere — while the rest of the line keeps running
+  untouched.
+- **Default technique:** the bigger version introduces one new intermediate
+  that is produced from a subset of the smaller version's inputs (possibly
+  plus one additional low-tier material), and otherwise reuses the smaller
+  version's inputs. Existing lines keep running and feed the new
+  intermediate's assemblers.
+- The property is the rule; the technique is only the default. It may be
+  broken where it fights thematic plausibility, as long as the property
+  still holds.
+
+## Cost archetypes
+
+Every item has two cost knobs: **material quantity** and **cycle time**.
+Both feed the threat value identically (threat = recursive
+production-seconds, REQ-MOD-THREAT), so the split between them does not
+change what an item is *worth* — it changes what kind of **factory
+pressure** it creates:
+
+- **Material-heavy, fast** (e.g. armor plates): simple items; stress belt
+  throughput, splitter logistics, and miner/smelter counts.
+- **Time-heavy, lean** (e.g. shield modules): technically complex items;
+  few inputs — possibly higher-tier ones — but long cycles; stress
+  assembler counts and parallelization.
+
+**Rule:** each module family commits to a clear archetype, so factories
+supporting different fleet doctrines feel structurally different to build.
+
+## Threat model (balancing backbone)
+
+- Threat cost = total recursive production-seconds (REQ-MOD-THREAT). One
+  factory-second equals one threat; player output and enemy wave budgets
+  are denominated in the same currency.
+- **Rule: combat power per threat is roughly constant** across all ships,
+  modules, and tiers. Higher tiers are better per *ship* and per *module
+  slot*, not per invested factory-second — their advantage is
+  concentration (fewer, bigger things; slot geometry per
+  `../content_design.md`) and qualitative capabilities, not a better
+  exchange rate. Deviations from this rule are deliberate and documented.
+- **Difficulty race:** the enemy threat rate (`threat_rate_formula`) is
+  tuned against the factory output (threat/s) achievable by a competent
+  player — slightly below it early, crossing above it eventually. The game
+  is endless; enemy scaling must ultimately outpace any factory, and
+  player skill shifts *when*, not *whether*.
+- **All time scaling lives in the threat rate** — waves get bigger, ships
+  of a given schematic never get individually stronger. There is no ship
+  level dimension: stat formulas are plain values, and per-ship level
+  scaling does not exist. Push scaling on enemy defence stations is the
+  separate, player-triggered difficulty axis and keeps its level formulas.
+
+## Unlock & drop pacing
+
+- **Starting set rule:** the schematics unlocked at game start
+  (`unlock_at_station_level = -1`) must be exactly enough to reach the
+  first push unaided — a functioning block loop, small hulls, a basic
+  weapon, and the salvage loop. Nothing more.
+- The `unlock_at_station_level` ladder mirrors the resource phases:
+  mid-tier hulls/modules/recipes at low station levels, capital content at
+  higher levels. A schematic must not become available before the chains
+  its materials need can be unlocked alongside it.
+- **Schematics can require other schematics.** Beyond the station-level
+  gate, a schematic (ship, module, or assembler recipe) may list
+  prerequisite schematics (`unlock_requires`, REQ-LOCK-PREREQ) that must
+  already be unlocked before it enters the drop pool — e.g. the medium
+  gun requires the small gun; a future Mk2 requires its base version.
+  Station level gates the earliest *when*; prerequisites gate the
+  *order*, keeping drop offers coherent with what the player already
+  owns.
+- **No duplicate drops.** Ship and module schematics leave the drop pool
+  once owned, exactly as assembler recipe schematics already do. There are
+  no schematic level-ups; player power grows through unlock breadth and
+  factory scale only, which keeps power-per-threat exact on both sides.
+  The pool therefore shrinks over a run and late pushes increasingly offer
+  artifacts — intended: the late game is a race for the win condition.
+  Per-item progression may return later as Mk2 upgrade recipes (see Future
+  work), never as free level-ups.
+- **Artifacts trade power for progress.** Artifact options compete with
+  schematic picks in the same choice dialog; the artifact chance must be
+  tuned so that taking one is a real decision (giving up an unlock), not
+  automatic in either direction.
+
+## Scrap & reprocessing economy
+
+- Scrap is the bridge from combat back into the factory, with two sinks:
+  **smelting** (same basic materials as ore — the safe, boring option) and
+  **reprocessing** (probabilistic higher intermediates, including the
+  late-game input — the gamble that eventually becomes mandatory).
+- The reprocessing output pool renormalizes over implicitly unlocked items
+  (REQ-LOCK-REPROCESSING-POOL), so its output quality improves
+  automatically as the run progresses. **Rule:** weights are authored for
+  the *fully unlocked* pool state; early-game behavior falls out of
+  renormalization for free and needs no separate staging.
+- **Rule: ship scrap drops are derived, never authored.** A destroyed ship
+  drops `threat cost × scrap_per_threat` (a `world.toml` key), with the
+  threat cost computed from its actual hull plus installed modules
+  (REQ-MOD-THREAT) — a kitted-out ship drops more scrap than a bare hull
+  automatically. `ships.toml` carries no scrap value. Defence stations are
+  the exception: they keep authored `scrap_drop_formula`s, because pushing
+  rewards are tuned independently of ship production costs.
+- Consequence: the threat value of scrap is the constant
+  `1 / scrap_per_threat` (REQ-THREAT-SCRAP). The former min-`scrap_drop`
+  schematic derivation and its potential circularity are gone.
+- **Rule:** the late-game input's income rate meaningfully gates capital
+  production — unlocking a capital hull must not mean spamming it; the
+  input trickles in slowly enough that every capital ship is a noticeable
+  investment. The tuning target is relative, not absolute: assume a
+  reference player who destroys and salvages roughly the threat the game
+  spawns ("fighting at parity"), and tune `scrap_per_threat`, the
+  reprocessing weights, and capital material costs so that this player
+  affords roughly N capital ships per boss cycle. An absolute income rate
+  would be meaningless (income depends entirely on how much the player
+  fights) and would not self-scale; per boss cycle, the target tracks the
+  threat rate as it steps up.
+
+## Building block economy
+
+- Building blocks are the only global currency and the early game's
+  central constraint. The early game is a bootstrap problem: convert the
+  starting stock into a self-sustaining block loop before the first waves
+  bite.
+- **Rule:** the starting stock suffices for a minimal block loop plus the
+  first shipyard — with a little slack for beginner mistakes, but not
+  enough to skip the loop entirely.
+- **Rule: the growth curve lives here.** A saturated building produces
+  exactly 1 threat/s, so the player's output curve *is* their
+  building-count curve — shaping growth over a run means shaping the
+  block and space economy, there is nowhere else it can live. Intended
+  shape: exponential bootstrap (block-limited) → ramp
+  (expansion-limited) → asymptotic squeeze as expansion costs outrun
+  income, racing the enemy threat rate throughout.
+- **Rule: escalating expansion costs.** Expansion cost is a formula of
+  the number of expansions already purchased, rising steeply enough that
+  expansions eventually outrun any block income. The starting asteroid
+  is deliberately small — filled within the first boss cycle or two, so
+  the early exponential burst is a satisfying ramp, not a balance hole —
+  and from then on the output curve is the expansion curve. Blocks keep
+  a meaningful sink for the entire run, and "grow vs. army" stays a live
+  decision at every moment.
+- **Rule: designed doubling time.** Block production is a positive
+  feedback loop (blocks buy assemblers, assemblers make blocks); its
+  time constant is a designed quantity, never an accident of quantity
+  choice. The block chain's depth and the per-building costs are tuned
+  against a stated target of the form: "a factory spending X% of its
+  capacity on blocks doubles in ~T minutes."
+- **Rule: growth is limited by economy, never by waiting.** Construction
+  times stay short; the serial build queue must not be used as a growth
+  brake. Waiting for placed buildings to become operational — especially
+  at the start of a run — is frustration, not gameplay. All growth
+  limiting comes from block income and expansion pricing.
+- Note: block income has a structural ceiling — blocks enter the stock
+  through the HQ's single belt port, so income is capped at belt
+  throughput regardless of assembler count. Per-building costs should be
+  high enough that this cap can bind late-game (see the condensed-block
+  idea under Future work).
+
+## Numeric guardrails
+
+Constraints that every recipe must respect, independent of tuning:
+
+- **Belt throughput:** belt speed and per-tile capacity cap how fast a
+  single belt can feed an input. A recipe whose per-cycle inputs cannot be
+  sustained by one belt per input at 100% duty cycle is a *deliberate*
+  design (forcing parallel belts/splitters as part of a high-tier puzzle)
+  — never an accident of quantity choice.
+- **Buffer burstiness:** input buffers hold 2× the per-cycle amount
+  (REQ-MAT-INPUT-BUFFER), so large per-cycle quantities create bursty belt
+  demand. Low tiers prefer small quantities with short cycles; big-batch
+  recipes are reserved for high tiers where burstiness is part of the
+  puzzle.
+- **Cycle times scale with tier** monotonically — a higher-tier item never
+  has a shorter total chain time than a lower-tier item of the same role.
+
+## Future work
+
+- **Condensed building blocks** — a drop-unlockable shortcut-style
+  recipe that packs several blocks' worth of value into one belt item,
+  relieving the HQ intake ceiling (see Building block economy) as a
+  late-game reward. The ceiling is the puzzle, the drop is the fix —
+  same philosophy as shortcut recipes.
+- **Mk2 upgrade recipes** — the deferred design for per-item progression,
+  to revisit once the config has stabilized. A duplicate-style drop
+  unlocks a distinct `*_mk2` item whose recipe consumes the Mk1 item plus
+  higher-tier parts. This preserves power-per-threat (the extra power is
+  paid in real production-seconds, since threat is recursive), satisfies
+  the refactorability rule (the Mk1 line keeps running and feeds one new
+  assembler), and keeps balancing one-dimensional (no level variable
+  anywhere). Enemy-side progression happens via `default_modules`
+  variants per era instead of a level formula.

docs/balancing/targets.md

@@ -0,0 +1,104 @@
+# Balancing Targets (base numbers)
+
+The root numbers of the balancing. Everything in `derived.md` is tuned to
+hit these; when rebalancing, **change these first and re-derive — never
+patch derived values directly**. The rules these numbers follow live in
+`rules.md`.
+
+All time targets are in **game time**. The player can pause and
+accelerate, so real session length differs; playtests measure both. The
+time unit is the boss cycle (`world.toml boss_countdown_seconds`, 300 s).
+Destroying a station set advances the boss countdown by
+`boss_advance_seconds` (60 s), so cycles run shorter than nominal when
+pushing actively — targets deliberately ignore that.
+
+## Run shape
+
+1. **Run length** — a winning run takes up to 2 hours of game time: win
+   around boss cycle 20–24. Losing runs end earlier.
+2. **Phase boundaries** — early = cycles 1–5 (iron/copper, small hulls),
+   mid = cycles 6–14 (quartz, medium hulls), late = cycles 15+
+   (voidsteel, capitals). Push cadence: first station set around cycle
+   2–3, roughly one per cycle from mid onward — so the destroyed set's
+   level ℓ is reached around cycle ℓ+2.
+3. **Factory size curve** — producing buildings over time; when
+   saturated, output threat/s equals this count, so this curve IS the
+   player power curve: ~25 when the starting asteroid is full (end of
+   cycle 2), ~60 at the start of mid (cycle 6), ~120 at the start of
+   late (cycle 15), ~150 near the win. `threat_rate_formula` must remain
+   a fraction of this curve; buildings plus belts must physically fit
+   the asteroid plus affordable expansions.
+4. **Threat-cost ladder** — total production-seconds per *fitted* hull
+   (including the typical/default module loadout): drone 10.5,
+   frigate 47, destroyer 99, cruiser 233.5, battlecruiser 354.5,
+   battleship 722.5, dreadnought 1491.5, carrier 1436.5. Every
+   production chain must sum to its ladder value. (The original strawman
+   was 10/40/80/200/350/700/1500; the small end runs ~10–20% hot because
+   fixed chain overhead dominates small hulls — accepted, and the
+   achieved values adopted as the ladder. The ~×2-per-class curve shape
+   is the invariant.)
+5. **Fleet size** — swarm-leaning: ~25 player combat ships as the
+   standing mid-game fleet. Standing fleet = build cadence (4) × average
+   ship lifetime, so this target drives time-to-kill and therefore all
+   combat stat magnitudes.
+6. **Block economy roots** — bootstrap complete (starting asteroid full)
+   by the end of cycle 2; a factory spending ~30% of its capacity on
+   blocks doubles in ~4 minutes early game; one expansion affordable per
+   cycle at ~1/3 of block income mid-game, decelerating to one per 2–3
+   cycles late as escalating costs outrun income.
+
+## Combat anchors
+
+All combat stats derive from these; per-hull HP additionally carries
+empirical trims from arena rounds (values in `derived.md`).
+
+- **Weapon DPS per threat pays a concentration tax that grows with gun
+  size**: small ≈ 0.62, medium ≈ 0.48, large ≈ 0.41 DPS per threat of
+  weapon contribution, compensated by the range ladder 50/70/100 m.
+  Rationale: concentration itself (focus fire, no DPS loss to attrition,
+  range) is worth paying for — with a flat curve, concentrated fleets
+  win equal-threat fights outright (arena round 1).
+- **Hull HP = 15 per threat of hull contribution** as the prior; per-hull
+  HP is the empirical trim knob (guns are shared across hulls, hull HP
+  moves exactly one matchup). The arena consistently prices capitals as
+  *tanks with taxed guns* — capital hulls sit well above the prior.
+- **Armor HP ≈ 37 per threat** — a strong premium over hull HP because
+  armor is pure HP with no capability, and fights snowball: killing
+  removes enemy DPS, surviving merely delays — HP must be cheaper than
+  DPS.
+- **Repair ≈ 0.7 HP/s per threat** — in-combat sustain effectively
+  removes enemy DPS and must be priced like DPS, not like HP.
+- **TTK / fight duration**: parity fights in the 30–60 s band at
+  mid-game scale; capital mirrors ~90 s deliberately; the extreme
+  tank-vs-chip-damage matchup (dreadnought vs destroyer swarm, ~3.5 min)
+  is an accepted outlier.
+- **Mobility is monotone in size** — the smallest hulls are the fastest
+  and nimblest. Sensor ranges (150→350 m) always exceed weapon ranges.
+- **Weapon modifiers are capital economy**: a ×1.2 damage modifier at
+  ~22.5 threat beats adding a gun once a ship carries more than ~68
+  threat of weapons — modifiers pay off on gun-heavy big hulls, waste on
+  small ones. Range modifiers are the strongest and are priced/kept
+  small (×1.3): range is the dominant stat under the orbit AI (free
+  approach fire).
+- **Stations**: a fresh player station holds one early parity wave
+  unaided; the enemy station at level 0 matches the player station
+  exactly and scales per push level. Station range is the dominance
+  lever, not HP (at 4× a small gun's range, two stations annihilated a
+  3× threat swarm through approach fire alone).
+- **Accepted imbalances**: the carrier loses its equal-threat fights
+  until the drone-launching capability exists (the hangar is dead
+  threat) — fix by implementing drones, not stats. A pure smallest-ship
+  fleet modestly loses (~15–25%) to a range-fitted capital — desirable
+  doctrine texture; the fair anti-capital answer is the mixed fleet.
+
+## Pacing anchors
+
+- **Starting set** is the rule-minimum: drone, frigate, small gun,
+  salvager (plus the explicitly unlocked building-block recipe).
+- **Threat rate shape**: below the player's achievable military output
+  (≈ half the factory curve) early, crossing at the late boundary
+  (~cycle 15), overwhelming by ~cycle 24.
+- **Winning = five real decisions**: `artifact_win_count` is set so that
+  across a winning run's ~15–18 pushes (~7 cumulative artifact offers at
+  the current chance formula), the player must choose the artifact over
+  a schematic about five times.

docs/content_design.md

@@ -1,9 +1,10 @@
-# Content Design — Ships & Modules
+# Content Design — Ships, Modules & Production Tree
 
-First real-content iterations (June 2026). Pass 1 defined ship hull grids and
-module surface masks; pass 2 defined the production tree (recipes). Stats and
-threat costs in the config files are still placeholders for the balancing
-pass.
+The designed game content: hull layout grids, module footprints and the
+gating between them, and the production tree (items, chains, fiction).
+All numbers — quantities, durations, threat values, stats, unlock levels
+— live in the config files and are documented with their derivations in
+`docs/balancing/` (see `balancing/README.md` for the index).
 
 ## Design principle: footprint gating
 
@@ -17,12 +18,12 @@ and makes them trivially moddable through the config files alone.
 
 | Footprint | Modules | Smallest hull that fits it |
 |-----------|---------|----------------------------|
-| 1x1 | laser_cannon_s, salvager, repair_tool | drone |
+| 1x1 | railgun_s, salvager, repair_tool | drone |
 | 1x2 | maneuvering_thrusters, sensor_booster, armor_plates | frigate |
 | 1x3 | afterburner | frigate (eats most of it) |
 | L-shape (3 cells) | weapon_stabilizer, weapon_primer, weapon_upgrade | frigate |
-| 2x2 | laser_cannon_m, drone_bay | cruiser |
-| 3x3 | laser_cannon_l | battleship |
+| 2x2 | railgun_m, drone_bay | cruiser |
+| 3x3 | railgun_l | battleship |
 | 2x6 | drone_hangar | carrier (only) |
 
 ### Hull grids
@@ -131,64 +132,163 @@ drone hangar — carrier 1.
 
 ## Production tree
 
-Design principle: each game phase adds exactly one new base input chain, so
-factory complexity ramps alongside ship size.
+Designed against the rules in `docs/balancing/rules.md` (ratio curve,
+cost ladder, cost archetypes, refactorability). Quantities, durations,
+and threat values live in `docs/balancing/derived.md`.
 
-| Phase | New input | How acquired | Unlocks |
-|-------|-----------|--------------|---------|
-| early | iron_ore, copper_ore | mined | drone, frigate, destroyer; small guns and basic supports |
-| mid | titanium_ore | mined (3x slower than iron) | cruiser, battlecruiser; m guns, drone bay, weapon modifiers |
-| late | advanced_alloy | ONLY from reprocessing salvaged scrap | battleship, dreadnought, carrier; l guns, drone hangar |
+### Base inputs (4) and fiction
 
-The advanced_alloy gate is the core loop hook: capital ship production
-requires fighting (salvaging scrap from kills and reprocessing it), not just
-mining. The reprocessing plant turns 5 scrap into iron/copper/titanium ingots
-or advanced_alloy probabilistically.
+- **iron_ore, copper_ore** — from the start, minable on every asteroid
+  tile. Fiction: the asteroid is an M-type (metal) body — its bulk rock
+  *is* ore, which is why the shipyard operation was built here at all.
+- **quartz** — mid-game, minable only on geode deposit patches in
+  expansion territory (see the Resource deposits rules in
+  `docs/balancing/rules.md`; the deposit mechanic itself is an open
+  action item — until it lands, quartz mines anywhere). Fiction:
+  ordinary silicate dust is everywhere and worthless; chips and optics
+  need rare, pocket-bound optical-grade crystal.
+- **voidsteel** — late-game, obtained only by reprocessing scrap.
+  Fiction: battle-forged — formed when weapon plasma anneals hull metal
+  in the violence of ship destruction. Any wreck yields it, including the
+  player's own; no foundry can replicate it.
+- **titanium was dropped** (v1 tree). Its hull-gating role moved to
+  quartz-era control systems ("you can smelt all the steel you want, but
+  you cannot steer a battlecruiser without electronics") plus the
+  hardened-steel quality step (a deliberately long-running, time-heavy
+  recipe) — explicitly not sheer steel quantity alone.
 
-Intermediate components, by tier:
+### Material palette (fingerprints per family)
 
-- **Tier 2 (early):** copper_wire (copper), steel_plate (iron), circuit_board
-  (iron + wire), building_block (iron).
-- **Tier 3 (mid):** mechanical_parts (steel + iron), targeting_unit (circuits
-  + wire), drive_unit (steel + mechanical_parts + circuit), titanium_frame
-  (titanium + steel).
-- **Tier 4 (late):** reinforced_plating (steel + advanced_alloy),
-  capital_core (targeting_unit + drive_unit + 2 advanced_alloy).
+- **iron/steel** — structure.
+- **copper** — conduction and heat: wiring, coils, heat sinks.
+- **silicon family** (all derived from quartz): silicon (logic,
+  sensors), ceramics (heat shielding, insulators); glass/optics are cut
+  from v1 — their only consumers would be lasers, which are deferred.
+- **voidsteel** — capital-tier structure and exotics.
+- Deliberately skipped: carbon (mostly redundant with copper/ceramics),
+  plastics (drags in Factorio-style chemical chains; ceramics read more
+  sci-fi anyway), volatiles/ice (materials are build costs only — no
+  consumption mechanic to justify fuel).
 
-Hulls and modules consume intermediates of their tier: early items are built
-from tier-2 parts, midgame items require tier-3 parts (deeper chains, more
-assemblers), capital items require tier-4 parts (and therefore combat). Hull
-items are named `<ship>_hull`; module items `<module>_module`. Every item has
-an `[items.*]` entry in visuals.toml; hull item outlines match the ship's
-fleet color from `[ships.*]`.
+### Weapons
 
-Consistency is checked by `tools/verify_recipes.py` — re-run it after editing
-recipes, ship/module materials, or visuals:
+- All v1 weapons are **railguns** (`railgun_s/m/l`, renamed from the
+  laser placeholders; footprints and the gating matrix unchanged).
+  Implementation is instant damage application with no projectile and no
+  ammunition — the beam visual reads as a tracer round. Materials: iron
+  slugs, copper coils, steel rails — the starting-metal fingerprint.
+- **Lasers are reserved for later** as a genuinely distinct weapon type
+  (e.g. once projectile/ammunition mechanics exist for other families),
+  arriving with quartz optics. More weapon types are planned; railguns
+  are simply the baseline tech that ships with v1.
+- `drone_bay` and `drone_hangar` are footprint-only placeholders: the
+  drone-launching capability does not exist in the simulation yet, so
+  they define no capability section. The carrier is deliberately weak
+  until that capability lands (see the accepted imbalances in
+  `docs/balancing/targets.md`).
+
+### Tree structure
+
+Input lists only — quantities, durations, and per-item threat values are
+in `docs/balancing/derived.md` and the configs.
+
+**Mined (miner):** `iron_ore`, `copper_ore` (every tile), `quartz`
+(geode deposits in expansion territory).
+
+**Smelted (smelter — exactly one recipe per input item):**
+
+| output | input | ratio class |
+|---|---|---|
+| iron_ingot | iron_ore | nice (1:1) |
+| copper_ingot | copper_ore | nice |
+| silicon | quartz | mid entry |
+| iron_ingot | scrap | the safe, boring scrap sink |
+
+**Reprocessing pool (scrap):** `iron_ingot`, `copper_ingot`, `silicon`,
+`voidsteel` — the only source of voidsteel. Weights authored for the
+fully unlocked pool state.
+
+**Tier 2 — early intermediates (clean ratios, ~2:3):**
+
+| item | inputs | role |
+|---|---|---|
+| steel_plate | iron_ingot | structure backbone, highest volume |
+| copper_wire | copper_ingot | conductors |
+| copper_coil | copper_wire | electromagnets: railguns, thrusters |
+| building_block | steel_plate | depth-3 chain = the doubling-time knob |
+
+**Tier 3 — mid intermediates (strange ratios begin, need quartz):**
+
+| item | inputs | role |
+|---|---|---|
+| control_chip | silicon + copper_wire | electronics gate for m+ hulls |
+| capacitor_bank | copper_coil + silicon | power for railgun m/l |
+| hardened_steel | steel_plate (long cycle) | quality gate for m+ hulls; time-heavy |
+| ceramic_plate | quartz | heat shielding: drives, l guns, capitals |
+| drive_unit | steel_plate + copper_coil + control_chip | propulsion for m+ hulls |
+
+**Tier 4 — late intermediates (need voidsteel):**
+
+| item | inputs | role |
+|---|---|---|
+| voidsteel_plate | voidsteel + hardened_steel | capital structure |
+| capital_core | voidsteel + capacitor_bank + control_chip | capital heart |
+
+**Hull items** (`<ship>_hull`, assembler-made; the shipyard consumes the
+hull item plus module materials). The m+ hull gate is **both**
+hardened_steel (quality steel, the time-heavy step) *and* control_chip
+(electronics):
+
+| hull | inputs |
+|---|---|
+| drone_hull | iron_ingot |
+| frigate_hull | steel_plate + copper_wire |
+| destroyer_hull | steel_plate + copper_coil |
+| cruiser_hull | hardened_steel + control_chip |
+| battlecruiser_hull | hardened_steel + control_chip + drive_unit |
+| battleship_hull | voidsteel_plate + drive_unit + control_chip |
+| dreadnought_hull | voidsteel_plate + capital_core + drive_unit |
+| carrier_hull | voidsteel_plate + capital_core + drive_unit |
+
+**Module items** (`<module>_module`, assembler-made prefabs — kept as
+items so shipyard belt inputs stay simple and module production can be
+stockpiled):
+
+| module | inputs | archetype |
+|---|---|---|
+| railgun_s | copper_coil | lean |
+| salvager | steel_plate + copper_wire | balanced |
+| repair_tool | steel_plate + copper_wire | balanced |
+| armor_plates | steel_plate (many) | material-heavy, fast |
+| maneuvering_thrusters | steel_plate + copper_coil | balanced |
+| sensor_booster | copper_wire + copper_coil | lean (an antenna, no chip) |
+| afterburner | copper_coil + steel_plate | balanced |
+| weapon_stabilizer | steel_plate + copper_coil | balanced |
+| weapon_primer | capacitor_bank + copper_coil | mid; time-heavy |
+| weapon_upgrade | control_chip + copper_coil | mid; time-heavy |
+| railgun_m | capacitor_bank + steel_plate + copper_coil | mid |
+| drone_bay | control_chip + steel_plate + copper_coil | mid |
+| railgun_l | capacitor_bank + hardened_steel + ceramic_plate | late |
+| drone_hangar | voidsteel_plate + control_chip + drive_unit | late (carrier only) |
+
+**Refactorability check** (the default technique holds): railgun_s → m
+introduces capacitor_bank, built from a subset of the small gun's inputs
+(copper_coil) plus the new base resource (silicon); the m gun otherwise
+reuses the small gun's inputs. Hulls likewise: the cruiser adds
+hardening (fed by the existing steel line) and chips (fed by the new
+quartz territory) without touching the iron/copper core.
+
+**Shortcut recipes** (drop-only assembler schematics; not every strange
+chain gets one): `iron_ore → steel_plate` (skips the ingot step on the
+highest-volume chain), `quartz → control_chip` (skips silicon),
+`iron_ingot → hardened_steel` (a nicer-ratio route past the deliberately
+awkward hardening step).
+
+Consistency is checked by `tools/verify_recipes.py` — re-run it after
+editing recipes, ship/module materials, or visuals:
 
     python dota_factory/tools/verify_recipes.py
 
 It verifies every consumed item has a producer, every item has a visuals
-entry, flags orphaned items, and prints which items are reprocessing-only
-(currently exactly advanced_alloy).
-
-## Deliberate placeholders / open questions for later passes
-
-- All new hulls have `threat.cost_formula = "0"` so enemy waves do not spawn
-  them yet (WaveSystem treats any ship with positive threat cost as wave-
-  eligible, regardless of unlock level). The balancing pass should set real
-  threat costs together with `default_modules` loadouts so waves spawn them
-  armed.
-- All new hulls and all assembler recipes are `unlock_at_station_level = -1`
-  (available from the start) to make testing easy; the balancing pass should
-  stagger these so mid/lategame recipes drop as schematics from enemy defence
-  stations.
-- Recipe quantities and durations are a first guess, deliberately roughly
-  tiered (capital hulls ~60 s, drones 4 s); the balancing pass tunes them.
-- `drone_bay` and `drone_hangar` are footprint-only placeholders: the drone
-  launching capability does not exist in the simulation yet, so they define
-  no capability section.
-- Renames in this pass: `laser_cannon_xs` → `laser_cannon_s` (the old 2x2
-  `laser_cannon_s` became `laser_cannon_m`), `armor_plate` → `armor_plates`,
-  `manuvering_thrusters` → `maneuvering_thrusters` (typo fix). Test data
-  under `bin/test/data/config` intentionally still uses the old ids — it is
-  an independent fixture set.
+entry, flags orphaned items, and prints which items are
+reprocessing-only (currently exactly voidsteel).

docs/replay_design.md

@@ -55,7 +55,7 @@ data, not the UI gesture. Example: placing a miner records
 One command per sim-mutating operation (the complete mutation surface):
 
 - `PlaceBuilding`
-- `Demolish`
+- `Deconstruct`
 - `RotateInPlace`
 - `SetRecipe`
 - `SetShipLayout`
@@ -125,7 +125,7 @@ the only way production code can reach them is `apply(command)`.
 > `BeltSystem` directly, and every production `buildings()`/`belts()` call is a const query.
 > So:
 >
-> - `Simulation::tryPlaceBuilding`, `demolish`, and `applySchematicChoice` are **private**.
+> - `Simulation::tryPlaceBuilding`, `deconstruct`, and `applySchematicChoice` are **private**.
 > - The mutable subsystem accessors are private and renamed `buildingsMutable()` /
 >   `beltsMutable()`; only `const BuildingSystem& buildings() const` / `belts() const` are
 >   public (queries). UI query sites bind to the const overload unchanged.
@@ -377,7 +377,7 @@ The whole feature rests on a deterministic sim, so prove that before building on
 
 Reshape mutations to flow through one path; behaviour unchanged.
 
-- Defined `Command` base + derived types (`PlaceBuilding`, `Demolish`, `RotateInPlace`,
+- Defined `Command` base + derived types (`PlaceBuilding`, `Deconstruct`, `RotateInPlace`,
   `SetRecipe`, `SetShipLayout`, `SetSiteSplitterFilters`, `SetSplitterFilters`,
   `ClearBeltTiles`, `ApplySchematicChoice`, `Reset`) in `lib`, each with a `playerId` (always 0
   now). `PlaceBuilding` is atomic (carries optional config — see the refinement note above).
@@ -390,11 +390,11 @@ Reshape mutations to flow through one path; behaviour unchanged.
   before the tick batch (runs even at 0× → build-while-paused preserved). A drained `Reset`
   triggers the view reset.
 - Refactored every UI mutation site: `GameWorldView` owns the `CommandManager` and enqueues
-  directly; `MainWindow` and `SelectedBuildingPanel` emit `CommandRequestedEvent` (carrying a
+  directly; `MainWindow` and `SelectionPanel` emit `CommandRequestedEvent` (carrying a
   `shared_ptr<const Command>`) which `GameWorldView` subscribes to and enqueues.
 - **Files:** new `lib/sim/Command.h`, `CommandManager.{h,cpp}`; `CommandRequestedEvent.h`;
   `Simulation.{h,cpp}` (`apply`); `GameWorldView.{h,cpp}`, `MainWindow.cpp`,
-  `SelectedBuildingPanel.cpp`; new `CommandTest.cpp`.
+  `SelectionPanel.cpp`; new `CommandTest.cpp`.
 - **Exit criteria:** game plays identically (including build-while-paused); determinism test
   still passes; `[command]` equivalence tests pass; no production call site can mutate the sim
   directly (compile-enforced: the `Simulation` mutators are private, tests excepted via

docs/requirements.md

@@ -4,13 +4,13 @@
 
 Config files use the TOML format. The following config files drive game parameters:
 
-- **world.toml** — world dimensions, region widths, expansion amounts, building refund percentage, wave timing, boss wave timing, belt speed, starting building blocks, departure interval, ship orbit factor, rally orbit radius, scrap-per-threat conversion, combat target-selection parameters (target score formula, overclaim penalty formula, target hysteresis), artifact chance formula, and artifact win count.
-- **buildings.toml** — building block cost and construction time per building type.
-- **recipes.toml** — crafting recipes: inputs, outputs, quantities, durations, and reprocessing plant probabilities. Assembler recipe entries may optionally define `unlock_at_station_level` (integer): -1 means the recipe is explicitly unlocked at game start; a value ≥ 0 means the recipe starts locked and a schematic for it can be awarded via defence station destruction (see REQ-LOCK-EXPLICIT, REQ-DEF-SCHEMATIC-DROP).
-- **ships.toml** — per schematic: a human-readable display name (used in the UI), hull stats (HP, max linear speed, sensor range, main acceleration, maneuvering acceleration, angular acceleration, max rotation speed) as plain values, required build materials, the station level at which the schematic becomes available for unlock (`unlock_at_station_level`; -1 means the player starts with the schematic already unlocked), a layout grid defining the ship's module slots, and a `default_modules` list used for enemy wave ships (see REQ-WAV-DEFAULT-MODULES).
-- **modules.toml** — per module type: id, surface mask, materials list, production time, fill color, glyph, the station level at which the schematic becomes available for unlock (`unlock_at_station_level`; -1 means the player starts with the module schematic already unlocked), and an optional capability section and/or stat modifier formulas. A module with a capability section (`[module.weapon]`, `[module.salvage]`, or `[module.repair]`) containing base stat formulas is a **capability module** that grants the ship a weapon, salvage bay, or repair tool per instance (see REQ-MOD-CONFIG for the full list of formulas per capability type). A module with only `added_*`/`multiplied_*` formulas is a **passive module** that modifies stats on the ship or on capability module instances (see REQ-MOD-STAT-CALC).
+- **world.toml** — world dimensions, region widths, expansion amounts, building refund percentage, building deconstruction time, wave timing, boss wave timing, belt speed, starting building blocks, departure interval, ship orbit factor, rally orbit radius, scrap-per-threat conversion, combat target-selection parameters (target score formula, overclaim penalty formula, target hysteresis), artifact chance formula, artifact win count, view pan speeds (slow and fast horizontal pan speed and pan ramp band width), an optional building blocks tooltip string (shown as the header bar's building blocks stock hover tooltip, REQ-UI-BLOCKS-TOOLTIP; omitted when unset), and an optional artifact tooltip string (shown as the header bar's artifact count hover tooltip, REQ-UI-ARTIFACTS-TOOLTIP; omitted when unset).
+- **buildings.toml** — building block cost and construction time per building type, plus an optional tooltip description string per building type (shown as the build button's hover tooltip, REQ-UI-BUILD-TOOLTIP; omitted when unset). Whether a building type is available from game start or must be unlocked during play is not defined here but in **unlocks.toml** (REQ-LOCK-EXPLICIT): a building type granted by an unlock group starts locked and is hidden from the build menu until its group is awarded (REQ-LOCK-BUILDING).
+- **recipes.toml** — crafting recipes: inputs, outputs, quantities, durations, and reprocessing plant probabilities. Assembler recipe entries may optionally define `unlocked_at_start` (boolean, default false): when true the recipe is available from game start regardless of the implicit item graph — used for base recipes that no schematic's materials reach (such as building blocks; see REQ-LOCK-IMPLICIT). Which assembler recipes must instead be awarded during play (explicitly gated) is defined in **unlocks.toml**, not here (REQ-LOCK-EXPLICIT); every remaining assembler recipe is implicitly unlocked through the item graph (REQ-LOCK-IMPLICIT).- **ships.toml** — per schematic: a human-readable display name (used in the UI), hull stats (HP, max linear speed, sensor range, main acceleration, maneuvering acceleration, angular acceleration, max rotation speed) as plain values, required build materials, a layout grid defining the ship's module slots, and a `default_modules` list used for enemy wave ships (see REQ-WAV-DEFAULT-MODULES). Whether a ship schematic is available from game start or must be unlocked during play is defined in **unlocks.toml** (REQ-LOCK-EXPLICIT), not here.
+- **modules.toml** — per module type: id, surface mask, materials list, production time, fill color, glyph, an optional tooltip description string (shown as the module selection button's hover tooltip, REQ-MOD-UI-MODULE-TOOLTIP; omitted when unset), and an optional capability section and/or stat modifier formulas. Whether a module schematic is available from game start or must be unlocked during play is defined in **unlocks.toml** (REQ-LOCK-EXPLICIT), not here. A module with a capability section (`[module.weapon]`, `[module.salvage]`, or `[module.repair]`) containing base stat formulas is a **capability module** that grants the ship a weapon, salvage bay, or repair tool per instance (see REQ-MOD-CONFIG for the full list of formulas per capability type). A module with only `added_*`/`multiplied_*` formulas is a **passive module** that modifies stats on the ship or on capability module instances (see REQ-MOD-STAT-CALC).
+- **unlocks.toml** — unlock groups: each `[[unlock]]` entry names a group of ship schematics, module schematics, building types, and/or assembler recipes that are awarded together from a single defence station drop (see Unlock Group Format, REQ-LOCK-EXPLICIT, REQ-DEF-SCHEMATIC-DROP). Anything not granted by any unlock group is available from game start.
 - **stations.toml** — HP, damage, range, fire rate, and scrap drop for player and enemy defence stations, defined as formulas of station level.
-- **visuals.toml** — rendering-only config (not game parameters): fill and outline colors and glyphs for every building type, item type, ship schematic, and station type; a distinct beam color per tool type (weapon, repair, salvage) and beam width; overlay and toast colors. Loaded by the UI at startup; the simulation does not read it.
+- **visuals.toml** — rendering-only config (not game parameters): fill and outline colors and glyphs (identity labels; used in the world for building types not covered by an icon and as the fallback when an icon file is missing — REQ-UI-WORLD-ICON) for every building type, item type, ship schematic, and station type; for items, the `fill` and `outline` colors are drawn as the item's belt/port square and serve as the fallback when the item's icon file is missing (REQ-UI-ITEM-ICON); a distinct beam color per tool type (weapon, repair, salvage) and beam width; overlay and toast colors; and building status light colors (grey, green, red, and yellow fills plus the outline color, REQ-UI-STATUS-LIGHT). Loaded by the UI at startup; the simulation does not read it.
 - **ship_layouts.toml** — named layout blueprints per ship type; written and read by the application to persist the layout blueprint panel (REQ-MOD-UI-BLUEPRINT-PANEL through REQ-MOD-UI-BLUEPRINT-FILE-LOAD). Not a game parameter file; the simulation does not read it.
 
 - REQ-CFG-RELOAD: When the player triggers a Restart (REQ-UI-GAME-MENU), all config files are reloaded from disk before the simulation is reset to its initial state. Formula strings are recompiled at that point. This allows config edits made while the application is running to take effect without a full application restart.
@@ -65,10 +65,32 @@ Modules in `modules.toml` define a `surface_mask` — a list of strings that des
 - `O` — module cell: must be placed on an unoccupied buildable cell (`O`) of the ship's layout.
 - `X` — ignored cell: may overlap any cell (non-buildable, unoccupied buildable, or occupied buildable) or extend outside the layout grid entirely.
 
+### Unlock Group Format
+
+Unlock groups in `unlocks.toml` define what the player can be awarded from defence station drops (REQ-DEF-SCHEMATIC-DROP); by their absence they also define what is available from game start (REQ-LOCK-EXPLICIT). Each entry:
+
+```toml
+[[unlock]]
+id = "salvage_operations"           # unique unlock-group id
+station_level = 2                   # eligible once a destroyed station set's level >= this
+requires = []                       # prerequisite unlock-group ids (REQ-LOCK-PREREQ); default empty
+ships = []                          # ship schematic ids granted (from ships.toml)
+modules = ["salvager"]              # module schematic ids granted (from modules.toml)
+buildings = ["salvage_bay"]         # building type ids granted (from buildings.toml)
+recipes = []                        # assembler recipe ids granted (from recipes.toml)
+```
+
+- `id` — unique identifier of the unlock group; referenced by other groups' `requires`. Its display name in the schematic choice dialog is derived from the id (same convention as building, module, and recipe ids); there is no separate name field for now.
+- `station_level` — the minimum destroyed enemy defence station level at which this group becomes eligible to drop (REQ-DEF-SCHEMATIC-DROP).
+- `requires` — optional list of prerequisite unlock-group ids that must already have been awarded before this group can drop (REQ-LOCK-PREREQ). Defaults to empty.
+- `ships`, `modules`, `buildings`, `recipes` — the ids granted when this group is awarded. Each list defaults to empty, but a group must grant at least one item overall. Every id must resolve to a definition in the corresponding config file, and `recipes` ids must name **assembler** recipes. Each grantable id (ship, module, building, or assembler recipe) may be granted by **at most one** unlock group; violations fail config load (REQ-LOCK-EXPLICIT).
+
+Any ship, module, building, or assembler recipe id that appears in no unlock group's grant lists is available from game start (REQ-LOCK-EXPLICIT).
+
 ## Game World
 
 - REQ-GW-COORDS: Tile coordinates are integer `(x, y)`. The origin `(0, 0)` is the first column of space — the tile immediately to the right of the asteroid's right edge at game start, at the top of the world. X grows right; Y grows down. All asteroid tiles have `x < 0`; asteroid left-expansions add tiles at increasingly negative X. The origin never shifts.
-- REQ-GW-TILE-SIZE: Tiles are square. The tile size in pixels is derived automatically so that the world height (in tiles) exactly fills the game world view's height in pixels. Items on belts are rendered at half-tile size; when multiple items occupy the same tile they are spaced quarter-tile apart along the direction of travel and overlap, rendered in ascending order of progress — the least-progressed item is drawn first (bottom) and the furthest-progressed item is drawn last (on top).
+- REQ-GW-TILE-SIZE: Tiles are square. The tile size in pixels is derived automatically so that the world height (in tiles) exactly fills the game world view's height in pixels. Items on belts are rendered at half-tile size (drawn as a colored square carrying the item's icon, or the square alone when the item has no icon — REQ-UI-ITEM-ICON); when multiple items occupy the same tile they are spaced quarter-tile apart along the direction of travel and overlap, rendered in ascending order of progress — the least-progressed item is drawn first (bottom) and the furthest-progressed item is drawn last (on top). Items emerging from a building's output port are rendered by these same rules on that port's output belt (REQ-MAT-OUTPUT-EMERGE).
 - REQ-GW-BELT-CAPACITY: Belt tiles and tunnel entry/exit tiles each hold up to four items simultaneously, queued one behind the other in the direction of travel. Splitter tiles hold up to four items: two unassigned items (progress < 0.5, not yet routed to an output) and one item per output slot (progress ≥ 0.5, committed to a specific output direction). Output-slot items are rendered on top of unassigned items; when both output slots are occupied, their rendering order follows the clockwise port order starting from East.
 - REQ-GW-BELT-SPEED: Items on belts move at `world.toml [world].belt_speed_tiles_per_second` tiles per second (default 2).
 - REQ-GW-HEIGHT: The world height (in tiles) is read from `world.toml [world].height_tiles`.
@@ -100,62 +122,99 @@ Modules in `modules.toml` define a `surface_mask` — a list of strings that des
 - REQ-BLD-COST: The player places buildings from a build menu. Placement costs building blocks from the global stock. The cost per building type is read from `buildings.toml [[building]].cost`.
 - REQ-BLD-QUEUE: Placed buildings enter a construction queue and are built one at a time. Each building takes a duration defined in `buildings.toml [[building]].construction_time_seconds` to construct.
 - REQ-BLD-ASTEROID-ONLY: Buildings can only be placed on asteroid tiles (per surface_mask; tiles marked `S` may extend into space).
-- REQ-BLD-BUILDER-MODE: Clicking a build button activates builder mode for that building type. Builder mode is exited by right-clicking in the game world or clicking the same build button again.
+- REQ-BLD-BUILDER-MODE: Clicking a build button activates builder mode for that building type. Builder mode is exited by right-clicking in the game world or clicking the same build button again. (Exception: while a belt drag placement is in progress, right-clicking cancels that drag instead of exiting, and builder mode stays active — REQ-BLD-BELT-DRAG.)
 - REQ-BLD-GHOST: While in builder mode, a ghost of the building is rendered at the tile under the cursor, showing where it would be placed. The ghost is drawn semi-transparently in the building type's own visuals — its `fill` and `outline` colors and `glyph` from `visuals.toml` — so that different building types are visually distinguishable in builder mode rather than all looking alike. When the current cursor position is invalid, the ghost instead uses the distinct "invalid" color (REQ-BLD-PLACE-VALID), which overrides the per-building coloring.
 - REQ-BLD-ROTATE: While in builder mode, pressing Shift+R rotates the ghost 90° clockwise and R rotates it 90° counter-clockwise. Rotation affects the direction of the output port.
-- REQ-BLD-PLACE: Clicking a valid tile in builder mode places a construction site and adds it to the build queue, consuming building blocks from the global stock.
-- REQ-BLD-PLACE-VALID: A placement position is valid only if (a) every footprint cell in the rotated `surface_mask` is satisfied by the underlying terrain — `A` cells coincide with asteroid tiles, `S` cells coincide with space tiles — (b) no footprint cell overlaps an existing placed building or construction site, except as allowed by REQ-BLD-ROTATE-IN-PLACE, and (c) the player has enough building blocks to afford the building. The ghost (REQ-BLD-GHOST) is rendered in a distinct "invalid" color — overriding its per-building coloring (REQ-BLD-GHOST) — when the current cursor position fails any of these conditions.
-- REQ-BLD-ROTATE-IN-PLACE: If the ghost's footprint exactly coincides with the footprint of an existing placed building or construction site of the same building type, clicking places no new construction site and consumes no building blocks. Instead, the existing building or site is rotated to match the ghost's rotation. If the target is a construction site, its construction progress is preserved. This applies in both normal builder mode and blueprint placement mode; in blueprint placement mode it is evaluated per building in the blueprint independently — buildings in the blueprint whose footprint coincides with an existing same-type building or site are rotated in place, while the remaining buildings in the blueprint are placed as normal construction sites (subject to the usual validity checks and total cost).
-- REQ-BLD-BELT-DRAG: For belts, the player can click and drag across multiple tiles to place a construction site on each tile in one gesture.
-- REQ-BLD-TUNNEL-AUTO-SWITCH: After the player successfully places a Tunnel Entry construction site, builder mode automatically switches to Tunnel Exit (and vice versa), preserving the current ghost rotation. This makes it easy to immediately place the paired end without manually selecting the complementary type.
-- REQ-BLD-DEMOLISH: The player can demolish a placed factory building. Demolition returns `world.toml [world].refund_percentage` percent of the original building block cost (default 75%) to the global stock. Exception: if the building is still in the construction queue (not yet fully built, including the one currently being constructed), it is removed from the queue and the **full** building block cost is refunded. The HQ and player defence stations cannot be demolished.
-- REQ-BLD-SITE-CONFIG: A construction site — a building that has been placed but is still queued or under construction (REQ-BLD-QUEUE) — can be selected and configured exactly like the equivalent operational building, before it finishes building. Whatever configuration the building type supports is available on the site: the recipe for a Miner or Assembler (REQ-UI-SELECT-BUTTON), the produced-ship schematic and its module layout for a Shipyard (REQ-UI-SELECT-BUTTON, REQ-MOD-UI-PREVIEW, REQ-MOD-UI-DIALOG), and the output filters for a Splitter (REQ-BLD-SPLITTER) — all set through the same Selected Building Panel controls (REQ-UI-CONFIG-INLINE). Only currently unlocked recipes and schematics are offered, exactly as for operational buildings (REQ-LOCK-UI-RECIPE, REQ-LOCK-UI-SCHEMATIC, REQ-LOCK-UI-SPLITTER). The configuration is stored on the construction site and carries over unchanged when construction completes, so the building becomes operational already configured. A construction site has no input/output buffers and runs no production cycle, so the buffer and production-progress portions of the panel (REQ-UI-SINGLE-SELECTION, REQ-UI-PRODUCTION-PROGRESS) are not shown for it; only its construction progress (REQ-UI-CONSTRUCTION-PROGRESS) and its configuration controls appear. (Blueprint placement already applies a stored recipe or schematic to a construction site on placement per REQ-UI-BLUEPRINT-PLACE; this requirement additionally lets the player set or change that configuration directly on an existing site.)
+- REQ-BLD-PLACE: Clicking a valid tile in builder mode places a construction site and adds it to the build queue, consuming building blocks from the global stock. (For belts, placement is instead deferred to a drag gesture and happens on mouse release — REQ-BLD-BELT-DRAG.)
+- REQ-BLD-PLACE-VALID: A placement position is valid only if (a) every footprint cell in the rotated `surface_mask` is satisfied by the underlying terrain — `A` cells coincide with asteroid tiles, `S` cells coincide with space tiles — (b) no footprint cell overlaps an existing placed building or construction site, except as allowed by REQ-BLD-ROTATE-IN-PLACE (builder mode) or REQ-UI-BLUEPRINT-OVERLAP and REQ-UI-BLUEPRINT-TRANSFER (blueprint placement mode), and (c) the player has enough building blocks to afford the building. The ghost (REQ-BLD-GHOST) is rendered in a distinct "invalid" color — overriding its per-building coloring (REQ-BLD-GHOST) — when the current cursor position fails any of these conditions.
+- REQ-BLD-ROTATE-IN-PLACE: If the ghost's footprint exactly coincides with the footprint of an existing placed building or construction site of the same building type, clicking places no new construction site and consumes no building blocks. Instead, the existing building or site is rotated to match the ghost's rotation. If the target is a construction site, its construction progress is preserved. **Exception:** Tunnel Entries and Tunnel Exits are never rotated in place — re-orienting a tunnel requires deconstructing and re-placing it (REQ-BLD-TUNNEL-MODE). A tunnel ghost whose footprint coincides with an existing tunnel is therefore treated as an ordinary occupied-tile placement, which is invalid. This applies **only in normal builder mode**, including the belt drag of REQ-BLD-BELT-DRAG. Blueprint placement mode never rotates an existing building in place: there, a ghost whose footprint coincides with an existing same-type building or site is a configuration-transfer target (REQ-UI-BLUEPRINT-TRANSFER), or a compatible overlap that is left untouched (REQ-UI-BLUEPRINT-OVERLAP), or else an ordinary occupied-tile overlap, which is invalid.
+- REQ-BLD-BELT-DRAG: **Belt drag placement.** For belts, placement is a deferred drag gesture rather than immediate per-tile placement: construction sites are not placed while the cursor hovers new tiles, but only once the player releases the left mouse button. Pressing the left mouse button in the game world while in belt builder mode starts a drag anchored at the tile under the cursor. As the cursor moves, a **rectilinear (L-shaped) path** of belt tiles is computed from the anchor tile to the tile under the cursor: the path first runs along the axis **parallel to the belt's current orientation** (REQ-BLD-ROTATE) — stepping toward the cursor's coordinate on that axis to a corner tile — and then runs along the orthogonal axis to the cursor tile. When the cursor shares the anchor's row or column the path degenerates to a straight line, and when it is on the anchor tile the path is a single tile.
+  - **Snapping to a building.** When the tile under the cursor is occupied by a non-belt building or construction site (the **target**), the path does not end on that occupied tile. Instead the end tile is the tile **closest to the cursor** (by distance from the cursor position to the tile) among the tiles orthogonally adjacent to the target across one of its **input-capable edges** — any footprint edge that is not one of the target's output ports, i.e. an edge on which the target can accept an incoming item (REQ-MAT-INPUT-PORTS for buildings, REQ-MAT-ACCEPT-DIR for splitters and tunnels). The geometrically closest such tile is **always** used, even if it turns out not to be a valid belt endpoint — in that case it is previewed and applied by the ordinary rules below (invalid color and skipped if occupied by a non-belt building or invalid terrain; re-oriented if it already holds a belt). The rest of the L-shaped path is computed from the anchor to this end tile exactly as above. The end tile's belt direction points **toward the target** (across the shared input edge), overriding the "final tile keeps its incoming step" rule; this applies whether the end tile is a newly placed belt or an existing belt re-oriented in place, and is reflected both in the ghost preview and in the placement on release.
+  - **Rotating during the drag.** Rotating the belt with R / Shift+R (REQ-BLD-ROTATE) while a drag is in progress re-picks the path's primary axis immediately from the new orientation and re-derives the whole path from the anchor to the current cursor tile, without waiting for the next cursor movement.
+  - **Ghosts.** While dragging, a belt ghost (REQ-BLD-GHOST) is rendered on every path tile that would be acted on, instead of a single ghost under the cursor. Each ghost is oriented to point toward the next tile along the path toward the cursor, so the path forms one connected belt run that turns at the corner (curved belts along the path auto-derive per REQ-BLD-BELT); the final tile keeps the direction of its incoming step (unless the end tile is snapped to a building, in which case it points into the target — see **Snapping to a building**), and a single-tile path keeps the belt's current orientation. A tile occupied by only an existing belt or belt construction site is a valid target — its belt is re-oriented to follow the path — and shows a normal belt ghost. A tile occupied by a non-belt building or construction site, or otherwise an invalid belt position (REQ-BLD-PLACE-VALID), is drawn in the distinct invalid color, overriding the belt coloring. A tile whose new belt is unaffordable — the cumulative cost of the belts newly placed up to and including it exceeds the global stock — shows **no ghost at all**.
+  - **Placement on release.** No construction site is placed while dragging. On releasing the left mouse button, the path is applied in order (anchor to cursor): each cell occupied by only an existing belt or belt construction site has that belt re-oriented in place to its path direction, consuming no building blocks and preserving any construction progress (REQ-BLD-ROTATE-IN-PLACE); each empty, valid cell gets a new belt construction site, consuming building blocks from the global stock (REQ-BLD-COST). Cells occupied by a non-belt building or construction site, cells that are otherwise invalid (REQ-BLD-PLACE-VALID), and cells whose new belt can no longer be afforded once the running total has been spent are skipped. This supersedes the click-to-place of REQ-BLD-PLACE for belts, including both the single-tile case and multi-tile drags that pass over existing belts.
+  - **Right-click cancels the drag.** Right-clicking while a belt drag is in progress cancels it: the path is discarded, no construction site is placed, and belt builder mode stays active (the exception to REQ-BLD-BUILDER-MODE). Right-clicking when no drag is in progress exits builder mode as usual (REQ-BLD-BUILDER-MODE).
+- REQ-BLD-TUNNEL-MODE: **Unified tunnel build mode.** The build button bar contains a single **Tunnel** button rather than separate Tunnel Entry and Tunnel Exit buttons (REQ-UI-BUILD-BAR), activated by that button or by hotkey 3 (REQ-UI-HOTKEYS). This one builder mode places either a Tunnel Entry or a Tunnel Exit construction site depending on the hovered position, so the player never manually chooses between the two ends. Both remain distinct building types (REQ-BLD-TUNNEL-ENTRY, REQ-BLD-TUNNEL-EXIT) with their own costs and construction; only their build-menu entry point is unified.
+  - **Default type.** The ghost (REQ-BLD-GHOST) is a **Tunnel Entry** by default; clicking places a Tunnel Entry construction site (REQ-BLD-PLACE). Rotation (REQ-BLD-ROTATE) sets the ghost's facing direction as for any building.
+  - **Exit-completion match.** While the ghost is at a valid position, the game tests whether placing a **Tunnel Exit** at the hovered tile with the current ghost rotation would pair — per the pairing rules of REQ-BLD-TUNNEL-PAIR (same facing direction, within `tunnel_max_distance`, first same-direction building along the search, nearest-claim semantics) — with an existing Tunnel Entry. If so, that Entry is the **exit-completion match** and the ghost turns into a **Tunnel Exit**; clicking then places a Tunnel Exit construction site.
+  - **Entry-completion match.** The game also tests whether placing a **Tunnel Entry** at the hovered tile with the current ghost rotation would pair — again per REQ-BLD-TUNNEL-PAIR — with an existing Tunnel Exit. If so, that Exit is the **entry-completion match** and the ghost stays a Tunnel Entry.
+  - **Resolving the type.** If neither match exists, the ghost is a Tunnel Entry (the default). If only one kind of match exists, the ghost is the kind that produces it (Tunnel Exit for an exit-completion match, Tunnel Entry for an entry-completion match). If **both** an exit-completion match (an existing Entry) and an entry-completion match (an existing Exit) exist, the mode resolves to the completion whose **existing partner building is closer to the mouse cursor position** — the actual sub-tile cursor position, not the hovered tile's center — and the ghost becomes the corresponding type (a Tunnel Exit to complete the nearer Entry, or a Tunnel Entry to complete the nearer Exit). Because the comparison uses the sub-tile cursor position, when the two partners are at the same tile distance the player can move the cursor within the hovered tile to switch which end is placed. When more than one candidate qualifies on a side, the nearest qualifying partner on that side is used.
+  - **Connection preview (green).** Whenever a completion match is resolved, the matched existing partner building is highlighted green, and every tile strictly between that partner and the hovered ghost tile (along the tunnel's straight run) is marked green, previewing the connection that placing the ghost would create.
+  - **Invalid positions.** The completion tests, type switch, and green preview apply only while the hovered position is a valid placement (REQ-BLD-PLACE-VALID). At an invalid position the ordinary invalid-colored ghost is shown (REQ-BLD-GHOST) with no green preview and no switch away from the default Tunnel Entry.
+- REQ-BLD-DECONSTRUCT: The player can deconstruct a placed factory building. Deconstructing a **fully-built** factory building does not remove it instantly: it is added to the deconstruction queue (REQ-BLD-DECON-QUEUE) and, once its deconstruction completes, `world.toml [world].refund_percentage` percent of the original building block cost (default 75%) is returned to the global stock. Exception: if the building is still in the construction queue (not yet fully built, including the one currently being constructed), it is **not** queued for deconstruction but removed instantly from the construction queue, and the **full** building block cost is refunded immediately. The HQ and player defence stations cannot be deconstructed.
+- REQ-BLD-DECON-QUEUE: Fully-built factory buildings marked for demolition (REQ-BLD-DECONSTRUCT) enter a **deconstruction queue** that is processed one building at a time and runs in parallel with the construction queue (REQ-BLD-QUEUE) — the two queues advance independently and simultaneously. Each building takes `world.toml [world].deconstruction_time_seconds` (default 0.1) to deconstruct, the same duration for every building type. When a building's deconstruction completes it is removed from the world and its refund is credited (REQ-BLD-DECONSTRUCT). A building **stops operating the moment it enters the queue**: it runs no production and transports no items, and no longer participates as a live building (its tunnel pairing is re-evaluated as if it were gone, REQ-BLD-TUNNEL-PAIR), but it still physically occupies its tiles until removed, so those tiles stay blocked for placement. A queued building can be taken back out of the deconstruction queue before it is removed (REQ-BLD-DECONSTRUCT-CLICK, REQ-BLD-DECONSTRUCT-BOX) — including the one currently being deconstructed; doing so discards any deconstruction progress, credits no refund, and the building resumes operating (and re-pairs, REQ-BLD-TUNNEL-PAIR). Construction sites never enter the deconstruction queue (REQ-BLD-DECONSTRUCT). Every building in the deconstruction queue is rendered with the deconstruct tint — the `visuals.toml [overlays].deconstruct_tint` color, the same tint applied to a building hovered in deconstruct mode (REQ-UI-DECONSTRUCT-BORDER) — so queued buildings are visually distinct.
+- REQ-BLD-DECONSTRUCT-CLICK: While in deconstruct mode (REQ-UI-HOTKEYS, REQ-UI-DECONSTRUCT-BUTTON), left-clicking a placed factory building or construction site in the game world marks it for demolition, following the rules of REQ-BLD-DECONSTRUCT: a fully-built building is added to the deconstruction queue (REQ-BLD-DECON-QUEUE), and a construction site is removed instantly with the full refund. Left-clicking a fully-built building that is **already in the deconstruction queue** instead removes it from the queue (un-queues it, REQ-BLD-DECON-QUEUE), with no refund; repeated clicks on the same building therefore alternate between queueing and un-queueing it. Clicking a building that cannot be deconstructed (the HQ or a player defence station, per REQ-BLD-DECONSTRUCT), or clicking empty world space, has no effect. Deconstruct mode stays active after each action so the player can continue without re-entering the mode; it is exited via the Q toggle (REQ-UI-HOTKEYS) or the Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON).
+- REQ-BLD-DECONSTRUCT-BOX: While in deconstruct mode (REQ-UI-HOTKEYS, REQ-UI-DECONSTRUCT-BUTTON), the player can click and drag a selection box in the game world. A selection rectangle is drawn while dragging, using the same box-drag gesture and coverage semantics as the multi-select box (REQ-UI-MULTI-SELECT). On mouse up, following the rules of REQ-BLD-DECONSTRUCT: every construction site covered by the box is removed instantly with the full refund; and among the fully-built deconstructible buildings covered by the box, if **all** of them are already in the deconstruction queue they are all removed from it (un-queued, REQ-BLD-DECON-QUEUE), otherwise every covered building not yet in the queue is added to the deconstruction queue (already-queued ones stay). Buildings that cannot be deconstructed (the HQ and player defence stations, per REQ-BLD-DECONSTRUCT) are excluded from the box demolition; ships and defence stations are never affected.
+- REQ-BLD-SITE-CONFIG: A construction site — a building that has been placed but is still queued or under construction (REQ-BLD-QUEUE) — can be selected and configured exactly like the equivalent operational building, before it finishes building. Whatever configuration the building type supports is available on the site: the recipe for a Miner, Assembler, Smelter or Reprocessing Plant (REQ-UI-SELECT-BUTTON, REQ-BLD-AUTO-RECIPE), the produced-ship schematic and its module layout for a Shipyard (REQ-UI-SELECT-BUTTON, REQ-MOD-UI-PREVIEW, REQ-MOD-UI-DIALOG), and the output filters for a Splitter (REQ-BLD-SPLITTER) — all set through the same selection panel controls (REQ-UI-CONFIG-INLINE). Only currently unlocked recipes and schematics are offered, exactly as for operational buildings (REQ-LOCK-UI-RECIPE, REQ-LOCK-UI-SCHEMATIC, REQ-LOCK-UI-SPLITTER). The configuration is stored on the construction site and carries over unchanged when construction completes, so the building becomes operational already configured. A construction site has no input/output buffers and runs no production cycle, so the buffer and production-progress portions of the panel (REQ-UI-SINGLE-SELECTION, REQ-UI-PRODUCTION-PROGRESS) are not shown for it; only its construction progress (REQ-UI-CONSTRUCTION-PROGRESS) and its configuration controls appear. (Blueprint placement already applies a stored recipe or schematic to a construction site on placement per REQ-UI-BLUEPRINT-PLACE; this requirement additionally lets the player set or change that configuration directly on an existing site.)
 
 ## Building Types
 
 - REQ-BLD-MINER: **Miner** (2×2): The player selects which ore type it extracts. Each ore type corresponds to a `recipes.toml [[recipe]]` entry with `building = "miner"`, defining the output item and `duration_seconds`. Every asteroid tile is equivalent for mining — any miner can produce any ore type based solely on its selected recipe. Ore never depletes. Only implicitly unlocked ore-type recipes are available for selection (REQ-LOCK-UI-RECIPE).
-- REQ-BLD-SMELTER: **Smelter** (2×2): Converts ore or scrap into basic materials. No recipe selection required. Inputs, outputs, and rates are defined in `recipes.toml [[recipe]]` entries with `building = "smelter"`.
+- REQ-BLD-SMELTER: **Smelter** (2×2): Converts ore or scrap into basic materials. Its recipe is selected as any other building's is, except that it also picks one for itself from the first material it is offered (REQ-BLD-AUTO-RECIPE). Inputs, outputs, and rates are defined in `recipes.toml [[recipe]]` entries with `building = "smelter"`.
 - REQ-BLD-ASSEMBLER: **Assembler** (3×3): The player selects a recipe from the config-defined crafting tree. Produces the selected output item at the rate defined in the corresponding `recipes.toml [[recipe]]` entry with `building = "assembler"`. Only implicitly unlocked recipes are available for selection (REQ-LOCK-UI-RECIPE).
-- REQ-BLD-REPROCESSING: **Reprocessing Plant** (3×3): Consumes scrap per cycle and produces exactly one higher-level intermediate product per cycle via weighted random pick. The input quantity, possible output items, per-output weights, and amounts are defined in `recipes.toml [[recipe]]` entries with `building = "reprocessing_plant"` (`inputs`, `outputs[].item`, `outputs[].amount`, `outputs[].weight`). Weights are normalized at load time; their sum does not need to equal 1. The output is rolled at cycle start (see REQ-MAT-CYCLE); the pool of eligible outputs is restricted to implicitly unlocked item types (REQ-LOCK-REPROCESSING-POOL). The output buffer holds at most one cycle's output — see REQ-MAT-OUTPUT-BUFFER-REPROCESSING.
-- REQ-BLD-SHIPYARD: **Shipyard** (4×2): The player selects a schematic. When all required materials — the ship's base materials (`[ship.schematic].materials`) plus the materials of all modules in the configured layout (REQ-MOD-MATERIALS) — are present in its input buffer, the shipyard consumes them and begins a production cycle lasting the ship's base `[ship.schematic].production_time_seconds` plus the sum of production times contributed by all module instances in the configured layout (REQ-MOD-PRODUCTION-TIME). One ship of that type is spawned with the configured modules when the cycle completes. The shipyard cannot start a new cycle while one is in progress. If the player confirms a layout change (REQ-MOD-UI-DIALOG) while a production cycle is in progress, the current cycle is cancelled and all consumed materials are discarded; the shipyard returns to idle with the new layout configuration.
-- REQ-BLD-SALVAGE-BAY: **Salvage Bay** (3×2): A dedicated drop-off point for salvage ships. Scrap delivered here is placed onto connected output belts.
-- REQ-BLD-BELT: **Belt** (1×1): Transports items. A belt tile has one direction (N, S, E, W) set at placement (modified by rotation). Curved belts are auto-derived: when a belt tile's outgoing direction leads into another belt whose direction is orthogonal, the downstream belt is rendered and behaves as a curve. Belt speed is defined in `world.toml [world].belt_speed_tiles_per_second` (REQ-GW-BELT-SPEED).
-- REQ-BLD-SPLITTER: **Splitter** (1×1): Distributes incoming items between two output directions. Each output can optionally have a filter (a list of item types), configurable via the selected building panel; only implicitly unlocked item types are available as filter options (REQ-LOCK-UI-SPLITTER). Routing rules:
+- REQ-BLD-REPROCESSING: **Reprocessing Plant** (3×3): Consumes scrap per cycle and produces exactly one **kind** of higher-level intermediate product per cycle via weighted random pick, in that output's configured amount (which may be more than one item). The input quantity, possible output items, per-output weights, and amounts are defined in `recipes.toml [[recipe]]` entries with `building = "reprocessing_plant"` (`inputs`, `outputs[].item`, `outputs[].amount`, `outputs[].weight`). Weights are normalized at load time; their sum does not need to equal 1. The output is rolled at cycle start (see REQ-MAT-CYCLE); the pool of eligible outputs is restricted to implicitly unlocked item types (REQ-LOCK-REPROCESSING-POOL). Its output side follows the general rules with no exception: one buffer per possible output item (REQ-MAT-OUTPUT-BUFFER), and a cycle starts only when every possible roll would fit (REQ-MAT-CYCLE) — which is also what denies the player a reroll by stalling the output belt. Like the Smelter it picks its recipe from the first material it is offered while none is set (REQ-BLD-AUTO-RECIPE).
+- REQ-BLD-AUTO-RECIPE: **Automatic recipe selection.** The Smelter and the Reprocessing Plant (REQ-BLD-SMELTER, REQ-BLD-REPROCESSING) are *auto-recipe buildings*. They carry a selected recipe and are configured exactly as a Miner or Assembler is — the same selection button and dialog (REQ-UI-SELECT-BUTTON), buffers sized for that one recipe alone (REQ-MAT-INPUT-BUFFER, REQ-MAT-OUTPUT-BUFFER), and the same pre-configuration on a construction site (REQ-BLD-SITE-CONFIG). They differ in one respect only:
+  - **Selection while none is set.** When such a building has no recipe, the first material offered at any of its input ports that some recipe of its type consumes selects that recipe; the material is then accepted as normal. This holds for every intake path — a belt, splitter or tunnel exit at an input port, and a directly coupled producer (REQ-MAT-DIRECT-COUPLE) — because a building that accepts nothing would otherwise leave a coupled producer stuck at its port forever. The choice is deterministic: input ports are examined in order, and where several recipes of the type consume the offered material the first in config order wins.
+  - **No further switching.** Once a recipe is set the building keeps it. It does not switch when its buffers run empty, nor when a material belonging to another of its recipes arrives — that material is simply not an accepted input, exactly as for any other building.
+  - **The player is always in control.** Selecting a different recipe clears the buffers (REQ-MAT-INPUT-BUFFER, REQ-MAT-OUTPUT-BUFFER); that is how a building left holding part of a cycle nothing feeds any more is freed, and how a selection the player did not want is corrected. For these buildings the dialog's clearing option is captioned `(Auto)` rather than `(None)` (REQ-UI-SELECT-OPTIONS): it unsets the recipe and hands the building back to automatic selection.
+- REQ-BLD-SHIPYARD: **Shipyard** (4×2): The player selects a schematic. When all required materials — the ship's base materials (`[ship.schematic].materials`) plus the materials of all modules in the configured layout (REQ-MOD-MATERIALS) — are present in its input buffer, the shipyard consumes them and begins a production cycle lasting the ship's base `[ship.schematic].production_time_seconds` plus the sum of production times contributed by all module instances in the configured layout (REQ-MOD-PRODUCTION-TIME). One ship of that type is spawned with the configured modules when the cycle completes. The shipyard cannot start a new cycle while one is in progress. If the player confirms a layout change (REQ-MOD-UI-DIALOG) while a production cycle is in progress, the current cycle is cancelled and all consumed materials are discarded; the shipyard returns to idle with the new layout configuration. Confirming a layout identical to the one already configured is not a change and cancels nothing (REQ-MAT-INPUT-BUFFER).
+- REQ-BLD-SALVAGE-BAY: **Salvage Bay** (3×2): A dedicated drop-off point for salvage ships. It has a single output buffer — scrap is the only thing it ever holds — whose holding capacity is defined by the `output_buffer_capacity` field of the `salvage_bay` entry in `buildings.toml` (rather than by a production cycle, since the Salvage Bay has no recipe). A ship at the bay hands over one unit of scrap per tick while the buffer has free space; a full buffer blocks further drop-off until space frees up (consistent with the buffer-full semantics of REQ-MAT-OUTPUT-BUFFER). Held scrap is pushed onto connected output belts.
+- REQ-BLD-BELT: **Belt** (1×1): Transports items. A belt tile has one direction (N, S, E, W) set at placement (modified by rotation). Curved belts are auto-derived: when a belt tile's outgoing direction leads into another belt whose direction is orthogonal, the downstream belt is rendered and behaves as a curve. Belt speed is defined in `world.toml [world].belt_speed_tiles_per_second` (REQ-GW-BELT-SPEED). A belt accepts items only through a non-output edge (REQ-MAT-ACCEPT-DIR).
+- REQ-BLD-SPLITTER: **Splitter** (1×1): Distributes incoming items between two output directions. Incoming items are accepted only through the splitter's non-output edges (REQ-MAT-ACCEPT-DIR). Each output can optionally have a filter (a list of item types), configurable via the selection panel; only implicitly unlocked item types are available as filter options (REQ-LOCK-UI-SPLITTER). Routing rules:
   - An item matching only one output's filter is routed to that output.
   - An item matching both outputs' filters is distributed by strict alternation between those outputs.
   - An item matching neither output's filter is routed to the unfiltered output. If both outputs have a filter and the item matches neither, the splitter stalls and moves no items until the situation is resolved.
   - If neither output has a filter, items are distributed by strict alternation.
   - In all alternation cases, if one output is blocked the item goes to the other output until it unblocks.
-- REQ-BLD-TUNNEL-ENTRY: **Tunnel Entry** (1×1): The sending end of a tunnel pair. The player sets a direction (N, S, E, W) at placement, rotatable with R/Shift+R. Items arriving from an adjacent belt tile whose direction points into the entry are forwarded through the tunnel to the paired Tunnel Exit (see REQ-BLD-TUNNEL-PAIR, REQ-BLD-TUNNEL-TRANSIT). If the entry is unpaired, or if the paired exit's output is blocked, the entry blocks like a full belt tile.
+- REQ-BLD-TUNNEL-ENTRY: **Tunnel Entry** (1×1): The sending end of a tunnel pair. The player sets a direction (N, S, E, W) at placement, rotatable with R/Shift+R. Items arriving from an adjacent belt tile on a non-output edge (i.e. not the mouth edge in the entry's facing direction — see REQ-MAT-ACCEPT-DIR) whose direction points into the entry are forwarded through the tunnel to the paired Tunnel Exit (see REQ-BLD-TUNNEL-PAIR, REQ-BLD-TUNNEL-TRANSIT). If the entry is unpaired, or if the paired exit's output is blocked, the entry blocks like a full belt tile.
 - REQ-BLD-TUNNEL-EXIT: **Tunnel Exit** (1×1): The receiving end of a tunnel pair. The player sets a direction at placement, rotatable with R/Shift+R. Items received from the paired Tunnel Entry emerge from the output side of the exit tile — the tile adjacent in the exit's facing direction — continuing in that direction. If the exit is unpaired or its output is blocked, it holds received items until they can advance.
-- REQ-BLD-TUNNEL-PAIR: **Tunnel pairing rules.** Pairing is re-evaluated for all Tunnel Entries whenever any Tunnel Entry or Tunnel Exit is placed or demolished.
+- REQ-BLD-TUNNEL-PAIR: **Tunnel pairing rules.** Pairing is re-evaluated for all Tunnel Entries whenever any Tunnel Entry or Tunnel Exit is placed, deconstructed, or enters or leaves the deconstruction queue (REQ-BLD-DECON-QUEUE; a tunnel end that is queued for deconstruction counts as removed for pairing).
   - A Tunnel Entry searches tile-by-tile in its facing direction for a partner. Any tunnel building (entry or exit) that faces a *different* direction is ignored and skipped. The search stops at the first tunnel building that faces the *same* direction as the searching entry.
   - If that first same-direction tunnel building is a Tunnel Exit, is within `tunnel_max_distance` tiles of the entry, and is not already paired with a closer entry, the two form a pair.
   - Otherwise the entry is unpaired.
   - Pairing is one-to-one: each Tunnel Entry pairs with at most one Tunnel Exit, and vice versa. A Tunnel Exit is claimed by the nearest Tunnel Entry that can validly reach it; all other entries for which it would otherwise qualify are unpaired.
-  - When one end of a pair is demolished, the pair is dissolved and any items currently in transit are discarded.
+  - When one end of a pair is deconstructed, the pair is dissolved and any items currently in transit are discarded.
 - REQ-BLD-TUNNEL-TRANSIT: **Tunnel transit.** Items inside a tunnel are not rendered (they travel invisibly). Transit time equals the tile-coordinate distance between entry and exit divided by `world.toml [world].belt_speed_tiles_per_second`, matching the time a chain of belt tiles of equivalent length would take. Multiple items may be in transit simultaneously, spaced as they would be on a belt chain of the same length. Clearing a tunnel entry or exit tile (REQ-UI-BELT-CLEAR) also discards all items currently in transit through that tunnel.
+- REQ-BLD-TUNNEL-SELECT-HIGHLIGHT: **Selected-tunnel connection highlight.** While a Tunnel Entry or Tunnel Exit — operational building or construction site — is part of the current selection (single selection or multi-selection, REQ-UI-MULTI-SELECT), its tunnel connection is marked green in the game world, using the same `visuals.toml [overlays].tunnel_preview` green as the placement connection preview (REQ-BLD-TUNNEL-MODE). The matching end is found by applying the pairing scan of REQ-BLD-TUNNEL-PAIR over both built tunnels **and** construction-site tunnels (site-inclusive, matching the placement preview): for a selected entry, the first same-direction tunnel within `tunnel_max_distance` along its facing direction, if it is a Tunnel Exit; for a selected exit, the first same-direction tunnel within `tunnel_max_distance` opposite its facing direction, if it is a Tunnel Entry. When a matching end is found, the entry tile, the exit tile, and every tile strictly between them (along the tunnel's straight run) are marked green. A selected tunnel with no matching end shows no green highlight (it still receives the normal selection outline). In multi-selection each selected tunnel end that has a matching end contributes its connection, and a given connection is shown whenever either of its ends is selected. The highlight is presentation-only and has no effect on the simulation.
 
 ## Material Transport & Buffers
 
-- REQ-MAT-BELT-ONLY: Materials are transported exclusively via belts, splitters, and tunnels.
-- REQ-MAT-INPUT-PORTS: A building accepts items from any adjacent belt tile on any edge of its footprint (excluding cells occupied by output port(s)) whose direction points toward the building, provided the item is an input required by the currently selected recipe and the matching per-material input buffer has free space.
-- REQ-MAT-OUTPUT-PORT: Each building has one or more fixed output port(s) defined by its surface_mask (direction determined by rotation). Produced items are placed onto the belt at the output port tile regardless of that belt's direction.
+- REQ-MAT-BELT-ONLY: Materials are transported exclusively via belts, splitters, and tunnels, with one exception: two directly adjacent buildings whose output and input ports meet transfer items straight between them without an intervening transport tile (REQ-MAT-DIRECT-COUPLE).
+- REQ-MAT-INPUT-PORTS: A building accepts items from any adjacent belt tile on any edge of its footprint (excluding cells occupied by output port(s)) whose direction points toward the building, provided the item is an input required by the currently selected recipe and the matching per-material input buffer has free space. An accepted item does not enter the building instantly; it is removed from the belt and travels inward across the input port's footprint cell on that port's own input belt before being added to the buffer (REQ-MAT-INPUT-INTAKE).
+- REQ-MAT-INPUT-INTAKE: Accepted input items travel into a building as an animation rather than vanishing off the belt instantly — the input-side mirror of REQ-MAT-OUTPUT-EMERGE. Each input port has its own **input belt** — a virtual belt tile occupying the input port's footprint cell (the body cell the feeding belt points into), oriented in the port's inward flow direction, with progress 0.0 at the outer edge adjacent to the feeding belt and 0.5 at the tile centre. It reuses the belt subsystem: movement at belt speed (REQ-GW-BELT-SPEED), item rendering and spacing (REQ-GW-TILE-SIZE), and capacity/packing (REQ-GW-BELT-CAPACITY), but restricted to the 0.0→0.5 half of the tile. This applies to every building that pulls items from adjacent belts into an input buffer (Smelter, Assembler, Reprocessing Plant, Shipyard); a building may run several input belts at once when belts feed it from more than one side. The HQ is included with the one difference noted below.
+  - **Acceptance & reservation.** The acceptance test of REQ-MAT-INPUT-PORTS is unchanged — an item is accepted only if it is a required input whose per-material input buffer has space — except that "has space" now counts both the items already buffered **and** the items of that material currently travelling on the building's input belts (reserved but not yet arrived), so the total (buffered + in-transit) never exceeds that material's buffer cap (REQ-MAT-INPUT-BUFFER). An item that fails this test is not placed on an input belt and stays on the feeding belt exactly as before, so items that are not required inputs never enter the building.
+  - **Feeding.** An accepted item is removed from the feeding belt on the same tick it would have been taken without this animation, and placed on the input belt at progress 0.0, reserving a slot in its per-material buffer. (An input belt may also be fed directly by an adjacent producer's output belt rather than by a real belt — see REQ-MAT-DIRECT-COUPLE — with the same reservation and entry rules.) A new item is placed only when the input belt's entry slot at progress 0.0 is free (per REQ-GW-BELT-CAPACITY spacing — no in-transit item within a quarter tile of 0.0). The 0.0→0.5 span holds at most three in-transit items (progress 0.0, 0.25, 0.5); the reservation limit above may permit fewer.
+  - **Travel & arrival.** An in-transit item advances from progress 0.0 to 0.5 at belt speed. On reaching progress 0.5 it leaves the input belt and is added to its per-material input buffer, turning its reservation into buffered stock; only then does it count toward starting a production cycle (REQ-MAT-CYCLE). Because the slot was reserved on entry, arrival always succeeds — there is no deadlock.
+  - **Reservation may delay production.** A reserved item occupies buffer capacity for its whole 0.0→0.5 travel without yet being consumable, so an input-starved building may briefly wait for an in-transit item to arrive before it can start a cycle. This is accepted.
+  - **Clearing.** Clearing the input buffers on a recipe or schematic change (REQ-MAT-INPUT-BUFFER) also discards any items currently travelling on the input belts and releases their reservations.
+  - **HQ.** The HQ has no input buffer (REQ-HQ-BELT-INPUT); a building block accepted at an HQ input port travels its input belt the same way but reserves nothing, and is added to the global building blocks stock (REQ-MAT-GLOBAL-STOCK) on reaching progress 0.5.
+  - **Intake rendering (no pop-out).** Mirror of the emergence rendering in REQ-MAT-OUTPUT-EMERGE: the building is rendered over the input belt, so an in-transit item is occluded while inside the footprint and is only visible as it crosses the outer edge — appearing to sink into the port. The portion inside the footprint is hidden, and the item disappears at the tile centre (progress 0.5) as it enters the buffer.
+- REQ-MAT-OUTPUT-PORT: Each building has one or more fixed output port(s) defined by its surface_mask (direction determined by rotation). Produced items do not appear on the outgoing belt instantly; each item leaves the building by first emerging across the output port tile on that port's own output belt and then transferring onto the adjacent real belt tile (REQ-MAT-OUTPUT-EMERGE). The adjacent belt's direction is otherwise unconstrained (it may flow away from the building or perpendicular to it), except that a belt oriented with its own output edge facing back into the building refuses the transfer and the item stays stuck at the port (REQ-MAT-ACCEPT-DIR, REQ-MAT-OUTPUT-EMERGE).
+- REQ-MAT-OUTPUT-EMERGE: Items emerge from a building output port as an animation rather than popping directly onto the outgoing belt. Each output port has its own **output belt** — a virtual belt tile occupying the output port tile, oriented in the port's facing direction, with progress 0.0 at the tile's inner edge and 1.0 at the outer (port) edge adjacent to the next real belt tile. It reuses the belt subsystem: movement at belt speed (REQ-GW-BELT-SPEED), item rendering and spacing (REQ-GW-TILE-SIZE), and capacity/packing (REQ-GW-BELT-CAPACITY), but restricted to the 0.5→1.0 half of the tile. This applies to every building that outputs items onto belts (Miner, Smelter, Assembler, Reprocessing Plant, Salvage Bay); it does not apply to the Shipyard, which spawns a ship rather than a belt item (REQ-SHP-SPAWN-PLAYER).
+  - **Feeding.** While the output buffers (REQ-MAT-OUTPUT-BUFFER) hold an item that has not yet begun emerging and the output belt's entry slot at progress 0.5 is free (per REQ-GW-BELT-CAPACITY spacing — no emerging item within a quarter tile of progress 0.5), the longest-waiting buffered item is placed on the output belt at progress 0.5. Items leave in the order they were produced whatever their type, so per-item-type buffers do not reorder what comes out of the port. Because only the 0.5→1.0 span is used, the output belt holds at most three emerging items (progress 0.5, 0.75, 1.0); once that span is full the building places no further items on it even if the output buffers still hold more.
+  - **Cosmetic hold.** An emerging item still counts as residing in its output buffer (REQ-MAT-GLOBAL-STOCK) for the whole animation; it only leaves the building when it transfers onto a real belt tile at progress 1.0. The output belt therefore adds no inventory capacity beyond the output buffers, and clearing them on a recipe or schematic change (REQ-MAT-OUTPUT-BUFFER) also removes any items currently emerging.
+  - **Travel & handoff.** An emerging item advances from progress 0.5 to 1.0 at belt speed. At progress 1.0 it attempts to transfer onto the adjacent real belt tile using the normal belt hand-off and accept-direction rules (REQ-MAT-OUTPUT-PORT, REQ-MAT-ACCEPT-DIR): the transfer succeeds only if a transport tile exists there, is not oriented with its output edge facing back into the building, and has free space. On success the item leaves the output buffer and becomes an ordinary item on that belt tile. If instead the output port tile is a directly adjacent building's input edge, the item transfers straight into that building (REQ-MAT-DIRECT-COUPLE).
+  - **Stuck items.** If there is no next real belt tile and no directly-coupled building (REQ-MAT-DIRECT-COUPLE), or the transfer is refused or blocked, the emerging item stops at progress 1.0 and is rendered there (still counted in the output buffer). Following items pile up behind it at progress 0.75 and 0.5 per the packing above, and once the 0.5→1.0 span is full no further items emerge until the front item transfers.
+  - **Emergence rendering (no pop-in).** An emerging item must not simply appear at progress 0.5. The output port tile's building is rendered over the output belt, so an emerging item is occluded while inside the footprint and is revealed progressively as it slides past the port edge — appearing to physically emerge from the building. The portion of the item still within the output port tile is hidden; the portion past the outer edge is drawn.
+- REQ-MAT-DIRECT-COUPLE: **Direct port coupling.** Two directly adjacent buildings whose ports meet transfer items between them with no intervening transport tile. A direct coupling exists at a shared edge where a producer building's output port tile (the tile it pushes toward, REQ-MAT-OUTPUT-PORT) is a body cell of a consumer building, and the producer's output direction carries the item across that edge into the consumer through one of the consumer's input edges (any perimeter edge other than the consumer's own output port, per REQ-MAT-INPUT-PORTS). Over a direct coupling the two virtual belts chain end to end: an item that reaches progress 1.0 on the producer's output belt at the shared edge (REQ-MAT-OUTPUT-EMERGE) is handed, instead of onto a real belt tile, directly onto the consumer's input belt at progress 0.0 (REQ-MAT-INPUT-INTAKE) and continues inward to the consumer's buffer — so the item appears to slide continuously across the shared edge from one building into the next.
+  - **Acceptance.** The hand-off obeys the consumer's normal input rules (REQ-MAT-INPUT-PORTS, REQ-MAT-INPUT-INTAKE): it succeeds only if the item is a required input of the consumer whose per-material buffer has space (reservation-aware — buffered + in-transit below the cap) and the consumer's input belt entry at progress 0.0 is free. On success the item leaves the producer's output buffer and reserves a slot in the consumer's input buffer, exactly as a belt-fed intake would. If the consumer does not accept the item — it is not one of its inputs, or the buffer is full, or the input-belt entry is occupied — the item stays stuck at the producer's output port at progress 1.0, exactly as when a downstream belt is blocked (REQ-MAT-OUTPUT-EMERGE stuck items).
+  - **Scope.** Direct coupling is the only case in which materials move between buildings without a belt, splitter, or tunnel (REQ-MAT-BELT-ONLY); it bridges only two buildings that are directly adjacent with meeting output/input ports. Transport tiles feeding a building (belt, splitter, or tunnel exit) continue to work through the normal pull, and a producer still hands off to a transport tile placed in the gap as before; a single such tile between two buildings is unaffected by this requirement.
+- REQ-MAT-ACCEPT-DIR: A transport tile (belt, splitter, tunnel entry, or tunnel exit) accepts an incoming item only through a non-output edge; an item that would enter through one of the tile's output edges is refused. For a belt or a tunnel entry/exit the sole output edge is the one in its facing direction; for a splitter either of its two output directions is an output edge. This applies both to items pushed from an adjacent transport tile and to items deposited by a building's output port (REQ-MAT-OUTPUT-PORT).
 - REQ-MAT-INPUT-BUFFER: Each building has one input buffer per required input material. Each per-material buffer holds up to twice that material's per-cycle requirement. When the player selects a new recipe or schematic, all items in all input buffers are cleared.
-- REQ-MAT-OUTPUT-BUFFER: Each building has an output buffer that holds up to twice the quantity produced by one production cycle. If the output buffer is full, production stops until space is available. When the player selects a new recipe or schematic, all items in the output buffer are cleared (relevant when the adjacent belt is jammed and items have accumulated).
-- REQ-MAT-OUTPUT-BUFFER-REPROCESSING: Exception to REQ-MAT-OUTPUT-BUFFER — the Reprocessing Plant's output buffer holds at most one cycle's output. This prevents exploits where the player stalls the output belt to force the plant to reroll.
-- REQ-MAT-CYCLE: Production cycle lifecycle. When a building is idle, it attempts to start a new cycle: (a) all required inputs must be present in the per-material input buffers, and (b) the cycle's output must fit in the output buffer. For the Reprocessing Plant, the output is picked at cycle start (weighted pick); the cycle only starts if that chosen output fits. On cycle start, inputs are consumed immediately and the production timer begins. On cycle completion, the (already-decided) output is deposited into the output buffer and the building returns to idle.
+  - **Setting a configuration to the value it already holds is a no-op.** Selecting the recipe or schematic already set, or applying a ship layout identical to the one already configured, changes nothing: buffers are not cleared, an in-progress production cycle is not cancelled (REQ-BLD-SHIPYARD), and a construction site's progress and stored settings are untouched. This holds however the setting is applied — through the selection dialog (REQ-UI-SELECT-BUTTON), the layout configuration dialog (REQ-MOD-UI-DIALOG), a blueprint placement (REQ-UI-BLUEPRINT-PLACE), or a blueprint configuration transfer (REQ-UI-BLUEPRINT-TRANSFER). Only a setting that genuinely differs has effects.
+- REQ-MAT-OUTPUT-BUFFER: Each building has **one output buffer per item its recipe can produce** — each output of a deterministic recipe, and every possible roll of a probabilistic one (REQ-BLD-REPROCESSING). Each per-material buffer holds up to twice that item's per-cycle amount, mirroring the input side (REQ-MAT-INPUT-BUFFER); a buffer's contents never occupy another item's capacity. An emerging item still occupies its buffer for the whole animation (REQ-MAT-OUTPUT-EMERGE). Whether a buffer without room stops production is decided by REQ-MAT-CYCLE. When the player selects a new recipe or schematic, all items in all output buffers are cleared (relevant when the adjacent belt is jammed and items have accumulated). Re-applying a setting the building already has clears nothing, per REQ-MAT-INPUT-BUFFER. Two buildings stand outside this rule: the Shipyard has no output buffer at all, since it spawns a ship rather than producing items (REQ-BLD-SHIPYARD), and the Salvage Bay has no recipe, so its single scrap buffer is sized by config instead (REQ-BLD-SALVAGE-BAY).
+- REQ-MAT-CYCLE: Production cycle lifecycle. When a building is idle, it attempts to start a new cycle: (a) all required inputs must be present in the per-material input buffers, and (b) **every** output the cycle could produce must fit in that item's own output buffer (REQ-MAT-OUTPUT-BUFFER). For a deterministic recipe (b) is simply its own outputs. The Reprocessing Plant rolls its output at cycle start (weighted pick, REQ-BLD-REPROCESSING), so every possible roll must fit: the roll is committed the moment the cycle begins, and a cycle whose result could not be stored must not be started at all. Testing every possibility rather than the rolled one is what keeps a stalled output belt from biasing the distribution — with one item type's buffer full the plant stops entirely instead of going on producing only the others. On cycle start, inputs are consumed immediately and the production timer begins. On cycle completion, the (already-decided) output is deposited into its output buffer and the building returns to idle.
 - REQ-MAT-GLOBAL-STOCK: The building blocks stock is the only global inventory. All other materials exist only in building buffers or on belt tiles.
 
 ## Resources
 
-- REQ-RES-SCRAP-DROP: Destroyed ships (both player and enemy) and destroyed defence stations (both player and enemy) drop scrap at their location. The scrap amount per ship is derived from the ship's threat cost (REQ-MOD-THREAT) for its as-built layout, multiplied by `world.toml [world].scrap_per_threat` (default 0.01) and rounded to the nearest integer (at least 1 for any ship whose threat cost is greater than 0); for stations it is defined as `stations.toml [player_station].scrap_drop_formula` and `[enemy_station].scrap_drop_formula`. A scrap drop carries an amount; salvage modules collect it one scrap per cycle (REQ-SHP-SALVAGE), and the drop is removed from the world once its remaining amount reaches zero or `world.toml [world].scrap_despawn_seconds` seconds have elapsed since it was dropped, whichever comes first.
-- REQ-RES-SCRAP-COLLECT: Scrap is collected by salvage ships and delivered to a Salvage Bay on the asteroid. From there it can be fed via belt into a smelter (same output as ore) or a Reprocessing Plant.
+- REQ-RES-DEBRIS-DROP: Destroyed ships (both player and enemy) and destroyed defence stations (both player and enemy) drop a piece of **debris** at their location. A piece of debris carries a scrap amount. For a ship this amount is derived from the ship's threat cost (REQ-MOD-THREAT) for its as-built layout, multiplied by `world.toml [world].scrap_per_threat` (default 0.01) and rounded to the nearest integer (at least 1 for any ship whose threat cost is greater than 0); for stations it is defined as `stations.toml [player_station].scrap_drop_formula` and `[enemy_station].scrap_drop_formula`. Salvage modules collect from a piece of debris one scrap per cycle (REQ-SHP-SALVAGE), and the debris is removed from the world once its remaining scrap amount reaches zero or `world.toml [world].debris_despawn_seconds` seconds have elapsed since it was dropped, whichever comes first.
+- REQ-RES-SCRAP-COLLECT: Scrap is collected from debris by salvage ships and delivered to a Salvage Bay on the asteroid. From there it can be fed via belt into a smelter (same output as ore) or a Reprocessing Plant.
 
 ## Ships
 
 - REQ-SHP-AUTONOMOUS: Ships are produced by shipyards and are fully autonomous once produced.
-- REQ-SHP-STATS: Base hull stats are defined as plain values in `ships.toml`: HP (`[ship.health].hp`), max linear speed (`[ship.movement].speed`), sensor range (`[ship.sensors].range`), main acceleration (`[ship.movement].main_acceleration`, tiles/s²), maneuvering acceleration (`[ship.movement].maneuvering_acceleration`, tiles/s²), angular acceleration (`[ship.movement].angular_acceleration`, rad/s²), max rotation speed (`[ship.movement].max_rotation_speed`, rad/s). Required build materials (`[ship.schematic].materials`) and the station level at which the schematic becomes available for unlock (`[[ship]].unlock_at_station_level`; -1 = player starts with the schematic already unlocked) are also defined there. Combat, salvage, and repair capabilities are provided by modules (see REQ-MOD-CONFIG). Final hull stats incorporate passive module modifiers per REQ-MOD-STAT-CALC.
+- REQ-SHP-STATS: Base hull stats are defined as plain values in `ships.toml`: HP (`[ship.health].hp`), max linear speed (`[ship.movement].speed`), sensor range (`[ship.sensors].range`), main acceleration (`[ship.movement].main_acceleration`, tiles/s²), maneuvering acceleration (`[ship.movement].maneuvering_acceleration`, tiles/s²), angular acceleration (`[ship.movement].angular_acceleration`, rad/s²), max rotation speed (`[ship.movement].max_rotation_speed`, rad/s). Required build materials (`[ship.schematic].materials`) are also defined there; whether the schematic starts unlocked or must be awarded during play is defined in `unlocks.toml` (REQ-LOCK-EXPLICIT). Combat, salvage, and repair capabilities are provided by modules (see REQ-MOD-CONFIG). Final hull stats incorporate passive module modifiers per REQ-MOD-STAT-CALC.
 - REQ-SHP-SPAWN-PLAYER: A ship produced by a shipyard spawns centered on the shipyard's output port tile.
 - REQ-SHP-SPAWN-ENEMY: Enemy ships spawn at a uniformly random position within the current enemy buffer zone — random X across the buffer's width and random Y across the world height.
 - REQ-SHP-MOVEMENT: Ships move using a physics-based model. Each ship has a velocity and a facing direction, both updated each tick. The main acceleration (`main_acceleration`) is applied along the ship's current facing direction only. The maneuvering acceleration (`maneuvering_acceleration`) can be applied in any direction independently of the facing direction, enabling lateral or braking movement without rotating. The angular acceleration (`angular_acceleration`) controls how quickly the ship rotates. Linear speed is capped at the ship's `speed` value; rotation rate is capped at the ship's `max_rotation_speed` value. Ship position refers to the ship's center for all range, sensor, and attack checks.
@@ -169,14 +228,14 @@ Modules in `modules.toml` define a `surface_mask` — a list of strings that des
 - REQ-SHP-NO-COLLISION: Ships do not collide with each other or with defence stations; they may visually overlap.
 - REQ-SHP-SENSOR: A ship perceives only entities within its sensor range. Behavior is driven by what is in sensor range; entities outside sensor range are ignored.
 - REQ-SHP-FIRING: All weapons — on ships and on defence stations — fire when off cooldown and the target is within attack range. Firing emits a fire event and starts a 0.15-second damage delay (half the beam duration). When that delay expires, damage is applied to the target — unless the target has already been destroyed, in which case the damage is silently dropped. If the shooter is destroyed before the delay expires, damage is still applied when the delay expires. There is no projectile entity and no intervening collision. The weapon's cooldown begins at the moment of firing, not at damage application.
-- REQ-SHP-FIRING-BEAM: Each weapon fire event (REQ-SHP-FIRING), repair-tool activation (REQ-SHP-REPAIR), and salvage activation (REQ-SHP-SALVAGE) produces a visual beam drawn from the acting ship's position to the target for 0.3 seconds; repair and salvage beams have the same duration as weapon beams. The beam is rendered in the tool type's beam color from `visuals.toml` (a distinct color for weapon, repair, and salvage beams). The beam endpoint is not the target's center but a point randomly offset from it: the offset direction is uniformly random and the offset magnitude is uniformly random up to half the target's visual size (for ships: half their rendered radius; for buildings/stations: half the shorter side of their tile footprint, in world units; for a scrap pile: half its rendered size). The offset is chosen once per activation event and held fixed for the beam's lifetime. The beam is a pure rendering effect and has no simulation state (does not block movement, does not re-apply its effect over its lifetime). Beams follow the acting ship and target positions if either moves during the 0.3-second window. The beam is rendered for its full 0.3-second duration even if the acting ship or target is destroyed before it expires.
+- REQ-SHP-FIRING-BEAM: Each weapon fire event (REQ-SHP-FIRING), repair-tool activation (REQ-SHP-REPAIR), and salvage activation (REQ-SHP-SALVAGE) produces a visual beam drawn from the acting ship's position to the target for 0.3 seconds; repair and salvage beams have the same duration as weapon beams. The beam is rendered in the tool type's beam color from `visuals.toml` (a distinct color for weapon, repair, and salvage beams). The beam endpoint is not the target's center but a point randomly offset from it: the offset direction is uniformly random and the offset magnitude is uniformly random up to half the target's visual size (for ships: half their rendered radius; for buildings/stations: half the shorter side of their tile footprint, in world units; for a piece of debris: half its rendered size). The offset is chosen once per activation event and held fixed for the beam's lifetime. The beam is a pure rendering effect and has no simulation state (does not block movement, does not re-apply its effect over its lifetime). Beams follow the acting ship and target positions if either moves during the 0.3-second window. The beam is rendered for its full 0.3-second duration even if the acting ship or target is destroyed before it expires.
 - REQ-SHP-COMBAT: Ships with at least one **weapon module** (player) — engage enemy ships within sensor range. When engaging an enemy, the ship orbits it at the combat orbit radius (REQ-SHP-ORBIT) rather than approaching its center.
 - REQ-SHP-RALLY: After spawning, ships with weapon modules move to and orbit the **rally point** — the midpoint between the two player defence stations (center of their Y-span, at the player defence stations' X position) — at the rally orbit radius (REQ-SHP-ORBIT). While orbiting the rally point, ships still engage any enemy that enters sensor range (switching to the combat orbit per REQ-SHP-COMBAT). Every `world.toml [world].departure_interval_seconds` seconds (default 20), all ships with weapon modules currently at the rally point depart simultaneously and begin their normal aggressive advance toward the enemy. The departure timer is global and shared across all shipyards; it is not reset by individual ship arrivals at the rally point.
-- REQ-SHP-SALVAGE: Ships with at least one **salvage module** (player) — patrol by moving forward (rightward, away from the asteroid) while searching sensor range. If scrap enters sensor range, navigate toward it by orbiting it at the salvage orbit radius (REQ-SHP-ORBIT); when it is within a module's `collection_range`, that module begins collecting from it, one scrap per cycle (see below). Once the ship's cargo pool is full, fly to a Salvage Bay and deliver (a direct approach, not an orbit — the ship must reach the bay); after delivery, resume patrol. If an enemy ship enters sensor range, the ship retreats (REQ-SHP-RETREAT) until no enemy is in sensor range, then resumes patrol — this applies regardless of whether the ship is targeting or carrying scrap. Ships with salvage modules are vulnerable to enemy ships while operating.
+- REQ-SHP-SALVAGE: Ships with at least one **salvage module** (player) — patrol by moving forward (rightward, away from the asteroid) while searching sensor range. If debris enters sensor range, navigate toward it by orbiting it at the salvage orbit radius (REQ-SHP-ORBIT); when it is within a module's `collection_range`, that module begins collecting from it, one scrap per cycle (see below). Once the ship's cargo pool is full, fly to a Salvage Bay and deliver (a direct approach, not an orbit — the ship must reach the bay); after delivery, resume patrol. If an enemy ship enters sensor range, the ship retreats (REQ-SHP-RETREAT) until no enemy is in sensor range, then resumes patrol — this applies regardless of whether the ship is targeting debris or carrying scrap. Ships with salvage modules are vulnerable to enemy ships while operating.
 
-  All salvage modules on a ship deposit into a single shared **cargo pool** whose size is the ship's cargo capacity stat (REQ-MOD-CARGO-CAPACITY). Each salvage module instance still runs its own collection cycle independently, with its own collection range (`collection_range`) and collection rate (`collection_rate`, in collection cycles per second). A module starts a collection cycle when it is off cooldown, the shared cargo pool has free space, and a scrap pile is within its `collection_range`. Free space is measured against the pool's current contents **plus the collection cycles already in flight toward the pool** (scrap claimed by cycles whose effect delay has not yet elapsed); each in-flight cycle is registered against the ship so that concurrent modules on the same ship never start more cycles than the remaining capacity can hold. Starting a cycle emits a collection beam toward that scrap pile (REQ-SHP-FIRING-BEAM) and begins a 0.15-second effect delay (half the beam duration); the module's cooldown of `1 / collection_rate` seconds begins at cycle start, not at effect application. When the delay expires, exactly 1 scrap is removed from the targeted pile and added to the ship's cargo pool — unless the pile has already been fully depleted or despawned, or the pool is now full, in which case the collection is silently dropped. A scrap pile worth more than 1 (REQ-RES-SCRAP-DROP) is depleted one scrap per cycle and persists, with its remaining amount decremented, until it is fully collected or despawns. A ship with multiple salvage modules can therefore run multiple collection cycles concurrently (one per ready module), and instances of different module types may have different ranges and rates. The ship navigates based on the maximum collection range across all installed salvage modules.
+  All salvage modules on a ship deposit into a single shared **cargo pool** whose size is the ship's cargo capacity stat (REQ-MOD-CARGO-CAPACITY). Each salvage module instance still runs its own collection cycle independently, with its own collection range (`collection_range`) and collection rate (`collection_rate`, in collection cycles per second). A module starts a collection cycle when it is off cooldown, the shared cargo pool has free space, and a piece of debris is within its `collection_range`. Free space is measured against the pool's current contents **plus the collection cycles already in flight toward the pool** (scrap claimed by cycles whose effect delay has not yet elapsed); each in-flight cycle is registered against the ship so that concurrent modules on the same ship never start more cycles than the remaining capacity can hold. Starting a cycle emits a collection beam toward that debris (REQ-SHP-FIRING-BEAM) and begins a 0.15-second effect delay (half the beam duration); the module's cooldown of `1 / collection_rate` seconds begins at cycle start, not at effect application. When the delay expires, exactly 1 scrap is removed from the targeted debris and added to the ship's cargo pool — unless the debris has already been fully depleted or despawned, or the pool is now full, in which case the collection is silently dropped. A piece of debris worth more than 1 (REQ-RES-DEBRIS-DROP) is depleted one scrap per cycle and persists, with its remaining scrap amount decremented, until it is fully collected or despawns. A ship with multiple salvage modules can therefore run multiple collection cycles concurrently (one per ready module), and instances of different module types may have different ranges and rates. The ship navigates based on the maximum collection range across all installed salvage modules.
 
-  Salvage collection cycles and delivery are processed regardless of which behavior the ship is currently executing; the salvage behavior only governs where the ship navigates (toward scrap, toward a Salvage Bay, or — when retreating — toward the rally point).
+  Salvage collection cycles and delivery are processed regardless of which behavior the ship is currently executing; the salvage behavior only governs where the ship navigates (toward debris, toward a Salvage Bay, or — when retreating — toward the rally point).
 - REQ-SHP-REPAIR: Ships with at least one **repair module** (player) — when no more urgent behavior applies, hold with the fleet (REQ-SHP-STANDBY) rather than charging the enemy, so damaged allies stay within sensor range. If a damaged player defence station or player ship enters sensor range, navigate toward it by orbiting it at the repair orbit radius (REQ-SHP-ORBIT) and repair. If an enemy ship enters sensor range, the ship retreats (REQ-SHP-RETREAT) until no enemy is in sensor range — except that it holds its ground and keeps repairing while a damaged friendly remains within sensor range (REQ-SHP-RETREAT), retreating only once there is nothing left to repair — then resumes patrol.
 
   Each repair module instance operates independently: it has its own repair rate (`repair_rate`, in repair cycles per second), per-cycle heal amount (`repair_amount_hp`), and repair range (`repair_range`). A module starts a repair cycle when it is off cooldown and a valid repair target is in range. To choose the target, the module first considers the ship's current behavior-level navigation target if that target is within the module's `repair_range` and is damaged (HP above zero and below maximum HP). If those conditions are not met — because the target is out of the module's `repair_range`, already at full health, or destroyed — the module independently searches for the nearest damaged friendly (player ship or player defence station) within its own `repair_range`. If no valid target is found within range, the module idles and starts no cycle. On starting a cycle, the module emits a repair beam toward the chosen target (REQ-SHP-FIRING-BEAM) and begins a 0.15-second effect delay (half the beam duration); the module's cooldown of `1 / repair_rate` seconds begins at cycle start, not at effect application. When the delay expires, `repair_amount_hp` HP is restored to the targeted entity, clamped to its maximum HP — unless that entity is no longer damaged or has been destroyed, in which case the heal is silently dropped. A ship with multiple repair modules can therefore run multiple repair cycles concurrently, healing different targets. Navigation is driven solely by the behavior-level target; individual module fallback targets do not affect which direction the ship moves. Repair cycles are processed regardless of which behavior the ship is currently executing.
@@ -196,7 +255,6 @@ Modules in `modules.toml` define a `surface_mask` — a list of strings that des
   - `id` — unique identifier, also used as the display name in the UI.
   - `surface_mask` — footprint within the ship layout grid (see Module Surface Mask Format).
   - `materials` — list of materials required per instance (added to the ship's build cost).
-  - `unlock_at_station_level` — the enemy defence station level at which this module's schematic becomes available for unlock; -1 means the player starts with the module schematic already unlocked.
   - `production_time_seconds` — time added to the ship's production cycle per instance.
   - `fill_color` — fill color used to render this module's cells in the layout grid.
   - `glyph` — single character rendered on this module's cells in the layout grid and preview widget.
@@ -223,14 +281,15 @@ Modules in `modules.toml` define a `surface_mask` — a list of strings that des
   2. The `production_time_seconds` of every module instance in the configured layout.
   3. For every material required (the union of the ship's base materials and all module instance materials, with quantities summed per item type): the recursive production time of that material multiplied by the required quantity (see REQ-THREAT-ITEM).
 
-- REQ-THREAT-ITEM: The threat value of an item type (in seconds) is determined by the recipe that produces it:
-  - **Miner recipe**: the recipe's `duration_seconds`.
-  - **Smelter recipe**: the recipe's `duration_seconds` plus the sum of each input's threat value multiplied by that input's required quantity.
-  - **Assembler recipe**: the recipe's `duration_seconds` plus the sum of each input's threat value multiplied by that input's required quantity.
-  - **Reprocessing-only item** (an item type that has no miner, smelter, or assembler recipe producing it, and is only obtainable via reprocessing): `(scrap_threat × scrap_per_cycle + duration_seconds) / probability`, where `scrap_threat` is the threat value of scrap (see REQ-THREAT-SCRAP), `scrap_per_cycle` is the number of scrap consumed per reprocessing cycle, `duration_seconds` is the reprocessing cycle time, and `probability` is the normalized weight of that item in the reprocessing output pool.
-  - **Multiple recipes**: if an item type can be produced by more than one non-reprocessing recipe (miner, smelter, or assembler), its threat value is the **maximum** across all such recipes. The reprocessing path is only used when no other recipe exists.
+- REQ-THREAT-ITEM: The threat value of an item type (in production-seconds **per unit**) is determined by the recipe that produces it:
+  - **Miner recipe**: `duration_seconds / output_amount`, where `output_amount` is the number of units produced per cycle.
+  - **Smelter recipe**: `(duration_seconds + Σ (input_threat × input_amount)) / output_amount`, where the sum is over all inputs.
+  - **Assembler recipe**: `(duration_seconds + Σ (input_threat × input_amount)) / output_amount`, where the sum is over all inputs.
+  - **Reprocessing-only item** (an item type that has no miner, smelter, or assembler recipe producing it, and is only obtainable via reprocessing): `(scrap_threat × scrap_per_cycle + duration_seconds) / probability`, where `scrap_threat` is the threat value of scrap (see REQ-THREAT-SCRAP), `scrap_per_cycle` is the number of scrap consumed per reprocessing cycle, `duration_seconds` is the reprocessing cycle time, and `probability` is the normalized weight of that item in the reprocessing output pool. (Reprocessing output amounts are 1 in practice, so per-unit division is already implicit in the formula.)
+  - **Multiple recipes**: if an item type can be produced by more than one non-reprocessing recipe (miner, smelter, or assembler), its threat value is the **maximum** across **all** such eligible recipes, and the threat is committed only once every eligible recipe is computable (so a shallow shortcut recipe that resolves earlier than a deeper base recipe cannot lower the item's threat). The reprocessing path is only used when no other recipe exists. If recipe cycles prevent full resolution, the max over the currently computable subset is used as a fallback.
+  - **Scrap-consuming recipe fallback**: a non-reprocessing recipe that takes `scrap` as an input participates in an item's threat computation only if no scrap-free recipe (miner, smelter, or assembler) produces that item. This mirrors the reprocessing fallback rule and prevents the scrap-to-ingot smelter recipe from inflating basic material threats via the max rule.
 
-- REQ-THREAT-SCRAP: The threat value of scrap is the constant `1 / world.toml [world].scrap_per_threat`. This is the exact inverse of the scrap-drop conversion in REQ-RES-SCRAP-DROP, so a destroyed ship drops scrap worth precisely its own threat cost. Because scrap threat is now a fixed constant, it no longer depends on any ship's threat cost, removing the potential circularity with REQ-MOD-THREAT for ships built from reprocessing-only materials.
+- REQ-THREAT-SCRAP: The threat value of scrap is the constant `1 / world.toml [world].scrap_per_threat`. This is the exact inverse of the scrap conversion in REQ-RES-DEBRIS-DROP, so a destroyed ship drops debris worth precisely its own threat cost. Because scrap threat is now a fixed constant, it no longer depends on any ship's threat cost, removing the potential circularity with REQ-MOD-THREAT for ships built from reprocessing-only materials.
 - REQ-MOD-STAT-CALC: For each stat (on the ship hull or on a capability module instance), the final value is computed as: `final = base × total_multiplier + total_additive`, where:
   - `base` is the stat's base value — the hull stat value (for hull stats) or the capability module's base stat value (for capability module stats).
   - `total_multiplier` = 1 + sum of (m_i − 1) for each multiplicative modifier m_i from all passive module instances. Each m_i is the module's multiplicative modifier value.
@@ -249,15 +308,21 @@ Modules in `modules.toml` define a `surface_mask` — a list of strings that des
 
 ### Module UI
 
-- REQ-MOD-UI-PREVIEW: When a schematic is selected in a shipyard's selected building panel, a small non-interactive **ship layout preview** widget is shown below the schematic selection button (REQ-UI-SELECT-BUTTON). The preview renders the ship's layout grid at a reduced scale: buildable cells without a module are shown as white, non-buildable cells are shown as black, and cells occupied by a module are shown in that module's `fill_color` with the module's `glyph` character. Below the preview, a "Configure" button is shown.
-- REQ-MOD-UI-DIALOG: Clicking the "Configure" button opens the **layout configuration dialog** as a modal. While the dialog is open, the game is paused (speed set to 0×). On close, the game speed is restored to what it was before the dialog was opened.
+- REQ-MOD-UI-PREVIEW: For a selected shipyard (operational building or construction site), the selection panel always shows a small non-interactive **ship layout preview** widget below the schematic selection button (REQ-UI-SELECT-BUTTON) and a "Configure" button below the preview. Both are **disabled while no schematic is selected**, and enabled once one is; the preview then shows an empty placeholder in place of a layout grid. When a schematic is selected, the preview renders the ship's layout grid at a reduced scale: buildable cells without a module are shown as white, non-buildable cells are shown as black, and cells occupied by a module are shown in that module's `fill_color` alone — no glyph, which at this scale would not be legible anyway; the layout configuration dialog's full-scale grid is where a module is identified by its glyph (REQ-MOD-UI-DIALOG). For non-shipyard buildings, neither the preview nor the "Configure" button is shown.
+- REQ-MOD-UI-DIALOG: Clicking the "Configure" button opens the **layout configuration dialog** as a modal, centered on the selection panel it was opened from (REQ-UI-PANEL-MODAL). While the dialog is open, the game is paused (speed set to 0×). On close, the game speed is restored to what it was before the dialog was opened.
 
   The dialog contains:
   - **Top**: The ship's layout grid rendered at full scale. Buildable cells are white; non-buildable cells are black. Placed modules are rendered with their `fill_color` and `glyph`. The ghost of the currently selected module is shown at the cursor position when in placement mode.
-  - **Left** (below the grid): The ship stats panel (see REQ-MOD-UI-STATS-PANEL).
-  - **Center** (below the grid): A grid of module selection buttons (one per **unlocked** module type; see REQ-DEF-SCHEMATIC-DROP) plus a "Remove" button. Each module button shows the module id and its glyph.
+  - **Left** (below the grid): The ship stats panel (see REQ-MOD-UI-STATS-PANEL), and beneath it the layout's **build cost**, so the price of a configuration is visible while it is being assembled rather than only once it has been confirmed: the total materials required for the ship — the union of the schematic's base materials and those of every placed module, summed per item type (REQ-MOD-MATERIALS) — drawn as item icons on their colored squares with their amounts (REQ-UI-ITEM-ICON), and beside them the total production time (REQ-MOD-PRODUCTION-TIME). Both update in real time as modules are placed and removed. The cost sits beside the stats panel rather than within it because a build cost belongs to a ship being configured: the same panel serves an existing ship (REQ-UI-SHIP-STATS-PANEL) and the balancing tool, neither of which costs anything.
+  - **Center** (below the grid): A grid of module selection buttons (one per **unlocked** module type; see REQ-DEF-SCHEMATIC-DROP) plus a "Remove" button. A module button shows the module's name — its `id` under the usual display convention — on its first line, and beneath it what the module costs: the icons of its `materials` items on their colored squares with their amounts (REQ-UI-ITEM-ICON) and the production time it adds, as `+<n> s` (REQ-MOD-MATERIALS, REQ-MOD-PRODUCTION-TIME). This is the same form a recipe option button uses to state what it makes (REQ-UI-SELECT-OPTIONS), and it puts the price of a module in front of the player before it is placed. The "Remove" button costs nothing and shows its caption alone.
   - **Right** (below the grid): The layout blueprint panel (see REQ-MOD-UI-BLUEPRINT-PANEL through REQ-MOD-UI-BLUEPRINT-FILE-LOAD).
-  - **Bottom**: A "Confirm" button and a "Cancel" button. Cancel discards all changes made in this dialog session and closes the dialog. Confirm applies the changes: the shipyard's configured layout is updated, the required materials and cycle time displayed in the selected building panel are recalculated, and the ship layout preview is refreshed.
+  - **Bottom**: A "Confirm" button and a "Cancel" button. Cancel discards all changes made in this dialog session and closes the dialog. Confirm applies the changes: the shipyard's configured layout is updated, the required materials and cycle time displayed in the selection panel are recalculated, and the ship layout preview is refreshed.
+
+- REQ-MOD-UI-EMPTY-PULSE: While a module is selected for placement in the layout configuration dialog (REQ-MOD-UI-DIALOG), the empty buildable cells of the layout grid pulse smoothly around their normal fill shade, oscillating between a slightly darker and a slightly brighter shade at approximately 1 Hz (one full cycle per second), to draw the player's attention to where the module can be placed. All empty buildable cells pulse in phase. When no module is selected for placement (including remove mode), empty buildable cells render at their normal static shade. Non-buildable cells and cells occupied by a placed module do not pulse.
+
+- REQ-MOD-UI-AUTO-DIALOG: When the player selects a schematic for a shipyard (operational building or construction site) through the schematic selection dialog (REQ-UI-SELECT-BUTTON), and the chosen schematic **differs** from the shipyard's current schematic, the layout configuration dialog (REQ-MOD-UI-DIALOG) opens automatically and immediately once the selection dialog closes — exactly as if the player had then clicked "Configure". Re-selecting the schematic already set does not reopen the dialog. This auto-open applies only to the manual schematic selection dialog; a schematic applied by blueprint placement (REQ-UI-BLUEPRINT-PLACE) does **not** auto-open the dialog. The player may still cancel the auto-opened dialog (REQ-MOD-UI-DIALOG), which leaves the newly selected schematic in place with its default empty layout; the "Configure" button (REQ-MOD-UI-PREVIEW) remains available to open the dialog again later.
+
+- REQ-MOD-UI-MODULE-TOOLTIP: Each module selection button in the layout configuration dialog (REQ-MOD-UI-DIALOG) shows a hover tooltip with the descriptive text defined for that module type in `modules.toml` (the optional per-module tooltip field). If a module type defines no tooltip text, its button shows no tooltip. The "Remove" button is not a module type and has no config-defined tooltip.
 
 - REQ-MOD-UI-STATS-PANEL: The **ship stats panel** in the layout configuration dialog shows the stats of the currently configured ship layout as they would be computed, incorporating all passive module modifiers per REQ-MOD-STAT-CALC. The panel updates in real time whenever modules are placed or removed in the layout grid.
 
@@ -303,43 +368,41 @@ Modules in `modules.toml` define a `surface_mask` — a list of strings that des
 - REQ-DEF-ENEMY-FIRE: Enemy defence stations automatically fire at player ships within range.
 - REQ-DEF-NO-CROSSFIRE: Enemy and player defence stations are never in each other's firing range.
 - REQ-DEF-PUSH: When both enemy defence stations in a set are destroyed, the boss countdown is advanced (REQ-WAV-BOSS-ADVANCE), the scrollable area is extended (REQ-GW-PUSH-EXPAND), a new set of enemy defence stations is placed at the new boundary, and exactly one schematic drop is awarded for the destroyed set (REQ-DEF-SCHEMATIC-DROP).
-- REQ-DEF-SCHEMATIC-DROP: Each destroyed set of enemy defence stations awards exactly one schematic drop (not one per station). The drop opens a **schematic choice dialog** — a modal dialog that pauses the game (speed set to 0×; on close, speed is restored to what it was before the dialog opened). Before drawing schematic picks, an artifact roll is made: evaluate `world.toml [world].artifact_chance_formula` with `x` set to the level of the destroyed station set, clamp the result to [0, 1], then compare against a uniform random value in [0, 1). If the roll succeeds, the dialog presents one **artifact option** plus two schematic picks drawn from the eligible pool; otherwise it presents three schematic picks. Up to three (or two, if an artifact option is present) schematic options are drawn uniformly at random **without replacement** from the eligible drop pool. If the pool contains fewer than the required number of entries, only that many schematic options are shown (the artifact option is always shown if the roll succeeded). The eligible drop pool contains:
-  - All **ship schematics** and **module schematics** whose `unlock_at_station_level` is ≥ 0 and ≤ the level of the destroyed station set, and which have not yet been unlocked.
-  - All **assembler recipe schematics** whose `unlock_at_station_level` is ≥ 0 and ≤ the level of the destroyed station set, whose output item is currently implicitly unlocked (REQ-LOCK-IMPLICIT), and which have not yet been awarded.
+- REQ-DEF-SCHEMATIC-DROP: Each destroyed set of enemy defence stations awards exactly one drop (not one per station). The drop opens a **schematic choice dialog** — a modal dialog that pauses the game (speed set to 0×; on close, speed is restored to what it was before the dialog opened). Before drawing picks, an artifact roll is made: evaluate `world.toml [world].artifact_chance_formula` with `x` set to the level of the destroyed station set, clamp the result to [0, 1], then compare against a uniform random value in [0, 1). If the roll succeeds, the dialog presents one **artifact option** plus two unlock picks drawn from the eligible pool; otherwise it presents three unlock picks. Up to three (or two, if an artifact option is present) unlock options are drawn uniformly at random **without replacement** from the eligible pool. If the pool contains fewer than the required number of entries, only that many unlock options are shown (the artifact option is always shown if the roll succeeded).
 
-  Each option in the dialog displays: the schematic name (ship `display_name` from `ships.toml`, module `id` from `modules.toml`, or the output item type for assembler recipes) and the schematic type (ship, module, or assembler recipe). The artifact option (if present) is displayed as a distinct entry with the name "Artifact".
+  The eligible pool contains every **unlock group** (REQ-LOCK-EXPLICIT) that (a) has not yet been awarded, (b) whose `station_level` is ≤ the level of the destroyed station set, and (c) every prerequisite in its `requires` list is currently satisfied (REQ-LOCK-PREREQ). Because the pool is rebuilt for each drop, an unlock group gated behind prerequisites first appears only after all of its prerequisites have themselves been awarded.
 
-  Each option additionally displays a vertical list of item names labeled "Unlocks recipes for:", showing which recipes would newly become implicitly unlocked (REQ-LOCK-IMPLICIT) if this option were selected — specifically, the output items of miner recipes and assembler recipes (without `unlock_at_station_level`) that are not currently implicitly unlocked but would become so after applying this option's effect:
-  - For a ship or module schematic, its `materials` are added to the base set per REQ-LOCK-IMPLICIT step 1a before recomputation.
-  - For an assembler recipe schematic, its output item is added to the base set per REQ-LOCK-IMPLICIT step 1b before recomputation.
+  Each option in the dialog displays the unlock group's display name — derived from its `id` (same display convention as building, module, and recipe ids) — and the list of items it would grant: its ship, module, building, and assembler-recipe ids (each shown with the same display convention as its respective selection dialog). The artifact option (if present) is displayed as a distinct entry with the name "Artifact".
 
-  Item names are deduplicated and sorted alphabetically. If no recipes would be newly unlocked, the list shows "None".
+  Each option additionally displays a vertical list of recipe lines labeled "Unlocks recipes:", showing which miner and assembler recipes would newly become implicitly unlocked (REQ-LOCK-IMPLICIT) if this option were selected — specifically, the miner recipes and implicitly-gated assembler recipes that are not currently implicitly unlocked but would become so after applying this option's effect. To compute this, all `materials` of the group's granted ship and module schematics are added to the base set per REQ-LOCK-IMPLICIT step 1a, and the output items of the group's granted assembler recipes are added per step 1b, before recomputation.
 
-  The player selects one option by clicking it. If the player selects the artifact option, the player's artifact count is incremented by 1 (REQ-WIN-ARTIFACT-COUNT) and the dialog closes; no schematic is applied. Otherwise, the selected schematic is applied and the dialog closes:
+  Each recipe is shown as a **recipe line** of the same two-row card the item production tooltip uses (REQ-UI-ITEM-TOOLTIP): the icon of the building that runs it (REQ-UI-BUILD-ICON) and the recipe's name — by its `id`, using the same display convention as the assembler recipe-selection dialog — on the first row, and the recipe drawn as the recipe summary draws it (REQ-UI-RECIPE-SUMMARY) on the second. The lines are sorted alphabetically by recipe name. The line says everything there is to say about the recipe, so nothing in this list carries a tooltip, as in the selection dialog (REQ-UI-SELECT-OPTIONS). If no recipes would be newly unlocked, the list shows "None".
 
-  For a **ship or module schematic**: it is unlocked (ship schematics unlock the corresponding shipyard selection; module schematics unlock the module type for placement in the layout configuration dialog (REQ-MOD-UI-DIALOG)).
-
-  For an **assembler recipe schematic**: the recipe is explicitly unlocked and becomes available in the assembler recipe-selection dialog (subject to REQ-LOCK-UI-RECIPE). The schematic is removed from the drop pool permanently (REQ-LOCK-EXPLICIT). The implicit unlock set is recomputed (REQ-LOCK-IMPLICIT).
+  The player selects one option by clicking it. If the player selects the artifact option, the player's artifact count is incremented by 1 (REQ-WIN-ARTIFACT-COUNT) and the dialog closes; no unlock is applied. Otherwise the selected unlock group is awarded and the dialog closes: every ship, module, building, and assembler recipe the group grants becomes unlocked at once — ship schematics unlock the corresponding shipyard selection; module schematics unlock the module type for placement in the layout configuration dialog (REQ-MOD-UI-DIALOG); building types become available in the build menu (REQ-LOCK-BUILDING); assembler recipes become available in the assembler recipe-selection dialog (subject to REQ-LOCK-UI-RECIPE). The unlock group is removed from the pool permanently (REQ-LOCK-EXPLICIT), and the implicit unlock set is recomputed (REQ-LOCK-IMPLICIT).
 
 ## Progression & Locking
 
-- REQ-LOCK-EXPLICIT: Ship schematics, module schematics, and **assembler recipe schematics** (assembler recipes in `recipes.toml` that define `unlock_at_station_level`) are **explicitly** locked or unlocked. A schematic starts unlocked if its `unlock_at_station_level` is -1; all others start locked. Locked schematics are unlocked only by REQ-DEF-SCHEMATIC-DROP. Once unlocked, a schematic is never re-locked within a run; lock states reset to their initial values on Restart (REQ-CFG-RELOAD). Unlike ship and module schematics, an assembler recipe schematic is removed from the drop pool permanently once awarded and cannot be dropped again.
+- REQ-LOCK-EXPLICIT: The unit of unlocking is an **unlock group**, defined by an `[[unlock]]` entry in `unlocks.toml` (see Unlock Group Format). Each unlock group grants a set of ship schematics, module schematics, building types, and/or assembler recipes. A ship, module, building, or assembler recipe is **locked at game start if and only if some unlock group grants it**; anything not granted by any unlock group starts unlocked. (For assembler recipes this "starts unlocked" is further governed by implicit gating — see REQ-LOCK-IMPLICIT; an assembler recipe granted by an unlock group is explicitly gated and never subject to implicit unlocking, while one flagged `unlocked_at_start` is always available.) A locked item is unlocked only by awarding its unlock group via REQ-DEF-SCHEMATIC-DROP, which grants all of the group's members at once. Once awarded, an unlock group and its members are never re-locked within a run, and the group is removed from the drop pool permanently; lock states reset to their initial values on Restart (REQ-CFG-RELOAD). Each grantable id may be granted by **at most one** unlock group; a grant id that names no defined ship/module/building/assembler-recipe, that names a non-assembler recipe, or that is granted by more than one unlock group, is a configuration error that fails config load with a descriptive message (REQ-CFG-RELOAD).
+
+- REQ-LOCK-PREREQ: An unlock group may optionally define `requires` — a list of prerequisite **unlock-group ids** that must already have been awarded before this group may enter the drop pool. A prerequisite is **satisfied** only when the unlock group it names has been awarded (REQ-LOCK-EXPLICIT). This check is applied in addition to the conditions in REQ-DEF-SCHEMATIC-DROP: a group enters the eligible pool only when its `station_level` condition is met, it has not yet been awarded, and every id in its `requires` is satisfied. `requires` defaults to empty (no prerequisites). The check is re-evaluated against the current set of awarded unlock groups every time a drop pool is built (after each REQ-DEF-SCHEMATIC-DROP and on Restart per REQ-CFG-RELOAD), so a gated group becomes eligible in the first drop after its last prerequisite is awarded. Every id listed in any `requires` must resolve to an unlock group defined in `unlocks.toml`; an id that names no such group is a configuration error that fails config load with a descriptive message (config is loaded at startup and reloaded on Restart, REQ-CFG-RELOAD). An unlock group that lists itself, or a cycle of mutually dependent prerequisites, is not a load error but can never become eligible, since no group in the cycle can be the first to be awarded.
 
 - REQ-LOCK-IMPLICIT: Item types and miner/assembler recipes are **implicitly** unlocked or locked based on the current set of unlocked ship, module, and assembler recipe schematics. The implicit unlock set is recomputed whenever any schematic changes lock state (on Restart or after REQ-DEF-SCHEMATIC-DROP). Computation:
-  1. Start with the union of: (a) all item types listed in `materials` across all currently unlocked ship schematics and all currently unlocked module schematics, and (b) the output item type of every currently explicitly unlocked assembler recipe schematic (REQ-LOCK-EXPLICIT).
-  2. For each item type in the current set: for every recipe (miner, smelter, or assembler) that produces it — skipping any assembler recipe schematic that defines `unlock_at_station_level` and is not yet explicitly unlocked — add each of that recipe's input item types to the set. If the recipe is a miner recipe or an assembler recipe that does not define `unlock_at_station_level`, mark it as implicitly unlocked. Explicitly unlocked assembler recipe schematics are available in the assembler recipe-selection dialog by virtue of REQ-LOCK-EXPLICIT; their inputs are also added to the implicit set in this step.
+  1. Start with the union of: (a) all item types listed in `materials` across all currently unlocked ship schematics and all currently unlocked module schematics, and (b) the output item type of every assembler recipe that is currently **explicitly available** — that is, either flagged `unlocked_at_start` in `recipes.toml`, or granted by an unlock group that has been awarded (REQ-LOCK-EXPLICIT).
+  2. For each item type in the current set: for every recipe (miner, smelter, or assembler) that produces it — skipping any assembler recipe that is granted by an unlock group whose group has not yet been awarded — add each of that recipe's input item types to the set. If the recipe is a miner recipe, or an assembler recipe that is not granted by any unlock group, mark it as implicitly unlocked. Assembler recipes that are explicitly available (flagged `unlocked_at_start`, or granted by an awarded unlock group) are available in the assembler recipe-selection dialog by virtue of REQ-LOCK-EXPLICIT; their inputs are also added to the implicit set in this step.
   3. Repeat step 2 until no new item types are added.
   Item types and miner/assembler recipes not reached by this process (and not explicitly unlocked) are locked. Smelter recipes participate in the traversal to propagate unlocking to their inputs but are never themselves shown in any UI dropdown.
 
 - REQ-LOCK-REPROCESSING-POOL: The pool of possible outputs for a Reprocessing Plant cycle (REQ-BLD-REPROCESSING) is restricted to item types that are currently implicitly unlocked (REQ-LOCK-IMPLICIT). Weights are renormalized over the eligible outputs. If no eligible outputs remain, the Reprocessing Plant cannot start a production cycle.
 
-- REQ-LOCK-UI-RECIPE: Locked miner ore-type recipes and assembler recipes are not shown in their respective recipe-selection dialogs (REQ-UI-SELECT-BUTTON).
+- REQ-LOCK-UI-RECIPE: Locked miner ore-type recipes and assembler recipes are not shown in their respective recipe-selection dialogs (REQ-UI-SELECT-BUTTON). Smelter and Reprocessing Plant recipes are never granted by an unlock group (REQ-LOCK-EXPLICIT restricts `recipes` grants to assembler recipes), so they are available from the start and their dialogs list them all; what gates them in practice is whether the building itself is unlocked (REQ-LOCK-BUILDING).
 
 - REQ-LOCK-UI-SCHEMATIC: Locked ship schematics are not shown in the shipyard's schematic-selection dialog (REQ-UI-SELECT-BUTTON).
 
+- REQ-LOCK-BUILDING: A building type granted by an unlock group (REQ-LOCK-EXPLICIT) is **locked** until that group is awarded. A locked building type has no button in the build button bar (REQ-UI-BUILD-BAR) and cannot be placed, selected as a build tool, or triggered by its build hotkey (REQ-UI-HOTKEYS); its button appears in the bar only once the building type is unlocked, at which point the bar re-centers. Building types not granted by any unlock group are available from game start. Lock state resets on Restart (REQ-CFG-RELOAD).
+
 - REQ-LOCK-UI-SPLITTER: Item types that are not implicitly unlocked are excluded from splitter filter dropdowns (REQ-BLD-SPLITTER).
 
-- REQ-LOCK-UI-BLUEPRINT: When a blueprint is placed (REQ-UI-BLUEPRINT-PLACE): if a stored recipe ID for a miner or assembler is currently locked, that building's recipe is left unset rather than applied; if a stored splitter filter entry refers to a locked item type, that entry is silently removed. (The analogous rule for locked ship schematics is defined in REQ-UI-BLUEPRINT-PLACE.)
+- REQ-LOCK-UI-BLUEPRINT: When a blueprint is placed (REQ-UI-BLUEPRINT-PLACE): if a building in the blueprint is of a currently locked building type (REQ-LOCK-BUILDING), that building is silently skipped — no ghost, no validity check, no construction site, and its cost is excluded from the total — exactly as if it were not part of the blueprint; if a stored recipe ID for a miner or assembler is currently locked, that building's recipe is left unset rather than applied; if a stored splitter filter entry refers to a locked item type, that entry is silently removed. (The analogous rule for locked ship schematics is defined in REQ-UI-BLUEPRINT-PLACE.)
 
 ## Threat Level & Enemy Waves
 
@@ -361,56 +424,107 @@ Modules in `modules.toml` define a `surface_mask` — a list of strings that des
 ## Asteroid Expansion
 
 - REQ-EXP-UNLOCK: The player can unlock additional asteroid tile columns to the left of the existing asteroid by spending building blocks from the global stock.
-- REQ-EXP-COST: Each expansion adds `world.toml [expansion].columns_per_expansion` columns and costs `[expansion].cost_building_blocks` building blocks.
+- REQ-EXP-COST: Each expansion adds `world.toml [expansion].columns_per_expansion` columns. The building block cost of an expansion is defined by the formula `world.toml [expansion].cost_building_blocks_formula`, where `x` is the number of expansions already purchased (0 for the first expansion, incrementing by 1 for each subsequent expansion). The formula is evaluated at purchase time and its result is floored to an integer number of building blocks.
 
 ## UI
 
 ### Layout
 
-The screen is divided into two columns: a main column (75% width) containing the header bar and game world, and a side panel column (25% width) containing the three UI panels stacked vertically:
+The screen is a single column: a header bar across the top and the game world view filling the whole area below it. There is no side panel. All three permanent UI widgets float over the game world — the build button bar (REQ-UI-BUILD-BAR) at its bottom center, the selection panel (REQ-UI-SELECTION-PANEL) beside whatever is currently selected — or wherever the player has dragged it by its header (REQ-UI-SELECTION-PANEL-DRAG) — shown only while something is selected and holding its place on the screen until the next selection, and the controls panel (REQ-UI-CONTROLS-PANEL) in its bottom-left corner, beside the build button bar and rising above it only when the two would overlap. Blueprints have no permanent screen real estate; they are reached through modal dialogs (REQ-UI-BLUEPRINT-DIALOG):
 
 ```
-+--------------------------------------+--------------+
-|             Header Bar               |              |
-+--------------------------------------+  Selected    |
-|                                      |  Building    |
-|                                      |  Panel       |
-|                                      +--------------+
-|           Game World                 |  Build       |
-|                                      |  Button      |
-|                                      |  Grid        |
-|                                      +--------------+
-|                                      |  Blueprint   |
-|                                      |  Panel       |
-+--------------------------------------+--------------+
-           (75% width)                   (25% width)
++-----------------------------------------------------------+
+|                        Header Bar                         |
++-----------------------------------------------------------+
+|                                             +-----------+ |
+|                                             | Selection | |
+|                    Game World               |   Panel   | |
+|                                             +-----------+ |
+|                                                           |
+| +----------+                                              |
+| | Controls |     +------------------+                     |
+| |  Panel   |     | Build Button Bar |                     |
++-+----------+-----+------------------+---------------------+
+                     (full window width)
 ```
 
-- REQ-UI-HEADER: The header bar spans the width of the game world column (75% of the screen width) and always shows the elapsed survival time, the current global building blocks stock, and the artifact count (REQ-WIN-ARTIFACT-COUNT) displayed as `Artifacts: x/y` (where `x` is the current artifact count and `y` is `world.toml [world].artifact_win_count`) on the left, the boss wave counter and boss countdown (REQ-UI-BOSS-STATUS) to the left of the speed buttons, and game speed controls on the right.
+- REQ-UI-HEADER: The header bar spans the full width of the game window and always shows the elapsed survival time, the current global building blocks stock, and the artifact count (REQ-WIN-ARTIFACT-COUNT) displayed as `Artifacts: x/y` (where `x` is the current artifact count and `y` is `world.toml [world].artifact_win_count`) on the left, the boss wave counter and boss countdown (REQ-UI-BOSS-STATUS) and an asteroid expansion button (REQ-UI-EXPAND-BUTTON) to the left of the speed buttons, and game speed controls on the right.
+- REQ-UI-BLOCKS-ICON: In the header bar (REQ-UI-HEADER), the global building blocks stock is displayed as `Stock: <n>` followed by the `building_block` item icon (REQ-UI-ITEM-ICON) — e.g. `Stock: 200` then a small block icon — replacing the `Building Blocks: <n>` text label. The icon is sized to the header text height. When no icon file exists for `building_block` (a missing icon is not an error, REQ-UI-ITEM-ICON), the display falls back to the `Stock: <n> Blocks` text. The hover tooltip (REQ-UI-BLOCKS-TOOLTIP) applies in either form.
+- REQ-UI-BLOCKS-TOOLTIP: The header bar's building blocks stock display (REQ-UI-HEADER) shows a hover tooltip with the descriptive text defined in `world.toml [world].building_blocks_tooltip` — intended to tell the player what building blocks are used for and how to obtain them. If the field is unset, the stock display shows no tooltip. This tooltip is distinct from the build/module button tooltips (REQ-UI-BUILD-TOOLTIP, REQ-MOD-UI-MODULE-TOOLTIP).
+- REQ-UI-ARTIFACTS-TOOLTIP: The header bar's artifact count display (REQ-UI-HEADER) shows a hover tooltip with the descriptive text defined in `world.toml [world].artifact_tooltip` — intended to tell the player what artifacts are, how they are obtained (REQ-DEF-SCHEMATIC-DROP), and that collecting `world.toml [world].artifact_win_count` of them wins the game (REQ-WIN-ARTIFACT-COUNT). If the field is unset, the artifact count display shows no tooltip. This tooltip is distinct from the building blocks tooltip (REQ-UI-BLOCKS-TOOLTIP) and the build/module button tooltips (REQ-UI-BUILD-TOOLTIP, REQ-MOD-UI-MODULE-TOOLTIP).
 - REQ-UI-BOSS-STATUS: The header bar displays, to the left of the speed buttons, the current boss wave counter (REQ-WAV-BOSS-COUNTER) and the time remaining on the boss countdown (REQ-WAV-BOSS-COUNTDOWN). The boss wave counter is shown as `Boss Wave #<x>` and the countdown as `Next boss: <M:SS>`, where `<M:SS>` is the remaining seconds formatted as whole minutes and two-digit seconds. Both values update continuously as the simulation runs.
-- REQ-UI-SPEED: The game speed controls in the header bar are buttons for 0×, 0.5×, 1×, 2×, and 4× speed. The currently active speed is shown as selected. All game simulation (production, movement, threat accumulation, wave timing) scales with the selected speed. 0× pauses the game.
-- REQ-UI-WORLD-SIZE: The game world view occupies the full height below the header bar in the main column (75% of the screen width).
-- REQ-UI-PANEL-COLUMN: The side panel column occupies 25% of the screen width and the full screen height. It is divided into three equal-height panels stacked top to bottom: selected building panel (top), build button grid (middle), and blueprint panel (bottom).
+- REQ-UI-SPEED: The game speed controls in the header bar are buttons for 0×, 0.5×, 1×, 2×, and 10× speed. The currently active speed is shown as selected. All game simulation (production, movement, threat accumulation, wave timing) scales with the selected speed. 0× pauses the game.
+- REQ-UI-PAUSE-BORDER: While the game is paused (speed 0×, whether set via the speed controls (REQ-UI-SPEED), the Space toggle (REQ-UI-HOTKEYS), or an auto-pausing modal), a vignette border is drawn around the edges of the game world view to make the paused state hard to miss. The border is black and fades in the alpha channel from fully transparent at its inner (center-facing) edge to 50% opacity at the viewport edge, over a thickness of 100 pixels (capped at half the smaller viewport dimension on very small views).
+- REQ-UI-DECONSTRUCT-BORDER: While deconstruct mode is active (REQ-UI-DECONSTRUCT-BUTTON, REQ-UI-HOTKEYS), a vignette border is drawn around the edges of the game world view to signal the mode, matching the geometry of the paused-state vignette (REQ-UI-PAUSE-BORDER): a 100-pixel thickness (capped at half the smaller viewport dimension on very small views) with the four sides meeting along mitred corner diagonals. It fades in the alpha channel from fully transparent at its inner (center-facing) edge to the deconstruct tint color at the viewport edge. The color — including its alpha, which sets the peak opacity at the viewport edge — is read from `visuals.toml [overlays].deconstruct_tint`, the same deconstruct-mode color used for the hover tint. The border is presentation-only and has no effect on the simulation. If the game is both paused and in deconstruct mode, both vignettes are drawn and compose over each other.
+- REQ-UI-EXPAND-BUTTON: The header bar shows an asteroid expansion button captioned `Expand: <x>` followed by the `building_block` item icon (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON) in place of the trailing `Blocks` word, where `<x>` is the current expansion cost computed from `world.toml [expansion].cost_building_blocks_formula` at the current number of purchased expansions (REQ-EXP-COST). When no icon file exists for `building_block`, the caption falls back to the `Expand: <x> Blocks` text. Clicking the button unlocks the next asteroid expansion (REQ-EXP-UNLOCK, REQ-GW-ASTEROID-EXPAND), spending that many building blocks from the global stock. The button is disabled when the player cannot currently afford the cost (consistent with REQ-UI-BUILD-DISABLED). The caption updates as the cost changes with each purchased expansion.
+- REQ-UI-WORLD-SIZE: The game world view occupies the full width of the game window and the full height below the header bar. No widget insets it: the build button bar (REQ-UI-BUILD-BAR), the selection panel (REQ-UI-SELECTION-PANEL), and the controls panel (REQ-UI-CONTROLS-PANEL) float over it.
+- REQ-UI-SELECTION-PANEL: The **selection panel** (the panel described under Selection Panel, REQ-UI-SINGLE-SELECTION and following) is a widget that **floats over the game world view** (REQ-UI-WORLD-SIZE), placed **beside the objects it describes** rather than at a fixed corner of the view, so it appears where the player is already looking. It is **sized to its content in both width and height**, so it grows and shrinks as the content changes. It keeps the same small margin from the view's edges that it uses as its gap from the selection.
+  - **Anchor rectangle.** The panel is placed against the screen rectangle of the selection **at the moment that selection started**: the footprint of the single object selected (a building or construction site, an actor, or a piece of debris), or, when the selection started as a multi-selection (REQ-UI-MULTI-SELECT), the bounding box of all the objects it started with.
+  - **Side.** The panel goes to the **right** of the anchor rectangle, separated from it by the panel's margin, whenever it fits within the view there. Otherwise it goes to the **left** of the anchor rectangle by that same margin. When it fits on neither side — a bounding box spanning most of the view, or an object too close to an edge — it is placed on whichever side leaves more room and then pushed inside the view. That is the one case in which the panel covers part of the selection.
+  - **Vertical placement.** The panel's **top edge is aligned with the anchor rectangle's top edge** and it extends downward. Its bottom is limited by the lowest of: the view's bottom edge less the panel's margin; and the top edge, less that margin, of the build button bar (REQ-UI-BUILD-BAR) or the controls panel (REQ-UI-CONTROLS-PANEL) — but each of those two only where the panel's own horizontal extent actually overlaps that widget's current rectangle, so a panel whose column misses them is not shortened by them. Should the panel not fit above that limit, it is shifted up, as far as the view's top margin and no further; if it still does not fit, its height is capped at the space available there and the content scrolls vertically within it.
+  - **Fixed for the life of the selection.** The anchor rectangle and the side are determined once, when the selection starts, and are not revisited while that selection lasts; the panel's own size is the only thing that may still move it (see **Resizing in place** below). The player may override the resulting position by dragging the panel's header (REQ-UI-SELECTION-PANEL-DRAG); the dragged position then takes the anchor rectangle's and the side's place for the rest of that selection. The panel **keeps its place on the screen** when the player scrolls the view (REQ-UI-SCROLL) and when a selected object moves under it (a selected ship flying away), rather than following the object — which may leave it beside nothing, or beside an object that has left the view entirely. It likewise does not move when the selection is **expanded** by adding objects or reduced by removing them (REQ-UI-MULTI-SELECT), nor when a selected object is destroyed or deconstructed. Starting a **new** selection — clicking a different object, or a box drag that replaces the selection — places the panel anew against the new anchor rectangle.
+  - **Resizing in place.** Only the anchor rectangle and the chosen side are fixed for the life of the selection (or, once the panel has been dragged, the dragged desired position — REQ-UI-SELECTION-PANEL-DRAG); the panel's geometry is **re-solved from them** whenever its content size changes (a section appearing or disappearing as the selection's state changes), the view is resized, or the build button bar's or controls panel's rectangle changes. Re-solving keeps the two edges the panel was placed by — its top edge, and the edge facing the anchor rectangle (its left edge when it sits to the right of the selection, its right edge when it sits to the left) — so the panel grows away from the selection rather than over it, and it never switches sides for as long as the selection lasts. What re-solving may change is the vertical result: growth that would take the panel outside the view or into either of those two widgets is resolved as in **Vertical placement** above, by shifting it up and capping its height, and a panel that shrinks again regains the room.
+  - **Visibility.** The panel is shown only while at least one object is selected. With an empty selection it is not shown at all (REQ-UI-EMPTY-SELECTION), leaving the full game world view visible.
+  - **Overlay behavior.** As for the build button bar (REQ-UI-BUILD-BAR): the panel occludes the strip of the game world it covers; the world view itself keeps its full extent and the view's scrolling, ghost rendering, and tile geometry are unaffected. It is drawn above the pause and deconstruct vignettes (REQ-UI-PAUSE-BORDER, REQ-UI-DECONSTRUCT-BORDER), which keep their full band underneath it, and below the modal dim (REQ-UI-MODAL-DIM), which covers the entire game window including the panel. The panel never overlaps the build button bar or the controls panel, because it stays above both wherever their rectangles meet its own; neither of them ever moves on the panel's account (REQ-UI-BUILD-BAR, REQ-UI-CONTROLS-PANEL).
+  - **Input.** Mouse events over the panel are consumed by the panel and never reach the game world: hovering it shows no builder-mode ghost at the tile beneath, and clicking it neither places a building nor changes the selection. Right-clicking the panel does not exit builder mode (REQ-BLD-BUILDER-MODE) or cancel a belt drag (REQ-BLD-BELT-DRAG). Beside the controls its content offers, the panel's own chrome offers one gesture: the header drag that moves it (REQ-UI-SELECTION-PANEL-DRAG).
+- REQ-UI-SELECTION-PANEL-DRAG: **Moving the panel by its header.** The player can move the selection panel by pressing the left mouse button on the panel's **header** (REQ-UI-SELECTION-CARD) and dragging: the panel follows the cursor for the duration of the drag and stays where it is dropped on release. The header is the whole drag handle, and no other part of the panel starts a drag.
+  - **Desired position, not resolved position.** A drag sets only the panel's **desired top-left corner** in view coordinates. Where the panel actually lands is resolved from that desired position by the rules of REQ-UI-SELECTION-PANEL, exactly as an anchor-derived position is: the panel keeps its margin from the view's edges; its bottom is limited by the top edge, less that margin, of the build button bar (REQ-UI-BUILD-BAR) and of the controls panel (REQ-UI-CONTROLS-PANEL), but each only where the panel's own horizontal extent actually overlaps that widget's current rectangle; and a panel that does not fit above that limit is shifted up as far as the view's top margin and, failing that, capped in height with its content scrolling. The player therefore cannot park the panel over either widget, and neither widget ever moves on the panel's account (REQ-UI-BUILD-BAR, REQ-UI-CONTROLS-PANEL) — stepping around them stays entirely the panel's job.
+  - **The desired position survives the resolution.** Resolving does not overwrite what the player set: the desired position is retained as dropped, so a panel that had to be shifted up or shortened returns to it as soon as the obstruction stops overlapping it — its content shrinks, the bar's button set changes (REQ-LOCK-BUILDING), the controls panel's context changes, or the view is resized. A desired position that the current view cannot honour at all is likewise kept, so enlarging the window brings the panel back to it.
+  - **What the drag replaces.** From the first drag on, the desired position replaces the anchor rectangle and the side (REQ-UI-SELECTION-PANEL) for the rest of the current selection; the panel no longer has a side and never switches to one. Re-solving (the **Resizing in place** rule of REQ-UI-SELECTION-PANEL) then keeps the top and left edges of the desired position, in place of the top edge and the edge facing the anchor, so the panel still grows away from where the player put it rather than over it. The panel may be dragged repeatedly; each drag replaces the previous desired position.
+  - **Scope: the current selection.** The desired position lasts as long as the selection it was set in — across the panel's own resizing, view resizes, and view scrolling (REQ-UI-SELECTION-PANEL), and across the selection being expanded or reduced (REQ-UI-MULTI-SELECT). Starting a **new** selection discards it: the panel is placed anew against the new anchor rectangle (REQ-UI-SELECTION-PANEL), and the player drags it again if they want it elsewhere.
+  - **Input.** The drag consumes its mouse events like every other event over the panel (REQ-UI-SELECTION-PANEL): the press, the movement, and the release never reach the game world, so dragging the header neither box-selects (REQ-UI-MULTI-SELECT) nor places belts (REQ-BLD-BELT-DRAG). The drag continues while the cursor moves outside the panel or outside the view, and ends when the left button is released, wherever that happens. A press and release on the header without movement moves nothing and has no other effect.
+  - **Presentation only.** Moving the panel is not a player command: it never enters the replay stream and has no effect on the simulation, consistent with the controls panel's collapsed state (REQ-UI-CONTROLS-PANEL). The desired position is not saved to disk.
+- REQ-UI-PANEL-MODAL: **A modal opened from the selection panel opens on the panel.** A modal the player opens from a control inside the selection panel is placed **centered on the panel's current rectangle** rather than centered on the game window, so it appears where the player is already looking and under the cursor that just clicked the control. This is the same reason the panel itself is placed beside the selection instead of at a fixed corner (REQ-UI-SELECTION-PANEL): a modal centered on the window sends the cursor back across the view and then back again. Two modals are opened from the panel — the recipe/schematic selection dialog (REQ-UI-SELECT-BUTTON), from the selection button; and the layout configuration dialog (REQ-MOD-UI-DIALOG), both from the "Configure" button (REQ-MOD-UI-PREVIEW) and when it opens automatically after a schematic change (REQ-MOD-UI-AUTO-DIALOG).
+  - **The panel's rectangle as it currently stands.** The modal is centered on where the panel actually is when the modal opens: the position resolved from the anchor rectangle (REQ-UI-SELECTION-PANEL) or, once the player has dragged the panel, the position they dragged it to (REQ-UI-SELECTION-PANEL-DRAG). The panel is always shown when one of these modals opens, since the modal is opened from a control within it (REQ-UI-EMPTY-SELECTION).
+  - **Kept inside the game window.** Should the modal, centered that way, extend past an edge of the game window, it is pushed back inside; its size is never changed to make it fit. A modal larger than the window in a dimension is instead aligned with the window's top or left edge in that dimension, so the part read first stays visible.
+  - **Placement is all that changes.** The modal is modal as before, pauses the game and restores the speed on close as before (REQ-UI-SELECT-BUTTON, REQ-MOD-UI-DIALOG), shows the dim over the entire window including the panel it sits on (REQ-UI-MODAL-DIM), and is dismissed the same way. That it covers the panel costs nothing: while it is open the panel is dimmed and takes no input anyway.
+  - **Only these modals.** Every other modal is placed as before, centered on the game window: the escape menu (REQ-UI-GAME-MENU), the blueprint save and selection dialogs (REQ-UI-BLUEPRINT-CREATE, REQ-UI-BLUEPRINT-DIALOG), and the schematic choice dialog (REQ-DEF-SCHEMATIC-DROP), none of which is opened from the panel. So is a modal opened from another modal rather than from the panel — the Create Blueprint name dialog within the layout configuration dialog (REQ-MOD-UI-BLUEPRINT-CREATE) — which is placed against the modal that opened it.
+  - **Presentation only.** The placement is computed once, when the modal opens, and is not revisited while it is open; the panel cannot move meanwhile, being behind the modal and receiving no input. It is not a player command, never enters the replay stream, and has no effect on the simulation.
+- REQ-UI-MODAL-DIM: While a modal dialog, menu, or full-screen state screen is open on top of the game, a transparent black overlay (a dim/scrim) is drawn over the **entire game window** — the header bar, the game world view, and the widgets floating over it (the build button bar, REQ-UI-BUILD-BAR, the selection panel, REQ-UI-SELECTION-PANEL, and the controls panel, REQ-UI-CONTROLS-PANEL) — behind that modal, so the game reads as inactive while the modal holds focus. The overlay is shown for every modal that auto-pauses the simulation — the escape menu (REQ-UI-GAME-MENU), the recipe/schematic selection dialog (REQ-UI-SELECT-BUTTON), the layout configuration dialog (REQ-MOD-UI-DIALOG), the schematic choice dialog (REQ-DEF-SCHEMATIC-DROP), the blueprint save dialog (REQ-UI-BLUEPRINT-CREATE), and the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG) — as well as the game-over screen (REQ-HQ-GAME-OVER) and the win screen (REQ-WIN-SCREEN), which end rather than pause the game. When modals are nested (for example the Create Blueprint name dialog (REQ-MOD-UI-BLUEPRINT-CREATE) opened from the layout configuration dialog), only a single dim is shown over the game window; nested modals do not stack additional overlays. The same applies when one modal hands directly off to another — the blueprint save dialog opening the blueprint selection dialog on confirm (REQ-UI-BLUEPRINT-CREATE): the dim persists across the handoff rather than flickering off and back on, and the simulation is not resumed in between. The dim color and opacity are read from `visuals.toml [overlays]` (a semi-transparent black modal-dim color), consistent with the other overlay colors. The overlay is presentation-only and has no effect on the simulation.
 
 ### Game World
 
-- REQ-UI-SCROLL: The player scrolls the view horizontally across the scrollable area by pressing A (scroll left) and D (scroll right).
-- REQ-UI-CONSTRUCTION-PROGRESS: Construction sites display the building's glyph centered on the footprint (same as an operational building). Below the glyph — or centered on the footprint if the building has no glyph — a construction progress percentage is shown (integer, e.g. `42%`), increasing from 0% to 100% as construction completes.
+- REQ-UI-SCROLL: The player scrolls the view horizontally across the scrollable area by pressing A (scroll left) and D (scroll right). The pan speed is not constant; it varies with the view's position per REQ-UI-SCROLL-SPEED.
+- REQ-UI-SCROLL-SPEED: The horizontal pan speed varies with position so the player crosses the empty middle of the world quickly while retaining fine control near the asteroid and near the front line. Two pan speeds are read from `world.toml [scroll]`: `pan_speed_slow_tiles_per_second` (the base speed, used while the view is over the asteroid and player buffer zone) and `pan_speed_fast_tiles_per_second` (the faster speed, used while the view is over the contest zone). Both are expressed in tiles per second and apply equally to the A and D scroll directions. The current pan speed is a function of the view's horizontal center X (REQ-GW-REGIONS defines the regions):
+  - **Flat regions:** while the view center is left of the contest zone (over the asteroid or player buffer zone) and outside any ramp band, the pan speed is the slow speed; while the view center is inside the contest zone and outside any ramp band, the pan speed is the fast speed.
+  - **Ramp bands:** a transition ramp band of width `world.toml [scroll].pan_ramp_band_width_tiles` tiles straddles each contest-zone boundary (the player defence stations on the left, the enemy defence stations on the right), centered on the boundary with half the band width on each side. While the view center is within a ramp band, the pan speed is linearly interpolated between the slow speed at the band's outer (non-contest-zone) edge and the fast speed at the band's inner (contest-zone) edge, by the view center's fractional position across the band. This produces smooth speed changes when entering and exiting the fast contest-zone range rather than an abrupt jump.
+  - **Narrow contest zone:** should the two ramp bands overlap (a contest zone narrower than the band width), each ramp is clamped at the contest-zone center so the bands do not cross; the fast plateau then reduces to a single point at the center and the peak speed there may be below the fast speed.
+
+  Because the contest-zone boundaries shift as the scrollable area grows with each push (REQ-GW-PUSH-EXPAND, REQ-GW-SCROLL-LIMIT), the ramp bands are recomputed from the current contest-zone boundaries. This is a presentation-only concern and does not affect the simulation, consistent with REQ-UI-NO-ZOOM.
+- REQ-UI-WORLD-ICON: In the game world, a building is drawn with an icon's glyph symbol centered on its footprint, in place of the letter identity glyph. The icon is an SVG loaded from `data/icons/buildings/`; only the icon's glyph is drawn in the world — in a contrasting ink (white over dark fills, dark over light fills) so it stays legible — and its colored chip background is omitted, because the footprint is already filled with the building's `visuals.toml` fill color. This applies to the production buildings (Miner, Smelter, Assembler, Reprocessing Plant, Shipyard, Salvage Bay), the HQ, and the player and enemy defence stations, wherever the identity label appears: operational buildings, construction sites (REQ-UI-CONSTRUCTION-PROGRESS), and the builder-mode and blueprint-placement ghosts. **Belts, splitters, and tunnels are excluded** — they keep their existing tile rendering so their orientation and flow stay readable (a centered icon would obscure direction). Their build-menu buttons still use icons (REQ-UI-BUILD-ICON); in particular the shared Tunnel button's `tunnel_entry.svg` is a build-button icon only, not a world icon. The directional output-port glyphs (REQ-UI-PORT-GLYPH, REQ-UI-PORT-TARGET-GLYPH) are a separate indicator and are unaffected. A building or station with no icon file falls back to its `visuals.toml` text glyph; a type with neither icon nor glyph shows no identity label. A missing icon is not an error, consistent with REQ-UI-BUILD-ICON.
+- REQ-UI-ITEM-ICON: In the game world, an item is drawn as its `visuals.toml` colored square (`fill` + `outline`, the square of REQ-GW-TILE-SIZE) carrying its **item icon** on top. The square is drawn for every item, with or without an icon: it is what gives the item contrast against the tile beneath it, and its outline is what separates neighbouring items where they overlap on a belt. The icon is a self-contained, full-color SVG (rendered as-is, unlike the glyph-only building icons of REQ-UI-WORLD-ICON), loaded at runtime from `data/icons/items/` — a sibling of the config directory, read the same way as the building icons (REQ-UI-BUILD-ICON) — one file per item type named after the item's id (e.g. `iron_ore.svg`). The square fills the item's half-tile rect, keeping the size, spacing, and draw-order rules of REQ-GW-TILE-SIZE; the icon is drawn **inset** within that rect so a frame of the square's color stays visible all around it — required because each icon's viewBox is cropped tight to its artwork, so an icon drawn at the full rect would cover the square entirely. This applies wherever an item is drawn: on belts, splitters, and tunnel ends, and while emerging from or sinking into a building port (REQ-MAT-OUTPUT-EMERGE, REQ-MAT-INPUT-INTAKE). An item type with no icon file shows the colored square alone; a missing icon is not an error, consistent with REQ-UI-BUILD-ICON. **The colored square travels with the icon into the UI.** Wherever the UI displays an item *as an item* — the selection panel's item chips (REQ-UI-SINGLE-SELECTION, REQ-UI-HQ-PANEL), the recipe summary's input and output icons (REQ-UI-RECIPE-SUMMARY), and those same icons wherever a recipe is drawn in that form: on the selection dialog's option buttons (REQ-UI-SELECT-OPTIONS), in the item production tooltip (REQ-UI-ITEM-TOOLTIP), and in the unlock-choice dialog's recipe lines (REQ-DEF-SCHEMATIC-DROP) — the icon is drawn on that same square, by the same rules: the item's `fill` and `outline` from `visuals.toml`, the icon inset within the square so a frame of the square's color stays visible all around it, and the square alone when the item has no icon file. The square fills the rect the display allots to the icon, as it fills the half-tile rect in the world. One item therefore reads the same in a panel as it does on a belt. The one exception is an **inline icon standing in for the item's name beside a number** on a line of text: the `building_block` icon in place of the word `Blocks` (REQ-UI-BLOCKS-ICON, REQ-UI-EXPAND-BUTTON, REQ-UI-BUILD-COST, REQ-UI-MULTI-SELECTION, REQ-UI-BLUEPRINT-CARD), and the `scrap` icon in place of the word `Scrap` in the debris panel's remaining-scrap value (REQ-UI-DEBRIS-PANEL, REQ-UI-FIELD-MULTI-SELECTION). There the icon is a decoration on a line of text rather than an item display: it is drawn bare, without the square, and sized to the height of the text it sits in. Where the same value is instead shown *as an item* it keeps the square, as the HQ's block stock chip does beside the header bar's bare block icon (REQ-UI-HQ-PANEL). For performance, each item icon is rasterized to a pixmap cached per target pixel size — re-rasterized only when the tile pixel size changes (e.g. on view resize) — rather than re-rendered from vector every frame.
+- REQ-UI-CONSTRUCTION-PROGRESS: Construction sites display the building's identity symbol centered on the footprint (same as an operational building) — its icon glyph, or the text glyph as a fallback (REQ-UI-WORLD-ICON). Below the symbol — or centered on the footprint if the building has neither an icon nor a glyph — a construction progress percentage is shown (integer, e.g. `42%`), increasing from 0% to 100% as construction completes.
 - REQ-UI-PORT-GLYPH: Every output port of every building is indicated by a directional glyph drawn on the port's tile. The glyph is a `>` rotated to face the port's exit direction (`>` for East, `^` for North, `<` for West, `v` for South). It is drawn at the midpoint between the tile center and the tile edge that the port exits through (i.e. halfway from center toward the exit edge). The indicator is rendered for all building states: operational buildings, construction sites, and the builder-mode ghost. Buildings with multiple output ports (e.g. splitters) show one indicator per port.
+- REQ-UI-PORT-TARGET-GLYPH: While in builder mode (REQ-BLD-BUILDER-MODE), the builder-mode ghost additionally shows, for each of the building's output ports, a directional glyph drawn centered in the port's **target cell** — the cell immediately outside the footprint that the port pushes into, i.e. the cell the surface-mask output-port indicator occupies (see Surface Mask Format). As in REQ-UI-PORT-GLYPH the glyph is a `>` rotated to face the port's exit direction (`>` East, `^` North, `<` West, `v` South), previewing where the port's output will go before placement. This is in addition to the on-tile port glyph of REQ-UI-PORT-GLYPH, and — unlike that indicator — is shown only for the builder-mode ghost, not for operational buildings, construction sites, or the blueprint-placement ghost (REQ-UI-BLUEPRINT-PLACE). A building with multiple output ports (e.g. a splitter) shows one target-cell glyph per port. The target-cell glyph is drawn larger than the on-tile port glyph so it stands out as the flow-direction preview. Exceptions: the Tunnel Entry shows no target-cell glyph, because it receives items (which may arrive from any of its non-mouth edges, REQ-BLD-TUNNEL-ENTRY) rather than emitting into a single adjacent cell; the Shipyard shows none either, because its output port is a ship-spawn point (REQ-SHP-SPAWN-PLAYER) rather than a belt-item output (REQ-MAT-OUTPUT-EMERGE).
+- REQ-UI-STATUS-LIGHT: Every operational production building — Miner, Smelter, Assembler, Reprocessing Plant, Shipyard, and Salvage Bay — renders a small **status light**: a filled circle with a black outline drawn in the building's upper-right corner, letting the player read a building's production state without selecting it. The light is anchored to the footprint corner that is the upper-right corner in the building's default orientation and rotates with the building — like the output-port glyph (REQ-UI-PORT-GLYPH) — so it stays on the same physical corner of the building as it is rotated. The status light is rendered only for operational buildings; construction sites (which instead show construction progress, REQ-UI-CONSTRUCTION-PROGRESS) and the builder-mode ghost do not render it. Buildings that are not production buildings — belts, splitters, tunnel entries/exits, and the HQ — have no status light. The black outline is constant; the fill color reflects the building's current production state.
+  - For the five production buildings (Miner, Smelter, Assembler, Reprocessing Plant, Shipyard), the fill color is determined by evaluating, in order:
+    - **Grey** — no recipe or schematic is selected. Every production building can show it, an auto-recipe building included: it is grey until something is offered at an input port for it to select a recipe from, and again whenever the player hands it back to automatic selection (REQ-BLD-AUTO-RECIPE).
+    - **Green** — the building is currently producing: a production cycle is active (REQ-MAT-CYCLE; for the Shipyard, an in-progress production cycle per REQ-BLD-SHIPYARD).
+    - **Red** — the building is idle because a required input is missing from its input buffers, so it cannot start a cycle. Missing input takes precedence over a blocked output side: if any required input is missing the light is red even when an output buffer is also out of room.
+    - **Yellow** — the building is idle with all required inputs present but the output side cannot take the cycle: at least one item the cycle could produce has no room in its own buffer, so no new cycle can start (REQ-MAT-OUTPUT-BUFFER, REQ-MAT-CYCLE). A buffer short of a full cycle's worth of free space blocks just as a completely full one does.
+    - A configured building that is momentarily idle yet blocked by neither condition (all inputs present and room for every output the cycle could produce — a transient state that resolves into a started cycle on the same or the next tick per REQ-MAT-CYCLE) shows green.
+  - The Salvage Bay has no recipe and no production cycle (REQ-BLD-SALVAGE-BAY); its status light uses only two states: **green** while its output buffer holds at least one unit of scrap, and **red** while its output buffer is empty. The Salvage Bay's status light is never grey or yellow.
+  - The four fill colors (grey, green, red, yellow) and the outline color are read from `visuals.toml [status_light]`, consistent with the other rendering-only colors. The status light is presentation-only and has no effect on the simulation.
 - REQ-UI-HP-BARS: All entities with HP — the HQ, player and enemy defence stations, and player and enemy ships — render an HP bar below them. The bar is always visible regardless of current HP. The bar's filled portion represents the fraction of current HP to maximum HP.
 - REQ-UI-NO-ZOOM: The view has a fixed zoom level; the player cannot zoom in or out.
 - REQ-UI-HOTKEYS: Global keyboard shortcuts:
   - **Space** — toggles pause. Pressing Space pauses (sets speed to 0×) and stores the previously selected non-zero speed; pressing Space again restores that speed.
-  - **W** — increases game speed by one step in the sequence 0×, 0.5×, 1×, 2×, 4× (no wrap-around past 4×).
+  - **W** — increases game speed by one step in the sequence 0×, 0.5×, 1×, 2×, 10× (no wrap-around past 10×).
   - **S** — decreases game speed by one step in the same sequence (no wrap-around past 0×).
   - **A / D** — scroll the view left / right (REQ-UI-SCROLL).
-  - **Q** — context-sensitive. If a build mode is active (builder mode or blueprint placement mode), pressing Q exits it. Otherwise, pressing Q toggles demolish mode: it enters demolish mode if inactive, or exits demolish mode if already active. (See also REQ-UI-DEMOLISH-BUTTON for the equivalent button.)
+  - **Q** — context-sensitive. If a build mode is active (builder mode or blueprint placement mode), pressing Q exits it. Otherwise, pressing Q toggles deconstruct mode: it enters deconstruct mode if inactive, or exits deconstruct mode if already active. (See also REQ-UI-DECONSTRUCT-BUTTON for the equivalent button.)
   - **R / Shift+R** — in builder mode, rotate the ghost counter-clockwise / clockwise (REQ-BLD-ROTATE).
-  - **Escape** — opens the escape menu (REQ-UI-GAME-MENU).
+  - **C** — create a temporary blueprint from the current selection and enter its placement mode (REQ-UI-BLUEPRINT-TEMP). Has effect only when at least one player-placeable building is selected; otherwise it does nothing.
+  - **V** — re-enter placement mode for the last temporary blueprint created with C (REQ-UI-BLUEPRINT-TEMP). Does nothing when no temporary blueprint exists.
+  - **Ctrl+C** — save the current selection as a named blueprint: opens the blueprint save dialog (REQ-UI-BLUEPRINT-CREATE). Has effect only when at least one player-placeable building is selected; otherwise it does nothing.
+  - **Ctrl+V** — opens the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG), from which a saved blueprint is picked for placement. It is available whenever the game is being played, regardless of the current selection or of which build mode is active, and opens the dialog even when no blueprints are saved yet.
+  - **Escape** — opens the escape menu (REQ-UI-GAME-MENU). While a blueprint dialog is open, Escape closes that dialog instead (REQ-UI-BLUEPRINT-DIALOG).
   - **Build mode selection** — pressing a build hotkey activates builder mode for the corresponding building type, equivalent to clicking its build button (REQ-BLD-BUILDER-MODE):
-    - **1** — Belt, **2** — Splitter, **3** — Tunnel Entry, **4** — Tunnel Exit.
+    - **1** — Belt, **2** — Splitter, **3** — Tunnel (the unified tunnel build mode, REQ-BLD-TUNNEL-MODE). Hotkey 4 is unused.
     - **Shift+1** — Miner, **Shift+2** — Smelter, **Shift+3** — Assembler, **Shift+4** — Shipyard, **Shift+5** — Salvage Bay, **Shift+6** — Reprocessing Plant.
 
+  These shortcuts are the definition; the controls panel (REQ-UI-CONTROLS-PANEL) displays the subset of them that applies to the player's current situation, and the build buttons carry the build hotkeys on their badges (REQ-UI-BUILD-COST). Neither display defines a binding of its own.
+
 ### Debug Draw
 
 - REQ-UI-DEBUG-DRAW: A debug draw mode can be toggled on and off with the **F3** key. It is inactive by default. While active, the sensor range of every ship — both player and enemy — is drawn as a circle centered on the ship, using that ship schematic's outline color from `visuals.toml`.
@@ -430,49 +544,257 @@ The screen is divided into two columns: a main column (75% width) containing the
   - **Quit** — closes the application.
   Pressing Escape while the escape menu is open is equivalent to clicking Continue.
 
-### Selected Building Panel
+### Selection Panel
 
-- REQ-UI-EMPTY-SELECTION: When no building is selected, the panel is empty.
-- REQ-UI-SINGLE-SELECTION: When one building is selected, the panel shows: building name, current recipe or schematic selection, input buffer contents, and output buffer contents. Buffer counts are displayed as `a/b` where `a` is the current item count and `b` is the per-cycle amount (items consumed per run for inputs; items produced per run for outputs). For a selected construction site, the recipe/schematic selection (and, for a shipyard, the layout preview and "Configure" button) are shown but the buffer rows are omitted (REQ-BLD-SITE-CONFIG).
-- REQ-UI-PRODUCTION-PROGRESS: For buildings that produce items or ships (miner, smelter, assembler, reprocessing plant, shipyard), the selected building panel also shows: (a) the cycle time of the currently selected recipe or schematic in seconds, and (b) the completion percentage of the active production cycle as an integer (e.g. `42%`), or the text `idle` when no production cycle is active. When no recipe or schematic is selected, neither the cycle time nor the progress indicator is shown.
-- REQ-UI-MULTI-SELECT: The player selects multiple buildings by box-drag or by Ctrl+clicking individual buildings to add or remove them from the selection.
-- REQ-UI-MULTI-SELECTION: When multiple buildings are selected, the panel shows how many of each building type are selected. No per-building detail is shown.
-- REQ-UI-CONFIG-INLINE: Recipe and schematic configuration for a selected building is shown within this panel. Recipe selection (miner, assembler) and schematic selection (shipyard) use the selection button and dialog (REQ-UI-SELECT-BUTTON) rather than an inline control. For shipyards, the panel additionally shows the ship layout preview and "Configure" button below the schematic selection button (REQ-MOD-UI-PREVIEW).
-- REQ-UI-SELECT-BUTTON: **Recipe and schematic selection control.** Recipe selection (Miner ore type, Assembler recipe) and schematic selection (Shipyard) are each presented in the selected building panel as a single **selection button** whose caption is the name of the currently selected recipe or schematic, or a placeholder ("Select recipe" / "Select schematic") when none is selected. Clicking the button opens a modal **selection dialog** that pauses the game (speed set to 0×; on close, the speed is restored to what it was before the dialog was opened). The dialog contains a grid of option buttons, one per selectable option — only options that are currently unlocked are shown (REQ-LOCK-UI-RECIPE for recipes, REQ-LOCK-UI-SCHEMATIC for schematics). Hovering an option button shows the selection info tooltip (REQ-UI-SELECT-TOOLTIP). Clicking an option button selects that recipe/schematic, closes the dialog, and updates the selection button's caption in the selected building panel. The dialog can be dismissed without changing the current selection (e.g. closing it without clicking an option). Selecting a new recipe or schematic has the same effects as before (REQ-MAT-INPUT-BUFFER, REQ-MAT-OUTPUT-BUFFER, REQ-BLD-SHIPYARD).
-- REQ-UI-SELECT-TOOLTIP: **Selection info tooltip.** Hovering an option button in the selection dialog (REQ-UI-SELECT-BUTTON), and hovering the selection button in the selected building panel when a selection is set, displays an info tooltip:
-  - For a **recipe** (Miner or Assembler): the recipe name; the name and quantity of each input item (no inputs are listed for miner recipes, which consume nothing); the completion time (`duration_seconds`); and the name and quantity of the produced output item.
-  - For a **ship schematic** (Shipyard): the ship's `display_name`; the name and quantity of each base required material (`[ship.schematic].materials`, excluding any module contributions); the base production time (`[ship.schematic].production_time_seconds`); and "Produces: 1 <ship display name>".
-- REQ-UI-BELT-CLEAR: When one or more belt, splitter, tunnel entry, or tunnel exit tiles are selected, the panel shows a "Clear" button that removes all items from the selected tiles. Clearing a tunnel entry or exit also discards all items currently in transit through that tunnel (REQ-BLD-TUNNEL-TRANSIT). This can be used to resolve stalled belts, splitters, and tunnels.
-- REQ-UI-ENTITY-CLICK-SELECT: The player can click any ship (player or enemy) or any defence station (player or enemy) in the game world to select it. Clicking a ship or defence station clears any existing selection and establishes a single-entity selection containing only that entity. Ships and defence stations cannot participate in multi-select together with buildings. Clicking empty world space (no building, ship, or defence station) clears the selection.
-- REQ-UI-SHIP-STATS-PANEL: When a single ship is selected (REQ-UI-ENTITY-CLICK-SELECT), the selected building panel shows a **ship stats panel**. The panel structure mirrors REQ-MOD-UI-STATS-PANEL but reflects the ship's actual live state: stats are computed from its installed modules per REQ-MOD-STAT-CALC. The panel always shows all hull stats: HP (current / maximum), max linear speed, sensor range, main acceleration, maneuvering acceleration, angular acceleration, and max rotation speed. In addition, capability module summaries are shown conditioned on which module types are installed, using the same aggregation rules as REQ-MOD-UI-STATS-PANEL: weapons (combined DPS, maximum range), salvage (combined collection rate, maximum range), and repair (combined repair rate, maximum range), each section appearing only if at least one instance of that module type is installed. While debug draw mode is active (REQ-UI-DEBUG-DRAW), the panel additionally shows the ship's derived threat cost (REQ-MOD-THREAT).
-- REQ-UI-STATION-STATS-PANEL: When a single defence station is selected (REQ-UI-ENTITY-CLICK-SELECT), the selected building panel shows a **station stats panel** displaying the station's stats computed at its current level: HP (current / maximum), damage, range, and fire rate.
+The selection panel shows the details of the current selection, whatever its category (REQ-UI-SELECTION-CATEGORIES): buildings and construction sites, ships, defence stations, and debris. Its position, size, and overlay behavior are defined in REQ-UI-SELECTION-PANEL; the requirements below define its content.
 
-### Build Button Grid
+The panel shows exactly one **content** at a time, picked from the catalog in REQ-UI-SELECTION-CONTENT by what is selected. Every content is assembled from the same small set of parts and follows the same card structure (REQ-UI-SELECTION-CARD), so different selections read alike and a part means the same thing wherever it appears.
 
-- REQ-UI-BUILD-GRID: All placeable building types are shown as a flat grid of buttons with no grouping.
-- REQ-UI-BUILD-COST: Each button caption shows the building name and its building block cost, e.g. "Belt: 2 Blocks".
-- REQ-UI-BUILD-DISABLED: Buttons for buildings the player cannot currently afford are shown as disabled.
-- REQ-UI-DEMOLISH-BUTTON: A dedicated **Demolish** button is shown in the build button grid. Clicking it toggles demolish mode on and off, equivalent to the Q demolish toggle (REQ-UI-HOTKEYS). The button is shown in a visually active/pressed state while demolish mode is active.
+- REQ-UI-EMPTY-SELECTION: When nothing is selected (no building, construction site, ship, defence station, or piece of debris), the selection panel is not shown at all — it is hidden rather than shown empty, so the full game world view is visible (REQ-UI-SELECTION-PANEL). It reappears as soon as an object is selected.
+- REQ-UI-SELECTION-CATEGORIES: **Selection categories and precedence.** Every selectable object belongs to one of two mutually exclusive selection categories: **buildings** (buildings and construction sites) and **field objects** (ships and defence stations — player or enemy — together with debris). A single selection holds objects from only one category at a time. Field objects of different kinds may be selected together (e.g. several ships plus debris, freely mixing player and enemy actors). Buildings are exclusive and take precedence — **buildings win**: selecting a building (by click, Ctrl+click, or a box-drag covering at least one building) clears any field selection and yields a buildings-only selection, and conversely selecting any field object clears any building selection. Point hit-testing prefers a building over a coincident field object, and among field objects prefers an actor (ship or defence station) over a coincident piece of debris (REQ-UI-ENTITY-CLICK-SELECT, REQ-UI-DEBRIS-CLICK-SELECT).
+- REQ-UI-SELECTION-CARD: **Card structure.** Every panel content is a card with the same three parts, top to bottom:
+  - **Header** — always shown. It holds the selection's identity symbol on the left — the building's icon glyph (REQ-UI-WORLD-ICON), a ship's schematic color swatch, or the kind symbol of a defence station or piece of debris — the selection's name beside it, and one optional **right slot**. The right slot holds a status indicator (REQ-UI-SELECTION-STATUS), a ship's current behavior (REQ-UI-SHIP-BEHAVIOR), or an object count — never more than one of them; which one applies is stated per content in REQ-UI-SELECTION-CONTENT. The header carries no control of its own, and doubles as the panel's drag handle (REQ-UI-SELECTION-PANEL-DRAG).
+  - **Configuration group** — the controls that change how the selected object is set up: the recipe/schematic selection control (REQ-UI-SELECT-BUTTON), a shipyard's layout preview and Configure button (REQ-MOD-UI-PREVIEW), and a splitter's output filters (REQ-BLD-SPLITTER). It is shown identically for an operational building and for a construction site of the same type (REQ-BLD-SITE-CONFIG).
+  - **Runtime group** — what the object is currently doing: buffer contents, production progress, HP, remaining scrap, and the belt clear action (REQ-UI-BELT-CLEAR). Where the object has **HP**, its bar is the first thing in this group, above everything else the card shows (REQ-UI-HQ-PANEL, REQ-UI-SHIP-STATS-PANEL, REQ-UI-STATION-STATS-PANEL) — how close the thing is to dying outranks what it is holding. For a **construction site** the entire runtime group is replaced by a captioned `Construction` section: a progress bar filled to the site's construction completion with that completion as an integer percentage beside the caption — the same value the world draws on the footprint (REQ-UI-CONSTRUCTION-PROGRESS) — followed by a note that buffers appear once the building is built, because a site has neither buffers nor a production cycle (REQ-BLD-SITE-CONFIG). That section sits **directly below the header, above the configuration group**, so how far along the site is reads first; the configuration group is otherwise unaffected and stays visible on a site.
 
-### Blueprint Panel
+  A group with nothing to show takes no space, so a content may consist of a header alone. Within a group, related parts form **sections** carrying a short caption above them (e.g. `Layout`, `Input buffers`, `Production`, `Output buffers`); a section and its caption are shown only while that section has content, so e.g. a Miner (which consumes nothing) shows no input buffer section.
+- REQ-UI-SELECTION-CONTENT: **Content catalog.** Which content the panel shows follows from the selection alone:
 
-- REQ-UI-BLUEPRINT-PANEL: The blueprint panel is shown to the right of the build button grid. It contains, from top to bottom: a "Create Blueprint" button, and a list of blueprint entries (one per saved blueprint, in creation order).
+  | Selection | Header right slot | Configuration group | Runtime group |
+  |---|---|---|---|
+  | Miner, Assembler, Smelter, Reprocessing Plant | status | recipe control + recipe summary | buffers + production |
+  | Shipyard | status | schematic control + layout preview + Configure | buffers + production |
+  | Salvage Bay | status | — | buffers |
+  | HQ | — | — | block stock + HP |
+  | Belt, Tunnel Entry, Tunnel Exit | count | — | clear action |
+  | Splitter | — | output filters | clear action |
+  | Several buildings | — | — | type counts + total cost |
+  | One ship | behavior | — | HP + hull stats + module summaries |
+  | One defence station | — | — | HP + stats |
+  | Debris (one or several) | count | — | remaining scrap |
+  | Several mixed field objects | count | — | type counts + scrap total |
 
-- REQ-UI-BLUEPRINT-CREATE: The "Create Blueprint" button is enabled only when at least one player-placeable building (i.e. a building with a button in the build button grid) is currently selected; non-player-placeable buildings (HQ, defence stations) in the selection do not count toward this condition. When clicked, a modal dialog appears prompting the player to enter a name. The dialog has Confirm and Cancel buttons. Clicking Cancel closes the dialog with no effect. Clicking Confirm with a non-empty name creates a blueprint from the current selection, silently excluding any non-player-placeable buildings, and appends its button to the blueprint list.
+  Selections sharing a row of this table get the same content and differ only in the name and symbol in the header. A count in the right slot appears only for an aggregated multi-selection (REQ-UI-SELECTION-AGGREGATE); a single selection of those types shows an empty slot.
+- REQ-UI-SELECTION-STATUS: **Status indicator.** For a building whose production state is already rendered in the world as a status light (REQ-UI-STATUS-LIGHT) — Miner, Smelter, Assembler, Reprocessing Plant, Shipyard, Salvage Bay — the header's right slot repeats that same state as a colored dot with a short caption beside it, so the panel and the world never disagree. The state is derived from the evaluation defined in REQ-UI-STATUS-LIGHT rather than from a second definition, and the dot uses that state's fill color from `visuals.toml [status_light]`. The captions name the state: `no recipe` (grey), `producing` (green), `missing input` (red), `output full` (yellow); for the Salvage Bay, `holding scrap` (green) and `empty` (red). A selected **construction site** shows the caption `constructing` with no dot, whatever its type. Buildings with no status light — belts, splitters, tunnel ends, the HQ — show nothing in the slot.
+- REQ-UI-SELECTION-AGGREGATE: **Aggregating a homogeneous multi-selection.** When several objects are selected and their content can be shown as one — the same content, with its values aggregated over the whole selection — the panel shows that single content with the number of selected objects in the header's right slot (`x<count>`), instead of the count summary of REQ-UI-MULTI-SELECTION / REQ-UI-FIELD-MULTI-SELECTION. This applies exactly where every part of the content aggregates:
+  - **Belt-subsystem tiles** — any mix of belts, tunnel entries, and tunnel exits. Their content is the clear action alone, which already acts on the whole selection (REQ-UI-BELT-CLEAR).
+  - **Debris** — several pieces of debris and nothing else. Their remaining scrap sums into one value (REQ-UI-DEBRIS-PANEL).
 
-- REQ-UI-BLUEPRINT-STORAGE: A blueprint stores its name and, for each building in the selection, the building type, its rotation, its tile offset (integer dx, dy) from the center of the bounding box of all selected buildings' footprints, and — where applicable — the selected recipe ID (miners and assemblers) or schematic ID (shipyards), and for splitters the two output filters (each a list of item types; an empty list means accept-all), at the time of capture. If no recipe or schematic was selected at capture time, none is stored; for a splitter with no filters set, no filter lists are stored. This structure maps directly to a TOML representation (e.g. one `[[building]]` array entry per constituent building, with the splitter filters as `filter_a`/`filter_b` arrays of item-type ids).
+  Every other multi-selection falls back to the count summary. In particular a selection mixing a splitter with belts does not aggregate (a splitter carries per-object output filters, which have no aggregate), and neither do several production buildings of one type (per-building buffers and cycle progress have no aggregate).
+- REQ-UI-SINGLE-SELECTION: When one building is selected, the panel shows its symbol and name in the header (REQ-UI-SELECTION-CARD), its current recipe or schematic selection (REQ-UI-SELECT-BUTTON) and recipe summary (REQ-UI-RECIPE-SUMMARY) in the configuration group, and its input and output buffer contents in the runtime group. Each buffered item is shown as an **item chip** bearing that item's icon on its colored square (REQ-UI-ITEM-ICON) and its current count, and hovering a chip shows that item's production tooltip (REQ-UI-ITEM-TOOLTIP):
+  - an **input** chip shows the per-cycle amount below the count (the items consumed per run, e.g. `/ 2 per cycle`), or the count alone when the building has no selected recipe or schematic to give one;
+  - an **output** chip shows the count against **that item's own** output buffer capacity as `a / b` (REQ-MAT-OUTPUT-BUFFER), with the item's name below. Each output chip therefore stands for one buffer, and a Reprocessing Plant shows one per possible roll.
 
-- REQ-UI-BLUEPRINT-BUTTON: Each blueprint entry consists of a blueprint button and a dedicated delete icon ("×") placed to the right of the button. The blueprint button displays the blueprint name and, below it, the total building block cost of the blueprint (sum of the individual costs of all constituent buildings). A blueprint button is disabled when the player cannot afford the total cost. Clicking an enabled blueprint button enters blueprint placement mode for that blueprint. The delete icon is always enabled regardless of whether the player can afford the blueprint.
+  Input and output chips form separately captioned sections (REQ-UI-SELECTION-CARD). A section lists a chip for **every item the building's cycle involves**, whether or not the buffer currently holds any: an empty buffer reads `0` rather than its chip disappearing, so the card keeps one shape while the building runs. A section left with no chips at all is not shown. The production section (REQ-UI-PRODUCTION-PROGRESS) sits **between them**, so the card reads in the direction the materials flow: what goes in, what is being made of it, what has come out. For a selected construction site the buffer sections are omitted (REQ-BLD-SITE-CONFIG).
 
-- REQ-UI-BLUEPRINT-MODE: In blueprint placement mode a ghost is rendered for every building in the blueprint at the position determined by its stored tile offset from the bounding-box center, which is anchored to the tile under the cursor. Each ghost is rendered individually as valid or invalid, applying REQ-BLD-PLACE-VALID conditions (a) and (b) per building (the other ghosts in the same blueprint do not count as existing buildings for the overlap check). A valid ghost uses its building type's semi-transparent per-building coloring (REQ-BLD-GHOST); an invalid ghost uses the distinct "invalid" color, as in single-building builder mode. Pressing R / Shift+R rotates the entire constellation 90° counter-clockwise / clockwise: each building's tile offset is rotated around the bounding-box center and each building's own rotation is updated, consistent with REQ-BLD-ROTATE. Blueprint placement mode is exited by right-clicking in the game world. Clicking a different blueprint button exits the current mode and enters blueprint placement mode for the newly clicked blueprint.
+  **Only unlocked items are listed.** Should a building's buffers carry an entry for an item the player cannot make yet, it is left out of both sections, consistent with the rest of the UI hiding what is not unlocked yet (REQ-LOCK-UI-RECIPE, REQ-LOCK-UI-SPLITTER).
+- REQ-UI-RECIPE-SUMMARY: Below the recipe/schematic selection control, a building running a recipe or schematic shows a one-line **recipe summary**: each input item's icon on its colored square (REQ-UI-ITEM-ICON) with its per-cycle amount and the inputs separated by `+`, an arrow, each output item's icon on its colored square with its per-cycle amount, and the cycle time in seconds. It restates what the building will do without opening the selection dialog, and it is the panel's only display of the cycle time. For a Shipyard the summary is built from the schematic's materials and production time including the placed modules' contributions (REQ-BLD-SHIPYARD, REQ-MOD-STAT-CALC), matching the buffers beneath it. A building with no recipe or schematic selected shows no summary — including an auto-recipe building that has yet to select one (REQ-BLD-AUTO-RECIPE), which shows none until it does and keeps it from then on, so the card does not resize in step with the building's status (REQ-UI-SELECTION-STATUS, REQ-UI-SELECTION-PANEL).
+- REQ-UI-PRODUCTION-PROGRESS: For buildings that produce items or ships (miner, smelter, assembler, reprocessing plant, shipyard), the panel's runtime group shows a captioned **production section** between the input and output buffer sections (REQ-UI-SINGLE-SELECTION): a horizontal progress bar filled to the completion of the active production cycle, with that completion beside the caption as an integer percentage (e.g. `72%`), or the text `idle` in place of the percentage and an empty bar when no production cycle is active. The cycle time is shown in the recipe summary (REQ-UI-RECIPE-SUMMARY) rather than repeated here. When no recipe or schematic is selected, the production section is not shown at all.
+- REQ-UI-MULTI-SELECT: The player selects multiple objects by box-drag or by Ctrl+clicking individual objects to add or remove them from the selection. Multi-select operates within a single category (REQ-UI-SELECTION-CATEGORIES). A box-drag that covers at least one building selects buildings (any field objects within the box are ignored — buildings win); a box-drag that covers no building but does cover ships, defence stations, or debris selects all of those field objects together (REQ-UI-ENTITY-CLICK-SELECT, REQ-UI-DEBRIS-MULTI-SELECT).
+- REQ-UI-MULTI-SELECTION: When multiple buildings are selected and the selection does not aggregate (REQ-UI-SELECTION-AGGREGATE), the panel shows a count summary. Its header names the size of the selection as `<n> buildings` in place of an object name, and carries no symbol and nothing in its right slot. Below it is one row per selected building type — the type's symbol, its name, and the number selected as `x<count>` — one type per row, and no per-building detail. A final row shows the **total building block cost** of the selection, captioned `Total cost` with the value followed by the `building_block` item icon (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON): the sum of each selected building's placement cost (`buildings.toml [[building]].cost`, per REQ-BLD-COST), counting only player-placeable buildings (buildings with a button in the build button bar); non-player-placeable buildings (the HQ and defence stations) are excluded from the total, consistent with the blueprint total (REQ-UI-BLUEPRINT-CARD). Construction sites count at their building type's full placement cost regardless of construction progress.
+- REQ-UI-CONFIG-INLINE: Recipe and schematic configuration for a selected building is shown within this panel, in its configuration group (REQ-UI-SELECTION-CARD). Recipe selection (miner, assembler, smelter, reprocessing plant) and schematic selection (shipyard) use the selection button and dialog (REQ-UI-SELECT-BUTTON) rather than an inline control. For shipyards, the panel additionally shows the ship layout preview and "Configure" button below the schematic selection button (REQ-MOD-UI-PREVIEW).
+- REQ-UI-SELECT-BUTTON: **Recipe and schematic selection control.** Recipe selection (Miner ore type, Assembler recipe, and the Smelter's and Reprocessing Plant's recipe per REQ-BLD-AUTO-RECIPE) and schematic selection (Shipyard) are each presented in the selection panel as a single **selection button** whose caption is the name of the currently selected recipe or schematic, or a placeholder ("Select recipe" / "Select schematic") when none is selected. Clicking the button opens a modal **selection dialog** that pauses the game (speed set to 0×; on close, the speed is restored to what it was before the dialog was opened) and that opens centered on the selection panel, as every modal opened from the panel does (REQ-UI-PANEL-MODAL). The dialog contains a vertical list of option buttons, one per selectable option, each describing itself (REQ-UI-SELECT-OPTIONS) — only options that are currently unlocked are shown (REQ-LOCK-UI-RECIPE for recipes, REQ-LOCK-UI-SCHEMATIC for schematics). Neither the option buttons nor the selection button carries a tooltip: an option button states what it makes on its own face, and what the building has selected is drawn beneath the selection button as the recipe summary (REQ-UI-RECIPE-SUMMARY), with the production paths of the items involved reachable by hovering the card's item chips (REQ-UI-ITEM-TOOLTIP). Clicking an option button selects that recipe/schematic, closes the dialog, and updates the selection button's caption in the selection panel. The dialog can be dismissed without changing the current selection (e.g. closing it without clicking an option). Selecting a new recipe or schematic has the same effects as before (REQ-MAT-INPUT-BUFFER, REQ-MAT-OUTPUT-BUFFER, REQ-BLD-SHIPYARD).
+- REQ-UI-SELECT-OPTIONS: **Option list of the selection dialog.** The selection dialog (REQ-UI-SELECT-BUTTON) lists its options as a **single vertical column** of buttons, one per option, rather than a grid: each button is as wide as the dialog and states what the option does, which needs a line of its own. No option button carries a tooltip — the button face is the whole description, so the player reads every option's inputs, product, and time from the list itself without hovering anything. Should the column be taller than the space the window leaves the dialog — a fully unlocked Assembler offers more options than any window can hold, and a modal is never resized to fit (REQ-UI-PANEL-MODAL) — the list **scrolls** within the dialog rather than the dialog growing past the window.
+  - A **recipe** option (Miner, Assembler) shows the **recipe name** on its first line and, beneath it, that recipe drawn as the recipe summary line draws it (REQ-UI-RECIPE-SUMMARY): each input item's icon on its colored square with its per-cycle amount, an arrow, each output item's icon with its amount, and the cycle time. A miner recipe consumes nothing, so its line begins at the arrow.
+  - A **ship schematic** option (Shipyard) shows the ship's `display_name` on its first line and, beneath it, the icons and quantities of its base required materials (`[ship.schematic].materials`, excluding any module contributions) with the base production time (`[ship.schematic].production_time_seconds`). A ship is not an item and has no icon of its own, so this line names no output: the button's caption is what it produces.
+  - The `(None)` option shows its text caption alone. On an auto-recipe building it is captioned `(Auto)` instead, because there it does not leave the building idle but returns it to automatic selection (REQ-BLD-AUTO-RECIPE).
+- REQ-UI-ITEM-TOOLTIP: **Item production tooltip.** Hovering an item chip in the selection panel — an input or output buffer chip (REQ-UI-SINGLE-SELECTION) or the HQ's block stock chip (REQ-UI-HQ-PANEL) — shows a tooltip telling the player where that item comes from. It has a heading and a body:
+  - the heading is the **hovered item's name**. For an input chip this is the only place the item is named at all, since such a chip carries a count and no name (REQ-UI-SINGLE-SELECTION).
+  - the body is the caption `Produced by` followed by one **recipe line** per unlocked recipe that produces the item. A recipe line is a small **card** of two rows: the icon of the building that runs the recipe (REQ-UI-BUILD-ICON) and the recipe's name on the first, and the recipe itself on the second, drawn as the recipe summary draws it (REQ-UI-RECIPE-SUMMARY) — each input item's icon on its colored square with its per-cycle amount, the inputs separated by `+`, an arrow, each output item's icon with its amount, and the cycle time. Two rows rather than one because an identity and a cycle read as different things, and a single row of icons, names and numbers runs too long to scan; a card around each because several producers stacked as bare lines read as one field of icons and numbers rather than as separate recipes. A line drawn where its surroundings already frame it — on an option button (REQ-UI-SELECT-OPTIONS), or as the panel's recipe summary — takes no card of its own. An item may have several producers — an iron ingot is smelted from ore, smelted from scrap, and recovered by reprocessing — and the building icon and recipe name are what tell those lines apart and tell the player which building to place for which path.
 
-- REQ-UI-BLUEPRINT-PLACE: Left-clicking in blueprint placement mode places the blueprint if (a) every building in the constellation satisfies REQ-BLD-PLACE-VALID conditions (a) and (b) at its resolved tile, and (b) the player has enough building blocks to afford the total cost. If both conditions are met, a construction site is added to the build queue for each building in the blueprint and the full total cost is deducted from the global building blocks stock in one transaction. If a recipe ID is stored for a building, it is applied to the construction site immediately. If a schematic ID is stored, it is applied only if that schematic is currently unlocked; if it is not unlocked, the shipyard's schematic is left unset. If splitter output filters are stored, they are applied to the construction site immediately and carry over when it finishes building (REQ-BLD-SITE-CONFIG). Locked recipe IDs and splitter filter entries for locked item types are handled on placement per REQ-LOCK-UI-BLUEPRINT. After a successful placement the game remains in blueprint placement mode, allowing the player to place the same blueprint again immediately.
+  **Only recipes the player can run are listed**, consistent with the rest of the UI hiding what the player cannot make yet. What that means differs by building, because only Miner and Assembler recipes are unlocked individually (REQ-LOCK-UI-RECIPE): those are listed once unlocked, while a Smelter's or Reprocessing Plant's recipes (REQ-BLD-SMELTER, REQ-BLD-REPROCESSING) are listed once **their building** is unlocked (REQ-LOCK-BUILDING) — there is no sense in naming a path through a plant the player cannot place. Two cases have no recipe line to show, and each says so in place of the list rather than leaving the tooltip bare:
+  - **An item no recipe produces at all.** Scrap is salvaged from debris (REQ-RES-DEBRIS-DROP) rather than crafted, so its tooltip reads `Salvaged from debris` in place of the `Produced by` caption and lists nothing beneath it.
+  - **An item whose every producing recipe is still locked.** The caption stays `Produced by`, and the single line beneath it reads `Undiscovered`: the player is told the item is made somehow, without being shown a path they have not unlocked yet.
 
-- REQ-UI-BLUEPRINT-DELETE: Clicking the delete icon ("×") on a blueprint entry immediately removes that blueprint from the list. If the deleted blueprint was active in blueprint placement mode, that mode is exited.
+  The tooltip belongs to item chips only. The selection dialog shows no tooltips at all, its buttons describing themselves (REQ-UI-SELECT-OPTIONS), and the icons of the recipe summary line (REQ-UI-RECIPE-SUMMARY) show none either: they are parts of one line that already describes one recipe, rather than standalone item displays.
+- REQ-UI-BELT-CLEAR: When one or more belt, splitter, tunnel entry, or tunnel exit tiles are selected, the panel's runtime group shows a **"Clear stuck items"** button that removes all items from the selected tiles. Clearing a tunnel entry or exit also discards all items currently in transit through that tunnel (REQ-BLD-TUNNEL-TRANSIT). This can be used to resolve stalled belts, splitters, and tunnels. The button acts on every selected tile, which is why a selection of belts and tunnel ends aggregates into one content rather than a count summary (REQ-UI-SELECTION-AGGREGATE).
+- REQ-UI-HQ-PANEL: When the HQ is selected, the panel shows the HQ's **HP** as a bar labelled `current / maximum` (REQ-HQ-STATS, REQ-UI-HP-BARS) and, beneath it, the **global building blocks stock** — the same value as the header bar's stock display (REQ-UI-BLOCKS-ICON), rendered as an item chip (REQ-UI-SINGLE-SELECTION) carrying the `building_block` icon on its colored square — a chip is an item display, so it takes the square even though the header bar's inline block icon does not (REQ-UI-ITEM-ICON, REQ-UI-BLOCKS-ICON), and hovering it shows the item production tooltip as any other chip does (REQ-UI-ITEM-TOOLTIP). The HP comes first, as it does on every card that has it (REQ-UI-SELECTION-CARD). The HQ has no input or output buffers of its own: building blocks delivered by belt go straight into the global stock (REQ-HQ-BELT-INPUT), and showing that stock on the HQ is what tells the player to route blocks there. The HQ has no configuration group and no status indicator (REQ-UI-SELECTION-STATUS), and it is never a construction site.
+- REQ-UI-ENTITY-CLICK-SELECT: The player can click any ship (player or enemy) or any defence station (player or enemy) in the game world to select it. A plain click on a ship or defence station makes it the sole selection, clearing any previous selection. Ships and defence stations can be multi-selected — by Ctrl+clicking individual actors to add or remove them, or by box-drag (REQ-UI-MULTI-SELECT) — and can be selected together with debris and with one another in a single field selection (REQ-UI-SELECTION-CATEGORIES), freely mixing player and enemy actors. Actors cannot be selected together with buildings: selecting a ship or defence station clears any building selection, and selecting a building clears the actors (buildings win). Clicking a piece of debris adds to or establishes a field selection (REQ-UI-DEBRIS-CLICK-SELECT). Clicking empty world space (no building, ship, defence station, or piece of debris) clears the selection.
+- REQ-UI-SHIP-STATS-PANEL: When exactly one ship is selected (REQ-UI-ENTITY-CLICK-SELECT) and no debris is selected, the selection panel shows a **ship stats panel**. (If debris is also selected, the panel shows the compact count summary instead, per REQ-UI-FIELD-MULTI-SELECTION.) The panel structure mirrors REQ-MOD-UI-STATS-PANEL but reflects the ship's actual live state: stats are computed from its installed modules per REQ-MOD-STAT-CALC. Its header (REQ-UI-SELECTION-CARD) carries the schematic's color swatch and display name, with the ship's current behavior in the right slot (REQ-UI-SHIP-BEHAVIOR). The panel always shows all hull stats: HP (current / maximum) as a **bar** with the two values beside its caption, then max linear speed, sensor range, main acceleration, maneuvering acceleration, angular acceleration, and max rotation speed as label/value rows. In addition, capability module summaries are shown below the hull stats, each as its own outlined row, conditioned on which module types are installed and using the same aggregation rules as REQ-MOD-UI-STATS-PANEL: weapons (combined DPS, maximum range), salvage (combined collection rate, maximum range), and repair (combined repair rate, maximum range), each appearing only if at least one instance of that module type is installed. While debug draw mode is active (REQ-UI-DEBUG-DRAW), the panel additionally shows the ship's derived threat cost (REQ-MOD-THREAT).
+- REQ-UI-SHIP-BEHAVIOR: The ship stats panel (REQ-UI-SHIP-STATS-PANEL) additionally displays the selected ship's **current behavior** in its header's right slot (REQ-UI-SELECTION-CARD) — a single label naming the top-priority behavior currently governing the ship's navigation, as resolved by the fixed-priority behavior arbitration. Only the winning behavior is named; lower-priority behaviors that are suppressed are not shown, and neither are the salvage/repair cycles that run regardless of the active behavior (REQ-SHP-SALVAGE, REQ-SHP-REPAIR). The label updates live as the ship's behavior changes, and it is always shown (independent of debug draw mode, unlike the threat-cost line of REQ-UI-SHIP-STATS-PANEL). This applies to both player and enemy ships (REQ-UI-ENTITY-CLICK-SELECT); enemy ships only ever show **Engaging** or **Advancing**. The behavior labels (all wrapped in `tr()`) are:
+  - **Retreating** — the ship is retreating (REQ-SHP-RETREAT).
+  - **Engaging** — the ship is engaging a combat target (player: REQ-SHP-COMBAT; enemy: REQ-SHP-ENEMY-AI).
+  - **Salvaging** — the ship is executing salvage navigation: seeking debris, collecting, or delivering to a Salvage Bay (REQ-SHP-SALVAGE).
+  - **Repairing** — the ship is navigating to a repair target (REQ-SHP-REPAIR).
+  - **Rallying** — the ship is moving to or orbiting the rally point (REQ-SHP-RALLY).
+  - **Standby** — the ship is holding with its fleet (REQ-SHP-STANDBY).
+  - **Advancing** — the ship is executing the baseline forward advance with no higher-priority behavior active (player: REQ-SHP-COMBAT advance toward the enemy; enemy: REQ-SHP-ENEMY-AI advance toward the asteroid).
+- REQ-UI-STATION-STATS-PANEL: When exactly one defence station is selected (REQ-UI-ENTITY-CLICK-SELECT) and no debris is selected, the selection panel shows a **station stats panel** displaying the station's stats computed at its current level: HP (current / maximum) as a **bar** with the two values beside its caption, then damage, range, and fire rate as label/value rows, matching the ship stats panel's rendering (REQ-UI-SHIP-STATS-PANEL). Its header carries no right slot: a station has no behavior label and no status light. (If debris is also selected, the panel shows the compact count summary instead, per REQ-UI-FIELD-MULTI-SELECTION.)
+- REQ-UI-FIELD-MULTI-SELECTION: A full single-object stats panel (REQ-UI-SHIP-STATS-PANEL, REQ-UI-STATION-STATS-PANEL, REQ-UI-DEBRIS-PANEL) is shown when the field selection holds exactly one object — one ship, one defence station, or one piece of debris — and, for debris only, when it holds several pieces of debris and nothing else, which aggregate into that same content (REQ-UI-SELECTION-AGGREGATE). Every other field selection of more than one object — multiple actors, or any mix of actors and debris — shows a **count summary** instead. Its header reads `Mixed selection` with the total number of selected objects in the right slot (REQ-UI-SELECTION-CARD). Below it is one row per type — the type's symbol, its name, and the number selected as `x<count>`, the same `x`-count notation as the recipe tooltip and the building multi-selection (REQ-UI-MULTI-SELECTION). Ships are grouped by schematic display name and defence stations as a group, distinguishing player from enemy; all selected pieces of debris are grouped into a single `Debris` row whose count is the number of selected pieces. No per-object detail is shown. If debris is part of the selection, its row is followed by an indented sub-row giving the summed remaining scrap across all selected debris as the amount followed by the bare `scrap` icon, exactly as the debris panel states it (REQ-UI-DEBRIS-PANEL, REQ-UI-ITEM-ICON). Building selections use REQ-UI-SINGLE-SELECTION / REQ-UI-MULTI-SELECTION instead.
+- REQ-UI-DEBRIS-CLICK-SELECT: The player can click any piece of debris (REQ-RES-DEBRIS-DROP) in the game world to select it. Debris are field objects (REQ-UI-SELECTION-CATEGORIES) and can be selected together with ships and defence stations, but not with buildings. A plain click on a piece of debris makes it the sole selection, clearing any previous selection; selecting a building clears any debris (buildings win), and selecting a piece of debris clears any building selection. Hit-testing prefers a building over a coincident actor or piece of debris, and an actor (ship or defence station) over a coincident piece of debris: a piece of debris is selected only when no building or actor is under the cursor. A selected piece of debris that despawns or is fully collected (REQ-RES-DEBRIS-DROP) is removed from the selection; if no selected object remains, the panel becomes empty (REQ-UI-EMPTY-SELECTION).
+- REQ-UI-DEBRIS-MULTI-SELECT: Multiple pieces of debris can be selected by box-drag or by Ctrl+clicking individual pieces to add or remove them, mirroring building multi-select (REQ-UI-MULTI-SELECT). Debris shares the field-object category with ships and defence stations (REQ-UI-SELECTION-CATEGORIES), so a field selection may hold debris and actors together. Ctrl+clicking a piece of debris while a field selection is active adds or removes that piece within the same selection; Ctrl+clicking a piece of debris while a building selection is active first clears the buildings and begins a field selection (buildings win). Conversely, selecting a building while a field selection is active clears it. Box-drag disambiguation follows REQ-UI-MULTI-SELECT (a box covering any building selects buildings; a box covering no building selects the ships, defence stations, and debris within it).
+- REQ-UI-DEBRIS-PANEL: When debris is selected and no actors are (REQ-UI-FIELD-MULTI-SELECTION), the selection panel shows a **debris stats panel** structured like the ship and station stats panels (REQ-UI-SHIP-STATS-PANEL, REQ-UI-STATION-STATS-PANEL): a header reading **"Debris"**, followed by a single stat row captioned **"Remaining"**, in the same label/value style as a ship hull stat row. Its value is the scrap amount followed by the `scrap` item icon drawn **bare, without its colored square** and sized to the row's text height — the same inline form the header bar uses for building blocks (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON). The icon stands in for the word `Scrap`, which is why the caption names neither the item nor its unit; when no icon file exists for `scrap` (a missing icon is not an error, REQ-UI-ITEM-ICON), the row falls back to the caption `Scrap remaining` with the amount alone as its value. With one piece selected the row shows that piece's remaining scrap amount (REQ-RES-DEBRIS-DROP) and the header's right slot is empty. With several pieces selected the same content is shown aggregated (REQ-UI-SELECTION-AGGREGATE): the number of selected pieces appears in the header's right slot as `x<count>` and the row shows the summed remaining scrap across them. When debris is selected together with actors, the debris are instead summarized within the count summary (REQ-UI-FIELD-MULTI-SELECTION): a `Debris` row giving the number of selected pieces, followed by an indented sub-row with their summed remaining scrap, stated in the same amount-plus-bare-icon form. The displayed scrap value updates as selected debris are partially collected or despawn (REQ-UI-DEBRIS-CLICK-SELECT).
 
-- REQ-UI-BLUEPRINT-SAVE: A "Save" button is shown at the bottom of the blueprint panel. Clicking it serializes all current blueprints to a file named `blueprints.toml` located in the same directory as the application executable. The TOML structure matches REQ-UI-BLUEPRINT-STORAGE. If writing fails, a modal error dialog is shown describing the failure.
+### Build Button Bar
 
-- REQ-UI-BLUEPRINT-LOAD: A "Load" button is shown at the bottom of the blueprint panel, to the right of the "Save" button. Clicking it shows a confirmation dialog ("Load blueprints? This will replace all current blueprints.") with Confirm and Cancel buttons. Clicking Cancel closes the dialog with no effect. Clicking Confirm reads `blueprints.toml` from the same directory as the application executable, replaces all current blueprints with those from the file (in the order they appear in the file), and exits any active blueprint-related mode (blueprint placement mode, delete mode). If the file does not exist or cannot be parsed, a modal error dialog is shown describing the failure and the current blueprint list is left unchanged.
+- REQ-UI-BUILD-BAR: All placeable building types are shown as a **single horizontal row** of buttons with no grouping and no wrapping, inside a widget that **floats over the game world view** (REQ-UI-WORLD-SIZE), horizontally centered and anchored at the bottom edge with a small margin. Tunnel Entry and Tunnel Exit share a single **Tunnel** button (REQ-BLD-TUNNEL-MODE) rather than one button each. The bar is sized to its buttons and re-centers whenever the set of shown buttons changes (REQ-LOCK-BUILDING) or the view is resized.
+  - **Overlay behavior.** The bar occludes the strip of the game world it covers; the world view itself keeps its full extent and the view's scrolling, ghost rendering, and tile geometry are unaffected (the world is not inset for the bar). The bar is drawn above the pause and deconstruct vignettes (REQ-UI-PAUSE-BORDER, REQ-UI-DECONSTRUCT-BORDER), which keep their full 100-pixel bottom band underneath it, and below the modal dim (REQ-UI-MODAL-DIM), which covers the entire game window including the bar.
+  - **No overlap with the selection panel.** The bar and the selection panel (REQ-UI-SELECTION-PANEL) never overlap, and keeping them apart is entirely the panel's job: the bar's position depends only on its own button set and the view size, and it never moves, re-centers, or resizes because the panel appears, disappears, or changes size. The panel instead steps around the bar's current rectangle wherever its own column would meet it (REQ-UI-SELECTION-PANEL).
+  - **Input.** Mouse events over the bar are consumed by the bar and never reach the game world: hovering it shows no builder-mode ghost at the tile beneath, and clicking it neither places a building nor changes the selection. Right-clicking the bar does not exit builder mode (REQ-BLD-BUILDER-MODE) or cancel a belt drag (REQ-BLD-BELT-DRAG).
+- REQ-UI-BUILD-COST: Each button is **icon-only with a cost**, its face composed of three elements: the button's **hotkey badge** in the top-left corner, the building's icon (REQ-UI-BUILD-ICON) centered below it, and the building block cost centered under the icon, shown with the `building_block` item icon (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON) to the right of the number in place of the trailing `Blocks` word, e.g. `2` then a small block icon. The building name is not shown on the button; it is shown in the button's hover tooltip instead (REQ-UI-BUILD-TOOLTIP). When no icon file exists for `building_block`, the cost is shown as the bare number. The Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON) has no cost and shows its name as a text caption in the cost's place.
+  - **Hotkey badge.** The badge names the build hotkey that activates the button (REQ-UI-HOTKEYS), so the player can learn the shortcuts from the bar itself. It is rendered dimmer than the cost so it reads as secondary, but at the same size and in bold, because a smaller badge is not legible. A plain-digit hotkey is shown as the bare digit (`1`, `2`, `3`); a Shift+digit hotkey is shown with an upwards arrow prefixed and no separator (`↑1` … `↑6`); the Deconstruct button shows `Q`. A button whose building type has no build hotkey shows no badge and keeps the same face size, so the row stays even.
+- REQ-UI-BUILD-ICON: Each build button shows an icon. Icons are SVG files loaded at runtime from `data/icons/buildings/` (a sibling of the config directory, read the same way as `visuals.toml`), one file per button named after the building's id (e.g. `belt.svg`, `reprocessing_plant.svg`). The shared Tunnel button (REQ-UI-BUILD-BAR) uses `tunnel_entry.svg`; the Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON) uses `deconstruct.svg`. Each icon is a rounded colored "chip" bearing a white line glyph, the chip color following the building's fill color in `visuals.toml`. A missing icon file leaves the button showing its building name as a text caption in place of the icon, so the button stays identifiable in the icon-only bar (REQ-UI-BUILD-COST); it is not an error.
+- REQ-UI-BUILD-TOOLTIP: Each building-type button shows a hover tooltip consisting of the building name followed by the descriptive text defined for that building type in `buildings.toml` (the optional per-building tooltip field). Because the button caption is icon-only (REQ-UI-BUILD-COST), the name is always part of the tooltip; if a building type defines no tooltip text, the tooltip shows the name alone. This tooltip is distinct from the item production tooltip of the selection panel's item chips (REQ-UI-ITEM-TOOLTIP); the recipe/schematic selection dialog has no tooltip at all (REQ-UI-SELECT-OPTIONS). The Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON) is not a building type and so has no config-defined tooltip; it instead shows its own refund tooltip defined in REQ-UI-DECONSTRUCT-BUTTON.
+- REQ-UI-BUILD-DISABLED: Buttons for buildings the player cannot currently afford are shown as disabled. A disabled button's icon (REQ-UI-BUILD-ICON) is rendered in a greyed variant, with its colored chip background recolored grey while the white glyph is retained.
+- REQ-UI-DECONSTRUCT-BUTTON: A dedicated **Deconstruct** button is shown in the build button bar (REQ-UI-BUILD-BAR), as the last entry of the row and **visually separated** from the building-type buttons by a gap (not a divider line), because it toggles a mode rather than selecting a building type. Its face follows REQ-UI-BUILD-COST with two differences: its hotkey badge reads `Q`, and because it has no building block cost it shows its **Deconstruct** name as a text caption where the building-type buttons show their cost — so it is the one labelled button in the bar. It is therefore wider than the building-type buttons, which share a uniform width. Clicking it toggles deconstruct mode on and off, equivalent to the Q deconstruct toggle (REQ-UI-HOTKEYS). The button is shown in a visually active/pressed state while deconstruct mode is active. The button shows a hover tooltip stating the deconstruction refund (REQ-BLD-DECONSTRUCT): that deconstructing a fully-built building returns `world.toml [world].refund_percentage` percent of its building block cost once deconstruction completes, and that a construction site removed before it finishes building is refunded in full. When `refund_percentage` is 100% both cases yield the same refund, and the tooltip is simplified to state the single refund percentage without distinguishing the two cases. Unlike the building-type button tooltips (REQ-UI-BUILD-TOOLTIP), this tooltip is not config-defined text but is composed from the refund percentage.
+
+### Controls Panel
+
+The controls panel tells the player which controls are available right now. It is context-sensitive: the game is always in exactly one **control context**, derived from the active build mode and the current selection, and the panel shows that context's rows and no others. Its position, size, and overlay behavior are defined in REQ-UI-CONTROLS-PANEL; its structure in REQ-UI-CONTROLS-CARD; and which rows each context shows in REQ-UI-CONTROLS-CONTENT. The panel never defines a binding: every row restates one already defined in REQ-UI-HOTKEYS or in the mouse gestures cited beside it.
+
+- REQ-UI-CONTROLS-PANEL: The **controls panel** is a widget that **floats over the game world view** (REQ-UI-WORLD-SIZE), anchored to the view's **bottom-left corner** with a small margin on both edges. It is **sized to its content in both width and height**, growing and shrinking upward from that corner as the context changes. Should its content ever be taller than the view, the panel's height is capped at the view height less its margins and the content scrolls vertically within it. The selection panel is placed beside the current selection (REQ-UI-SELECTION-PANEL) and so can reach this corner; the two never overlap, and keeping them apart is entirely the selection panel's job — this panel's position depends only on its own content, the view size, and the build button bar, and it never moves or resizes because the selection panel appears, disappears, or changes size.
+  - **Stepping around the build button bar.** Like the selection panel (REQ-UI-SELECTION-PANEL), the panel does **not** confine itself to the band above the build button bar's strip: the bar is horizontally centered and sized to its buttons (REQ-UI-BUILD-BAR), so it normally leaves this corner free, and the panel shares the view's bottom edge with it. The panel **rises only to avoid an actual overlap**: whenever the panel at the bottom-left corner would intersect the bar's current rectangle, it is moved up so that its bottom edge clears the bar's top by the same margin it keeps from the view's edges, and its height is capped at the space that leaves. Whether it rises therefore depends on how wide the bar and the panel currently are, and it returns to the corner as soon as they no longer meet. The bar never moves on the panel's account (REQ-UI-BUILD-BAR).
+  - **Visibility.** The panel is shown whenever the game is being played. Unlike the selection panel it has no empty state (REQ-UI-EMPTY-SELECTION): every context has rows, so there is never nothing to show.
+  - **Collapsing.** Clicking anywhere on the panel's header (REQ-UI-CONTROLS-CARD) toggles the panel between **expanded** and **collapsed**. Collapsed, it shows its header alone, keeping the context name visible and the header clickable so the panel can be expanded again; expanded, it shows the header followed by every row of the current context. The panel starts **expanded**. Changing context does not change the collapsed state: a panel collapsed in one context stays collapsed in the next, and its header updates in place. The collapsed state is presentation-only — it is not a player command, never enters the replay stream, and has no effect on the simulation. It persists for as long as the application runs, including across a restart from the escape menu (REQ-UI-GAME-MENU), and is not saved to disk.
+  - **Overlay behavior.** As for the build button bar and the selection panel (REQ-UI-BUILD-BAR, REQ-UI-SELECTION-PANEL): the panel occludes the strip of the game world it covers; the world view itself keeps its full extent and the view's scrolling, ghost rendering, and tile geometry are unaffected. It is drawn above the pause and deconstruct vignettes (REQ-UI-PAUSE-BORDER, REQ-UI-DECONSTRUCT-BORDER), which keep their full left-hand band underneath it, and below the modal dim (REQ-UI-MODAL-DIM), which covers the entire game window including the panel.
+  - **Input.** Mouse events over the panel are consumed by the panel and never reach the game world: hovering it shows no builder-mode ghost at the tile beneath, and clicking it neither places a building nor changes the selection. Right-clicking the panel does not exit builder mode (REQ-BLD-BUILDER-MODE) or cancel a belt drag (REQ-BLD-BELT-DRAG). The only control the panel itself offers is the header click that collapses and expands it.
+- REQ-UI-CONTROLS-CARD: **Card structure.** The panel is a card with two parts, top to bottom:
+  - **Header** — always shown, and the panel's only interactive element (REQ-UI-CONTROLS-PANEL). It holds a colored context dot on the left, the context's name beside it in upper case, and, for contexts that define one, a **detail suffix** separated by a middle dot (`BUILD MODE · Assembler`). The name and detail per context are given in REQ-UI-CONTROLS-CONTENT.
+  - **Rows** — one per available control, shown only while the panel is expanded. Each row is one or more **key badges** on the left — the key or mouse button drawn as a small bordered chip — and a **label** beside them naming what it does. An action reachable two ways carries both badges in the same row (`RMB` `Q` — Exit placement) rather than occupying two rows. A row whose action leaves the current mode is drawn with the destructive badge styling, distinguishing it from the rows that act within the mode. No row is ever drawn greyed or otherwise disabled: a control the player cannot currently use is not shown at all (REQ-UI-CONTROLS-ACCURACY).
+
+  The rows that are live in every context (REQ-UI-CONTROLS-CONTENT) are shown last, under a divider and the caption `ALWAYS AVAILABLE`. This holds in every context including the General one, which has context rows of its own above the divider like any other, so the card is read the same way wherever the player is.
+- REQ-UI-CONTROLS-CONTENT: **Content catalog.** The control context follows from the active build mode and the selection alone. Build modes are mutually exclusive (REQ-BLD-BUILDER-MODE), so exactly one context applies at any moment:
+
+  | Context | When | Header name | Header detail |
+  |---|---|---|---|
+  | General | no build mode active, nothing selected | `GENERAL` | — |
+  | Selection | no build mode active, at least one object selected | `SELECTION` | `<n> buildings` or `<n> objects` |
+  | Build | builder mode active (REQ-BLD-BUILDER-MODE) | `BUILD MODE` | the building type's name |
+  | Blueprint | blueprint placement mode active (REQ-UI-BLUEPRINT-MODE) | `BLUEPRINT MODE` | the blueprint's name, or `Temporary` for a temporary blueprint (REQ-UI-BLUEPRINT-TEMP) |
+  | Deconstruct | deconstruct mode active (REQ-UI-DECONSTRUCT-BUTTON) | `DECONSTRUCT MODE` | — |
+
+  The Selection context's detail counts the selection and names its category (REQ-UI-SELECTION-CATEGORIES): `<n> buildings` for a building selection, `<n> objects` for a field selection, in the singular at a count of one. The Build and Blueprint contexts show **the same rows** and differ only in their header.
+
+  **Always-available rows**, shown in every context:
+
+  | Badges | Label | Shown |
+  |---|---|---|
+  | `A` `D` | Move | always |
+  | `W` `S` | Game speed | always |
+  | `Space` | Toggle pause | always |
+  | `V` | Paste last | only while a temporary blueprint exists (REQ-UI-BLUEPRINT-TEMP) |
+  | `Ctrl` `V` | Blueprints | always |
+  | `Esc` | Menu | always |
+
+  **Context rows**, shown above the always-available block:
+
+  | Context | Badges | Label |
+  |---|---|---|
+  | General | `LMB` | Select |
+  | | `LMB` drag | Select area |
+  | | `Q` | Deconstruct mode |
+  | Selection | `LMB` | Select / clear selection |
+  | | `LMB` drag | Select area |
+  | | `Ctrl` `LMB` | Add / remove from selection |
+  | | `Ctrl` `LMB` drag | Add area to selection |
+  | | `Q` | Deconstruct mode |
+  | | `C` | Copy to temporary blueprint |
+  | | `Ctrl` `C` | Create blueprint |
+  | Build, Blueprint | `LMB` | Place |
+  | | `LMB` drag | Place belt line |
+  | | `R` / `Shift` `R` | Rotate |
+  | | `RMB` `Q` | Exit placement |
+  | Deconstruct | `LMB` | Toggle deconstruct |
+  | | `LMB` drag | Deconstruct area |
+  | | `RMB` `Q` | Exit deconstruct mode |
+
+  Four rows are conditional on more than the context, because the binding behind them is:
+  - **`C` / `Ctrl` `C`** are shown only while the selection holds at least one player-placeable building, the condition under which those keys do anything (REQ-UI-HOTKEYS). A selection of ships, defence stations, or debris shows neither.
+  - **`LMB` drag — Place belt line** is shown only in builder mode for the Belt type, the only type placed by dragging (REQ-BLD-BELT-DRAG). Every other builder type and blueprint placement omit the row.
+  - **`RMB` `Q` — Exit placement** splits into two rows **while a belt drag is in progress**, because the two bindings then part company (REQ-BLD-BELT-DRAG): `RMB` reads **Cancel belt line** and cancels the drag while leaving builder mode active, and `Q` reads **Exit placement** and leaves the mode outright.
+  - **`LMB` — Place** reads **Apply settings** instead whenever the ghost under the cursor resolves to a configuration transfer (REQ-UI-BLUEPRINT-TRANSFER) — a single-building blueprint hovering a same-type building of a configurable type, which is the case in which clicking hands over settings rather than placing anything. A blueprint holding more than one building keeps the `Place` label, since its click both places and transfers (REQ-UI-BLUEPRINT-PLACE).
+- REQ-UI-CONTROLS-ACCURACY: **The panel never advertises a binding that would do nothing.** Every row shown must, if triggered in the situation the panel is showing it in, have the effect its label names; a binding that is inert in the current context is omitted rather than shown greyed (REQ-UI-CONTROLS-CARD). The relation holds in one direction only: the panel may omit a binding that is available, and deliberately does so in three cases:
+  - **Build hotkeys** (REQ-UI-HOTKEYS) are live in every context, but are advertised on the build buttons' badges (REQ-UI-BUILD-COST) instead of taking eleven rows in every context of this panel.
+  - **`C` and `Ctrl` `C`** are omitted from the Build, Blueprint, and Deconstruct contexts even though a selection surviving into a build mode keeps them working. They belong to the Selection context, and repeating them in every mode would defeat the panel's purpose of showing what the player's current situation affords.
+  - **`Ctrl` `LMB` and `Ctrl` `LMB` drag** work with nothing selected — they select the object under the cursor much as a plain click would — but are shown only in the Selection context. "Add / remove from selection" names an operation on a selection, and there is none to operate on until something is selected; the plain `LMB` row already covers what the gesture does before then.
+  - **`F3` and `F4`** (REQ-UI-DEBUG-DRAW) are development controls rather than player controls and appear in no context.
+
+  This asymmetry between what is available and what is shown is why the two are separate questions in the implementation, and why the tests assert that a resolvable input is *available* rather than that it is displayed.
+
+### Blueprints
+
+Blueprints occupy no permanent screen space. They are saved with **Ctrl+C** from the current selection (REQ-UI-BLUEPRINT-CREATE) and picked for placement from the blueprint selection dialog, opened with **Ctrl+V** (REQ-UI-BLUEPRINT-DIALOG). The unmodified **C** and **V** keys are the throwaway counterparts of the same two gestures: they capture and re-place a single unnamed temporary blueprint that is never saved and never listed (REQ-UI-BLUEPRINT-TEMP). Blueprints have no widget on the game screen at all. (The ship layout blueprint panel of the layout configuration dialog, REQ-MOD-UI-BLUEPRINT-PANEL, is a separate feature and is unaffected.)
+
+- REQ-UI-BLUEPRINT-CREATE: Pressing **Ctrl+C** (REQ-UI-HOTKEYS) opens the modal **blueprint save dialog**, which pauses the simulation and dims the game window (REQ-UI-MODAL-DIM). It has effect only when at least one player-placeable building (i.e. a building with a button in the build button bar) is currently selected; non-player-placeable buildings (HQ, defence stations) in the selection do not count toward this condition, and pressing Ctrl+C with an empty selection or a selection of only non-player-placeable buildings does nothing (no dialog opens). A selected player-placeable building may be either an operational building or a construction site (a building placed but not yet fully built, REQ-BLD-SITE-CONFIG); both count toward this condition and are captured identically (REQ-UI-BLUEPRINT-STORAGE). The dialog prompts the player to enter a name and has Confirm and Cancel buttons. Clicking Cancel — or pressing Escape, or closing the dialog — closes it with no effect and does not open the blueprint selection dialog. Clicking Confirm with a non-empty name creates a blueprint from the current selection, silently excluding any non-player-placeable buildings, appends it to the blueprint list, closes the save dialog, and immediately opens the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG) showing the new blueprint among the others.
+
+- REQ-UI-BLUEPRINT-DIALOG: The **blueprint selection dialog** is the only place saved blueprints are shown. It is opened by pressing **Ctrl+V** (REQ-UI-HOTKEYS) and by confirming a save (REQ-UI-BLUEPRINT-CREATE). It is modal, pauses the simulation, and dims the game window (REQ-UI-MODAL-DIM). The dialog has a fixed size and consists of:
+  - A **title bar** reading `Blueprints`, followed by a small dimmed **hotkey badge** reading `Ctrl+V` — the same "learn the shortcut from the widget" device as the build button badges (REQ-UI-BUILD-COST) — and, at the far right, a **close ("×") button**.
+  - Below it, a **scrollable two-column grid of blueprint cards** (REQ-UI-BLUEPRINT-CARD), one per saved blueprint, filling the grid left to right and top to bottom in creation order. The column count is fixed at two; the grid scrolls vertically when the cards do not fit, and does not scroll horizontally.
+  - When no blueprints are saved, the dialog still opens and shows an empty-state message in place of the grid, telling the player that blueprints are created with Ctrl+C from a selection of buildings.
+
+  Clicking the close button, pressing Escape, or closing the dialog through the window manager closes it with no other effect: the current selection, build mode, and blueprint list are unchanged, and the simulation speed is restored to what it was before the dialog was opened. While the dialog is open, Escape closes it rather than opening the escape menu (REQ-UI-GAME-MENU).
+
+```
++------------------------------------------------------+
+| Blueprints  [Ctrl+V]                             [x]  |
++------------------------------------------------------+
+| +---------------------+  +---------------------+ |^| |
+| | Smelter array       |  | Gear cell           | | | |
+| | 4 Smelters, 1 Miner |  | 2 Assemblers, ...   | | | |
+| | 528 [blk]       (x) |  | 460 [blk]       (x) | | | |
+| +---------------------+  +---------------------+ | | |
+| +---------------------+                          | | |
+| | Defence line        |                          |_v_|
++------------------------------------------------------+
+```
+
+- REQ-UI-BLUEPRINT-TEMP: Pressing the **C** key (REQ-UI-HOTKEYS) creates a **temporary blueprint** from the current selection and immediately enters blueprint placement mode for it, without opening the naming dialog. It has effect only when at least one player-placeable building is currently selected — the same condition as REQ-UI-BLUEPRINT-CREATE; pressing C with an empty selection, or a selection containing only non-player-placeable buildings (HQ, defence stations), does nothing at all, and in particular leaves any existing temporary blueprint in place. Entering this mode replaces any currently active build, blueprint placement, or deconstruct mode. The temporary blueprint is captured exactly as a saved blueprint (REQ-UI-BLUEPRINT-STORAGE), silently excluding any non-player-placeable buildings from the selection, but it is never named, never shown in the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG), and never persisted to `blueprints.toml` (REQ-UI-BLUEPRINT-SAVE). Placement behaves identically to a saved blueprint's placement mode (REQ-UI-BLUEPRINT-MODE, REQ-UI-BLUEPRINT-PLACE): a ghost is rendered per building, R / Shift+R rotate the entire constellation, placement follows the same per-building validity and total-cost rules, and after a successful placement the mode stays active so the blueprint can be placed again. Right-clicking in the game world exits placement mode; unlike the mode, the temporary blueprint itself survives, so it can be entered again with V.
+
+  Pressing the **V** key re-enters blueprint placement mode for the temporary blueprint, capturing nothing new: it is independent of the current selection, can be pressed any number of times, and yields exactly the mode described above. Like C it replaces any currently active build, blueprint placement, or deconstruct mode, and it does not test whether the player can currently afford the blueprint — cost is enforced at placement (REQ-UI-BLUEPRINT-PLACE), consistently with C. Pressing V when no temporary blueprint exists does nothing: no mode is entered and any currently active mode is left untouched.
+
+  There is at most one temporary blueprint at a time; pressing C replaces the previous one. It is held only in memory for the current run: it is discarded when the application closes and when the simulation is restarted from the escape menu (REQ-UI-GAME-MENU), after which V does nothing until C captures a new one.
+
+- REQ-UI-BLUEPRINT-STORAGE: A blueprint stores its name and, for each building in the selection, the building type, its rotation, its tile offset (integer dx, dy) from the center of the bounding box of all selected buildings' footprints, and — where applicable — the selected recipe ID (miners and assemblers) or schematic ID (shipyards), and for splitters the two output filters (each a list of item types; an empty list means accept-all), at the time of capture. A source building may be either an operational building or a construction site (REQ-BLD-SITE-CONFIG); a construction site is captured identically, storing whatever configuration it currently holds and never any buffer or construction-progress state. If no recipe or schematic was selected at capture time, none is stored; for a splitter with no filters set, no filter lists are stored. This structure maps directly to a TOML representation (e.g. one `[[building]]` array entry per constituent building, with the splitter filters as `filter_a`/`filter_b` arrays of item-type ids).
+
+- REQ-UI-BLUEPRINT-CARD: Each blueprint in the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG) is shown as a **card**. All cards share a uniform size. A card contains, from top to bottom:
+  - The **blueprint name**.
+  - A **contents line** summarizing what the blueprint holds: one `<building name> x <count>` entry per building type it contains, comma-separated, in descending count order with ties broken by the order the types appear in the build button bar (REQ-UI-BUILD-BAR). This is the same `x`-count notation as the building multi-selection summary (REQ-UI-MULTI-SELECTION). If the entries do not fit on the line, the line is elided at its end rather than wrapped or shrunk, so every card keeps the same height.
+  - The **total building block cost** of the blueprint (sum of the individual costs of all constituent buildings), shown with the `building_block` item icon to the right of the number in place of a trailing `Blocks` word, exactly as elsewhere in the UI (REQ-UI-BLOCKS-ICON, REQ-UI-BUILD-COST). When no icon file exists for `building_block`, the cost is shown as the bare number.
+  - A **delete icon ("×")** in the card's bottom-right corner (REQ-UI-BLUEPRINT-DELETE).
+
+  A card shows no preview of the blueprint's layout.
+
+  Clicking anywhere on an enabled card other than its delete icon closes the dialog and enters blueprint placement mode for that blueprint (REQ-UI-BLUEPRINT-MODE). A card is disabled when the player cannot currently afford its total cost; a disabled card is rendered dimmed and clicking it does nothing (consistent with REQ-UI-BUILD-DISABLED), and neither closes the dialog nor enters placement mode. The delete icon is always enabled regardless of whether the player can afford the blueprint.
+
+- REQ-UI-BLUEPRINT-MODE: In blueprint placement mode a ghost is rendered for every building in the blueprint (excluding any of a currently locked building type, REQ-LOCK-BUILDING, which is omitted entirely per REQ-LOCK-UI-BLUEPRINT) at the position determined by its stored tile offset from the bounding-box center, which is anchored to the tile under the cursor. Each ghost is rendered individually as valid or invalid, applying REQ-BLD-PLACE-VALID conditions (a) and (b) per building (the other ghosts in the same blueprint do not count as existing buildings for the overlap check). A valid ghost uses its building type's semi-transparent per-building coloring (REQ-BLD-GHOST); an invalid ghost uses the distinct "invalid" color, as in single-building builder mode; a ghost over a configuration-transfer target uses the distinct "transfer" color instead of either and, for a single-building blueprint, is drawn snapped onto the target rather than at the blueprint's own position (REQ-UI-BLUEPRINT-TRANSFER); a ghost over a compatible overlap counts as valid and keeps the ordinary per-building coloring (REQ-UI-BLUEPRINT-OVERLAP). Pressing R / Shift+R rotates the entire constellation 90° counter-clockwise / clockwise: each building's tile offset is rotated around the bounding-box center and each building's own rotation is updated, consistent with REQ-BLD-ROTATE. Blueprint placement mode is exited by right-clicking in the game world. Opening the blueprint selection dialog while placement mode is active (REQ-UI-BLUEPRINT-DIALOG) leaves the mode active — closing the dialog without picking a card returns to it unchanged — while clicking a card exits the current mode and enters blueprint placement mode for the newly picked blueprint.
+
+- REQ-UI-BLUEPRINT-PLACE: This describes placing the blueprint's buildings as new construction sites. Ghosts sitting on a building that is already there are handled elsewhere and place nothing: a configuration-transfer target receives the blueprint's stored settings instead (REQ-UI-BLUEPRINT-TRANSFER), and a compatible overlap is left alone (REQ-UI-BLUEPRINT-OVERLAP). Both still take part in the single all-or-nothing click described here. Buildings of a currently locked building type (REQ-LOCK-BUILDING) are first excluded from the blueprint for this placement, per REQ-LOCK-UI-BLUEPRINT — they are not ghosted, not validity-checked, not placed, and their cost is excluded from the total. Left-clicking in blueprint placement mode then places the (remaining) blueprint if (a) every building in the constellation satisfies REQ-BLD-PLACE-VALID conditions (a) and (b) at its resolved tile, and (b) the player has enough building blocks to afford the total cost. Buildings that are compatible overlaps (REQ-UI-BLUEPRINT-OVERLAP) or configuration-transfer targets (REQ-UI-BLUEPRINT-TRANSFER) are excluded from the total cost and are not placed, but do not block the placement; a transfer target additionally receives the blueprint's stored settings. If both conditions are met, a construction site is added to the build queue for each remaining building in the blueprint and the full total cost is deducted from the global building blocks stock in one transaction. If a recipe ID is stored for a building, it is applied to the construction site immediately. If a schematic ID is stored, it is applied only if that schematic is currently unlocked; if it is not unlocked, the shipyard's schematic is left unset. If splitter output filters are stored, they are applied to the construction site immediately and carry over when it finishes building (REQ-BLD-SITE-CONFIG). Locked recipe IDs and splitter filter entries for locked item types are handled on placement per REQ-LOCK-UI-BLUEPRINT. After a successful placement the game remains in blueprint placement mode, allowing the player to place the same blueprint again immediately.
+
+- REQ-UI-BLUEPRINT-OVERLAP: **Compatible overlap.** In blueprint placement mode, a ghost whose footprint **exactly coincides** with the footprint of an existing placed building or construction site that is of the **same building type** and has the **same rotation** is a *compatible overlap*: the building the blueprint wants is already there. Such a ghost is **valid** despite the occupied tiles (REQ-BLD-PLACE-VALID condition (b)), so it does not block the placement of the rest of the constellation — dropping a blueprint over a partially-built copy of itself fills in what is missing. It is drawn in the ordinary per-building ghost color (REQ-BLD-GHOST), like any other valid ghost.
+
+  On placement the overlapped building is **left completely untouched**: no construction site is placed on it, no building blocks are charged for it (it is excluded from the total cost of REQ-UI-BLUEPRINT-PLACE), its rotation is not changed, and a construction site's progress is preserved. This applies per building in the blueprint, independently, and to blueprints of any size. Unlike REQ-BLD-ROTATE-IN-PLACE, which it replaces in this mode, it applies to Tunnel Entries and Tunnel Exits too — nothing is re-oriented, so the reason for their exception does not arise.
+
+  A coinciding same-type building whose **rotation differs** is not a compatible overlap: the blueprint cannot rotate it (REQ-BLD-ROTATE-IN-PLACE no longer applies here), so the position is an ordinary occupied-tile overlap and therefore invalid.
+
+  **Order of the two rules.** A ghost is tested for a configuration transfer (REQ-UI-BLUEPRINT-TRANSFER) first, and this requirement governs only what that test does not claim. Because a coinciding building of a **configurable** type always transfers, this requirement covers exactly the types that have nothing to configure:
+  - **Configurable type** (Miner, Assembler, Shipyard, Splitter) — a transfer, never a compatible overlap. It is drawn in the transfer color and hands the blueprint's settings over.
+  - **Type with no settings** (Smelter, Reprocessing Plant, Salvage Bay, belt, tunnel end) — a compatible overlap if the rotation matches, invalid otherwise. There is nothing to hand over, so the building is simply left as it is and the ghost keeps its ordinary color. This holds for a single-building blueprint too: the cursor hit-test of REQ-UI-BLUEPRINT-TRANSFER applies only to configurable types, so hovering a belt with a belt blueprint still just overlaps it.
+
+  A single blueprint can hold both kinds at once, and each ghost is judged on its own: dropping a constellation over a partial copy of itself may reconfigure some of the buildings already there (cyan) while leaving others untouched (ordinary color) and placing the rest as new construction sites.
+
+- REQ-UI-BLUEPRINT-TRANSFER: **Configuration transfer.** A blueprint hands its stored settings to buildings that are already standing where it wants them, instead of only to ones it places. A single-building blueprint therefore doubles as a way to copy one building's settings onto others of the same type: select a configured building, press **C** to capture it as a temporary blueprint and enter placement mode (REQ-UI-BLUEPRINT-TEMP), then click same-type buildings to stamp its settings onto them. **V** re-enters that mode later. A multi-building blueprint does the same for each of its buildings as it is placed.
+
+  A blueprint ghost is a **configuration-transfer target** when all of the following hold:
+  - The building is of a **configurable building type** — one with player-facing settings: Miner and Assembler (recipe), Shipyard (schematic and module layout), Splitter (output filters). Whether anything was actually configured at capture time is irrelevant; an unconfigured source transfers its unconfigured state (see below). Building types with no settings at all (Smelter, Reprocessing Plant, Salvage Bay, belts, tunnel entries and exits, the HQ) never transfer; a coinciding building of those types is a compatible overlap instead (REQ-UI-BLUEPRINT-OVERLAP).
+  - There is a target, found in one of two ways depending on the blueprint's size, because the two are different gestures:
+    - **Single-building blueprint** — the target is the building or construction site **under the cursor**, if it is of the same type. There is no coincidence test at all: the target's rotation, its footprint, and its alignment with the ghost are all irrelevant. The ghost is drawn **snapped onto the target**, at the target's own anchor and rotation, so it shows what the click will act on rather than where a building would go. This is the copying gesture, and a footprint test made it unusable for buildings that are not square: a Shipyard rotated 90° covers different tiles altogether, so no amount of lining up would ever match a differently-facing one.
+    - **Multi-building blueprint** — the ghost's footprint must **exactly coincide** with the footprint of an existing building or site of the same type (the coincidence test of REQ-BLD-ROTATE-IN-PLACE), and that target must have the **same rotation** as the ghost, which is what makes the position valid at all (REQ-UI-BLUEPRINT-OVERLAP). A constellation is placed as a layout, so its ghosts stay where the blueprint puts them: nothing snaps to the cursor and nothing is re-oriented.
+
+  At a transfer target:
+  - The ghost is drawn in a distinct **transfer** color read from `visuals.toml [overlays]`, overriding both the per-building coloring and the "invalid" color (REQ-BLD-GHOST, REQ-BLD-PLACE-VALID). The position counts as valid despite the occupied tiles (REQ-BLD-PLACE-VALID condition (b)).
+  - **Left-clicking transfers the configuration** to the existing building or site, making the target's settings **identical to the source's**: the recipe ID (Miner, Assembler), the schematic ID together with the ship layout (Shipyard), or the two output filters (Splitter). No construction site is placed, no building blocks are consumed (it is excluded from the total cost of REQ-UI-BLUEPRINT-PLACE), and the target's **rotation is not changed** — a transfer never rotates.
+  - The transfer is a **full mirror, including the absence of a setting**: where the blueprint stores no configuration for a field (REQ-UI-BLUEPRINT-STORAGE stores nothing for an unselected recipe or schematic, and no filter lists for a splitter whose filters were empty at capture time), the target's corresponding setting is **cleared** rather than left as it was. So a splitter captured with no filters clears the target splitter's filters back to accept-all, and a miner captured with no recipe selected clears the target miner's recipe. This holds for every blueprint size, so a constellation captured from unconfigured buildings clears the settings of every matching building it is dropped on.
+  - The transfer has the same effects as making that selection through the selection panel, clearing included: buffer clearing per REQ-MAT-INPUT-BUFFER and REQ-MAT-OUTPUT-BUFFER, and, for a Shipyard, in-progress cycle cancellation per REQ-BLD-SHIPYARD. It inherits the no-op rule of REQ-MAT-INPUT-BUFFER with them: a transfer onto a building whose settings already match the source changes nothing at all — no buffers cleared, no production cycle cancelled, no construction progress lost — so repeatedly clicking already-matching buildings is harmless. Each field is judged on its own, so transferring an identical recipe with a differing layout affects only the layout. The layout configuration dialog does not auto-open (REQ-MOD-UI-AUTO-DIALOG).
+  - Unlock gating matches placement (REQ-UI-BLUEPRINT-PLACE): a stored schematic is applied only if it is currently unlocked, and locked recipe IDs and splitter filter entries for locked item types are handled per REQ-LOCK-UI-BLUEPRINT.
+  - Both operational buildings and construction sites are transfer targets (REQ-BLD-SITE-CONFIG); a configuration applied to a site carries over unchanged when it finishes building.
+  - After the transfer the game stays in blueprint placement mode, so further same-type buildings can be clicked in turn.
+  - A blueprint placement applies every transfer among its ghosts in the same click that places its new construction sites (REQ-UI-BLUEPRINT-PLACE); the placement is all-or-nothing, so if any ghost is invalid nothing is placed and nothing is transferred.
+
+- REQ-UI-BLUEPRINT-DELETE: Clicking the delete icon ("×") on a blueprint card (REQ-UI-BLUEPRINT-CARD) immediately removes that blueprint from the list, without a confirmation prompt. The blueprint selection dialog stays open and its card grid reflows to close the gap. If the deleted blueprint was active in blueprint placement mode, that mode is exited.
+
+- REQ-UI-BLUEPRINT-SAVE: On application shutdown, all current blueprints are serialized to a file named `blueprints.toml` located in the same directory as the application executable. The TOML structure matches REQ-UI-BLUEPRINT-STORAGE. Write errors are silently ignored on shutdown (no button, no dialog).
+
+- REQ-UI-BLUEPRINT-LOAD: At application startup, blueprints are loaded from `blueprints.toml` in the same directory as the application executable, populating the blueprint list (in the order they appear in the file). If the file does not exist, the blueprint list starts empty with no error. If the file exists but cannot be parsed (malformed TOML), a modal error dialog describes the failure and the blueprint list starts empty. There is no Load button and no runtime reload.
 
 ## Balancing Tool
 
@@ -500,19 +822,23 @@ A separate executable target (`balancing`) that links against `lib` but contains
 
 - REQ-BAL-SIM-ENV: Each arena simulates a pure-space environment using the same tick-based simulation as the main game. There is no asteroid, no buildings, no belts, no wave system, and no threat accumulation. Only ships, HQs, defence stations, and combat are active.
 - REQ-BAL-SIM-AI: Ships use the same AI and stats as in the main game. Ships with no target in sensor range advance toward the enemy team's HQ. Ships that detect an enemy in sensor range engage it as in the normal game (REQ-SHP-COMBAT, REQ-SHP-ENEMY-AI).
-- REQ-BAL-SIM-SPEED: Each arena that is not being inspected runs its simulation at maximum tick rate (as many ticks per second as the hardware allows), with no rendering. An inspected arena runs at a player-controllable game speed (same speed steps as the main game: 0×, 0.5×, 1×, 2×, 4×) with full rendering in the inspect window, defaulting to 1× on open.
+- REQ-BAL-SIM-SPEED: Each arena that is not being inspected runs its simulation at maximum tick rate (as many ticks per second as the hardware allows), with no rendering. An inspected arena runs at a player-controllable game speed (same speed steps as the main game: 0×, 0.5×, 1×, 2×, 10×) with full rendering in the inspect window, defaulting to 1× on open.
 - REQ-BAL-SIM-PARALLEL: All arenas are simulated in parallel, each on its own thread.
 - REQ-BAL-SIM-END: An arena fight ends when either team's HQ is destroyed or all ships and defence stations of one team have been destroyed. If a team has no defence stations, destroying all its ships is sufficient. When the fight ends, the simulation for that arena stops.
 
 ### UI
 
-- REQ-BAL-UI-WINDOW: On startup the tool displays a window containing a "Reload Config" button and a "Start All" button at the top (in that order, left to right), followed by a scrollable vertical list of arena widgets, one per arena defined in `balancing.toml`. Simulations do not start automatically on startup. All buttons and controls in the main window are disabled while an arena is being inspected (REQ-BAL-UI-INSPECT).
+- REQ-BAL-UI-WINDOW: On startup the tool displays a window containing a "Reload Config" button, a "Start All" button, and a "Log" button at the top (in that order, left to right), followed by a scrollable vertical list of arena widgets, one per arena defined in `balancing.toml`. Simulations do not start automatically on startup. All buttons and controls in the main window are disabled while an arena is being inspected (REQ-BAL-UI-INSPECT).
 - REQ-BAL-UI-RELOAD: The "Reload Config" button reloads all config files from disk (`balancing.toml`, `ships.toml`, `stations.toml`), stops any running simulations, and replaces the arena widget list with freshly created widgets from the reloaded config. The button is disabled while any arena simulation is currently running.
 - REQ-BAL-UI-START-ALL: The "Start All" button is placed above the scrollable arena list, to the right of the "Reload Config" button. Clicking it starts (or restarts) the simulation for every arena that is not currently running. The button is disabled when all arenas are currently running.
-- REQ-BAL-UI-WIDGET: Each arena widget displays the arena name, an "Inspect" button (to the right of the arena name), and two columns (one per team). Each column shows the team name as a header, then directly below the header the team's **accumulated threat level** — the sum, across the team's configured ship entries, of each entry's `count` multiplied by the threat cost (REQ-MOD-THREAT) of one ship of that entry computed from its level-independent module layout. Only ships contribute; the HQ and defence stations are excluded. This value is static: it is computed once from the full configured roster and does not change as ships are destroyed during the fight. Below the threat level, the column shows a list of entries. The HQ is always the first entry in each column. Below the HQ, ship types are listed, followed by defence stations (if any). Each entry uses the format `surviving/total TypeName` for ship entries and `surviving/total TypeName Llevel` for the HQ and defence station entries — for example `2/3 Fighter`, `1/1 HQ L1`, or `2/2 Enemy Station L3`. The surviving count updates live as the simulation progresses. When the fight ends, the winning team's name header is prefixed with `[WON]`.
+- REQ-BAL-UI-LOG: The "Log" button is placed in the header to the right of the "Start All" button. It is enabled whenever the main window's controls are enabled — including while simulations are running (it captures a live snapshot) — and, like all main window controls, is disabled only while an arena is being inspected (REQ-BAL-UI-WINDOW). Clicking it writes the current state of every arena to a file named `balancing_log.md` in the tool's current working directory, replacing (overwriting) any previous content of that file. The log captures, for every arena in `balancing.toml` order, exactly the information shown in that arena's widget (REQ-BAL-UI-WIDGET) at the moment the button is clicked. Each arena is written as its own section:
+  - A heading with the arena name followed by the arena's current state — `not started`, `running`, or `ended` (corresponding to the widget border colors of REQ-BAL-UI-WIDGET-BORDER). For an `ended` arena, the heading also includes the battle duration (REQ-BAL-UI-WIDGET), for example `ended, 42.3 s`.
+  - A markdown table with one column per team (team 1 left, team 2 right). Each team's column header shows the team name — prefixed with `[WON]` when that team won, matching REQ-BAL-UI-WIDGET — the team's accumulated threat level, and the team's remaining EHP percentage (REQ-BAL-UI-WIDGET).
+  - Below the header, each table row holds one of that team's entries, in the same order and text format as the widget (REQ-BAL-UI-WIDGET): the HQ first, then ship types, then defence stations, formatted `surviving/total TypeName` for ship entries and `surviving/total TypeName Llevel` for the HQ and defence station entries. When the two teams have different numbers of entries, the shorter column's remaining cells are left blank.
+- REQ-BAL-UI-WIDGET: Each arena widget displays the arena name, an "Inspect" button (to the right of the arena name), and two columns (one per team). Each column shows the team name as a header, then directly below the header the team's **accumulated threat level** — the sum, across the team's configured ship entries, of each entry's `count` multiplied by the threat cost (REQ-MOD-THREAT) of one ship of that entry computed from its level-independent module layout. Only ships contribute; the HQ and defence stations are excluded. This value is static: it is computed once from the full configured roster and does not change as ships are destroyed during the fight. Directly below the threat level, the column shows the team's **remaining EHP percentage** — the sum of the current HP of all of the team's ships and defence stations, divided by the sum of their maximum HP, expressed as a percentage rounded to a whole number. Maximum HP is the final per-entity maximum (REQ-MOD-STAT-CALC), so module HP bonuses such as armor plates are included. (The game has no damage mitigation, so effective HP equals raw HP.) The HQ is excluded from both sums. A destroyed ship or station contributes 0 to the numerator and its maximum HP to the denominator, so the value measures how much of the team's fielded durability remains: it starts at 100% and decreases as units take damage or are destroyed. Unlike the static threat level, this value updates live as the simulation progresses. If the team has neither ships nor defence stations (the denominator is 0), the percentage is shown as `n/a`. Below the EHP percentage, the column shows a list of entries. The HQ is always the first entry in each column. Below the HQ, ship types are listed, followed by defence stations (if any). Each entry uses the format `surviving/total TypeName` for ship entries and `surviving/total TypeName Llevel` for the HQ and defence station entries — for example `2/3 Fighter`, `1/1 HQ L1`, or `2/2 Enemy Station L3`. The surviving count updates live as the simulation progresses. When the fight ends, the winning team's name header is prefixed with `[WON]`. When the fight has ended, the widget also displays the arena's **battle duration** — an arena-level value (not per team) giving the game time the fight lasted, computed as the number of simulated ticks at completion multiplied by the simulation's fixed tick duration (the same tick-based simulation as the main game, REQ-BAL-SIM-ENV). This is game time, not wall-clock time, so it is independent of how fast the arena was simulated (non-inspected arenas run at maximum tick rate, REQ-BAL-SIM-SPEED). It is shown in seconds with one decimal place, for example `Duration: 42.3 s`. The battle duration is shown only for completed (ended) runs; it is not shown while the arena is not started or running.
 - REQ-BAL-UI-WIDGET-START: Each arena widget contains a "Start" button that starts the simulation for that arena. The button is disabled while the arena's simulation is running. When a finished arena's Start button is clicked, a fresh simulation is created and started (the widget resets to initial unit counts, the border returns to blue, and the previous results are replaced).
 - REQ-BAL-UI-WIDGET-BORDER: Each arena widget has a colored border indicating its state: grey when not yet started, blue while its simulation is running, and green when the fight has ended.
 - REQ-BAL-UI-INSPECT: Clicking an arena widget's "Inspect" button opens a new inspect window for that arena. Any previously open inspect window is closed first (its arena's simulation is aborted and its widget border returns to grey). The inspected arena is restarted with a fresh simulation that runs at controllable game speed with full rendering (REQ-BAL-SIM-SPEED). The arena widget updates live during inspection (surviving counts, border color, `[WON]` prefix) as it does for non-inspected arenas. Only one inspect window may be open at a time.
-- REQ-BAL-UI-INSPECT-WINDOW: The inspect window consists of three sections, top to bottom: a title bar area containing the arena name and game speed controls (same buttons as the main game: 0×, 0.5×, 1×, 2×, 4×, with Space to toggle pause — see REQ-UI-SPEED and REQ-UI-HOTKEYS), the arena view in the center, and an info panel at the bottom displaying the same team columns and entry format as the arena widget in the main window (REQ-BAL-UI-WIDGET), updated live.
+- REQ-BAL-UI-INSPECT-WINDOW: The inspect window consists of three sections, top to bottom: a title bar area containing the arena name and game speed controls (same buttons as the main game: 0×, 0.5×, 1×, 2×, 10×, with Space to toggle pause — see REQ-UI-SPEED and REQ-UI-HOTKEYS), the arena view in the center, and an info panel at the bottom displaying the same team columns and entry format as the arena widget in the main window (REQ-BAL-UI-WIDGET), updated live, including the arena's battle duration once the fight has ended (REQ-BAL-UI-WIDGET).
 - REQ-BAL-UI-INSPECT-VIEW: The arena view renders all tiles of the arena and displays ships, HQs, defence stations, and laser beams using the same visual elements and `visuals.toml` colors as the main game. Team 1 uses player visual styles; team 2 uses enemy visual styles. The view has a fixed zoom level — no zoom or scroll is possible. The tile size is derived so that the full arena (all tiles) fits within the view.
 - REQ-BAL-UI-INSPECT-CLOSE: Closing the inspect window (via the window's close button) aborts the inspected arena's simulation. The arena widget's border returns to grey and its surviving counts are left as they were at the moment of closing. All main window buttons and controls are re-enabled.

src/CMakeLists.txt

@@ -1,4 +1,4 @@
-set(TARGET_BASE_NAME "DotaFactory")
+set(TARGET_BASE_NAME "${PRODUCT_NAME}")
 
 set(TARGET_APP_NAME "${TARGET_BASE_NAME}")
 set(TARGET_LIB_NAME "${TARGET_BASE_NAME}_lib")
@@ -10,7 +10,12 @@ set(TARGET_LIB_INCLUDE_DIRS
     "${CMAKE_CURRENT_SOURCE_DIR}/lib"
     "${CMAKE_CURRENT_SOURCE_DIR}/external"
 )
-set(TARGET_UI_INCLUDE_DIRS "${CMAKE_CURRENT_SOURCE_DIR}/ui")
+set(TARGET_UI_INCLUDE_DIRS
+    "${CMAKE_CURRENT_SOURCE_DIR}/ui"
+    # The balancing target compiles a few ui files into itself rather than linking the
+    # ui library, and the ship stats panel is built from the selection card's parts.
+    "${CMAKE_CURRENT_SOURCE_DIR}/ui/selection"
+)
 set(TARGET_TEST_INCLUDE_DIRS "${CMAKE_CURRENT_SOURCE_DIR}/test")
 set(TARGET_BALANCING_INCLUDE_DIRS "${CMAKE_CURRENT_SOURCE_DIR}/balancing")
 
@@ -78,6 +83,7 @@ unset(SRCS)
 
 set(HDRS)
 set(SRCS)
+set(UI_INCLUDE_PATH)
 
 add_subdirectory(ui)
 
@@ -106,6 +112,7 @@ set_target_properties(${TARGET_UI_NAME} PROPERTIES
 )
 target_include_directories(${TARGET_UI_NAME} PUBLIC
     "${TARGET_UI_INCLUDE_DIRS}"
+    "${UI_INCLUDE_PATH}"
     "${TARGET_LIB_INCLUDE_DIRS}"
     "${LIB_INCLUDE_PATH}"
 )
@@ -117,6 +124,7 @@ target_link_libraries(${TARGET_UI_NAME}
     Qt5::Network
     Qt5::Multimedia
     Qt5::Charts
+    Qt5::Svg
 )
 target_compile_definitions(${TARGET_UI_NAME} PRIVATE TOML_FLOAT_CHARCONV=0)
 
@@ -183,6 +191,19 @@ target_compile_definitions(${TARGET_APP_NAME} PRIVATE
 )
 target_link_libraries(${TARGET_APP_NAME} ${TARGET_UI_NAME})
 
+# Embed the Windows version resource so the version shows on the executable's
+# Details tab (right-click -> Properties). Values come from cmake/version.cmake
+# (version numbers) and the product identity variables in the top-level
+# CMakeLists.txt. MSVC compiles the .rc automatically once it is a target source.
+if (WIN32)
+    configure_file(
+        "${CMAKE_SOURCE_DIR}/cmake/version.rc.in"
+        "${CMAKE_CURRENT_BINARY_DIR}/version.rc"
+        @ONLY
+    )
+    target_sources(${TARGET_APP_NAME} PRIVATE "${CMAKE_CURRENT_BINARY_DIR}/version.rc")
+endif ()
+
 unset(APP_FILES)
 unset(RELATIVE_HDRS)
 unset(RELATIVE_SRCS)

src/balancing/ArenaSimulation.cpp

@@ -2,6 +2,8 @@
 
 #include <algorithm>
 #include <cassert>
+#include <cmath>
+#include <string>
 
 #include <QVector2D>
 
@@ -20,7 +22,7 @@
 #include "PositionComponent.h"
 #include "RepairSystem.h"
 #include "SalvagerSystem.h"
-#include "ScrapSystem.h"
+#include "DebrisSystem.h"
 #include "ShipIdentityComponent.h"
 #include "ShipSystem.h"
 #include "ShipsConfig.h"
@@ -42,9 +44,10 @@ ArenaSimulation::ArenaSimulation(const GameConfig& gameConfig,
     , m_team1HqEntity(entt::null)
     , m_team2HqEntity(entt::null)
     , m_finished(false)
-    , m_winnerTeam(-1)
     , m_stopRequested(false)
 {
+    m_factoryState = makeFactoryState(m_gameConfig);
+
     m_buildingSystem = std::make_unique<BuildingSystem>(
         m_gameConfig,
         m_beltSystem,
@@ -62,7 +65,7 @@ ArenaSimulation::ArenaSimulation(const GameConfig& gameConfig,
     m_movementIntentSystem = std::make_unique<MovementIntentSystem>();
     m_dynamicBodySystem    = std::make_unique<DynamicBodySystem>();
     m_combatSystem   = std::make_unique<CombatSystem>(m_gameConfig);
-    m_scrapSystem    = std::make_unique<ScrapSystem>(m_admin);
+    m_debrisSystem    = std::make_unique<DebrisSystem>(m_admin);
     m_salvagerSystem = std::make_unique<SalvagerSystem>(m_admin);
     m_repairSystem   = std::make_unique<RepairSystem>(m_admin);
 
@@ -86,12 +89,49 @@ ArenaSimulation::ArenaSimulation(const GameConfig& gameConfig,
 
     placeStructures();
     spawnShips();
+    computeTeamMaxEhp();
 
     m_shipSystem->triggerRallyDeparture();
 
     updateStatus();
 }
 
+std::string ArenaStatus::TeamStatus::getEhpPercentText() const
+{
+    if (maxEhp <= 0.0)
+    {
+        return "n/a";
+    }
+    const int percent = static_cast<int>(std::lround(100.0 * currentEhp / maxEhp));
+    return std::to_string(percent) + "%";
+}
+
+void ArenaSimulation::computeTeamMaxEhp()
+{
+    m_teamMaxEhp[0] = 0.0;
+    m_teamMaxEhp[1] = 0.0;
+
+    // Ships contribute their full max HP.
+    m_admin.forEach<ShipIdentityComponent, FactionComponent, HealthComponent>(
+        [this](entt::entity /*e*/, const ShipIdentityComponent& /*si*/,
+               const FactionComponent& f, const HealthComponent& h)
+        {
+            m_teamMaxEhp[f.isEnemy ? 1 : 0] += static_cast<double>(h.maxHp);
+        });
+
+    // Defence stations contribute their full max HP; the HQ is excluded.
+    m_admin.forEach<StationBodyComponent, FactionComponent, HealthComponent>(
+        [this](entt::entity e, const StationBodyComponent& /*sb*/,
+               const FactionComponent& f, const HealthComponent& h)
+        {
+            if (m_admin.hasAll<HqProxyComponent>(e))
+            {
+                return;
+            }
+            m_teamMaxEhp[f.isEnemy ? 1 : 0] += static_cast<double>(h.maxHp);
+        });
+}
+
 ArenaSimulation::~ArenaSimulation() = default;
 
 BuildingId ArenaSimulation::allocateBuildingId()
@@ -124,7 +164,7 @@ void ArenaSimulation::placeStructures()
                                                 hp, hp, false);
         // Tag as an HQ so it is excluded from repair targeting (REQ-SHP-REPAIR).
         m_admin.addComponent<HqProxyComponent>(m_team1HqEntity);
-        m_buildingSystem->registerTileOccupancy(absCells, allocateBuildingId());
+        m_buildingSystem->registerTileOccupancy(m_factoryState, absCells, allocateBuildingId());
     }
 
     // Team 2 HQ — ECS proxy entity, enemy faction (isEnemy=true). No weapon.
@@ -145,7 +185,7 @@ void ArenaSimulation::placeStructures()
                                                 hp, hp, true);
         // Tag as an HQ so it is excluded from repair targeting (REQ-SHP-REPAIR).
         m_admin.addComponent<HqProxyComponent>(m_team2HqEntity);
-        m_buildingSystem->registerTileOccupancy(absCells, allocateBuildingId());
+        m_buildingSystem->registerTileOccupancy(m_factoryState, absCells, allocateBuildingId());
     }
 
     auto placeArenaStation = [&](const ArenaStationEntry& entry, bool isEnemy)
@@ -199,7 +239,7 @@ void ArenaSimulation::placeStructures()
             m_admin.addComponent<ModuleOwnerComponent>(wChild,
                 ModuleOwnerComponent{stationEntity});
         }
-        m_buildingSystem->registerTileOccupancy(absCells, allocateBuildingId());
+        m_buildingSystem->registerTileOccupancy(m_factoryState, absCells, allocateBuildingId());
     };
 
     for (const ArenaStationEntry& entry : m_arenaConfig.teams[0].stations)
@@ -273,7 +313,7 @@ void ArenaSimulation::requestStop()
     m_stopRequested.store(true, std::memory_order_relaxed);
 }
 
-ArenaStatus ArenaSimulation::status() const
+ArenaStatus ArenaSimulation::getStatus() const
 {
     std::lock_guard<std::mutex> lock(m_statusMutex);
     return m_status;
@@ -284,13 +324,13 @@ void ArenaSimulation::tick()
     // Ship behavior systems (tick step 7): evaluate, select winner, execute.
     // Module + combat systems emit their tool beams into a shared buffer.
     m_shipSystem->clearMovementIntents();
-    m_aiSystem->tick(m_admin, *m_buildingSystem, *m_scrapSystem);
+    m_aiSystem->tick(m_admin, m_factoryState);
     std::vector<BeamFiredEvent> beamFiredEvents;
-    m_salvagerSystem->tick(m_currentTick, *m_scrapSystem, *m_buildingSystem, beamFiredEvents);
+    m_salvagerSystem->tick(m_currentTick, m_factoryState, beamFiredEvents);
     m_repairSystem->tick(m_currentTick, beamFiredEvents);
 
     // Combat resolution (tick step 8).
-    m_combatSystem->tick(m_currentTick, m_admin, *m_buildingSystem, beamFiredEvents);
+    m_combatSystem->tick(m_currentTick, m_admin, beamFiredEvents);
     m_beamFiredEvents.insert(m_beamFiredEvents.end(), beamFiredEvents.begin(), beamFiredEvents.end());
     m_combatSystem->applyPendingDamage(m_currentTick, m_admin);
 
@@ -302,7 +342,7 @@ void ArenaSimulation::tick()
     m_dynamicBodySystem->tick(m_admin);
 
     // Scrap despawn (tick step 11).
-    m_scrapSystem->tickDespawn(m_currentTick);
+    m_debrisSystem->tickDespawn(m_currentTick);
 
     ++m_currentTick;
 
@@ -333,8 +373,8 @@ void ArenaSimulation::tickDeaths()
         if (si.scrapDrop > 0)
         {
             const Tick despawnAt = m_currentTick
-                + secondsToTicks(m_gameConfig.world.scrapDespawnSeconds);
-            m_scrapSystem->spawn(pos.value, si.scrapDrop, despawnAt);
+                + secondsToTicks(m_gameConfig.world.debrisDespawnSeconds);
+            m_debrisSystem->spawn(pos.value, si.scrapDrop, despawnAt);
         }
         m_shipSystem->despawn(deadEntity);
     }
@@ -354,7 +394,7 @@ void ArenaSimulation::tickDeaths()
     for (entt::entity deadEntity : deadStations)
     {
         const StationBodyComponent& sb = m_admin.get<StationBodyComponent>(deadEntity);
-        m_buildingSystem->unregisterTileOccupancy(sb.bodyCells);
+        m_buildingSystem->unregisterTileOccupancy(m_factoryState, sb.bodyCells);
         {
             std::vector<entt::entity> stationChildren;
             m_admin.forEach<ModuleOwnerComponent>(
@@ -394,10 +434,13 @@ void ArenaSimulation::tickDeaths()
         });
 
     m_admin.forEach<StationBodyComponent, FactionComponent>(
-        [&team1HasUnits, &team2HasUnits](entt::entity /*e*/,
+        [this, &team1HasUnits, &team2HasUnits](entt::entity e,
                                           const StationBodyComponent& /*sb*/,
                                           const FactionComponent& f)
         {
+            // The HQ carries a StationBodyComponent but is not a defence station;
+            // its destruction is a separate end condition (REQ-BAL-SIM-END).
+            if (m_admin.hasAll<HqProxyComponent>(e)) { return; }
             if (f.isEnemy) { team2HasUnits = true; }
             else           { team1HasUnits = true; }
         });
@@ -431,42 +474,47 @@ bool ArenaSimulation::isFinished() const
     return m_finished;
 }
 
-int ArenaSimulation::winnerTeam() const
+std::optional<int> ArenaSimulation::getWinnerTeam() const
 {
     return m_winnerTeam;
 }
 
-Tick ArenaSimulation::currentTick() const
+Tick ArenaSimulation::getCurrentTick() const
 {
     return m_currentTick;
 }
 
-const ArenaConfig& ArenaSimulation::arenaConfig() const
+const ArenaConfig& ArenaSimulation::getArenaConfig() const
 {
     return m_arenaConfig;
 }
 
-const BuildingSystem& ArenaSimulation::buildings() const
+const FactoryState& ArenaSimulation::getFactoryState() const
+{
+    return m_factoryState;
+}
+
+const BuildingSystem& ArenaSimulation::getBuildings() const
 {
     return *m_buildingSystem;
 }
 
-const ShipSystem& ArenaSimulation::ships() const
+const ShipSystem& ArenaSimulation::getShips() const
 {
     return *m_shipSystem;
 }
 
-const ScrapSystem& ArenaSimulation::scraps() const
+const DebrisSystem& ArenaSimulation::getDebrisSystem() const
 {
-    return *m_scrapSystem;
+    return *m_debrisSystem;
 }
 
-EntityAdmin& ArenaSimulation::admin()
+EntityAdmin& ArenaSimulation::getAdmin()
 {
     return m_admin;
 }
 
-const EntityAdmin& ArenaSimulation::admin() const
+const EntityAdmin& ArenaSimulation::getAdmin() const
 {
     return m_admin;
 }
@@ -476,12 +524,41 @@ void ArenaSimulation::updateStatus()
     ArenaStatus newStatus;
     newStatus.finished = m_finished;
     newStatus.winnerTeam = m_winnerTeam;
+    newStatus.durationSeconds = ticksToSeconds(m_currentTick);
+
+    // Live remaining HP of each team's ships and defence stations (HQ excluded);
+    // the EHP-percentage numerator (denominator is the fixed m_teamMaxEhp).
+    double currentEhp[2] = {0.0, 0.0};
+    m_admin.forEach<ShipIdentityComponent, FactionComponent, HealthComponent>(
+        [&currentEhp](entt::entity /*e*/, const ShipIdentityComponent& /*si*/,
+                      const FactionComponent& f, const HealthComponent& h)
+        {
+            if (h.hp > 0.0f)
+            {
+                currentEhp[f.isEnemy ? 1 : 0] += static_cast<double>(h.hp);
+            }
+        });
+    m_admin.forEach<StationBodyComponent, FactionComponent, HealthComponent>(
+        [this, &currentEhp](entt::entity e, const StationBodyComponent& /*sb*/,
+                            const FactionComponent& f, const HealthComponent& h)
+        {
+            if (m_admin.hasAll<HqProxyComponent>(e))
+            {
+                return;
+            }
+            if (h.hp > 0.0f)
+            {
+                currentEhp[f.isEnemy ? 1 : 0] += static_cast<double>(h.hp);
+            }
+        });
 
     for (int ti = 0; ti < 2; ++ti)
     {
         ArenaStatus::TeamStatus& teamStatus = newStatus.teams[ti];
         teamStatus.name = m_arenaConfig.teams[ti].name;
         teamStatus.threatLevel = m_teamThreat[ti];
+        teamStatus.currentEhp = currentEhp[ti];
+        teamStatus.maxEhp = m_teamMaxEhp[ti];
 
         // HQ entry (always first).
         {

src/balancing/ArenaSimulation.h

@@ -10,6 +10,7 @@
 
 #include "BalancingConfig.h"
 #include "BeltSystem.h"
+#include "FactoryState.h"
 #include "EntityAdmin.h"
 #include "BuildingId.h"
 
@@ -26,7 +27,7 @@ class MovementIntentSystem;
 class RepairSystem;
 class SalvagerSystem;
 class ShipSystem;
-class ScrapSystem;
+class DebrisSystem;
 
 struct ArenaStatus
 {
@@ -44,12 +45,24 @@ struct ArenaStatus
     {
         std::string name;
         double threatLevel = 0.0;    // accumulated threat of the team's configured ships
+        // Remaining durability of the team's ships and defence stations (HQ
+        // excluded). currentEhp is summed live; maxEhp is the fixed full-HP
+        // baseline. See getEhpPercentText() for the displayed value.
+        double currentEhp = 0.0;
+        double maxEhp = 0.0;
         std::vector<Entry> entries;  // HQ first, then ships, then stations
+
+        // Remaining EHP as a whole-number percentage ("NN%"), or "n/a" when the
+        // team has no ships or stations (maxEhp == 0).
+        std::string getEhpPercentText() const;
     };
 
     TeamStatus teams[2];
     bool finished = false;
-    int winnerTeam = -1;  // 0 or 1 when finished; -1 while running
+    std::optional<int> winnerTeam;  // 0 or 1 when finished; nullopt while running
+    // Game time the fight has lasted (simulated ticks * fixed tick duration).
+    // Meaningful once finished; the battle duration shown for completed runs.
+    double durationSeconds = 0.0;
 };
 
 class ArenaSimulation
@@ -66,22 +79,24 @@ public:
     void tickOnce();
     std::vector<BeamFiredEvent> drainBeamFiredEvents();
 
-    ArenaStatus status() const;
+    ArenaStatus getStatus() const;
     bool isFinished() const;
-    int winnerTeam() const;
-    Tick currentTick() const;
+    std::optional<int> getWinnerTeam() const;
+    Tick getCurrentTick() const;
 
-    const ArenaConfig& arenaConfig() const;
-    const BuildingSystem& buildings() const;
-    const ShipSystem& ships() const;
-    const ScrapSystem& scraps() const;
-    EntityAdmin&       admin();
-    const EntityAdmin& admin() const;
+    const ArenaConfig& getArenaConfig() const;
+    const BuildingSystem& getBuildings() const;
+    const FactoryState&   getFactoryState() const;
+    const ShipSystem& getShips() const;
+    const DebrisSystem& getDebrisSystem() const;
+    EntityAdmin&       getAdmin();
+    const EntityAdmin& getAdmin() const;
 
 private:
     BuildingId allocateBuildingId();
     void placeStructures();
     void spawnShips();
+    void computeTeamMaxEhp();
     void tick();
     void tickDeaths();
     void updateStatus();
@@ -94,6 +109,7 @@ private:
     BuildingId m_nextBuildingId;
 
     EntityAdmin m_admin;
+    FactoryState                      m_factoryState;
     BeltSystem m_beltSystem;
     std::unique_ptr<BuildingSystem> m_buildingSystem;
     std::unique_ptr<ShipSystem>     m_shipSystem;
@@ -101,7 +117,7 @@ private:
     std::unique_ptr<MovementIntentSystem> m_movementIntentSystem;
     std::unique_ptr<DynamicBodySystem>    m_dynamicBodySystem;
     std::unique_ptr<CombatSystem>   m_combatSystem;
-    std::unique_ptr<ScrapSystem>    m_scrapSystem;
+    std::unique_ptr<DebrisSystem>    m_debrisSystem;
     std::unique_ptr<SalvagerSystem> m_salvagerSystem;
     std::unique_ptr<RepairSystem>   m_repairSystem;
 
@@ -109,12 +125,16 @@ private:
     entt::entity m_team2HqEntity;
 
     bool m_finished;
-    int m_winnerTeam;
+    std::optional<int> m_winnerTeam;
     std::atomic<bool> m_stopRequested;
 
     // Static accumulated threat per team, computed once from the configured roster.
     double m_teamThreat[2] = {0.0, 0.0};
 
+    // Full-HP baseline per team (ships + defence stations, HQ excluded), computed
+    // once after spawning; the EHP-percentage denominator.
+    double m_teamMaxEhp[2] = {0.0, 0.0};
+
     std::vector<BeamFiredEvent> m_beamFiredEvents;
 
     mutable std::mutex m_statusMutex;

src/balancing/ArenaView.cpp

@@ -1,4 +1,5 @@
 #include "ArenaView.h"
+#include "FactoryQueries.h"
 
 #include <algorithm>
 #include <cmath>
@@ -15,7 +16,7 @@
 #include "Building.h"
 #include "BuildingSystem.h"
 #include "EntityHitTest.h"
-#include "EntitySelectedEvent.h"
+#include "EntitySelectionChangedEvent.h"
 #include "EventManager.h"
 #include "FacingComponent.h"
 #include "FactionComponent.h"
@@ -24,11 +25,12 @@
 #include "PositionComponent.h"
 #include "RepairBehavior.h"
 #include "SalvageScrapBehavior.h"
-#include "ScrapSystem.h"
+#include "DebrisSystem.h"
 #include "SensorRangeComponent.h"
 #include "ShipIdentityComponent.h"
 #include "StationBodyComponent.h"
-#include "ScrapDataComponent.h"
+#include "DebrisComponent.h"
+#include "WorldPrimitives.h"
 
 namespace
 {
@@ -73,7 +75,7 @@ void ArenaView::setGameSpeed(double multiplier)
         std::make_shared<GameSpeedChangedEvent>(multiplier));
 }
 
-double ArenaView::gameSpeed() const
+double ArenaView::getGameSpeed() const
 {
     return m_gameSpeedMultiplier;
 }
@@ -121,7 +123,7 @@ void ArenaView::onFrame()
     // Expire old beams. Lifetime is measured in game ticks so beams stay
     // visible while the simulation is paused or slowed (REQ-SHP-FIRING-BEAM).
     {
-        const Tick now = m_sim->currentTick();
+        const Tick now = m_sim->getCurrentTick();
         std::vector<ActiveBeam> live;
         for (const ActiveBeam& b : m_activeBeams)
         {
@@ -144,16 +146,16 @@ void ArenaView::onFrame()
 void ArenaView::handleEvent(std::shared_ptr<const BeamFiredEvent> event)
 {
     float maxRadius = 0.125f;
-    if (m_sim->admin().isValid(event->target)
-        && m_sim->admin().hasAll<StationBodyComponent>(event->target))
+    if (m_sim->getAdmin().isValid(event->target)
+        && m_sim->getAdmin().hasAll<StationBodyComponent>(event->target))
     {
-        const StationBodyComponent& sb = m_sim->admin().get<StationBodyComponent>(event->target);
+        const StationBodyComponent& sb = m_sim->getAdmin().get<StationBodyComponent>(event->target);
         const int shorter = std::min(sb.footprint.width(),
                                      sb.footprint.height());
         maxRadius = shorter / 2.0f;
     }
-    else if (m_sim->admin().isValid(event->target)
-        && m_sim->admin().hasAll<ScrapDataComponent>(event->target))
+    else if (m_sim->getAdmin().isValid(event->target)
+        && m_sim->getAdmin().hasAll<DebrisComponent>(event->target))
     {
         maxRadius = 0.1f;
     }
@@ -175,80 +177,53 @@ void ArenaView::paintGL()
     QPainter painter(this);
     painter.setRenderHint(QPainter::Antialiasing, false);
 
-    drawTiles(painter);
-    drawBuildings(painter);
-    drawStations(painter);
-    drawScrap(painter);
+    // One transform snapshot for the whole frame; every draw below reads the
+    // viewport through it.
+    const WorldCoordinates coordinates = getCoordinates();
+
+    drawTiles(painter, coordinates);
+    drawBuildings(painter, coordinates);
+    drawStations(painter, coordinates);
+    drawDebris(painter, coordinates);
     if (m_debugDraw)
     {
-        drawDebugSensorRanges(painter);
-        drawDebugTargetLines(painter);
+        drawDebugSensorRanges(painter, coordinates);
+        drawDebugTargetLines(painter, coordinates);
     }
-    drawShips(painter);
-    drawBeams(painter);
+    drawShips(painter, coordinates);
+    drawBeams(painter, coordinates);
 }
 
 // ---------------------------------------------------------------------------
 // Coordinate helpers
 // ---------------------------------------------------------------------------
 
-float ArenaView::tilePx() const
+WorldCoordinates ArenaView::getCoordinates() const
 {
-    const ArenaConfig& ac = m_sim->arenaConfig();
+    // The arena is a fixed, fully visible world — unlike the game view it has no
+    // scrolling, so the tile size comes from fitting the whole arena in the widget.
+    const ArenaConfig& ac = m_sim->getArenaConfig();
     const int totalWidth = ac.playerBufferWidth_tiles
                          + ac.contestZoneWidth_tiles
                          + ac.enemyBufferWidth_tiles;
-    const int totalHeight = ac.heightTiles;
-    if (totalWidth <= 0 || totalHeight <= 0) { return 1.0f; }
-
-    const float pxPerTileH = static_cast<float>(height()) / static_cast<float>(totalHeight);
-    const float pxPerTileW = static_cast<float>(width())  / static_cast<float>(totalWidth);
-    return std::min(pxPerTileH, pxPerTileW);
-}
-
-QPointF ArenaView::worldToWidget(QVector2D worldPos) const
-{
-    return QPointF(
-        static_cast<qreal>(worldPos.x() * tilePx()),
-        static_cast<qreal>(worldPos.y() * tilePx()));
-}
-
-QPointF ArenaView::tileToWidget(QPoint tile) const
-{
-    return worldToWidget(QVector2D(static_cast<float>(tile.x()),
-                                   static_cast<float>(tile.y())));
-}
-
-QRectF ArenaView::tileRect(QPoint tile) const
-{
-    const QPointF tl = tileToWidget(tile);
-    return QRectF(tl.x(), tl.y(),
-                  static_cast<qreal>(tilePx()), static_cast<qreal>(tilePx()));
+    return WorldCoordinates::fitToWorld(size(), totalWidth, ac.heightTiles);
 }
 
 std::optional<QVector2D> ArenaView::entityPosition(entt::entity entity) const
 {
-    if (!m_sim->admin().isValid(entity) || !m_sim->admin().hasAll<PositionComponent>(entity))
+    if (!m_sim->getAdmin().isValid(entity) || !m_sim->getAdmin().hasAll<PositionComponent>(entity))
     {
         return std::nullopt;
     }
-    return m_sim->admin().get<PositionComponent>(entity).value;
-}
-
-QVector2D ArenaView::widgetToWorld(QPoint widgetPt) const
-{
-    const float px = tilePx();
-    if (px < 0.001f) { return QVector2D(0.0f, 0.0f); }
-    return QVector2D(static_cast<float>(widgetPt.x()) / px,
-                     static_cast<float>(widgetPt.y()) / px);
+    return m_sim->getAdmin().get<PositionComponent>(entity).value;
 }
 
 void ArenaView::mousePressEvent(QMouseEvent* event)
 {
     if (event->button() == Qt::LeftButton)
     {
-        const QVector2D worldPos = widgetToWorld(event->pos());
-        entt::entity hit = entityAtWorldPos(m_sim->admin(), worldPos);
+        const QVector2D worldPos = getCoordinates().widgetToWorld(event->pos());
+        entt::entity hit = entityAtWorldPos(m_sim->getAdmin(), worldPos);
 
         if (hit != entt::null)
         {
@@ -259,8 +234,14 @@ void ArenaView::mousePressEvent(QMouseEvent* event)
             m_selectedEntity = std::nullopt;
         }
 
+        // The arena is strictly single-select; emit a vector of size 0 or 1.
+        std::vector<entt::entity> selection;
+        if (m_selectedEntity.has_value())
+        {
+            selection.push_back(*m_selectedEntity);
+        }
         EventManager::getInstance()->sendEventImmediately(
-            std::make_shared<EntitySelectedEvent>(m_selectedEntity));
+            std::make_shared<EntitySelectionChangedEvent>(selection));
     }
 
     QOpenGLWidget::mousePressEvent(event);
@@ -280,9 +261,9 @@ void ArenaView::keyPressEvent(QKeyEvent* event)
 // Rendering
 // ---------------------------------------------------------------------------
 
-void ArenaView::drawTiles(QPainter& painter)
+void ArenaView::drawTiles(QPainter& painter, const WorldCoordinates& coordinates)
 {
-    const ArenaConfig& ac = m_sim->arenaConfig();
+    const ArenaConfig& ac = m_sim->getArenaConfig();
     const int totalWidth = ac.playerBufferWidth_tiles
                          + ac.contestZoneWidth_tiles
                          + ac.enemyBufferWidth_tiles;
@@ -293,14 +274,14 @@ void ArenaView::drawTiles(QPainter& painter)
     {
         for (int y = 0; y < totalHeight; ++y)
         {
-            painter.fillRect(tileRect(QPoint(x, y)), m_visuals->space.fill);
+            painter.fillRect(coordinates.tileRect(QPoint(x, y)), m_visuals->space.fill);
         }
     }
 }
 
-void ArenaView::drawBuildings(QPainter& painter)
+void ArenaView::drawBuildings(QPainter& painter, const WorldCoordinates& coordinates)
 {
-    for (const Building& b : m_sim->buildings().allBuildings())
+    for (const Building& b : getAllBuildings(m_sim->getFactoryState()))
     {
         const std::map<BuildingType, BuildingVisuals>::const_iterator it =
             m_visuals->buildings.find(b.type);
@@ -310,13 +291,13 @@ void ArenaView::drawBuildings(QPainter& painter)
         painter.setPen(Qt::NoPen);
         for (const QPoint& cell : b.bodyCells)
         {
-            painter.fillRect(tileRect(cell), bv.fill);
+            painter.fillRect(coordinates.tileRect(cell), bv.fill);
         }
 
-        const QPointF tl = tileToWidget(b.anchor);
+        const QPointF tl = coordinates.tileToWidget(b.anchor);
         const QRectF bboxRect(tl.x(), tl.y(),
-            b.footprint.width()  * static_cast<qreal>(tilePx()),
-            b.footprint.height() * static_cast<qreal>(tilePx()));
+            b.footprint.width()  * static_cast<qreal>(coordinates.getTilePx()),
+            b.footprint.height() * static_cast<qreal>(coordinates.getTilePx()));
 
         painter.setPen(QPen(bv.outline, 1));
         painter.setBrush(Qt::NoBrush);
@@ -330,22 +311,18 @@ void ArenaView::drawBuildings(QPainter& painter)
     }
 }
 
-void ArenaView::drawScrap(QPainter& painter)
+void ArenaView::drawDebris(QPainter& painter, const WorldCoordinates& coordinates)
 {
-    const float r = tilePx() * 0.2f;
-    for (const ScrapInfo& scrap : m_sim->scraps().allScrapInfo())
+    for (const DebrisInfo& debris : getAllDebrisInfo(m_sim->getAdmin()))
     {
-        const QPointF center = worldToWidget(scrap.position);
-        painter.setBrush(QColor(128, 110, 90));
-        painter.setPen(QPen(QColor(50, 40, 30), 1));
-        painter.drawEllipse(center,
-                            static_cast<qreal>(r), static_cast<qreal>(r));
+        drawDebrisMarker(painter, coordinates,
+                         coordinates.worldToWidget(debris.position));
     }
 }
 
-void ArenaView::drawStations(QPainter& painter)
+void ArenaView::drawStations(QPainter& painter, const WorldCoordinates& coordinates)
 {
-    m_sim->admin().forEach<StationBodyComponent, FactionComponent, HealthComponent>(
+    m_sim->getAdmin().forEach<StationBodyComponent, FactionComponent, HealthComponent>(
         [&](entt::entity e, const StationBodyComponent& sb, const FactionComponent& f, const HealthComponent& h)
         {
             const BuildingType visType = f.isEnemy
@@ -359,13 +336,13 @@ void ArenaView::drawStations(QPainter& painter)
             painter.setPen(Qt::NoPen);
             for (const QPoint& cell : sb.bodyCells)
             {
-                painter.fillRect(tileRect(cell), bv.fill);
+                painter.fillRect(coordinates.tileRect(cell), bv.fill);
             }
 
-            const QPointF tl = tileToWidget(sb.anchor);
+            const QPointF tl = coordinates.tileToWidget(sb.anchor);
             const QRectF bboxRect(tl.x(), tl.y(),
-                sb.footprint.width()  * static_cast<qreal>(tilePx()),
-                sb.footprint.height() * static_cast<qreal>(tilePx()));
+                sb.footprint.width()  * static_cast<qreal>(coordinates.getTilePx()),
+                sb.footprint.height() * static_cast<qreal>(coordinates.getTilePx()));
 
             painter.setPen(QPen(bv.outline, 1));
             painter.setBrush(Qt::NoBrush);
@@ -373,14 +350,9 @@ void ArenaView::drawStations(QPainter& painter)
 
             if (h.maxHp > 0.0f)
             {
-                const float fraction = std::max(0.0f, h.hp / h.maxHp);
-                const qreal barH  = static_cast<qreal>(tilePx()) * 0.12;
-                const qreal barY  = bboxRect.bottom() + 1.0;
-                const qreal barW  = bboxRect.width();
-                painter.fillRect(QRectF(bboxRect.left(), barY, barW, barH),
-                                 QColor(60, 60, 60));
-                painter.fillRect(QRectF(bboxRect.left(), barY, barW * static_cast<qreal>(fraction), barH),
-                                 f.isEnemy ? QColor(200, 60, 60) : QColor(60, 200, 60));
+                drawHealthBar(painter, coordinates, bboxRect.left(),
+                              bboxRect.bottom() + 1.0, bboxRect.width(),
+                              h.hp / h.maxHp, f.isEnemy);
             }
 
             if (m_selectedEntity.has_value() && *m_selectedEntity == e)
@@ -392,9 +364,11 @@ void ArenaView::drawStations(QPainter& painter)
         });
 }
 
-void ArenaView::drawShips(QPainter& painter)
+void ArenaView::drawShips(QPainter& painter, const WorldCoordinates& coordinates)
 {
-    m_sim->admin().forEach<ShipIdentityComponent, PositionComponent, FacingComponent,
+    const float forward = getShipForwardExtentPx(coordinates);
+
+    m_sim->getAdmin().forEach<ShipIdentityComponent, PositionComponent, FacingComponent,
                            FactionComponent, HealthComponent>(
         [&](entt::entity e, const ShipIdentityComponent& si,
             const PositionComponent& pos, const FacingComponent& facing,
@@ -404,40 +378,22 @@ void ArenaView::drawShips(QPainter& painter)
                 m_visuals->ships.find(si.schematicId);
             if (it == m_visuals->ships.end()) { return; }
 
-            const QPointF center = worldToWidget(pos.value);
-			const QVector2D dir(std::cos(facing.radians), std::sin(facing.radians));
-            const QVector2D perp(-dir.y(), dir.x());
-
-            const float fwd  = tilePx() * 0.45f;
-            const float side = tilePx() * 0.25f;
-
-            QPolygonF tri;
-            tri << QPointF(center.x() + static_cast<qreal>(dir.x()  * fwd),
-                           center.y() + static_cast<qreal>(dir.y()  * fwd))
-                << QPointF(center.x() + static_cast<qreal>(perp.x() * side - dir.x() * side),
-                           center.y() + static_cast<qreal>(perp.y() * side - dir.y() * side))
-                << QPointF(center.x() + static_cast<qreal>(-perp.x() * side - dir.x() * side),
-                           center.y() + static_cast<qreal>(-perp.y() * side - dir.y() * side));
-
-            painter.setPen(QPen(it->second.outline, 1));
-            painter.setBrush(it->second.fill);
-            painter.drawPolygon(tri);
+            const QPointF center = coordinates.worldToWidget(pos.value);
+            drawShipBody(painter, coordinates, center, facing.radians,
+                         it->second.fill, it->second.outline);
 
             if (h.maxHp > 0.0f)
             {
-                const float fraction = std::max(0.0f, h.hp / h.maxHp);
-                const qreal barW = static_cast<qreal>(fwd) * 2.0;
-                const qreal barH = static_cast<qreal>(tilePx()) * 0.12;
-                const qreal barX = center.x() - static_cast<qreal>(fwd);
-                const qreal barY = center.y() + static_cast<qreal>(fwd) + 1.0;
-                painter.fillRect(QRectF(barX, barY, barW, barH), QColor(60, 60, 60));
-                painter.fillRect(QRectF(barX, barY, barW * static_cast<qreal>(fraction), barH),
-                                 fac.isEnemy ? QColor(200, 60, 60) : QColor(60, 200, 60));
+                const qreal barW = static_cast<qreal>(forward) * 2.0;
+                const qreal barX = center.x() - static_cast<qreal>(forward);
+                const qreal barY = center.y() + static_cast<qreal>(forward) + 1.0;
+                drawHealthBar(painter, coordinates, barX, barY, barW,
+                              h.hp / h.maxHp, fac.isEnemy);
             }
 
             if (m_selectedEntity.has_value() && *m_selectedEntity == e)
             {
-                const qreal radius = static_cast<qreal>(tilePx()) * 0.55;
+                const qreal radius = static_cast<qreal>(coordinates.getTilePx()) * 0.55;
                 painter.setPen(QPen(QColor(255, 255, 0), 2));
                 painter.setBrush(Qt::NoBrush);
                 painter.drawEllipse(center, radius, radius);
@@ -445,10 +401,10 @@ void ArenaView::drawShips(QPainter& painter)
         });
 }
 
-void ArenaView::drawDebugSensorRanges(QPainter& painter)
+void ArenaView::drawDebugSensorRanges(QPainter& painter,
+                                      const WorldCoordinates& coordinates)
 {
-    painter.setBrush(Qt::NoBrush);
-    m_sim->admin().forEach<ShipIdentityComponent, PositionComponent, SensorRangeComponent>(
+    m_sim->getAdmin().forEach<ShipIdentityComponent, PositionComponent, SensorRangeComponent>(
         [&](entt::entity /*e*/, const ShipIdentityComponent& si,
             const PositionComponent& pos, const SensorRangeComponent& sensor)
         {
@@ -456,17 +412,14 @@ void ArenaView::drawDebugSensorRanges(QPainter& painter)
                 m_visuals->ships.find(si.schematicId);
             if (it == m_visuals->ships.end()) { return; }
 
-            const QPointF center   = worldToWidget(pos.value);
-            const qreal   radiusPx = static_cast<qreal>(sensor.value_tiles)
-                                     * static_cast<qreal>(tilePx());
-            QColor circleColor = it->second.outline;
-            circleColor.setAlpha(77);
-            painter.setPen(QPen(circleColor, 1));
-            painter.drawEllipse(center, radiusPx, radiusPx);
+            drawSensorRange(painter, coordinates,
+                            coordinates.worldToWidget(pos.value),
+                            sensor.value_tiles, it->second.outline);
         });
 }
 
-void ArenaView::drawDebugTargetLines(QPainter& painter)
+void ArenaView::drawDebugTargetLines(QPainter& painter,
+                                     const WorldCoordinates& coordinates)
 {
     // Draw a thin translucent line from a ship to a target, colored by the ship's
     // team to match the per-side HQ/station colors used elsewhere in the arena
@@ -484,10 +437,11 @@ void ArenaView::drawDebugTargetLines(QPainter& painter)
         QColor lineColor = it->second.fill;
         lineColor.setAlpha(128);
         painter.setPen(QPen(lineColor, 1));
-        painter.drawLine(worldToWidget(from), worldToWidget(to));
+        painter.drawLine(coordinates.worldToWidget(from),
+                         coordinates.worldToWidget(to));
     };
 
-    m_sim->admin().forEach<ShipIdentityComponent, PositionComponent,
+    m_sim->getAdmin().forEach<ShipIdentityComponent, PositionComponent,
                            FactionComponent, AttackBehavior>(
         [&](entt::entity /*e*/, const ShipIdentityComponent& /*si*/,
             const PositionComponent& pos, const FactionComponent& fac,
@@ -502,7 +456,7 @@ void ArenaView::drawDebugTargetLines(QPainter& painter)
             drawTargetLine(fac.isEnemy, pos.value, *targetPos);
         });
 
-    m_sim->admin().forEach<ShipIdentityComponent, PositionComponent,
+    m_sim->getAdmin().forEach<ShipIdentityComponent, PositionComponent,
                            FactionComponent, RepairBehavior>(
         [&](entt::entity /*e*/, const ShipIdentityComponent& /*si*/,
             const PositionComponent& pos, const FactionComponent& fac,
@@ -517,19 +471,19 @@ void ArenaView::drawDebugTargetLines(QPainter& painter)
             drawTargetLine(fac.isEnemy, pos.value, *targetPos);
         });
 
-    m_sim->admin().forEach<ShipIdentityComponent, PositionComponent,
+    m_sim->getAdmin().forEach<ShipIdentityComponent, PositionComponent,
                            FactionComponent, SalvageScrapBehavior>(
         [&](entt::entity /*e*/, const ShipIdentityComponent& /*si*/,
             const PositionComponent& pos, const FactionComponent& fac,
             const SalvageScrapBehavior& salvage)
         {
-            if (!salvage.scrapTarget.has_value()) { return; }
+            if (!salvage.debrisTarget.has_value()) { return; }
 
-            drawTargetLine(fac.isEnemy, pos.value, *salvage.scrapTarget);
+            drawTargetLine(fac.isEnemy, pos.value, *salvage.debrisTarget);
         });
 }
 
-void ArenaView::drawBeams(QPainter& painter)
+void ArenaView::drawBeams(QPainter& painter, const WorldCoordinates& coordinates)
 {
     for (const ActiveBeam& beam : m_activeBeams)
     {
@@ -545,7 +499,7 @@ void ArenaView::drawBeams(QPainter& painter)
             case BeamKind::Salvage: color = m_visuals->beams.salvageColor; break;
         }
         painter.setPen(QPen(color, m_visuals->beams.widthPx));
-        painter.drawLine(worldToWidget(*shooterPos),
-                         worldToWidget(*targetPos + beam.targetOffset));
+        painter.drawLine(coordinates.worldToWidget(*shooterPos),
+                         coordinates.worldToWidget(*targetPos + beam.targetOffset));
     }
 }

src/balancing/ArenaView.h

@@ -13,10 +13,11 @@
 #include "BeamFiredEvent.h"
 
 #include "entt/entity/entity.hpp"
-#include "EntitySelectedEvent.h"
+#include "EntitySelectionChangedEvent.h"
 #include "Tick.h"
 #include "TickDriver.h"
 #include "VisualsConfig.h"
+#include "WorldCoordinates.h"
 
 class ArenaSimulation;
 class QPainter;
@@ -32,7 +33,7 @@ public:
     ~ArenaView() override;
 
     void setGameSpeed(double multiplier);
-    double gameSpeed() const;
+    double getGameSpeed() const;
     void togglePause();
     void stopRendering();
 
@@ -47,22 +48,22 @@ private slots:
 private:
     void handleEvent(std::shared_ptr<const BeamFiredEvent> event) override;
 
-    void drawTiles(QPainter& painter);
-    void drawBuildings(QPainter& painter);
-    void drawStations(QPainter& painter);
-    void drawScrap(QPainter& painter);
-    void drawShips(QPainter& painter);
-    void drawDebugSensorRanges(QPainter& painter);
-    void drawDebugTargetLines(QPainter& painter);
-    void drawBeams(QPainter& painter);
+    void drawTiles(QPainter& painter, const WorldCoordinates& coordinates);
+    void drawBuildings(QPainter& painter, const WorldCoordinates& coordinates);
+    void drawStations(QPainter& painter, const WorldCoordinates& coordinates);
+    void drawDebris(QPainter& painter, const WorldCoordinates& coordinates);
+    void drawShips(QPainter& painter, const WorldCoordinates& coordinates);
+    void drawDebugSensorRanges(QPainter& painter, const WorldCoordinates& coordinates);
+    void drawDebugTargetLines(QPainter& painter, const WorldCoordinates& coordinates);
+    void drawBeams(QPainter& painter, const WorldCoordinates& coordinates);
 
-    float tilePx() const;
-    QPointF worldToWidget(QVector2D worldPos) const;
-    QPointF tileToWidget(QPoint tile) const;
-    QRectF tileRect(QPoint tile) const;
+    // The world <-> widget transform for the current viewport size. The arena
+    // shows the whole world at once and never scrolls, so this fits the arena's
+    // full extent into the widget; like GameWorldView's, it is a per-frame
+    // snapshot rather than cached state.
+    WorldCoordinates getCoordinates() const;
 
     std::optional<QVector2D> entityPosition(entt::entity entity) const;
-    QVector2D widgetToWorld(QPoint widgetPt) const;
 
     struct ActiveBeam
     {

src/balancing/ArenaWidget.cpp

@@ -33,6 +33,9 @@ void ArenaWidget::buildLayout(const std::string& arenaName)
     m_titleLabel->setFont(titleFont);
     titleRow->addWidget(m_titleLabel);
 
+    m_durationLabel = new QLabel(this);
+    titleRow->addWidget(m_durationLabel);
+
     titleRow->addStretch();
 
     m_inspectButton = new QPushButton(tr("Inspect"), this);
@@ -63,6 +66,8 @@ void ArenaWidget::buildLayout(const std::string& arenaName)
     team1Layout->addWidget(m_team1Header);
     m_team1Threat = new QLabel(this);
     team1Layout->addWidget(m_team1Threat);
+    m_team1Ehp = new QLabel(this);
+    team1Layout->addWidget(m_team1Ehp);
     m_team1Content = new QLabel(this);
     team1Layout->addWidget(m_team1Content);
     team1Layout->addStretch();
@@ -75,6 +80,8 @@ void ArenaWidget::buildLayout(const std::string& arenaName)
     team2Layout->addWidget(m_team2Header);
     m_team2Threat = new QLabel(this);
     team2Layout->addWidget(m_team2Threat);
+    m_team2Ehp = new QLabel(this);
+    team2Layout->addWidget(m_team2Ehp);
     m_team2Content = new QLabel(this);
     team2Layout->addWidget(m_team2Content);
     team2Layout->addStretch();
@@ -99,13 +106,29 @@ void ArenaWidget::resetToGrey()
     setStyleSheet("ArenaWidget { border: 2px solid #999999; padding: 8px; }");
 }
 
+ArenaWidget::State ArenaWidget::getState() const
+{
+    if (m_wasFinished)
+    {
+        return State::Ended;
+    }
+    if (m_running)
+    {
+        return State::Running;
+    }
+    return State::NotStarted;
+}
+
 void ArenaWidget::updateStatus(const ArenaStatus& status)
 {
+    m_lastStatus = status;
+
     for (int ti = 0; ti < 2; ++ti)
     {
         const ArenaStatus::TeamStatus& team = status.teams[ti];
         QLabel* header = (ti == 0) ? m_team1Header : m_team2Header;
         QLabel* threat = (ti == 0) ? m_team1Threat : m_team2Threat;
+        QLabel* ehp = (ti == 0) ? m_team1Ehp : m_team2Ehp;
         QLabel* content = (ti == 0) ? m_team1Content : m_team2Content;
 
         if (status.finished && status.winnerTeam == ti)
@@ -118,6 +141,7 @@ void ArenaWidget::updateStatus(const ArenaStatus& status)
         }
 
         threat->setText(tr("Threat: %1").arg(QString::number(team.threatLevel, 'f', 0)));
+        ehp->setText(tr("EHP: %1").arg(QString::fromStdString(team.getEhpPercentText())));
 
         QString lines;
         for (const ArenaStatus::Entry& entry : team.entries)
@@ -138,6 +162,10 @@ void ArenaWidget::updateStatus(const ArenaStatus& status)
         content->setText(lines);
     }
 
+    m_durationLabel->setText(status.finished
+        ? tr("Duration: %1 s").arg(QString::number(status.durationSeconds, 'f', 1))
+        : QString());
+
     if (status.finished && !m_wasFinished)
     {
         m_wasFinished = true;

src/balancing/ArenaWidget.h

@@ -14,21 +14,35 @@ class ArenaWidget : public QFrame
     Q_OBJECT
 
 public:
+    enum class State
+    {
+        NotStarted,
+        Running,
+        Ended
+    };
+
     ArenaWidget(int arenaIndex, const std::string& arenaName, QWidget* parent = nullptr);
 
     void updateStatus(const ArenaStatus& status);
     void startSimulation();
     void resetToGrey();
 
+    const ArenaStatus& getLastStatus() const { return m_lastStatus; }
+    State getState() const;
+
 private:
     void buildLayout(const std::string& arenaName);
 
     int m_arenaIndex;
+    ArenaStatus m_lastStatus;
     QLabel* m_titleLabel;
+    QLabel* m_durationLabel;
     QLabel* m_team1Header;
     QLabel* m_team2Header;
     QLabel* m_team1Threat;
     QLabel* m_team2Threat;
+    QLabel* m_team1Ehp;
+    QLabel* m_team2Ehp;
     QLabel* m_team1Content;
     QLabel* m_team2Content;
     QPushButton* m_inspectButton;

src/balancing/BalancingWindow.cpp

@@ -1,13 +1,70 @@
 #include "BalancingWindow.h"
 
+#include <algorithm>
+
+#include <QFile>
 #include <QHBoxLayout>
 #include <QMessageBox>
+#include <QTextStream>
 #include <QVBoxLayout>
 
 #include "ConfigLoader.h"
 #include "InspectWindow.h"
 #include "VisualsLoader.h"
 
+namespace
+{
+    // Escapes characters that would break a markdown table cell.
+    QString escapeCell(const QString& text)
+    {
+        QString escaped = text;
+        escaped.replace("|", "\\|");
+        return escaped;
+    }
+
+    QString stateText(ArenaWidget::State state)
+    {
+        switch (state)
+        {
+            case ArenaWidget::State::NotStarted:
+                return QStringLiteral("not started");
+            case ArenaWidget::State::Running:
+                return QStringLiteral("running");
+            case ArenaWidget::State::Ended:
+                return QStringLiteral("ended");
+        }
+        return QString();
+    }
+
+    // Team column header: "[WON] Name — threat N", matching the arena widget.
+    QString teamHeaderCell(const ArenaStatus& status, int teamIndex)
+    {
+        const ArenaStatus::TeamStatus& team = status.teams[teamIndex];
+        QString header = QString::fromStdString(team.name);
+        if (status.finished && status.winnerTeam == teamIndex)
+        {
+            header = QStringLiteral("[WON] ") + header;
+        }
+        header += QStringLiteral(" - threat %1").arg(QString::number(team.threatLevel, 'f', 0));
+        header += QStringLiteral(" - EHP %1").arg(QString::fromStdString(team.getEhpPercentText()));
+        return escapeCell(header);
+    }
+
+    // Single entry line: "surviving/total DisplayName [L<level>]", matching the arena widget.
+    QString entryCell(const ArenaStatus::Entry& entry)
+    {
+        QString cell = QString("%1/%2 %3")
+                           .arg(entry.surviving)
+                           .arg(entry.total)
+                           .arg(QString::fromStdString(entry.displayName));
+        if (entry.level.has_value())
+        {
+            cell += QStringLiteral(" L%1").arg(entry.level.value());
+        }
+        return escapeCell(cell);
+    }
+}
+
 BalancingWindow::BalancingWindow(const BalancingConfig& balancingConfig,
                                  GameConfig gameConfig,
                                  const std::string& configDir,
@@ -19,7 +76,6 @@ BalancingWindow::BalancingWindow(const BalancingConfig& balancingConfig,
     , m_balancingConfigPath(balancingConfigPath)
     , m_nextSeed(0)
     , m_inspectWindow(nullptr)
-    , m_inspectedArenaIndex(-1)
 {
     m_visuals = VisualsLoader::load(m_configDir + "/visuals.toml");
     setWindowTitle(tr("DotaFactory — Balancing Tool"));
@@ -31,13 +87,16 @@ BalancingWindow::BalancingWindow(const BalancingConfig& balancingConfig,
     QHBoxLayout* buttonRow = new QHBoxLayout();
     m_reloadButton = new QPushButton(tr("Reload Config"), this);
     m_startAllButton = new QPushButton(tr("Start All"), this);
+    m_logButton = new QPushButton(tr("Log"), this);
     buttonRow->addWidget(m_reloadButton);
     buttonRow->addWidget(m_startAllButton);
+    buttonRow->addWidget(m_logButton);
     buttonRow->addStretch();
     mainLayout->addLayout(buttonRow);
 
     connect(m_reloadButton, &QPushButton::clicked, this, &BalancingWindow::reloadConfig);
     connect(m_startAllButton, &QPushButton::clicked, this, &BalancingWindow::startAll);
+    connect(m_logButton, &QPushButton::clicked, this, &BalancingWindow::writeLog);
 
     m_scrollArea = new QScrollArea(this);
     m_scrollArea->setWidgetResizable(true);
@@ -87,7 +146,7 @@ void BalancingWindow::populateArenas(const BalancingConfig& balancingConfig)
         entry.widget = new ArenaWidget(index, arenaConfig.name, scrollContent);
         contentLayout->addWidget(entry.widget);
 
-        entry.widget->updateStatus(entry.simulation->status());
+        entry.widget->updateStatus(entry.simulation->getStatus());
 
         m_arenas.push_back(std::move(entry));
     }
@@ -119,15 +178,15 @@ void BalancingWindow::pollStatuses()
     {
         if (entry.worker.joinable())
         {
-            const ArenaStatus status = entry.simulation->status();
+            const ArenaStatus status = entry.simulation->getStatus();
             entry.widget->updateStatus(status);
         }
     }
 
-    if (m_inspectedSim && m_inspectedArenaIndex >= 0)
+    if (m_inspectedSim && m_inspectedArenaIndex.has_value())
     {
-        const ArenaStatus status = m_inspectedSim->status();
-        m_arenas[static_cast<std::size_t>(m_inspectedArenaIndex)].widget->updateStatus(status);
+        const ArenaStatus status = m_inspectedSim->getStatus();
+        m_arenas[static_cast<std::size_t>(*m_inspectedArenaIndex)].widget->updateStatus(status);
     }
 
     updateButtons();
@@ -182,7 +241,7 @@ void BalancingWindow::startArena(int index)
     entry.simulation = std::make_unique<ArenaSimulation>(
         m_gameConfig, entry.config, m_nextSeed++);
     entry.widget->startSimulation();
-    entry.widget->updateStatus(entry.simulation->status());
+    entry.widget->updateStatus(entry.simulation->getStatus());
     ArenaSimulation* sim = entry.simulation.get();
     entry.worker = std::thread([sim]() { sim->run(); });
     updateButtons();
@@ -195,13 +254,13 @@ void BalancingWindow::inspectArena(int index)
         delete m_inspectWindow;
         m_inspectWindow = nullptr;
 
-        if (m_inspectedSim && m_inspectedArenaIndex >= 0
+        if (m_inspectedSim && m_inspectedArenaIndex.has_value()
             && !m_inspectedSim->isFinished())
         {
-            m_arenas[static_cast<std::size_t>(m_inspectedArenaIndex)].widget->resetToGrey();
+            m_arenas[static_cast<std::size_t>(*m_inspectedArenaIndex)].widget->resetToGrey();
         }
         m_inspectedSim.reset();
-        m_inspectedArenaIndex = -1;
+        m_inspectedArenaIndex = std::nullopt;
     }
 
     ArenaEntry& entry = m_arenas[static_cast<std::size_t>(index)];
@@ -218,7 +277,7 @@ void BalancingWindow::inspectArena(int index)
 
     entry.widget->resetToGrey();
     entry.widget->startSimulation();
-    entry.widget->updateStatus(m_inspectedSim->status());
+    entry.widget->updateStatus(m_inspectedSim->getStatus());
 
     m_inspectWindow = new InspectWindow(
         m_inspectedSim.get(), &m_gameConfig, &m_visuals, entry.config.name, nullptr);
@@ -237,16 +296,16 @@ void BalancingWindow::closeInspectWindow()
     m_inspectWindow->deleteLater();
     m_inspectWindow = nullptr;
 
-    if (m_inspectedArenaIndex >= 0 && m_inspectedSim)
+    if (m_inspectedArenaIndex.has_value() && m_inspectedSim)
     {
         if (!m_inspectedSim->isFinished())
         {
-            m_arenas[static_cast<std::size_t>(m_inspectedArenaIndex)].widget->resetToGrey();
+            m_arenas[static_cast<std::size_t>(*m_inspectedArenaIndex)].widget->resetToGrey();
         }
     }
 
     m_inspectedSim.reset();
-    m_inspectedArenaIndex = -1;
+    m_inspectedArenaIndex = std::nullopt;
     setMainControlsEnabled(true);
     updateButtons();
 }
@@ -255,6 +314,7 @@ void BalancingWindow::setMainControlsEnabled(bool enabled)
 {
     m_reloadButton->setEnabled(enabled);
     m_startAllButton->setEnabled(enabled);
+    m_logButton->setEnabled(enabled);
     for (ArenaEntry& entry : m_arenas)
     {
         for (QPushButton* btn : entry.widget->findChildren<QPushButton*>())
@@ -275,7 +335,7 @@ void BalancingWindow::updateButtons()
     bool allRunning = true;
     for (ArenaEntry& entry : m_arenas)
     {
-        if (entry.worker.joinable() && !entry.simulation->status().finished)
+        if (entry.worker.joinable() && !entry.simulation->getStatus().finished)
         {
             anyRunning = true;
         }
@@ -291,4 +351,58 @@ void BalancingWindow::updateButtons()
 
     m_reloadButton->setEnabled(!anyRunning);
     m_startAllButton->setEnabled(!allRunning);
+    m_logButton->setEnabled(true);
+}
+
+void BalancingWindow::writeLog()
+{
+    QFile file(QStringLiteral("balancing_log.md"));
+    if (!file.open(QIODevice::WriteOnly | QIODevice::Truncate | QIODevice::Text))
+    {
+        QMessageBox::warning(this, tr("Log Failed"),
+            tr("Could not open balancing_log.md for writing."));
+        return;
+    }
+
+    QTextStream out(&file);
+    out.setCodec("UTF-8");
+
+    out << "# Balancing Log\n";
+
+    for (const ArenaEntry& entry : m_arenas)
+    {
+        const ArenaStatus& status = entry.widget->getLastStatus();
+        const ArenaWidget::State state = entry.widget->getState();
+
+        QString stateSuffix = stateText(state);
+        if (state == ArenaWidget::State::Ended)
+        {
+            stateSuffix += QStringLiteral(", %1 s")
+                .arg(QString::number(status.durationSeconds, 'f', 1));
+        }
+
+        out << "\n## Arena: " << QString::fromStdString(entry.config.name)
+            << "  (" << stateSuffix << ")\n\n";
+
+        out << "| " << teamHeaderCell(status, 0) << " | "
+            << teamHeaderCell(status, 1) << " |\n";
+        out << "|---|---|\n";
+
+        const std::size_t rowCount = std::max(status.teams[0].entries.size(),
+                                              status.teams[1].entries.size());
+        for (std::size_t row = 0; row < rowCount; ++row)
+        {
+            QString leftCell;
+            if (row < status.teams[0].entries.size())
+            {
+                leftCell = entryCell(status.teams[0].entries[row]);
+            }
+            QString rightCell;
+            if (row < status.teams[1].entries.size())
+            {
+                rightCell = entryCell(status.teams[1].entries[row]);
+            }
+            out << "| " << leftCell << " | " << rightCell << " |\n";
+        }
+    }
 }

src/balancing/BalancingWindow.h

@@ -1,6 +1,7 @@
 #pragma once
 
 #include <memory>
+#include <optional>
 #include <string>
 #include <thread>
 #include <vector>
@@ -46,6 +47,7 @@ private slots:
     void pollStatuses();
     void reloadConfig();
     void startAll();
+    void writeLog();
 
 private:
     void startArena(int index);
@@ -72,10 +74,11 @@ private:
     unsigned int m_nextSeed;
     QPushButton* m_reloadButton;
     QPushButton* m_startAllButton;
+    QPushButton* m_logButton;
     QScrollArea* m_scrollArea;
     QTimer* m_pollTimer;
 
     InspectWindow* m_inspectWindow;
-    int m_inspectedArenaIndex;
+    std::optional<int> m_inspectedArenaIndex;  // nullopt = no arena inspected
     std::unique_ptr<ArenaSimulation> m_inspectedSim;
 };