refinement

docs/progression_design.md

@@ -46,11 +46,16 @@ adapts later (see Refactorability).
 
 ### Structure
 
-- **One new base input chain per phase.** Factory complexity ramps
+- **Each phase transition adds exactly one new base input chain.** A base
-  alongside ship size; no phase adds more than one new bottom-level chain.
+  input is a bottom-level resource entering the factory from outside — a
+  mined ore or the scrap-only input. The early game starts with two ores
+  as the baseline; the transition to mid adds one (the third ore), 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
+  modules and hulls of a tier draw from a shared pool of that tier's and
-  intermediates rather than each having bespoke inputs.
+  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
@@ -77,6 +82,12 @@ adapts later (see Refactorability).
   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 new (see Action items).
 - **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 —
@@ -88,8 +99,15 @@ adapts later (see Refactorability).
 ### Refactorability
 
 - **Rule (the property):** unlocking the next tier or size of a thing must
-  be an *extension* of the existing production line — adding assemblers and
+  be a *local edit* of the existing production line — adding assemblers
-  belts to what is already built — never a teardown and rebuild.
+  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
@@ -149,6 +167,13 @@ supporting different fleet doctrines feel structurally different to build.
   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 that must already be unlocked before it enters
+  the drop pool — e.g. the medium laser requires the small laser; 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
@@ -184,8 +209,16 @@ supporting different fleet doctrines feel structurally different to build.
   `1 / scrap_per_threat`. The min-`scrap_drop` schematic derivation
   (REQ-THREAT-SCRAP) and its potential circularity disappear.
 - **Rule:** the late-game input's income rate meaningfully gates capital
-  production. The tuning target is expressed as "capital ships per boss
+  production — unlocking a capital hull must not mean spamming it; the
-  cycle for a player who fights at parity", not as an absolute rate.
+  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
 
@@ -272,3 +305,14 @@ configs:
    current `world.toml` values still produce the intended difficulty
    curve (the config reportedly already runs with a flat ship level, so
    this is likely a review, not a retune).
+7. **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.
+8. **Schematic prerequisites.** Add an optional prerequisite list to
+   ship, module, and assembler recipe schematic entries (e.g.
+   `unlock_requires = ["laser_cannon_s"]`): a schematic enters the drop
+   pool only when every listed schematic is already unlocked, in addition
+   to the station-level check. Update REQ-DEF-SCHEMATIC-DROP and
+   REQ-LOCK-EXPLICIT. This is also the mechanism the future Mk2 design
+   builds on (`*_mk2` requires the base schematic).