# From the complete reference to future development

## C08-BUILD-01 — The reference is ready to plan from; game work remains separate

This programme authorizes creative documentation, reference presentation, diagrams, concept artwork and development-planning records. It does not authorize mod implementation or game-ready asset production. The future backlog below explains useful units and their evidence requirements so that an explicit game BUILD can start from a concrete proposal. It does not schedule releases, change the accepted game sequence or claim that the documented systems already exist.

The recorded game authority remains a0a702c2b5788d099645ab55ad23d8a5bf45c137; the launcher authority remains e2a7137a53a1737166158d8dee59ca2137d2d64c. At that game baseline, Smelt is unbuilt. Any future implementation assignment should first inspect the relevant current game branch and accepted later handoffs. A creative-source commit and a public Website commit do not establish a new game state.

The useful unit of development is a player outcome with bounded dependencies. 'All machines' is too broad to verify. 'One ordinary material becomes a fitting, improves a real cargo route and survives a saved interruption without duplication' is concrete. The broad catalogue can then grow through units that reuse a proven foundation while adding a distinct capability.

## C08-BUILD-02 — Evidence levels and honest completion

| Evidence level | What it can establish | What it cannot establish alone |
| --- | --- | --- |
| Creative source and recorded user decision | Intended experience, identities, boundaries and selected direction | Runtime availability, numerical balance or model fit |
| Reviewed illustration or editable diagram | Visual identity, composition and explicitly shown functional relationships | Collision, pressure integrity, inventory capacity or animation correctness |
| Source checks and reproducible reader build | Preservation, parseable records, correct links, assets and repeatable documentation output | Native gameplay or successful public deployment |
| Local browser interaction and accessibility checks | Behavior and presentation exercised in the named browser, viewport and revision | Other browsers, independent usability judgment or game behavior |
| Native implementation and focused automated tests | The tested rules, data accounting and failure handling in the pinned game build | A satisfying complete experience or broad balance without play evidence |
| Play sessions, seed corpus and measured asset studies | The actual travel, interaction, fit, accessibility and cost questions exercised | Unobserved seeds, future versions or automatic universal balance |
| Production Website checks | The exact published resources and interactions verified at a deployed revision | Game implementation or later record-only revisions without their own evidence |

A report must name its execution, environment and revision. Historical successful Website checks remain useful evidence of that incorporation; they do not become fresh maintainer checks. The historical maintainer browser/download failure remains recorded separately. A source verifier that does not exercise a browser reports that browser interaction is outside the verifier and NOT RUN, rather than replaying an old environmental explanation.

## C08-BUILD-03 — Dependency structure without a release promise

The implementation graph starts with the currently approved game work, then proves a small material-to-use loop, a dependable world route and the first workshop duty. Shared contracts for actual inventory, interruption, typed services, readable state and persistent local identity support later systems. They should be introduced when a concrete player unit needs them, with the smallest coherent scope that can be tested.

Earth expansion, living systems and industrial branches can then grow from those foundations. A first complete space loop requires the chosen vehicle representation, separate service duties, a supported arrival/refuge and an independent return. It does not require every Earth experience, all 66 machines or the entire settlement simulation. Moon, Mars and each farther campaign receive their own end-to-end unit before optional regional depth multiplies.

