Open Items Register¶
This is the single register for open work, open design questions, unresolved documentation debt, and known code/design divergence pointers.
Rules:
- Every gap found by any pass gets logged here immediately, in the same pass that found it.
Kindsays what has to happen before a row can move.defect— something is wrong today and the fix is already knownundecided— a decision has not been made; nobody can act until it istask— agreed work, not a correction- Log
undecidedwhile designing, not while comparing documents. A reconciliation pass that records every unmade decision as a finding manufactures a backlog that can never empty, and buries the real defects among ordinary unfinished design. During a document comparison, logdefectandtask; logundecidedonly when the gap blocks something else, or when a specific audit was asked for. - Nothing may exist only in a design document.
- Design documents describe the design. Open work lives here.
- The register is the only place open work lives; if it isn't here, it doesn't exist.
- IDs are stable. Never reuse or renumber an ID.
- ⚠️ When editing rows by script, anchor matches to the start of a line. An ID also appears inside the
Blocked bycolumn, so searching for| OI-041 |finds another row's blocker field before it finds the row itself. That has silently spliced two rows together twice. - Prefix note.
CI-001toCI-053inclosed-items.mdare the batch closed during the 2026-08-26 consolidation, before this register existed. They keep that prefix permanently. Every item closed since then keeps itsOI-id when it moves, starting withOI-024. The two blocks are not renumbered into one scheme:CI-andOI-numbers overlap (CI-001andOI-001are unrelated items), so unifying them would mean assigning 53 new IDs, which is renumbering done to tidy up how the never-renumber rule was applied. - When an item closes, move the row to
docs/closed-items.mdand add how it resolved. Never delete a row.
| ID | Area | Kind | Item | Intent steer | Detail lives in | Blocked by | Priority | Raised |
|---|---|---|---|---|---|---|---|---|
| OI-001 | code | task | Implement fluid as a production input path for buildings. | - | AGENTS.md -> Known Code/Design Divergences; 04_Factory -> Resources -> Fluids |
- | DO FIRST | 2026-08-26 |
| OI-004 | ports | task | Unblocked 2026-08-30; this is now the refactor itself. Plan and implement the coordinated port refactor that replaces IoConnector and PipeConnector. Sequencing constraint: the Building Detail Panel does not exist and is on the critical path. All ports default to DISABLED (OI-058) and port configuration lives in that panel, so merging without it produces a factory that cannot move anything; the panel must cover every port in both directions and also carry recipe selection (OI-320), since ports cannot be configured before the building knows what it makes. Port reconfiguration is an instant UI action, not a Genesis task (OI-259), so GenesisTask.Type shrinks by two and grows by none. Regression baseline exists as of OI-258: tests/unit/test_item_transport.gd covers the chain end to end and pins constraints C3, C4 and C5, and is designed to be re-run after the refactor. Split the passes: the item half is well-bounded (~400 changed lines across 11 files); the fluid half is now scopeable since OI-003 decided direct transfer (two touching fluid ports are a pair-equalisation pair with the pipe removed). C5 connector chaining is the one deliberate loss - test_connector_chaining_passes_items_between_adjacent_connectors should be deleted as part of the work, not quietly broken. |
item half first; delete the C5 test knowingly | 23_Port System Design -> Code Impact Summary; tests/unit/test_item_transport.gd; AGENTS.md -> Known Code/Design Divergences |
- | DO FIRST | 2026-08-25 |
| OI-008 | art | task | Keep Mk accent tab pitch at or above 0.4 m. | >= 0.4 m | 07_Art Direction Style Bible -> Form Language |
- | HIGH | 2026-08-26 |
| OI-009 | art | task | Use a reduced 0.15 m port band for 1x1 buildings. | 0.15 m | 07_Art Direction Style Bible -> Form Language |
- | HIGH | 2026-08-26 |
| OI-010 | code | task | Move Chemical Gas onto the fluid path. Previously scoped as "retype the .tres to FLUID", which would not have fixed anything: nothing enforces the belt/pipe split via tier. Belts never check tier or any fluid flag; the separation is structural, with fluids moving through fluid_inventory / pop_fluid_output() and items through inventory / pop_output_item(). Chemical Gas rides belts because it has an item-shaped definition, not because its tier is 0. The real work is moving it to the fluid path, which is why it was always blocked behind OI-001. Under the new model it becomes chemical / GAS, and rides pipes because it is a gas rather than because a field says so. |
gases travel as FLUID |
06_Design Session Decision Log -> Resource Data Model; AGENTS.md -> Known Code/Design Divergences |
OI-001 | HIGH | 2026-08-26 |
| OI-017 | code | undecided | Decide the BuildingCategory enum value for environmental buildings. |
- | 04_Factory -> Waste & Environmental Buildings |
- | HIGH | 2026-08-26 |
| OI-018 | docs | task | Reconcile 04_Factory train signalling and locomotive fuel claims with Canonical Design Facts. |
- | - | - | HIGH | 2026-08-26 |
| OI-019 | docs | task | Remove category colour-coding from design documents that still prescribe it. | - | - | - | HIGH | 2026-08-26 |
| OI-023 | docs | defect | Replace duplicate fluid tables in 04_Factory with a generated or extracted reference. |
- | - | - | NORMAL | 2026-08-26 |
| OI-028 | art | task | Remove cel-shader requirements from the asset quality checklist. | - | 05_Asset List & Delivery Specification -> Quality checklist |
- | HIGH | 2026-08-25 |
| OI-029 | art | task | Update the asset tech spec away from flat-colour-only StandardMaterial3D and no texture maps. |
- | 05_Asset List & Delivery Specification -> Tech spec |
- | HIGH | 2026-08-25 |
| OI-030 | art | defect | Remove obsolete io_connector and pipe_connector assets. |
- | 05_Asset List & Delivery Specification; 23_Port System Design -> Code Impact Summary |
OI-004 | HIGH | 2026-08-25 |
| OI-031 | art | task | Add the shared building_base kit asset. |
- | 07_Art Direction Style Bible -> Modular Kit |
OI-004 | HIGH | 2026-08-25 |
| OI-032 | logistics | task | Remove Splitter, Merger, and Filter Splitter assets and add the Router asset. | - | 20_Belt Logistics - The Router -> Consequences Elsewhere |
OI-004 | HIGH | 2026-08-25 |
| OI-033 | storage | task | Rename buffer_chest asset and concept language to Silo. |
- | - | - | HIGH | 2026-08-25 |
| OI-035 | restoration | undecided | Resolve the RECLAIM naming collision with Outpost Mode. | - | 28_Restoration - Third Endgame Path -> Naming - Collision With Outpost |
- | NORMAL | 2026-08-25 |
| OI-037 | docs | task | Watch AGENTS.md length and split Known Code/Design Divergences if it keeps growing. |
accuracy beats brevity | - | - | NORMAL | 2026-08-26 |
| OI-038 | tooling | task | Consider porting repo checks from PowerShell to Node when either script needs real work. | - | - | - | DEFERRED | 2026-08-26 |
| OI-039 | docs | task | DECIDED 2026-08-30: delete 04_AI Tool Selection Guide.md. Its premise - "Design in Claude.ai. Code in GitHub Copilot" plus Copilot premium-request budgeting - describes a workflow the project has moved past; Claude Code now does the coding and rewrote the AI instruction baseline on 2026-08-26. Nothing is lost: the AI Instruction Governance section is already in AGENTS.md, and the Art Asset Stack duplicates 08_AI Toolchain almost word for word. Removed from the MkDocs nav 2026-08-30; the file still needs git rm. Closes OI-324 with it, since the four unresolvable links live in this file. |
delete, do not rewrite | 04_Project Management/04_AI Tool Selection Guide.md |
- | HIGH | 2026-08-26 |
| OI-040 | art | task | Rescope or remove M5.2 Art Pass because it assumes a cel-shader. | - | - | - | NORMAL | 2026-08-25 |
| OI-042 | storage | task | Rename building_storage_chest and building_buffer_chest in 04_Factory to Silo terms. |
- | - | - | HIGH | 2026-08-25 |
| OI-043 | docs | task | Rename tutorial references to chest, including Genesis dialogue in steps 10 and 11. | - | - | - | HIGH | 2026-08-25 |
| OI-044 | docs | task | Rename chest_vault achievement skin. |
- | 11_Achievements Design Document -> Cosmetic Reward Catalogue |
- | NORMAL | 2026-08-25 |
| OI-045 | docs | task | Rewrite 03_Art & Audio/03_Prompt Library.md entirely. This is far larger than the Buffer Chest rename it was originally logged as. The whole document, roughly 40 prompts, is built on the superseded art direction: every building prompt opens with a [MASTER STYLE PROMPT] specifying cel-shading, thick dark outlines and flat colour faces, and every one names a per-category accent colour (amber extraction, orange-red processing, acid green chemical, electric blue assembly, yellow power, purple storage, teal research, olive defence, gold modules) - the category colour-coding dropped in Canonical section 6. It also contains prompts for removed buildings: IoConnector and Pipe Connector, both with the "blue glowing input face, green glowing output face" language the port system replaced, plus Buffer Chest. ✅ Good news: every prompt is marked "Not yet generated", so no assets need redoing - only the prompts. Blocked on OI-249, since section 4 of the Style Bible (Concept Prompt Template) is the authority this document must be rebuilt against. |
rewrite, not rename; no assets affected | 03_Art & Audio/03_Prompt Library.md; 07_Art Direction Style Bible -> Concept Prompt Template |
OI-249 | HIGH | 2026-08-25 |
| OI-046 | ui | task | Rename build toolbar Chest button label and Ch letter code. |
- | - | - | HIGH | 2026-08-25 |
| OI-047 | ui | task | Rename genesis_queue_ui_v5.html SUBJ_MAP chest references. |
- | - | - | NORMAL | 2026-08-25 |
| OI-048 | code | task | Rename ChestMode to StorageRole and values to UNASSIGNED, DEPOSIT, CONSTRUCTION. |
- | AGENTS.md -> Known Code/Design Divergences; 04_Factory -> Storage Roles |
OI-004 | HIGH | 2026-08-25 |
| OI-049 | code | task | Rename get_chests_sorted_by_distance() and related code identifiers. |
- | - | OI-048 | HIGH | 2026-08-25 |
| OI-050 | art | task | Fix the Mining Drill .glb size. |
- | - | - | HIGH | 2026-08-25 |
| OI-051 | art | task | Rebuild the Mining Drill concept to Image 3 standard. | - | 07_Art Direction Style Bible -> Surface finish |
- | NORMAL | 2026-08-25 |
| OI-052 | art | task | Add orange exhaust tips to the logo. | - | - | - | NORMAL | 2026-08-25 |
| OI-053 | art | task | Consolidate the two Blender docs and incorporate the modular kit and Blender MCP workflow. | - | - | - | NORMAL | 2026-08-25 |
| OI-054 | tooling | task | Install the official Blender MCP server and test on a saved file. | - | - | - | NORMAL | 2026-08-25 |
| OI-055 | ports | undecided | Decide the new role for R and E keys after connectors are removed. |
- | 23_Port System Design -> Input Keys |
OI-004 | NORMAL | 2026-08-25 |
| OI-056 | ports | undecided | Decide central aperture dimensions. | - | 23_Port System Design -> Central aperture |
OI-007 | NORMAL | 2026-08-25 |
| OI-057 | ports | undecided | Confirm that fluid and item ports can coexist on one base. | assumed yes via medium field |
23_Port System Design -> Open Questions |
OI-001 | HIGH | 2026-08-25 |
| OI-375 | logistics | task | The drone-making building still needs a name, footprint, recipe and category. Carried over from OI-297, whose other half (a dedicated fluid-carrier drone) was dropped 2026-09-08 in favour of ordinary drones carrying barrels and rail carrying fluid in tank wagons. This half is unaffected by that decision and still open. | data pass | 21_Drone Logistics Design; data/buildings.json |
OI-363 | NORMAL | 2026-09-08 |
| OI-376 | logistics | undecided | How the insulated tank wagon loses heat. 41_Fluid Packaging & Carriage Design section 4.2 and 22_Trains & Rail section 4.2a fix the design constraint - short haul only, so a long run arrives with a solidified load - and deliberately leave the expression open. Candidates: a distance budget per trip; a timer from the moment of loading; or a modelled temperature decaying toward ambient and solidifying below fld_liquid_metal's min_temp of 450C. Modelled temperature is the most honest and the most expensive, and the only one under which an insulated wagon's rating means anything. ⚠️ Whatever is chosen must not strand a train: Canonical section 19 is disabled-never-deleted, so a solidified load should block the unload and require clearing, never destroy the wagon or its cargo silently. Supersedes the original row, which asked the same question of the Insulated Barrel; that container is deleted in v0.2 and the question moved to the wagon that replaced it. |
short haul is decided, the expression is not; never strand a train | 41_Fluid Packaging & Carriage Design section 4.2; 22_Trains & Rail section 4.2a |
- | NORMAL | 2026-09-08 |
| OI-378 | trains | undecided | Whether the tank wagon needs its own platform type or reuses the fluid platform. 22_Trains & Rail section 4.3 already gives the Diesel locomotive a fuel platform with a fuel pipe in, so station plumbing exists. Open whether loading a tank wagon reuses that platform or needs a distinct one, which matters because section 4.1 makes platforms extensions rather than buildings and section 4.2's per-wagon commodity routing is itself unresolved (OI-260). A tank wagon in a mixed train makes that routing question harder, not easier. |
reuse if it can, and say so | 41_Fluid Packaging & Carriage Design section 4; 22_Trains & Rail sections 4.1 to 4.3 |
OI-260 | NORMAL | 2026-09-08 |
| OI-061 | art | undecided | Verify protruding nozzles and Mk tabs do not read as clutter at Base Mk3. | - | 07_Art Direction Style Bible -> Port Geometry - Direction |
- | NORMAL | 2026-08-25 |
| OI-064 | logistics | undecided | Decide Mk1 Router split behaviour: strictly even or round-robin. | round-robin simpler and steady-state equivalent | 20_Belt Logistics - The Router -> Open Questions |
OI-004 | NORMAL | 2026-08-25 |
| OI-066 | logistics | undecided | Decide whether the Router needs a base ring and status despite being 1x1. | - | 20_Belt Logistics - The Router -> Open Questions |
OI-009 | NORMAL | 2026-08-25 |
| OI-067 | logistics | undecided | Decide whether there should be a belt balancer building or manual balancer design. | - | - | OI-063 | NORMAL | 2026-02-22 |
| OI-070 | modules | undecided | Decide whether to include a Speed module or let Productivity cover it. | - | 24_Module System Design -> Research node names |
- | NORMAL | 2026-08-25 |
| OI-071 | modules | undecided | Decide whether modules have Mk tiers. | no, flat for Phase 1 | 24_Module System Design -> Research node names |
- | NORMAL | 2026-08-25 |
| OI-072 | modules | task | Define upgrade kit recipes and Module Crafter inputs. | - | 24_Module System Design -> Upgrade Kits |
- | HIGH | 2026-08-25 |
| OI-073 | modules | undecided | Confirm upgrade defaults: downtime, kit recovery on downgrade, and kit cost. | brief downtime; recoverable or partial return; expensive | 24_Module System Design -> Other defaults |
- | NORMAL | 2026-08-25 |
| OI-074 | power | undecided | Decide roof-mounted pole coverage radius relative to ground poles. | increased coverage would make research feel worth it | 24_Module System Design -> Power Poles |
- | NORMAL | 2026-08-25 |
| OI-075 | modules | task | Define module recipes and Module Crafter inputs. | - | 24_Module System Design -> Open Questions |
OI-072 | NORMAL | 2026-08-25 |
| OI-076 | modules | undecided | Decide whether modules can be removed and recovered or are consumed on install. | affects experimentation | 24_Module System Design -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-077 | modules | undecided | Confirm which buildings actually get Mk levels. | most buildings | 24_Module System Design -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-078 | modules | task | Defer Network / IoT modules to the automation idea. | - | 24_Module System Design -> Open Questions; 00_Ideas/03_Idea - Network, IoT & Factory Automation.md |
- | DEFERRED | 2026-08-25 |
| OI-080 | power | undecided | Decide Machine Mk superlinear draw exponent. | Mk2 = 2x output, 2.4x draw | 25_Power System Design -> Machine Mk |
- | NORMAL | 2026-08-25 |
| OI-083 | power | undecided | Decide which of Biomass, Coal, Wind, and Nuclear ship in Early Access. Now decidable on evidence: §5.1 gives all nine sources real output and fuel numbers, so each one's cost can be weighed rather than guessed. The expensive one is unambiguous - Nuclear, which needs a uranium resource that does not exist in data/resources/ (the coolant does - fld_coolant.tres ships), a waste chain, and the fluid-input path still blocked on OI-001. Biomass and Coal are cheap and both already have their resources. Wind needs no new work at all: the building exists and its numbers were already specified in 06_Vertical Layers. |
numbers exist now; this is a scope call | 25_Power System Design -> §5.1, §5.4 |
- | HIGH | 2026-08-25 |
| OI-084 | power | undecided | Confirm which planet resource tables include wood, coal, and uranium per planet type. | - | 25_Power System Design -> Why planet type matters |
- | HIGH | 2026-08-25 |
| OI-085 | power | undecided | Design interplanetary power approach. | risks trivialising Trade Station layer | 25_Power System Design -> Interplanetary Power - NOT DESIGNED |
- | DEFERRED | 2026-08-25 |
| OI-088 | power | undecided | Decide transmission clearance height and Sky Level interaction. | - | 25_Power System Design -> Transmission Line Clearance |
- | HIGH | 2026-08-25 |
| OI-090 | pollution | undecided | Decide whether recycling returns usable material or only neutralises waste. | returning material is satisfying but risks perpetual-motion loops | 26_Pollution, Waste & Organic Systems Design -> Nuclear waste is the exception |
- | HIGH | 2026-08-25 |
| OI-092 | pollution | undecided | Decide which planet types support farming. | Rogue has no light — but artificial lighting ([27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) section 5.1) may make Rogue viable, which was previously assumed impossible. Costs power, and is only as clean as the grid |
26_Pollution, Waste & Organic Systems Design -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-093 | pollution | undecided | Decide whether pollution persists across sessions in a persistent world. | - | 26_Pollution, Waste & Organic Systems Design -> Open Questions; 17_HUD Panel Flap -> Tab 7 Pollution |
- | NORMAL | 2026-08-25 |
| OI-094 | pollution | undecided | Decide whether the Air Scrubber produces a solid waste byproduct. | captured particulates | 26_Pollution, Waste & Organic Systems Design -> Air Scrubber |
- | NORMAL | 2026-08-25 |
| OI-095 | pollution | undecided | Decide underground decay multiplier versus surface. | - | 26_Pollution, Waste & Organic Systems Design -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-096 | pollution | undecided | Decide leach rate, per-level attenuation, and delay. | backend tuning | 26_Pollution, Waste & Organic Systems Design -> Ground contamination leaches downward |
- | NORMAL | 2026-08-25 |
| OI-097 | pollution | undecided | Decide whether contamination decays naturally or only via Soil Remediation. | - | 26_Pollution, Waste & Organic Systems Design -> Restoration - Soil Remediation |
- | NORMAL | 2026-08-25 |
| OI-098 | pollution | undecided | Decide remediation rate relative to contamination rate. | far slower than contamination | 04_Factory -> Waste & Environmental Buildings; Pollution -> Restoration - Soil Remediation |
- | HIGH | 2026-08-26 |
| OI-099 | pollution | undecided | Decide whether base Mk and Machine Mk levels affect emission rates. | - | 26_Pollution, Waste & Organic Systems Design -> Open Questions |
OI-080 | NORMAL | 2026-08-25 |
| OI-100 | pollution | undecided | Decide footprints for all five environmental buildings and five new generators. | - | 04_Factory -> Waste & Environmental Buildings; 04_Factory -> Power Buildings |
- | HIGH | 2026-08-26 |
| OI-102 | pollution | undecided | Decide Recycler and Water Treatment power draw. | significant | 04_Factory -> Waste & Environmental Buildings |
OI-001 for Water Treatment | HIGH | 2026-08-26 |
| OI-103 | pollution | undecided | Decide Soil Remediation power draw. | power-hungry | 04_Factory -> Waste & Environmental Buildings |
- | HIGH | 2026-08-26 |
| OI-105 | pollution | undecided | Decide recipe quantities and rates for the five environmental buildings and five new generators. | - | 04_Factory -> Waste & Environmental Buildings; 04_Factory -> Power Buildings |
OI-001 where fluid inputs are involved | HIGH | 2026-08-26 |
| OI-106 | logistics | undecided | Decide Incinerator heat recovery fraction. | always a fraction of embodied energy, never more | 04_Factory -> Waste & Environmental Buildings; 20_Belt Logistics - The Router -> The deliberate way out |
- | NORMAL | 2026-08-26 |
| OI-107 | pollution | undecided | Decide Air Scrubber neutralisation rate. | - | 04_Factory -> Waste & Environmental Buildings |
- | NORMAL | 2026-08-26 |
| OI-108 | pollution | undecided | Decide Air Scrubber and Soil Remediation zone/radius of effect. | - | 04_Factory -> Waste & Environmental Buildings |
- | NORMAL | 2026-08-26 |
| OI-109 | pollution | undecided | Decide Recycler output. | - | 04_Factory -> Waste & Environmental Buildings |
OI-090 | HIGH | 2026-08-26 |
| OI-110 | trains | undecided | Decide electrified rail power draw: per-tile or per-active-train. | - | 22_Trains & Rail -> Electric train is only as clean as your grid |
- | NORMAL | 2026-08-25 |
| OI-111 | trains | undecided | Decide whether schedules are per-train or per-route with trains assigned. | per-route is simpler at scale | 22_Trains & Rail -> Schedules |
- | NORMAL | 2026-08-25 |
| OI-112 | trains | undecided | Decide whether trains cross vertical levels or are surface-only. | underground rail adds a lot | 22_Trains & Rail -> Open Questions |
- | DEFERRED | 2026-08-25 |
| OI-113 | trains | undecided | Decide whether rail can cross belts and pipes or blocks them. | - | 22_Trains & Rail -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-114 | trains | undecided | Decide wagon types or one generic wagon with port config. | port config | 22_Trains & Rail -> Open Questions |
OI-004 | NORMAL | 2026-08-25 |
| OI-115 | trains | undecided | Decide whether Nuclear locomotive waste is handled at station or carried to disposal. | carrying it makes train part of waste chain | 22_Trains & Rail -> Open Questions |
OI-001 | NORMAL | 2026-08-25 |
| OI-116 | trains | undecided | Decide whether platforms can be shared between two stations on parallel tracks. | - | 22_Trains & Rail -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-117 | trains | undecided | Decide what a train does when it has nowhere to go. | hold at station or park in depot | 22_Trains & Rail -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-118 | trains | undecided | Decide whether Steam locomotive coal demand should share the Coal Generator bottleneck. | may be a good tension | 22_Trains & Rail -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-119 | restoration | undecided | Decide whether Planet Health feeds supply chain contribution or is a parallel currency. | - | 28_Restoration - Third Endgame Path -> Measuring It |
- | NORMAL | 2026-08-25 |
| OI-120 | restoration | undecided | Decide restoration contract structure, pricing, and abuse prevention. | prevent deliberately wrecking planets to farm contracts | 28_Restoration - Third Endgame Path -> The Economy |
- | NORMAL | 2026-08-25 |
| OI-121 | restoration | undecided | Decide whether procedurally damaged planets are available from the start or only after player wrecks exist. | - | 28_Restoration - Third Endgame Path -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-122 | restoration | undecided | Decide whether restoration has a completion state or endless gradient. | - | 28_Restoration - Third Endgame Path -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-123 | restoration | undecided | Decide whether restored planets can be re-wrecked. | owner or raider | 28_Restoration - Third Endgame Path -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-124 | restoration | undecided | Decide consent, anonymisation, and attribution for harvesting player wrecks as scenarios. | opt-in is safer, and could carry a reward | 28_Restoration - Third Endgame Path -> Where the scenarios come from |
- | HIGH | 2026-08-25 |
| OI-125 | restoration | undecided | Decide whether Restoration Mode reuses Outpost Mode's three-mode structure. | Progression / Seasonal / Sandbox | 28_Restoration - Third Endgame Path -> Restoration Mode |
- | NORMAL | 2026-08-25 |
| OI-126 | restoration | undecided | Decide which leaderboard scoring metric leads Restoration Mode. | time, material spent, or elegance | 28_Restoration - Third Endgame Path -> Restoration Mode |
- | NORMAL | 2026-08-25 |
| OI-127 | ui | undecided | Decide whether the Pollution tab appears from the start or unlocks on first pollution. | empty tab in hour one teaches nothing | 17_HUD Panel Flap -> Tab 7 Pollution |
- | NORMAL | 2026-08-25 |
| OI-128 | ui | undecided | Decide whether the Pollution tab needs a planet-wide history graph or only current state. | - | 17_HUD Panel Flap -> Tab 7 Pollution |
OI-093 | NORMAL | 2026-03-31 |
| OI-129 | docs | undecided | Decide whether the Genesis Image 3 design becomes canonical and changes tutorial voice/personality docs. | - | 06_Design Session Decision Log -> Open Questions; 01_World Bible -> Open Questions |
- | NORMAL | 2026-08-25 |
| OI-130 | art | undecided | Decide whether AI-to-3D is acceptable for static props. | rocks, debris, scatter | 06_Design Session Decision Log -> Open Questions |
- | DEFERRED | 2026-08-25 |
| OI-132 | power | undecided | Design per-building waste heat recovery from smelters, refineries, and similar. | deferred session topic | 26_Pollution, Waste & Organic Systems Design -> Incinerator |
- | DEFERRED | 2026-08-25 |
| OI-133 | code | undecided | Design combat and territory systems. | - | - | - | DEFERRED | 2026-08-25 |
| OI-134 | logistics | undecided | Design trade and the Trade Station. | - | 14_Win Conditions & Faction Allegiance -> Trade Network |
- | DEFERRED | 2026-08-25 |
| OI-136 | tooling | task | Write the data validator. No database, no schema, no seed data — those went with the SQLite plan. Rescoped 2026-08-31 against 03_Data Pipeline & Design Console - Plan v0.2, which now records .tres as the source of truth rather than an export. Stage 1 shrank rather than grew: both exporters already exist in scripts/build-data.js, so the validator is all that remains, and §6 calls it the real value and the only part never buyable off the shelf. Seven of §6's eight checks need nothing new — build-data.js already parses every .tres into memory, so items with no producer, items nothing consumes, circular dependencies, buildings with no recipe, recipes naming items that do not exist, and recipes needing an unreachable Mk are all queries over a graph that is already there. The eighth needs the research tree as data, which does not exist: 08_Research Tree Design is prose, and turning ~90 nodes into data is a larger question than this row, because the prose carries the reasoning beside the structure. Model it on the warning that already works: build-data.js reports generators shipping power_output = 0, names the files and points at OI-317. Eight more of those, running on every build. |
validator only; no SQLite, no schema | 03_Data Pipeline & Design Console - Plan §6, §6a, §8; scripts/build-data.js |
- | HIGH | 2026-08-25 |
| OI-137 | tooling | task | Mostly delivered 2026-08-31 as three focused pages rather than one console. 05_Reference/10_Recipe Explorer, 11_Chain Explorer and 12_Ratio Calculator cover browsing, visualising the chain and seeing balance ratios - three of the four things this row asked for - built on the pattern the Power Explorer already set: a standalone HTML page reading the generated JSON, read-only, no framework. Unblocked from OI-136 rather than waiting for it: the validator is a separate deliverable, and in practice the pages surface the same gaps as a side effect of rendering them, since a chain that reaches a resource nothing produces has to say so to be honest about its own totals. What remains is the fourth thing: running validation as validation, with a pass or fail rather than an annotation, which is OI-136. Also still open: a building browser, and recipe pages generated into the vault (OI-139). |
pages, not one console | 05_Reference/10_Recipe Explorer.html; 11_Chain Explorer.html; 12_Ratio Calculator.html |
- | HIGH | 2026-08-25 |
| OI-139 | tooling | task | Generate wiki pages into the vault from the data pipeline. | Obsidian [[wikilinks]] |
03_Data Pipeline & Design Console - Plan -> The Wiki - Nearly Free |
- | NORMAL | 2026-08-25 |
| OI-140 | networking | undecided | Decide maximum player count per session. | likely 8 | 02_Server Architecture Document -> Open Questions |
- | NORMAL | 2026-02-22 |
| OI-141 | networking | undecided | Decide how player names work before Steam integration. | - | 02_Server Architecture Document -> Open Questions |
- | NORMAL | 2026-02-22 |
| OI-142 | networking | undecided | Decide whether the host can pause simulation for all players. | - | 02_Server Architecture Document -> Open Questions |
- | NORMAL | 2026-02-22 |
| OI-143 | networking | undecided | Decide whether there is a spectator mode. | - | 02_Server Architecture Document -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-144 | achievements | undecided | Decide how many achievements ship at Early Access launch. | target 20-30 | 02_Server Architecture Document -> Open Questions; 11_Achievements Design Document |
- | NORMAL | 2026-02-22 |
| OI-145 | achievements | undecided | Decide whether achievement progress is visible mid-session. | e.g. 750/1000 Metal Plates | 11_Achievements Design Document -> Open Questions |
- | NORMAL | 2026-02-22 |
| OI-146 | ui | undecided | Decide how the Open to Friends toggle works in the UI. | pause-menu button? | 02_Server Architecture Document -> Open Questions |
- | NORMAL | 2026-02-23 |
| OI-147 | monetization | undecided | Decide whether to offer a supporter pack. | artbook, soundtrack, behind-the-scenes | 03_Monetization Design Document -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-148 | monetization | undecided | Decide mobile monetization flow. | separate app or shared codebase flow | 03_Monetization Design Document -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-149 | monetization | undecided | Decide whether the soundtrack is sold separately as DLC. | - | 03_Monetization Design Document -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-150 | monetization | undecided | Decide referral or gifting discount for multiplayer groups. | - | 03_Monetization Design Document -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-151 | monetization | undecided | Decide whether Early Access has a Founder's Edition cosmetic bonus. | - | 03_Monetization Design Document -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-152 | world | undecided | Decide whether orbital stations persist when Genesis leaves or are dismantled. | - | 05_World Generation & Planet Types -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-153 | world | undecided | Decide whether multiple players can each have an orbital station above the same Gas Giant. | - | 05_World Generation & Planet Types -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-154 | art | task | Define the 3D-space visual representation of an orbital station. | - | 05_World Generation & Planet Types -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-155 | world | undecided | Decide whether Rogue Planets appear inside solar systems or only in deep space. | - | 05_World Generation & Planet Types -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-156 | logistics | task | Define planet contribution factor formula for supply chain contribution. | deferred milestone | 05_World Generation & Planet Types; 06_Vertical Layers -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-157 | vertical | undecided | Decide whether Genesis can be on a different level than the camera. | - | 06_Vertical Layers -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-158 | vertical | undecided | Decide what happens to buildings on a level if the structure above is destroyed. | - | 06_Vertical Layers -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-159 | vertical | undecided | Decide whether underground levels are always the same grid size as the surface. | - | 06_Vertical Layers -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-160 | vertical | undecided | Decide Sky Platform construction flow. | scaffolding first or direct level add | 06_Vertical Layers -> Open Questions |
- | DEFERRED | 2026-02-26 |
| OI-161 | vertical | undecided | Decide whether multiple Item Lifts or Fluid Risers can connect the same two levels at different cells. | yes | 06_Vertical Layers -> Open Questions |
- | NORMAL | 2026-02-26 |
| OI-162 | pipes | undecided | Decide whether two different fluids can exist in the same pipe network. | current assumption: no | 07_Pipe & Fluid System Design -> Open Questions |
- | NORMAL | 2026-02-27 |
| OI-163 | pipes | undecided | Decide what happens when a Storage Tank switches fluid type. | drain first or block switching | 07_Pipe & Fluid System Design -> Open Questions |
- | NORMAL | 2026-02-27 |
| OI-164 | pipes | undecided | Decide whether pipe HP is visible without the diagnostic overlay. | - | 07_Pipe & Fluid System Design -> Open Questions |
- | NORMAL | 2026-02-27 |
| OI-165 | pipes | undecided | Decide whether Fire Suppressor is a placeable building or consumable carried by Genesis. | - | 07_Pipe & Fluid System Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-166 | pipes | undecided | Decide whether viscosity affects heat loss as well as flow rate. | - | 07_Pipe & Fluid System Design -> Open Questions |
- | NORMAL | 2026-02-27 |
| OI-167 | pipes | undecided | Decide Pipe Connector E-key output rotation research unlock tier. | - | 07_Pipe & Fluid System Design -> Open Questions |
OI-004 | NORMAL | 2026-02-27 |
| OI-168 | pipes | undecided | Decide whether pipe complexity can change between sessions or is locked per save file. | - | 07_Pipe & Fluid System Design -> Open Questions |
- | NORMAL | 2026-02-27 |
| OI-169 | pipes | task | Add a fluid-consuming building/content path to test pipe-to-building end-to-end. | content gap, not a bug | 07_Pipe & Fluid System Design -> Open Questions |
OI-001 | HIGH | 2026-02-27 |
| OI-170 | ui | undecided | Decide whether Build Menu auto-hides when not in Build Mode. | - | 09_UI-UX Design Document -> Open Questions |
- | NORMAL | 2026-03-31 |
| OI-171 | ui | undecided | Decide whether HUD layout is player-configurable beyond flap width/collapse. | - | 09_UI-UX Design Document -> Open Questions |
- | NORMAL | 2026-03-31 |
| OI-172 | ui | undecided | Decide tooltip delay: 0.5s or instant. | - | 09_UI-UX Design Document -> Open Questions |
- | NORMAL | 2026-03-31 |
| OI-173 | ui | undecided | Decide how Full Planet Map handles very large planets performance-wise. | - | 09_UI-UX Design Document -> Open Questions |
- | NORMAL | 2026-03-31 |
| OI-174 | ui | undecided | Decide Chat panel position. | above build toolbar or floating | 09_UI-UX Design Document -> Open Questions |
- | NORMAL | 2026-03-31 |
| OI-175 | ui | undecided | Decide how Right Flap Production tab handles very large chain diagrams on small screens. | - | 09_UI-UX Design Document -> Open Questions |
- | NORMAL | 2026-03-31 |
| OI-176 | achievements | undecided | Decide whether achievement toasts appear to all multiplayer players or only the earner. | - | 11_Achievements Design Document -> Open Questions |
- | NORMAL | 2026-03-08 |
| OI-177 | achievements | undecided | Decide whether tiered achievements show the next tier goal once a tier is completed. | yes | 11_Achievements Design Document -> Open Questions |
- | NORMAL | 2026-03-08 |
| OI-178 | achievements | undecided | Decide whether Tier III chains should be designed now or left until post-EA. | - | 11_Achievements Design Document -> Open Questions |
- | DEFERRED | 2026-03-08 |
| OI-179 | achievements | undecided | Decide whether Genesis skins affect visor/laser colour. | yes | 11_Achievements Design Document -> Open Questions |
- | NORMAL | 2026-03-08 |
| OI-180 | gauntlet | undecided | Decide whether Gauntlet wave rewards are fixed per wave or random from a pool. | - | 12_Gauntlet Planet Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-181 | gauntlet | undecided | Decide whether the player can visit the Gauntlet Planet multiple times per session. | - | 12_Gauntlet Planet Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-182 | gauntlet | undecided | Decide whether multiplayer Gauntlet defence is shared or instanced. | - | 12_Gauntlet Planet Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-183 | gauntlet | undecided | Decide Gauntlet Planet story/lore reason. | - | 12_Gauntlet Planet Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-184 | gauntlet | undecided | Decide Gauntlet arena visual direction. | alien ruins or ancient structure | 12_Gauntlet Planet Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-185 | gauntlet | undecided | Decide whether Gauntlet has a maximum wave or is truly infinite. | - | 12_Gauntlet Planet Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-186 | gauntlet | undecided | Decide whether failed Gauntlet runs give partial rewards. | - | 12_Gauntlet Planet Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-187 | gauntlet | undecided | Decide available building set on the Gauntlet Planet. | defence-only or full factory | 12_Gauntlet Planet Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-188 | progression | undecided | Decide whether XP is visible to other players in multiplayer lobbies. | could create pressure | 13_Player Levelling System -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-189 | progression | undecided | Decide whether there is a level cap or infinite levels. | - | 13_Player Levelling System -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-190 | progression | undecided | Decide whether multiplayer sessions award a bonus XP multiplier. | reward cooperative play | 13_Player Levelling System -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-191 | progression | undecided | Decide level 100 prestige system. | reset for cosmetic badge, keep mechanical bonuses? | 13_Player Levelling System -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-192 | progression | undecided | Decide activities that should explicitly not give XP. | anti-farming | 13_Player Levelling System -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-193 | progression | undecided | Decide whether offline/idle time gives XP. | probably not | 13_Player Levelling System -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-194 | factions | undecided | Decide exact session reward for first ship launch. | - | 14_Win Conditions & Faction Allegiance -> Open Questions |
- | DEFERRED | 2026-03-31 |
| OI-195 | factions | task | Define exact material requirements for the Master Rill. | - | 14_Win Conditions & Faction Allegiance -> Open Questions |
- | DEFERRED | 2026-03-31 |
| OI-196 | factions | undecided | Decide whether factions can go to war with each other independent of the player. | - | 14_Win Conditions & Faction Allegiance -> Open Questions |
- | DEFERRED | 2026-03-31 |
| OI-198 | factions | undecided | Decide what The Remnants actually want. | - | 14_Win Conditions & Faction Allegiance -> Open Questions; 01_World Bible -> Factions |
- | DEFERRED | 2026-03-31 |
| OI-199 | factions | undecided | Decide whether multiplayer faction relationships are per-player or shared. | - | 14_Win Conditions & Faction Allegiance -> Open Questions |
- | DEFERRED | 2026-03-31 |
| OI-200 | factions | undecided | Decide whether factions can be permanently destroyed. | - | 14_Win Conditions & Faction Allegiance -> Open Questions |
- | DEFERRED | 2026-03-31 |
| OI-201 | factions | undecided | Decide whether faction relationships persist across worlds. | - | 14_Win Conditions & Faction Allegiance -> Open Questions |
- | DEFERRED | 2026-03-31 |
| OI-202 | ships | undecided | Decide whether APR is visible to other players in multiplayer. | could affect diplomacy/intimidation | 15_Ship & Army Points Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-203 | ships | undecided | Decide whether fleet APR factors into War layer supply-chain demand. | - | 15_Ship & Army Points Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-204 | ships | undecided | Decide whether faction fleets show APR before scanning or only after scanner reveal. | - | 15_Ship & Army Points Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-205 | ships | undecided | Decide whether research nodes boost APR calculation. | tactics bonuses | 15_Ship & Army Points Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-206 | ships | undecided | Decide whether APR scales with pilot skill/experience in later phases. | - | 15_Ship & Army Points Design -> Open Questions |
- | DEFERRED | 2026-02-27 |
| OI-207 | lore | undecided | Decide exact cause of The Collapse. | may remain permanently ambiguous | 01_World Bible -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-208 | lore | undecided | Decide whether discoverable lore fragments appear in Phase 1 or are deferred to Phase 2. | - | 01_World Bible -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-209 | lore | undecided | Decide what the ancient ruins are and who built them. | can remain mystery through v1.0 | 01_World Bible -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-210 | factions | undecided | Decide whether factions exist in Phase 1 as AI opponents or only in Phase 3. | - | 01_World Bible -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-211 | factions | undecided | Decide whether players can name their faction and customise its colours. | - | 01_World Bible -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-212 | lore | undecided | Decide whether in-game narrative progression exists or the story is purely systemic. | - | 01_World Bible -> Open Questions |
- | DEFERRED | 2026-02-22 |
| OI-213 | art | undecided | Decide polygon budget per building. | deferred to optimisation pass | 01_Art Direction Document -> Open Questions |
- | NORMAL | 2026-03-03 |
| OI-214 | factory | undecided | Decide exact passive Field Data RP rates. | prototype and balance | - | - | NORMAL | 2026-02-22 |
| OI-215 | pipes | undecided | Decide whether fluids have temperature as a mechanic. | - | 07_Pipe & Fluid System Design -> Temperature System |
- | NORMAL | 2026-02-22 |
| OI-216 | genesis | undecided | Decide Genesis mining speed relative to a Mining Drill. | - | - | - | NORMAL | 2026-02-22 |
| OI-218 | code | defect | Pointer: IoConnector / PipeConnector still ship despite design replacing them with ports. |
- | AGENTS.md -> Known Code/Design Divergences |
OI-004 | HIGH | 2026-08-26 |
| OI-219 | code | defect | Pointer: BuildingInstance.ChestMode exists but is unassigned and unserialized. |
- | AGENTS.md -> Known Code/Design Divergences |
OI-048 | HIGH | 2026-08-26 |
| OI-220 | code | defect | Pointer: Splitter/Merger/Filter Splitter are removed in design but Router does not exist in code. | - | AGENTS.md -> Known Code/Design Divergences |
OI-063 | HIGH | 2026-08-26 |
| OI-221 | code | defect | Pointer: power is data only; no simulation consumes power_draw or power_output. |
- | AGENTS.md -> Known Code/Design Divergences |
OI-079 | HIGH | 2026-08-26 |
| OI-222 | code | defect | Pointer: upgrade implementation must preserve modules, ports, storage contents, role, and in-progress work. | - | AGENTS.md -> Known Code/Design Divergences |
OI-072 | HIGH | 2026-08-26 |
| OI-223 | code | defect | Pointer: building status is on the wrong surface; base ring, working lights, and pulse rhythms do not exist. | - | AGENTS.md -> Known Code/Design Divergences |
- | HIGH | 2026-08-26 |
| OI-224 | code | defect | Pointer: minimap coordinate conversion misses the +100 world offset. | - | AGENTS.md -> Known Code/Design Divergences |
- | HIGH | 2026-08-26 |
| OI-225 | code | defect | Pointer: no building can receive fluid as a production input. | - | AGENTS.md -> Known Code/Design Divergences |
OI-001 | HIGH | 2026-08-26 |
| OI-226 | art | defect | Pointer: only the Mining Drill has a 3D asset; all other buildings are procedural boxes. | - | AGENTS.md -> Known Code/Design Divergences |
OI-031 | NORMAL | 2026-08-26 |
| OI-227 | code | defect | Pointer: ScenarioTestRunner docstring says F8 but binding is F9. |
- | AGENTS.md -> Known Code/Design Divergences |
- | NORMAL | 2026-08-26 |
| OI-228 | outpost | undecided | Specify Outpost navigation UI. | pending 08_Navigation & UI.md |
06_Outpost/01_Outpost Mode Overview -> Open Questions |
- | DEFERRED | 2026-03-13 |
| OI-229 | outpost | undecided | Decide exact alien detection radius per storey depth. | balance pass | 06_Outpost/03_Enemy Design -> Open Questions |
- | DEFERRED | 2026-03-13 |
| OI-230 | outpost | undecided | Decide whether internal drones patrol before Genesis is detected. | AI design | 06_Outpost/03_Enemy Design -> Open Questions |
- | DEFERRED | 2026-03-13 |
| OI-231 | outpost | undecided | Decide command drone special abilities beyond high flight. | tower design doc | 06_Outpost/03_Enemy Design -> Open Questions |
- | DEFERRED | 2026-03-13 |
| OI-232 | outpost | task | Define the full Outpost hazard list and mechanical effects. | procedural generation doc | 06_Outpost/03_Enemy Design -> Open Questions |
- | DEFERRED | 2026-03-13 |
| OI-233 | outpost | undecided | Decide exact building completion multiplier values. | balance pass | 06_Outpost/04_Progression & Rewards -> Open Questions |
- | DEFERRED | 2026-03-09 |
| OI-234 | outpost | undecided | Decide passive trickle rate per outpost type and level. | balance pass | 06_Outpost/04_Progression & Rewards -> Open Questions |
- | DEFERRED | 2026-03-09 |
| OI-235 | outpost | undecided | Decide whether request bonus XP scales with difficulty or is flat. | - | 06_Outpost/04_Progression & Rewards -> Open Questions |
- | DEFERRED | 2026-03-09 |
| OI-236 | outpost | undecided | Decide social visibility settings for Outpost session records. | - | 06_Outpost/04_Progression & Rewards -> Open Questions |
- | DEFERRED | 2026-03-09 |
| OI-237 | outpost | undecided | Decide exact storey count ranges per outpost type and level. | balance pass | 06_Outpost/05_Procedural Generation -> Open Questions |
- | DEFERRED | 2026-03-09 |
| OI-238 | outpost | undecided | Decide whether the full outpost map is visible immediately or revealed through exploration. | - | 06_Outpost/05_Procedural Generation -> Open Questions |
- | DEFERRED | 2026-03-09 |
| OI-239 | outpost | undecided | Decide whether players can share Outpost seeds. | - | 06_Outpost/05_Procedural Generation -> Open Questions |
- | DEFERRED | 2026-03-09 |
| OI-240 | outpost | task | Define visual differentiation between outpost types. | art pass | 06_Outpost/05_Procedural Generation -> Open Questions |
- | DEFERRED | 2026-03-09 |
| OI-241 | ideas | undecided | Decide whether Quantum Silo being invalid as production input is too strict. | protects the belt game | 00_Ideas/04_Idea - Quantum Silo.md -> Interaction With the Store Redesign |
- | DEFERRED | 2026-08-25 |
| OI-249 | art | task | 07_Art Direction Style Bible section 4, Concept Prompt Template, is marked Pending and blocks all concept generation. The Recraft and Leonardo master prompts in 01_Art Direction Document specified cel-shading, thick dark outlines, flat colour faces and per-category accent colours - all superseded - and were removed in the v0.6 rewrite. They were not replaced in that document, because writing them there would author the authority's pending content downstream and invert the precedence rule. Section 4 must embed the section 1 palette values plus a locked reference render. |
must embed section 1 values plus a locked reference render | 07_Art Direction Style Bible -> Concept Prompt Template; 01_Art Direction Document -> Concept Generation Prompts |
- | HIGH | 2026-08-27 |
| OI-250 | art | defect | Faction badge colours conflict with the single-accent rule. 01_Art Direction Document assigns five saturated badge colours (Salvagers orange, Vanguard steel blue, Cultivators forest green, Remnants dark purple, plus player white), applied as a band at the base of every building. Canonical section 6 says Accent Orange is the only accent colour, and the base ring is a signal channel that is unlit when healthy. Faction identity may be a legitimate exception, or badges may need moving off the base ring entirely - a coloured band at ground level sits exactly where fault status lives. |
- | 01_Art Direction Document -> Faction Badge System; 07_Art Direction Style Bible -> Base Ring Status |
- | HIGH | 2026-08-27 |
| OI-251 | art | defect | Primary Visual References may no longer describe the target style. 01_Art Direction Document cites Satisfactory, Astroneer, Townscaper and Factorio, chosen when the style was cel-shaded low poly with thick outlines. The Style Bible instead anchors on a locked reference render it calls "Image 3" and specifies clean chamfered hard-surface, matte PBR, no outlines. Decide whether the four references still hold, and replace them with the locked render if not. |
- | 01_Art Direction Document -> Primary Visual References; 07_Art Direction Style Bible -> Surface finish |
- | NORMAL | 2026-08-27 |
| OI-252 | art | defect | Cyan selection highlight collides with a signal channel. 01_Art Direction Document specifies Bright Cyan #00E5FF for selection highlight, while Emissive Cyan #2ED9E8 at energy 2.5 means alive and working on every building (Style Bible section 1.7a). Two cyans a few hex values apart, one a UI state and one a world signal. Also check the translucent green/red placement ghosts against the amber/red fault palette. |
- | 01_Art Direction Document -> Colour System; 07_Art Direction Style Bible -> Working Lights |
- | NORMAL | 2026-08-27 |
| OI-253 | power | defect | The Atmospheric Harvester is missing from the power generation source table. It is fully specified in 06_Vertical Layers with a per-level efficiency table (surface 50%, Sky L1 75%, Sky L2 100%, Sky L3+ 125%), planet modifiers (Rogue 0% - no atmosphere, Carbon 60% - thin) and an unlock (High Altitude Construction), but 25_Power System Design section 5.1 lists nine sources and it is not among them. Flagged in the vertical addendum as "not accounted for in the power source table" and carried over when that document was merged. Adding the row needs an output value and variability rating that were never decided. |
- | 06_Vertical Layers -> Planet-Type Efficiency Modifiers; 25_Power System Design -> Source Table |
- | NORMAL | 2026-08-27 |
| OI-254 | code | defect | Every pipe connector runs tick_pull/tick_push twice per simulation tick. WorldScene._place_pipe_connector_at() registers the same object into both PipeSystem._connectors and SimulationManager._pipe_connectors (WorldScene.gd:1143-1144). SimulationManager._simulation_tick() ticks them at P3b/P3c (:174-182), then P3d calls PipeSystem.simulation_tick() which ticks the same objects again (PipeSystem.gd:139-142). Fluid throughput on connector-mediated links is currently 2x the intended rate. Fix or measure before the port refactor, or the port system will look like a 50% fluid nerf. |
- | SimulationManager.gd:174-186; PipeSystem.gd:136-144; WorldScene.gd:1143 |
- | DO FIRST | 2026-08-27 |
| OI-255 | code | defect | SAVE_VERSION is written but never read. SaveManager.gd:12 defines it and :42 writes it into the save dict; nothing anywhere compares data["version"] on load. Bumping the constant will not reject old saves. This matters now because the port refactor renumbers GenesisTask.Type: removing PLACE_CONNECTOR (index 4) and PLACE_PIPE_CONNECTOR (index 6) shifts FETCH_MATERIALS 7->5 and DEPOSIT_MATERIALS 8->6, and the load match has no default arm, so an old save silently constructs the wrong task type and then errors on a missing key. Add the version gate as part of the refactor, not after. |
refuse to load version < 2 | SaveManager.gd:12,42; GenesisTask.gd:11-21; WorldScene.gd:2093-2130 |
- | HIGH | 2026-08-27 |
| OI-256 | data | defect | Building footprints in 04_Factory disagree with the shipped .tres files. gas_pump is 2x2 in data, 2x3 in the doc. advanced_press is 2x3 in data, 4x5 in the doc. refinery matches at 3x4. This is load-bearing for the port refactor: port count per face derives from footprint edge length, so the design's worked examples do not match what would actually be generated. Audit all 24 .tres against the doc tables and decide which side is right in each case. |
- | 04_Factory -> Building List; data/buildings/*.tres |
- | HIGH | 2026-08-27 |
| OI-257 | code | defect | Three dead artefacts to delete with the port refactor, not build on. BuildingInstance.install_port() (:283-286) is an empty uncalled function whose comment claims "kept for API compatibility" for an API that never shipped - the only commit touching it is the one that added it, and its untyped int signature is wrong for a per-cell port model. BuildingInstance.tick_output() (:166-171) is an uncalled no-op still sitting in the tick path's shape. src/entities/pipes/PipeConnector.gd is a 171-byte dead stub superseded by the buildings/ version, and is not listed in the refactor's deletion table. |
- | BuildingInstance.gd:166,283; src/entities/pipes/PipeConnector.gd |
- | NORMAL | 2026-08-27 |
| OI-260 | trains | defect | Freight and Fuel Platforms were described as buildings with ports, which under 24_Module System Design section 2.2 gave a four-wagon station five module slots. Converted to extensions of the Station Head 2026-08-27, matching farm bays. The contradiction that remains: 22_Trains & Rail section 4.2 keeps the four-commodity capability, but its stated mechanism was "each platform's ports are configured independently" and platforms now have no ports. Presumably reachable via the Station Head's own ports with per-wagon filters, but no document specifies that. Decide the mechanism; do not drop the capability. |
extensions, matching farm bays | 22_Trains & Rail -> Stations Are Modular; [27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) -> Two Buildings, One Pattern |
- | HIGH | 2026-08-27 |
| OI-261 | farming | undecided | Decide the greenhouse air input: a zonal yield bonus from local air pollution, or a piped capture fluid taken from generator exhaust. | piped; zonal makes smog locally good and fights Pollution section 2. Capture uses where the Air Scrubber neutralises |
[27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) -> The air input is open |
- | HIGH | 2026-08-27 |
| OI-262 | farming | undecided | Decide whether Algae is a distinct resource or the Pond Head produces fld_fuel via an intermediate. This row now also owns creating raw_algae if the answer is distinct. OI-286 split raw_biomass into the family biomass with wood as its substance, and deliberately stopped there rather than deciding this by omission — the structure is ready for a second substance and nothing else blocks it. OI-287 is waiting on the outcome in practice, since biomass currently has one member and a any substance in this family rule cannot be demonstrated on a family of one. |
- | [27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) -> Algae |
- | HIGH | 2026-08-27 |
| OI-263 | farming | undecided | Decide the flue capture ceiling. Must be below 100%. | zero requires stopping combustion, not out-plumbing it; full capture would collapse the dirty-versus-clean axis into a plumbing puzzle solved once | [27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) -> The Zero-Pollution Planet |
OI-261 | HIGH | 2026-08-27 |
| OI-264 | farming | undecided | Decide footprints for Control Hut, Greenhouse Bay, Pond Head and Pond Bay. | - | [27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) -> What This Touches |
- | HIGH | 2026-08-27 |
| OI-265 | farming | undecided | Decide artificial lighting power draw, and whether it replaces ambient light fully or only supplements it. | - | [27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) -> Artificial lighting is allowed |
- | NORMAL | 2026-08-27 |
| OI-266 | farming | undecided | Decide maximum bay count per head, and whether bays must be contiguous with the head. | placement validation is new; nothing else in the vault does this | [27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) -> Control Hut plus Bays |
- | NORMAL | 2026-08-27 |
| OI-267 | farming | undecided | Decide the fertiliser recipe and which recycled organic waste produces it. | - | [27_Organic Farming & Biomass Design](<01_Design Documents/Systems/27_Organic Farming & Biomass Design.md>) -> Inputs; Pollution -> Waste Handling |
- | NORMAL | 2026-08-27 |
| OI-270 | tooling | task | Delete sync_docs.bat. The vault sync workflow is retired. The OneDrive Obsidian folder it pushed to has been removed, so the script has no destination and no purpose. It was already non-functional: both hardcoded paths were wrong for this machine and it exited 2 without copying, so no sync had happened for as long as the repo has been at its current path. docs/ in the repo is now the only copy. |
delete, do not repoint | sync_docs.bat |
- | NORMAL | 2026-08-27 |
| OI-274 | trade | undecided | Decide whether quantum travel replaces ship travel time as a late-game upgrade to the trade route, or runs as a parallel channel alongside ships. Scope is settled: player-to-player only, never to yourself, which is what keeps the transport ship layer intact. This is the remaining question. | upgrade reads better than a parallel channel: it changes something the player has felt the cost of for hours | 06_Design Session Decision Log -> Transport & Logistics; 14_Win Conditions & Faction Allegiance -> Trade |
- | NORMAL | 2026-08-27 |
| OI-277 | data | task | Collapse ResourceDefinition and FluidDefinition into one class. They are separate classes, not inheritance, joined only by a shared id string, and nothing enforces that a fluid-medium resource has a matching FluidDefinition. That is how Chemical Gas ended up with a ResourceDefinition and no fluid properties at all - no viscosity, density or temperatures. With phase as a field, the fluid physical properties become optional fields on the same resource and the whole failure mode disappears. |
one class, optional fluid properties | 06_Design Session Decision Log -> Resource Data Model; FluidDefinition.gd; ResourceDefinition.gd |
- | HIGH | 2026-08-28 |
| OI-279 | data | defect | No recipe produces any fluid, and Liquid Metal has no production path at all. None of the ten shipped recipes outputs an fld_* resource. fld_liquid_metal is iron in liquid phase, but the model had no way to express a phase change, so the smelting step that would produce it was never written. Under the new model this becomes an honest SOLID -> LIQUID recipe on one substance rather than a mapping between two unrelated rows. |
smelting is a phase change | 06_Design Session Decision Log -> Resource Data Model; data/recipes/ |
- | HIGH | 2026-08-28 |
| OI-280 | data | defect | ResourceTier is already wrong on its own terms, in shipped data. cmp_structural_frame is made from cmp_hull_plating and cmp_power_cell from cmp_circuit_board, so two of five components are made from components and the ladder does not hold. Nothing is tier 3 - ADVANCED has zero resources. Recorded as evidence for OI-276 rather than as separate work; it closes with the tier removal. |
- | 06_Design Session Decision Log -> Resource Data Model; data/recipes/ |
- | NORMAL | 2026-08-28 |
| OI-281 | logistics | undecided | Drone payload is determined by the cache box it carries, not a flat per-drone figure. Capacity is a property of the box, so a drone's throughput is chosen at load time rather than fixed by the drone. Still to decide: how many box sizes exist, whether box size affects flight speed or battery drain, whether a fluid-carrier drone uses a box or a dedicated tank, and how box capacity compares to a belt's throughput over the same distance. | capacity belongs to the box, not the drone | 06_Design Session Decision Log -> Transport & Logistics |
- | HIGH | 2026-08-28 |
| OI-282 | logistics | task | Make belts data-driven with real Mk tiers. 04_Factory documents Basic 1/sec, Fast 2/sec and Express 4/sec, but there is one hardcoded speed - BeltSegment.BELT_TICKS = 20 - and no belt .tres exists at all among the 24 building definitions. This is prototype scaffolding, not a design gap: the tiers were documented ahead of the data. Needs belt definitions in data/, the speed moved out of the script per the no-hardcoded-balance rule, and a decision on how belt tiers compose with Base Mk, which raises port throughput - two throughput systems that currently have no stated interaction. |
prototype scaffolding to replace, not a defect to fix | 06_Design Session Decision Log -> Transport & Logistics; BeltSegment.gd:22; 04_Factory -> Conveyor Belts |
- | HIGH | 2026-08-28 |
| OI-283 | data | undecided | Decide whether substance, viscosity and density earn their place - after the whole game has been reviewed, not before. All three are currently unread. viscosity and density are declared on FluidDefinition and consumed nowhere; substance is proposed but has no consumer yet, and no shipped comparison game has an equivalent (Satisfactory keeps Iron Ore and Molten Iron as unrelated items). Deliberately deferred rather than cut: systems not yet designed may need them, and cutting a field because today's code does not read it is how the game ends up unable to describe something later. Revisit once the full system pass is done. |
do not cut on today's evidence alone | 06_Design Session Decision Log -> Transport & Logistics; FluidDefinition.gd |
- | NORMAL | 2026-08-28 |
| OI-284 | docs | task | Keep 05_Reference/04_Data Dictionary.md current, and sweep the vault against its deprecated word list. The dictionary is new and its deprecated column is the actionable part: chest, Wood, Solar Collector, generic Shaft, Splitter/Merger/Filter Splitter, ResourceTier, Module Expansion, cel-shader and category accent colour all still appear in places across docs, code identifiers, UI labels and asset filenames. Sweep each, and add new terms to the dictionary before using them rather than after. |
one term, one meaning | 05_Reference/04_Data Dictionary.md -> Deprecated Words |
- | HIGH | 2026-08-28 |
| OI-285 | design | undecided | Decide the Simulation Level payoff. Structure is settled: a global level sets defaults, per-system overrides are allowed, and pipe_complexity becomes one facet rather than a special case. What higher levels reward is deliberately open. Precedent exists - pipe_complexity already grants a permanent supply chain contribution multiplier of x1.0 / x1.15 / x1.30. Candidates recorded, none chosen: extend the contribution multiplier; content that only exists higher up (temperature-dependent recipes are meaningless at Basic, so Full has recipes Basic cannot run, which costs no balance tuning); separate leaderboards per simulation level; reduced player-to-player transfer cost. Also decide which systems get an override. 2026-09-11: the rule and the first two answers now exist. Canonical section 24 states the constraint: a Simulation Level never changes what is optimal - fidelity scales, balance does not. It is strictly stronger than the doc 19 test, which abstracting the barrel return loop passes while still breaking the pipe-versus-barrel comparison. Two concrete answers followed: 41_Fluid Packaging & Carriage Design section 10 (container ratings at 2, wear/fire/venting at 3, the empties loop baseline at every level), and 26_Pollution section 3b.6 (cell size and tick rate as the dial, which is also OI-365's answer). Both cost no balance tuning, which is the content that only exists higher up candidate working as hoped. What is still open is narrower than it was: whether the contribution multiplier keeps scaling with level, whether leaderboards separate by level, and which systems get an override. |
global default + per-system overrides | 06_Design Session Decision Log -> Resource Properties and Simulation Level; 01_Master GDD -> Session Rules |
- | HIGH | 2026-08-28 |
| OI-287 | data | task | Let recipes accept any substance in a category. ref_polymer should take any biomass rather than naming wood and algae separately, or the split in OI-286 forces duplicate polymer recipes. This is what makes category load-bearing rather than organisational: the recipe system becomes a reader of it, which is the test tier failed. Needs RecipeDefinition.inputs to express a category as well as a resource id. |
any-substance-in-category inputs | 06_Design Session Decision Log -> Resource Properties and Simulation Level; RecipeDefinition.gd |
- | HIGH | 2026-08-28 |
| OI-288 | tooling | task | Add a validator for the refining rule: a component is never made directly from raw. True in all ten shipped recipes, but written down nowhere until now. Warn, do not fail. In reality almost nothing skips a step, but the step is often trivial - stone is cut, logs are sawn - and forcing a refined intermediate every time risks padding the chain with a machine and a belt that add no decision. A warning catches accidents while allowing a deliberate override. This validator is what gives type a reader; without it type is a hand-maintained label nobody consumes, which is how tier died. |
warning, never a hard failure | 06_Design Session Decision Log -> Resource Properties and Simulation Level |
- | HIGH | 2026-08-28 |
| OI-289 | data | task | Add fuel_value to resources, and an accepted-fuel list to burners. Energy per unit is a property of the substance a burner cannot know, so it lives on the resource. There is deliberately no fuel_type: Steam burns coal and Diesel burns liquid fuel, and both are combustion, so a COMBUSTION tag would let a steam locomotive eat diesel. Per-burner lists are simpler and more expressive. ⚠️ Burning cannot be a recipe - RecipeDefinition outputs a resource, and power is not a resource - so burners need their own fuel mechanism regardless. No fuel system exists today: coal_generator.tres has empty accepted_recipe_ids. |
fuel_value on the substance, accepted list on the burner | 06_Design Session Decision Log -> Resource Properties and Simulation Level; coal_generator.tres |
- | HIGH | 2026-08-28 |
| OI-290 | trains | undecided | Decide whether steam locomotives consume water, as a Simulation Level feature. A steam locomotive burns coal; water is the working fluid, not the fuel, and 22_Trains & Rail section 3 currently lists coal only. Realistic, but loading coal and water into every depot is a heavy burden for the earliest locomotive, which is already the highest-burden option. Candidate for a higher Simulation Level rather than a baseline. |
opt-in realism, not baseline | 06_Design Session Decision Log -> Resource Properties and Simulation Level; 22_Trains & Rail -> Locomotive Types |
OI-285 | NORMAL | 2026-08-28 |
| OI-291 | docs | defect | 27_Organic Farming & Biomass Design section 2.1 is now partly wrong. It states that raw_wood, organic carbon and bio-polymer crops were "deleted rather than defined". Under the category model, wood is a substance in category biomass and is restored; only organic carbon and bio-polymer crops remain deleted as duplicates. The document's conclusion still holds - three crops feeding identical outputs was duplication - but it collapsed to the category name. Not edited unilaterally: it is an authored design document and this reverses a stated decision in it. |
wood restored, the other two stay deleted | 06_Design Session Decision Log -> Resource Properties and Simulation Level; 27_Organic Farming & Biomass Design -> The Correction |
- | HIGH | 2026-08-28 |
| OI-292 | trains | task | Design the nuclear reprocessing chain. Reprocessing is the Treat option for nuclear waste in the existing three-way Store / Treat / Dump structure (Pollution section 5), and it is what turns nuclear from a penalty into a system. Needs the building, the recipe, and a recovery rate. ⚠️ Recovery must never reach 100% - the third instance of this guard rail after Incinerator heat recovery and the flue capture ceiling. |
reduces the problem, never removes it | 06_Design Session Decision Log -> Locomotive Power; 26_Pollution, Waste & Organic Systems Design -> Waste Handling |
- | HIGH | 2026-08-28 |
| OI-293 | trains | undecided | Decide the battery-electric locomotive's numbers and its charging station. Battery is now an electric variant alongside catenary, paying in time rather than distance: a charging station at each stop plus charging duration. Needs range per charge, charge time, station cost and footprint, and whether a battery train can use catenary where it exists. The distinction that must survive: catenary cost scales with route length, battery cost with number of stops. | point infrastructure, not none | 06_Design Session Decision Log -> Locomotive Power; 22_Trains & Rail -> Locomotive Types |
- | HIGH | 2026-08-28 |
| OI-294 | trains | undecided | Decide nuclear's concrete advantage over the other two. Framed as strongest for long hauls and remote lines, but no numbers exist. Candidates: range between refuels, payload, or speed sustained without stops. Must be enough that a player who has built the waste chain feels rewarded, without making catenary and battery pointless on the routes they suit. | strongest where neither wiring nor stopping is acceptable | 06_Design Session Decision Log -> Locomotive Power |
OI-292 | NORMAL | 2026-08-28 |
| OI-295 | logistics | undecided | Decide drone numbers. Battery range per charge, charge time in the module, flight speed, and cache box sizes. Range is the load-bearing one: it sets how far a route can be before poles are needed en route, and therefore how much the Simulation Level stranding behaviour actually bites. | range constrains route length; poles are insurance, not required | 06_Design Session Decision Log -> Drones; 04_Factory -> Drones |
- | HIGH | 2026-08-28 |
| OI-296 | logistics | undecided | Decide drone module mechanics. Can a module hold a drone and transfer cargo at the same time, or are docking and transfer separate phases? One drone per module, or several? Now also: how an assigned drone's module interacts with a reserve drone arriving from the pit - does the reserve dock in the same module, and can both be present at once? | - | 06_Design Session Decision Log -> Drones |
- | NORMAL | 2026-08-28 |
| OI-299 | data | task | Add unit_size to resources. Silo capacity is measured in units, not items: a Silo of capacity 10 holds two things of unit_size 5. Makes storage spatial rather than a count. May also give density a job - it exists on FluidDefinition and is read by nothing, and is the natural fluid analogue. Needs values assigned per substance, which is balance work. |
unit_size on the resource, capacity on the Silo |
06_Design Session Decision Log -> Storage Model; ResourceDefinition.gd |
- | HIGH | 2026-08-29 |
| OI-300 | code | defect | inventory_capacity means two different things in the same class. receive_item() caps per substance; receive_items() caps the total across all substances. A building with capacity 10 holds 10 iron and 10 copper when belt-fed, but Genesis refuses to deposit once the total reaches 10 - same field, two meanings, depending on which door the items came through. Per-substance is correct for buildings (machines buffer, Silos store), so receive_items is the one to fix. |
per-substance for buildings | 06_Design Session Decision Log -> Storage Model; BuildingInstance.gd:183,255 |
- | HIGH | 2026-08-29 |
| OI-301 | code | task | Delete max_input_slots and max_output_slots from BuildingDefinition. Under the port model any port can be INPUT or OUTPUT and port count derives from footprint, so the player decides how many of each - a separate cap is the pre-port model left behind. The code only reads them as > 0 booleans meaning "does this accept input at all", which ports answer better. Confirms the port refactor's instinct rather than reviving them. Set in all 24 building .tres. |
ports replace them entirely | 06_Design Session Decision Log -> Storage Model; BuildingDefinition.gd:56,60 |
OI-004 | HIGH | 2026-08-29 |
| OI-302 | logistics | task | Specify the packing station and the packing module. Two ways to feed drones, both kept: belt or pipe into a packing station that drones collect from (centralised, one station serving many routes, costs space and a building), or a packing module on the building itself (local, no belt run, costs a module slot). Needs the building, the module, footprints, power and what packing actually consumes. | both routes stay; they scale differently | 06_Design Session Decision Log -> Storage Model; 04_Factory -> Drones |
OI-295 | HIGH | 2026-08-29 |
| OI-303 | logistics | undecided | Decide how the packing capability is obtained. ⚠️ Approach superseded by OI-306: rather than crafting a combined module from two and swapping it in, the installed drone module is upgraded in place, reusing the Upgrade Kit pattern. That gives two functions in one slot without reviving stacking. What remains open is the cost: available from the start, research-gated (recommended), or not at all so drone logistics simply costs two slots. Recommendation is research-gating, on the same shape as an existing decision - the ground Power Pole is free and the roof-mounted pole module is research-gated. | research-gated, mirroring the roof Power Pole | 06_Design Session Decision Log -> Storage Model; 24_Module System Design -> No Stacking |
OI-302 | HIGH | 2026-08-29 |
| OI-304 | storage | undecided | Decide Silo capacity scaling, and whether Tanks follow the same rule. Canonical says Silo capacity scales by Mk, but not by how much, and unit_size now means the same Silo holds very different amounts of different substances. Also confirm the Tank is single-fluid by the same rule the Silo is single-substance - the pipe no-mixing rule already implies it but it is not written as a storage rule. |
Tank should mirror the Silo | 06_Design Session Decision Log -> Storage Model; 00_Canonical Design Facts -> Storage |
OI-299 | NORMAL | 2026-08-29 |
| OI-308 | logistics | task | Specify the drone pit. Holds the shared reserve: drones are stationed there, charge there, and are dispatched to any configured route that spikes. Needs the building, footprint, power draw, how many drones it holds, and how a player assigns drones into it. Rules already settled: serves any selected route at any distance with no coverage radius, trips always finish with no mid-route recall, and an empty pit simply means no more drones - the route runs at assigned capacity. | no radius; distance is paid for, not prohibited | 06_Design Session Decision Log -> Drone Routing; 04_Factory -> The drone pit |
OI-295 | HIGH | 2026-08-29 |
| OI-309 | logistics | undecided | Decide cache box numbers. Settled: a box holds one substance, a drone carries several boxes, and capacity per box type is a tuning value so cardboard and metal can differ. Still needed: box capacity in units per material, boxes per drone, and whether more boxes costs battery drain - coupling capacity to range would keep bigger from being strictly better, using the constraint that already makes stranding bite. | couple capacity to battery drain, not free | 06_Design Session Decision Log -> Drone Routing; 04_Factory -> Drones |
OI-299 | HIGH | 2026-08-29 |
| OI-310 | data | task | Specify the cardboard chain and both box items. New: a cardboard substance from wood, plus flat box and assembled box as distinct items in each material. Flat ships normally; assembled exists only at modules and in drone cargo, which is what breaks the ship-boxes-inside-boxes recursion. Needs recipes for cardboard, flat boxes in both materials, and assembly at the module. Gives the Biomass Farm a customer beyond fuel and polymer. | flat ships, assembled packs | 06_Design Session Decision Log -> Cache Boxes; 04_Factory -> Cache boxes |
- | HIGH | 2026-08-29 |
| OI-311 | logistics | undecided | Decide box degradation and worn-box handling at Simulation Level 3. Rate is configured per substance, so metal and plastic wear differently - a tuning value, not a design decision. Still needed: the values, whether wear is per trip or per unit carried, and how worn boxes are collected from modules. Worn boxes are recycled, not repaired - they go to the Recycler and return as material, which reuses an existing building rather than inventing item repair. ⚠️ Recovery must be below 100%, or cardboard becomes free and metal has no reason to exist. | recycle never repair; lossy recovery; per-substance rate | 06_Design Session Decision Log -> Cache Boxes; Pollution -> Waste Handling |
OI-310 | NORMAL | 2026-08-29 |
| OI-315 | docs | defect | closed-items.md has three row shapes and its header describes one. The header declares nine columns and omits Kind, matching all 53 CI- rows. But 30 of the 31 OI- rows carry ten, keeping Kind from open-items.md, so Markdown renders their extra cell into a column with no heading. The 31st is OI-016, which carries nine and is missing its Kind entirely - a one-off that predates this finding and is the clearest evidence the shape was never deliberate. Practice across 30 closures is consistent, so the header is what is wrong, but correcting it means giving 53 historical rows a Kind they were never assigned, and reconstructing one for OI-016. Not fixed unilaterally because it means editing append-only history. |
header follows practice; historical rows take -; OI-016 gets its Kind back |
docs/closed-items.md |
- | NORMAL | 2026-08-29 |
| OI-316 | code | task | The orthographic-vs-perspective camera question was never answered; the engine default answered it. 01_Technical Architecture Document -> Open Technical Questions still lists it unticked as (Test both in prototype), and the test was never run. scenes/main.tscn sets no projection and no fov on the Camera3D, so perspective at 75 degrees is Godot's default rather than a choice - CI-001 recorded those numbers as fact without noting that nothing chose them. Left unticked deliberately: marking it resolved would record a decision that was not made. Worth settling early, because projection changes how buildings read at distance and the Style Bible leans on that - silhouette as the category signal (§1.1), tab counting at range (§1.7), and tabs breaking the silhouette. |
run the comparison, or accept perspective on purpose | 01_Technical Architecture Document -> Open Technical Questions; scenes/main.tscn; 07_Art Direction Style Bible §1.7 |
- | NORMAL | 2026-08-29 |
| OI-317 | data | task | Write the decided power values into the .tres files. All nine sources now have output and fuel rates in 25_Power System Design §5.1 and §5.1a, so the numbers exist; the data does not. Every generator still ships power_output = 0.0 (coal_generator, fuel_generator, solar_panel, accumulator) while consumers carry real draws. Needs Coal 100, Fuel 250, Solar 50 peak, Biomass 40, Wind 60 base, Geothermal 300, Nuclear 600, and the Core Power Station left formula-driven from CER. Also needs the fuel rate fields, which do not exist on BuildingDefinition at all, and the two scale knobs from §1a.3. Distinct from OI-221, which is that no simulation reads these fields. |
§5.1 is the authority; do not re-derive | 25_Power System Design -> §5.1, §5.1a, §1a.3; data/buildings/*.tres |
- | HIGH | 2026-08-29 |
| OI-318 | data | task | Give the Accumulator its storage and rate fields. The design is settled - 25_Power System Design §5.5 sets capacity 500 PU·s, charge and discharge capped at 100 PU, round-trip 0.90 - but accumulator.tres has no capacity field and power_draw and power_output are both 0.0, so it neither charges nor discharges. BuildingDefinition needs the three fields. Note the unit: storage is PU·s, not PU, and 04_Factory has been corrected. §4a.7 depends on reading current charge and on knowing whether the discharge rate can hold for the restore dwell window. |
PU·s for storage, PU for the rate | 25_Power System Design -> §5.5; data/buildings/accumulator.tres; BuildingDefinition.gd |
- | HIGH | 2026-08-29 |
| OI-319 | code | task | BuildingDefinition has no power priority field. It carries power_draw and power_output and nothing else power-related, but 04_Factory -> Power Priority System specifies a 1-5 per-building priority set in the building detail panel after Power Management research, and 25_Power System Design §4a.6 makes that priority the primary shed ordering. Needs the field, the default order (Research Labs -> Drones -> Storage -> Processing -> Extraction), the pre-research fixed-order behaviour, and persistence in saves, since a player's priority settings must survive a reload. Note the panel dependency: like the port work in OI-004, the setting lives in a Building Detail Panel that does not exist yet. |
field, default, save, panel | 04_Factory -> Power Priority System; 25_Power System Design -> §4a.6; BuildingDefinition.gd |
- | HIGH | 2026-08-29 |
| OI-321 | code | defect | Pipe basic complexity does not use a fixed flow rate, though the design says it does. 07_Pipe & Fluid System Design line 182 states "pressure simulation active in Standard and Full modes. Basic mode uses fixed flow rate." In code, PipeNetwork.simulation_tick() calls _propagate_fluid(pipe_system, true) for basic, but that function's _fixed_flow parameter is explicitly unused - its own comment says "kept for API compatibility... unused here" - so basic and standard move fluid identically at 40% of the difference, and basic differs only by skipping pressure propagation. Surfaced by a GUT test that had asserted the fixed-flow model since before 336270d and had been failing on main ever since (fixed under OI-258). Decide which is right: implement fixed flow for basic and give the parameter a job, or drop the claim from the document and delete the dead parameter. The second is likely, since pair equalisation exists precisely to stop the oscillation the old push-flow model caused, and reintroducing a fixed rate for one mode risks reintroducing it there. |
probably delete the claim, not add the feature | 07_Pipe & Fluid System Design -> Flow Rate Formula; PipeNetwork.gd -> _propagate_fluid |
- | NORMAL | 2026-08-30 |
| OI-323 | modules | defect | Two documents give the power module different names for the same mechanism. 24_Module System Design §2 and §4 call it a Power Pole that "distributes power over an area from the building roof", and 08_Research Tree Design Branch 8 follows that. 25_Power System Design §8 says it is "no longer a 'roof-mounted pole'" but "a range extender on the building's integrated transmitter, turning any building into a distribution relay without a dedicated pole", and 25_Power §4c.4 gives it a concrete +8 tiles. The mechanism agrees in both readings - the module makes a building act as a distribution point - so this is a naming and framing conflict rather than a design one, which is why it was not settled during the OI-246 audit. 24_Module is the stated authority for modules and its name was kept in the tree pending this. Decide which framing is canonical and make the other match; the roof-pole framing carries a spatial-upgrade rationale (§4, reclaimed ground) that the range-extender framing does not, and that rationale is worth keeping or consciously dropping. |
one name, and keep the spatial rationale if it survives | 24_Module System Design §2, §4; 25_Power System Design §8, §4c.4; 08_Research Tree Design Branch 8 |
- | NORMAL | 2026-08-30 |
| OI-325 | docs | defect | Three in-page anchor links point at headings that do not exist. (Was four.) 02_Technical Documents/01_Technical Architecture Document.md -> #placement-system; 03_Art & Audio/01_Art Direction Document.md -> #primary-visual-reference; 03_Art & Audio/05_Asset List & Delivery Specification.md -> #quality-checklist; ~~04_Project Management/01_Development Roadmap.md -> #what-to-do-when-youre-stuck~~ (resolved 2026-08-30 - that file and its table of contents were removed by the roadmap merge, so three remain). Each is a link to a section that was renamed or removed without updating the reference. Surfaced by the first mkdocs build as INFO rather than WARNING, so they pass even under --strict, which is now on - confirmed 2026-08-30 that these three do not fail the build and therefore need fixing deliberately rather than being caught. |
rename the anchor or the link, per case | Build output, mkdocs build |
- | NORMAL | 2026-08-30 |
| OI-329 | ui | defect | The Genesis queue card status colours are not the canonical palette, and one of them is the model the design removed. GenesisQueue.gd ships STATUS_OK = #2ADB7A (green), STATUS_WAIT = #F0C040, STATUS_ERROR = #E84848 and STATUS_IDLE = #4A9EFF. The Style Bible palette is Status Amber #F5A623 and Status Red #E8433A, so two of those are near-misses rather than the real values - close enough to look right and to survive review, far enough to be a second palette. #2ADB7A and #4A9EFF are in no palette at all. Worse, green-for-healthy is exactly what 04_Factory removed: "Earlier versions specified green for running... That is removed", replaced by healthy-is-unlit. Found while deleting the Copilot prompts that produced this code, and the prompt was more compliant than the result - 03_copilot_prompt_hud_02b_fixes.md specified cyan #2ED9E8, amber #F5A623 and red #E8433A correctly, and the implementation drifted from its own brief. The design question first: the four signal channels govern building meshes, and a HUD queue card is UI chrome, so decide whether the model extends to UI at all before repainting anything. If it does not, the palette values still apply and the near-misses are still wrong. |
decide the scope, then the values | 07_Art Direction Style Bible §1.1; 00_Canonical Design Facts §5; src/ui/hud/GenesisQueue.gd |
- | NORMAL | 2026-08-30 |
| OI-330 | docs | task | Write a short flavour description for every resource. The generated Substances page lists 19 resources as bare rows - id, substance, family, type, phase, transport - which is correct and completely dry. A one-line description per resource, in the game's voice and allowed to be silly, would make the page readable and give tooltips somewhere to draw from. Needs a field first: ResourceDefinition has no description, so this is a schema addition plus 19 strings, and scripts/build-data.js then surfaces it as a column or a sub-line on the Substances page. Keep it to one line each - the moment a description explains mechanics it duplicates the design documents and starts to drift from them. Flavour only; the tables already carry the facts. |
one line each, flavour not mechanics | 05_Reference/09_Substances.md; ResourceDefinition.gd; scripts/build-data.js |
- | NORMAL | 2026-08-30 |
| OI-331 | research | undecided | Decide whether the research tree becomes machine-readable. It is the only blocker left on full validation: two of 03_Data Pipeline §6's eight checks - recipes unlocked by no research node and win-critical recipes behind an optional branch - need the tree as data, and 08_Research Tree Design is prose. The second check matters more than it sounds. It was verified by hand on 2026-08-30 closing OI-081 and it held, but a hand check holds only until the next node moves; 25_Power System Design §8a.3 says it must never happen, which is a claim wanting a test rather than a memory. The cost is the reason this is undecided, not a task. The tree is ~90 nodes across 9 branches, and the prose carries the reasoning beside the structure - why transmission extends Branch 2, why Nuclear needs a Branch 9 prerequisite, why Efficiency is the starter module. Extracting nodes into data risks the document becoming a shell that no longer explains itself, which is the failure the vault has spent this month undoing elsewhere. A middle option exists: extract only id, branch, prerequisites, unlocks and leave every word of reasoning in place, generating nothing back into the document. |
data beside the prose, never instead of it | 03_Data Pipeline & Design Console - Plan §6a; 08_Research Tree Design; OI-081 |
- | NORMAL | 2026-08-31 |
| OI-332 | data | defect | Coal has no producer. Nothing in the game can obtain it. raw_coal.tres exists and the Coal Generator burns it at 0.5/sec - and that generator is the reference source for the entire power scale, the 100 PU everything else is a multiple of (25_Power System Design §1a.2). So the anchor of the power economy runs on a fuel the player cannot get. No building produces it: Mining Drill outputs raw_metal_ore only, and no other extraction building names it. Found by running two of the 03_Data Pipeline §6 validator checks by hand on 2026-08-31, which is the argument for OI-136 in miniature - this is invisible by reading and obvious in a graph. Decide the shape before the data: a dedicated Coal Drill, a Mining Drill that takes its output from the node it sits on, or coal as a second output of an existing extractor. The middle option is worth weighing beyond coal, since the drill currently hardcodes one resource and every future ore repeats this. Planet-side availability is OI-084. |
fix the shape, not just the row | 25_Power System Design §1a.2, §5.1; data/buildings/mining_drill.tres; data/resources/raw_coal.tres |
- | HIGH | 2026-08-31 |
| OI-334 | data | task | Recipes cannot carry a power draw, so per-recipe power is unrepresentable. power_draw and power_output live on BuildingDefinition; RecipeDefinition has inputs, output, output_amount, production_ticks and no power field at all. 29_Metallurgy & Alternate Recipes Design depends on this throughout: melt_iron must draw more than melt_copper in the same Foundry (1538 degC against 1085 degC), and leach_copper_plate is power-hungry precisely because electrowinning is the final step. None of that can be expressed today, so the design and the data disagree the moment either is written down. Decide the shape, not just the field: an absolute power_draw per recipe that overrides the building's, or a multiplier applied to it. The multiplier keeps the building meaningful and makes Mk scaling compose (25_Power System Design section 9.1); the absolute is simpler to read in a tuning table. Also affects docs/05_Reference/12_Ratio Calculator.html, which currently computes draw from the building alone. |
multiplier on the building, not a second absolute | 29_Metallurgy & Alternate Recipes Design section 4.2, 5.1; RecipeDefinition.gd; 25_Power System Design section 9.1 |
- | HIGH | 2026-09-01 |
| OI-335 | data | task | raw_metal_ore must split into one resource per metal. "Metal ore" is a generic term for every metal resource arriving as ore, not a resource in its own right (decided 2026-09-01). The data has a single raw_metal_ore with substance = iron feeding both plate and copper wire, which is why OI-336 exists. Splitting gives raw_iron_ore and raw_copper_ore, and fld_liquid_metal splits with it into fld_liquid_iron and fld_liquid_copper. This rewrites 2 of the 10 existing recipes (smelt_metal_plate, extrude_copper_wire) and ref_metal_plate becomes ref_iron_plate. 05_World Generation & Planet Types needs a read at the same time: line 147 lists guaranteed resources as "Metal Ore, Iron, Stone" and line 129 lists "Uncommon: Iron, Copper", which reads as category-plus-instance rather than two nodes, but the wording should be made unambiguous once the resources are real. Blocks the whole metallurgy layer. |
generic term, never an id | 29_Metallurgy & Alternate Recipes Design section 6; data/resources/raw_metal_ore.tres; 05_World Generation & Planet Types |
- | HIGH | 2026-09-01 |
| OI-336 | data | defect | Copper is currently made out of iron. extrude_copper_wire takes 1x raw_metal_ore (substance = iron) and outputs 2x ref_copper_wire (substance = copper), so the only source of copper in the game is the iron ore node. 04_Factory & Resource System Design line 110 already hedges this as "Metal Ore (variant)", so the intent was ore variants that were never modelled. The fix is a chain, not a row: 29_Metallurgy & Alternate Recipes Design section 5.4 replaces it with draw_copper_wire (1 copper plate -> 2 wire), which routes wire through ref_copper_plate and adds a tier to the chain: ore -> plate -> wire instead of ore -> wire. That lengthens the circuit board chain by one step, and circuit boards feed power cells, which are on the M1 ship path, so the M1 chain gets longer as a consequence. |
fix the chain, not the row | 29_Metallurgy & Alternate Recipes Design section 5.4; data/recipes/extrude_copper_wire.tres; 04_Factory & Resource System Design line 110 |
OI-335 | HIGH | 2026-09-01 |
| OI-337 | data | task | Add raw_copper_ore_low, ore that only the leach route can process. Without it cast_copper_plate (1.00 ore/plate) strictly dominates leach_copper_plate (1.50), and leaching becomes dead content the moment the player can plumb, which violates the no-strictly-better-route rule (29_Metallurgy section 2.4). Low-grade ore gives leaching a permanent niche nothing else can fill. It is also the most true-to-life part of the metals design and the least widely known: low-grade rock is exactly why hydrometallurgy was developed, because the ore is too poor to smelt economically. Building the chemical route turns previously worthless map deposits into a resource, which is a discovery rather than a number going up. Needs the world-generation pass first: the ratio between standard and low-grade ore, and the abundance multiplier on the deposits, are meaningless until deposit placement is decided. leach_copper_plate_low (6 low-grade + 1 solvent -> 2 plate) is a placeholder. Also blocked in practice by the undesigned chemical layer, which owes fld_chemical_solvent a producer. |
needs worldgen before the numbers mean anything | 29_Metallurgy & Alternate Recipes Design section 5.3; 05_World Generation & Planet Types |
OI-335 | NORMAL | 2026-09-01 |
| OI-338 | docs | defect | Every wikilink wrapped in backticks renders as literal markdown instead of a link. mkdocs-roamlinks-plugin rewrites [[X]] into [X](<path>) before the markdown renderer runs, so a wikilink inside a code span is rewritten and then displayed verbatim: the Related: header of 27_Organic Farming & Biomass Design renders as [26_Pollution, Waste & Organic Systems Design](<./26_Pollution...md>) in a grey code box rather than as a clickable link. 393 occurrences across 49 pages, measured against the built site on 2026-09-01, so it affects nearly every design document's header block. mkdocs build --strict does not catch it because the link is never emitted as a link, so there is nothing to validate. The house pattern is the cause, not a mistake in one file: every document wraps its Related: and Amends: targets in backticks, and new documents copy it. Decide once, then apply everywhere: drop the backticks so the links work, or keep them and accept the header block is decoration rather than navigation. Dropping them changes the visual weight of every header block, which is the reason this is worth a decision rather than a sweep. |
one decision, then sweep all 49 | mkdocs.yml -> plugins -> roamlinks; any 01_Design Documents header block |
- | NORMAL | 2026-09-01 |
| OI-339 | data | defect | raw_silicon is mined as elemental silicon, which does not occur in nature. The resource is named "Silicon Crystals" and comes straight out of crystal_extractor. What is actually mined is quartz or silica sand, which is silicon dioxide; the silicon has to be reduced out of it with carbon. This is not compression, it is a false claim about how the material works, which 01_Master GDD -> Teach The Real Thing forbids. Rename to raw_quartz, which also fits the existing Crystal Extractor building name better, since quartz genuinely is the crystalline form. The reduction step that produces actual silicon is designed in 29_Metallurgy section 5a.2 and arrives with OI-340. Touches refine_silicon_wafer (its only consumer today) and 04_Factory lines 66, 99 and 107. |
rename, do not add a parallel resource | 29_Metallurgy & Alternate Recipes Design section 5a.1; data/resources/raw_silicon.tres; 04_Factory & Resource System Design lines 66, 99, 107 |
- | HIGH | 2026-09-01 |
| OI-340 | data | task | Three new resources for the silicon chain: raw_sand, ref_silicon, ref_charcoal. 29_Metallurgy section 5a inserts a reduction tier that does not exist today: quartz is currently refined straight to wafer in one step, with no elemental silicon in between. ref_silicon (metallurgical grade) is the new middle tier, made by carbothermic reduction. raw_sand is the abundant low-ratio feedstock; 05_World Generation line 128 already lists Sand as Common on Terrestrial planets, so the world has it and the resource does not. ref_charcoal (char_wood: 3 wood -> 2 charcoal) is the biomass reductant, and gives raw_wood a second consumer, which today is only process_polymer. Five recipes come with them: three routes to ref_silicon, char_wood, and a rewritten refine_silicon_wafer that takes silicon plus chemical gas rather than raw quartz. Charcoal is also the natural third route for iron plate later (section 5a.3). |
needs OI-339 first, same chain | 29_Metallurgy & Alternate Recipes Design section 5a.2, 5a.3, 5a.4; 05_World Generation & Planet Types line 128 |
OI-339 | NORMAL | 2026-09-01 |
| OI-341 | data | task | Silicon smelting needs a very high per-recipe power draw, which OI-334 must land first. Carbothermic silicon reduction is among the most electricity-intensive processes in real industry, and 29_Metallurgy section 5a gives silicon that identity deliberately: copper is the chemical chain, silicon is the one that eats the grid. All three routes to ref_silicon draw heavily and refine_silicon_wafer draws more. None of it is expressible today, because the draw belongs to the Refinery rather than the recipe, so every route through the same building would cost the same power and the design's whole point would vanish. Logged separately from OI-334 so the silicon numbers are not forgotten once the field exists. |
the identity is the power cost; do not ship it flat | 29_Metallurgy & Alternate Recipes Design section 5a.2, 5a.4; OI-334 |
OI-334 | NORMAL | 2026-09-01 |
| OI-342 | data | undecided | Buildings have no construction cost, anywhere in the data or the design. BuildingDefinition carries power_draw, footprint, inventory_capacity and the rest, and no build-cost field; a search of 01_Design Documents finds no document specifying what any building costs to place. So nothing in the game consumes resources to construct a building, and the entire factory output has exactly one sink, which is ships. This surfaced from silicon (29_Metallurgy section 5a.5): real silicon splits into solar grade and electronic grade, a genuine and interesting second axis, but solar grade's natural consumer is the Solar Panel building, so it cannot exist without build costs and would ship as an orphan. Not decided here, and deliberately so. The shape is a real design question: a flat cost per building, a cost that scales with Mk, whether Genesis consumes from a stockpile or from nearby storage, and whether refunds happen on demolition. It also interacts with 15_Ship & Army Points Design, since a second sink changes what ships compete with. Blocks the two-grade silicon split and probably a lot more. |
El decides the shape; do not assume flat cost | 29_Metallurgy & Alternate Recipes Design section 5a.5; BuildingDefinition.gd; 15_Ship & Army Points Design |
- | HIGH | 2026-09-01 |
| OI-343 | data | task | The ten ship components have APR values and no recipes. Nothing makes a Laser Cannon. 15_Ship & Army Points Design specifies Laser Cannon, Pulse Cannon, Missile Launcher, Point Defence, Shield Generator, Armour Plating, Engine Thruster, Reactor Core, Hangar Bay and EMP Emitter, each with a base APR, and no source for any of them. Meanwhile 04_Factory & Resource System Design specifies cmp_drive_core, cmp_power_cell and cmp_structural_frame, which the data reports as consumed by nothing. The two lists were written in different documents and never joined: the ship layer has components with no sources, the factory layer has components with no consumers, and they are two halves of one missing bridge. This is the prerequisite for 30_Ship Construction System, which computes a ship's bill by summing its components; with no component recipes there is nothing to sum. Writing them also kills the three orphans. Some joins are close to forced already: Armour Plating against cmp_hull_plating, Reactor Core against cmp_power_cell. 2026-09-13: the bridge was found. The two lists are not two halves of one component set, they are two kinds of component: subsystems, which every ship needs and which scale with hull (the five cmp_* already in the data - frame, plating, drive, power cell, circuit board), and fittings, which are chosen in the editor and carry APR (the ten in 15_Ship & Army Points Design). That also explains why the ten have no recipes: they are Phase 2 content nobody has reached, not an oversight. ⚠️ What this row still owns is larger than it was: under the parts model discussed 2026-09-12, the five cmp_* may be the materials that ship parts are made from rather than the parts themselves, which would put an assembly step between the factory and the editor's catalogue. That is OI-388 and it must land before recipes are written, or they get written twice. |
join the two lists; do not invent a third | 30_Ship Construction System section 2; 15_Ship & Army Points Design -> Component APR Values; 04_Factory & Resource System Design -> Components |
- | HIGH | 2026-09-01 |
| OI-346 | progression | undecided | What exactly fires First Assembly. 36_Progression Arc Design §3.1 defines the beat as a machine completes a recipe with two or more distinct automated inputs, which fires very early, possibly within minutes of the tutorial ending. The stronger alternative is to require that both inputs are themselves manufactured rather than raw ore, which pushes the beat later and makes it a real I built a supply chain moment rather than I merged two belts. The trade-off is genuine: the early version rewards the player while they are still fragile, the late version rewards something that deserves it. Needs a play test, not an argument. |
El decides after the first playable | 36_Progression Arc Design section 3.1 |
- | NORMAL | 2026-09-05 |
| OI-347 | progression | undecided | The prescribed Phase 1 ship does not exist. 02_Scope & MVP Document v0.4 puts First Launch in Phase 1 as its finale, built from a single prescribed hull recipe rather than the ship editor, which stays in Phase 2. Nothing specifies what that ship is: its name, its recipe, its fuel requirement, or what the Shipyard building costs to place. It must be the hardest bill of materials in Phase 1 by a wide margin and must consume every chain the player has built, which makes it a balance object as much as a content one. Depends on OI-342, since building costs are still undecided. This is the Phase 1 ending and it currently has no content. 2026-09-13: the ship now exists as a thing, not yet as a bill. It is a Scout, which the vault had already decided - 15_Ship & Army Points Design says of that class "which is why the first ship a player ever launches is a non-combat one". What it is: the player is a command intelligence with no body who has only ever seen through things they built, so the first ship is the first time their senses leave the planet - unmanned, no cargo, no weapons, sensors and a drive. It comes back if you gave it the fuel to, which makes range a round-trip decision rather than a rule. Built from subsystems then fuelled, in two steps, which gives the launch pad a fluid line and fld_fuel its first consumer in the game. The launch costs power, drawn over a visible countdown so it can be aborted - making the finale of the release also the largest load the grid has ever carried, so First Launch and First Blackout rhyme. It is a stock blueprint, not a special-case recipe (OI-387), so the Space Update's editor can open it rather than orphaning it. Name candidates: Vantage (recommended), Longsight, Kite. Still open: the actual bill of materials and its quantities, which is what this row still owns. |
El decides; must consume every Phase 1 chain | 36_Progression Arc Design section 3.5; 02_Scope & MVP Document Phase 1 |
OI-342 | HIGH | 2026-09-05 |
| OI-348 | progression | undecided | Beat XP values are unset. 36_Progression Arc Design names five Phase 1 beats and says First Ascent and First Launch are ceremonial with the largest awards, but no numbers exist. They cannot be set until 13_Player Levelling System's curve is rebased, since the curve's own playtime estimates were written before the ladder existed. See OI-351. |
set after the curve is rebased | 36_Progression Arc Design; 13_Player Levelling System |
OI-351 | NORMAL | 2026-09-05 |
| OI-349 | progression | undecided | First Blackout needs a recovery window, or does not. The beat fires when the priority waterfall sheds a tier and the player restores full supply. Restores it within what period? An unbounded window means a player who quits, sleeps and fixes it tomorrow still earns it, which is probably right and probably harmless. A bounded window makes it a save rather than a repair. Also unclear whether repeated blackouts should re-fire anything, or whether the beat is strictly once per world. | probably unbounded; confirm | 36_Progression Arc Design section 3.3; 25_Power System Design |
- | NORMAL | 2026-09-05 |
| OI-351 | progression | defect | The level curve's playtime estimates have never been checked against anything. 13_Player Levelling System claims level 5 at 5 to 8 hours, level 25 at 80 to 120 hours and level 100 at 1,000 plus, with the note that estimates assume mixed gameplay across all XP sources. Those sources include war, combat, asteroid mining and exploration, none of which exist in Phase 1. So a Phase 1 player earns XP from a strict subset and the curve is wrong for the entire Early Access period, in an unknown direction. The beat ladder now gives real hour targets (hour 1, 10, 30, 60, 100) to rebase against. Blocks OI-348. |
rebase against the Phase 1 beat hours | 13_Player Levelling System Level Curve; 36_Progression Arc Design section 3 |
- | NORMAL | 2026-09-05 |
| OI-352 | progression | undecided | Whether the launch cinematic offers credits. 36_Progression Arc Design §3.5 suggests credits are appropriate at First Launch for a player who wants an ending, with the factory still running behind them when dismissed. Unresolved: whether declining is remembered, whether they replay, and whether a Phase 2 player sees them at all now that the launch is no longer the end of the game. Cosmetic, deferrable, worth not forgetting. |
after Phase 1 is playable | 36_Progression Arc Design section 3.5 |
- | DEFERRED | 2026-09-05 |
| OI-353 | progression | undecided | Whether a host-set production target survives as a challenge preset. The old session goals system (host sets produce X units of advanced components) is replaced by the beat ladder in 02_Scope & MVP Document v0.4. A production target may still be worth keeping as an optional challenge preset alongside sandbox and the time limit, for players who want a scored run. Nice-to-have, not progression. |
Phase 1 nice-to-have | 02_Scope & MVP Document Phase 1 Progression & Goals |
- | DEFERRED | 2026-09-05 |
| OI-356 | docs | task | Sweep the vault for the deprecated session-scoped wording. 12_Gauntlet Planet Design was found saying its wave modifiers are session-scoped, which under the vocabulary locked in 04_Data Dictionary §0 means the player loses them when they close the game. Corrected in place to world-scoped. This is the same defect fixed in 08_Research Tree Design (v0.6) and 13_Player Levelling System (v0.2), which makes three, so the remaining occurrences should be found rather than waited for. Every use of session in a design document needs reading against §0: some are correct (one sitting), most predate the lock and mean world. |
read each, do not sed it | 04_Data Dictionary section 0; 12_Gauntlet Planet Design |
- | NORMAL | 2026-09-05 |
| OI-357 | threats | undecided | The second threat family needs a name that is not Scavengers. 26_Pollution section 6 calls them scavengers, and 14_Win Conditions & Faction Allegiance calls one of the four factions The Salvagers. The two words are near-synonyms in a game where one is a trading partner met in the space layer and the other is vermin that eats your generators, so they will be confused permanently. 37_Planet Threats & Defence Design uses Ferals as a working name and marks it as such. Candidates: Ferals, Scrappers, Rakers, Chaff. Blocks nothing, but every document written before it is settled will need the word changed. |
El picks; must not be Scavengers | 37_Planet Threats & Defence Design section 6 and section 12 |
- | NORMAL | 2026-09-05 |
| OI-358 | threats | undecided | What pollution reaching their territory means numerically. 37_Planet Threats & Defence Design makes native aggression trigger on the player's air arriving where the natives live, deliberately rather than on a global pollution figure, so that the trigger is directional and visible. Unspecified: whether it is a concentration threshold measured at the zone boundary, or an accumulated level held by the zone itself, and whether it decays when the player cleans up. The second matters for whether a player can ever calm a woken zone, which is the difference between a mistake being permanent and being recoverable. 2026-09-11: the substrate now exists. 26_Pollution section 3b makes air a coarse grid with a stored amount per cell, which is what this row needed and did not have: a threshold can now be read at the zone boundary, or accumulated by the zone itself, against a real number. Section 3b.2's natural decay also answers the harder half - a cleaned-up cell genuinely falls, so a woken zone can be calmed, which this row asked the design to preserve. And section 3b.3's wind makes the trigger directional in fact rather than only on paper: a downwind zone wakes long before an equidistant upwind one. What remains is the threshold value and whether the zone's anger decays at the same rate the pollution does or slower. |
design it so a woken zone can be calmed | 37_Planet Threats & Defence Design section 5.1; 26_Pollution section 3a |
- | HIGH | 2026-09-05 |
| OI-363 | data | task | Second pass: items, buildings, recipes and flows, one at a time. El flagged 2026-09-06 that after the systems are specified the vault needs a data-layer pass going item by item, building by building, recipe by recipe, chain by chain. This is where consumption rates, per-building construction costs (OI-342), ship component recipes (OI-343), ammunition rates (OI-362) and the prescribed Phase 1 ship (OI-347) all actually get numbers. It is not a documentation pass, it is the design work that every systems document has been deferring, and several HIGH items are waiting on it. Note the existing tooling: data/buildings.json, 05_Reference/13_Recipes, 09_Substances, and the Recipe, Chain and Ratio explorer pages. |
after the systems passes; expect it to be long | data/buildings.json; 05_Reference/13_Recipes; 05_Reference/09_Substances |
OI-342, OI-343, OI-347, OI-362 | HIGH | 2026-09-06 |
| OI-365 | space | undecided | What Simulation Level does to a planet nobody is standing on. A restatement of OI-285 with new urgency. 39_Space Layer Design section 7.2: once players can settle anywhere, a remote planet must still run — drills extract, power sheds, pollution spreads, natives wake — or a second planet is a diorama. 19_Transport & Logistics section 4 already has the mechanism, a global default with per-system overrides, and a remote planet is the obvious candidate for a lower level. The document asserts one rule and leaves the rest open: whatever the fidelity, a remote planet's behaviour must be honest — a stalled chain the player finds on return must have a real cause they could have predicted, not an artefact of cheap simulation. |
honest over cheap | 39_Space Layer Design section 7.2; 19_Transport & Logistics section 4 |
OI-285 | HIGH | 2026-09-06 |
| OI-366 | space | undecided | Whether the orbital station can build hulls too large to launch from a surface. 39_Space Layer Design section 6 settles the station as repair, hangar and refuel, a service node and a consumer with its own supply problem, explicitly not a factory. Left open because it is the natural home for large-hull construction if that is ever wanted, and it would set up the Master Rill. Deciding yes would make the station a production building and change its supply requirements substantially, so it should be decided rather than drifted into. |
decide, do not drift | 39_Space Layer Design section 6 |
- | NORMAL | 2026-09-06 |
| OI-367 | power | task | The Charge Cell is a new item and needs specifying. El decided 2026-09-06 that power ships between planets, settling 25_Power System Design section 5.3 in favour of cargo over beamed power and a direct grid link. The shipped object cannot be the Accumulator: section 5.5 sets it at 500 PU.s, five seconds of a 100 PU deficit, deliberately, because it is a buffer rather than a power source — five hundred of them would deliver about fourteen minutes of a modest 300 PU site after a round trip measured in minutes. So a distinct Charge Cell is needed: bulk capacity, slow to charge, slow to discharge, useless as a grid buffer, and an ordinary solid item when charged. Needs capacity, charge and discharge rates, a shipping loss above the Accumulator's 10% (storage is a service you pay for, 25_Power System Design section 5.5), a recipe, a footprint for whatever charges it, and a decision on whether an empty cell ships back or is consumed. Name also open. Note this item gates a player choice, not just a convenience: per 39_Space Layer Design section 4a.4, importing power is how a player opts out of the ferals, so the Cell's numbers decide how expensive that opt-out is. |
keep the Accumulator untouched | 39_Space Layer Design section 4a; 25_Power System Design sections 5.3 and 5.5; 19_Transport & Logistics section 3.6 |
OI-363 | HIGH | 2026-09-06 |
| OI-369 | research | task | Branch 7 RP total needs recomputing after the Genesis amendment. 08_Research Tree Design v0.8 section 0.6 deletes four flat-percentage nodes from Branch 7 — Genesis Build Speed I and II, Bulk Mining, and Task Queue Expansion — plus the speed half of Mining Upgrade, whose unlock half survives as Genesis Multi-Resource Task. That removes roughly 475 RP of finite nodes, so the Genesis Abilities row in the RP Cost Reference and the ~32,500 RP finite tree total are both now wrong. Mechanical, but it touches a table other documents quote. |
recompute, do not estimate | 08_Research Tree Design section 0.6 and RP Cost Reference |
- | NORMAL | 2026-09-07 |
| OI-371 | genesis | undecided | How Genesis takes Mk levels and modules, given it is not a building. 40_Genesis Design section 6 decides that Genesis improves by Factory Research for verbs, upgrade kits for Mk, and modules for capacity, replacing Branch 7's percentages. Unresolved mechanics: Genesis has no ports, so Base Mk may not apply and it may have Machine Mk only, which would be a deliberate exception worth stating in Canonical section 4. Module slot count is also unresolved, since 24_Module System Design's slot table is driven by building footprint size class and Genesis has no footprint. Also open: whether Genesis mining speed relative to a Mining Drill (OI-216) should now be expressed per Mk level. |
one Mk track is probably right | 40_Genesis Design section 6 and Open Questions; 24_Module System Design section 2.2; 00_Canonical Design Facts section 4 |
OI-216 | HIGH | 2026-09-07 |
| OI-373 | space | undecided | The comms satellite needs specifying. El decided 2026-09-07 that Genesis talks to you where you are standing, and to hear a planet you are not on you build a satellite (40_Genesis Design section 7.1). With one, that planet reports: its Genesis speaks to you, its alarms reach you, and you can open its panel and queue work. Without one there is silence, and you find out what happened when you arrive. The rule is the satellite gives you the panel, not the hands — you can see and queue, but nothing that needs Genesis happens without Genesis being there. Unspecified: whether it is a building launched from the planet it covers or something the orbital station assembles; whether one covers a planet, a system, or a radius; its recipe and power draw; whether it can be lost, and what a suddenly silent planet looks like in the UI. This is what makes settling widely honestly priced — many sites means many satellites — so it is not cosmetic. |
remote awareness is paid for, never free | 40_Genesis Design section 7.1; 39_Space Layer Design sections 4.3 and 7.2; 05_World Generation & Planet Types (the Scanner, its sibling) |
- | HIGH | 2026-09-07 |
| OI-374 | genesis | undecided | How long a bot lasts on a charge, and where it recharges. 40_Genesis Design section 4.0 makes bots run on energy and Genesis not: bots are faster, Genesis never stops. When the grid sheds, the bay stops and the bots go quiet while Genesis carries on slowly, which is what turns a blackout into a construction problem and makes First Blackout felt rather than announced. The numbers decide how bad a blackout gets. Too long a charge and the blackout is invisible; too short and every brownout halts construction. Also unresolved: whether bots recharge at the bay only or in the field, and whether a bot caught away from the bay on a dead grid is stranded or crawls home. Interacts with 25_Power System Design's shedding priorities — the bay's priority tier is itself a player decision. |
the blackout must be felt, not fatal | 40_Genesis Design section 4.0; 25_Power System Design; 36_Progression Arc Design section 3.3 |
OI-363 | HIGH | 2026-09-07 |
| OI-379 | trains | undecided | Whether a tank wagon can carry gas. 41_Fluid Packaging & Carriage Design v0.2 gives the tank wagon liquids and leaves gas open. A gas wagon is a pressure vessel on bogies, not a tank, so it is a different object with a different failure mode rather than a variant. It may not be needed at all: gases ride as cylinders, cylinders are ordinary items, and ordinary items already ride in ordinary wagons, so the question is whether moving gas as gas over rail buys anything the cylinder does not. Not needed before the Space Update, since Phase 1 has no gas. |
cylinders may already be answer enough | 41_Fluid Packaging & Carriage Design section 4 and Open Questions; 22_Trains & Rail section 4.2a |
- | LOW | 2026-09-11 |
| OI-380 | pollution | undecided | The pollution grid numbers. 26_Pollution section 3b settles the model and none of the values. Needed: cell size (coarse enough that a district spans a handful of cells, per section 3b), tick rate, diffusion fraction per tick, natural decay per cell, per-building emission rates with their falloff radius, wind strength as a bias on diffusion, and the sink rates for trees, Soil Remediation and Air Scrubbers. ⚠️ The decay and the emission rates are one decision, not two: together they set where equilibrium sits, and therefore how big a factory can be before anything stirs (section 3b.2). Setting them separately is how the first hour accidentally becomes punishing. Belongs to the data pass (OI-363). |
decay and emission are one number in two halves | 26_Pollution section 3b; 06_Tuning Values |
OI-363 | HIGH | 2026-09-11 |
| OI-382 | research | task | Cylinder rungs need research nodes, and none exist. 41_Fluid Packaging & Carriage Design v0.2 tiers containers by research (Cylinder, Reinforced Cylinder, Cryogenic Cylinder) and the tree has no container nodes at all - the word barrel does not appear in 08_Research Tree Design. Not urgent and not free: cylinders carry gas, Phase 1 has no gas, so nothing is blocked before the Space Update. But 08_Research Tree Design §0.5 holds the rule that no building is ever a research unlock at a higher tier, and containers are items rather than buildings, so the tree needs to be able to express an item ladder without reintroducing the pattern that rule exists to forbid. Decide that shape before the Space Update branch is written, not during. |
an item ladder, not a building tier | 41_Fluid Packaging & Carriage Design section 2.2; 08_Research Tree Design section 0.5 |
- | NORMAL | 2026-09-11 |
| OI-383 | ui | task | 10_Tutorial & Onboarding Design needs a full revisit, deliberately deferred. It predates threats, pollution as a grid, wind, Genesis-per-player, power shedding and every beat in 36_Progression Arc Design. Revisiting it now would mean rewriting it again once the data pass (OI-363) settles what the first hour actually contains. v0.2 records the position the revisit should start from - the tutorial teaches the hand, primers teach the game - so the eleven steps to a working chain stay and everything after is a primer. What the revisit still owes: whether Step 0's wake-up still reads correctly now that Genesis has a voice and a satellite range, and whether any of the eleven steps changed under the port and module work. |
do it after the data pass, not before | 10_Tutorial & Onboarding Design section The tutorial stops here on purpose |
OI-363 | NORMAL | 2026-09-11 |
| OI-384 | audio | task | Build the Genesis vocalisation library. 18_Notifications v0.2 section 3 decides what it is (non-verbal, keyed to tier and category, spatialised, throttled, never sound-only) and nothing about what it sounds like. Needed: the category set (curious, affirm, alert, alarm, sad, pleased at minimum), how many variations each carries before repetition becomes grating, and the throttle window. ⚠️ The throttle is the risky number, not the sounds. Too loose and a charming companion becomes a smoke alarm, which is the failure mode that makes players mute audio permanently and lose every other cue with it. |
the throttle matters more than the timbre | 18_Notifications sections 3 and 3.2; 03_Art & Audio |
- | NORMAL | 2026-09-11 |
| OI-385 | ui | undecided | Whether a guest joining mid-session sees any acknowledgement of beats already fired. 36_Progression Arc Design section 7a raises it and leaves it open; 18_Notifications v0.2 section 7.2 inherits it rather than deciding it. The constraint is fixed: a beat fires once per world and a late guest earns nothing retroactively, because the ladder measures what a world has done. Open is whether they see what the world has done - a line in the world summary is the suggestion, and an award is explicitly not. Small, but it is the difference between a guest understanding where they have arrived and a guest wondering why the host has a launch pad. |
show the history, award nothing | 36_Progression Arc Design section 7a; 18_Notifications section 7.2 |
- | LOW | 2026-09-11 |
| OI-387 | ships | task | Specify the stock blueprints, starting with the Scout. Decided 2026-09-13 that the prescribed Launch release ship is a stock blueprint rather than a one-off recipe: a design shipped with the game, made of the same parts and wired the same way a player's would be. Why it matters beyond tidiness: a one-off recipe gets orphaned the moment the editor lands in the Space Update, while a stock blueprint can be opened, examined and improved on, which is a good first ten seconds for that release. Needs: one stock design per hull so a player who never wants to design anything can still build ships, and a decision on whether the Scout ships pre-wired and locked in the Launch release. | stock designs, not special cases | 30_Ship Construction System; 34_Ship & Mothership Editor Design |
OI-386 | NORMAL | 2026-09-13 |
| OI-388 | ships | undecided | Are the five cmp_* the ship parts, or what ship parts are made from? Discussed 2026-09-13 and deliberately left open because it decides how much content the editor is. A: they are the parts, fitted directly - everything exists today, but mix and match reduces to choosing how many drive cores, which is a slider rather than a decision. B: they are materials, and a second step assembles them into parts the editor fits - Engine, Reactor, Fuel Tank, Cargo Hold, Sensor Array, Heat Shield. B costs an assembly layer and buys the thing the editor exists for: a Cargo Hold and a Fuel Tank are visibly different objects doing different jobs, both made from the same plating and frames, so the factory stays general and the Shipyard is where generality becomes purpose. ⚠️ Blocks OI-343: component recipes written before this lands get written twice. |
B unless the content cost is unaffordable | 34_Ship & Mothership Editor Design -> The Component Catalogue; 04_Factory & Resource System Design |
- | HIGH | 2026-09-13 |
| OI-389 | ships | undecided | What a ship wreck actually yields, and who can reach it. 30_Ship Construction System §13 settles the shape - a lossy subset of the salvageable parts, no per-part condition tracking - and none of the numbers. Needed: the survival proportion, whether it varies by what destroyed the ship, how long a wreck persists, whether it is visible on the map before being scanned, and the Salvage Module's working rate. ⚠️ The proportion is bounded on both sides: high enough that recovery is worth a trip, and low enough that it never approaches decommissioning, which returns everything salvageable with no travel at all. |
worth the trip, never better than a decom | 30_Ship Construction System section 13; 34_Ship & Mothership Editor Design -> Role components |
- | NORMAL | 2026-09-13 |
| OI-390 | lore | defect | 01_World Bible still describes aliens as organic creatures. It specifies the Gravel Crawlers ("low-slung, many-legged") and Spore Drifters ("floating, plant-like organisms" releasing spore clouds), and frames the whole Alien Species section around ecosystems and creature behaviour. 37_Planet Threats & Defence Design decided in September that both threat families are machines - Natives drawn by pollution, Ferals drawn by power signature and e-waste. The World Bible is dated 2026-02-22 and has not been touched since. Not fixed in passing: it is the lore source of truth, it also carries the factions, the crash and the player's nature, and rewriting its threat section is a narrative conversation rather than a find-and-replace. |
machines, and the lore has to mean it | 01_World Bible -> Alien Species; 37_Planet Threats & Defence Design |
- | NORMAL | 2026-09-13 |
| OI-393 | ships | undecided | Whether a mothership may be commissioned anywhere, or only in the player's own world. 34_Ship & Mothership Editor Design v0.6 records own world only as the working answer and the reason: otherwise a high-level guest can spend a host's materials on a hull the host cannot build, which is account progress arriving as capability inside somebody else's factory - the exact thing 36_Progression Arc Design section 7 exists to prevent, arriving through a side door. It also reads correctly in fiction, since the mothership is the player's home base that flies. Left open because it has a real co-op cost: a player helping a friend for an evening cannot start their own mothership there, and must go home to do it. Decide whether that friction is wanted. |
own world, unless the co-op cost is judged too high | 34_Ship & Mothership Editor Design -> Two Gates; 36_Progression Arc Design section 7.3 |
- | NORMAL | 2026-09-15 |
| OI-394 | ships | task | 15_Ship & Army Points Design needs a pass: its class table is now a stat block for objects that do not exist. 34_Ship & Mothership Editor Design v0.7 establishes nothing is declared, everything is derived — only the envelope and the parts are authored, and everything a player reads is computed from those plus what is inside. That makes two columns of that document's class table obsolete: the APR weight column (Fighter weapons x1.5, Carrier hangars x2.0) and the Factory Supply Cost column (Low / Medium / High), both declared per class, where classes are now stock blueprints rather than objects. El's direction: APR weighting should derive from hull size, shape, and what is fitted - a small flat hull is agile so weapons weight higher, a deep hull protects so armour does. ⚠️ Phase 2, so it can wait, but it must not be skipped: leaving a declared table beside a derived model is how the two quietly disagree. |
derive from geometry, delete the table | 15_Ship & Army Points Design -> Ship Classes and APR Calculation; 34_Ship & Mothership Editor Design -> Nothing Is Declared |
- | NORMAL | 2026-09-20 |
| OI-395 | data | task | Add mass to resources, separate from unit_size. 34_Ship & Mothership Editor Design v0.7 makes cargo mass part of a ship's total mass, so a hold of ore and a hold of circuit boards are not the same ship. ⚠️ mass is not unit_size: Canonical section 12a already has unit_size for Silo capacity, and a barrel of foam and a barrel of lead occupy the same space at very different weights. Conflating them is the one-word-two-jobs error. What it buys is a player discovery rather than a lesson: refine at the mine and ship the refined thing, because ore costs fuel - which compounds with 39_Space Layer Design section 6a.2, where the expensive leg is the lift. Values belong to the data pass; the property belongs now, before recipes are written against a model that lacks it. |
a separate property, decided before the data pass | 34_Ship & Mothership Editor Design -> Mass; ResourceDefinition.gd; 00_Canonical Design Facts section 12a |
OI-363 | HIGH | 2026-09-20 |
| OI-396 | space | undecided | The lift numbers, and whether the Space Elevator is Phase 1 or Phase 2. 39_Space Layer Design section 6a settles the shape - Mass Driver up, Drop Pod Bay down, Space Elevator as a later upgrade - and none of the values. Needed: the Mass Driver's power draw per unit lifted and its batch size, the Drop Pod Bay's pod cost and whether pods are recoverable, and the Elevator's capital cost against its per-unit saving. ⚠️ The power draw is the load-bearing number: it is what makes refine before you lift obvious rather than merely true, and too low a value deletes the whole asymmetry. Also open is which release the Elevator lands in - it is a natural late-Space-Update reward, but it could equally sit with the war economy. |
the power draw carries the lesson | 39_Space Layer Design section 6a; 06_Tuning Values |
OI-363 | HIGH | 2026-09-20 |
| OI-397 | trains | task | Rail cargo weight at Simulation Levels 2 and 3, with a hard guard rail. Decided 2026-09-20: level 1 ignores load, levels 2 and 3 make a loaded locomotive burn more fuel. ⚠️ It sits close to Canonical section 24, which forbids a Simulation Level from changing what is optimal. The rule written alongside it: cargo weight may scale fuel consumption, and must never be large enough to change which carrier a player picks. If loaded weight made rail uncompetitive against belts for heavy low-value cargo, it would be a balance change and section 24 would require it to ship for everyone - the verdict wind received. This row owns proving that the numbers stay inside the guard rail, which cannot be checked until the data pass gives rail and belts real throughputs. | fidelity, never a carrier decision | 19_Transport & Logistics section 4; 00_Canonical Design Facts section 24; 22_Trains & Rail |
OI-363 | NORMAL | 2026-09-20 |