moonmoon

MoonBit-native lunar world model for measured terrain evidence, mission constraints, and robot-facing MoonSuite boundaries.

moonbit
lunar
terrain
mission-planning
robotics
moon add vectie/moonmoon@0.1.0
Download zip
Author
Version
0.1.0
License
Apache-2.0
Last updated
14 days ago
Downloads
2

Dependencies

README

#MoonMoon

Domain product · digital simulation alpha. Read the product contract for evidence claims, the MoonRobo boundary, capability status and release gates.

MoonMoon is a MoonBit-native lunar terrain and mission model.

The project is intentionally small: source data lives under data/, domain logic lives under src/, and the root package is only a facade. Generated Markdown, JSON, HTML, screenshots, and future build products should not be committed as source.

#Shape

  • src/core: common lunar coordinates, provenance, uncertainty, and source claim types.
  • src/data_core, src/data_store, src/data_validate: generic data refs, local data-root persistence, and data-root validation.
  • src/lunar_data, src/lunar_catalog, src/site_catalog: lunar source records, catalog materialization, and catalog-backed first-site evidence.
  • src/robot_data, src/robot_catalog: pure robot episode/model/signal/replay/telemetry/gait contracts and the robot data-root materialization adapter.
  • src/terrain: terrain source manifests, checked DEM fixtures, grid analysis, slope, roughness, and hazard classification.
  • src/mission: traverse scoring, corridor ranking, horizon evidence, terrain remediation, energy assessment, and route clearance.
  • src/site: the assembled first trusted square dossier.
  • src/ui: renderer-neutral view models plus a standalone MoonBit-rendered HTML inspection page.
  • ui/rabbita-moon: Rabbita-native app for the live 3D terrain view, built as relative static assets for browser or Lepusa packaging.
  • lepusa.json: least-privilege static desktop manifest; domain and UI behavior remain in MoonBit and Rabbita.
  • src/kernel: the compact product kernel, evidence gates, and near-term build queue.
  • cmd/main: the native CLI.

#Docs

#Run

moon run cmd/main moon run cmd/main -- json moon run cmd/main -- kernel moon run cmd/main -- terrain moon run cmd/main -- mission horizon moon run cmd/main -- mission terrain moon run cmd/main -- mission energy moon run cmd/main -- robot-mission simulate <design-json> <moonmoon-root> <output-json> moon run cmd/main -- data root-json target/data-roots/first-trusted-square moon run cmd/main -- data ingest-first-site target/data-roots/first-trusted-square moon run cmd/main -- data ingest-first-site target/data-roots/first-trusted-square json moon run cmd/main -- data site-json target/data-roots/first-trusted-square moon run cmd/main -- data ui-json target/data-roots/first-trusted-square moon run cmd/main -- data ui-html target/data-roots/first-trusted-square moon run cmd/main -- data robot-json target/robot-catalog-tests/episode-directory-import moon run cmd/main -- data robot-readiness-json target/robot-catalog-tests/episode-directory-import moon run cmd/main -- data ingest-robot-telemetry target/data-roots/robot-telemetry data/robot_telemetry/input telemetry-alpha robot-alpha session-alpha moon run cmd/main -- data robot-telemetry-json target/data-roots/robot-telemetry telemetry-alpha moon run cmd/main -- ui moon run cmd/main -- ui json moon run cmd/main -- ui html moon run cmd/moonflow_adapter -- capability moon run cmd/moonflow_adapter -- declaration

#Bound robot mission simulation

robot-mission simulate requires a typed moonsuite.robot-design.v1 mission that binds the MoonRobo robot/revision, staged robot.json, URDF, accepted validation receipt, simulation bridge, and their SHA-256 identities. All staged paths must remain relative to the supplied MoonMoon root. MoonMoon inspects the profile, URDF identity, accepted simulation-only receipt, and disabled physical bridge before a scenario can be accepted.

Every scenario records an ID, positive deterministic seed, kind, and injected faults. A qualified moonmoon.digital-twin-calibration.v1 input supplies the testbed/source references, uncertainty, severity, observability, retained performance, energy multiplier, and recovery action for each modeled fault. The simulator records normal -> degraded -> diagnosis -> recovery-attempt transitions and distinguishes recovered, reduced-mission, safe-return, and fail-closed outcomes. Unknown or invalidly calibrated faults still fail closed. Identical inputs produce byte-equivalent receipts.

An accepted result may claim calibrated-digital-twin only when its calibration is qualified and referenced. This remains bounded digital evidence for the enumerated terrain path; physical_readiness is always false. It preserves broader-terrain blockers and explicitly does not establish slip, sinkage, localization, dust, thermal-vacuum, manufacturing, launch, landing, or physical lunar readiness.