| Build family | Prerequisite relationship | First useful boundary | Expansion after evidence |
| --- | --- | --- | --- |
| Existing game work | Inspect and preserve the accepted game sequence | Complete the already-approved next unit, including Smelt when authorized | Reconcile actual results into a later reference receipt |
| Opening material and route loop | Compatible stock, one work method and actual receiving storage | A repaired fitting or cargo duty used on a real route | Additional recipes and distinct route improvements |
| Workshop order and service foundation | One eligible process and its actual inventory states | Start, pause, resume, complete and safely block one accountable order | More machine families, services and configurations |
| Earth journey and living place | Reachable generation, field preparation and persistent storage | One complete outing plus a useful homecoming | Distinct regions, ecology and settlement projects |
| First space expedition | Selected transport representation, separate services and a tested refuge | Earth preparation to Moon activity and return with the same craft | Lunar depth, further applications and repeat visits |
| Mars campaign | Interplanetary configuration, route knowledge and field service | One supported regional expedition with imported first supplies | Brine/Rootstone investigation and chosen yard growth |
| Outer campaigns | Their stated earlier-route preparation and service foundation | One distinct destination's three-outing loop and signature project | Optional mastery, variants and local production |
| Proposed Beyond Sol | A satisfying Solar conclusion and explicitly selected continuation | Bounded Cairn navigation and independent return | Morrow's chosen local living project |

No line in this table requires a new monolithic engine framework before useful play. A technical abstraction earns its place by serving a demonstrated repeated need. Conversely, a shortcut that cannot preserve actual stock or supported recovery should not become the foundation for dozens of later machines.

## C08-BUILD-04 — The standard future build brief

Each structured build record names the player outcome, source identities, dependencies, included behavior, exclusions, acceptance criteria, risks and validation evidence. An implementation agent should use the referenced creative text to understand the purpose, then inspect the current game authority and propose the concrete code and asset boundary. It must not silently treat every recommendation in a concept chapter as a confirmed engineering choice.

Acceptance criteria should observe the outcome. For example: the hoist carries the actual cargo between declared fixed landings; an occupied landing prevents the next movement with a readable reason; unloading transfers the same items once; save and reload preserve the stated load and position; the player can use the resulting route improvement. 'Hoist class exists' is an implementation detail, not a complete player criterion.

Risks should name the uncertainty and the evidence that resolves it. If a rover route might not fit generated turns, require a measured turning envelope and seed routes tested with the actual vehicle. If a recipe may make an optional destination compulsory, require a full preparation-path comparison. If a screen may overload the player, require a task-based review at the supported scale and input modes.

The structured briefs in the campaign, industry/equipment and living-experience registers extend this standard to their full scopes. This chapter supplies the shared contracts and integration order. Together they form a planning handoff, not pre-created promises of a particular release date or staffing plan.

## C08-BUILD-05 — Validate materials through the whole useful chain

Material equivalence is an explicit unresolved integration question. A familiar name in the creative document does not prove that the current mod has the matching item, tag, recipe or physical behavior. The first implementation of a chain should identify the actual source item, accepted substitutes, preparation method, intermediate form, receiving container and final use. A mapping table belongs with the code or implementation record before the reference starts making implemented claims.

Balance requires observing the whole duty. Gathering, carrying, fuel preparation, machine access, service, waiting, byproduct storage and the value of the result all contribute. A recipe that looks inexpensive in isolation can be burdensome through travel; an apparently costly component can be trivial if a process creates it while doing unrelated work. Proposed starting values are useful test inputs, not evidence that the system is balanced.

The validation plan should compare at least a compact earlier method and the proposed improved method under the same intended outcome. Record what changes: preparation effort, active interactions, space, service needs, accessible resources, risk and repeatability. Explain why the player would choose each. Late material applications should improve a named duty and preserve a supported earlier option where the campaign promises optionality.

## C08-BUILD-06 — Validate physical fit and transport with the actual representation

The Explorer fit question remains consequential. A complete study uses the actual player and suit, camera modes, entry interaction, occupied cabin, cargo representation, service approach and animation envelope. The compact-first dimensions remain a candidate until those views and interactions work together. If the representation cannot fit, the decision record should compare the smallest coherent remedies without silently altering the confirmed external identity.

The same discipline applies to Tier 2/3 and HUL01–HUL06, support vehicles and carrier arrangements. A visible bay or seam does not prove transport, separation or seating. Each selected configuration needs an explicit statement of what moves together, what remains fixed, where the player is during travel and how custody transfers at a handoff. Concept studies can make the intended relationships reviewable while leaving implementation choice qualified.

An initial native prototype should prove one supported travel loop before broadening configurations. Boarding and disembarking, interruption, save/reload, destination arrival, docking where included, service connections and the actual return must be tested. Seamless flight, arbitrary moving player-built structures, orbital physics and multiplayer seating are not default promises in this reference.

## C08-BUILD-07 — Validate generation through solvable relationships

Seed checks should verify more than block counts. They should observe whether the player can reach the first work site, recognize the intended landmark, occupy the interaction position, carry the expected equipment and retreat using the supported route. A generator can satisfy a nominal region placement while leaving its only useful face buried or its vehicle turn impossible.

The seed corpus should include ordinary cases, boundary cases and deliberately adverse combinations relevant to the unit under development. Keep the exact seed, version, configuration and observed route with the result. Where a validator repairs or rejects a placement, record the reason. Do not claim universal validity from a small attractive screenshot selection.

A campaign's critical invariant is the relationship among arrival, support, observation, activity and return. Optional branches can vary more widely. Later world-generation changes need a save/migration decision: preserve existing sites, identify newly generated areas and avoid silently invalidating a player's commissioned refuge or stored route. The full migration design belongs to the authorized implementation, but the need is part of this handoff.

## C08-BUILD-08 — Validate interfaces with complete tasks

The interface direction defines common information hierarchy: identify the object or place, show the current state, explain the blocked reason, make the next useful action available and distinguish actual stock from planned allocation. A machinery screen should help the player complete a duty without forcing them to memorize the entire industrial catalogue. An expedition screen should show where essential stock physically resides.

Test complete tasks such as preparing a field kit, diagnosing a blocked receiver, preserving a specimen while allocating process stock, retreating from a changed route and returning to the same workshop. Observe whether the player can understand the result through text, shape, position and optional sound, without relying solely on colour. Accessibility settings should improve that same task rather than existing as disconnected menu entries.

The reference reader's own browser and accessibility checks are a separate documentation gate. They verify navigation, source links, search, notes, image viewing, spoilers, comparison controls, print and responsive presentation in the named environment. They do not establish that the future game interface is usable or implemented.

## C08-BUILD-09 — A small set of consequential unresolved choices

Most editorial and concept choices can be completed within the accepted direction. The remaining consequential issues are questions that require actual implementation evidence or an explicit change to canon. They should have a recommended next action and a bounded decision point, rather than appearing as vague permanent placeholders.

| Open issue | Working direction | Evidence or decision required | What remains possible now |
| --- | --- | --- | --- |
| Explorer cabin, entry and occupied fit | Preserve the compact-first identity while testing the complete player/suit/camera duty | Measured native fit study, then choose the smallest coherent remedy if necessary | Complete reference components, service logic, concepts and future tests |
| Vehicle transport and carrier arrangements | Support only explicitly selected configurations; retain independent return | Native representation and custody prototype for each included arrangement | Operational state and connection documentation with honest qualifications |
| Recipes, rates, capacities and material equivalence | Use stated starting proposals only as test inputs; preserve viable earlier alternatives | Actual item/tag mapping, chain comparisons and observed play duties | Complete intended operations, process relationships and balance rationale |
| Numerical environment and hazard behavior | Preserve readable local warning, counterplay and return relationships | Seed corpus and controlled play tests using the implemented traversal and equipment | Full campaign and generation contracts without invented tuned values |
| CEC01 Mars ecology | Remain conditional and unselected | User selection before including it as canon or implementation scope | Complete geological Mars and its existing non-ecological outcomes |
| Proposed Afterlight continuation | Preserve Cairn/Morrow as the finite proposed continuation with a Solar stopping point | Explicit future build selection after the earlier game earns it | Complete creative reference, spoiler-controlled reading and concept direction |

This table does not ask the user to reconfirm the whole programme. It protects a few real decision boundaries. A later discovery that would materially alter an approved asset identity, roster or product direction should be presented with concrete options and evidence at that point.