The product-owned pack.json exposes the simulation as moonmoon/simulation.robot-mission@0.1.0 and exposes independent result inspection as moonmoon/simulation.mission-result.inspect@0.1.0. The moonflow.adapter.v2 runtime consumes serialized workspace artifacts, persists replay, provenance, evaluation and attempt receipts, and supports restart reconciliation. It never loads a sibling MoonRobo source checkout.

Robot episode imports read top-level text payloads as signal frames. Optional replays/ and quality/ subdirectories are staged as replay and quality evidence in the same episode dataset.

Robot telemetry imports are a separate data-root boundary. They create robot-telemetry-stream datasets instead of hiding streams inside episode frames.

The catalog-backed UI commands read the same validated first-site data root as data site-json, so source labels and catalog manifest paths can come from the materialized root instead of static product defaults.

Run the live browser view through Rabbita, not through generated output/ artifacts:

cd ui/rabbita-moon npm install npm run dev

Open http://127.0.0.1:8766/first_trusted_square.html.

The production build uses relative asset URLs so the same Rabbita output works inside lepusa://packaged/main/:

cd ui/rabbita-moon npm run build

The desktop release boundary is defined by lepusa.json. See docs/UI_RELEASE_READINESS.md for the strict Lepusa verification, DMG, installed-copy UI run, checksum, and signing limitations.

#Develop

moon check moon test moon info moon fmt

moon info updates generated .mbti interfaces. Review those diffs as the public API signal.

The product-home layout contract is covered by MoonBit tests in moonmoon_test.mbt; keep root-level shell smoke scripts out of the core development loop unless they guard a true external data or build boundary.

#Product Rule

MoonMoon owns lunar world claims. It may later export evidence to other Moon suite products, but those adapters should be explicit boundary packages or separate tools. The core repository should stay MoonBit-first and should not grow around Python check scripts, committed output/ trees, generated browser asset bundles, or compatibility launch paths.

#
MoonMoonMoonSuiteProductHome

pub(all) struct MoonMoonMoonSuiteProductHome {
product_id : String
state_path : String
service_path : String
cache_path : String
tmp_path : String
accepted_output_path : String
} derive(Eq, ToJson,
Debug
,
FromJson
)

#
ingest_moonmold_simulation

#
moonflow_adapter_capability_json

fn moonflow_adapter_capability_json() -> Json

Describe MoonMoon's product-owned MoonFlow adapter boundary. Actual execution is provided by src/mission_adapter; this root facade deliberately exposes only the portable capability description.

#
moonsuite_product_accepted_output_path

fn moonsuite_product_accepted_output_path(book_id? : String) -> String

#
moonsuite_product_accepted_output_path_for_workspace_root

fn moonsuite_product_accepted_output_path_for_workspace_root(root : String, book_id? : String) -> String

#
moonsuite_product_cache_path

fn moonsuite_product_cache_path() -> String

#
moonsuite_product_cache_path_for_workspace_root

fn moonsuite_product_cache_path_for_workspace_root(root : String) -> String

#
moonsuite_product_home

fn moonsuite_product_home(book_id? : String) -> MoonMoonMoonSuiteProductHome

#
moonsuite_product_home_for_workspace_root

fn moonsuite_product_home_for_workspace_root(root : String, book_id? : String) -> MoonMoonMoonSuiteProductHome

#
moonsuite_product_id

fn moonsuite_product_id() -> String

#
moonsuite_product_service_path

fn moonsuite_product_service_path() -> String

#
moonsuite_product_service_path_for_workspace_root

fn moonsuite_product_service_path_for_workspace_root(root : String) -> String

#
moonsuite_product_state_path

fn moonsuite_product_state_path() -> String

#
moonsuite_product_state_path_for_workspace_root

fn moonsuite_product_state_path_for_workspace_root(root : String) -> String

#
moonsuite_product_tmp_path

fn moonsuite_product_tmp_path() -> String

#
moonsuite_product_tmp_path_for_workspace_root

fn moonsuite_product_tmp_path_for_workspace_root(root : String) -> String

#
product_kernel_json

fn product_kernel_json() -> Json

#
product_kernel_markdown

fn product_kernel_markdown() -> String

#
trusted_square_dossier

#
trusted_square_html

fn trusted_square_html() -> String

#
trusted_square_json

fn trusted_square_json() -> Json

#
trusted_square_markdown

fn trusted_square_markdown() -> String

#
trusted_square_view_json

fn trusted_square_view_json() -> Json

#
trusted_square_view_markdown

fn trusted_square_view_markdown() -> String

#
trusted_square_view_model