## C08-BUILD-10 — What remains after reference completion

The completed reference is the creative and planning source. Its remaining categories are future game implementation, game-ready asset production, technical validation, genuinely conditional content and the Website agent's manual incorporation. These categories are different from unwritten required chapters or unexplained illustration placeholders.

Future implementation turns the described loops into playable behavior under an explicit BUILD. Production assets translate the reviewed concepts into measured models, textures, animations, audio and native UI. Technical validation resolves fit, balance, generation, performance and platform questions with actual evidence. Conditional content remains available as a documented option without being presented as selected. Website incorporation adapts this exact source edition into its public Reference, Worlds, Systems and roadmap explanations while preserving truthful maturity labels.

The handoff identifies exact commits and paths. A source snapshot, a delivery record, a tested Website revision, a deployed product revision and a later report-only commit each have their own role. The source maintainer records the returned Website incorporation additively. No automatic synchronization, release promise or deployment claim is inferred from the presence of files.

# Maintaining and reviewing the complete reference

## C08-REF-01 — Read by question, then follow the whole relationship

The reader provides current subject entrances for the journey, worlds, workshop, equipment, living places, spacecraft, player experience and future build planning. Each entrance leads to the new connected explanation and the relevant preserved detailed sources. Search includes prose and stable identifiers so that a question about PM04, IND-M53 or a named region can reach its actual context.

Persistent navigation shows the current chapter and section and keeps useful movement controls available while scrolling. A mobile contents control, keyboard access, direct fragments and the existing review notes support the same document. A comparison should help the reader judge a real choice, such as a compact versus regional workshop or an optional versus principal route; it should not require the reader to reconstruct the comparison from unrelated pages.

The visual catalogue opens the complete source context and unchanged original or editable graphic. A caption identifies the image's job, source identities, review status and limits. Later-story material uses explicit reveal controls. Search or a direct link into that material should retain a clear spoiler boundary while allowing the user to choose to continue.

## C08-REF-02 — Rebuild from sources without reconstructing the prose

The edition keeps the canonical narrative files, structured registers, exact earlier reader, images, diagrams, configuration and build instructions together. The builder assembles the current reader from those sources while checking preserved source blocks and identifiers. Repeated counts, inventories and handoff fields are generated from the same records, reducing disagreement between the document and its receipt.

Editorial judgment remains human-readable and explicit. A manifest can prove that a file is present and unchanged; it cannot decide that a scene adequately covers a region or that a machine drawing communicates its operating state. The visual register therefore records substantive review alongside file integrity. The coverage register distinguishes the purpose actually served from technical work that remains unverified.

Future agents can propose corrections or extensions through isolated reports and structured data in the repository. The maintainer reconciles those reports, preserves the accepted baseline and builds an additive edition. An available branch is not automatically accepted or deployed. Manual synchronization remains the working model.

## C08-REF-03 — Changelog, preservation and review states

The changelog records meaningful additions, corrections, supersessions and open questions. Earlier records retain their original date and result. A later successful Website check is appended with its own evidence rather than replacing a maintainer's failed historical attempt. The SRC07-F01 correction remains a metadata correction to how fresh source-verifier records describe their own scope; it does not invalidate the 21 historical source checks or reopen creative content.

The user's endorsement of existing published homepage, Worlds and Systems visuals is recorded as an additive aesthetic approval against the captured source revision. REF03 and CD05-A03 remain central art authorities. Earlier functional-study and selected-candidate labels remain part of their history, while the new endorsement is visible separately. None of these aesthetic approvals resolves physical fit, numerical specification or implementation maturity.

New generated selections receive a maintainer review and a candid candidate status. Rejected or superseded attempts keep their provenance and reason. The absence of a fixed generation cap allows adequate coverage; it does not make every generated result automatically suitable or approved. The reference should improve through deliberate selection rather than by accumulating indistinguishable pictures.